W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: I-D Action:draft-reschke-rfc5987bis-00.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 17 Apr 2011 15:09:17 +0200
Message-ID: <4DAAE67D.7010801@gmx.de>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, julian.reschke@greenbytes.de, ietf-http-wg@w3.org
On 17.04.2011 14:46, "Martin J. Dürst" wrote:
> On 2011/04/16 5:59, Bjoern Hoehrmann wrote:
>> * Internet-Drafts@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> Title : Character Set and Language Encoding for Hypertext Transfer
>>> Protocol (HTTP) Header Field Parameters
>>> http://www.ietf.org/internet-drafts/draft-reschke-rfc5987bis-00.txt
>> So while there is some value in retaining the title, maybe get rid of at
>> least the HTTP expansion? Also, http://www.w3.org/TR/charmod/#C020 but
>> in this case I suppose an argument can be made to keep "character set".
> I guess the first five words were meant to parse as
> Character Set Encoding and Language Encoding
> which would mean that "encoding" does not stand for transforming one
> stream of values into another (as it does in most other usages), but
> just for applying and attaching a single code value to some data. In the
> vicinity of "Character Encoding", this is highly confusing. I guess a
> much better title would be
> Indicating Character Encoding and Language for HTTP Header Field Parameters

Sounds good to me. I'll check with the IESG once we get there whether we 
want to change the title at this point.

> It would also be helpful to understand what changes are planned.
> http://tools.ietf.org/html/draft-reschke-rfc5987bis-00#appendix-A, which
> should document them, says [[none yet]].

See my mail from yesterday:

> See <http://greenbytes.de/tech/webdav/draft-reschke-rfc5987bis-00.html#rfc.issues-list> for the current TO-DO list (which is short).

...so the only normative change currently on the table is to drop the 
requirement to support ISO-8859-1 in addition to UTF-8.

> On top of that, I'd like to repeat that this stuff is hopelessly
> confusing and overengineered. There's no need for encoding labels, all
> that's needed is to accept that UTF-8 works in HTTP headers (and fix it
> where it doesn't yet). As for language tagging, the uses for this a very
> few and very far between.

We had these discussions many time.

- We can't change the defaults for HTTP/1.1, in particular not for 
existing header fields.

- The RFC 2231/5987 encoding nowadays is widely implemented for 
Content-Disposition (all UAs except Safari).

- The language tagging is a leftover from RFC 2231; it may not be very 
useful, but there's no point breaking deployed code just because we may 
think it is.

Best regards, Julian
Received on Sunday, 17 April 2011 13:09:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:51 UTC