Skip to main content

Structured Email: Use cases
draft-ietf-sml-structured-email-use-cases-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Hans-Jörg Happel
Last updated 2024-02-13
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-sml-structured-email-use-cases-00
SML                                                         H.-J. Happel
Internet-Draft                                              audriga GmbH
Intended status: Informational                          13 February 2024
Expires: 16 August 2024

                      Structured Email: Use cases
              draft-ietf-sml-structured-email-use-cases-00

Abstract

   This document collects and discusses use cases for "structured email"
   ([I-D.happel-structured-email-00]).

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 16 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Happel                   Expires 16 August 2024                 [Page 1]
Internet-Draft         Structured Email: Use cases         February 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  Existing use cases  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Orders and invoices . . . . . . . . . . . . . . . . . . .   3
     3.2.  Promotions  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.3.  Reservations  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Sharing use cases . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Geolocation . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Media . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Newsletters . . . . . . . . . . . . . . . . . . . . . . .   4
     4.4.  Products and services . . . . . . . . . . . . . . . . . .   4
     4.5.  Public events . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Transactional use cases . . . . . . . . . . . . . . . . . . .   5
     5.1.  Formal interaction  . . . . . . . . . . . . . . . . . . .   5
     5.2.  Mail-in-APIs  . . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Multi-factor authentication . . . . . . . . . . . . . . .   5
     5.4.  Sign-up messages  . . . . . . . . . . . . . . . . . . . .   5
     5.5.  Status notifications  . . . . . . . . . . . . . . . . . .   6
   6.  Email-specific use cases  . . . . . . . . . . . . . . . . . .   6
     6.1.  MUA configuration . . . . . . . . . . . . . . . . . . . .   6
     6.2.  Reactions . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.3.  Structured email signature  . . . . . . . . . . . . . . .   6
     6.4.  Structured vacation notice  . . . . . . . . . . . . . . .   7
   7.  Use cases specified by RFCs . . . . . . . . . . . . . . . . .   7
     7.1.  Message scheduling  . . . . . . . . . . . . . . . . . . .   7
   8.  Security considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   11. Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document is currently structured in the following sections:

   *  Existing use cases, which are already in use by vendors.
   *  Sharing use cases, which relate to sharing functions of other
      communication tools such as social networks and instant messaging
      tools.
   *  Transactional use cases, which address (semi-)formal interactions
      carried out via email messages.
   *  Email-specific use cases that are specfic to the email domain as
      such.

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

Happel                   Expires 16 August 2024                 [Page 2]
Internet-Draft         Structured Email: Use cases         February 2024

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.

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.

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.

Happel                   Expires 16 August 2024                 [Page 3]
Internet-Draft         Structured Email: Use cases         February 2024

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.

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.

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.

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

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.

Happel                   Expires 16 August 2024                 [Page 4]
Internet-Draft         Structured Email: Use cases         February 2024

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.

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.

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.

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.

Happel                   Expires 16 August 2024                 [Page 5]
Internet-Draft         Structured Email: Use cases         February 2024

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.

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.

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

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.

Happel                   Expires 16 August 2024                 [Page 6]
Internet-Draft         Structured Email: Use cases         February 2024

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.

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

   <a name="#MessageScheduling"></a>

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

   None to date.

9.  Privacy considerations

   None to date.

10.  IANA Considerations

   This document has no IANA actions at this time.

11.  Informative References

Happel                   Expires 16 August 2024                 [Page 7]
Internet-Draft         Structured Email: Use cases         February 2024

   [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, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3676]  Gellens, R., "The Text/Plain Format and DelSp Parameters",
              RFC 3676, DOI 10.17487/RFC3676, February 2004,
              <https://www.rfc-editor.org/info/rfc3676>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <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, October 2010,
              <https://www.rfc-editor.org/info/rfc6068>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011,
              <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,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9073]  Douglass, M., "Event Publishing Extensions to iCalendar",
              RFC 9073, DOI 10.17487/RFC9073, August 2021,
              <https://www.rfc-editor.org/info/rfc9073>.

Happel                   Expires 16 August 2024                 [Page 8]
Internet-Draft         Structured Email: Use cases         February 2024

   [RFC9078]  Crocker, D., Signes, R., and N. Freed, "Reaction:
              Indicating Summary Reaction to a Message", RFC 9078,
              DOI 10.17487/RFC9078, August 2021,
              <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
   Email: happel@audriga.com
   URI:   https://www.audriga.com

Happel                   Expires 16 August 2024                 [Page 9]