Re: [Json] Differences between RFC 4627 or the current ECMAScript specification

So, I (blush) confess to never having read ECMA-262, which is what 4627
references.  I thought I’d have a glance; I'm assuming that what I want is:
http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf

It turns out to be nontrivial to isolate the diffs between it and 4627; to
start with, 262 does not contain any instances of either "JSON" nor "object
notation”.  I guess if you look at 11.1 and squint your eyes and ignore the
“this”, Identifier, and (Expression) variants, what’s left over might be
JSON more or less. Maybe.

So, since the spec is >150 pages, and I’m a JavaScript journeyman at best,
if there’s going to be a concise list of differences, someone who
understands that spec is going to have to write it, with references into
the spec.  I suggest that if we don’t get such a proposal, this is not a
fatal flaw in RFC4627bis because actually nobody cares.  If someone is
inclined to do the work, it would improve our charter conformance but I’m
not sure it would really add much practical value to the spec.

On Thu, Sep 26, 2013 at 11:36 AM, Paul Hoffman <paul.hoffman@vpnc.org>wrote:

> On Sep 26, 2013, at 10:31 AM, R S <sayrer@gmail.com> wrote:
>
> > Charter:
> > >
> > > All differences between RFC 4627 or the current ECMAScript
> specification > will be documented in the new RFC.
> >
> > The ECMAScript specification allows primitives at the root level,
> specifies exactly how to interpret numbers, and can handle " bit sequences
> which cannot encode Unicode characters" just fine.
>
> <no hat>
>
> Based on what we have learned in the last six months, it might be better
> for this RFC *not* to do what the charter says.
>
> - TC39 is actively revising ECMAScript and it is not clear whether the
> -bis draft of their version will be out first.
>
> - Some of what ECMAscript says about JSON is intertwingled with the
> definition of ECMAscript, such as "exactly how to interpret numbers"
>
> I'm no longer sure that a long-lasting RFC interpreting parts of another
> SDO's spec is a good idea.
>
> --Paul Hoffman
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>