JSON liaison

DKA: Welcome to our guests
... The topic of JSON came up at the recent TAG f2f
... Particularly the question of the relation between work and specs at ECMA TC39 and the IETF JSON WG
... We wanted to help with any possible coordination issues, but didn't feel we had enough information
... And thought that getting a number of the relevant players from the two groups "in the same room"
... So here we are
... So, AR, what were your particular concerns

AR: We were trying to see if we could identify and perhaps better coordinate wrt what we saw as overlap between TC39 work and IETF JSON WG work

DKA: Potential output would be a decision to spawn some joint work, but everything is on the table
... If the TAG can help, we'd like to

MM: I'm one of the cochairs of JSON WG at the IETF

MM: RFC 4627 is the only existing IETF JSON doc, but it's informational

MM: The WG was chartered to revise this to the Standards track, as there was real need from other IETF docs for a normative reference
... IETF participation in WGs is by individuals volunteering, and a number of people have gotten invovled
... We reached WG consensus recently, and are now in what is known as WG Last Call at the IETF
... The next step would be IETF Last Call

<twbray> Possibly of interest related to this discussion:

<twbray> Specifications of JSON: https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.section.1.2

<twbray> Introduction to This Revision: https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.section.1.3

<twbray> Appendix A. Changes from RFC 4627: https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.appendix.A

HST: IETF LC is similar to W3C Last Call and/or CR, in that it's a) the point at which wide review is appropriate and b) the point before adoption

<annevk> So, FWIW, the combination of XMLHttpRequest's JSON and JSON's definition in ECMAScript has a wider grammar than this RFC

<annevk> It doesn't seem useful from a platform perspective...

DKA: Is IETF LC our opportunity to get involved?
... AK, AR, could you say what you think the issues are?

AR: I'd first like to hear DC's perspective

DC: I'm not involved now in the IETF effort -- I was for a while, but left the WG because I was concerned about the direction the WG was going
... I went back to ECMA and produced a grammar of JSON as a serialization of Javascript: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
... Which was intended for other specs and so on to reference

<slightlyoff> didn't understand...what's the issue?

DC: The old RFC 4627 was never intended to be a language spec., it was a necessary part of registering the application/json media type

TBL: What was the char encoding?

AvK: [inaudible]

TBL: I think you're talking about the US-ASCII default for the text/... MIME tree

<annevk> What I tried to say was that text/* has a bunch of IETF legacy they don't really want to get around, but implementers have. So we have text/vtt and such today that work sanely...

DKA: When was the old RFC?

DC: July 2006

DKA: So maybe that's water under the bridge -- TB, what's your view?

TB: The draft we published a few weeks ago is worth a look
... There are many specifications of JSON: json.org, ecmascript 5.2, rfc4627, ecma 404
... hard to see any as more canonical than any others

TB: They are all consistent, except for the original 4627 which has some top-level constraints
... the IETF draft (http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06), which I encourage you all to read, just retakes the RFC and adds notes about places where interoperability problems have been observed

AR: I have recalled from the TC39 discussions that there was debate about the semantics which was encodable
... ECMA404 explictly declines talk about the semantics: willful ignorance
... Embedding specs, e.g. browser specs, might supply (most likely) Javascript semantics
... Whereas the IETF draft does give some semantics
... DC, can you confirm that "no semantics" was your intent?

DC: Yes, precisely -- that's a matter for consuming application

TBL: So some flexibility in interpretation?

DC: Yes -- what I did not want to do was require that what Javascript does is what everyone should do

AR: Whereas I hear the IETF saying that this "willful ignorance" leads to interop problems

AR: And they want to fix that
... TB, is that right?

TB: No, I don't think so
... First, "the IETF" doesn't say anything as such

TB: Second, the WG thinks that JSON generally works great
... interoperability is good
... There are a few areas where interoperability issues have been observed, and the IETF draft [4627bis] tries to enumerate them
... but the IETF draft does NOT contain any MUSTs or SHOULDs that weren't in 4627

TB: In particular, in my day job work wrt identity some of these give rise to security vulnerabilities

<twbray> One particular standards-writing pain point is that people who are doing identity standards is that they have to reference JSON and then add extra criteria such as MUST NOT have dupe keys. We'd like to give them something to point to so they don't have to repeat that for every standard

DKA: Are you aware of incompatibility with ECMA404?

AvK: ECMA404 specifies a language which is a superset of the language in 4627bis

AvK: A document consisting of 'false' is allowed by ECMA404, but not by 4627bis

TB: Yes, that's the point I mentioned above which we inherited from 4627

AvK: What we want is to have interop with the JSON that Javascript will parse

<annevk> What we want for web platform APIs is to have interoperability with JSON.parse() from JavaScript

<annevk> E.g. xhr.responseType = "json"; alert(xhr.response) when you load a resource that contains "false" should give the false value

DKA: So is that interop point something the WG has looked at?

TB: Not as such, no. There are lots of JSON parsers in lots of languages, and they seem to interoperate well

<annevk> It seems if you load such a document in Python that ought to work too

<slightlyoff> twbray, what was the consensus about?

MM: We did discuss expanding the top-level constraint, but since there are parsers [?] which have a problem with that, we didn't make a change there

JT: Is this similar to the kind of issue with HTML where the main HTML spec. describes all sorts of strings which masquerade as HTML, because that's what browsers need to do, but the TAG argued for an authors' spec, to describe what should be produced for best interop
... Is this the same issue? Is the ECMA404 language the broader one, and the 4627bis one the author's spec?

DC: No, it's not like that

<slightlyoff> is this about using the word "JSON" vs. saying "IETF is spec-ing a subset with the following constraints..."?

TB: 4627bis says things such as "if there are no duplicate keys, you will achieve good interop, whereis if you have duplicate keys, the following interop problems have been observed"

<slightlyoff> twbray, is that the extent of the subsetting?

<twbray> Recommend you guys read the IETF draft.

<slightlyoff> twbray, if so...could we just put that language into one of the other specs?

DKA: Is there something to be done to improve the interop issue?

DC: I don't see an interop problem

<slightlyoff> here's my worry: we're going to have multiple specs that say mostly the same things, distinguished by non-normative language...why do we have that then?

<dka> Alex, can you clarify "non-normative language"?

<slightlyoff> dka, so ISTM that this isn't about the grammar, it's about the advice to users

<annevk> Well the grammar is different between Ecma and IETF

<annevk> So if Python follows IETF they can't parse all the things XHR can

<annevk> Unless Python implements some XHR bindings... but that'd be sad for different reasons

TBL: If two different implementations do two different things with the same document, expectations may be confounded
... E.g. if someone uses append to override earlier keys, but this doesn't always have that effect, there is a security risk

TB: Precisely -- that's why the IETF draft points out this kind of problem

TBL: So it would be nice to have a kind of JSON-strict which would avoid these pitfalls

TB: We have discussed going further to produce something along those lines, but not yet on the table

<twbray> There have been proposals to produce something called I-JSON which has MUST NOTs for all the interoperability problems, i.e. no dupe keys, no broken Unicode.

MM: Our charter is restricted to updating 4627, so such work would only come later -- please join us if you'd like to help with that in due course

AvK: If the grammar is different between 404 and 4627bis, then following one vs. the other will produce different behaviour, for example with the 'false' document.
... The Web Platform specs will be following ECMA404 here

TB: 4627 requires the top-level to be an array or a list, and some implementations enforce that restriction

AvK: ECMA404 only requires a value

AR: Now that there's an [scribe missed]

<JeniT> bottom line is that having two specs for the same thing sucks for everyone

<slightlyoff> JeniT, but it seems like we're gonna have that, regardless of the mimetype def location in this case

<JeniT> yes

<annevk> JeniT, W3C could take some lessons there too

<slightlyoff> JeniT, so while I agree, I'm not sure how we get either ECMA or IETF to say "cool...it's theirs instead"

HST: It is now entirely possible for ECMA to submit a registration for application/json, referring to ECMA404, but there is already an IETF WG chartered to do just that, namely the JSON WG, and having two competing attempts to register a media type is a bad thing.

TBL: I really don't like the situation where it's necessary to have a media type registration document which is separate from the language definition

<twbray> nb: There have been proposals for JSON fragment ids

TBL: So I would like to see the original ECMA spec. submitted to the IETF -- better practice

DKA: Is there an opportunity to introduce more of a normative reference from 4627bis to ECMA404?

TB: Why would this be a benefit to readers? Why should they have to go somewhere else?

<twbray> Why would that be of benefit to users? Everyone agrees on the syntax, so why send them off somewhere else to read something else?

<annevk> twbray, euhm, we just explained that we don't agree on syntax

PLH: Having the media type registration as part of a W3C spec. is now our preferred pattern, and IANA is happy with it

<annevk> +1 to that

<twbray> The IETF draft notes specifically that the ECMA draft allows top-level primitive types

<annevk> twbray, acknowledging something in an introduction doesn't indicate agreement in my book

<annevk> twbray, reads more like "yeah, these guys defined x, but it's really y, trust us"

AR: DC, both the ECMA process and the IETF process, were started by you, which one would you choose if you could?

DC: I'd prefer ECMA, I understood the process

AR: What about the documents?

DC: I gave you my preference

DC: I didn't have the number of years of experience apparently necessary to understand the IETF process

DKA: That's true in my experience across many organisations

<JeniT> can we identify and list the interoperability problems between the two specs?

<annevk> JeniT, is there a point?

<JeniT> annevk, to aim to move the specs closer

<annevk> JeniT, hah

DKA: Is there anything we can do to help reconcile this apparent conflict?

DKA: From an IETF/TC39/W3C love-in perspective

DC: I'd like to see 4627bis cite ECMA404 as a normative reference

TB: So people have to read one to understand the other

DC: Yes, 404 is the definitive definition

TBL: It settles the question of who has design authority
... Who do you go to if you have questions, or want changes

TB: The good news is that the only difference between any of the existing specifications of JSON is the top-level production

DC: 404 only talks about one aspect of JSON, and that's the grammar
... It should be the one that all other documents refer to

DKA: I think the TAG consensus is in line with that
... Maybe we leave that there, and we have the opportunity to make our voices known to that effect as part of the IETF Last Call process. How quickly do we have to move to do that?

<slightlyoff> one resolution to the implicit tension would be a commitment for no future normative incompatibilities

<annevk> twbray, you also don't override the ABNF default of being 7-bit it seems

<annevk> twbray, seems like a pretty big hole, am I missing something?

<twbray> hm, sounds like a bug (fortunately not one that has produced any interop problems that I'm aware of)

MM: We're not quite to IETF LC yet, we're waiting on our Area Director to make that move, but he's travelling right now

MM: You are indeed welcome to join json@ietf.org to give input

DKA: Would next week be time enough? How fast are things moving?

MM: Next IETF f2f is 3--8 November, so ADs are trying to get documents moved forward, so the earlier the better

<slightlyoff> I'm deeply uncomfortable with the current situation.

<JeniT> slightlyoff, +1

<slightlyoff> it seems like a recipe for incompat

<slightlyoff> if not now, in the future

<twbray> Well, except for, in practice jSON interoperates beautifully in practice

<twbray> annevk - help me out, where's the 7-bit issue?

<annevk> twbray, JSON consists of a sequence of code points

<annevk> twbray, you define it as a sequence of 7-bit thingies...

<twbray> Sorry, where is that 7-bit constraint?

<annevk> twbray, http://tools.ietf.org/html/rfc5234

<annevk> twbray, your dependencies

<annevk> twbray, nobody will trip over this in practice (I hope!), but it's not correct

DKA: Alex, final words?

AR: This may be unintended consequences, AvK has spotted some incompatibilities, but without a normative sitation from one doc to the other, or at least a binding commitment to ensure consistency wrt their normative bits, the situation is not acceptable.

AR: I'd like to have TC39 and the IETF WG agree to negotiate this, because without agreement we are headed in the long haul for an untenable situation

AvK: I don't see the point in two specs -- let Ecma do the mime type registration and leave it at that

PLH: This is to some extent an issue between IETF and ECMA, but W3C has to live with the result, and one document would be better than two

DKA: Thanks to all, I'm hopeful going forward