Steve Dorner wrote in message
I have made a revision to the current C-D draft. Before submitting the
full revision, I want to run the salient bits by everyone. If these
changes are largely acceptable, I will submit a new draft.
Regarding non-US-ASCII characters (punt):
Current [RFC 1521] grammar restricts parameter values (and
hence Content-Disposition filenames) to US-ASCII. We
recognize the great desirability of allowing arbitrary
character sets in filenames, but it is beyond the scope of
this document to define the necessary mechanisms. We expect
that the basic [RFC 1521] `value' specification will someday
be amended to allow use of non-US-ASCII characters, at which
time the same mechanism should be used in the Content-
Disposition filename parameter.
Once again postponing a solution is the worst thing that can
happen in my opinion. It's bad enough that the current MIME
specification doesn't allow other character sets than US-ASCII
in the Message/External-Body parameters where they are needed.
It would be a shame if IETF in 1995 publishes a new
application-level protocol still unable to handle more capable
character sets than US-ASCII. The "Inter" in "Internet" really
should be interpreted also as "International" now.
Since I obviously haven't been able to convince anybody but
myself about the merits of the solution I proposed in message
<199501171931(_dot_)OAA24485(_at_)wilma(_dot_)cs(_dot_)utk(_dot_)edu>, I drop
Regard it as never having been put forward. I hope this will
prevent our discussion energy from being wasted on less
important technicalities about the optimal way of encoding
un-American character sets. With interest I look forward to an
acceptable proposal based on maximal resuse of RFC 1522
technology, that I hope others will be able to produce.
Concerning two of my other main points of constructive
criticism of the Content-Dispostion draft in message
<9501172341(_dot_)AA09597(_at_)mercutio(_dot_)admin(_dot_)kth(_dot_)se> -- the
today's practical filename portability problems and the detailed
analysis of the difference between saving only the body of a
message body part to a file and saving the whole body part --
the former has resulted only in the addition of some practically
less helpful general remarks, and the latter hasn't led to any
change of the draft at all. In my opinion this is misguided
specification length economy, but the authors of the draft may
be right in regarding these contributions as peripheral to the
essential subject of the draft.
Besides this, I have no intention of further interfering with
the IETF processing of this important extension of MIME.
Olle Jarnefors, Royal Institute of Technology, Stockholm