ietf-822
[Top] [All Lists]

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

2020-10-06 16:39:26
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