Subject: [Json] Benoit Claise's No Objection on charter-ietf-json-00-01: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 16 May 2013 01:28:58 -0700

Benoit Claise has entered the following ballot position for
charter-ietf-json-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Probably a detail, but it puzzles me. Maybe I read too much into this...

"Any changes that break compatibility with existing implementations of
either RFC 4627 or
the ECMAScript specification will need to have very strong justification
and broad support."

Versus 

"Any changes that break compatibility with the RFC 4627 or
the ECMAScript specifications will need to have very strong
justification
and broad support."

Is this intentional that you mention the existing implementations of RFC
4627?
Do you expect discrepancies between the "existing implementations of RFC
4627" and the "RFC 4627 specifications" (and ECMAScript specification
btw)?
The way it's written implies that the existing implementations are the
reference versus the specifications.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 May 2013 15:02:39 +0100

> Probably a detail, but it puzzles me. Maybe I read too much into this...

I think you are.

> Is this intentional that you mention the existing implementations of RFC

Yes.

Consider that this is an essentially similar situation to what we had
in going from PS to DS... except here we're going from Informational
to PS.  The point, though, is that we have a mature protocol that's
moving in the Standards Track (here, *into* the Standards Track).  The
justification required for a change increases with the level of
disruption it would cause to what's out there.

Errata are easy.
Useful changes that are fully compatible with current implementations
are still easy; the conversation should be brief.
Important changes that break compatibility are still within scope, but
require a very strong justification, and will probably involve a lot
more discussion.

Your version (the second above) doesn't make much sense: changes to
the spec are changes to the spec.  The point is to consider the effect
those changes will have on implementations.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 May 2013 07:49:48 -0700

> 4627" and the "RFC 4627 specifications" (and ECMAScript specification

There are known discrepancies between RFC 4627 and ECMAScript, and some implementations rely on one versus the other. See <http://www.ietf.org/proceedings/86/slides/slides-86-json-2.pdf>, particularly slides 4 and 5.

--Paul Hoffman

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 May 2013 19:13:29 +0200

Ok, thanks Barry.

Regards, Benoit