W3C home > Mailing lists > Public > www-international@w3.org > October to December 2003

RE: Problem in downloading a pdf file having Japanese characters in the name of the file

From: Jungshik Shin <jshin@i18nl10n.com>
Date: Tue, 4 Nov 2003 03:59:57 +0900 (KST)
To: "Addison Phillips [wM]" <aphillips@webmethods.com>
Cc: "Paul Deuter (by way of Martin Duerst <duerst@w3.org>)" <PaulD@plumtree.com>, www-international@w3.org
Message-ID: <Pine.LNX.4.58.0311040331540.978@jshin.net>

On Mon, 3 Nov 2003, Addison Phillips [wM] wrote:

> I think that an Internet-Draft with the IETF (that is, a new RFC) would be a
> more likely alternative, since RFCs define the headers and their semantics.
>
> It also seems that there are standards, but that they are not implemented
> consistently. That might actually be the starting place.

 I agree.


> > -----Original Message-----
> > From: www-international-request@w3.org
> >
> > Steve is correct.  There does not seem to be any standard for encoding
> > the "filename" value in the Content-Disposition header.

  At least for emails, there is clearly the standard(it's RFC 2231).
To be compliant with RFC 822/STD 11, one cannot use RFC 2047-style
encoding for filename and other parameters of MIME header fields.

  When it comes to http headers, there's no explicit mention. However,
http borrows several things from MIME so that it's quite natural to
assume what's true of RFC 822/STD 11 and MIME is also true of HTTP in
absence of a provision explicitly saying otherwise.

 As I wrote earlier, it's regrettable and unfortunate that it's buried
deep inside RFC 2231. It's certainly unlikely that many people came to
that document while looking for answers on the issue.

  Anyway, if a new standard is going to be written for http header, I'd
say that it should be 'raw UTF-8'.

  Jungshik
Received on Monday, 3 November 2003 14:00:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:03 GMT