Re: structured headers "why not JSON" FAQ

On 2018-06-13 12:01, Mark Nottingham wrote:
> ...
>>> Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult to enforce.
>>
>> Not sure what interop problems you are referring to. SH currently only has ASCII, forcing non-ASCII content (when needed) into binary values. That doesn't seem to be an advantage for those who actually need non-ASCII.
> 
> The easy availability of non-ASCII content in JSON invites its use when it isn't necessary.

So what are the interop problems you were referring to?

>>> Another example is JSON’s ability to nest content to arbitrary depths. Since the resulting memory commitment might be unsuitable (e.g., in embedded and other limited server deployments), it’s necessary to limit it in some fashion; however, existing JSON implementations have no such limits, and even if a limit is specified, it’s likely that some header field definition will find a need to violate it.
>>
>> a) A limit could be enforced *before* feeding the field values into the JSON parser.
>>
>> b) "and even if a limit is specified, it’s likely that some header field definition will find a need to violate it" - how is that different in SH?
> 
> In SH, if you violate the limits, you won't work with most SH implementations (provided we can get good conformance; that's why having a test suite and detailed algorithms are important) -- or at least enough to dissuade violating the limits. With JSON, there are strong incentives to allow "all of JSON" in.
> ...

I would say that the incentives are exactly the same for the two 
variants. If the spec makes a mandatory requirement on the recipient 
that is easy to implement, why would implementations choose to follow it 
for SH but not for JFV?

Best regards, Julian

Received on Wednesday, 13 June 2018 10:13:12 UTC