Subject: [ietf-822] Encoding (Re: 😟 Re: Fwd: New Version Notification for draft-crocker-inreply-react-00.txt)

From: Dave Crocker <[email-masked]>
Date: Mon, 5 Oct 2020 11:56:14 -0700

>> To be fair, when I saw the lack of any specified encoding

Folks,

As a few postings have demonstrated with emoticons in this thread, it's 
clear that at least some MUAs (or MSAs or MTAs?) are already able to 
take 'raw' Unicode and pass it successfully to recipient MUAs.

Still since there's been concern about encoding raised, I'll ask for 
suggested text to include in the draft.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2020 02:29:15 -0000

In article <[email-masked]>,
>take 'raw' Unicode and pass it successfully to recipient MUAs.

That's a UTF8SMTP aka EAI feature. They're only supposed to do that
for recipients that advertise UTF8SMTP as an EHLO option but having
just done a bunch of EAI compliance tests I can tell you that they're
pretty sloppy about when they do.

>suggested text to include in the draft.

Make it a MIME word with the usual base64 or QP encoding, like the
subject line of the message you just sent. As far as I can tell, only
Unicode has an interesting repertoire of emoji so you could say that
they must be encoded UTF-8.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 Oct 2020 20:07:48 -0700

> they must be encoded UTF-8.

1. "MIME Word" is a term I don't know.  It doesn't make obvious sense to me.

2. MIME doesn't apply to header fields, such as Subject:

3. I wasn't kidding about asking for text.  I mean exact text.  This is 
not a sandbox I've played in or even studied in detail and the text 
needs to be written by someone who has and does.

d/

---

From: "John R Levine" <[email-masked]>
Date: 5 Oct 2020 23:19:39 -0400

> 1. "MIME Word" is a term I don't know.  It doesn't make obvious sense to me.

Sorry, MIME encoded-word.  See RFC 2047 for details.

> 2. MIME doesn't apply to header fields, such as Subject:

That's how you put Chinese and emoji in the subject field in non-EAI Mail. 
Again, see RFC 2047.  For example, the actual subject line of your message 
to which this is a reply was:

Subject: =?UTF-8?B?UmU6IFtpZXRmLTgyMl0gRW5jb2RpbmcgKFJlOiDwn5ifIFJlOiBGd2Q6?=
  =?UTF-8?Q?_New_Version_Notification_for_draft-crocker-inreply-react-00=2etx?=
  =?UTF-8?Q?t=29?=

> 3. I wasn't kidding about asking for text.  I mean exact text.  This is not a 
> sandbox I've played in or even studied in detail and the text needs to be 
> written by someone who has and does.

Well, Keith wrote RFC 2047, so he knows more about this than I do, but I 
think that saying that it's a MIME encoded-word like the unstructured 
text in any other header should do the trick.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Mon, 05 Oct 2020 23:20:58 -0400

> take 'raw' Unicode and pass it successfully to recipient MUAs.

Only if the entire path is sufficiently 8-bit clean. Somewhere between ietf.org's
mail server, google, and fetchmail to my laptop the emoji got smashed into
a lower case 'p' followed by a 0x1f181f, almost certainly due to something
not being totally 8-bit-clean.

So we're still a *long* way from saying "just send 8 bit"

> suggested text to include in the draft.

Anything along the line of "if you don't have an 8-bit clean path, you
need to use rfc2047 to encode the utf-8" is fine by me.

---

From: Ned Freed <[email-masked]>
Date: Mon, 05 Oct 2020 20:51:26 -0700 (PDT)

> So we're still a *long* way from saying "just send 8 bit"

IME it keeps dropping, but never goes entirely clean.

> need to use rfc2047 to encode the utf-8" is fine by me.

+1

				Ned

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Tue, 06 Oct 2020 01:00:55 -0400

> text in any other header should do the trick.

That fixes the encoding issue, and did we decide to punt on what to do
with a "reaction" that consists of a emoji and a short text, like ":) I'm on it!"?

On one hand, that introduces length issues, but on the other hand, I don't know
how to write RFC-ese for "allow more than one emoji" without allowing that
sort of reply as well.  Any MIME-aware MSA or MTA should Just Work if the
header has 'MIME encoded-word' in it, so maybe just a "an MUA MAY truncate
the display of excessively long reactions" may be sufficient?

(Actually, if the final version says it's an encoded-word, and include the "MUA MAY
truncate", I'm pretty sure that addresses all of my concerns...)

---

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

> with a "reaction" that consists of a emoji and a short text, like ":) I'm on it!"?

IMO:  Given that the context for this is an email message, and email 
already provides places for text, providing one more will just add 
unnecessary complexity to this specification, without adding serious 
capability.

> sort of reply as well. 

The current draft already allows for more than one emoji.

I'd expect length limits to be handled by the usual, 'environmental' 
limits on header-fields.

(Also, anyone listing enough emojis to run into that limit probably has 
bigger problems...)

d/

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2020 11:09:21 -0400

>not being totally 8-bit-clean.

I would blame fetchmail which is not famous for high quality standards
compliant code. Postfix and Gmail do not screw up MIME encodings,
particularly since all they need to do to comply is nothing. I see you
use exmh but you presumably know what your code does.

>need to use rfc2047 to encode the utf-8" is fine by me.

Well, yes, that's been the rule for about three decades.

R's,
John

---

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

> Well, yes, that's been the rule for about three decades.

We could say that the field isn't encoded and only available for SMTPUTF8
as a forcing function... you want your emojis, step up.

I know, doesn't really work that way, we'd probably just get 5 different
non-standard ways of encoding it instead.

Brandon