Quoting: Ned Freed <NED(_at_)innosoft(_dot_)com>
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.
Well surely Keith and others have justified the non-suitability
for as-is use of 1522-encoded words better than that!?
I already have lots of code to support RFC1522. I suspect
many other people do as well. I would like to be able to
reuse this code if at all possible.
Olle said
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
for instance.
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!
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
their users.
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.
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?
Concerning the formalities, I think the discussion have shown
that we don't now if and how we can "amend MIME":
Steve:
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.
Steve:
All I want the C-D RFC to say is that, when the problem is
solved for MIME in general, the same solution should be used
for C-D, either explicitly (via a revision) or implicitly.
If you can think of better words for that, I'll be happy to
use them.
Keith:
I guess I was wondering if the problem ever would be solved
for MIME in general, as opposed to just solving the problem
for new MIME extensions. What do other people think will
happen?
I agree. We can't and shouldn't redefine.
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!
---
Peter Svanberg, NADA, KTH Email:
psv(_at_)nada(_dot_)kth(_dot_)se
Dept of Num An & CS,
Royal Inst of Tech Phone: +46 8 790 71 40
S-100 44 Stockholm, SWEDEN Fax: +46 8 790 09 30