Subject: Re: [Json] Normative reference reasoning and logistics

From: Stefan Hagen <[email-masked]>
Date: Sun, 1 May 2016 10:59:18 +0200

On 2016-APR-28 at 19:06 in some TZ Joe Hildebrand (jhildebr) wrote:
> Going back to an earlier point in the thread:
>
> On 11/14/15, 11:10 AM, "Tim Bray" <[email-masked]> wrote:
>
>> So, is there a *real* reason why a normative reference might be useful? I think there might be, and it's purely rhetorical (in the formal sense, designed to support an argument): To make it clear to the world
>> that all JSON is the same JSON no matter where it's specified.  So I think it would be plausible to add the following to the second paragraph of section 1.2 of 7159 (for convenience:
>> http://rfc7159.net/rfc7159#rfc.section.1.2 ):
>>
>> “The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term “JSON text” in any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability.”
>
> I like this text a lot.  Adding a few more points would be useful, I believe:
>
> - The intent is that the grammar is the same between the two documents, although different descriptions are used.  If there a difference is found between them, ECMA and the IETF will work together to update both documents.
>
> - If an error is found with either document, the other should be examined to see if it has a similar error, and fixed if possible.
>
> - If either document is changed in the future, ECMA and the IETF will work together to ensure that the two documents stay aligned through the change.
>
>
> There is liaison work to do to ensure that ECMA-404bis has similar language, but I wouldn't have any problem with us publishing a 7159bis draft that included language like this before ECMA is fully onboard.

I like the proposed text with the ammendment from Joe.
This includes the need for ensuring liaison work and the possibility to 
first include this text and second initiate the ongoing liaison work.

Best,
Stefan.
-- 
Stefan Hagen
read://hagen.link
talk://eventually

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 1 May 2016 14:14:44 +0200

IMO, ES6's JSON serialization scheme will likely be way more significant than ECMA-404
(which I believe very few application developers have bothered looking into).

Anders

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 1 May 2016 21:22:49 +0900

> (which I believe very few application developers have bothered looking

Hello Anders,

Can you provide some background? Is "ES6's JSON serialization scheme" a 
separate format, with changes from ECMA-404?

Or are you just saying that the IETF better point to "ES6's JSON 
serialization scheme" than ECMA-404? I guess we should do that if that's 
what ECMA wants, but your "will likely be" doesn't really sound very 
definitive yet.

Regards,   Martin.

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 1 May 2016 14:36:38 +0200

>> (which I believe very few application developers have bothered looking

Hello Martin,

First off I don't see the point with having multiple organizations specifying
the JSON core format.  AFAIK, JSON started its life as RFC4627 which later was
upgraded by RFC7159.  That is, ECMA-404 can safely be ignored.

My reference to ES6 is not related to the JSON format, but how JSON parsers
and serializers could (IMO SHOULD) be implemented in order to offer maximum
interoperability as well as supporting digital signatures in a human-friendly way:
https://cyberphone.github.io/openkeystore/resources/docs/jsonsignatures.html

Anders

---

From: Tim Bray <[email-masked]>
Date: Sun, 1 May 2016 13:58:06 -0700

Never seen anything quite like this in an RFC, but it doesn’t feel crazy or
damaging.

I share the opinion expressed by others here that ECMA-404 is largely
ignored and of marginal relevance, but I gather there’s a perceived benefit
in establishing that ECMA & IETF are in sync on this subject.

On Thu, Apr 28, 2016 at 10:06 AM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> >So, is there a *real* reason why a normative reference might be useful? I
> think there might be, and it's purely rhetorical (in the formal sense,
> designed to support an argument): To make it clear to the world
> > that all JSON is the same JSON no matter where it's specified.  So I
> think it would be plausible to add the following to the second paragraph of
> section 1.2 of 7159 (for convenience:
> >“The reference to ECMA-404 in the previous sentence is normative, not
> with the usual meaning that implementors need to consult it in order to
> understand this document, but to emphasize that there are no
> inconsistencies in the definition of the term “JSON text” in any of its
> specifications. Note, however, that ECMA-404 allows several practices which
> this specification recommends avoiding in the interests of maximal
> interoperability.”
>
> - The intent is that the grammar is the same between the two documents,
> although different descriptions are used.  If there a difference is found
> between them, ECMA and the IETF will work together to update both documents.
>
> - If an error is found with either document, the other should be examined
> to see if it has a similar error, and fixed if possible.
>
> - If either document is changed in the future, ECMA and the IETF will work
> together to ensure that the two documents stay aligned through the change.
>
>
> There is liaison work to do to ensure that ECMA-404bis has similar
> language, but I wouldn't have any problem with us publishing a 7159bis
> draft that included language like this before ECMA is fully onboard.
>
> --
> Joe Hildebrand
>
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

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

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 2 May 2016 08:18:36 +0900

Just for the record, I also agree with Joe's text proposal.

Regards,   Martin.

---

From: "Manger, James" <[email-masked]>
Date: Mon, 2 May 2016 09:19:24 +1000

Sounds more harmful than helpful to again change the RFC number that defines JSON — rfc4627, rfc7158, rfc7159, rfcXXXX — for what is supposed to be a simple and stable format.
Stick the text in as an errata marked “held for document update”; or stick it in its own RFC that updates rfc7159 (bit weird?); or in a liaison note to ECMA.

--
James Manger

From: json [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Monday, 2 May 2016 6:58 AM
To: Joe Hildebrand (jhildebr) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Json] Normative reference reasoning and logistics

Never seen anything quite like this in an RFC, but it doesn’t feel crazy or damaging.

I share the opinion expressed by others here that ECMA-404 is largely ignored and of marginal relevance, but I gather there’s a perceived benefit in establishing that ECMA & IETF are in sync on this subject.

On Thu, Apr 28, 2016 at 10:06 AM, Joe Hildebrand (jhildebr) <[email-masked]<mailto:[email-masked]>> wrote:
Going back to an earlier point in the thread:

--
Joe Hildebrand

_______________________________________________
json mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/json

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

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 2 May 2016 16:17:43 +0000

If we did this, then we would have to talk the IESG into applying an STD number to RFC 7159 with known errata, or give up on JSON becoming a full Internet Standard.  In my opinion, it's worth changing the RFC number again.

-- 
Joe Hildebrand

On 5/1/16, 5:19 PM, "Manger, James" <[email-masked]> wrote:

>Sounds more harmful than helpful to again change the RFC number that defines JSON — rfc4627, rfc7158, rfc7159, rfcXXXX — for what is
> supposed to be a simple and stable format.
>On Thu, Apr 28, 2016 at 10:06 AM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
>
>>“The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term “JSON text”
> in any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability.”
>
>https://keybase.io/timbray <https://keybase.io/timbray>)
>
>
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 May 2016 18:28:02 +0200

> If we did this, then we would have to talk the IESG into applying an STD number to RFC 7159 with known errata, or give up on JSON becoming a full Internet Standard.  In my opinion, it's worth chang…

...we have errata to apply anyway, right?

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 2 May 2016 16:40:06 +0000

> On May 2, 2016, at 10:28, Julian Reschke <[email-masked]> wrote:
> 

Yes, there are four errata that are either "Verified" or "Held for Document Update":

< https://www.rfc-editor.org/errata_search.php?rfc=7159&rec_status=15&presentation=table >

--
- m&m

Matt Miller
Cisco Systems, Inc.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 May 2016 12:45:55 +1000

> On 3 May 2016, at 2:17 AM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
> 

For better or worse, that's how things work. If we stop progressing documents to get stable RFC numbers, something's really broken. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 9 May 2016 15:55:40 +0000

Hello all,

It appears we have rough consensus to include a combination of the following text suggested by Tim Bray:

    The reference to ECMA-404 in the previous sentence is normative,
    not with the usual meaning that implementors need to consult it
    in order to understand this document, but to emphasize that there
    are no inconsistencies in the definition of the term “JSON text”
    in any of its specifications. Note, however, that ECMA-404 allows
    several practices which this specification recommends avoiding in
    the interests of maximal interoperability.

With these additional points suggested by Joe Hildebrand:

    - The intent is that the grammar is the same between the two
      documents, although different descriptions are used.  If there a
      difference is found between them, ECMA and the IETF will work
      together to update both documents.

    - If an error is found with either document, the other should be
      examined to see if it has a similar error, and fixed if possible.

    - If either document is changed in the future, ECMA and the IETF will
      work together to ensure that the two documents stay aligned through
      the change.

If there are no objections, then Tim and Joe can finalize the text and include it with the next revision to draft-ietf-jsonbis-rfc7159bis.

Thank you,

- JSON Chair

---

From: Tim Bray <[email-masked]>
Date: Thu, 12 May 2016 22:11:54 -0700

Will do.

On Mon, May 9, 2016 at 8:55 AM, Matt Miller (mamille2) <[email-masked]>
wrote:

> If there are no objections, then Tim and Joe can finalize the text and
> include it with the next revision to draft-ietf-jsonbis-rfc7159bis.
>
>
> Thank you,
>
> - JSON Chair
>