Re: structured headers "why not JSON" FAQ

On 2018-06-13 12:16, Mark Nottingham wrote:
> 
> 
>> On 13 Jun 2018, at 8:12 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> 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?
> 
> String normalisation, comparison, homographs, etc.

Well, yes. I18N makes things harder. I just don't buy the argument that 
it's a *downside* of JFV over SH. Either you need non-ASCII, in which 
case JFV is clearly better than SH. Or you don't, and then it doesn't 
matter.

>>>>> 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?
> 
> Because the option of deploying a JSON implementation *without* those constraints is extremely easy.

I don't buy that argument.

Best regards, Julian

Received on Wednesday, 13 June 2018 11:04:41 UTC