W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: #227: Encoding advice for new headers and parameters

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 6 Oct 2016 14:44:10 +0200
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>, Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <4db0e6bf-987e-265d-2bc6-a79c85a91ab3@gmx.de>
On 2016-10-04 05:28, Martin J. Dürst wrote:
> On 2016/10/04 10:59, Mark Nottingham wrote:
>> <chair hat> it sounds like we can close this issue with no action --
>> anyone else have thoughts?
> Well, this is in no way a new thought, but it is worth repeating: What
> about just using UTF-8, plain and simple.

Well, that's an orthogonal discussion. It hasn't been UTF-8 in the past, 
and APIs assume otherwise, so it's not that simple. But it's certainly 
something we can consider in the future.

FWIW, I tried to better explain this in 

(We discussed this a bit in Stockholm, and my proposal was just to 
opt-in using a BOM in the first bytes of the field value...).

> This solution was available almost 20 years ago (see RFC 2277). There
> were certain backwards-compatibility issues, the worst of which
> according to my knowledge would have been that UTF-8 would have shown up
> as double-encoded garbage when interpreted as iso-8859-1 (as defined in
> HTTP at that time).
> What I find extremely disappointing is that despite this group being
> composed of a lot of very intelligent people, it was impossible to move
> towards such a simple solution even at a slow pace. The good thing is
> that it's never too late. But that doesn't mean that we have to push
> this solution out another 20 or 50 years.

I agree that we need a better solution than RFC 5987.

However, the purpose of 5987bis is just to update a specification that's 
already in use.

Best regards, Julian
Received on Thursday, 6 October 2016 12:45:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 October 2016 12:45:26 UTC