Subject: Re: [Json] Kicking Off JSONbis

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Oct 2015 14:54:13 -0400

> I must admit that I am puzzled as to how ECMA-404 can be a normative
> reference for any document that is a minor change from rfc7159.  What in
> ECMA-404 is needed to understand or implement what is in rfc7159?

Rob has it nailed in his message:
"To me, it seems like a political or diplomatic gesture that helps the
Internet to move forward.

"Framing it in technical or standards-wonk terms seems counterproductive.
I don't think there are substantive issues in those areas that would be
resolved by objecting to the plan in the charter."

That really is the point: tying the two documents together more tight,
to make people more comfortable that they are not likely (certainly
not intended) to diverge later.

> As has been stated, rfc7159 already references ECMA-404.  A conservative way
> to make a closer connection from rfc7159 to ECMA-404 would be to state that
> ECMA-404 has an alternative description of JSON that is extremely close to
> the definition in rfc7159.

Such a statement would, indeed, be an excellent one to put into 7159bis.

Barry, responsible AD

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 1 Oct 2015 13:47:44 -0700

On 10/01/2015 11:54 AM, Barry Leiba wrote:
> not intended) to 

further (?)

> diverge later.

peter

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 Oct 2015 07:03:31 -0700

> In a nutshell, the goal of this effort is to produce a bis to 7159 that:
>
> * promotes JSON to IETF Internet Standard
> * references ECMA-404 and is a reference for ECMA-404
>
> Tim Bray has agreed to edit 7159bis.
>
> As a start, I propose we start with rfc7159 and:
>
> 1) Apply verified errata from < https://www.rfc-editor.org/errata_search.php?rfc=7159 >
> 2) Change the reference to ECMA-404 from informative to normative

Can we get a first version of this before the I-D cutoff for Yoko
(this coming Monday, 19 Oct)?

Barry

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Oct 2015 21:02:50 -0700

Sure, but isn’t a consensus call on the substantive change to the spec in
order?

On Tue, Oct 13, 2015 at 7:03 AM, Barry Leiba <[email-masked]>
wrote:

> > 1) Apply verified errata from <
> https://www.rfc-editor.org/errata_search.php?rfc=7159 >

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Oct 2015 00:22:29 -0400

>> > https://www.rfc-editor.org/errata_search.php?rfc=7159

That could be done by posting an I-D to make the proposal, and have
the working group review it and comment on it.  Right now, there's
just a "here's what we plan to do", and there've been a few comments
about that.  Specific text to review might help, no?

Barry

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 14 Oct 2015 07:39:43 +0200

I'm obviously "somewhat" biased but how about evaluating my proposal which addresses
two entirely different topics:

- The ability to sign JSON objects in a way that mimics XML DSig but without bringing
   in a complex canonicalization scheme
- Predictive serialization which most developers are likely to appreciate

Note: There's no need defining a specific signature scheme, it is enough creating a
foundation for such work.

https://mailarchive.ietf.org/arch/msg/json/wfyXZ6mzDwQqVMUw-UT_-L1fhQU

JWS will be a hard sell to the business community who are slowly but surely converting
from XML and EDI to JSON.  They shouldn't have to develop their own JSON standards!

Cheers,
Anders Rundgren

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2015 09:43:25 +0200

On 2015-10-14 06:02, Tim Bray wrote:
> Sure, but isn’t a consensus call on the substantive change to the spec
> in order?

Right. As far as I recall, there was little (or no?) support for the 
reference change. I believe we should discuss it here *before* making a 
change in the draft.

Best regards, Julian

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 14 Oct 2015 15:26:31 +0000

> from XML and EDI to JSON.  They shouldn't have to develop their own JSON standards!

The WG's charter is very constrained, and these are not in scope.

--
- m&m

Matt Miller <[email-masked]>
Cisco Systems, Inc.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 14 Oct 2015 15:37:40 +0000

> On Oct 13, 2015, at 22:22, Barry Leiba <[email-masked]> wrote:
> 

RFC 7159 has the following verified errata:

* https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=3915
* https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4264
* https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4336

I suggest at the least an I-D be published that applies these.

--
- m&m

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Oct 2015 12:10:01 -0400

> I suggest at the least an I-D be published that applies these.

That works for me.

As to the other, specific text proposed on the list will give people
something to discuss.

Barry

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Oct 2015 11:05:15 -0700

On the off-chance anyone is listening: The second erratum is a correction
to a couple of errata references.  But I'd have thought that 7159bis should
really only have references to errata post-7159.  Pardon the extreme
editorial wonkery.

On Wed, Oct 14, 2015 at 8:37 AM, Matt Miller (mamille2) <[email-masked]>
wrote:

> in

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Oct 2015 11:34:54 -0700

[I'll post a 7159bis with errata by end-of-day whether I get an answer on
the errata-wonkery or not.  Now, returning to the meat of the discussion.]

I have really major heartburn with introducing a Normative Reference to
ECMA404 in 7159bis.  Because language in standards documents should be used
carefully, and “Normative Reference” has a very specific meaning, and that
meaning clearly does not apply in this case.  However, since there is
apparently a feeling that there is some benefit to the community in
achieving “standards harmony”, let me propose three ways forward:

1. Include a normative reference to ECMA404, but accompany it with text
explaining that this reference is marked normative because it is considered
authoritative in the community of JavaScript language specifiers, not in
the normal sense of “normative”; there is no necessity to read it in order
too understand or implement RFC7159bis, nor does it specify any technology
which must be present in an implementation that is not also described in
7159bis.”

2. Do not include a normative reference, but expand the note about ECMA404
in Section 1.2 to emphasize that ECMA404 may be considered authoritative in
the community of JavaScript implementers.

3. Conclude that this effort has no observable benefit to the community
implementing JSON on the Internet and abandon the RFC7159bis project.

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Sun, 18 Oct 2015 12:22:21 -0700

You are echoing my sentiments.

I vote for something along the lines of option 2.  (I would really like to
vote for 3, but standards harmony does indeed have some benefit.)

The other option would be to make all the language definition stuff in
RFC7159bis informative and point to ECMA404 for the normative definition.
However, this option has the added problem that the language definition in
ECMA404 depends on an undefined formalism.

peter

On 10/18/2015 11:34 AM, Tim Bray wrote:
> [I'll post a 7159bis with errata by end-of-day whether I get an answer on the
> errata-wonkery or not.  Now, returning to the meat of the discussion.]
> 
> apparently a feeling that there is some benefit to the community in achieving
> “standards harmony”, let me propose three ways forward:
> 
> authoritative in the community of JavaScript language specifiers, not in the
> normal sense of “normative”; there is no necessity to read it in order too
> understand or implement RFC7159bis, nor does it specify any technology which
> must be present in an implementation that is not also described in 7159bis.”
> 
> 2. Do not include a normative reference, but expand the note about ECMA404 in
> Section 1.2 to emphasize that ECMA404 may be considered authoritative in the
> community of JavaScript implementers.
> 
> On Wed, Oct 14, 2015 at 9:10 AM, Barry Leiba <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Rob Sayre <[email-masked]>
Date: Sun, 18 Oct 2015 15:11:41 -0700

>  “Normative Reference” has a very specific meaning, and that meaning
clearly does not apply in this case.

That conclusion is not clear to me. Can you explain?

- Rob

On Sun, Oct 18, 2015 at 11:34 AM, Tim Bray <[email-masked]> wrote:

> too understand or implement RFC7159bis, nor does it specify any
> technology which must be present in an implementation that is not also
> described in 7159bis.”
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 19 Oct 2015 00:23:58 +0200

> That conclusion is not clear to me. Can you explain?

I'll leave explaining the conclusion to Tim, but here is the premise:

https://www.ietf.org/iesg/statement/normative-informative.html

In particular: "Normative references specify documents that must be read
to understand or implement the technology in the new RFC, or whose
technology must be present for the technology in the new RFC to work."

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Oct 2015 16:32:45 -0700

Thanks, Carsten. My belief is that ECMA404 meet neither of those criteria.

I also believe, based on prior conversation, that the goal of this WG has
nothing to do with with changing the meaning of RFC7159, but rather is
aimed at “standards harmonization”. While I’m unconvinced of the benefits,
if there’s IETF consensus behind such harmonization, I wouldn’t stand in
the way.  But I would hope that there’s a better way to achieve it than
with a flagrantly bogus normative reference.  And I’ve suggested a couple.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 19 Oct 2015 10:01:41 +0900

I'd be fine with 1.

I agree that strictly speaking, it doesn't meet the criteria for a 
normative reference. But then, I don't know of anybody who would just go 
ahead and read straight through all the normative references when 
implementing a spec; in some cases, it may be a single paragraph or 
subsection that makes a reference normative, so selecting what you read 
is the default (unless the default is "look only at the examples and 
hack something up, and reading some part of normative references is 
anyway useless because thoroughly reading the spec at hand is too much 
work in the first place).

There's one condition, namely that this is reciprocal (i.e. that ECMA 
also uses a normative reference), but as far as I understand, that's 
part of the plan, or not?

Regards,   Martin.

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Oct 2015 19:49:22 -0700

It’s not letting me submit the draft because it claims that:
============
JavaScript Object Notation
Group exists but is not an active group
============
I’ve uploaded the XML & txt & HTML to http://www.tbray.org/ietf/7159bis/ -
if someone else knows how to work around this go ahead, otherwise I could
upload it as an individual submission.

---

From: Rob Sayre <[email-masked]>
Date: Sun, 18 Oct 2015 20:13:36 -0700

> with a flagrantly bogus normative reference.  And I’ve suggested a couple.

ECMA404 should be a normative reference.

- Rob

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 19 Oct 2015 13:16:40 +0900

Hello Tim,

I suggest to send it directly to the relevant mail address 
([email-masked], see https://datatracker.ietf.org/submit/), 
i.e. to use the old way of submission. In your mail, explain the 
circumstances and cc. the chairs and Barry (AD). Submissions per mail 
are still accepted, and are handled manually, so this should work (as 
long as you stay within the deadline and Barry confirms).

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Oct 2015 09:49:18 +0200

On 2015-10-18 20:34, Tim Bray wrote:
> [I'll post a 7159bis with errata by end-of-day whether I get an answer
> on the errata-wonkery or not.  Now, returning to the meat of the
> discussion.]
>
> ECMA404 in 7159bis.  Because language in standards documents should be
> used carefully, and “Normative Reference” has a very specific meaning,
> and that meaning clearly does not apply in this case.  However, since

Exactly.

> there is apparently a feeling that there is some benefit to the
> community in achieving “standards harmony”, let me propose three ways
> forward:
>
> explaining that this reference is marked normative because it is
> considered authoritative in the community of JavaScript language
> specifiers, not in the normal sense of “normative”; there is no
> necessity to read it in order too understand or implement RFC7159bis,
> nor does it specify any technology which must be present in an
> implementation that is not also described in 7159bis.”

Sounds good, but we'd probably also have to talk about what it would 
mean should both documents disagree.

> 2. Do not include a normative reference, but expand the note about
> ECMA404 in Section 1.2 to emphasize that ECMA404 may be considered
> authoritative in the community of JavaScript implementers.

Works for me as well.

> implementing JSON on the Internet and abandon the RFC7159bis project.

I believe it's worthwhile to apply *other* errata and publish as full 
standard, even if we can't achieve "harmony" with ECMA404.

 > ...

Best regards, Julian

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Mon, 19 Oct 2015 02:51:05 -0700

On 10/18/2015 08:13 PM, Rob Sayre wrote:
> On Sun, Oct 18, 2015 at 4:32 PM, Tim Bray <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Please explain your reasoning behind this.  Do you believe that ECMA404 meets
the technical requirements for being a normative reference for RFC7159bis?

peter

>     On Sun, Oct 18, 2015 at 3:23 PM, Carsten Bormann <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Rob Sayre wrote:
>         [email-masked] <mailto:[email-masked]>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 19 Oct 2015 14:21:42 +0200

It is a bit sad that you are more interested in solving a problem that
maybe only 0.001% of the development community is likely to know about,
when the JSON tool feature "Predictive Serializing" is fairly easy to
find requests for, in addition to addressing "Signed JSON" in a more
useful way than the ugly hack the JOSE WG is currently adding to JWS
(due to the obvious push-back on dressing everything in Base64).

Anders

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sat, 31 Oct 2015 02:42:49 +0000

(Sorry I didn't get to this until now)

>technology must be present for the technology in the new RFC to work."

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.

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.

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.

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:

"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."

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

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 Oct 2015 11:57:39 +0900

I like that approach.

Grüße, Carsten