In article <8cd3a145-2105-9fc0-e382-122bf3cbf94f(_at_)dcrocker(_dot_)net> you
write:
On 10/6/2020 10:23 AM, Dave Crocker wrote:
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.
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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822