Quoting: Ned Freed <NED(_at_)innosoft(_dot_)com>
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
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
Well surely Keith and others have justified the non-suitability
for as-is use of 1522-encoded words better than that!?
On the contrary. What Keith has done previously is illustrate how use of
RFC1522 encoded-words is orthogonal to the use specified here. That is, you
cannot expect a RFC1522 processor to decode these things for display, that
there are inherent ambiguities involved in RFC1522 displays, and so on.
Keith has also said that these problems are actually features of RFC1522. I
agree. The processing called for by RFC1522 is quite clear, and equally clearly
would not apply to the content-disposition parameters. We need to do something
different for these parameters, it needs to be specified separately, and it
needs to be implemented very differently.
All I said, and all that I believe Harald said, is that a gratuitous change of
syntax just for the sake of being different is not a good idea. Why not
reuse the syntax if at all possible so implementors can use the machinery
they already have to decode encoded words?
Syntax is not semantics. The semantics of these parameters values is quite
different from the semantics of RFC1522 encoded-words.
That doesn't mean we cannot use the same syntax, and the same syntax
processors, for different functions.
We do have additional work to do here, however. For example, should we allow
multiple character sets in the same parameter value?
If RFC 1522 encoding is to be used in parameter values, a new
"profile" of the general encoding must be done for this new
application. Also the specification must be reworked and made
more precise. There is no full EBNF specification in RFC 1522
I agree with the first and not the second. This is effectively a new profile of
encoded words. However, the RFC1522 specification does NOT need to be reworked,
and it most certainly does not need more complete EBNF and greater precision.
RFC1521 illustrates quite nicely that extra EBNF and greater precision doesn't
always make things clearer. There is much less EBNF in the new draft of the
MIME specification, since much of it was found to be inconsistent and useless.
Maybe it is better, after all, to solve the problem in this
way, istead of inventing something new?
May main concern is that
THIS PROBLEM MUST BE SOLVED IN (or in
parallel with) THIS DRAFT!
Parallel I can accept. However, we need the mechanisms this draft provides
sooner rather than later. And as you say, the solution needs to be extended to
cover other cases where structured machine-readable entities (as opposed to the
totally unstructured "write-only" entities RFC1522 deals with) appear and
need similar capabilities.
A specification of a filename parameter with only ASCII
capabilities will lead to a miserable situation with lots of
user irritation and probably a bunch of different own solutions
by the implementors - as a result of too much complaints from
Note that files with non-ASCII names are not rare. At least on
Macs it is as natural to use non-ASCII letters in file names as
it is to use them in (other) text.
Sure. And this issue has been discussed endlessly in this group and elsewhere.
It came up when MIME moved from proposed to draft, and we spent hours on it at
a couple of different IETF meetings.
Consider the situation that a user has 10 files that he wants
to send. How should the program handle it? Tell the user to go
change all the names of the files and then try again? Urge him
to interactively give 10 new names to be used in the transport
to the receiver - giving him poorer (and incompatible) names?
And what should a gateway between a local net and Internet
do when handling a message from a non-Internet UA which
has no such limitations? Bounce?
We are all aware of the problems.
Concerning the formalities, I think the discussion have shown
that we don't now if and how we can "amend MIME":
If there were ever a time to change MIME-Version, changing
the parameter syntax would be it.
As I recall it, the conclusions of the agreements on the IETF
meeting when the MIME text was finalized was that it is
impossible to change the MIME-version field, ever.
This simply is not the case.
1522 was a special - and well justified - case of retroactive
change of an established standard. We should not deliberately
create a need to do such a change again!
Unfortunately it is too late for that.