Ned Freed <NED(_at_)innosoft(_dot_)com>:
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?
In the case of a filename it shouldn't be necessary but if we
want this to be usable for other kinds of values it may be.
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.
I see that, but don't we need the *full* mechanisms, not just
part of it, with things needing to be changed later?
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
I know that you and several others knows about this, but
there are newcomers.
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.
I quote from the archive:
Subject: Minutes of the RFC 822extensions WG in Columbus
Date: Wed, 07 Apr 93 17:49:46 -0400
From: Greg Vaudreuil <gvaudre(_at_)cnri(_dot_)reston(_dot_)va(_dot_)us>
MIME-Version: 1.0 Header Semantics
The Working Group discovered that the MIME-Version header was
insufficiently defined to be used for true versioning and that the
interpretation of this header was not uniform across current
implementations. Understanding that backward compatible changes to
MIME were unliely and that changing the version in the current header
will cause at least one implementation to fail to recognize the
message as valid MIME, the Working Group agreed that this header
should now be considered a string constant and any version specific
notes should be encoded as an RFC822 comment in the MIME-version
header line, a feature available in all other rfc822 headers.
OK, according to this you can put "notes" in the comment.
(Should "unliely" have been "unlikely"?)
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.
What do you have in view?