]> Structured Quoted Content Apple Inc.
ptao@apple.com
ICANN
arnt@gulbrandsen.priv.no
Beonex
ben.bucksch@beonex.com
Applications and Real-Time Structured Email quoted content reply forward This document describes a machine-readable format for conveying quoted content in email messages. This can be used when replying to or forwarding an email message. Structured quoted content is expected to be used in conjunction with conventional, human-readable quote formatting. They are based on the forthcoming "structured email" specification defined in [I-D.ietf-sml-structured-email-03] and related drafts. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Structured Email Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Email messages often content quoted sections of earlier email messages, typically as part of a reply or a forwarded message. The presentation is entirely determined by the sending MUA. Though various conventions have evolved around this quoting, the behavior is still largely unstandardized, and behavior differs widely between MUAs. Some notable differences include:
  • Where newly authored content may be inserted relative to the quoted content.
    • Some MUAs allow inserting new content only above the quoted message, while some allow inserting new content inline between blocks of quoted text.
  • The formatting used to denote the quoted section.
  • Whether some set of headers are also quoted, or whether an attribution line or preamble is inserted.
    • Whether the headers, attribution line, or preamble are localized into the sender's device language.
Due to the above, an email chain in a user's inbox may involve a wide mix of differing quoting styles, which can be visually disorienting. The goal of this draft is to introduce a standardized way to structure quoted content in message replies and forwarded messages. This allows the sending MUA to annotate the various components of the quoted content in such a way that the receiving MUA can then apply a consistent presentation across all messages.
Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.
Overview An MUA that supports Structured Quoted Content composes the HTML part of a reply or forward as usual, in its own quoting style. It then:
  • marks each part of the quoted content in the HTML part with an element that has a data-id attribute (); and
  • adds an application/ld+json part with a JSON-LD object for each marked element, whose @id matches the element's data-id ().
The figure below shows this for a quote introduced by an attribution line.
An attribution-style quote and its structured data (identifiers shortened) ..... QuotedContent message --> EmailMessage
QuoteAttribution On Sep 15, Alice Chen wrote: from --> sender
date --> dateSent
... TextContent (Alice's text)
]]>
A receiving MUA that supports Structured Quoted Content can therefore find each part of the quoted content in the HTML part, know what it is and which message it comes from, and render it differently (). A receiving MUA that does not support it renders the HTML part as usual.
Structured Email Format
Structured Data Type All quoted content will be transmitted as "Partial representation" as defined in .
Vocabularies Structured Quoted Content uses the Schema.org vocabulary , as well as a custom vocabulary to be defined at INSERT LINK.
JSON-LD Objects The structured data is an array containing two kinds of objects:
  • EmailMessage objects describe a message being quoted. There is one for each message that appears anywhere in the quoted content.
  • QuotedContent, QuotedHeaderBlock, QuotedHeader, QuoteAttribution, TextContent, and ForwardPreamble objects describe how the quoted content is laid out in the HTML part. These objects mark parts of the HTML part.
Where this document says a property references an object, its value is that object's @id, or an array of them. The relationships between the object types are: EmailMessage +-- preamble ------> ForwardPreamble +-- headerBlock ---> QuotedHeaderBlock | +-- header: QuotedHeader objects | +-- value --> a property of the | EmailMessage +-- attribution ---> QuoteAttribution | +-- date --> dateSent | +-- from --> sender +-- content -------> TextContent and nested QuotedContent ]]> A QuotedHeaderBlock and a QuoteAttribution are alternative ways of introducing a quoted message, so a QuotedContent has at most one of them ().
Common Properties Every object has @context, @type, and @id. Each object type defines its own @id format. EmailMessage defines its own @context (); for all other object types, @context is "https://sml.draft.iana.org". Unless stated otherwise, a receiving MUA MUST ignore properties it does not recognize, and MUST process the rest of the object as if they were absent.
EmailMessage An EmailMessage object describes one message that appears in the quoted content. It holds the header field values that MUAs typically show for a quoted message, such as its sender, recipients, subject, and date. The structured data contains one EmailMessage object for each distinct message in the quoted content, at any level of nesting. A sending MUA SHOULD NOT include EmailMessage objects that no QuotedContent object references. When the sending MUA splits one quoted message into several blocks, for example to insert inline comments, each block has its own QuotedContent object, and they all reference the same EmailMessage. EmailMessage uses the Schema.org EmailMessage type, with terms from the sml.draft.iana.org vocabulary for dates. Its @context MUST be the following: Unlike Schema.org's dateSent, these dates are nodes with their own @id, so that QuotedHeader and QuoteAttribution objects can reference them. Its @id is a mid: URL : "mid:" followed by the value of the message's Message-ID header field, without the enclosing angle brackets and percent-encoded as requires. For example, a message with Message-ID: <msg-ex1-001@example.com> has the @id "mid:msg-ex1-001@example.com". Characters such as #, /, and % are allowed in a Message-ID but have special meaning in the URL, so they have to be encoded: Message-ID: <a#b/c@example.com> gives "mid:a%23b%2Fc@example.com".
Value Types The EmailMessage properties in use the following value types. Each property defines the @id format of its values.
DateTime A DateTime is a DateTime object from the sml.draft.iana.org vocabulary, representing a date and time. It has this property:
iso8601Extended
REQUIRED. The date and time in ISO 8601 extended format, with a UTC offset, using the date-time syntax of , for example "2025-09-15T09:47:00-07:00".
Person A Person is a Person object from the Schema.org vocabulary , representing one mailbox. It has these properties:
email
REQUIRED. The mailbox's address, for example "alice@example.com".
name
OPTIONAL. The mailbox's display name with any encoded-words decoded, if the header field includes one.
Thing A Thing is a Thing object from the Schema.org vocabulary. It has this property:
name
REQUIRED. The text that the Thing represents, as defined by the property that uses it.
Properties The following table lists the properties of an EmailMessage, with the requirement level and value type of each. Each property is defined after the table. EmailMessage properties
Property Requirement Value
dateSent REQUIRED DateTime ()
sender REQUIRED Person ()
toRecipient RECOMMENDED Person, or array of Person ()
ccRecipient RECOMMENDED Person, or array of Person ()
about RECOMMENDED Thing ()
bccRecipient MUST NOT appear  
The RECOMMENDED properties apply only when the message has the corresponding header field (To, Cc, or Subject). In addition, an EmailMessage MUST include every property that a QuotedHeader or QuoteAttribution object references. For example, if a header block shows a "Cc:" line, the EmailMessage for that message includes ccRecipient. The properties are defined as follows:
dateSent
The message's Date header field, as a DateTime. Its @id is the message's @id followed by "#dateSent", for example "mid:msg-ex1-001@example.com#dateSent". The UTC offset in its iso8601Extended SHOULD be the one in the Date header field.
sender
The author of the message, from its From header field (not its Sender header field), as a Person. Its @id is a mailto: URI : "mailto:" followed by the mailbox's address, for example "mailto:alice@example.com". The address in the @id, with any percent-encoding decoded, MUST be the same as the Person's email.
toRecipient
The recipients in the message's To header field, as a Person or an array of Person, in the order they appear in the header field. Each Person is as described for sender.
ccRecipient
The recipients in the message's Cc header field, as a Person or an array of Person, in the order they appear in the header field. Each Person is as described for sender.
about
The message's Subject header field, as a Thing. Its @id is the message's @id followed by "#subject", for example "mid:msg-ex1-001@example.com#subject". Its name is the subject text with any encoded-words decoded.
The same mailbox often appears more than once in the structured data, for example as the sender of one message and a recipient of another. A sending MUA SHOULD include the full Person object only once, and use a node reference containing only its @id, for example {"@id": "mailto:alice@example.com"}, for the other occurrences. The bccRecipient property is defined by Schema.org for EmailMessage, but MUST NOT be included. Bcc recipients are hidden from the message's other recipients by design, and including them would disclose them to everyone who receives the new message.
Other Properties A sending MUA MAY include other properties that Schema.org defines for EmailMessage, other than bccRecipient. This document does not define any behavior for such properties, and a receiving MUA MAY ignore them. When a receiving MUA ignores a property, it MUST process the rest of the object as if that property were absent. The presence of such a property does not make the object or the structured data invalid.
QuotedContent A QuotedContent object represents one block of quoted content: a contiguous part of a quoted message, as it appears in the HTML part. It links the block to the message it was quoted from, to any preamble, header block, or attribution line that the sending MUA placed above it, and to the content of the block itself. QuotedContent objects nest. When a quoted message itself contains quoted content, the inner block is a separate QuotedContent object, listed in the content of the outer one. When the sending MUA splits a quoted message into several blocks, for example to insert inline comments between them, each block is a separate QuotedContent object that references the same EmailMessage. Typically only the first of these blocks has an attribution line or header block. A sending MUA introduces a quoted message either with a header block or with an attribution line, depending on its quoting style. A QuotedContent object therefore has at most one of headerBlock and attribution, never both. It has neither when the block has no introduction, for example when it continues a message after an inline comment. Its @type is "QuotedContent", and its @id is "quoted-content:" followed by a UUID . It has the following properties:
message
REQUIRED. References the EmailMessage that this block is quoted from.
preamble
OPTIONAL. References the ForwardPreamble shown above the block. Present only when the block is a forwarded message and the sending MUA shows a preamble.
headerBlock
OPTIONAL. References the QuotedHeaderBlock shown above the block. MUST NOT be present if attribution is present.
attribution
OPTIONAL. References the QuoteAttribution shown above the block. MUST NOT be present if headerBlock is present.
content
REQUIRED. A JSON-LD list ({"@list": [...]}) of references to the TextContent and nested QuotedContent objects that make up the block, in the order they appear in the HTML part.
QuotedHeaderBlock A QuotedHeaderBlock object represents the lines of header fields (such as "From:", "Date:", and "Subject:") that some MUAs show above a quoted or forwarded message. Its @type is "QuotedHeaderBlock", and its @id is "quoted-header-block:" followed by a UUID. It has the following property:
header
REQUIRED. A JSON-LD list ({"@list": [...]}) of one or more QuotedHeader objects, one for each line of the block, in the order they are displayed. A QuotedHeaderBlock with no QuotedHeader objects is not allowed.
QuotedHeader A QuotedHeader object represents one line of a header block. It identifies the EmailMessage property whose value the line shows. QuotedHeader objects appear only in the header list of a QuotedHeaderBlock; they are never top-level objects in the structured data, and no other JSON-LD object refers to them. A QuotedHeader's property and value refer to the EmailMessage referenced by the QuotedContent that the header block belongs to. Its @type is "QuotedHeader", and its @id is "quoted-header:" followed by a UUID. It has the following properties:
property
REQUIRED. References the EmailMessage property that the line shows, by that property's IRI: https://schema.org/sender, https://schema.org/toRecipient, https://schema.org/ccRecipient, https://schema.org/about, or https://sml.draft.iana.org/dateSent. For example, a "From:" line has {"@id": "https://schema.org/sender"}.
value
REQUIRED. References the value that the line shows: the Person objects of sender, toRecipient, or ccRecipient, the subject object of about, or the DateTime of dateSent. When a line shows several recipients, this is an array.
QuoteAttribution A QuoteAttribution object represents the attribution line that some MUAs place above quoted text, for example "On Sep 15, 2025, at 9:47 AM, Alice Chen <alice@example.com> wrote:". Its properties reference the date and sender that the line shows. Its @type is "QuoteAttribution", and its @id is "quote-attribution:" followed by a UUID. It has the following properties:
date
OPTIONAL. References the DateTime of the dateSent property shown in the line. Absent when the line shows no date, as in "Alice Chen wrote:".
from
REQUIRED. References the Person of the sender property shown in the line.
TextContent A TextContent object represents a section of a quoted message's body , not including any content that the message itself quotes. Its @type is "TextContent", and its @id is "text-content:" followed by a UUID. It has no properties other than the common ones.
ForwardPreamble A ForwardPreamble object marks the line that some MUAs place at the start of a forwarded message, such as "---------- Forwarded message ---------" or "Begin forwarded message:". Its @type is "ForwardPreamble", and its @id is "forward-preamble:" followed by a UUID. It has no properties other than the common ones.
HTML Format Each QuotedContent, QuotedHeaderBlock, QuotedHeader, QuoteAttribution, TextContent, and ForwardPreamble object MUST correspond to exactly one element in the HTML part, typically a div or span. The element has the following attributes:
data-id
REQUIRED. The @id of the object, as defined in .
data-source-hint
OPTIONAL. A hint for where to find the object: a cid: URI referencing the MIME part that contains the structured data. The object is identified by its data-id; this attribute only suggests where to look for it.
An object's element MUST be inside the element of the object that refers to it. The elements of a QuotedContent's preamble, header block, attribution line, and content are inside the QuotedContent's element, and the element of each QuotedHeader is inside the element of its QuotedHeaderBlock. EmailMessage objects describe messages rather than parts of the HTML part, and have no element.
MUA Guidance Structured Quoted Content identifies the parts of the quoted content in the HTML part, and the messages they were quoted from. A receiving MUA can use it to change or replace how the quoted content is rendered, in any number of ways. For example, it can:
  • Switch between quoting styles, for example rendering a header block as an attribution line or an attribution line as a header block, using the values in the EmailMessage.
  • Add or remove quoted header lines. For example, an MUA that always shows exactly the Date, Subject, and To of each quoted message can add any of those lines that a header block lacks, using the values in the EmailMessage, and remove any other lines.
  • Translate the attribution line or quoted header labels into the user's preferred language.
  • Show the date of a quoted message in the user's own time zone, or as the sender saw it, using the UTC offset in dateSent.
  • Replace, translate, or hide a forward preamble.
  • Add an attribution line to a quoted block that has none, such as a block that continues a quoted message after an inline comment, so that the author of every block is clear.
  • Identify quoted text reliably, including deeply nested quotes, and collapse or condense it, without having to infer the quote structure from the HTML.
A receiving MUA can use as much or as little of the structure as it needs. At one end, it can work on a single kind of object and leave the rest of the HTML part as the sending MUA wrote it, for example translating the labels of quoted header lines while ignoring the rest of the quoted structure. At the other end, it can replace the HTML of an entire top-level QuotedContent block with HTML it generates itself from the structured data. It can also do anything in between. The text of the quoted messages is not in the structured data; it is only in the HTML part, in the elements of the TextContent objects. A receiving MUA that generates its own HTML for a block therefore still uses the HTML of those elements for the quoted text.
Backwards Compatibility Not every MUA in a reply chain will support Structured Quoted Content. This creates two situations:
  1. An MUA that supports Structured Quoted Content quotes a message that has none.
  2. An MUA that does not support Structured Quoted Content quotes a message that has it.
Quoting a Message Without Structured Quoted Content An MUA that quotes a message without Structured Quoted Content SHOULD NOT try to reconstruct that message's quote structure, for example by parsing its HTML. Instead, it treats the quoted message as containing no quoted content: the message's body, including anything that it quotes in turn, is TextContent, with no nested QuotedContent. shows this.
Quoting a Message With Structured Quoted Content, Without Support An MUA that does not support Structured Quoted Content is not bound by this document. When it quotes a message that has Structured Quoted Content, it can break it, for example by:
  • editing the HTML, so that its elements no longer match the objects in the structured data;
  • removing or changing the application/ld+json part, or keeping it only as an attachment, as some MUAs do with a quoted or forwarded message's attachments; or
  • changing the MIME structure, so that the message is no longer a partial representation.
The resulting message has no usable Structured Quoted Content, even if its HTML still contains data-id attributes copied from the message it quoted.
Effect on Later Messages As a result, the structured data in a message describes only the most recent part of the reply chain: the messages back to the first one sent by an MUA without Structured Quoted Content support. Older messages are part of that message's TextContent, as ordinary HTML. When rendering a message, a receiving MUA SHOULD use only the structured data in that message's own application/ld+json part: the one in the same multipart/related entity as the HTML part it describes (). An application/ld+json part elsewhere in the message, such as one attached from a quoted message, is not that message's structured data. A receiving MUA SHOULD ignore any data-id attribute that does not match an object in that part, and render that HTML as ordinary content.
Examples The examples in this section illustrate how Structured Quoted Content is applied across a range of common quoting scenarios. In each example, the application/ld+json MIME part carries all JSON-LD objects, its Content-Id is referenced by the data-source-hint attributes in the HTML part, and HTML elements use data-id to identify their corresponding JSON-LD object. Each Person is included in full once, at its first occurrence, and referenced by its @id elsewhere (). All examples use the following MIME structure, with a unique Content-Id per message: ]]>
Example 1: Forward Containing a Nested Quote Alice emails Bob. Bob replies and CCs Carol. Carol forwards Bob's reply to Dave. Carol's message has the following structure:
HTML Part
---------- Forwarded message ---------
From: Bob Kumar <bob@example.com>
Date: Mon, Sep 15, 2025 at 2:23 PM
Subject: Re: Lorem ipsum
To: Alice Chen <alice@example.com>
On Sep 15, 2025, at 9:47 AM, Alice Chen <alice@example.com> wrote:
]]>
JSON-LD Part
Example 2: Reply with Inline Comment Carol emails Dave and Eve. Dave replies, quoting Carol's message. Eve replies, inserting an inline comment between Carol's message text. Eve's message has the following structure:
HTML Part
On Mon, Oct 6, 2025 at 2:15 PM, Dave Nguyen <dave@example.com> wrote:
From: Carol Davies <carol@example.com>
Sent: Monday, October 6, 2025 9:00 AM
To: Dave Nguyen <dave@example.com>; Eve Larsson <eve@example.com>
Subject: Lorem ipsum
]]>
JSON-LD Part
Example 3: Quote Chain including Non-Adopter Frank emails Grace, Heidi, and Ivan. Grace replies to Frank; Grace's MUA does not support Structured Quoted Content. Heidi replies to Grace. Ivan replies to Heidi. Ivan's message has the following structure:
HTML Part
On Tue, Oct 7, 2025 at 11:30 AM, Heidi Mueller <heidi@example.com> wrote:
From: Grace Kim <grace@example.com> Sent: Tuesday, October 7, 2025 10:15 To: Frank Osei <frank@example.com>; Heidi Mueller <heidi@example.com>; Ivan Santos <ivan@example.com> Subject: Re: Lorem ipsum
]]>
JSON-LD Part
Security Considerations TODO Security
IANA Considerations This document has no IANA actions.
Normative References JSON-LD 1.1 Schema.org W3C Schema.org Community Group n.d. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Structured Email audriga GmbH This document specifies how a machine-readable variant of its content can be added to email messages. Internet Message Format This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] Content-ID and Message-ID Uniform Resource Locators The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK] Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. The 'mailto' URI Scheme This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK] MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK] Universally Unique IDentifiers (UUIDs) This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122.
Acknowledgments TODO acknowledge.