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