[Top] [All Lists]

Re: quoted-phrase in content-disposition header

1995-01-25 19:07:32
To extend encoded-words to
apply to quoted strings would certainly make the encoded-word RFC more

I guess I don't understand why you dislike this.

Because I'm the one who gets mail from people who don't understand
1522 :)

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'?

It can certainly be done, given the right set of restrictions on the
contents of a Q-encoded field.

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.

Right.  If you use encoded-words in MIME values, you have to enclose
them in double quotes.

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.

That may be so.  I have no way of knowing how much of a pain this will
be compared with, say: the use of unquoted "."s in RFC 822 phrases, or
using domain abbreviations where FQDNs are required, or illegal
timezones in dates.

All of the above examples seem to be similar to what I fear for
encoded-words: taking something that seems reasonable in one context
(a person's name, a domain abbreviation, a timezone name) and putting
it verbatim in another place where it doesn't belong.  All of these
are symptoms of the "plain-text protocol disease": the assumption that
"if the protocol looks like text, you can put any kind of text you
want there".

In all of these cases the RFCs clearly prohibit the bogus behavior,
but such behavior is prevalent anyway, and it does cause problems.

But the problems caused by the examples above don't appear to be as
detrimental to interoperability as would be the case if the same kind
of abuse were to happen with MIME parameters.  For example, none of
the problems mentioned above are likely to interfere with the
recipient's ability to read the message.  I doubt we would be so lucky
with encoded-words used in MIME parameters.

Encoded-words might be the best way to go, but I'm still skeptical.

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.

If you use encoded-words in values you have to enclose them in double
quotes.  My question is still: should we use encoded-words in values?