Subject: [Json] REMINDER - WGLC Ends 2013-10-11

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 10 Oct 2013 03:21:11 +0000

A reminder that the current Working Group Last Call for draft-ietf-json-rfc4627bis officially ends on Friday, October 11.  Please provide any feedback as soon as you can, even if it's "the draft is good enough".

Thanks!

- Paul Hoffman and Matt Miller

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2013 01:41:41 -0000

This draft is ready to publish.  I have a few editorial comments,
none of which I think would be contentious.

Section 1.2 says:

   Object; thus, for example, "Hello world!", "42", and "true" would all
   be valid JSON texts in the ECMAScript 5.1 context.

My guess is that the quotes are intended to be part of "Hello world!"
but not part of 42 or true.  Dunno how to fix that other than perhaps
to display them, e.g.

   Object; thus, for example, these would all
   be valid JSON texts in the ECMAScript 5.1 context:

	"Hello world!"
	42
	true

Please move section 1.4, the list of changes, to the end.  I think
that most people will be more interested in the JSON spec rather
than the minutiae of what's changed.

Section 9 has some upper case MAY and some lower case.  It should
probably be consistent one way or the other.  I realize this is
currently unchanged from 4627.

In section 11, the Published specification should be this document,
not RFC 4627.  Since this is standards track, shouldn't the change
controller now be the IETF?

R's,
John

---

From: Tim Bray <[email-masked]>
Date: Thu, 10 Oct 2013 19:30:07 -0700

I’m OK with John’s changes, except for the MAY variation in section 9.  The
second half, with all the instances of lower-case “may”, is talking about
implementation behavior.  I had read it as advice for the reader as for
what implementations might do.  So turning those into MAY means that they
normatively describe behavior of conforming implementations.  Are we really
OK with that?  My instinct is that, since this spec has held together
pretty well all these years, why don’t we leave this alone?  -T

On Thu, Oct 10, 2013 at 6:41 PM, John Levine <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.21 (FreeBSD)
>
> iEYEARECAAYFAlJXV2oACgkQkEiFRdeC/kVapgCeIERm3QfwTBxFq5AxTmUpPKQT
> 85gAniYwpILyl3iYeppy1KW9VhmxINJR
> =8rQb
> -----END PGP SIGNATURE-----
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Oct 2013 19:33:27 -0700

<no hat>

On Oct 10, 2013, at 7:30 PM, Tim Bray <[email-masked]> wrote:

> I’m OK with John’s changes, except for the MAY variation in section 9.  The second half, with all the instances of lower-case “may”, is talking about implementation behavior.  I had read it as advice for the reader as for what implementations might do.  So turning those into MAY means that they normatively describe behavior of conforming implementations.  Are we really OK with that?  My instinct is that, since this spec has held together pretty well all these years, why don’t we leave this alone?  -T

Either is fine. The use of RFC 2119 MAYs are a humorously fertile flowerbed of contention.

--Paul Hoffman

---

From: John R Levine <[email-masked]>
Date: Thu, 10 Oct 2013 22:38:42 -0400 (EDT)

> pretty well all these years, why don’t we leave this alone?  -T

There is a somewhat theological argument that if you use 2119 language at 
all, the capital and lower case versions of the magic words are equally 
normative.  You could avoid that by writing around it, e.g.

    An implementation might set limits on the size of texts that it
    accepts.  An implementation might set limits on the maximum depth of
    nesting.  An implementation might set limits on the range and precision
    of numbers.  An implementation might set limits on the length and
    character contents of strings.

R's,
John

PS: There's another argument that since informational RFCs aren't 
normative, 4627 shouldn't have used 2119 language at all, but that horse 
is long since water under the barn.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 11 Oct 2013 14:06:38 -0700

Nothing earth shattering, I think the document can progress.  A few small
comments that might duplicate others peoples comments.  I am not wedded to
any of the comments, ignore if you don't care for them.

Jim

1.  It seems odd in Section 1 that a value is defined for object, but it is
not for array.  It might be better to move the definition of value in the
paragraph of what JSON can represent so it does not appear to be special for
object.

2.  In section 1.2, My reading of the following text ||"Hello world!", "42",
and "true"|| is that there are three strings here, but I think it was
supposed to represent a string, an number and a Boolean.  I am not sure how
to make this clearer, but killing the quotes on the last two items might be
reasonable.

3.  It seems a bit odd to title section 2 "Grammar" when it does not have
the entire grammar.  It also seems odd that the introduction paragraph talks
about things which are not in this section, but are in the following
sections.

4.  The following is technically a change in the grammar, however is there a
reason why an integer cannot be 00, but 1E00 is legal?  Do we want to change
the definition of the exponent so that it matches that of integer?

5.  There has been mention that one reason for using ABNF is that it can be
machine consumable, does it make any sense to create an appendix which has
the full grammar in it for simplicity of reference?

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 14:13:04 -0700

> paragraph of what JSON can represent so it does not appear to be special

Don’t get it, which para is that?  I’m looking at instances of “value” in
Section 1 and not seeing it.

> to make this clearer, but killing the quotes on the last two items might be

Yep, done.

> about things which are not in this section, but are in the following

Yeah,  the title should be “Tokens” or some such, but it’s survived all
these years without causing breakage, I think we can live with it.

> the definition of the exponent so that it matches that of integer?

Eeeek, please no.

> the full grammar in it for simplicity of reference?

Evidence suggests that people have no trouble constructing JSON parsers, so
probably not a huge ROI here.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 11 Oct 2013 23:28:47 +0200

>the definition of the exponent so that it matches that of integer?

In ecmascript a leading zero indicates an octal numeric literal. That
does not affect `00`, but `010 === 8` which is confusing and there is
no need for octal numbers in JSON. `1E00` is unambiguously decimal.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Oct 2013 23:29:19 +0200

On Oct 11, 2013, at 23:06, "Jim Schaad" <[email-masked]> wrote:

> reason why an integer cannot be 00, but 1E00 is legal? 

Many floating point formatters by default spit out something like 1.23e+08:

>> "%g" % 1.23e8
=> "1.23e+08"

>>> "%g" % 1.23e8
'1.23e+08'

#include <stdio.h>
int main() {printf("%g\n", 1.23e8); return 0;}
1.23e+08

We would make it harder*) to produce JSON for those implementations.

More importantly, there is lots of canned JSON out there that looks this way.

>  Do we want to change

Certainly not.

Grüße, Carsten

*) inspect.sub(/(e[+-])0+/) {$1}
(I happen to have written this line exactly two months ago as part of making some output bitwise identical with the output of some JavaScript code.)

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 11 Oct 2013 21:59:33 +0000

/me doffs hat

I think this document is ready for publication.  I have one very minor nit:

* 1.2. Specifications of JSON -- This section starts off with "A description of JSON in ECMAScript terms first appeared in version 5.1 of the ECMAScript specification [ECMA-262]...".  However, it actually was first introduced to ECMA-262 with 5th Edition.

If changing this is worthwhile, I would suggest that fragment change to "A description of JSON in ECMAScript terms exists in version 5.1 of the ECMAScript specification [ECMA-262]..."

- m&m

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

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 15:13:39 -0700

WFM

On Fri, Oct 11, 2013 at 2:59 PM, Matt Miller (mamille2)
<[email-masked]>wrote:

> * 1.2. Specifications of JSON -- This section starts off with "A
> description of JSON in ECMAScript terms first appeared in version 5.1 of
> the ECMAScript specification [ECMA-262]...".  However, it actually was
> first introduced to ECMA-262 with 5th Edition.
>
> If changing this is worthwhile, I would suggest that fragment change to "A
> description of JSON in ECMAScript terms exists in version 5.1 of the
> ECMAScript specification [ECMA-262]..."
>
>
> - m&m
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 11 Oct 2013 15:58:05 -0700

From: Tim Bray [mailto:[email-masked]] 
Sent: Friday, October 11, 2013 2:13 PM
To: Jim Schaad
Cc: JSON WG
Subject: Re: [Json] REMINDER - WGLC Ends 2013-10-11

Don’t get it, which para is that?  I’m looking at instances of “value” in Section 1 and not seeing it.

An object is an unordered collection of zero or more name/value

   pairs, where a name is a string and a value is a string, number,

   boolean, null, object, or array.

   An array is an ordered sequence of zero or more values

Value is explicitly set in the first paragraph, but is implicit in the second (or it flows from the first)..

---

From: Allen Wirfs-Brock <[email-masked]>
Date: Fri, 11 Oct 2013 16:00:48 -0700

We really should avoid having two (Ecma-404 and rfc4627bis) normative syntax specifications for JSON text.  Since it is claimed that the 4627bis ABNF recognizes the same language as that described by the Ecma-404 syntax diagrams it would seem more appropriate for 4627bis to narratively reference Ecma-404 and say that the 4627bis ABNF is an informative restatement of the Ecma-404 syntax specification. 

Notational preference really isn't a very good reason to have  two different normative definitions of the same thing. 

Allen Wirfs-Brock

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 16:07:06 -0700

Since the normative definitions are isomorphic, there is no benefit to the
reader in making them go somewhere else to discover what is already present
in this document, and that would be the only effect of removing the syntax
specification, especially since there is no intention anywhere that the
syntax ever change.  -T

On Fri, Oct 11, 2013 at 4:00 PM, Allen Wirfs-Brock <[email-masked]>wrote:

> We really should avoid having two (Ecma-404 and rfc4627bis) normative
> syntax specifications for JSON text.  Since it is claimed that the 4627bis
> ABNF recognizes the same language as that described by the Ecma-404 syntax
> diagrams it would seem more appropriate for 4627bis to narratively
> reference Ecma-404 and say that the 4627bis ABNF is an informative
> restatement of the Ecma-404 syntax specification.
>
> Notational preference really isn't a very good reason to have  two
> different normative definitions of the same thing.
>
> Allen Wirfs-Brock

---

From: Stefan Drees <[email-masked]>
Date: Sat, 12 Oct 2013 01:09:54 +0200

I think, the draft is good enough.

{"Stefan"}

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Oct 2013 01:19:21 +0200

On Oct 12, 2013, at 01:00, Allen Wirfs-Brock <[email-masked]> wrote:

> Notational preference

The ABNF actually means something.

If we were arguing this, I'd say that while the JSON grammar is simple enough that the racetracks (plus the explanatory text) should not be overly problematic, it would have been better if ECMA-404 had used them as illustrations only and referenced RFC 4627 for the normative grammar (as amended for the gratuitous change).

But since Tim is right, we don't need to argue this.

Grüße, Carsten

---

From: Stefan Drees <[email-masked]>
Date: Sat, 12 Oct 2013 01:32:02 +0200

+1 from me.

{"Stefan"}
On 2013-10-12 01:19 +02:00, Carsten Bormann wrote:
> If we were arguing this, I'd say that while the JSON grammar is
> simple enough that the racetracks (plus the explanatory text) should not be
> overly problematic, it would have been better if ECMA-404 had used them
> as illustrations only and referenced RFC 4627 for the normative grammar
> (as amended for the gratuitous change).
>
> Grüße, Carsten ...

---

From: Nico Williams <[email-masked]>
Date: Fri, 11 Oct 2013 19:16:44 -0500

> Since the normative definitions are isomorphic, there is no benefit to the

Ignoring the difference regarding top-level values, has this been shown?

If they are isomorphic, which ABNF definition is better, for any value
of "better" (subjective, objective under any specific criteria)?

Nico
--

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 19:06:13 -0700

> Ignoring the difference regarding top-level values, has this been shown?

Yes, there is a huge body of empirical evidence, namely the vast number of
JSON implementations which are observed to interoperate successfully.

> of "better" (subjective, objective under any specific criteria)?

I can’t think of any serious arguments in favor of the proposition that any
is qualitatively better than the others.  -T

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Oct 2013 22:24:52 -0400

I have one unanswered technical question from earlier, when I wrote:
> What I would suggest is that at the very least we understand the
> differences, so that we know what we're getting into. 
I think John Cowan answered this question in part in his mail of October
8th (Re: [Json] FYI ECMA, W3C, IETF coordination on JSON) by stating
that  ECMA 404 is pretty much RFC 4627.  Therefore, so long as we have
in the draft an accurate and up-to-date list of changes, then at least
we know if we are introducing interoperability problems.  Section 1.3
sort of does this, but should be cleaned up to be succinct and limited
to TECHNICAL changes ONLY.  Other changes should be moved to the back.

The key differences, therefore, are as follows:

  * No specific version of unicode.
  * Specific language on duplicate members
  * Discussion of character model
  * IEEE numbers and number  ABNF

Are those all the technical differences?

Eliot

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 19:34:35 -0700

Note that those differences are not *normative*; they are simply
explanations of which legal JSON idioms can increase the risk of
interoperability problems.  There remains no normative difference between
any of the flavors of JSON except that the ECMA specs don’t require
array/object at the top level.

On Fri, Oct 11, 2013 at 7:24 PM, Eliot Lear <[email-masked]> wrote:

> 8th (Re: [Json] FYI ECMA, W3C, IETF coordination on JSON) by stating that
> ECMA 404 is pretty much RFC 4627.  Therefore, so long as we have in the
> draft an accurate and up-to-date list of changes, then at least we know if
> we are introducing interoperability problems.  Section 1.3 sort of does
> this, but should be cleaned up to be succinct and limited to TECHNICAL
> changes ONLY.  Other changes should be moved to the back.
>
>    - No specific version of unicode.
>    - Specific language on duplicate members
>    - Discussion of character model
>    - IEEE numbers and number  ABNF
>
>
> json mailing [email-masked]://www.ietf.org/mailman/listinfo/json
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Oct 2013 20:00:01 -0700

<hat on>

On Oct 11, 2013, at 7:24 PM, Eliot Lear <[email-masked]> wrote:

> I think John Cowan answered this question in part in his mail of October 8th (Re: [Json] FYI ECMA, W3C, IETF coordination on JSON) by stating that  ECMA 404 is pretty much RFC 4627.  Therefore, so long as we have in the draft an accurate and up-to-date list of changes, then at least we know if we are introducing interoperability problems.  

There are no technical changes between RFC 4627 and this draft, other than the removal of the faulty sample regex in the Security Considerations.

There is one technical difference between RFC 4627 and ECMA-404: the definition of "JSON text" in section 1.2.

> Section 1.3 sort of does this, but should be cleaned up to be succinct and limited to TECHNICAL changes ONLY.  Other changes should be moved to the back.
> 
> 	• No specific version of unicode.
> 	• Specific language on duplicate members
> 	• Discussion of character model
> 	• IEEE numbers and number  ABNF

These are not technical differences between this draft and ECMAScript, nor between this draft and RFC 4627. They are helpful proposals to developers where none of the specs are clear enough to be sure.

--Paul Hoffman

---

From: John Cowan <[email-masked]>
Date: Fri, 11 Oct 2013 23:04:49 -0400

Jim Schaad scripsit:

> 4.  The following is technically a change in the grammar, however is
> there a reason why an integer cannot be 00, but 1E00 is legal?  Do we
> want to change the definition of the exponent so that it matches that
> of integer?

I believe that 010 is forbidden because it's not clear if it means
eight (as in C/C++/Java) or ten (as in programming languages from other
traditions).  00 would mean the same thing in either case, but it's more
uniform to simply forbid leading zeros (other than in the value 0, of
course).

-- 
Mark Twain on Cecil Rhodes:                    John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                [email-masked]
buy a piece of the rope for a keepsake.