Subject: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-01.txt

From: Dave Crocker <[email-masked]>
Date: Tue, 6 Oct 2020 10:23:21 -0700

Note:

Diff:  https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-01

d/
-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-inreply-react-01.txt
Date: Tue, 06 Oct 2020 10:18:44 -0700
From: [email-masked]
To: Dave Crocker <[email-masked]>

A new version of I-D, draft-crocker-inreply-react-01.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:		draft-crocker-inreply-react
Revision:	01
Title:		React: Indicating Summary Reaction to a Message
Document date:	2020-10-06
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/id/draft-crocker-inreply-react-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-crocker-inreply-react/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-crocker-inreply-react
Htmlized:       https://tools.ietf.org/html/draft-crocker-inreply-react-01
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-01

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 indication.  This specification
    permits a similar facility for Internet Mail.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Tue, 6 Oct 2020 11:05:51 -0700

> Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-01

Besides the usual request for review of the new text, for refinement, 
I'll ask whether there is any additional work that folk think this 
documents needs.

Also, while I think it reasonable to publish this as Informational, I'm 
inclined to suggest Experimental, mostly as an implicit request for folk 
to try it.

d/

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2020 17:39:08 -0400

>I'll ask whether there is any additional work that folk think this 

OLD:

   Fully interoperable email uses 7-bit ASCII, although some email	
 	   handling paths directly support 8-bit ASCII.  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	
 	   [MIMEencode].

NEW:

     Emoji and any other code points outside the ASCII range MUST be encoded
     using [MIMEencode], unless the message is Internationalized [RFC6532].

The 8BITMIME SMTP extension is widely implemented but only enables 8
bit characters in message bodies. To allow UTF-8 in headers, it has to
be EAI which at this point, most mail is not. See RFCs 6530, 6531, and
6532.

Every MUA written in the past two decades knows how to handle
encoded-words so you don't lose anything by using them even if you
could get away with bare UTF-8.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 7 Oct 2020 07:44:23 -0700

>       using [MIMEencode], unless the message is Internationalized [RFC6532].

This thread is prompting a meta-thought. The thought is mostly driven by 
the need for simplicity, especially across multiple specifications. The 
specific directive applicable here is that normative redundancy is bad.

That is:

A specification which is only providing usage detail, within an 
established context, rather than providing new context rules, SHOULD NOT 
make additional normative declarations, within that context.  Normative 
language is needed only if the new specification is /changing/ that context.

Addition of normative declarations that merely replicate established 
normative declarations invites errors.

Consequently, I'll now suggest this wording, for this specification:

Fully interoperable email uses 7-bit ASCII, although some email handling 
paths directly support 8-bit ASCII.  Emoji characters are drawn from the 
space outside of 7-bit ASCII.  [IntHdr] covers data encoding for email 
header fields, along handling paths that are known to be 8-bit clean. 
[MIMEencode] covers encoding for paths that are not known to be 8-bit clean.

d/

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2020 15:53:44 -0400

>paths directly support 8-bit ASCII.

Um, what is 8-bit ASCII?  (I presume you don't mean IBM's failed USASCII8
on S/360.)  If you mean UTF-8, ...

>  Emoji characters are drawn from the 

Not really.  There is more to EAI than 8-bit clean.  That is, EAI mail
handling is 8-bit clean, but not everything that is 8-bit clean is EAI
or UTF-8.  For example, my qmail system has been 8-bit clean for 20 years
but I still needed to make a lot of changes for EAI and default UTF-8 to
work.  Without the UTF8SMTP indicator, mail systems can assume any random
encoding for non-ASCII bytes.

>[MIMEencode] covers encoding for paths that are not known to be 8-bit clean.

Well, sort of.  It covers encoding for 5322 compliant mail.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 7 Oct 2020 21:03:07 -0400

Overall impression: It's a useful facility, probably workable, could use 
some tweaks to the specification.   I appreciate the effort to keep this 
proposal simple.

Specific impressions and questions, in no particular order:

- I wonder if it makes sense to have a way for the subject message to 
provide a set of reaction choices recommended for use by a recipient in 
composing a reply.   Such a facility could be used, for example, by a 
mailing list to request specific responses,  or even for voting.  
Presumably a separate header field would be used in the subject message 
to specify choices, e.g.:

reply-react-choices = "Reply-React-Choices:" ("single" / "multiple") ";" 
lwsp react-choice *("," lwsp react-choice)

; single means: please choose up to one of these to include in an 
In-Reply-React response
; multiple means: multiple choices are acceptable (no more than one of 
any choice) in an In-Reply-React response

react-choice = { rfc2047 encoded-word no longer than 75 characters, 
using "utf-8" as charset and the "B" encoding }

One advantage of this might be an improvement in user interface for 
recipients composing replies, since recipients could choose from a small 
menu rather than being expected to input arbitrary characters.

While useful, voting would introduce additional security considerations 
such as lack of authentication, ease of forging votes on others' behalf, 
need to handle potential (deliberate or accidental) duplicate or 
conflicting votes.

Another way to look at it: if we were to add a voting facility to email 
messages, would it be better to combine it with In-Reply-React, or for 
the two to be separate?

- I might prefer it if the responses were not limited to emojis but 
could be arbitrary (short) text (say, no more than a single RFC2047 
encoded-word).    Part of my reason for this preference is that whenever 
I receive emoji in text or email, I often find myself wondering what it 
actually means.   On the other hand, a set of lengthy (in terms of 
screen space) choices might be more difficult to manage on handheld devices.

[One downside: a limitation of a single encoded-word would be unfair to 
some languages for which UTF-8 encodings are not as compact as others.]

- I think the service would work more reliably, and be more consistently 
implemented, if all responses were encoded using the UTF-8 charset and 
the "B" encoding.   In other words, the encoding of the In-Reply-React 
field should be consistent for all sending user agents.

- RFC2047 section 5 permits use of encoded-words only in certain 
portions of a message header.   I don't view this as a showstopper.   
Presumably a new header field can define whatever encoding it wants, 
including an encoding that's identical to one defined in RFC2047.   But 
some additional explanation might be in order to resolve an apparent 
conflict between this specification and RFC 2047 section 5.

- As for use of 2047 as the encoding, I have no strong opinion about 
this either way.  Clearly it's already established and widely 
implemented.   There may be MTAs and gateways in the wild that take the 
decode encoded-words any where they find them, and some that take the 
liberty of translating encoded-words to unencoded text.   I have heard 
from vendors of malware filters that decode 2047 encoded-words to look 
for malicious content (I have no idea what kinds of content they 
consider malicious).   I don't know whether the use of encoded-words in 
a new header field would trigger spam or malware filters.   etc.  
Overall, though, I suspect this proposal is Mostly Harmless.

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2020 22:11:10 -0400

>lwsp react-choice *("," lwsp react-choice)

I don't think it's a great idea to go down this particular rathole.

If you want to send people a multiple choice response form, the way to
do it these days to send a MIME HTML message body that contains a web
form. Reinventing this wheel doesn't seem very useful.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 7 Oct 2020 22:39:32 -0400

On 10/7/20 10:11 PM, John Levine wrote:

> form.

Fair point.   And 1990s-style web forms will already work with most 
existing MUAs.

(Though such web forms aren't easily added to subject messages by 
mailing lists.)

---

From: "Ricardo Signes" <[email-masked]>
Date: Thu, 08 Oct 2020 08:19:03 -0400

> Diff:  https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-01

A coworker and I had -just- been discussing a nearly identical idea.  I mentioned it to Bron, who mentioned this draft to me.

I just had two things I thought might be worth chiming in on:

First:  This one is a bit tedious, but since I was going to post here anyway:  the definition of emoji should refer to emoji characters *and sequences*, lest it omit lots of non-single-character emoji.  (Even the humble red heart is more than one character.)

The other thought was about the question of what goes in the body.  Specifically, we discussed a means to distinguish "Look, I just want to send 👍🏽 and nothing else" from "I would like to write a treatise on the ways in which I agree, but if you are not prepared to bask in the glory of my prose, I guess you can summarize it as 👍🏽".  This would allow (for example) a means to count up reactions of a type, even when there's content, and would also allow user agents to avoid drawing whole messages when the content was trivial.  Something like "Header-Contains-Whole-Message: yes" would sum that up, meaning "reaction if provided, otherwise subject".  It's out of scope for this draft as written, but I think multiplies the draft's value.

-- 
rjbs

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Oct 2020 11:13:08 -0700

(this is an open note, not directed at anyone in particular.)

<rant>

The draft specifies a simple header field, to be added to a regular 
email  message.

There have been a number of suggestions looking to make enhancements to 
this basic model.

Thee suggestions are all predicated on reasonable thoughts, but they 
wind up altering the nature of the basic proposal.

They create basic limitations to extensibility or usability, such as by 
not having this be a regular email message.  Or they start the slide 
down a slope of complexity by what really is the start of an effort to 
replicate functions that are likely to be useful -- or already are -- 
but which are separate from signalling a reaction.

The basic proposal is intentionally simplistic and incremental.  Just 
add a place for signaling a reaction.

Everything else about the message is left unspecified because... it's a 
regular email message.  Add or don't add whatever would be in a regular 
email message.

A regular email message might or might not have a Subject line.  It 
might or might not have a body.  The body might or might not be complex, 
such as including an entire survey form.  It's regular email.

</rant>

<plea>

What will make the basic mechanism useful to its specific goal, 
sufficient as a specification, reasonable to implement, and as simple as 
possible without defeating its other goals?

</plea>

d/

ps. besides the encoding issue, which certainly satisfies the plea, 
another one in the works modifies the emoji details a bit.  A useful 
bit.  But only a bit.

---

From: "Ricardo Signes" <[email-masked]>
Date: Thu, 08 Oct 2020 21:35:44 -0400

> possible without defeating its other goals?

Here's one thing:

The Unicode Emoji List is revised more or less annually.  This means that releasing software that validates this header against the contents of UTS #51 is liable to fall out of date.

A problem closely analogous to this one, and seen in the real world:  an email with an IDN is in transit and some system attempts to decode the IDN, finds that it contains unallocated code points, and takes some sort of negative action… but the code points -are- allocated, but were not allocated at time time of the program's construction.

So:  what is the implementation to do when confronted with a valid encoded-word?  If the implementation was built on Unicode 12 and encounters the sequence { White Flag, ZWJ, Transgender Symbol } it will be unable to validate that sequence as an emoji-forming sequence.

The problem here is that some implementors like to validate data at layers were its validity is (probably) irrelevant to its intended use.  Maybe this warrants a note for implementors, and maybe not, but it seemed worth raising the point.

-- 
rjbs

---

From: Brandon Long <[email-masked]>
Date: Thu, 8 Oct 2020 23:58:49 -0700

> possible without defeating its other goals?

If I understood your original point of this spec, it was seeing that
various other tools have such a reaction
mechanism, and the logical plan of bringing that to Email.

Would it be useful to see what those other tools do to make sure we aren't
leaving anything obvious out?

FB has their limited reactions, but it's just adding one, seems compatible
with the draft.  There is alt text, but
presumably clients can handle that and there's some obvious handling of alt
text for emojis and it's all on the
client side, no need for anything in the spec.  I don't think limiting the
selection of reactions is worthwhile.

Twitter/Instagram only have a single reaction, ditto on not thinking that's
worthwhile.

iMessage I haven't used, but I think it's just adding a limited reaction...
there is a translation for regular
sms as backward compatibility.  For email, that would require a whole bunch
of work that's probably not worth
it... though if you think about someone receiving an email message that had
nothing in it and if their client didn't
support this, it would seem like a weird blank email ... so perhaps instead
of an empty message, an
implementation should include fallback support in some way in the body of
the message.  The spec could
contain such suggestions, or it could not and just leave that to various
implementations to handle themselves.
No opinion on that.

Some systems have stickers or gifs, some systems (discord, slack) allow you
to add community specific
reactions.  This could be handled with some of the url or data formats that
were brought up earlier.  Part of
me likes the extensibility of that proposal, and part likes the simplicity
of just emojis.  Of course, these can always
be put in the body of the message as well.  The stickers/gifs are usually
done in a way that would be compatible with
the body of the message.  The community reactions are usually handled like
regular emoji reactions, however.

Emoji's do update frequently, so we could consider some sort of fallback
support... but it seems like most uses I've seen
just fail to properly show the emoji and show an "unknown" character
instead... so adding a fallback system is probably overkill.

So, I don't have extensive usage of these other systems or ones beyond
these, but the simple spec seems to satisfy
the majority of the examples.  Hopefully others will speak up if other
systems do more than this.

Brandon

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Oct 2020 18:24:33 -0700

> systems do more than this.

Thanks for the review of existing practice.  It's good to have something 
like that in the list archive and even better to have it discussed.

There are a number of directions extensibility could take, here.  Each 
one will have some appeal. Maybe a lot.

The danger in any exercise like this is trying to guess which 
capabilities are best to include or -- much worse -- trying to include 
all of them -- or at least, someone's guess at what all of them are 
(is?)  Possibly demonstrating a bit of cultural bias, on my part, I tend 
to call that the OSI approach...

However there is quite a bit of history suggesting that it is best to 
start with something that is distinctly simple -- and even simplistic -- 
at first, to make it easy to develop and deploy, getting basic field 
experience.  Typically, that means starting with the smallest capability 
that is deemed useful.

Best of all is to start with something that is already established, 
while leaving room for /future/ extensions, based on actual demand. For 
the current draft, I tossed in a simple, non-normative rule with a set 
of emojis that already have an established base of experience.

If this gets deployed and used, and there is a community outcry -- or at 
least a polite, cohesive request -- for one particular kind of 
enhancement or another, that enhancement is likely to be easy.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Oct 2020 05:07:18 -0700

On 10/8/2020 6:35 PM, Ricardo Signes wrote:
> The Unicode Emoji List is revised more or less annually.  This means 
> that releasing software that validates this header against the contents 
> of UTS #51 is liable to fall out of date.

The RFC series come with an up-pointer reference mechanism for 
replacement versions.  It appears that The Unicode Consortium does not. 
I'd guess the best we can do is to have some generic language associated 
with the reference that says "or a successor".

> ...some system attempts to decode the
> IDN, finds that it contains unallocated code points

How about:

    Reference to unallocated code points SHOULD NOT be treated as an 
error; the associated bytes SHOULD be presented in numeric form.

or some such?

d/

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sun, 11 Oct 2020 20:49:39 -0400

> with the reference that says "or a successor".

Yeah, that's probably the "least worst" way to solve that problem.

> error; the associated bytes SHOULD be presented in numeric form.

"associated bytes SHOULD be presented with the system default method
for denoting an unallocated or undisplayable code point"

Pretty much everything on my laptop uses an empty rectangular box to display
a character that's not available in the current font or other similar issues. And
yes, "allocated but not available" code points *will* happen if your font doesn't
have the pixels  needed...

Plus, "numeric" is a poor choice.  We should specify  "U+hexbytes" if we're going
that route. Otherwise some bozo UI person is going to make it output 15712188
instead of U+EFBFBC

"system default method or U+ format" probably covers all the reasonable
bases.

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2020 22:44:30 -0400

In article <[email-masked]> you write:
>The Unicode Emoji List is revised more or less annually.  This means that releasing software that validates this header against the
>contents of UTS #51 is liable to fall out of date.

The entire Unicode standard is revised more or less annually This year
Unicode 13 added over 5000 characters to Unicode 12. If you send a new
emoji or any of those other 5000 characters you run the risk that
someone with last year's software will see a little box. That's life.

>The problem here is that some implementors like to validate data at layers were its validity is (probably) irrelevant to its intended
>use.

"Don't do that".

If they haven't already figured out that it's a fool's errand to
validate Unicode beyond broad rules like don't allow surrogates in
UTF-8, they're not going to figure it out for this tiny hack.

---

From: "Ricardo Signes" <[email-masked]>
Date: Sun, 11 Oct 2020 23:49:33 -0400

On Sun, Oct 11, 2020, at 10:44 PM, John Levine wrote:
> >The problem here is that some implementors like to validate data at layers were its validity is (probably) irrelevant to its intended use.
> 
> "Don't do that".

Right.  And my email said:
> Maybe this warrants a note for implementors, and maybe not, but it seemed worth raising the point.

So:  "Is it worth including «Don't do that.» in this spec?"

> UTF-8, they're not going to figure it out for this tiny hack.

I believe this says "It is not worth including that."

-- 
rjbs

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Oct 2020 06:33:45 -0700

> for denoting an unallocated or undisplayable code point"

Yeah.  That works.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Oct 2020 06:37:56 -0700

> I believe this says "It is not worth including that."

This thread seems to be about a concern that an implementor will not 
know how to properly deal with Unicode.  No doubt that's a valid issue, 
but this specification isn't the place to fix this.  Unicode is a 
discrete (and complex) topic.

Basic tutorials or cautions about it don't belong in a specification 
like this.

If there is a statement to include, it should be a very general, 
non-normative pointer to background information about Unicode or Unicode 
technical issues.

d/

---

From: "John Levine" <[email-masked]>
Date: 13 Oct 2020 13:20:42 -0400

>discrete (and complex) topic.

Quite right. Ever since MIME was invented 30 years ago it's been
possible to send mail that includes text with code points that aren't
valid in their putative encoding. I am having trouble understanding
why anyone thinks we this is a problem we should try to solve now for
this tiny application.

>non-normative pointer to background information about Unicode or Unicode 

Naah.  Let's leave the worms in the can for once.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 22 Oct 2020 12:16:56 -0400

On 10/8/2020 2:13 PM, Dave Crocker wrote:
> sufficient as a specification, reasonable to implement, and as simple
> as possible without defeating its other goals?
>
> </plea>

There would be many implementation and design questions.   First 
thought to mind, email has too much RFC5322 creation and reply 
overhead for simplistic, small footprint "dynamic notification" 
reaction reply concepts.

Should reactions also come with Body content?   Akin to some MUA will 
popup a "No Subject. Continue to send?" dialog. To react to a message 
with no new content also popup a dialog?

Could there be a minimum reply set of just sending headers without 
resending/quoting body content?

From:
To:
Subject:
In-reply-react:
Message-ID:  <-- key anchor of threads where reaction apply.

Also, does it have to be resign? DKIM?  ARC?  DMARC, DMARC-Reports? 
Serious more overhead just for reaction.

Finally, consider what Twitter is doing with "retweet?"   It has two 
option:

- Retweet (No comment necessary)
- Retweet with comment

It is my understanding, for lack of a better term, lets call it the 
"Trump Rule" change, Twitter is now "testing" eliminating the 
"retweet" because of the abuse seen with just retweeting (a form of a 
reaction) controversial (fake news) tweets without adding any comment. 
I have a feeling it is enabled on a per user profile basis which would 
be without a doubt something I would add to our mail user profile 
system "[_] Allow Email Reaction" a group profile concept.

Overall, I like the concept. Its applies well at the local mail level, 
but in a network form, it has a high overhead concern due to the 
nature of IMF and SMTP.  It can be unintentionally and intentionally 
abused when some of the above concerns are not considered and addressed.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos