To extend encoded-words to
apply to quoted strings would certainly make the encoded-word RFC more
complex.
I guess I don't understand why you dislike this.
1522 already specifies that it can be used only in specific grammatical
entities. What's wrong with specifying one of those specific spots as
inside a quoted string in a MIME 'value'?
The only practical problem I see is that it disallows literal values that
happen to look like 1522-encoded words. Given what 1522-encoded words look
like, I'm not sure that's a big deal.
It doesn't break anything that is legal now and can be retrofitted into all
existing values; no need to redefine them all just to get the benefit of
1522.
encoded-words enclosed in delimiters
What delimiters do you have in mind? If you use anything other than "'s,
you create syntax errors for parsers that don't understand what you're
doing, because = is a tspecial.
I've received enough
questions about encoded-words in private mail to convince me that the
various cases are not well understood
I think the RFC is reasonably clear and these problems are no worse than
others we live with. The only thing that's a real pain in the neck is the
whitespace stuff, which, as you say, could be made better by not allowing a
mix of encoded words and plain text.
I really don't mean to be argumentative, I just don't see how we can use
1522 in values without enclosing it in "'s, and if we enclose it in quotes,
then I don't see what the harm is in applying it to existing parameters.
As I said before, I'm willing to live with some solution other than 1522.
But if we're going to use 1522, then using it inside "'s in parameter
values seems like an easy call to me.
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."