From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: sml@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Structured Email (sml)
A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2023-10-02.
Structured Email (sml)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Alexey Melnikov <alexey.melnikov@isode.com>
Barry Leiba <barryleiba@computer.org>
Assigned Area Director:
Murray Kucherawy <superuser@gmail.com>
Applications and Real-Time Area Directors:
Murray Kucherawy <superuser@gmail.com>
Francesca Palombini <francesca.palombini@ericsson.com>
Mailing list:
Address: sml@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/sml
Archive: https://mailarchive.ietf.org/arch/browse/sml/
Group page: https://datatracker.ietf.org/group/sml/
Charter: https://datatracker.ietf.org/doc/charter-ietf-sml/
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 specifications for
annotating human-readable email content with a machine-readable version, to
allow for more reliable and accurate content analysis and processing.
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:
Nov 2023 - WG adoption of a use case document to illustrate potential
applications of this work
Nov 2023 - 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
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
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
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
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
sml-chairs@ietf.org,
sml@ietf.org
Subject: WG Action: Formed Structured Email (sml)
A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information, please contact the Area Directors or the WG Chair.
Structured Email (sml)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Alexey Melnikov <alexey.melnikov@isode.com>
Assigned Area Director:
Murray Kucherawy <superuser@gmail.com>
Applications and Real-Time Area Directors:
Murray Kucherawy <superuser@gmail.com>
Francesca Palombini <francesca.palombini@ericsson.com>
Mailing list:
Address: sml@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/sml
Archive: https://mailarchive.ietf.org/arch/browse/sml/
Group page: https://datatracker.ietf.org/group/sml/
Charter: https://datatracker.ietf.org/doc/charter-ietf-sml/
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:
Nov 2023 - WG adoption of a use case document to illustrate potential
applications of this work
Nov 2023 - 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
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
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)
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 use case document to illustrate potential applications of
this work to the IESG (Informational)