Structured Email: Use cases

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.

Conventions Used in This Document The terms "message" and "email message" refer to "electronic mail messages" or "emails" as specified in . The term "Message User Agent" (MUA) denotes an email client application as per . Similarly, a "Calendar Calendar User Agent" (CUA) denotes a client application that a calendar user utilizes to access and manipulate a calendar . 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" . 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 when, and only when, they appear in all capitals, as shown here.

Benefits of structured email

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)

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.

Auto-processing The Sieve email filtering language 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 ). Examples could be structured vacation notices (see ) or the management of encryption keys [I-D.pep-sml-auto-processing-marker-00].

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 . 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.

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.

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.

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 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).

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 (). In email, the can currently either by shared by URLs/deep links to online map services or using the "geo" URI scheme . Indicators:

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

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:" () 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?)

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?)

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 (), which allow to embed 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?)

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".

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?)

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?)

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?)

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?)

Transactions

Service-to-Person

Orders and invoices Related to the general topic of online shopping, the 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 in email (see also ). 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)

Reservations Various types of reservations can be processed by some email providers and tools (see also ). These include types 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)

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)

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)

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)

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 in email (see also ). Indicators:

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

Person-to-Service

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)

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

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)

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

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?)

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 )

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?)

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)

Tasks While calendaring and task management are often tightly related in tooling and specs (), 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?)

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.

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

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 . Some vendors have also implemented similar solutions, which are however mainly designed for usage within the vendor's own platform (, ). Indicators:

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

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 . With a similar intention, some MUAs allow to append vCard () files to outgoing messages. Indicators:

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

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)

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

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.

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.

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.

Related approaches During the chartering process of the SML WG, there has been various discussion about in how far a novel specification is required to realize the use cases described here, given the already modular and extensible nature of MIME. First of all, structured email is based on structured data according to the RDF knowledge representation language. Hence, SML can, for example, be realized with a body part of type "application/ld+json" (JSON-LD is a serialization format for RDF). One main task of the core SML spec [I-D.ietf-sml-structured-email-02] is hence to help the MUA distinguish body parts of type "application/ld+json" which are mere attachments of a message from those which are actually intended to represent its content. To this extent, SML can be considered similar to IETF calendaring standards such as which provide similar guidance around iCalendar () body parts. Since many common MUAs include calendar functionality, they can also act in the rule of a CUA. This tight MUA/CUA interaction comprises several RFCs. Providing similar RFCs for all use cases described in this draft is likely unfeasibly. Structured email hence tries to provide a more generic approach in which MUAs can help support the described use cases, even though perhaps not in the same detail as they already do for the calendaring use case.

Security considerations Some security considerations are discussed inline.

Privacy considerations Some privacy considerations are discussed inline.

IANA Considerations This document has no IANA actions at this time.