After sending my last message I found where Keith had snuck in some
additional prose about the undesirability of reusing the syntax. My
comments on his statements follow.
Without the requirement to be backward compatible with RFC 822 atoms
in phrases, the encoding can be much simpler. For new applications,
it is easier to design an encoding scheme that is simple to decode
correctly, than it is to extend a 1522 encoder and decoder to handle
the extra special cases for new applications of encoded-words.
The amount of simplicity gained is very marginal at best -- one character
instead of two in two places. Whoopee. I also think that given the fact that
this needs to extend to other structured fields we need the two character
guards here every bit as much as we do in RFC1522.
And if you make the new scheme look too much like encoded-words, it'll
just invite confusion between the two. It certainly doesn't make it
easier for the implementor.
On the contrary, it makes it much easier for the implementor. I have all kinds
of routines available to me to deal with encoded words. Now you are telling me
that I have to write a new suite of them or add options to them to deal with a
gratuituous two-character change in syntax. Sorry, I don't buy this at all.