Re: [EAI] draft-klensin-encoded-word-type-u-00

[Frank Ellermann <[e-mail]>]

On 24 November 2011 22:58, John C Klensin <[e-mail]> wrote:

> encoding form "B" pretty much requires a computer to decode.
> %-encoded UTF-8 octets are even worse: one needs a computer
> or a subtle calculation to turn them into a Unicode code point

I'm not sure what is worse, with UTF-8 I'd see where code points
begin and end, and a "manual" decoding of the tail bytes is not
impossible.  But after that step I'd give up and write a decoder,
actually I did that years ago.

> I've just posted draft-klensin-encoded-word-type-u-00 as a
> strawman

| =?iso-10646-UCS-4+de?u?Das ist verr\u'00FC'ckt?=

Yes, it must appear as ASCII-gibberish word, you have to encode
the spaces somehow.  And there are lots of MUST NOTs in section
5 bullet (3) of RFC 2047.  I vaguely recall that the USEFOR WG
also tried to do something interesting with RFC 2047 + 2231, but
I've forgotten the outcome.  Only Bruce Lilly really understands
these RFCs, and here I intentionally exclude the authors. :-)

But doing something based on RFC 5137 is attractive.  (If you
want to see me screaming look up "RFC 2231" in USEFOR archives.)

Of course we could say that rare EAI downgrading scenarios can
as well eat the existing 2231 dogfood, but I'm not sure that
"encoded words" really solve EAI problems with all those MUST
NOT in 2047.

-Frank