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)", . Bucksch & Happel Expires 24 April 2025 [Page 15] Internet-Draft Structured Email: Use cases October 2024 [GmailReactions] Google, "Reply to emails with emoji reactions", . [MachineReadable] NIST, "NIST IR 7511 Rev. 4", . [OutlookReactions] Microsoft, "Reactions in Microsoft Outlook", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, DOI 10.17487/RFC3676, February 2004, . [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December 2005, . [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, . 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, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9073] Douglass, M., "Event Publishing Extensions to iCalendar", RFC 9073, DOI 10.17487/RFC9073, August 2021, . [RFC9078] Crocker, D., Signes, R., and N. Freed, "Reaction: Indicating Summary Reaction to a Message", RFC 9078, DOI 10.17487/RFC9078, August 2021, . [RFC9671] Murchison, K., Signes, R., and M. Horsfall, "Sieve Email Filtering: Extension for Processing Calendar Attachments", RFC 9671, DOI 10.17487/RFC9671, October 2024, . [SchemaOrg] W3C Schema.org Community Group, "Schema.org", . [StructuredEmail] Structured.email, "Structured.email: Schema.org for Email", . 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]