Subject: [ietf-822] Review of and suggested changes for draft-crocker-inreply-react-01.txt

From: Ned Freed <[email-masked]>
Date: Wed, 21 Oct 2020 06:43:14 -0700 (PDT)

One of the interesting things about the Internet standards process is how
often a particular implementation creates the architectural model, rather than
the other way around.

This specification is a case in point. It starts by offering three key
insights:

(1) It's possible to tease the design of a generic "reaction" facility out
    of various social media systems.
    
(2) Restricting the system to emoji, or a even subset of emoji, is essential
    to the viability of the facility.
    
(3) Given (1) and (2), it's possible to add a reaction capability to existing
    messaging systems, even one as well established as email.

All of these insights seem obvious in hindsight, but I for one have never
really thought about them, or about extending email in this way. As such, I
applaud Dave for coming up with this proposal.

However, like so many previous proposals, the specification now shifts rather
abruptly to implementation specifics, using an approach based on existing
header-based mechanisms like X-Face. And this is where things start to get a
little iffy.

First of all, I think there's at least one more key insight that we need to
pull out of existing reaction facilities: In many if not most cases they
operate independently of reply messages. Indeed, this is what makes them so
attractive: As a user I can offer an opinion of something without having to
write anything. I just click on a button, up comes a panel of emoji, I make a
selection, done. (Yes, I realize this is a UI detail, and we don't do UIs,
but it's such an important capability that it warrants our attention.)

And this isn't simply a matter of being lazy - although the virtues of
laziness often fail to be appreciated. The separation of reactions from
replies makes it possible to implement very different sorts of workflows.
The obvious example is voting - most reaction interfaces provide the
tally you need of user reactions automatically, whereas with replies the
tally has to be done manually - exactly the sort of things computers are
supposed to do for us.

Second, as everyone knows, I am one of the authors of MIME, and one of the
key elements of MIME was backwards compatibility with non-MIME systems. I
firmly believe this is one of the things that made MIME succesful, so it's
something I worry about in every new proposal that comes along.

Returning to the current document, I believe the proposed implementation
doesn't adequately address either of these points, and that there are
alternatives that do.

In particular, the current proposal creates a reaction mechanism that's
independent of replies but then requires that a reply be sent in order to
send a reaction. This linkage makes it very awkward to use the mechanism
for things like voting - having a long list of meaningless replies show up
as part of a vote is definitely not a Good Thing.

Of course it's possible to define a semantic where, say, an empty message body
in conjunction with a reaction header, would be silently ignored. But this
brings us to the second point: Backwards compatibility. If this proposal starts
to deploy it will be into a world where no client is aware of the meaning of
this new reaction header field. Now consider what this will look like in an
unextended client: A bunch of empty replies. Definitely Not Good.

Other alternatives fare no better: Clients won't know what to do with a
"ignore" content-disposition, and will ignore it rather than the message.
Ditto for a text/ignore content type.

But there is one thing that does work, which is put the reaction in the
message body. This way clients that don't implement the reaction facility will 
display something, and it's actually pretty sensible.

Putting the reaction in the message body solves an even bigger backwards
compatibility problem: The least astonishment principle violation that occurs
when the participants in a discussion with upgraded clients see a bunch of
reactions but those without upgraded clients see nothing at all.

The current document does provide the option to do this: It says clients
MAY include a copy of the reaction in the message body. But making this
optional leads to even more unpredictability.

But if we always put the reaction in the message body, the header field is now
superfluous. So let's proceed on the assumption that the reaction will be
in the message body - and only in the message body - and see how far we get.

MIME provides us with multipart messages, so the obvious thing to do is
put the reaction in its own part. This however, brings us face to face
with our first real problem: How do we combine a reaction with a reply? If
the reply is text/plain then there's a simple solution: Use multipart/mixed
containing the two parts. (Tests show this actually works pretty well.)

What if the reply is text/html? multipart/alternative? multipart/related?
If past experience with client MIME support is any indication, complex
nested MIME structures are best avoided. But in this case we have a
simple alternative: Combine if you can, but if you can't send two
messages!

So now the rule would be for conforming clients to look for a
reaction part and process it as such. Processing terminates if the
message consists solely of that part. If not, process the remainder as
a reply.

The next issue is really more of a detail: How do we label a part as a
reaction? One way to do it is to define a new Content- field,
say Content-Reaction. This is pretty much guaranteed to work. But it would
be nice if we could do this using existing Content- fields. And we have
at least two of those: Content-type and Content-Disposition.

A text/reaction media type makes quite a bit of sense - we are, after all,
restricting the repertoire to emoji, so this isn't really text/plain. And
there are other media types, e.g., multipart/related, that exist solely to
invoke specialized client handling. Finally, RFC 2045 section 4.1.4
quite specifically states that unknown subtypes of text should be handled
as text/plain, providing the necessary fallback behavior.

Unfortunately a bit of testing shows that section 4.1.4 has apparently been
ignored by at least two major mail service providers - they both treat
text/reaction as application/octet-stream. (Bad Google. Bad Microsoft.
Bad.)

I guess we could stand on principle that this is clearly a standards violation
and proceed with the media type, but why fight a fight we are almost certain
to lose when there are viable alternatives?

So how about a reaction content-disposition? This seems to work well -
unknown content-dispositions look like they are ignored. (Or maybe nobody
is currently paying attention to disposition information, which is also
fine for our purposes.)

My suggestion, then, is to switch from a header field to a MIME part
with a content-disposition of "reaction"", a content-type of text/plain,
UTF-8 charset, and contents restricted to emoji. Combine the reaction with
a reply if you can, if can't send it as a separate message.

The current document is pleasantly short, so it's possible for me to
suggest a set of changes to implement this suggestion:

OLD:

   This facility defines a header field, to be used in junction with the
   In-Reply-To header field, to link one or more emojis as a summary
   reaction to a previous message.

NEW:

   This facility defines a new 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 be treated as a summary reaction to a
   previous message.

OLD:

2.  In-Reply-React

   A message sent as a reply MAY indicate the responder's summary
   reaction to the original message by including an In-Reply-React
   header field:
   
   The [ABNF] for the header field is:

in-reply-react = "In-Reply-React:" emoji *(lwsp emoji) CRLF

emoji = emoji_sequence
emoji_sequence = { defined in [Emoji-Seq] }

base-emojis = thumbs-up / thumbs-down / grinning-face / frowning-face /
crying-face

thumbs-up = {U+1F44D}
thumbs-down = {U+1F44E}
grinning-face = {U+1F600}
frowning-face = {U+2639}
crying-face = {U+1F622}

NEW:

2.  The reaction content-disposition

   A message sent as a reply MAY include a part containing a
   content-disposition field with the value "reaction". If such a field
   is specified the content-type of the part MUST be:
   
     Content-type: text/plain; charset=utf-8
   
   The content of this part is restricted to single line of emoji:
   
   part-content = emoji *(lwsp emoji) CRLF

   emoji = emoji_sequence
   emoji_sequence = { defined in [Emoji-Seq] }

DELETE:

   Fully interoperable email uses 7-bit ASCII, although some email
   handling paths directly support 8-bit data.  Emoji characters are
   drawn from the space outside of 7-bit ASCII.  For email handling
   paths that are 8-bit clean, the an emoji character does not need
   special encoding.  If the path from author to recipients is not known
   to be 8-bit clean, The emoji character SHOULD be encoded using
   [MIME-Enc].

(I don't think an explanation of body part encoding is necessary or
useful.)

OLD:

   For recipient MUAs that do not support this mechanism, the header
   field might not be displayed to the recipient.  To ensure that the
   reaction is presented to the recipient, the responding MUA MAY
   automatically include a second copy of the header field in the
   message body.  This might be as the first line of the body or as the
   first mime-part.  [MIME] By making the text be the full header field,
   it also allows MUAs that do support the mechanism to identify this
   redundant information and possibly remove it from display.

NEW:

   Recipient MUAs that support this mechanism operate as follows:
   
   (0) If an In-Reply-To field is present check to see if it references
       a previous message the MUA has received. 

   (1) If a reference to an existing message is found check for a part with
       a "reaction" content-disposition at either the outermost level or as
       part of a multipart at the outermost level.

   (2) If such a part is found, and the content of the part conforms to the
       restrictions outlined above, remove the part from the message and
       process it as a reaction. (The exact details of reaction processing are
       necessarily MUA-specific and beyond the scope of this specification.)
       
   (3) Processing terminates if no parts remain in the message. (Again, the
       handling of a message that has been successfully processed is
       MUA-specific and beyond the scope of this specification.) If parts
       remain process the remaining message content as a reply.

OLD:

4.  Security Considerations

   This specification defines a distinct location for specialized
   message content.  Processing that handles the content differently
   from content in the message body might introduce vulnerabilities.
   However the mere definition or use of this mechanism does not create
   new vulnerabilities.
 
NEW:

4.  Security Considerations

   This specification employs message content that is a strict subset
   of existing content, and thus introduces no new content-specific
   security considerations.

   This specification defines a distinct label for specialized
   message content.  Processing that handles the content differently
   from other content in the message body might introduce vulnerabilities.

OLD:

5.  IANA Considerations

   Add to "Permanent Message Header Field Registry":

      Header field name:    In-Reply-React

      Applicable protocol:    Mail (RFC 2822)

      Status:     Experimental

      Author/Change controller:    IETF

      Specification document(s):   This specification.

      Related information:    None

NEW:

5.  IANA Considerations

 New Content-Disposition Parameter Registrations

   This document specifies a new "reaction" content disposition and its
   handling that should be added to the IANA registry.
 
TBD:

In order for different clients to interoperate in their handling of
reactions, regardless of the mechanism used this document should
probably include a specification of how to store reactions using
IMAP annotations.

I think that's more than enough for now.

                                Ned

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 21 Oct 2020 16:43:00 -0500

+1 mostly.  Or should I say, 👍.   As usual your analysis is excellent.

But you say that a MIME part with “Content-Disposition: reaction” should have its contents restricted to UTF-8 emoji.  Most likely some implementors will ignore that and include additional UTF-8 text, or worse, pictures or video.  How should a conformant implementation handle that?  It seems like this creates an excellent opportunity for bad implementations to help people send content that might never be displayed to the recipient.  Although it will be the fault of the sending implementation, the consequences will be experienced by the readers more than the senders, so it could be hard to even notice, let alone get fixed.

I’m not sure we should dismiss out of hand the “text/reaction” idea.  Conformant implementations will treat it as a reaction — a new thing.   What does it really matter whether nonconformant implementations treat it as text/plain or application/octet-stream?  Either way, it won’t have any special automatic reaction processing, and it will make the content available to the user either as readable text or an attachment that the user is at least told exists.  Sure, application/octet-stream is the wrong choice, but it’s no more wrong than it has been all along for unrecognized text subtypes.  In fact, if this gives us a reaction mechanism that works for everything but Microsoft and Google, it might actually spur those companies to start doing the right thing with unrecognized text subtypes in general.  (OK, I wouldn’t bet the farm on that, but you never know.)

These are just my reactions, I’m not yet sure what I think is the right answer.  — Nathaniel

> On Oct 21, 2020, at 8:43 AM, Ned Freed <[email-masked]> wrote:
> 
> _______________________________________________
> ietf-822 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-822

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Thu, 22 Oct 2020 05:18:32 -0400

On Wed, 21 Oct 2020 16:43:00 -0500, Nathaniel Borenstein said:
> But you say that a MIME part with “Content-Disposition: reaction” should have
> its contents restricted to UTF-8 emoji.  Most likely some implementors will
> ignore that and include additional UTF-8 text, or worse, pictures or video.

I have to admit that the number of times I've wanted to reply to an email with
just an emoji is outweighed by the number of times that Nope Badger is the
appropriate response.  I haven't checked if there's an Egads! emoji defined...

(On the other hand, a text/reaction and a text/plain response multipart/related
so I can give an emoji summary (suitable for one column of the display of the
recipient's inbox so they can tell the general tone without reading the note)
plus a more detailed response in text.... that I could use more of if there's traction)

I find Ned's analysis fairly compelling, but I'm reading it at 4AM and insufficient
caffeine.  But we certainly should chase down the implications of a text/reaction
type.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Oct 2020 06:33:55 -0700

> but it's such an important capability that it warrants our attention.)

(I'm responding, here, only to the above text, and not yet to the 
proposal that followed.)

In spite of the above text's latter comment on UI detail, it seems to 
confuse UI design with semantics.

Specifically: Triggering a reaction is, in fact, making a reply.

The UI means of doing that are, of course, quite different from typing a 
text reply, and the display of the reaction is handled quite 
differently.  That's possible because the reply is data-typed specially.

In a sense, this is on a par with distinguishing a message's being a 
reply, versus being standalone.  It's created somewhat differently and 
it (can be) displayed somewhat differently (linking it to previous 
messages), by virtue of attaching the In-Reply-To header field.  (Let's 
ignore the earlier, heuristic of matching Subject: text.)

These creation-side and display-side UI differences are hugely 
important, of course, but they don't alter the underlying, transactional 
nature of an affect-indication response, from a free-form text response.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Thu, 22 Oct 2020 06:06:55 -0700 (PDT)

> But you say that a MIME part with “Content-Disposition: reaction” should
> have its contents restricted to UTF-8 emoji.  Most likely some implementors
> will ignore that and include additional UTF-8 text, or worse, pictures or
> video.  How should a conformant implementation handle that?

I tried to make that clear, but I guess it didn't come through. My
sugggested approach is to treat any reaction part that doesn't conform
to the specification as if it doesn't have the reaction disposition.

This makes it difficult for a bad sender to cause trouble by creating silly
states, has reasonable fallback semantics, and allows for future extension.

> wIt seems like this creates an excellent opportunity for bad implementations to
> help people send content that might never be displayed to the recipient. 

Not if doing it immediately engages the fallback behavior of treating the
part as regular text.

> Although it will be the fault of the sending implementation, the consequences
> will be experienced by the readers more than the senders, so it could be hard
> to even notice, let alone get fixed.

> I’m not sure we should dismiss out of hand the “text/reaction” idea. 
> Conformant implementations will treat it as a reaction — a new thing.   What
> does it really matter whether nonconformant implementations treat it as
> text/plain or application/octet-stream?

I suggest you try it and see what happens with gmail.com and outlook.com - it
shows up as an ugly little attachment symbol, which people are unlikely to
bother clicking on. I do not regard this behavior as an acceptable fallback.

Content-disposition: reaction, OTOH, is displayed as text. It runs into
adjacent parts when used in a multipart/mixed. I really can't think of
better fallback behavior than this.

> Either way, it won’t have any special automatic reaction processing, and it
> will make the content available to the user either as readable text or an
> attachment that the user is at least told exists. 

I don't think they're told in a way where they are likely to bother
looking.

I also think this is probably a deliberate UI design choice. It's easy for bad
things to happen when people download and then click on random content. The
designers of thsee interfaces are caught between a hard conformace requirement
and a modern day security issue.

> Sure, application/octet-stream is the wrong choice, but it’s no more wrong
> than it has been all along for unrecognized text subtypes.  In fact, if this
> gives us a reaction mechanism that works for everything but Microsoft and
> Google, it might actually spur those companies to start doing the right thing
> with unrecognized text subtypes in general.  (OK, I wouldn’t bet the farm on
> that, but you never know.)

I'm not just concerned about Google and Microsoft. I've found in the past
that what they did is a good indication of what others have done.

FWIW, the MIME specification may be partly at fault here. The need to be able
to fall back to application/octet-stream so the data is at least accessible is
vital and is mentioned multiple times, including in the conformance document
RFC 2049.

But we didn't make the conformance criteria for unknown subtypes of text
nearly as clear. In RFC 2046 we said:

        Unrecognized subtypes of "text" should be treated as subtype "plain"
        as long as the MIME implementation knows how to handle the charset.
        Unrecognized subtypes which also specify an unrecognized charset
        should be treated as "application/octet- stream".

This is quite clear. But we didn't say the same thing in RFC 2049. Instead we
said:

         -- For unrecognized subtypes in a known character
            set, show or offer to show the user the "raw" version
            of the data after conversion of the content from
            canonical form to local form.

It can be argued that this criteria is met by fallback to
application/octet-stream. An oops on our part...

> These are just my reactions, I’m not yet sure what I think is the right

Thanks for the feedback.

				Ned