From Keith Moore:
+ They were also designed only for "free-form" text, not to
transparently convey arbitrary data. For instance, there aren't good
rules for
when an encoded value begins and ends.
+ There are complicated rules that say when certain characters can
appear unencoded in certain contexts (in a phrase, in *text, or in a
comment).
+ The RFC on encoded-words is written in terms of how encoded-words
are to be *displayed*, and not as a mapping between an unencoded string
octets
and and encoded one. So there is inherent ambiguity,
for example, in how to treat white space between adjacent encoded-words
when
they appear in a parameter.
Keith,
I see this as a bug in the encoded word spec. It seems that a proper
examination of that text can tighen up the rules for encoded words such that
they would be precice enough for this usage. I don't see free form text as an
opportunity to be imprecice with the encoding.
In particular, we can specify what whitespace rules to use for separating
encoded words. We can also loosen some restrictions as to their length, making
the encoded word length restriction only a function of it's use in an RFC822
header. None of these changes is incompatable with current usage or the spec
itself, but they do prepare the encoded word for use in the many places where it
can be useful.
Greg V.