RE: json-string for HTTP header field parameter values

> 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 UTC