Structured Email (sml)

WG Name Structured Email
Acronym sml
Area Applications and Real-Time Area (art)
State Active
Charter charter-ietf-sml-01 Approved
Document dependencies
Personnel Chairs Alexey Melnikov, Arnt Gulbrandsen
Area Director Murray Kucherawy
Delegate Bernie Hoeneisen
Mailing list Address sml@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/sml
Archive https://mailarchive.ietf.org/arch/browse/sml/
Chat Room address https://zulip.ietf.org/#narrow/stream/sml

Charter for Working Group

Today, the content of many email messages is not manually written by users but generated by software. Those messages often have a transactional nature, such as notifications, confirmations, or receipts. Based on templates, their content typically follows a certain structure, even if written in natural language.

Solutions like the Sieve filtering language [RFC5228] leverage such patterns in email structure, allowing users to deal with their emails in a more useful and efficient way. More recently, approaches to annotate text-based information on the Web with a machine-readable variant (e.g., SchemaOrgWeb) have been applied in the email domain (e.g., email markup). While some major vendors support this approach, adoption is still rather low and vendor implementations differ in various aspects.

The Structured Email (SML) working group will develop standards track specifications for:

  • annotating human-readable email content with a machine-readable version, to allow for more reliable and accurate content analysis and processing; and

  • recommendations for security and trust mechanisms that should be applied when processing machine-readable content in email messages.

It may also opt to publish a document illustrating and explaining relevant use cases.

RDF/Schema.org will be the foundation for this work, since it is already used by vendors. The working group will specify how to use RDF/Schema.org in email messages to annotate email content.

Vendors currently embed RDF/Schema.org data in a script tag within the text/html MIME body part. The working group needs to decide if this practice will be adopted, or if structured data should be added as a dedicated MIME part.

This might be determined for both, the case that the machine-readable version is intended to be a partial representation of the human-readable content (similar to multipart-related) and for the case of providing a full representation (multipart/alternative).

Hence, machine-readable data might essentially be added to a message by using MIME body parts. Different from conventional MIME body parts such as images, email clients will need additional specification about how to deal with this data, since it is intended for automated processing.

Towards this end, the working group needs to discuss:

  • Which RDF encoding to use in which part of email messages

  • The usage and sharing of RDF vocabulary for actual annotation

  • How email clients should handle scenarios such as replying, forwarding, or embedded messages

  • Extensions (e.g., to email message formats [RFC5322,RFC2045] or IMAP flags [RFC9051]) that enable tools to efficiently determine if a message or parts of it are machine-readable

  • Security and trust recommendations to prevent abuse of structured email

Structured email should leverage capabilities of the Internet Message Format [RFC5322] and ensure downwards-compatibility with legacy email clients. Users must still be able to consume email content, even if a machine-readable variant exists in parallel.

The following points are out of scope for the working group:

  • Modeling RDF vocabulary for particular use cases or domains. Exceptions might only be made for vocabulary directly related to the email domain itself. If required, such work should be carried out in cooperation with appropriate bodies such as the Schema.org W3C Community Group.

  • The specification will not define how email recipient systems will use structured data once extracted from email messages. Specifications such as adding support for structured email to the Sieve language could however be addressed by a rechartering, once initial work has been finished.

The working group aims to coordinate efforts with at least these related groups as required:

  • Active IETF working groups that deal with most of the IETF’s email activities

  • The Schema.org W3C Community Group (Schema.orgCG)

  • M3AAWG (in particular its Dynamic Email Security SIG)

Milestones

Date Milestone Associated documents
Jun 2024 Submit use case document to illustrate potential applications of this work to the IESG (Informational)
Jun 2024 Submit document document discussing and recommending security and trust mechanisms that should be applied when processing machine-readable content in email messages to the IESG (Proposed Standard)
Jun 2024 Submit document that specifies core conventions on how machine-readable content should be included in email messages and how email clients and servers should interact in their processing to the IESG (Proposed Standard)
Nov 2023 WG adoption of a document discussing and recommending security and trust mechanisms that should be applied when processing machine-readable content in email messages

Done milestones

Date Milestone Associated documents
Done WG adoption of a document that specifies core conventions on how machine-readable content should be included in email messages and how email clients and servers should interact in their processing
Done WG adoption of a use case document to illustrate potential applications of this work