Re: comment for draft-moore-mime-cdisp-00

[Ned Freed <[e-mail]>]

> Regarding the Filename parameter, none of Asia language is taken into
> consideration.

This is simply not true. This draft specifically references the
I-D draft-freed-pvcsc-03.txt, which was recently approved as a proposed
standard. This draft provides a means by which any MIME content-type
parameter or content-disposition parameter can be encoded, can have
a character label, and can have a language label. As such, not only is
it possible to have filenames containing Asian characters, the mechanism
for doing so is already standardized.

> As result, it is sort of nightmare in specially Japan.
> Many copmanies use different encoding scheme. This is because none of
> RFC does allow to use Asia character for file name as of today, it
> allows only US-ASCII.

The one thing the draft doesn't do is deal with the issue of what character
sets to use when. And make no mistake about it -- this _is_ a nightmare.
This is the reason we didn't define a mechanism when MIME was first developed.
What we've done now is simply avoid this issue because were we to try and
deal with it we'd never have reached any sort of consensus. 

> Since using double-byte character is very natual in Asia countries as
> file name. filename-paran := "filename" "=value" need to be more
> considered to be able to accomodate non-US-ASCII character for value
> field. MIME-2(Message Header Extensions for Non-ASCII) is defined as
> extension for header field., I don't think this can be applied to this
> "value".

This has already been. See the referenced draft.

> It is time to say like
> ---------------------------------------------
> disposition-param := filename-param
> 	/..............
> filename-param := "filename" "=" dstring
> dstring := 1*utf8
> utf8 := <any sequence of octets formed from the UTF-8 transformation of
> a character from ISO 10646>
> ---------------------------------------------

This is unacceptable, as it would lead to 8bit characters in message headers.
Message headers have to remain 7bit to be compatible with the installed base.
But this is not a problem if the mechanisms we've defined are used.

				Ned