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

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Oct 2020 12:04:36 -0700

Note -- Diff:

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

-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-inreply-react-02.txt
Date: Fri, 16 Oct 2020 11:59:55 -0700
From: [email-masked]
To: Dave Crocker <[email-masked]>, R. Signes <[email-masked]>

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

Name:		draft-crocker-inreply-react
Revision:	02
Title:		React: Indicating Summary Reaction to a Message
Document date:	2020-10-16
Group:		Individual Submission
Pages:		6
URL: 
https://www.ietf.org/archive/id/draft-crocker-inreply-react-02.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-02
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-02

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: "John Levine" <[email-masked]>
Date: 16 Oct 2020 18:33:29 -0400

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

Looks better but this part is still wrong:

   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].

In non-EAI mail there is no rule about interpreting 8-bit stuff other
than that it is invalid, and definitely no rule that assumes it is
encoded as UTF-8. I have no idea whether there are other character
sets that have emoji, and I don't think any of us want to waste time
finding out.  Ergo:

   In messages that are not Internationalized [RFC6532], emoji and any
   other non-ASCII characters MUST be encoded using [MIME-Enc].

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 16 Oct 2020 16:01:38 -0700 (PDT)

> finding out.

UTF-EBCDIC is one such.

   <ducks and runs>

>  Ergo:

>    other non-ASCII characters MUST be encoded using [MIME-Enc].

+1

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Oct 2020 12:39:12 -0700

>>     other non-ASCII characters MUST be encoded using [MIME-Enc].

Drat.  Thought I'd included the text for this.

However, I just got an offlist suggestion I'd like to get reactions to:

> ... consider allowing the emoji to be specified (one option) as
> "U+1F44D", so:
>    In-Reply-React: U+1F44D U+1F622

The plus is that it's extremely simple, and works nicely for short 
sequences like this.

The minus is that it's not 'standard'.

Thoughts?

d/

---

From: Ned Freed <[email-masked]>
Date: Sun, 18 Oct 2020 13:00:22 -0700 (PDT)

> Thoughts?

My thought is "no". It's not that encoded-words are great, it's that they enjoy
universal deployment. Use encoded-words and access to the unencoded form is one
routine call away, if that. Anything else is more work, and no matter how much
better is looks to coding geeks, it's still nonsense to users.

				Ned

---

From: "Ricardo Signes" <[email-masked]>
Date: Sun, 18 Oct 2020 16:59:40 -0400

On Sun, Oct 18, 2020, at 4:00 PM, Ned Freed wrote:
>>  [ … U+1Fxxx …]

Totally agreed.

-- 
rjbs

---

From: "John Levine" <[email-masked]>
Date: 18 Oct 2020 17:37:33 -0400

>> > ... consider allowing the emoji to be specified (one option) as "U+1F44D", so:

>better is looks to coding geeks, it's still nonsense to users.

I agree. Every MUA that can display Unicode already has code to handle
encoded-words. Use it. Indeed, having tracked down some MIME bugs in
mail processing libraries I can say that in many cases it would take
extra special case coding to make an MUA *not* do encoded-word
decoding on a new header field.

---

From: Ned Freed <[email-masked]>
Date: Sun, 18 Oct 2020 18:42:15 -0700 (PDT)

> decoding on a new header field.

And if encoded-words are still too... flexible, how about a recommendation
or even a requirement that UTF-8 be used? Amending your suggested language
to:

   In messages that are not Internationalized [RFC6532], emoji and any
   other non-ASCII characters MUST be encoded using [MIME-Enc] with UTF-8
   as the charset.

				Ned