W3C home > Mailing lists > Public > www-tag@w3.org > November 2013

Re: Final Proposed Text for Liaison to IETF re: JSON

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 20 Nov 2013 15:18:00 -0800
Message-ID: <CANr5HFXWRg+PytVeSLi4sAEoD-iqtCYonTFS0DoZQZmxn5RAZg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Appelquist Daniel <Daniel.Appelquist@telefonica.com>, www-tag <www-tag@w3.org>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, "wseltzer@w3.org" <wseltzer@w3.org>, "plh@w3.org" <plh@w3.org>
Same.

I'm also working with TC39 this week to get a statement from the ECMA side
ASAP.


On Wed, Nov 20, 2013 at 2:50 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 21/11/2013, at 12:49 AM, Appelquist Daniel (UK) <
> Daniel.Appelquist@telefonica.com> wrote:
>
> > Please see below for some final proposed text for a liaison statement to
> > IETF regarding the issues we are discussing with JSON, as proposed by
> Mark
> > Nottingham last week.  Thanks to Tim Bray and Martin Dürst for the
>
> Well, I said it was one of your options...
>
> > feedback which I think I’ve addressed.  Let’s agree the final wording on
> > tomorrow’s TAG call after which I propose that we request the W3C liaison
> > (Wendy and / or Philippe) to ship to over to IETF (in addition to the
> > substantive cross-posted discussion currently going on).
> >
> > Thanks,
> > Dan
> >
> > --
> > The W3C Technical Architecture Group has a concern regarding the ongoing
> > coordination of the industry standardization work on JSON.  JSON is a key
> > integration technology for Web applications and a key data interchange
> > format for the Web.  The current state of affairs, where there are now
> two
> > different JSON specifications which may be normatively referenced, one
> > developed in ECMA as ECMA-404 and one developed in IETF as RFC-4627 and
> in
> > last call as RFC-4627bis is not ideal and could lead to confusion in the
> > industry.  We believe that this could  lead to interoperability issues.
> > Because the two specs vary slightly, we believe this could lead to
> > interoperability issues.
> >
> > For example, today there are JSON parsers (conforming to ECMA-404) that
> > can parse "42" (a JSON document consisting of a single integer). There
> are
> > also parsers (conforming to RFC 4627/draft-ietf-json-rfc4627bis-07) that
> > cannot parse "42" today, but they can be meaningfully upgraded to do so
> > too. This would not break applications using those parsers, unless they
> > depend on parsing "42" as an error, which is a far more unlikely scenario
> > than parsing it as 42 given precedence.
> >
> > Regardless of the historical reasons for the current situation, the W3C
> > TAG believes that having one definition of JSON would be beneficial for
> > the Web and for the wider community of JSON implementors and JSON
> > consuming and producing applications.  We suggest that the IETF JSON
> > working group should re-enter discussions with ECMA TC39 in order to
> > facilitate aligning RFC-4627bis with the current ECMA-404 specification.
>
> This looks like a good expression of the concerns in the discussion I
> heard.
>
> Cheers,
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>
Received on Wednesday, 20 November 2013 23:18:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC