Reaction: Indicating Summary Reaction to a Message
draft-crocker-inreply-react-14

[Ballot comment]
Thanks for addressing my previous comments.

During post-last-call discussion, concerns were raised regarding appropriate recognition for contributors in the Acknowledgements section of this document.  I conducted a searching review of this topic while preparing these comments, including seeking the advice of IETF counsel, and I thank the interested parties for their patience as I did my research.

Although it has been suggested that BCP 78 (Section 5.6) and BCP 9 (Section 10.3.1) are instructive about what should be included in Acknowledgements, IETF oral tradition grants authors and editors wide latitude in this regard.  Also, notably, while BCP 9 is fairly limited in terms of what it says needs to go into Acknowledgements (mainly “major contributors”), BCP 78, which formally updates BCP 9, is markedly more liberal on this point.  Collectively, this naturally means there is no clear answer.

In its response to an appeal in 2013, the IESG declined to intervene in a similar case, deferring instead to the discretion of the document author.  The disposition of that appeal, as is the case here, appears to pivot on the author’s discretion with respect to whether the contribution was “major”.

On review, it is my personal opinion that certain text at the end of the current document’s Sections 3 and 5 was the synthesis of some of that discussion.  I do not, however, have an opinion as to whether these contributions qualify as “major”.  While I have urged, and with these comments do so again, that this discretion be reconsidered given the broad intent of BCP 78 and the typical (but less formal) guidance to be comprehensive and transparent with acknowledgements, I decline to obstruct progress of this document on that basis at this point in its life cycle.

Though not a formal appeal, this is now the second time this question has been raised to the level of the IESG for consideration.  As such, I suggest that the issue may be ripe for the community to discuss and contemplate more firm guidelines in this space.  For an organization already concerned with attrition and attracting newer participants, and with the very real risk of rather contentious formal proceedings, this is an area in which I believe we would do well to reach stronger consensus.

[Ballot comment]
Though this is not the reason for my abstention, the IANA
Considerations section remains inconsistent with the structure
of the registry in which it is requesting allocation.

[Ballot comment]
The IANA Considerations section registers a content disposition of "React", but everywhere else in the document it's "Reaction".  Please make it consistent by converging on one of them.  (Basically this translates as "I support Ben's DISCUSS".)

I also note, as Benjamin did, that the capitalized "R" is curiously different from all other registered ones.  Any particular reason for that?

[Ballot comment]
There are still some issues that I'm trying to get aired on the last-call list, mostly related to limiting the set of allowed emoji characters.  I'm leaving this at the non-blocking comment level now.

[Ballot comment]
I must admit that I really don't like the base idea. Emoji's annoy me, and I'd much rather that people reply to messages with a written reply instead of some hard to interpret picture of a upside down hose eating a banana.... but, I'll fully acknowledge that all the cool kids are doing it, and I'm clearly old and curmudgeonly.

Luckily, my opinions on if emojis and thumbs up are not actually important here -- the proposed solution seem to work, and so while I personally hope that this never catches on, I'm balloting No Objection (with a side-order of soapbox opining... )

[Ballot comment]
I have to say that I am a bit worried about two things with this specification. They are both in some sense raised.

The first is the user aspects of knowing who the response is going to. Is this being sent to just the sender or all recipients. And are the reaction bundled with a reply or sent separately?

Secondly, is the operational aspect of reactions going to all recipients and mailing lists. This appears that it can cause a lot of messages and especially for the people that don't have a MUA that support this will gets a lot of bewildering emails.

[Ballot comment]
The IANA Considerations section registers a content disposition of "React", but everywhere else in the document it's "Reaction".  Please make it consistent by converging on one of them.

I also note, as Benjamin did, that the capitalized "R" is curiously different from all other registered ones.  Any particular reason for that?

[Ballot discuss]
I thought you were going to clean up whether the Content-Disposition was
"React" or "Reaction" based on the gen-art review, but the document still seems
internally inconsistent about it.
https://mailarchive.ietf.org/arch/msg/gen-art/zun860KMrKdwqyKSWbrvWSPMuYM/
indicates that "React" was the intent, but Sections 2 and 4.1 still use
"Reaction", while the IANA Considerations register "React".  Section 3
uses lowercase "reaction" in the context of a "Content-Disposition"
header field as well.  Section 7 mentions a "Reaction capability".

[Ballot comment]
  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.  [Mail-Fmt].  For
  processing details, see Section 3.

I don't think I understand what "for the message in which they both are
present" is intended to mean (specifically "for the message").  My best guess
is that "when both 'Content-Disposition: Reaction' and 'In-Reply-To:' are
present in a message, these are the semantics; if 'Content-Disposition:
Reaction' is present without 'In-Reply-To:', the semantics are undefined".

Section 5

Given the difficulty of conclusively proving a negative, the value of
stating "there is no analysis demonstrating it does" seems minimal.

  This specification defines a distinct Content-Disposition value, for
  specialized message content.  Processing that handles the content
  differently from other content in the message body might introduce
  vulnerabilities.

The potential for new implementation vulnerabilities when new code is
added for the specialized processing seems clear; it seems there may
also be human-factor vulnerabilities depending on how the information is
displayed, which may be less obvious to some readers and thus worth a
dedicated mention.

Section 6

  The IANA is request to register the React MIME Content-Disposition
  parameter, per [RFC2183]

    Content-Disposition parameter name:    React

  Allowable values for this parameter:    (none)

At https://www.iana.org/assignments/cont-disp/cont-disp.xhtml I see
distinct registries for "Content Disposition Values" and "Content
Disposition Parameters".
It notably does not have any columns relating what parameters are
allowed for use with a given value.

My undersatnding is that "React" is intended to be a "content
disposition value" and that no changes to the "content disposition
parameters" registry is to be made (and thus that the last quoted line
serves no purpose for IANA).  Some prose discussion, separate from the
registration, that no parameters are used with the content-disposition
value, would of course be welcome.

I also note that all of the existing entries in the "content disposition
values" registry are written in all lowercase form, but "React" contains
the majuscule 'R'.

[Ballot discuss]
There were Internationalization issues raised by John Klensin and Patrik Fältström that need to bbe addressed, and I haven’t seen a response to them yet.  The primary one involves cross-cultural understanding of the meaning of emoji symbols, and, thus, weather it makes sense to use the emoji symbols themselves as protocol elements, rather than defining specific protocol elements and letting the implementation select emoji based on regional/cultural custom.

[Ballot comment]
Interesting idea and easy to read document.

May I assume that the choice of a non-existing day in the example (29th of February in 2021 :) ) is on purpose ?

Perhaps a nits in section 4.1, should there be a space character after ':' in "In-Reply-To:12345@example.com" ?

Another nit, while I do appreciate Barry Leiba (and this is the last document from Barry that I am reviewing), is it necessary to list him twice in the acknowledgement section ?

Regards

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-crocker-inreply-react-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Content Disposition Parameters registry on the Content Disposition Values and Parameters registry page located at:

https://www.iana.org/assignments/cont-disp/

a single, new parameter is to be registered as follows:

Name: Reaction
Description: Permit a recipient to respond by signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-12):

From: The IESG
To: IETF-Announce
CC: barryleiba@gmail.com, draft-crocker-inreply-react@ietf.org, todd.herr@valimail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (React: Indicating Summary Reaction to a Message) to Experimental RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'React: Indicating Summary Reaction to a Message'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-crocker-inreply-react/



No IPR declarations have been submitted directly on this I-D.

Summary
The document shepherd is Todd Herr. The responsible Area Director is Barry Leiba.

This document defines a facility for the reader of an Internet Mail message to provide a summary reaction to the message in a form similar to that used for social media. More specifically, it proposes a new MIME Content-Disposition, to be used in conjunction with the In-Reply-To field, to indicate that a part of a message containing one or more emojis be treated as a summary reaction to the previous message.

Review and Consensus
Implementation of the new Content-Disposition is straightforward for MTAs. The document rightly declares details for handling it to be specific to each MUA and therefore beyond the scope of this specification. Discussion of the document took place on the ietf-822 mailing list in the autumn of 2020, and was limited to a handful of threads, each initiated by the publication of a new version of the document. There was no difficulty in coming to consensus.

Intellectual Property
The authors have confirmed conformance with BCP 78/79. There are no IPR disclosures in the document.

Other Points
There are normative references to the following documents:
RFC 5234, “Augmented BNF for Syntax Specifications”
Unicode(R) Technical Standard #51, “Unicode Emoji”
RFC 5598, “Internet Mail Architecture”
RFC 5322, “Internet Message Format”
RFC 2045, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”
RFC 2119 (a.k.a., BCP 14), “Key words for use in RFCs to Indicate Requirement Levels”
RFC 2183, “Communicating Presentation Information in Internet Messages”