ietf-822
[Top] [All Lists]

Re: [ietf-822] More encoding (was Re: Fwd: New Version Notification for draft-crocker-inreply-react-02.txt)

2020-10-18 20:49:31
In article <01RQYDVJUD5A005PTU(_at_)mauve(_dot_)mrochek(_dot_)com> you write:
On 10/16/2020 4:01 PM, Ned Freed wrote:
    In messages that are not Internationalized [RFC6532], emoji and any
    other non-ASCII characters MUST be encoded using [MIME-Enc].

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

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.

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.

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

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822