| Internet-Draft | Structured Email: Use cases | February 2024 |
| Happel | Expires 16 August 2024 | [Page] |
This document collects and discusses use cases for "structured email" ([I-D.happel-structured-email-00]).¶
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 (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.¶
This document is currently structured in the following sections:¶
A final section points to related use cases which are addressed by particular RFCs.¶
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.¶
The following use cases are currently supported by one or more of the email providers which support [SchemaOrg] in email (see also [StructuredEmail]).¶
Related to the general topic of online shopping, the [SchemaOrg] types "Order", "Invoice", and "ParcelDelivery" can be used throughout the purchasing lifecycle.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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]).¶
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.¶
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.¶
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¶
<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).¶
None to date.¶
None to date.¶
This document has no IANA actions at this time.¶