rfc9078xml2.original.xml   rfc9078.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "RFC2629.dtd"[]> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?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" ?>
<rfc category="exp" docName="draft-crocker-inreply-react-14" ipr="trust200902" s
ubmissionType="IETF">
<front>
<title abbrev="reaction">Reaction: Indicating Summary Reaction to a Mess
age</title>
<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 year="2021"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-cr
<area>Applications and Real-Time</area> ocker-inreply-react-14" number="9078" ipr="trust200902" submissionType="IETF" co
<workgroup/> nsensus="true" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" ver
sion="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"/>
<keyword>reaction</keyword> <keyword>reaction</keyword>
<keyword>emoji</keyword> <keyword>emoji</keyword>
<keyword>social networking</keyword> <keyword>social networking</keyword>
<keyword>email</keyword> <keyword>email</keyword>
<keyword>affect</keyword> <keyword>affect</keyword>
<keyword>messaging</keyword> <keyword>messaging</keyword>
<keyword>emoticon</keyword> <keyword>emoticon</keyword>
<keyword>smileys</keyword> <keyword>smileys</keyword>
<keyword>like</keyword> <keyword>like</keyword>
<keyword>mime</keyword> <keyword>mime</keyword>
<keyword>reply</keyword> <keyword>reply</keyword>
<abstract> <abstract>
<t>The popularity of social media has led to user comfort with easil <t>The popularity of social media has led to user comfort with easily sign
y signaling basic reactions to aling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smiley' grap hic. This specification an author's posting, such as with a 'thumbs up' or 'smiley' grap hic. This specification
permits a similar facility for Internet Mail.</t> permits a similar facility for Internet Mail.</t>
</abstract> </abstract>
</front> </front>
<middle>
<section>
<name>Introduction</name>
<middle> <t>The popularity of social media has led to user comfort with easily sign
<section title="Introduction"> aling summary reactions
<t>The popularity of social media has led to user comfort with easil
y signaling summary reactions
to an author's posting, by using emoji graphics, such as with a 'thumbs up', 'heart', or to an author's posting, by using emoji graphics, such as with a 'thumbs up', 'heart', or
'smiley' indication. Sometimes the permitted repertoire is const rained to a small set and 'smiley' indication. Sometimes the permitted repertoire is const rained to a small set, and
sometimes a more extensive range of indicators is supported. </t > sometimes a more extensive range of indicators is supported. </t >
<t>This specification extends this existing practice in social media and i
<t>This specification extends this existing practice in social media nstant messaging into
and instant messaging into
Internet Mail.</t> Internet Mail.</t>
<t>While it is already possible to include symbols and graphics as part of
<t>While it is already possible to include symbols and graphics as p an email reply's
art of an email reply's content, there has not been an established means of signaling th
content, there has not been an established means of signalling t e semantic substance that
he semantic substance that such data are to be taken as a summary 'reaction' to the origina
such data are to be taken as a summary 'reaction' to the origina l message -- that is, a
l message. That is, a
mechanism to identify symbols as specifically providing a summar y reaction to the cited mechanism to identify symbols as specifically providing a summar y reaction to the cited
message, rather than merely being part of the free text in the b message rather than merely being part of the free text in the bo
ody of a response. Such a dy of a response. Such a
structured use of the symbol(s) allows recipient MUAs to correla structured use of the symbol(s) allows recipient Mail User Agent
te this reaction to the s (MUAs) to correlate this reaction to the
original message and possibly to display the information distinc tively.</t> original message and possibly to display the information distinc tively.</t>
<t>This facility defines a new MIME Content-Disposition, to be used in con
<t>This facility defines a new MIME Content-Disposition, to be used junction with the
in conjunction with the
In-Reply-To header field, to specify that a part of a message co ntaining one or more emojis In-Reply-To header field, to specify that a part of a message co ntaining one or more emojis
can be be treated as a summary reaction to a previous message.</ can be treated as a summary reaction to a previous message.</t>
t> </section>
<section>
</section> <name>Terminology</name>
<t>Unless provided here, terminology, architecture, and specification nota
<section title="Terminology"> tion used in this
document are incorporated from:</t>
<t>Unless provided here, terminology, architecture and specification <ul spacing="normal">
notation used in this <li>
document are incorporated from: <list style="symbols"> <xref target="RFC5598"/></li>
<t><xref target="Mail-Arch"/></t> <li>
<t><xref target="Mail-Fmt"/></t> <xref target="RFC5322"/></li>
<t><xref target="MIME"/></t> <li>
</list>, and syntax is specified with <list style="symbols"> <xref target="RFC2045"/></li>
<t><xref target="ABNF"/></t> </ul>
</list>The ABNF rule Emoji-Seq is inherited from <xref target="E <t>Syntax is specified with</t>
moji-Seq"/>; details are in <ul spacing="normal">
<li>
<xref target="RFC5234"/></li>
</ul>
<t>The ABNF rule emoji-sequence is inherited from <xref target="Emoji-Seq"
/>; details are in
<xref target="contentreact"/>.</t> <xref target="contentreact"/>.</t>
<t>Normative language, per <xref target="RFC2119"/> and <xref target="RFC8
174"/>:</t>
<t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="contentreact">
<name>Reaction Content-Disposition</name>
<t>A message sent as a reply <bcp14>MAY</bcp14> include a part containing:
</t>
<t>Normative language, per <xref target="RFC8174"/>: <list> <artwork><![CDATA[Content-Disposition: reaction
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S ]]></artwork>
HALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTI
ONAL" 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.</t>
</list></t>
</section> <t>If such a field is specified, the Content-Type of the part <bcp14>MUST< /bcp14> be:</t>
<section title="Reaction Content-Disposition" anchor="contentreact"> <artwork><![CDATA[Content-Type: text/plain; charset=utf-8
<t>A message sent as a reply MAY include a part containing: <figure> ]]></artwork>
<artwork type="ABNF">Content-Disposition: reaction </artwork <t>The content of this part is restricted to a single line of emoji. T
> he
</figure> If such a field is specified the Content-Type of the p <xref target="RFC5234"/> is: </t>
art MUST be:<figure>
<artwork>Content-Type: text/plain; charset=utf-8</artwork> <sourcecode name="" type="abnf"><![CDATA[part-content = emoji *(WSP
</figure> emoji) CRLF
<list>
<t>
<figure>
<preamble>The content of this part is restricted to
a single line of emoji. The
<xref target="ABNF"/> is: </preamble>
<artwork type="ABNF">part-content = emoji *(WSP e
moji) CRLF
emoji = emoji-sequence emoji = emoji-sequence
emoji-sequence = { defined in [Emoji-Seq] } emoji-sequence = { defined in [Emoji-Seq] }
base-emojis = thumbs-up / thumbs-down / grinning-face / base-emojis = thumbs-up / thumbs-down / grinning-face /
frowning-face / crying-face frowning-face / crying-face
; Basic set of emojis, drawn from [Emoji-Seq]
thumbs-up = {U+1F44D} ; thumbs-up = {U+1F44D}
thumbs-down = {U+1F44E} ; thumbs-down = {U+1F44E}
grinning-face = {U+1F600} ; grinning-face = {U+1F600}
frowning-face = {U+2639} ; frowning-face = {U+2639}
crying-face = {U+1F622}</artwork> ; crying-face = {U+1F622}
</figure></t> ]]></sourcecode>
</list> <t>The part-content is either the message's single MIME body or the conten
</t> t portion of the first MIME multipart body part.</t>
<t>The ABNF rule emoji-sequence is inherited from <xref target="Emoji-Seq"
<t>The part-content is either the entire content portion of a messag />. It defines a set of
e'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>
<t>The ABNF rule emoji_sequence is inherited from <xref target="Emoj
i-Seq"/>. It defines a set of
Unicode code point sequences, which must then be encoded as UTF- 8. Each sequence forms a 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] differs fr single pictograph. The BNF syntax used in <xref target="Emoji-Se
om <xref target="ABNF"/>, and q"/> differs from <xref target="RFC5234"/> and
MUST be interpreted as used in Unicode documentation. The refere <bcp14>MUST</bcp14> be interpreted as used in Unicode documentat
nced document describes these ion. The referenced document describes these
as sequences of code points.<list style="hanging"> as sequences of code points.</t>
<t hangText="Note: ">The part-content can first be parsed i
nto candidate reactions, <aside><t>Note: The part-content can first be parsed into candidate reac
tions,
separated by WSP. Each candidate reaction that does not constitute a single separated by WSP. Each candidate reaction that does not constitute a single
emoji-sequence (as per <xref target="Emoji-Seq"/>) is in valid. Invalid candidates can emoji-sequence (as per <xref target="Emoji-Seq"/>) is in valid. Invalid candidates can
be treated individually, rather than affecting the remai nder of the part-content's be treated individually, rather than affecting the remai nder of the part-content's
processing. The remaining candidates form the set of rea ctions to be processed. This processing. The remaining candidates form the set of rea ctions to be processed. This
approach assumes use of a mechanism for emoji sequence v alidation that is not approach assumes use of a mechanism for emoji sequence v alidation that is not
specified here.</t> specified here.</t></aside>
</list></t>
<t>The rule base-emojis is provided as a simple, common list, or 'vo <t>The rule base-emojis is provided as a simple, common list, or 'vocabula
cabulary' of emojis, It was ry' of emojis. It was
developed from some existing practice, in social networking, and developed from some existing practice in social networking and i
is intended for similar use. s intended for similar use.
However support for it as a base vocabulary is not required. Hav However, support for it as a base vocabulary is not required. Ha
ing providers and consumers ving providers and consumers
employ a common set will facilitate user interoperability, but d ifferent sets of users might employ a common set will facilitate user interoperability, but d ifferent sets of users might
want to have different, common (shared) sets.</t> want to have different, common (shared) sets.</t>
<t>The reaction emoji or emojis are linked to the current message's
<!-- <t>The emoji(s) express a recipient's summary reacti In-Reply-To field, which references
on to the specific message referenced by the an earlier message and provides a summary reaction to that earli
accompanying In-Reply-To header field, for the message in which er message <xref target="RFC5322"/>. For processing details, see <xref target="p
they both are present. <xref rocessing"/>.</t>
target="Mail-Fmt"/>. For processing details, see <xref targe <t>Reference to unallocated code points <bcp14>SHOULD NOT</bcp14> be treat
t="processing"/>.</t>--> ed as an error; the corresponding UTF-8-encoded code points <bcp14>SHOULD</bcp14
> be processed using the system default method for denoting an
<t>The reaction emoji(s) are linked to the current message's In-Repl
y-To: field, which references
an earlier message, and provides a summary reaction to that earl
ier message. <xref
target="Mail-Fmt"/>. For processing details, see <xref targe
t="processing"/>.</t>
<t>Reference to unallocated code points SHOULD NOT be treated as an
error; the corresponding UTF-8
encoded code points SHOULD be processed using the system default
method for denoting an
unallocated or undisplayable code point. </t> unallocated or undisplayable code point. </t>
<aside><t>Note: The "emoji" token looks simple. It isn't. Implementers a
<t><list style="hanging"> re
<t hangText="Note: ">The "emoji" token looks simple. It isn well advised not to assume that emoji sequences are triv
't. Implementers are ial to parse or validate.
well-advised not to assume that emoji sequences are triv
ial to parse or validate.
Among other concerns, an implementation of the Unicode C haracter Database is required. Among other concerns, an implementation of the Unicode C haracter Database is required.
An emoji is more than a stand-in for a simple alternatio n of characters. Similarly, An emoji is more than a stand-in for a simple alternatio n of characters. Similarly,
one emoji sequence is not interchangeable with, or equiv alent to, another one, and one emoji sequence is not interchangeable with, or equiv alent to, another one, and
comparisons require detailed understanding of the releva nt Unicode mechanisms. Use of comparisons require detailed understanding of the releva nt Unicode mechanisms. Use of
an existing Unicode implementation will typically prove extremely helpful, as will an an existing Unicode implementation will typically prove extremely helpful, as will an
understanding of the error modes that may arise with a c understanding of the error modes that may arise with a c
hosen implementation.</t> hosen implementation.</t></aside>
</list></t> </section>
</section> <section anchor="processing">
<name>Reaction Message Processing</name>
<section title="Reaction Message Processing" anchor="processing"> <t>The presentation aspects of reaction processing are necessarily MUA spe
cific and beyond the
<t>The presentation aspects of reaction processing are necessarily M
UA-specific and beyond the
scope of this specification. In terms of the message itself, a r ecipient MUA that supports scope of this specification. In terms of the message itself, a r ecipient MUA that supports
this mechanism operates as follows: <list style="numbers"> this mechanism operates as follows: </t>
<t>If a received message R's header contains an In-Reply-To: <ol spacing="normal" type="1"><li>If a received message R's header contain
field, check to see if it s an In-Reply-To field, check to see if it
references a previous message that the MUA has sent or r references a previous message that the MUA has sent or r
eceived. </t> eceived. </li>
<li>If R's In-Reply-To: does reference one, then check R's message conte
<t>If R's In-Reply-To: does reference one, then check R's me nt for a part with
ssage content for a part with
a "reaction" Content-Disposition header field, at either the outermost level or as a "reaction" Content-Disposition header field, at either the outermost level or as
part of a multipart at the outermost level.</t> part of a multipart at the outermost level.</li>
<li>If such a part is found and the content of the part conforms to the
<t>If such a part is found, and the content of the part conf restrictions
orms to the restrictions outlined above, remove the part from the message and pro
outlined above, remove the part from the message and pro cess the part as a reaction. </li>
cess the part as a reaction. </t> </ol>
<aside><t>Note: A message's content might include other, nested messages
</list></t> . These can
<t><list style="hanging">
<t hangText="Note: ">A message's content might include othe
r, nested messages. These can
be analyzed for reactions, independently of the containi ng message, applying the above be analyzed for reactions, independently of the containi ng message, applying the above
algorithm for each contained message, separately.</t> algorithm for each contained message, separately.</t></a
</list></t> side>
<t>Again, the handling of a message that has been successfully processed i
<t>Again, the handling of a message that has been successfully proce s MUA specific and
ssed is MUA-specific and
beyond the scope of this specification.</t> beyond the scope of this specification.</t>
</section>
</section> <section>
<name>Usability Considerations</name>
<section title="Usability Considerations"> <t>This specification defines a mechanism for the structuring and carriage
<t>This specification defines a mechanism for the structuring and ca of information. It does
rriage of information. It does not define any user-level details of use. However, the design of
not define any user-level details of use. However the design of the user-level mechanisms
the user-level mechanisms
associated with this facility is paramount. This section discuss es some issues to associated with this facility is paramount. This section discuss es some issues to
consider.</t> consider.</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Creation: </dt>
<dd>Because an email environment is different from a typical social
<t hangText="Creation: ">Because an email environment is di
fferent from a typical social
media platform, there are significant -- and potentially challenging -- choices in the 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 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 sen t to all recipients? Should be sent only to the original author, or should it be sen t to all recipients? Should
the reaction always be sent in a discrete message contai ning only the reaction, or the reaction always be sent in a discrete message contai ning only the reaction, or
should the user also be able to include other message co ntent? (Note that carriage of should the user also be able to include other message co ntent? (Note that carriage of
the reaction in a normal email message enables inclusion the reaction in a normal email message enables inclusion
of this other content.)</t> of this other content.)</dd>
<dt>Display: </dt>
<t hangText="Display: ">Reaction indications might be more <dd>Reaction indications might be more useful when displayed in close
useful when displayed in close
visual proximity to the original message, rather than me rely as part of an email visual proximity to the original message, rather than me rely as part of an email
response thread. The handling of multiple reactions, fro response thread.
m the same person, is also an The handling of
opportunity for possibly interesting user experience des multiple reactions, from the same person, is also an opp
ign choice.</t> ortunity
for making a user experience design choice that could be
<t hangText="Culture: ">The use of an image, intended to se interesting.</dd>
rve as a semantic signal, is <dt>Culture: </dt>
<dd>The use of an image, intended to serve as a semantic signal, is
determined and affected by cultural factors, which diffe r in complexity and nuance. It determined and affected by cultural factors, which diffe r in complexity and nuance. It
is important to remain aware that an author's intent whe n sending a particular emoji is important to remain aware that an author's intent whe n sending a particular emoji
might not match how the recipient interprets it. Even si mple, commonly used emojis can might not match how the recipient interprets it. Even si mple, commonly used emojis can
be be subject to these cultural differences.</t> be subject to these cultural differences.</dd>
</list></t> </dl>
<section>
<t/> <name>Example Message</name>
<t>A simple message exchange might be:</t>
<section title="Example Message"> <artwork><![CDATA[To: recipient@example.org
<t>A simple message exchange might be:<figure>
<artwork><![CDATA[To: recipient@example.com
From: author@example.com From: author@example.com
Date: Today, 29 February 2021 00:00:00 -800 Date: Today, 29 February 2021 00:00:00 -800
Message-id: 12345@example.com Message-ID: 12345@example.com
Subject: Meeting Subject: Meeting
Can we chat at 1pm pacific, today?]]></artwork> Can we chat at 1pm pacific, today?
</figure> with a thumbs-up, affirmative response of:<figure> ]]></artwork>
<artwork><![CDATA[To: author@example.com <t> with a thumbs-up, affirmative response of:</t>
<artwork><![CDATA[To: author@example.com
From: recipient@example.org From: recipient@example.org
Date: Today, 29 February 2021 00:00:10 -800 Date: Today, 29 February 2021 00:00:10 -800
Message-id: 56789@example.org Message-ID: 56789@example.org
In-Reply-To: 12345@example.com In-Reply-To: 12345@example.com
Subject: Meeting Subject: Meeting
Mime-Version: 1.0 (1.0) Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Content-Disposition: Reaction Content-Disposition: reaction
{U+1F44E}]]></artwork>
</figure> The Unicode character, represented here as "{U+1F4
4E}" for readability, would
actually be sent as the UTF-8-encoded 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">
<t>Repeating the caution that actual use of this capability requ
ires 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 li
st of messages :<list
style="hanging">
<t hangText="Summary: ">Summary listings of messages in
a folder include columns such
as Subject, From, and Date. Another might be added,
to show common reactions and a
count of how many of them have been received.</t>
<t hangText="Message: ">A complete message is often dis {U+1F44D}
played with a tailored section ]]></artwork>
for header-fields, enhancing the format and showing
only selected header fields. A
pseudo-field might be added, for reactions, again sh
owing the symbol and a
count.</t>
</list>
</t>
</section>
</section> <t> The Unicode character, represented here as "{U+1F44D}" for readabili
ty, would actually be sent as the UTF-8-encoded character.</t>
<t>The example could, of course, be more elaborate, such as the first of
a MIME multipart sequence.</t>
<section title="Security Considerations"> </section>
<t>This specification employs message content that is a strict subse <section>
t of existing possible <name>Example Display</name>
content, and thus introduces no new content-specific security co <t>Repeating the caution that actual use of this capability requires car
nsiderations. The fact that eful 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 li
st of 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 t
o show common reactions and a
count of how many of them have been received.</dd>
<dt>Message:</dt>
<dd>A complete message is often displayed with a tailored section
for header fields, enhancing the format and showing
only selected header fields. A
pseudo-field might be added for reactions, again sho
wing the symbol and a
count.</dd>
</dl>
</section>
</section>
<section>
<name>Security Considerations</name>
<t>This specification employs message content that is a strict subset of e
xisting possible
content and thus introduces no new content-specific security con
siderations. The fact that
this content is structured might seem to make it a new threat su rface, but there is no this content is structured might seem to make it a new threat su rface, but there is no
analysis demonstrating that it does.</t> analysis demonstrating that it does.</t>
<t>This specification defines a distinct Content-Disposition value for spe
<t>This specification defines a distinct Content-Disposition value, cialized message
for specialized message
content. Processing that handles the content differently from ot her content in the message content. Processing that handles the content differently from ot her content in the message
body might introduce vulnerabilities. Since this capability is l ikely to produce new user body might introduce vulnerabilities. Since this capability is l ikely to produce new user
interaction features, that might also produce new social enginee ring vulnerabilities.</t> interaction features, that might also produce new social enginee ring vulnerabilities.</t>
</section>
<section>
<name>IANA Considerations</name>
<t>IANA has registered the Reaction MIME Content-Disposition parameter, pe
r <xref target="RFC2183"/>.</t>
<dl newline="false" spacing="normal">
<dt>Content-Disposition parameter name:</dt>
<dd>reaction</dd>
<dt>Allowable values for this 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<
/dd>
</dl>
</section>
<section>
<name>Experimental Goals</name>
<t>The basic, email-specific mechanics for this capability are well establ
ished and
well understood. Points of concern, therefore, are: </t>
<ul spacing="normal">
<li>Technical issues in using emojis within a message body</li>
<li>Market interest</li>
<li>Usability</li>
</ul>
<t> So the questions to answer for this Experimental specification are:</t
>
<ul spacing="normal">
<li>Is there demonstrated interest by MUA developers?</li>
<li>If MUA developers add this capability, is it used by authors?</li>
<li>Does the presence of the Reaction capability create any operational
problems for
recipients?</li>
<li>Does the presence of the Reaction capability demonstrate additional
security
issues?</li>
<li>What specific changes to the specification are needed?</li>
<li>What other comments will aid in use of this mechanism?</li>
</ul>
<t>Please send comments to ietf-822@ietf.org.</t>
</section>
</middle>
<back>
</section> <displayreference target="RFC5234" to="ABNF"/>
<displayreference target="RFC5598" to="Mail-Arch"/>
<section title="IANA Considerations"> <displayreference target="RFC5322" to="Mail-Fmt"/>
<displayreference target="RFC2045" to="MIME"/>
<t>The IANA is requested to register the Reaction MIME Content-Dispo
sition parameter, per <xref
target="RFC2183"/><list style="hanging">
<t hangText=" Content-Disposition parameter name: ">reactio
n</t>
<t hangText="Allowable values for this parameter: ">(none)<
/t>
<t hangText=" Description: ">Permit a recipient to respond b
y signaling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smil
ey' graphic</t>
</list>
</t>
</section>
<section title="Experimental Goals">
<t>The basic, email-specific mechanics for this capability are well-
established and
well-understood. Points of concern, therefore, are: <list style=
"symbols">
<t>Technical issues in using emojis within a message body pa
rt</t>
<t>Market interest</t>
<t>Usability</t>
</list> So the questions to answer for this Experimental specifi
cation are:<list
style="symbols">
<t>Is there demonstrated interest by MUA developers?</t>
<t>If MUA developers add this capability, is it used by auth
ors?</t>
<t>Does the presence of the Reaction capability create any o
perational problems for
recipients?</t>
<t>Does the presence of the Reaction capability demonstrate
additional security
issues?</t>
<t>What specific changes to the specification are needed?</t
>
<t>What other comments will aid in use of this mechanism?</t
>
</list>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/i
nfo/rfc2119">
<front>
<title> Key words for use in RFCs to Indicate Requirement Le
vels </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 o
ften capitalized. This
document defines these words as they should be inter
preted in IETF documents. This
document specifies an Internet Best Current Practice
s for the Internet Community,
and requests discussion and suggestions for improvem
ents. </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 M
essages: 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" ro
le="editor">
<organization/>
</author>
<date year="1997" month="August"/>
<abstract>
<t> This memo provides a mechanism whereby messages conf
orming to the MIME
specifications [RFC 2045, RFC 2046, RFC 2047, RFC 20
48, RFC 2049] can convey
presentational information. It specifies the "Conten
t- Disposition" header field,
which is optional and valid for any MIME entity ("me
ssage" 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>
<!-- <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/f
ull-emoji-list.html"
/>
</reference>-->
<reference anchor="Emoji-Seq">
<front>
<title> Unicode® Technical Standard #51: Unicode Emoji</titl
e>
<author fullname="M. Davis" initials="M." role="editor" surn
ame="Davis">
<organization>Google, Inc.</organization>
</author>
<author fullname="P. Edberg" initials="P." role="editor" sur
name="Edberg.">
<organization>Apple, Inc</organization>
</author>
<date day="18" month="September" year="2020"/>
</front>
<seriesInfo name="WEB" value="http://www.unicode.org/reports/tr5
1/#def_emoji_sequence"/>
</reference>
<reference anchor="Mail-Fmt">
<front>
<title>Internet Message Format</title>
<author fullname="Peter W. Resnick" initials="P." role="edi
tor" 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="Bore
nstein">
<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 Thr
ee: 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 clarif
ying 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>
</references>
<!--<references title="Informative References"> <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"/>
</references>--> <reference anchor="Emoji-Seq" target="https://www.unicode.org/reports/tr5
1/#def_emoji_sequence">
<front>
<title> 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="Edbe
rg">
<organization>Apple, Inc</organization>
</author>
<date month="September" year="2020"/>
</front>
</reference>
<section title="Acknowledgements"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.
<t>This specification had substantive commentary on three IETF maili xml"/>
ng lists.</t> <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"/>
<t>This work began as a private exercise, in July 2020, with private </references>
discussion, for <section numbered="false">
draft-crocker-reply-emoji. It morphed into draft-crocker-inreply <name>Acknowledgements</name>
-react, with significant <t>This specification had substantive commentary on three IETF mailing lis
discussion on the ietf-822 mailing list, September through Novem ts.</t>
ber 2020. The discussion <t>This work began as a private exercise, in July 2020, with private discu
ssion, for draft-crocker-reply-emoji. It morphed into draft-crocker-inreply-reac
t, with significant discussion on the ietf-822 mailing 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 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 Content-Disposition type, as well as significantly enhancing its text concerning Unicode. It
also produced two additional co-authors.</t> also produced two additional coauthors.</t>
<t>In November 2020, the Dispatch mailing list <eref target="https://www.i
<t>In November 2020, the Dispatch list was queried about the draft, etf.org/mailman/listinfo/dispatch" brackets="angle"/> was queried about the draf
but produced no discussion, t, but it produced no discussion,
though it did garner one statement of interest.</t> though it did garner one statement of interest.</t>
<t>A 4-week Last Call was issued on this document, January 2021, resulting
<t>A 4-week Last Call was issued on the document, January 2021, resu in quite a bit of fresh
lting in quite a bit of fresh discussion on the last-call mailing list <eref target="https://w
discussion on the last-call mailing list, and producing further ww.ietf.org/mailman/listinfo/last-call" brackets="angle"/> and producing further
changes to the draft. After changes to this document. After
Last Call completed, additional concerns were surfaced, about th Last Call completed, additional concerns regarding the Unicode-r
e Unicode-related details, elated details surfaced, producing yet more changes to the document. It also pro
producing yet more changes to the draft. It also produced a chal duced a challenge that prompted the
lenge that prompted the current version of this Acknowledgements section.</t>
current version of the Acknowledgements section.</t> <t>Readers who are interested in the details of the document's history are
encouraged to peruse the
<t>Readers who are interested in the detail of the document's histor archives for the three lists, searching Subject fields for "reac
y are encouraged to peruse the t".</t>
archives for the three lists, searching Subject fields for "-rea </section>
ct".</t> </back>
</section>
</back>
</rfc> </rfc>
 End of changes. 48 change blocks. 
607 lines changed or deleted 361 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/