Re: [Json] Kicking Off JSONbis

On Fri, Oct 30, 2015 at 7:42 PM, Joe Hildebrand (jhildebr) <
jhildebr@cisco.com> wrote:

> 
> There's an argument to be made that if you want to interoperate with JSON
> implementations in browsers, you should probably read ECMA-404.  Several of
> the places where 7159 says "interoperable in
> 
> the sense" have specific choices in ECMA-404.
>

I just re-read ECMA-404 (I recommend this, it doesn’t take long) and I
couldn't find examples of such specific choices, could you be more specific?

> 
> Conversely, serious implementors of ECMA-404 really ought to read 7159bis
> in order to understand some of the edge cases of interoperability a little
> better.
>

Agreed.

> The argument that we shouldn't bother with 7159 at all was discussed the
> last time through.  ECMA-404 only specifies what to do in an ECMAscript
> environment, and someone needed to specify interoperability for other
> environments, such as those that don't use UTF-16 code units or 64bit
> floats as their implementation substrate.
>

Actually ECMA-404 says exactly nothing about what any software should do.
(Maybe I missed it?)

Whether one should bother with ECMA-404 is out of our control, and overcome
> by events.  Both documents exist, and we need to ensure that they stay in
> sync going forward.  We could add a statement to section 1.2 such as:
>

I'm not sure about the premise.  It's not obvious to me that any changes
are required in either 404 or 7159 for the foreseeable future.  404
explicitly says “Because it is so simple, it is not expected that the JSON
grammar will ever change.”

"This document intends to document the exact same data model as described
> in ECMA-404, which is the main document used by ECMAscript implementors.
> Implementors that want to interoperate with ECMAscript implementations
> (such as web browsers) are advised to also read ECMA-404 to understand any
> potential interoperability challenges. Any differences in the model
> described in this document with that described in ECMA-404 are not
> intentional, and will require the IETF and ECMA to work together to resolve
> the difference."
>

1. First, ECMA-404 absolutely does not describe any data model.
2. I don't like this sort of nudge-nudge, wink-wink language. If we want to
provide this language, don't tell them to go search 404 for
“interoperability challenges”. Rather, a simple statement along these lines
would be appropriate.  “This document contains several recommendations for
best practices to avoid interoperability problems.   ECMA-404 enforces none
of these, thus implementations based on it might potentially emit JON texts
which exhibit these problems.“
3. Having re-read 404 closely, I am pretty sure that there are not in fact
any differences in the set of data objects which qualify as “JSON texts”
aside from 404's greater permissiveness already noted. So I'm dubious of
the need for any future work.

> 
> That makes the normative reference understandable, and makes
> 
> clear that the IETF and ECMA are partners in maintaining JSON going
> forward.
>

No, it still falls massively short of the very explicit and clear
definition of the term “normative reference”.

I’m sticking with my suggestion that if it is absolutely necessary to
insert a normative reference, we need language acknowledging that, while
this reference does not meet the usual criteria for that sort of reference,
we are inserting one anyhow because [X].   I think Joe was starting to
suggest a value for [X], but I'm pretty sure we can do better.  I'll write
a note with some suggestions.

>
> --
> Joe Hildebrand
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)