- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Tue, 05 Nov 2013 16:34:01 +0000
- To: www-tag@w3.org
We had several visitors for this meeting, which focussed on questions
around the question of standarisation of JSON. These minutes were
delayed in order to give those visitors a chance to review them, but
are now available online at
http://www.w3.org/2001/tag/2013/10/17-minutes.html
and below in text form.
Discussion of possible next steps can be found in a thread [1]
starting the same day on this mailing list.
ht
[1] http://lists.w3.org/Archives/Public/www-tag/2013Oct/0029.html
-----------
- DRAFT -
Technical Architecture Group Teleconference
17 Oct 2013
Attendees
Present
Daniel Appelquist, Tim Bray, Doug Crockford, Tim Berners-Lee,
Sergey Konstantinov, Yves Lafon, Philippe Le Hegaret, Peter
Linss, Matt Miller, Alex Russell, Wendy Seltzer, Jeni Tennison,
Henry S. Thompson, Anne van Kesteren
Absent
Yehuda Katz
Chair
Daniel Appelquist
Scribe
Henry S. Thompson
Contents
* [2]Topics
1. [3]JSON liaison
__________________________________________________________________
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
[4]ECMA TC39 and the [5]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: [6]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:
[7]https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.sec
tion.1.2
<twbray> Introduction to This Revision:
[8]https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.sec
tion.1.3
<twbray> Appendix A. Changes from RFC 4627:
[9]https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.app
endix.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:
[10]http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-4
04.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
([11]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, [12]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
__________________________________________________________________
Minutes formatted by David Booth's [13]scribe.perl version 1.135
([14]CVS log)
$Date: 2013-10-21 13:09:06 $
References
1. http://www.w3.org/
2. http://www.w3.org/2001/tag/2013/10/17-minutes.html#agenda
3. http://www.w3.org/2001/tag/2013/10/17-minutes.html#item01
4. http://www.ecma-international.org/memento/TC39.htm
5. https://datatracker.ietf.org/wg/json/
6. http://tools.ietf.org/html/rfc4627
7. https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.section.1.2
8. https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.section.1.3
9. https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-06.html#rfc.appendix.A
10. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
11. http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06
12. http://tools.ietf.org/html/rfc5234
13. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
14. http://dev.w3.org/cvsweb/2002/scribe/
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Tuesday, 5 November 2013 16:34:25 UTC