Internet-Draft Structured Email: Use cases July 2024
Happel Expires 9 January 2025 [Page]
Workgroup:
SML
Internet-Draft:
draft-ietf-sml-structured-email-use-cases-01
Published:
Intended Status:
Informational
Expires:
Author:
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-01].

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 9 January 2025.

Table of Contents

1. Introduction

This document is currently structured in the following sections:

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

A final section points to related use cases which are addressed by particular RFCs.

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

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. Existing use cases

The following use cases are currently supported by one or more of the email providers which support [SchemaOrg] in email (see also [StructuredEmail]).

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

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)

3.2. Promotions

Some vendors support arrays of structured data which are aggregated to show promotional offers to end users.

These arrays contain a set of products (images), a discount or coupon code and vendor information.

Indicators:

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

3.3. Reservations

Various types of reservations can be processed by some email providers and tools. 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)

4. Sharing use cases

4.1. Geolocation

Location sharing is common action 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?)

4.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.3. 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.4. 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.5. Public 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?)

5. Transactional use cases

5.1. Formal interaction

Email messages are often used for formal requests sent to government organizations or business.

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

5.3. Multi-factor authentication

Email is often used as an additional "factor" in multi-factor authentication. 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.4. 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.5. 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)

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

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

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

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

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

Indicators:

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

7. Use cases specified by RFCs

Specific structured formats for email messages have been employed for a number of specific use cases in the past. Semantics and interactions of these messages have been captured in individual RFCS

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

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.

9. Security considerations

Some security considerations are discussed inline.

10. Privacy considerations

Some privacy considerations are discussed inline.

11. IANA Considerations

This document has no IANA actions at this time.

12. Informative References

[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>.
[RFC5322]
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <https://www.rfc-editor.org/info/rfc5322>.
[RFC5598]
Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, , <https://www.rfc-editor.org/info/rfc5598>.
[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>.
[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>.
[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>.

Author's Address

Hans-Joerg Happel
audriga GmbH