Internet-Draft Structured Email: Use cases October 2024
Bucksch & Happel Expires 24 April 2025 [Page]
Workgroup:
SML
Internet-Draft:
draft-ietf-sml-structured-email-use-cases-02
Published:
Intended Status:
Informational
Expires:
Authors:
B. Bucksch
Beonex GmbH
H.-J. Happel
audriga GmbH

Structured Email: Use cases

Abstract

This document collects and discusses use cases for "structured email" [I-D.ietf-sml-structured-email-02].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 April 2025.

1. Introduction

This document is currently structured into a brief discussion about benefits of structured email, followed by different categories of use cases:

  • Information sharing use cases; further distinguished into URL sharing and "bundles" of information
  • Transactional use cases covering communication between persons and services, which address (semi-)formal interactions carried out via email messages
  • Interaction use cases between persons
  • Email-specific use cases that are specfic to the email domain as such

Each use case includes a small informal note about privacy and trust levels.

The end of the document contains an initial collection of modeling guidance and a brief discussion of technical approaches related to structured email.

2. Conventions Used in This Document

The terms "message" and "email message" refer to "electronic mail messages" or "emails" as specified in [RFC5322]. The term "Message User Agent" (MUA) denotes an email client application as per [RFC5598]. Similarly, a "Calendar Calendar User Agent" (CUA) denotes a client application that a calendar user utilizes to access and manipulate a calendar [RFC4324].

The terms "machine-readable data" and "structured data" are used in contrast to "human-readable" messages and denote information expressed "in a structured format (..) which can be consumed by another program using consistent processing logic" [MachineReadable].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Benefits of structured email

3.1. Accessibility

The core benefit of structured email is to make email content machine-readable, which is the basis for the further benefits discussed in this section.

This may include to unlock alternative means of access:

  • On a media level: e.g., a news article offered in text / audio / video
  • On a logical level: ability to switch service (vs. deep-linked URL to a music service)

3.2. Interaction

Structured data can allow for particular visualizations of information, such as rendering a map based on geo-cordinates or a timeline based on dates.

Related to that, particular actions or related apps/services (see als interoperability) may be offered based on the type of data.

3.3. Auto-processing

The Sieve email filtering language [RFC5228] allows to take actions on messages, if certain conditions are met. Most of its use cases are however limited to filing/deleting/forwarding messages based on keyword matching, due to a lack of understanding of the email content (with some exceptions such as meeting requests [RFC9671]).

Examples could be structured vacation notices (see Section 7.4, Paragraph 1) or the management of encryption keys [I-D.pep-sml-auto-processing-marker-00].

3.4. Interoperability and data portability

Structured data allows to find compatible extensions, apps, or services which can use or store the information. This is similar to how MUAs can already deal with media types of attached files [RFC6838].

In addition, structured data can help to distangle content from a particular provider (e.g. a product tied to a particular shop or a song tied to a particular streaming service), thus fostering data portability. Structured email itself can also be considered a data export mechanism according to data portability regulations.

3.5. Enrichment

Structured data enables tools on behalf of the user to combine the data with other data. This can be local/private data of the user, such as a calendar or a music collection, or public data such as weather at a travel destination or upcoming concerts of an artist.

Structured data could also inform a client how to obtain updates on status notification emails (such as in parcel tracking), live locations, or polls.

4. Information sharing

This section is about use cases related to sharing information - either between persons or from a service to a person.

Use cases are distinguished into sharing URLs/"one item per mail" and sharing "bundles" of items.

4.1. URL sharing

Many websites or browsers allow to share URLs with others - either individually or via one's social media feed. In addition, sharing items from mobile apps (e.g., a song in a music app) typically results in a URL to be shared.

Individual sharing typically points to instant messaging (IM) tools or to "share by email", using either the "mailto" URI scheme [RFC6068] or a form provided by the application.

Instant messaging applications and social media sites usually provide a rich visualization ("link preview") of the shared URL, while "share by email" usually results in a bare URL pasted in a message body.

SML not just allows MUA to provide link previews (either on sender or on receiver side), but also to provide more specific interaction features, if provided with structured data about what is represented by that URL (e.g., a music album, an event or a news article).

4.1.1. Places

Geo-located places can by of various kinds, such as a local business or a tourist attraction. The sharing of one's current personal location is discussed later in this draft (Section 6.1, Paragraph 1).

In email, the can currently either by shared by URLs/deep links to online map services or using the "geo" URI scheme [RFC5870].

Indicators:

  • Privacy level: low-medium (depending on the nature of the place)
  • Trust level: low (no strong case for abuse?)

4.1.2. Media

Media and content such as news articles, books, cooking recipes, films, or music albums are commonly shared by users. Many websites contain corresponding "share buttons". The particular "share by email" feature either launches an email send form or a MUA using a "mailto:" ([RFC6068]) URL.

In both cases, email messages will typically contain a plain website URL pointing to the shared media item. The recipient needs to switch from her MUA to the web browser and find out manually, what kind of content has been shared.

Indicators:

  • Privacy level: low-medium (may expose interest in senstive topics as assume by the person sending sharing the content)
  • Trust level: low (no strong case for abuse?)

4.1.3. Products and services

Similar to media and content, users may share or recommend certain products and services, which may result in a later purchase or reservation (see first section).

Indicators:

  • Privacy level: low-medium (may expose interest in senstive topics as assume by the person sending sharing the content)
  • Trust level: low (no strong case for abuse?)

4.1.4. Events

While (corporate) meeting scheduling is a common use case based on email (see Message Scheduling below), public events are not supported similarly well.

There are efforts to extend the current event data model for this use case ([RFC9073]), which allow to embed [SchemaOrg] into calendar data. Structured email might complement and improve this use case.

Indicators:

  • Privacy level: low-medium (may expose interest in senstive topics as assume by the person sending sharing the content)
  • Trust level: low (no strong case for abuse?)

4.2. Bundles

Emails may be focused on a particular topic/transaction or may cover a broader set of information. Accordingly, the structured data contained in such emails might be more extensive. For the sake of this document, we call these kind of emails "bundles".

4.2.1. Newsletters

Newsletters can be considered as a special conduit for sharing information between a newsletter editor and a larger audience.

They often feature media and content or products. Structured data might ease the further sharing or processing of individual pieces of information.

Indicators:

  • Privacy level: low (as long as a newsletter is not personalized, the mere content does not convey more than the newsletter sending address; private unsubscribe links might be a side aspect)
  • Trust level: low (no strong case for abuse?)

4.2.2. Canteen plan

A weekly canteen plan is probably similar to a newsletter, containing e.g., meals, opening/closing times and canteen location(s).

Indicators:

  • Privacy level: low (usually public information)
  • Trust level: low (no strong case for abuse?)

4.2.3. Travel information

Traveling often contains multiple means of transports and locations. E.g., a hotel reservation might contain restaurant recommendations or the location of nearby public transport or parking.

Indicators:

  • Privacy level: low-medium (may expose interest in senstive topics as assume by the person sending sharing the content)
  • Trust level: low (no strong case for abuse?)

4.2.4. Meeting information

Similar to the traveling case, certain meetings might not just consist of the actual meeting, but a related social lunch, reception or transport information.

Indicators:

  • Privacy level: medium (may depend on the kind of meeting)
  • Trust level: low (no strong case for abuse?)

5. Transactions

5.1. Service-to-Person

5.1.1. Orders and invoices

Related to the general topic of online shopping, the [SchemaOrg] types Order, Invoice, and ParcelDelivery can be used throughout the purchasing lifecycle.

This use case is already supported by one or more of the email providers which support [SchemaOrg] in email (see also [StructuredEmail]).

Indicators:

  • Privacy level: high (orders and invoices may expose senstivite data; even the mere sender/shop may be sensitive in some cases)
  • Trust level: high (fake orders or invoices may pose serious threats)

5.1.2. Reservations

Various types of reservations can be processed by some email providers and tools (see also [StructuredEmail]). These include types [SchemaOrg] for transport (Bus-, CarRental-, Flight-, and TrainReservation), HotelReservation, RestaurantReservation and a generic EventReservation type.

Indicators:

  • Privacy level: high (exposes potential whereabouts of the user)
  • Trust level: high (fake reservations may pose serious threats)

5.1.3. Sign-up messages

Email is a major form of digital communication with third parties and services they offer. The beginning of such interaction is often some form of "sign-up" or "welcome" message.

Structured data could allow MUAs and downstream tools to help users keep track and manage services they have subscribed to.

Indicators:

  • Privacy level: high (may expose senstivite data; even the mere sender may be sensitive in some cases)
  • Trust level: high (starting point of trust relationship)

5.1.4. Status notifications

Various software systems use email message to notify users about certain updates and status changes. In many cases, users may want to respond with a comment, confirmation, or similar actions.

These kind of actions currently involve URLs, which often results in a web browser launched out of the MUA. Structured email could help provide a more seamless and direct user interaction in those cases.

Indicators:

  • Privacy level: high (depends on particular use case)
  • Trust level: high (may be abused for phishing attempts)

5.1.5. Authentication and confirmation

Email is often used as an additional "factor" in multi-factor authentication or various forms of sign-up procedures. Services will send a message to the pre-registered address which users will need to confirm in order to complete a log-in process or similar transactions.

Such messages will typically contain a code and/or a link (URL) to a website.

Indicators:

  • Privacy level: high (security-related; howerver, typically short-lived)
  • Trust level: high (inherently security-related)

5.1.6. Promotions

Promotions may be considered an individual product or a bundle of products and/or a discount or coupon code.

This use case is already supported by one or more of the email providers which support [SchemaOrg] in email (see also [StructuredEmail]).

Indicators:

  • Privacy level: medium (promotions may be personalized based on user's interest or past transactions)
  • Trust level: low (just normal SPAM)

5.2. Person-to-Service

5.2.1. Form-based interaction

Email messages are often used for formal requests sent to government organizations, businesses, or within organizations.

Users may intiate such requests by composing a free-form email message in their MUA or use a so-called "contact form" on a website, which in many cases will generate an email based on the form's content.

Such contact forms are however a major source of email abuse, since the recipient will technically send an email to itself, based on whatever data was entered into the form.

Structured email could provide means which make such formal contact more efficient and trustworthy.

Indicators:

  • Privacy level: high (may depend on use case, though)
  • Trust level: high (due to interaction)

5.2.2. Change of personal data

Email is often used to inform third parties about the change of addresses or similar personal information. This typically happens in an unstructured way, requiring manual actions on both sides and making the process error prone.

A structured data format signaling the update of personal data could provide a standard way of solving this procedure in a more efficient way.

Indicators:

  • Privacy level: high
  • Trust level: high

5.2.3. Mail-in-APIs

Various tools such as ticket systems or mailinglist management software allow for controled vocabulary (such as "UNSUBSCRIBE") in reply messages to trigger certain functionality.

Structured email could help to formalize and improve such use cases, so that they allow for easier interaction.

Indicators:

  • Privacy level: low (may depend on use case, though)
  • Trust level: high (due to interaction)

6. Interaction

Use cases in this section mainly deal with Person-to-Person interactions.

6.1. Location sharing

Personal location sharing is common feature supported by many instant messaging tools. The current best practice to share locations in email messages would probably be to share URLs/deep links to online map services.

Indicators:

  • Privacy level: high (exposes whereabouts of the user)
  • Trust level: low (no strong case for abuse?)

6.2. Meeting scheduling

Message scheduling is probably the most widely use form of interaction with email messages, which is not mainly based on writing text.

Due to the iCalendar Message-Based Interoperability Protocol (iMIP; [RFC6047), certain well-defined messages can be sent between calendaring software in order to deal with meeting invitations.

While mainly focused on private/business meetings, the use case of public events is less well supported in these workflows (see also discussion above).

Indicators:

  • Privacy level: high (exposes whereabouts of the user)
  • Trust level: medium (has been abused for calendar spam [CalSpam])

6.3. Polls

Similar to location sharing, polls are a frequent feature of instant messaging clients. Users essentially pick one or more items from a list of options.

Indicators:

  • Privacy level: low-medium (depending on content)
  • Trust level: low (no strong case for abuse?)

6.4. Approval

Email is used in various forms to seek consent between users.

  • Privacy level: low-medium (depending on content)
  • Trust level: medium-high (depending on impact of approval)

6.5. Tasks

While calendaring and task management are often tightly related in tooling and specs ([RFC5545]), there are not similar interaction mechanisms such as IMIP for collaborating on tasks.

Indicators:

  • Privacy level: low-medium (depending on content)
  • Trust level: low (no strong case for abuse?)

7. Email-specific use cases

This section presents a number of use cases which are specfic to the email domain as such and/or relate to core features of MUAs.

7.1. MUA configuration

Mobile devices can allow special messages for over-the-air (OTA) configuration updates. In a similar fashion, structured email could be used for (re-)configuring MUA settings.

Indicators:

  • Privacy level: low (rather technical information)
  • Trust level: high

7.2. Reactions

Social networks and instant messaging tools allow for various forms of low-level instant reactions, such as "liking", "thumbs up", "heart", or "smiley".

A simple variant for usage in email messages has been proposed in [RFC9078]. Some vendors have also implemented similar solutions, which are however mainly designed for usage within the vendor's own platform ([OutlookReactions], [GmailReactions]).

Indicators:

  • Privacy level: low (reaction by itself does not carry much information)
  • Trust level: low

7.3. Structured email signature

Email signatures are a commonly used feature of MUAs which allow users to append contact details or information about upcoming events to email messages. They may also be a legal obligation in some settings.

There are no standards for such signatures beyond the separator "-- " used in text/plain body parts, which stems from Usenet practice [RFC3676]. With a similar intention, some MUAs allow to append vCard ([RFC6350]) files to outgoing messages.

Indicators:

  • Privacy level: low (considering there is a human-language signature anyway)
  • Trust level: low (peripheral content only)

7.4. Structured vacation notice

So called "vacation notices" or "out-of-office replies" are automated messages which are sent in response to incoming messages if a recipient is absent or otherwise unable to respond.

Those messages typically include instructions for the sender (when to retry or whom to contact instead). MUAs can currently hardly assist in dealing with such messages, as they are mainly based on human-language.

See also [I-D.happel-sml-structured-vacation-notices-01]

Indicators:

  • Privacy level: medium (many users chose to widely autoreply vacation notices)
  • Trust level: medium (some imaginable attack vector)

8. Modeling guidance

This (work in progress) section collects general modeling guidance for discussing and drafting new use cases.

8.1. Reusing concepts

Concepts from existing vocabularies such as [SchemaOrg] should be reused whenever possible. If smaller extension or improvements are required, editors might want to discuss improvements with respective vocabulary maintainers.

8.2. Describing data, not action

Modeling should focus on describing data itself and not prescribe its use unless this is an inherent part of the modeling (such as in the case of a potentialAction property.

E.g., codes for multi-factor authentication might be rather shared as a ConfirmationCodeconcept, than CopyToClipBoard.

8.3. Considering privacy and trust

Modeling should consider privacy and trust implications of sharing underlying data. Such information could guide senders and receivers in taking appropriate action to ensure responsible data processing.

10. Security considerations

Some security considerations are discussed inline.

11. Privacy considerations

Some privacy considerations are discussed inline.

12. IANA Considerations

This document has no IANA actions at this time.

13. Informative References

[CalSpam]
The Calendaring and Scheduling Consortium (“CalConnect”), "Calendar operator practices — Guidelines to protect against calendar abuse (CC/R 18003:2019)", <https://standards.calconnect.org/csd/cc-18003.html>.
[GmailReactions]
Google, "Reply to emails with emoji reactions", <https://support.google.com/mail/answer/14080429?hl=en>.
[MachineReadable]
NIST, "NIST IR 7511 Rev. 4", <https://csrc.nist.gov/glossary/term/Machine_Readable>.
[OutlookReactions]
Microsoft, "Reactions in Microsoft Outlook", <https://support.microsoft.com/en-us/office/reactions-in-microsoft-outlook-06315501-a790-4a2a-90c1-fbc89d84c393>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3676]
Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, DOI 10.17487/RFC3676, , <https://www.rfc-editor.org/info/rfc3676>.
[RFC4324]
Royer, D., Babics, G., and S. Mansour, "Calendar Access Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, , <https://www.rfc-editor.org/info/rfc4324>.
[RFC5228]
Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, , <https://www.rfc-editor.org/info/rfc5228>.
[RFC5322]
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <https://www.rfc-editor.org/info/rfc5322>.
[RFC5545]
Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, , <https://www.rfc-editor.org/info/rfc5545>.
[RFC5598]
Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, , <https://www.rfc-editor.org/info/rfc5598>.
[RFC5870]
Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, , <https://www.rfc-editor.org/info/rfc5870>.
[RFC6068]
Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, , <https://www.rfc-editor.org/info/rfc6068>.
[RFC6350]
Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, , <https://www.rfc-editor.org/info/rfc6350>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9073]
Douglass, M., "Event Publishing Extensions to iCalendar", RFC 9073, DOI 10.17487/RFC9073, , <https://www.rfc-editor.org/info/rfc9073>.
[RFC9078]
Crocker, D., Signes, R., and N. Freed, "Reaction: Indicating Summary Reaction to a Message", RFC 9078, DOI 10.17487/RFC9078, , <https://www.rfc-editor.org/info/rfc9078>.
[RFC9671]
Murchison, K., Signes, R., and M. Horsfall, "Sieve Email Filtering: Extension for Processing Calendar Attachments", RFC 9671, DOI 10.17487/RFC9671, , <https://www.rfc-editor.org/info/rfc9671>.
[SchemaOrg]
W3C Schema.org Community Group, "Schema.org", <https://schema.org/>.
[StructuredEmail]
Structured.email, "Structured.email: Schema.org for Email", <https://structured.email/content/related_work/frameworks/schema_org_for_email.html>.

Authors' Addresses

Ben Bucksch
Beonex GmbH
URI: https://www.beonex.com
Hans-Joerg Happel
audriga GmbH
URI: https://www.audriga.com