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

[John C Klensin <[e-mail]>]

Hi.

One of John Levine's comments about the mailinglist document and
some issues with pop-imap-downgrade have convinced me that there
is a problem with the use of encoded words in strings that users
are expected to see and work with that we might actually know
how to fix.   

Historically, encoded words have been used in contexts where we
expected MUAs to turn them back into their original (native
character) forms, with display of those encoded forms to users
being a (hopefully infrequent) last resort.   That decoding is
less likely in the pop-imap-downgrade and mailing list
situations: in both, if the relevant clients could handle native
UTF-8 addresses, the encoded word forms would not be necessary.

The problem with encoded words in those contexts is that
encoding form "Q" is pretty useless except for mostly-ASCII text
and of somewhat dubious value then and 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 reference which then must be
looked up in a table and one actually has to understand how
UTF-8 works to be able to tell whether %NN%MM%OO is one
character, two characters, or three characters.

One possible solution is to mix the encoded word strategy will
direct encoding of Unicode characters by code point.  I've just
posted draft-klensin-encoded-word-type-u-00 as a strawman for
doing just that.  It is not a WG document.  It is not even a
serious proposal at this stage.  But it provides a relatively
concrete proposal about "something else" that we might do to get
at least slightly dug out of the present hole that some of you
might consider worth thinking about.

I have deliberately not added normalization considerations to
that draft, but it could easily be done and I suspect it would
be necessary if the proposal was to be as useful as it might be.

    john