Structured Email: Use cases
draft-ietf-sml-structured-email-use-cases-02
| Document | Type | Active Internet-Draft (sml WG) | |
|---|---|---|---|
| Authors | Ben Bucksch , Hans-Jörg Happel | ||
| Last updated | 2024-10-21 | ||
| Replaces | draft-happel-structured-email-use-cases | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| 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-02
SML B. Bucksch
Internet-Draft Beonex GmbH
Intended status: Informational H.-J. Happel
Expires: 24 April 2025 audriga GmbH
21 October 2024
Structured Email: Use cases
draft-ietf-sml-structured-email-use-cases-02
Abstract
This document collects and discusses use cases for "structured email"
[I-D.ietf-sml-structured-email-02].
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 24 April 2025.
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.
Bucksch & Happel Expires 24 April 2025 [Page 1]
Internet-Draft Structured Email: Use cases October 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Benefits of structured email . . . . . . . . . . . . . . . . 4
3.1. Accessibility . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Interaction . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Auto-processing . . . . . . . . . . . . . . . . . . . . . 4
3.4. Interoperability and data portability . . . . . . . . . . 4
3.5. Enrichment . . . . . . . . . . . . . . . . . . . . . . . 5
4. Information sharing . . . . . . . . . . . . . . . . . . . . . 5
4.1. URL sharing . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Places . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Media . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3. Products and services . . . . . . . . . . . . . . . . 6
4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Bundles . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Newsletters . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Canteen plan . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Travel information . . . . . . . . . . . . . . . . . 7
4.2.4. Meeting information . . . . . . . . . . . . . . . . . 8
5. Transactions . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service-to-Person . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Orders and invoices . . . . . . . . . . . . . . . . . 8
5.1.2. Reservations . . . . . . . . . . . . . . . . . . . . 8
5.1.3. Sign-up messages . . . . . . . . . . . . . . . . . . 9
5.1.4. Status notifications . . . . . . . . . . . . . . . . 9
5.1.5. Authentication and confirmation . . . . . . . . . . . 9
5.1.6. Promotions . . . . . . . . . . . . . . . . . . . . . 10
5.2. Person-to-Service . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Form-based interaction . . . . . . . . . . . . . . . 10
5.2.2. Change of personal data . . . . . . . . . . . . . . . 10
5.2.3. Mail-in-APIs . . . . . . . . . . . . . . . . . . . . 11
6. Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Location sharing . . . . . . . . . . . . . . . . . . . . 11
6.2. Meeting scheduling . . . . . . . . . . . . . . . . . . . 11
6.3. Polls . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Approval . . . . . . . . . . . . . . . . . . . . . . . . 12
6.5. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Email-specific use cases . . . . . . . . . . . . . . . . . . 12
7.1. MUA configuration . . . . . . . . . . . . . . . . . . . . 13
7.2. Reactions . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Structured email signature . . . . . . . . . . . . . . . 13
7.4. Structured vacation notice . . . . . . . . . . . . . . . 14
8. Modeling guidance . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Reusing concepts . . . . . . . . . . . . . . . . . . . . 14
8.2. Describing data, not action . . . . . . . . . . . . . . . 14
8.3. Considering privacy and trust . . . . . . . . . . . . . . 14
Bucksch & Happel Expires 24 April 2025 [Page 2]
Internet-Draft Structured Email: Use cases October 2024
9. Related approaches . . . . . . . . . . . . . . . . . . . . . 15
10. Security considerations . . . . . . . . . . . . . . . . . . . 15
11. Privacy considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This document is currently structured into a brief discussion about
benefits of structured email, followed by different categories of use
cases:
* Information sharing use cases; further distinguished into URL
sharing and "bundles" of information
* Transactional use cases covering communication between persons and
services, which address (semi-)formal interactions carried out via
email messages
* Interaction use cases between persons
* Email-specific use cases that are specfic to the email domain as
such
Each use case includes a small informal note about privacy and trust
levels.
The end of the document contains an initial collection of modeling
guidance and a brief discussion of technical approaches related to
structured email.
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]. Similarly, a "Calendar Calendar User Agent" (CUA) denotes
a client application that a calendar user utilizes to access and
manipulate a calendar [RFC4324].
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.
Bucksch & Happel Expires 24 April 2025 [Page 3]
Internet-Draft Structured Email: Use cases October 2024
3. Benefits of structured email
3.1. Accessibility
The core benefit of structured email is to make email content
machine-readable, which is the basis for the further benefits
discussed in this section.
This may include to unlock alternative means of access:
* On a media level: e.g., a news article offered in text / audio /
video
* On a logical level: ability to switch service (vs. deep-linked URL
to a music service)
3.2. Interaction
Structured data can allow for particular visualizations of
information, such as rendering a map based on geo-cordinates or a
timeline based on dates.
Related to that, particular actions or related apps/services (see als
interoperability) may be offered based on the type of data.
3.3. Auto-processing
The Sieve email filtering language [RFC5228] allows to take actions
on messages, if certain conditions are met. Most of its use cases
are however limited to filing/deleting/forwarding messages based on
keyword matching, due to a lack of understanding of the email content
(with some exceptions such as meeting requests [RFC9671]).
Examples could be structured vacation notices (see Section 7.4,
Paragraph 1) or the management of encryption keys [I-D.pep-sml-auto-
processing-marker-00].
3.4. Interoperability and data portability
Structured data allows to find compatible extensions, apps, or
services which can use or store the information. This is similar to
how MUAs can already deal with media types of attached files
[RFC6838].
In addition, structured data can help to distangle content from a
particular provider (e.g. a product tied to a particular shop or a
song tied to a particular streaming service), thus fostering data
portability. Structured email itself can also be considered a data
export mechanism according to data portability regulations.
Bucksch & Happel Expires 24 April 2025 [Page 4]
Internet-Draft Structured Email: Use cases October 2024
3.5. Enrichment
Structured data enables tools on behalf of the user to combine the
data with other data. This can be local/private data of the user,
such as a calendar or a music collection, or public data such as
weather at a travel destination or upcoming concerts of an artist.
Structured data could also inform a client how to obtain updates on
status notification emails (such as in parcel tracking), live
locations, or polls.
4. Information sharing
This section is about use cases related to sharing information -
either between persons or from a service to a person.
Use cases are distinguished into sharing URLs/"one item per mail" and
sharing "bundles" of items.
4.1. URL sharing
Many websites or browsers allow to share URLs with others - either
individually or via one's social media feed. In addition, sharing
items from mobile apps (e.g., a song in a music app) typically
results in a URL to be shared.
Individual sharing typically points to instant messaging (IM) tools
or to "share by email", using either the "mailto" URI scheme
[RFC6068] or a form provided by the application.
Instant messaging applications and social media sites usually provide
a rich visualization ("link preview") of the shared URL, while "share
by email" usually results in a bare URL pasted in a message body.
SML not just allows MUA to provide link previews (either on sender or
on receiver side), but also to provide more specific interaction
features, if provided with structured data about what is represented
by that URL (e.g., a music album, an event or a news article).
4.1.1. Places
Geo-located places can by of various kinds, such as a local business
or a tourist attraction. The sharing of one's current personal
location is discussed later in this draft (Section 6.1, Paragraph 1).
In email, the can currently either by shared by URLs/deep links to
online map services or using the "geo" URI scheme [RFC5870].
Bucksch & Happel Expires 24 April 2025 [Page 5]
Internet-Draft Structured Email: Use cases October 2024
Indicators:
* Privacy level: low-medium (depending on the nature of the place)
* Trust level: low (no strong case for abuse?)
4.1.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.1.3. 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.1.4. 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:
Bucksch & Happel Expires 24 April 2025 [Page 6]
Internet-Draft Structured Email: Use cases October 2024
* 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.2. Bundles
Emails may be focused on a particular topic/transaction or may cover
a broader set of information. Accordingly, the structured data
contained in such emails might be more extensive. For the sake of
this document, we call these kind of emails "bundles".
4.2.1. 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.2.2. Canteen plan
A weekly canteen plan is probably similar to a newsletter, containing
e.g., meals, opening/closing times and canteen location(s).
Indicators:
* Privacy level: low (usually public information)
* Trust level: low (no strong case for abuse?)
4.2.3. Travel information
Traveling often contains multiple means of transports and locations.
E.g., a hotel reservation might contain restaurant recommendations or
the location of nearby public transport or parking.
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?)
Bucksch & Happel Expires 24 April 2025 [Page 7]
Internet-Draft Structured Email: Use cases October 2024
4.2.4. Meeting information
Similar to the traveling case, certain meetings might not just
consist of the actual meeting, but a related social lunch, reception
or transport information.
Indicators:
* Privacy level: medium (may depend on the kind of meeting)
* Trust level: low (no strong case for abuse?)
5. Transactions
5.1. Service-to-Person
5.1.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.
This use case is already supported by one or more of the email
providers which support [SchemaOrg] in email (see also
[StructuredEmail]).
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)
5.1.2. Reservations
Various types of reservations can be processed by some email
providers and tools (see also [StructuredEmail]). These include
types [SchemaOrg] 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)
Bucksch & Happel Expires 24 April 2025 [Page 8]
Internet-Draft Structured Email: Use cases October 2024
5.1.3. 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.1.4. 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)
5.1.5. Authentication and confirmation
Email is often used as an additional "factor" in multi-factor
authentication or various forms of sign-up procedures. 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)
Bucksch & Happel Expires 24 April 2025 [Page 9]
Internet-Draft Structured Email: Use cases October 2024
5.1.6. Promotions
Promotions may be considered an individual product or a bundle of
products and/or a discount or coupon code.
This use case is already supported by one or more of the email
providers which support [SchemaOrg] in email (see also
[StructuredEmail]).
Indicators:
* Privacy level: medium (promotions may be personalized based on
user's interest or past transactions)
* Trust level: low (just normal SPAM)
5.2. Person-to-Service
5.2.1. Form-based interaction
Email messages are often used for formal requests sent to government
organizations, businesses, or within organizations.
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.2. Change of personal data
Email is often used to inform third parties about the change of
addresses or similar personal information. This typically happens in
an unstructured way, requiring manual actions on both sides and
making the process error prone.
Bucksch & Happel Expires 24 April 2025 [Page 10]
Internet-Draft Structured Email: Use cases October 2024
A structured data format signaling the update of personal data could
provide a standard way of solving this procedure in a more efficient
way.
Indicators:
* Privacy level: high
* Trust level: high
5.2.3. 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)
6. Interaction
Use cases in this section mainly deal with Person-to-Person
interactions.
6.1. Location sharing
Personal location sharing is common feature 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?)
6.2. Meeting scheduling
Message scheduling is probably the most widely use form of
interaction with email messages, which is not mainly based on writing
text.
Bucksch & Happel Expires 24 April 2025 [Page 11]
Internet-Draft Structured Email: Use cases October 2024
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).
Indicators:
* Privacy level: high (exposes whereabouts of the user)
* Trust level: medium (has been abused for calendar spam [CalSpam])
6.3. Polls
Similar to location sharing, polls are a frequent feature of instant
messaging clients. Users essentially pick one or more items from a
list of options.
Indicators:
* Privacy level: low-medium (depending on content)
* Trust level: low (no strong case for abuse?)
6.4. Approval
Email is used in various forms to seek consent between users.
* Privacy level: low-medium (depending on content)
* Trust level: medium-high (depending on impact of approval)
6.5. Tasks
While calendaring and task management are often tightly related in
tooling and specs ([RFC5545]), there are not similar interaction
mechanisms such as IMIP for collaborating on tasks.
Indicators:
* Privacy level: low-medium (depending on content)
* Trust level: low (no strong case for abuse?)
7. 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.
Bucksch & Happel Expires 24 April 2025 [Page 12]
Internet-Draft Structured Email: Use cases October 2024
7.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
7.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
7.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)
Bucksch & Happel Expires 24 April 2025 [Page 13]
Internet-Draft Structured Email: Use cases October 2024
7.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.
See also [I-D.happel-sml-structured-vacation-notices-01]
Indicators:
* Privacy level: medium (many users chose to widely autoreply
vacation notices)
* Trust level: medium (some imaginable attack vector)
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.
Bucksch & Happel Expires 24 April 2025 [Page 14]
Internet-Draft Structured Email: Use cases October 2024
9. Related approaches
During the chartering process of the SML WG, there has been various
discussion about in how far a novel specification is required to
realize the use cases described here, given the already modular and
extensible nature of MIME.
First of all, structured email is based on structured data according
to the RDF knowledge representation language. Hence, SML can, for
example, be realized with a body part of type "application/ld+json"
(JSON-LD is a serialization format for RDF).
One main task of the core SML spec [I-D.ietf-sml-structured-email-02]
is hence to help the MUA distinguish body parts of type "application/
ld+json" which are mere attachments of a message from those which are
actually intended to represent its content.
To this extent, SML can be considered similar to IETF calendaring
standards such as [RFC5598] which provide similar guidance around
iCalendar ([RFC5545]) body parts. Since many common MUAs include
calendar functionality, they can also act in the rule of a CUA. This
tight MUA/CUA interaction comprises several RFCs.
Providing similar RFCs for all use cases described in this draft is
likely unfeasibly. Structured email hence tries to provide a more
generic approach in which MUAs can help support the described use
cases, even though perhaps not in the same detail as they already do
for the calendaring use case.
10. Security considerations
Some security considerations are discussed inline.
11. Privacy considerations
Some privacy considerations are discussed inline.
12. IANA Considerations
This document has no IANA actions at this time.
13. Informative References
[CalSpam] The Calendaring and Scheduling Consortium (“CalConnect”),
"Calendar operator practices — Guidelines to protect
against calendar abuse (CC/R 18003:2019)",
<https://standards.calconnect.org/csd/cc-18003.html>.
Bucksch & Happel Expires 24 April 2025 [Page 15]
Internet-Draft Structured Email: Use cases October 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>.
[RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access
Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December
2005, <https://www.rfc-editor.org/info/rfc4324>.
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
January 2008, <https://www.rfc-editor.org/info/rfc5228>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/info/rfc5545>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Identifier for Geographic Locations ('geo' URI)",
RFC 5870, DOI 10.17487/RFC5870, June 2010,
<https://www.rfc-editor.org/info/rfc5870>.
Bucksch & Happel Expires 24 April 2025 [Page 16]
Internet-Draft Structured Email: Use cases October 2024
[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>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[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>.
[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>.
[RFC9671] Murchison, K., Signes, R., and M. Horsfall, "Sieve Email
Filtering: Extension for Processing Calendar Attachments",
RFC 9671, DOI 10.17487/RFC9671, October 2024,
<https://www.rfc-editor.org/info/rfc9671>.
[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>.
Authors' Addresses
Ben Bucksch
Beonex GmbH
Email: ben.bucksch@beonex.com
URI: https://www.beonex.com
Bucksch & Happel Expires 24 April 2025 [Page 17]
Internet-Draft Structured Email: Use cases October 2024
Hans-Joerg Happel
audriga GmbH
Email: happel@audriga.com
URI: https://www.audriga.com
Bucksch & Happel Expires 24 April 2025 [Page 18]