Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt

[Carsten Bormann <[e-mail]>]

On 05 Dec 2013, at 16:27, Paul Hoffman <[e-mail]> wrote:

> <hat on>
> 
> On Dec 5, 2013, at 12:20 AM, Carsten Bormann <[e-mail]> wrote:
> 
>> Major new bug (apart from the one Rob found):
>> 
>> — A SHOULD-level requirement for BOM tolerance is a gratuitous change.  (I thought we were shooting for a MAY.)
> 
> There was a reasonable number of people who were very concerned that JSON documents that were being sent around with a BOM would be rejected.

As they should be.

One way to deal with a common mistake is to legitimize it.

Doing this too often leads to soup.

(The alternative is to point out the mistake is a mistake.)

However, I’m not at all convinced that people adding BOMs to their JSON senders even is a common mistake.

I have seen way more HT characters (TABs) in strings, trailing commas etc., than BOMs in JSON documents.  Should we legitimize those, too?

> Given the current text:
>   Implementations have been observed to generate JSON texts prefixed
>   with a Byte Order Mark character.  While this is not allowed by the
>   grammar in this specification, in the interests of interoperability
>   it is RECOMMENDED that implementations which parse JSON texts ignore
>   the presence of a byte order mark rather than treating it as an
>   error.
> what change would you make?

it is RECOMMENDED that implementations which parse JSON texts ignore
->
implementations that parse JSON texts MAY WISH TO ignore

(OK, without the RFC 6919ism, as apt as that may be here, that becomes:)

implementations that parse JSON texts MAY ignore

(Maybe add that this is mostly relevant for parsers that are used to interpret JSON files entered by users, not so much for those used for data interchange.)

>> — Even if the WG decides that change is warranted, the text on -08 will be read as “JSON now allows BOMs” by anyone who is not a language lawyer.  The “SHOULD accept” needs to be accompanied by a (redundant, but contextually necessary) “MUST NOT send”.
> 
> If it is redundant (and it is, given the carefully worded intro to that sentence), why do you feel it is "contextually necessary”?

Because a number of decades of watching people interpret specifications teaches me that people will read this as “JSON now allows BOMs”, all careful wording aside.  So they will add BOMs to all JSON documents they send and then complain to the other JSON implementers that haven’t changed their implementations for BOM tolerance that “this is now valid JSON”, as you "SHOULD ignore the BOM".

Adding the (theoretically redundant) “MUST NOT send” makes it more likely that this obvious misunderstanding is nipped in the bud.

If the ensuing clarity creates too much cognitive dissonance, at least s/the grammar in//.

Grüße, Carsten