- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 27 Apr 2012 18:50:54 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Apr 27, 2012 at 12:39 AM, Mark Nottingham <mnot@mnot.net> wrote: > > On 27/04/2012, at 5:32 PM, James M Snell wrote: >> >> It may be because it's after midnight and I really should be getting >> some sleep, but i don't quite follow what you're saying about >> requiring knowledge of the headers to translate between the different >> encodings. > > Right now, it's possible to encode non-Latin-1 characters into headers using an encoding, like that described in RFC5987. > > However, that isn't a blanket encoding; i.e. the header definition has to specify its use. Generic software can't just look at headers and say "look, that's internationalised"; it has to know the header's specific syntax to lift it up to UTF-8 (for example). > > Right, but could we not "simply" do what WebSockets has done and define distinct binary and text data frames in which the text frame always assumes UTF-8? With such an approach, we would not need to worry about things like RFC5987 or determining whether the header is defined as being i18n'able. - James
Received on Saturday, 28 April 2012 01:51:43 UTC