- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 31 Oct 2011 19:54:52 +1100
- To: "Manger, James H" <James.H.Manger@team.telstra.com>
- Cc: "Thomson, Martin" <Martin.Thomson@commscope.com>, httpbis Group <ietf-http-wg@w3.org>
On 31/10/2011, at 5:34 PM, Manger, James H wrote: >> But Mark said it best. The encoding in 5987 is sufficient. >> I tend to think that it loses a lot in the human-readable area, >> which is still important to me, but it is hard to justify >> adding another mechanism where an adequate one already exists. > > If the RFC5987 encoding is sufficient, then httpbis should recommend RFC5987 syntax instead of token and quoted-string (for new headers and auth scheme parameters). It is having to add RFC5987 as an additional syntax just to get Unicode support that is most objectionable. Unicode isn't necessary for the majority of headers; it's only when there's user-visible data that it's necessary. Mandating 5987 -- or any encoding -- across the board would be overkill. > Mark said: >>> New headers (or new parameters to existing ones) don't have to >>> support two parameter names -- if they want to specify that only >>> foo* be present, so be it, AIUI. That puts it to one syntax and >>> one escaping mechanism. > > That might work. I doubt groups defining new parameters will be that happy that some names have to end with a * (and values start with UTF-8''), particularly when Unicode support is nice but not crucial (at least initially). It would be better if Unicode wasn't a 2nd-class citizen. That is, it would be better if the recommended way to include a string parameter value automatically supported Unicode. See above. HTTP headers aren't intended to be exposed to end users, so I'm not sure why a * matters that much, in the big scheme of things. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 31 October 2011 08:55:38 UTC