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

RE: json-string for HTTP header field parameter values

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Mon, 31 Oct 2011 17:34:45 +1100
To: "Thomson, Martin" <Martin.Thomson@commscope.com>, httpbis Group <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E11291D3891F@WSMSG3153V.srv.dir.telstra.com>
> 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.


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.

--
James Manger
Received on Monday, 31 October 2011 06:35:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:49 GMT