Re: quoted-phrase in content-disposition header

[Keith Moore <moore@xxxxxxxxxx>]

> > Olle,
> > I may be a bit stupid, but why is
> 
> > filename = :b:iso-8859-1: R/Z0dGluZ2VuLm1hcA==
> 
> > so much simpler than
> 
> > filename = =?iso-8859-1?b?R/Z0dGluZ2VuLm1hcA==?=
> 
> > that it is worth creating a new, incompatible coding scheme
> > for it?
> 
> I agree. If we're to have a character set name in there and the field
> is to be encoded there is little purpose to be served by inventing something
> that is different just for the sake of being different.

I think we have two choices: either (a) allow the encoding mechanism
to be retroactively applied to older header fields (such as the
'value' portion of content-type field parameters) also, or (b) allow
the encoding mechanism to be used only in newly defined header fields,
where the definition of each new field explicitly allows such usage.

---

If we do (a), the encoded form of 'value' has to fit within
the syntax of the old 'value':

     value := token / quoted-string

     token  :=  1*<any (ASCII) CHAR except SPACE, CTLs,
                   or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@"
                /  "," / ";" / ":" / "\" / <">
                /  "/" / "[" / "]" / "?" / "="
               ; Must be in quoted-string,
               ; to use within parameter values

As currently defined, encoded-words don't work for either 'token'
(since they always contain tspecial characters) or 'quoted-string'
(since strings that look like encoded-words aren't treated as such
when they appear within quoted-strings).  To extend encoded-words to
apply to quoted strings would certainly make the encoded-word RFC more
complex.  

(The original encoded-word draft applied to quoted-strings also, but
that text was excised after discussion at the Santa Fe IETF meeting.
The argument was that encoded-words were their own quoting mechanism,
and therefore there was no need to have them apply to quoted-strings.
I welcomed the suggestion as a useful simplification.)

---

If we do (b), the encoding can have whatever syntax it wants to have.
Encoded-words would work here, but for this use of encoded-words it
would be a good idea to get rid of some of the special rules for
mixing encoded-words and plain text.  

(For instance, if encoded-words were extended to use in MIME
parameters, I would rather have such a parameter be either a series of
encoded-words enclosed in delimiters OR a single token OR a single
quoted-string, NOT some mixture of these.)

My technical (as opposed to aesthetic) objection to using
encoded-words for parameters is based on my fear that implementors
won't get all of the special cases right.  I've received enough
questions about encoded-words in private mail to convince me that the
various cases are not well understood, and yet I don't see how the
current RFC could be made much clearer.  (Suggestions are welcome.)

But since I don't see any reason why using encoded-words for approach
(b) is *technically* infeasible...

IF the consensus is to take approach (b), AND people feel that
(despite my objections) encoded-words are still better, I will modify
1522bis to define this use of encoded-words.

Keith