- 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>
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 <https://github.com/httpwg/http-extensions/commit/5ec7eed4fa2c941a34e868117ef2fb634d8d506e>. (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