<?xml version="1.0" encoding="utf-8"?><?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "RFC2629.dtd"[]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline="yes"?>
<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-crocker-inreply-react-14" number="9078" ipr="trust200902" submissionType="IETF"> submissionType="IETF" consensus="true" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.7.0 -->
<front>
<title abbrev="reaction">Reaction: Indicating Summary Reaction to a Message</title>
<seriesInfo name="RFC" value="9078"/>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author fullname="Ricardo Signes" initials="R." surname="Signes">
<organization>Fastmail</organization>
<address>
<email>rjbs@semiotic.systems</email>
</address>
</author>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Oracle</organization>
<address>
<email>ned.freed@mrochek.com</email>
</address>
</author>
<date month="August" year="2021"/>
<area>Applications and Real-Time</area>
<workgroup/>
<keyword>reaction</keyword>
<keyword>emoji</keyword>
<keyword>social networking</keyword>
<keyword>email</keyword>
<keyword>affect</keyword>
<keyword>messaging</keyword>
<keyword>emoticon</keyword>
<keyword>smileys</keyword>
<keyword>like</keyword>
<keyword>mime</keyword>
<keyword>reply</keyword>
<abstract>
<t>The popularity of social media has led to user comfort with easily signaling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smiley' graphic. This specification
permits a similar facility for Internet Mail.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section>
<name>Introduction</name>
<t>The popularity of social media has led to user comfort with easily signaling summary reactions
to an author's posting, by using emoji graphics, such as with a 'thumbs up', 'heart', or
'smiley' indication. Sometimes the permitted repertoire is constrained to a small set set, and
sometimes a more extensive range of indicators is supported. </t>
<t>This specification extends this existing practice in social media and instant messaging into
Internet Mail.</t>
<t>While it is already possible to include symbols and graphics as part of an email reply's
content, there has not been an established means of signalling signaling the semantic substance that
such data are to be taken as a summary 'reaction' to the original message. That message -- that is, a
mechanism to identify symbols as specifically providing a summary reaction to the cited
message,
message rather than merely being part of the free text in the body of a response. Such a
structured use of the symbol(s) allows recipient MUAs Mail User Agents (MUAs) to correlate this reaction to the
original message and possibly to display the information distinctively.</t>
<t>This facility defines a new MIME Content-Disposition, to be used in conjunction with the
In-Reply-To header field, to specify that a part of a message containing one or more emojis
can be be treated as a summary reaction to a previous message.</t>
</section>
<section title="Terminology">
<section>
<name>Terminology</name>
<t>Unless provided here, terminology, architecture architecture, and specification notation used in this
document are incorporated from: <list style="symbols">
<t><xref target="Mail-Arch"/></t>
<t><xref target="Mail-Fmt"/></t>
<t><xref target="MIME"/></t>
</list>, and syntax from:</t>
<ul spacing="normal">
<li>
<xref target="RFC5598"/></li>
<li>
<xref target="RFC5322"/></li>
<li>
<xref target="RFC2045"/></li>
</ul>
<t>Syntax is specified with <list style="symbols">
<t><xref target="ABNF"/></t>
</list>The with</t>
<ul spacing="normal">
<li>
<xref target="RFC5234"/></li>
</ul>
<t>The ABNF rule Emoji-Seq emoji-sequence is inherited from <xref target="Emoji-Seq"/>; details are in
<xref target="contentreact"/>.</t>
<t>Normative language, per <xref target="RFC8174"/>: <list> target="RFC2119"/> and <xref target="RFC8174"/>:</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</list></t>
</section>
<section title="Reaction Content-Disposition" anchor="contentreact">
<name>Reaction Content-Disposition</name>
<t>A message sent as a reply MAY <bcp14>MAY</bcp14> include a part containing: <figure>
<artwork type="ABNF">Content-Disposition: </t>
<artwork><![CDATA[Content-Disposition: reaction </artwork>
</figure> If
]]></artwork>
<t>If such a field is specified specified, the Content-Type of the part MUST be:<figure>
<artwork>Content-Type: <bcp14>MUST</bcp14> be:</t>
<artwork><![CDATA[Content-Type: text/plain; charset=utf-8</artwork>
</figure>
<list>
<t>
<figure>
<preamble>The charset=utf-8
]]></artwork>
<t>The content of this part is restricted to a single line of emoji. The
<xref target="ABNF"/> target="RFC5234"/> is: </preamble>
<artwork type="ABNF">part-content </t>
<sourcecode name="" type="abnf"><![CDATA[part-content = emoji *(WSP emoji) CRLF
emoji = emoji-sequence
emoji-sequence = { defined in [Emoji-Seq] }
base-emojis = thumbs-up / thumbs-down / grinning-face /
frowning-face / crying-face
; Basic set of emojis, drawn from [Emoji-Seq]
; thumbs-up = {U+1F44D}
; thumbs-down = {U+1F44E}
; grinning-face = {U+1F600}
; frowning-face = {U+2639}
; crying-face = {U+1F622}</artwork>
</figure></t>
</list>
</t> {U+1F622}
]]></sourcecode>
<t>The part-content is either the entire content portion of a message's single MIME body or it is the content portion of the first MIME multi-part body-part that constitute a message's
body.</t> multipart body part.</t>
<t>The ABNF rule emoji_sequence emoji-sequence is inherited from <xref target="Emoji-Seq"/>. It defines a set of
Unicode code point sequences, which must then be encoded as UTF-8. Each sequence forms a
single pictograph. The BNF syntax used in [Emoji-Seq] <xref target="Emoji-Seq"/> differs from <xref target="ABNF"/>, target="RFC5234"/> and
MUST
<bcp14>MUST</bcp14> be interpreted as used in Unicode documentation. The referenced document describes these
as sequences of code points.<list style="hanging">
<t hangText="Note: ">The points.</t>
<aside><t>Note: The part-content can first be parsed into candidate reactions,
separated by WSP. Each candidate reaction that does not constitute a single
emoji-sequence (as per <xref target="Emoji-Seq"/>) is invalid. Invalid candidates can
be treated individually, rather than affecting the remainder of the part-content's
processing. The remaining candidates form the set of reactions to be processed. This
approach assumes use of a mechanism for emoji sequence validation that is not
specified here.</t>
</list></t> here.</t></aside>
<t>The rule base-emojis is provided as a simple, common list, or 'vocabulary' of emojis, emojis. It was
developed from some existing practice, practice in social networking, networking and is intended for similar use.
However
However, support for it as a base vocabulary is not required. Having providers and consumers
employ a common set will facilitate user interoperability, but different sets of users might
want to have different, common (shared) sets.</t>
<!--
<t>The emoji(s) express a recipient's summary reaction to the specific message referenced by the
accompanying In-Reply-To header field, for the message in which they both are present. <xref
target="Mail-Fmt"/>. For processing details, see <xref target="processing"/>.</t>-->
<t>The reaction emoji(s) emoji or emojis are linked to the current message's In-Reply-To: In-Reply-To field, which references
an earlier message, message and provides a summary reaction to that earlier message. message <xref
target="Mail-Fmt"/>. target="RFC5322"/>. For processing details, see <xref target="processing"/>.</t>
<t>Reference to unallocated code points SHOULD NOT <bcp14>SHOULD NOT</bcp14> be treated as an error; the corresponding UTF-8
encoded UTF-8-encoded code points SHOULD <bcp14>SHOULD</bcp14> be processed using the system default method for denoting an
unallocated or undisplayable code point. </t>
<t><list style="hanging">
<t hangText="Note: ">The
<aside><t>Note: The "emoji" token looks simple. It isn't. Implementers are
well-advised
well advised not to assume that emoji sequences are trivial to parse or validate.
Among other concerns, an implementation of the Unicode Character Database is required.
An emoji is more than a stand-in for a simple alternation of characters. Similarly,
one emoji sequence is not interchangeable with, or equivalent to, another one, and
comparisons require detailed understanding of the relevant Unicode mechanisms. Use of
an existing Unicode implementation will typically prove extremely helpful, as will an
understanding of the error modes that may arise with a chosen implementation.</t>
</list></t> implementation.</t></aside>
</section>
<section title="Reaction Message Processing" anchor="processing">
<name>Reaction Message Processing</name>
<t>The presentation aspects of reaction processing are necessarily MUA-specific MUA specific and beyond the
scope of this specification. In terms of the message itself, a recipient MUA that supports
this mechanism operates as follows: <list style="numbers">
<t>If </t>
<ol spacing="normal" type="1"><li>If a received message R's header contains an In-Reply-To: In-Reply-To field, check to see if it
references a previous message that the MUA has sent or received. </t>
<t>If </li>
<li>If R's In-Reply-To: does reference one, then check R's message content for a part with
a "reaction" Content-Disposition header field, at either the outermost level or as
part of a multipart at the outermost level.</t>
<t>If level.</li>
<li>If such a part is found, found and the content of the part conforms to the restrictions
outlined above, remove the part from the message and process the part as a reaction. </t>
</list></t>
<t><list style="hanging">
<t hangText="Note: ">A </li>
</ol>
<aside><t>Note: A message's content might include other, nested messages. These can
be analyzed for reactions, independently of the containing message, applying the above
algorithm for each contained message, separately.</t>
</list></t> separately.</t></aside>
<t>Again, the handling of a message that has been successfully processed is MUA-specific MUA specific and
beyond the scope of this specification.</t>
</section>
<section title="Usability Considerations">
<section>
<name>Usability Considerations</name>
<t>This specification defines a mechanism for the structuring and carriage of information. It does
not define any user-level details of use. However However, the design of the user-level mechanisms
associated with this facility is paramount. This section discusses some issues to
consider.</t>
<t><list style="hanging">
<t hangText="Creation: ">Because
<dl newline="false" spacing="normal">
<dt>Creation: </dt>
<dd>Because an email environment is different from a typical social
media platform, there are significant -- and potentially challenging -- choices in the
design of the user interface, to support indication of a reaction. Is the reaction to
be sent only to the original author, or should it be sent to all recipients? Should
the reaction always be sent in a discrete message containing only the reaction, or
should the user also be able to include other message content? (Note that carriage of
the reaction in a normal email message enables inclusion of this other content.)</t>
<t hangText="Display: ">Reaction content.)</dd>
<dt>Display: </dt>
<dd>Reaction indications might be more useful when displayed in close
visual proximity to the original message, rather than merely as part of an email
response thread.
The handling of
multiple reactions, from the same person, is also an opportunity
for possibly interesting making a user experience design choice.</t>
<t hangText="Culture: ">The choice that could be interesting.</dd>
<dt>Culture: </dt>
<dd>The use of an image, intended to serve as a semantic signal, is
determined and affected by cultural factors, which differ in complexity and nuance. It
is important to remain aware that an author's intent when sending a particular emoji
might not match how the recipient interprets it. Even simple, commonly used emojis can
be be subject to these cultural differences.</t>
</list></t>
<t/>
<section title="Example Message"> differences.</dd>
</dl>
<section>
<name>Example Message</name>
<t>A simple message exchange might be:<figure> be:</t>
<artwork><![CDATA[To: recipient@example.com recipient@example.org
From: author@example.com
Date: Today, 29 February 2021 00:00:00 -800
Message-id:
Message-ID: 12345@example.com
Subject: Meeting
Can we chat at 1pm pacific, today?]]></artwork>
</figure> today?
]]></artwork>
<t> with a thumbs-up, affirmative response of:<figure> of:</t>
<artwork><![CDATA[To: author@example.com
From: recipient@example.org
Date: Today, 29 February 2021 00:00:10 -800
Message-id:
Message-ID: 56789@example.org
In-Reply-To: 12345@example.com
Subject: Meeting
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Content-Disposition: Reaction
{U+1F44E}]]></artwork>
</figure> reaction
{U+1F44D}
]]></artwork>
<t> The Unicode character, represented here as "{U+1F44E}" "{U+1F44D}" for readability, would actually be sent as the UTF-8-encoded character. </t> character.</t>
<t>The example could, of course, be more elaborate, such as the first of a MIME multipart sequence.</t>
</section>
<section title="Example Display">
<section>
<name>Example Display</name>
<t>Repeating the caution that actual use of this capability requires careful usability design
and testing, this section describes simple examples -- which have not been tested -- of
how the reaction response might be displayed in a summary list of messages :<list
style="hanging">
<t hangText="Summary: ">Summary messages:</t>
<dl newline="false" spacing="normal">
<dt>Summary:</dt>
<dd>Summary listings of messages in a folder include columns such
as Subject, From, and Date. Another might be added, added to show common reactions and a
count of how many of them have been received.</t>
<t hangText="Message: ">A received.</dd>
<dt>Message:</dt>
<dd>A complete message is often displayed with a tailored section
for header-fields, header fields, enhancing the format and showing only selected header fields. A
pseudo-field might be added, added for reactions, again showing the symbol and a
count.</t>
</list>
</t>
count.</dd>
</dl>
</section>
</section>
<section title="Security Considerations">
<section>
<name>Security Considerations</name>
<t>This specification employs message content that is a strict subset of existing possible
content,
content and thus introduces no new content-specific security considerations. The fact that
this content is structured might seem to make it a new threat surface, but there is no
analysis demonstrating that it does.</t>
<t>This specification defines a distinct Content-Disposition value, value for specialized message
content. Processing that handles the content differently from other content in the message
body might introduce vulnerabilities. Since this capability is likely to produce new user
interaction features, that might also produce new social engineering vulnerabilities.</t>
</section>
<section title="IANA Considerations">
<t>The IANA is requested to register
<section>
<name>IANA Considerations</name>
<t>IANA has registered the Reaction MIME Content-Disposition parameter, per <xref
target="RFC2183"/><list style="hanging">
<t hangText=" Content-Disposition target="RFC2183"/>.</t>
<dl newline="false" spacing="normal">
<dt>Content-Disposition parameter name: ">reaction</t>
<t hangText="Allowable name:</dt>
<dd>reaction</dd>
<dt>Allowable values for this parameter: ">(none)</t>
<t hangText=" Description: ">Permit parameter:</dt>
<dd>(none)</dd>
<dt>Description:</dt>
<dd>Permit a recipient to respond by signaling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smiley' graphic</t>
</list>
</t> graphic</dd>
</dl>
</section>
<section title="Experimental Goals">
<section>
<name>Experimental Goals</name>
<t>The basic, email-specific mechanics for this capability are well-established well established and
well-understood.
well understood. Points of concern, therefore, are: <list style="symbols">
<t>Technical </t>
<ul spacing="normal">
<li>Technical issues in using emojis within a message body part</t>
<t>Market interest</t>
<t>Usability</t>
</list> body</li>
<li>Market interest</li>
<li>Usability</li>
</ul>
<t> So the questions to answer for this Experimental specification are:<list
style="symbols">
<t>Is are:</t>
<ul spacing="normal">
<li>Is there demonstrated interest by MUA developers?</t>
<t>If developers?</li>
<li>If MUA developers add this capability, is it used by authors?</t>
<t>Does authors?</li>
<li>Does the presence of the Reaction capability create any operational problems for
recipients?</t>
<t>Does
recipients?</li>
<li>Does the presence of the Reaction capability demonstrate additional security
issues?</t>
<t>What
issues?</li>
<li>What specific changes to the specification are needed?</t>
<t>What needed?</li>
<li>What other comments will aid in use of this mechanism?</t>
</list>Please mechanism?</li>
</ul>
<t>Please send comments to ietf-822@ietf.org.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
<front>
<title> Key words for use in RFCs to Indicate Requirement Levels </title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t> 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. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>-->
<reference anchor="RFC2183" target="https://www.rfc-editor.org/info/rfc2183">
<front>
<title> Communicating Presentation Information in Internet Messages: The
Content-Disposition Header Field </title>
<author initials="R." surname="Troost" fullname="R. Troost">
<organization/>
</author>
<author initials="S." surname="Dorner" fullname="S. Dorner">
<organization/>
</author>
<author initials="K." surname="Moore" fullname="K. Moore" role="editor">
<organization/>
</author>
<date year="1997" month="August"/>
<abstract>
<t> This memo provides a mechanism whereby messages conforming to the MIME
specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey
presentational information. It specifies the "Content- Disposition" header field,
which is optional and valid for any MIME entity ("message" or "body part").
[STANDARDS-TRACK] </t>
</abstract>
</front>
<seriesInfo name="RFC" value="2183"/>
<seriesInfo name="DOI" value="10.17487/RFC2183"/>
</reference>
<reference anchor="ABNF">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
</author>
<author surname="Overell" initials="P." fullname="P. Overell">
<organization>THUS plc</organization>
</author>
<date year="2008" month="January"/>
</front>
<seriesInfo name="RFC" value="5234"/>
</reference>
<!--
<displayreference target="RFC5234" to="ABNF"/>
<displayreference target="RFC5598" to="Mail-Arch"/>
<displayreference target="RFC5322" to="Mail-Fmt"/>
<displayreference target="RFC2045" to="MIME"/>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2183.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<reference anchor="Emoji-List">
<front>
<title>Full Emoji List, v13.0</title>
<author>
<organization>Unicode Consortium</organization>
<address>
<phone>+1-408-401-8915</phone>
<uri>https://home.unicode.org/</uri>
</address>
</author>
<date/>
</front>
<seriesInfo name="WEB" value="https://unicode.org/emoji/charts/full-emoji-list.html"
/>
</reference>-->
<reference anchor="Emoji-Seq"> anchor="Emoji-Seq" target="https://www.unicode.org/reports/tr51/#def_emoji_sequence">
<front>
<title> Unicode® Unicode Technical Standard #51: Unicode Emoji</title>
<author fullname="M. Davis" initials="M." role="editor" surname="Davis">
<organization>Google, Inc.</organization>
</author>
<author fullname="P. Edberg" initials="P." role="editor" surname="Edberg."> surname="Edberg">
<organization>Apple, Inc</organization>
</author>
<date day="18" month="September" year="2020"/>
</front>
<seriesInfo name="WEB" value="http://www.unicode.org/reports/tr51/#def_emoji_sequence"/>
</reference>
<reference anchor="Mail-Fmt">
<front>
<title>Internet Message Format</title>
<author fullname="Peter W. Resnick" initials="P." role="editor" surname="Resnick">
<organization> Qualcomm Incorporated </organization>
</author>
<date month="October" year="2008"/>
</front>
<seriesInfo name="RFC" value="5322"/>
</reference>
<reference anchor="Mail-Arch">
<front>
<title>Internet Mail Architecture</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
</author>
<date year="2009" month="July"/>
</front>
<seriesInfo name="RFC" value="5598"/>
</reference>
<!-- <reference anchor="Mail-Hdrs">
<front>
<title>Common Internet Message Headers</title>
<author fullname="J. Palme" initials="J." surname="Palme">
<organization>Stockholm University/KTH</organization>
</author>
<date month="February" year="1997"/>
</front>
<seriesInfo name="RFC" value="2076"/>
</reference>-->
<reference anchor="MIME">
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization>Innosoft</organization>
</author>
<author fullname="N. Borenstein" initials="N." surname="Borenstein">
<organization>First Virtual</organization>
</author>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2045"/>
</reference>
<!--<reference anchor="MIME-Enc">
<front>
<title>MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>
</author>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2047"/>
</reference>-->
<!-- <reference anchor="IANA">
<front>
<title>Guidelines for Writing an IANA Considerations Section
in RFCs</title>
<author fullname="M. Cotton" initials="" surname="M. Cotton"/>
<author fullname="B. Leiba" initials="" surname="B. Leiba"/>
<author fullname="T. Narten" initials="" surname="T. Narten"/>
<date year="2017"/>
</front>
<seriesInfo name="I-D"
value="draft-leiba-cotton-iana-5226bis-11"/>
</reference>-->
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
<front>
<title> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words </title>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t> 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. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<!--<references title="Informative References">
</references>-->
<section title="Acknowledgements"> numbered="false">
<name>Acknowledgements</name>
<t>This specification had substantive commentary on three IETF mailing lists.</t>
<t>This work began as a private exercise, in July 2020, with private discussion, for draft-crocker-reply-emoji. It morphed into draft-crocker-inreply-react, with significant discussion on the ietf-822 mailing list, list <eref target="https://www.ietf.org/mailman/listinfo/ietf-822" brackets="angle"/>, September through November 2020. The discussion
produced a fundamental change from proposing a new header field to instead defining a new
Content-Disposition type, as well as significantly enhancing its text concerning Unicode. It
also produced two additional co-authors.</t> coauthors.</t>
<t>In November 2020, the Dispatch mailing list <eref target="https://www.ietf.org/mailman/listinfo/dispatch" brackets="angle"/> was queried about the draft, but it produced no discussion,
though it did garner one statement of interest.</t>
<t>A 4-week Last Call was issued on the this document, January 2021, resulting in quite a bit of fresh
discussion on the last-call mailing list, list <eref target="https://www.ietf.org/mailman/listinfo/last-call" brackets="angle"/> and producing further changes to the draft. this document. After
Last Call completed, additional concerns were surfaced, about regarding the Unicode-related details, details surfaced, producing yet more changes to the draft. document. It also produced a challenge that prompted the
current version of the this Acknowledgements section.</t>
<t>Readers who are interested in the detail details of the document's history are encouraged to peruse the
archives for the three lists, searching Subject fields for "-react".</t> "react".</t>
</section>
</back>
</rfc>