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

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 15 Apr 2011 22:59:31 +0200

* [email-masked] 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

Let me quote <http://www.rfc-editor.org/rfc-editor/tutorial.latest.pdf>:

  Title

    * Should be thoughtfully chosen

    * No un-expanded abbreviations, except for very well known ones
      (e.g., IP, TCP, HTTP, MIME, MPLS)

    * We like short, snappy titles, but sometimes we get titles like:

        "An alternative to XML Configuration Access Protocol (XCAP)
         for manipulating resource lists and authorization lists,
         Using HTTP extensions for Distributed Authoring and
         Versioning (DAV)"

    * Choose a good abbreviated title for the running header

    * "WebDAV Alternative to XCAP"

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".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 17 Apr 2011 21:46:35 +0900

> 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

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]].

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.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 Apr 2011 15:09:17 +0200

On 17.04.2011 14:46, "Martin J. Dürst" wrote:
> 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.

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.

> 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