Subject: [Json] Working Group Last Call of draft-ietf-json-rfc4627bis-04

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 26 Sep 2013 17:14:34 +0000

Hello All,

This message begins the Working Group Last Call (WGLC) on "The JSON Data Interchange Format" < draft-ietf-json-rfc4627bis-04 >.  WGLC will end in two weeks, on October 11.

Please review the document and send comments to the Working Group mailing list < json at ietf.org > or the co-chairs <json-chairs at tools.ietf.org > before the end of the WGLC.  Note that suggested changes which include proposed text will be more strongly considered than those without.

Thanks,

- Paul Hoffman and Matt Miller

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 10:31:17 -0700

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.

Other issues:

I don't think we've seen a JSON implementation "suffer fatal runtime
exceptions" in the presence of the aforementioned bit sequences. Carsten
showed the Python 3 print function throwing an exception, but its standard
JSON module parsed and then stringified them without error.

I don't think there is a rationale for the text on -0.0. Is it for
non-IEE754 implementations?

- Rob

On Thu, Sep 26, 2013 at 10:14 AM, Matt Miller (mamille2) <[email-masked]
> wrote:

> Hello All,
>
> This message begins the Working Group Last Call (WGLC) on "The JSON Data
> Interchange Format" < draft-ietf-json-rfc4627bis-04 >.  WGLC will end in
> two weeks, on October 11.
>
> Please review the document and send comments to the Working Group mailing
> list < json at ietf.org > or the co-chairs <json-chairs at tools.ietf.org> before the end of the WGLC.  Note that suggested changes which include
> proposed text will be more strongly considered than those without.
>
>
> Thanks,
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 11:14:05 -0700

A real HTML version is at
https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-04.html

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 11:36:00 -0700

On Sep 26, 2013, at 10:31 AM, R S <[email-masked]> 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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 11:38:19 -0700

On Sep 26, 2013, at 10:31 AM, R S <[email-masked]> wrote:

> I don't think we've seen a JSON implementation "suffer fatal runtime exceptions" in the presence of the aforementioned bit sequences. Carsten showed the Python 3 print function throwing an exception, but its standard JSON module parsed and then stringified them without error.

Suggested wording differences are appreciated.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 11:41:24 -0700

Numbers which represent zero without a sign, for example as 0 or 0.0
   not -0 or -0.0, are interoperable in the sense that software
   implementations will agree on the zero value.  Signed zeros are
   significant in some numerically-intensive applications, but
   implementations which read JSON texts cannot be relied upon to
   preserve that distinction.

On Sep 26, 2013, at 10:31 AM, R S <[email-masked]> wrote:

> I don't think there is a rationale for the text on -0.0. Is it for non-IEE754 implementations?

Do we need to state a rationale here, or does the text stand on its own?

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 11:48:19 -0700

> Do we need to state a rationale here, or does the text stand on its own?
I meant that I don't see why it's in the draft at all. I propose deleting
this paragraph, since I don't believe it is correct. Most implementations
can be relied upon to preserve signed zeros.

- Rob

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 11:48:49 -0700

I’m with Rob on this one. There is de facto a stable ECMA spec that has
language defining JSON, the definition is different, and people who go and
try to do some of the things it allows will likely have interoperability
issues, so I’d put this in.  Yeah, they might do another spec or specs but
that wouldn't invalidate our reference to the existing one.

On Thu, Sep 26, 2013 at 11:36 AM, Paul Hoffman <[email-masked]>wrote:

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

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 11:50:27 -0700

Well, except for the very first thing I tried, a modern Ruby with the
default "require 'json'", did not preserve the sign.

I think Rob’s right that a large majority of modern implementations do...
is that enough reason to take out the caution?

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 11:50:56 -0700

Leave this part:

However, the ABNF in this specification allows member names and string
values to contain bit sequences which cannot encode Unicode characters, for
example "\uDEAD" (a single unpaired UTF-16 surrogate). Instances of this
have been observed, for example when a library truncates a UTF-16 string
without checking whether the truncation split a surrogate pair.

Remove this part:

The behavior of software which receives JSON texts containing such values
is unpredictable; for example, implementations might return different
values for the length of a string value, or even suffer fatal runtime
exceptions.

- Rob

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Sep 2013 20:52:04 +0200

Paul,

> <no hat>

I've got an IAB hat, and it involves this, but I am but a member of the
IAB, and the below is my advice.
> 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.

This is a matter for Pete.  He hinted at something about this in a
previous message, but...
> I'm no longer sure that a long-lasting RFC interpreting parts of another SDO's spec is a good idea.

What I would suggest is that at the very least we understand the
differences, so that we know what we're getting into.  My understanding
is that what is proposed in the latest draft is in line with what
they've produced, although we provide interoperability guidance that is
somewhat more constraining.  Some eyes here would be good.

If we agree on all of this, there is the question on whether or not the
document should simply normatively reference ECMA.  But I would only do
this if we are agreed that the normative specifications are intended to
be identical, and then I would think it a good idea (even though I'm
entirely non-plussed by the approach taken by ECMA members), simply to
avoid unintended differences.

If, however, the working group has diverged intentionally, I would
suggest that those differences be called out.

Eliot

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 11:52:37 -0700

I think we should leave this in; I speak as a person who has written quite
a lot of low-level C code that, frankly, looking in the rearview mirror, I
have no idea whether or not it'll silently work around, throw an orderly
error, or blow up on a singleton \uDEAD.  I suspect there’s a lot of that
out there.

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 11:52:47 -0700

> default "require 'json'", did not preserve the sign.

I bet they would take a patch, though. I was wondering whether we were
enshrining a bug in the spec or catering to other floating point
implementations.

- Rob

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 11:57:12 -0700

Hm, I bet that there are languages that look at the JSON number and if
there's no exp or frac parts, jam it into an integer; do modern *integer*
implementations preserve negative zero?

---

From: John Cowan <[email-masked]>
Date: Thu, 26 Sep 2013 15:31:10 -0400

R S scripsit:

> I meant that I don't see why it's in the draft at all. I propose
> deleting this paragraph, since I don't believe it is correct.

An implementation written in C cannot be counted on to either produce
or preserve sign on zero, at least not if it uses sscanf/sprintf,
since they are not required to be IEEE-compliant.  Indeed, few
languages defined by spec (as opposed to by a unique or predominant
implementation) require IEEE compliance.

> Most implementations can be relied upon to preserve signed zeros.

Evidence for this statement is lacking.

-- 
Evolutionary psychology is the theory           John Cowan
that men are nothing but horn-dogs,             http://www.ccil.org/~cowan
and that women only want them for their money.  [email-masked]
        --Susan McCarthy (adapted)

---

From: John Cowan <[email-masked]>
Date: Thu, 26 Sep 2013 15:36:28 -0400

Tim Bray scripsit:

> Hm, I bet that there are languages that look at the JSON number and
> if there's no exp or frac parts, jam it into an integer; do modern
> *integer* implementations preserve negative zero?

By definition, no language that provides a exact representation of
numbers (whether fixed-point or integral) can differentiate 0 and -0.
It is because floating-point values represent *ranges* of numbers that
it makes sense to differentiate between too-small numbers that cannot
be negative (0.0) and too-large numbers that cannot be positive (-0.0).

-- 
John Cowan  [email-masked]  http://ccil.org/~cowan
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 13:39:15 -0700

> Evidence for this statement is lacking.

Well, I wrote a widely-used implementation. And all of the implementations
I use, including the C one, handle it. It is part of JSON, after all.

I think the burden of proof is on those that want to leave this text in.

- Rob

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 16:23:44 -0700

> for this RFC *not* to do what the charter says.

Are you saying the concerns you list below warrant a recharter? If so, I
disagree.

> -bis draft of their version will be out first.

We have a reference to ECMAScript in the draft already.

> definition of ECMAscript, such as "exactly how to interpret numbers"

We wouldn't even need to add a reference to explain this:

"4.3.19 Number value
primitive value corresponding to a double-precision 64-bit binary format
IEEE 754 value"

<http://www.ecma-international.org/ecma-262/5.1/#sec-4.3.19>

 - Rob

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Sep 2013 09:24:37 +1000

I haven't been following this document terribly closely, but it looks good from what I see.

FWIW, other reviewers may find this useful:
  http://www.ietf.org/rfcdiff?url1=rfc4627&url2=draft-ietf-json-rfc4627bis-04

A couple of nits (which may have already been discussed, pardon my ignorance):

* Shouldn't this document obsolete 4627?
* Since this document is so similar to 4627, have you considered leaving Crockford on the author list?
* Is section 1.3 intended to be in the final, published document? If so, it contains a needless amount of detail (e.g., a link to a consensus call, a note that the 'changes' section has been added, WG attribution, adding Tim as editor)
* Appendix.A is supposed to be removed by the RFC Editor, right?

Cheers,

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Sep 2013 17:27:01 -0600

> leaving Crockford on the author list?

IMHO that is the right thing to do, unless he objects. The Area
Director might need to perform an AD-override on AUTH48 approvals if
Mr. Crockford has in fact disappeared or is uncommunicative.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 16:36:06 -0700

+1, I think the only sane thing is to list Douglas as an author since a
large majority of the text is his.  I was told to put it this way for now.
-T

On Thu, Sep 26, 2013 at 4:27 PM, Peter Saint-Andre <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSRMLFAAoJEOoGpJErxa2p1HAQAJNQpOnjgHJJ/Vvn/4Rw4a3T
> AuF3MFRN1c1rXa4a3vvAv/H64tXjgVZXbBzNQScB3P0F1jOdL1DGzeyCYQlSci30
> Nl1Kn3GF9aLFSaD7JkgnSOkTjkptQuZS9tj5ybm0ub9M8rQBXMPFRSCuzMczJOiV
> ZuQyXbx2maSX/Nm1UIZo+wpFw34NnmE2+pTnBeIvclIY+LVJTmPkXoUvDW8Nq3WQ
> Ng2klJ8f7Qyd6OFOitsdmci7xNuxqQgu8taZn1fHWJa9KsQ20xg41UoHKpI5+C6a
> 4/xzBicLTKGLdJY6Fp+paXfxk6EL2P3EV0IFHI8E66B8cPi3x+y1/lfxDSH5Gl8z
> M9uXbDj7s8FzKBFUc8trlyFk5cXbHcBv/yqJOQAK07UuWo95VGKbsVL8Z9VxnbPe
> 2gQn83HRa04RfZUzEqUCGqoSIOQBIV0YqzLbRfowR7mI2sKCvo6v2fasGDLw19Ik
> D4HH3uCaBbmPr04lGH+XdfOmAeSJdqsA9tVnmAL4/XmvyX7vzca6o5g2tzjqA2m6
> E3vWk9MEFBmx29tNU/etg1sLVQsKqIQmbyHLaQDmwl6Q2JZuNnI/0ugt+QARqngs
> oXJNWtvXOsztaeS6HR1sqWWU+vHWRdV04wk3R24QnS/DrcYwg43m0TDIojBCQdCq
> 9xElSZ6E1K7fhUHZNCKJ
> =dz4j
> -----END PGP SIGNATURE-----

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 17:20:39 -0700

On Sep 26, 2013, at 4:23 PM, R S <[email-masked]> wrote:

> Are you saying the concerns you list below warrant a recharter? If so, I disagree.

No, I was suggesting we ignore the charter and beg for forgiveness.

A different thought is to (a) assume that version 5.1 is the "current ECMAScript" and (b) simply mimic the two bullets from the beginning of Section 15.12. This worries me because the JSON definition in 5.1 is not exactly the same as 3 (which is what 4627 was based on), and it is not exactly the same as the JSON definition in the current draft of 6. Therefore, us saying "here are some differences" seems to be of more danger than actual value.

> We have a reference to ECMAScript in the draft already.

So? It clearly is not to the current ECMAScript specification.

> primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value"
> 

That seems irrelevant. Section 15.12.2 and 15.12.3 talk about "Numbers", not "number values". TC39 might change this in version 6, or they might not; we cannot tell.

But you seem keen on us having such a section. Please provide the full wording for what you think would be valuable to include.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 17:29:24 -0700

<co-chair hat on>

> * Since this document is so similar to 4627, have you considered leaving Crockford on the author list?

As we said not long ago, we have not heard back from Douglas, even after multiple attempts to reach him. Leaving his name as a co-author means a few things:

- He agrees with everything in the document that has his name on it. We cannot tell if that is true, and we suspect it might not be.

- He can cause the eventual RFC to never be published by never responding during AUTH48, the last step in the RFC publication process. That would mean that the hard work that many people have done here would be a waste of time and energy.

If Douglas himself asks to be the lead editor again under normal IETF rules, the co-chairs would be happy to have him back and happier to have his name where it should be on the eventual RFC. Without any such agreement, or even acknowledgement that we have tried to reach him, we were forced to move on.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 17:30:14 -0700

<no hat>

> * Shouldn't this document obsolete 4627?

Er, yes, it probably should. Does anyone have any objection to this?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 17:33:39 -0700

<hat on>

On Sep 26, 2013, at 4:24 PM, Mark Nottingham <[email-masked]> wrote:

> * Is section 1.3 intended to be in the final, published document?

Yes.

> If so, it contains a needless amount of detail (e.g., a link to a consensus call, a note that the 'changes' section has been added, WG attribution, adding Tim as editor)

The link to the consensus call is probably worth removing. The rest should stay because they are, pedantically, changes from RFC 4627.

> * Appendix.A is supposed to be removed by the RFC Editor, right?

Yes.

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 17:54:29 -0700

> No, I was suggesting we ignore the charter and beg for forgiveness.

Bad suggestion--the charter means what it says. If it doesn't, integrity
would compel us to consider all of the suggestions that fall outside of the
charter.

>
> A different thought is to (a) assume that version 5.1 is the "current
> ECMAScript" and (b) simply mimic the two bullets from the beginning of
> Section 15.12. This worries me because the JSON definition in 5.1 is not
> exactly the same as 3 (which is what 4627 was based on),

There is no JSON definition in ECMAScript 3.

> and it is not exactly the same as the JSON definition in the current draft
> of 6. Therefore, us saying "here are some differences" seems to be of more
> danger than actual value.
>

We are free to cite the current version of ECMAScript, as Tim points out.

> That seems irrelevant.

Disagree.

> Section 15.12.2 and 15.12.3 talk about "Numbers", not "number values".

It's the same:
<http://www.ecma-international.org/ecma-262/5.1/#sec-8.5>

> TC39 might change this in version 6, or they might not; we cannot tell.
>

Again, we won't be citing a future version with hypothetical changes.

> But you seem keen on us having such a section. Please provide the full
wording for what you
> think would be valuable to include.

I already have--feel free to reuse it.

- Rob

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 18:05:28 -0700

On Thu, Sep 26, 2013 at 5:29 PM, Paul Hoffman <[email-masked]> wrote:

>
> - He agrees with everything in the document that has his name on it. We
> cannot tell if that is true, and we suspect it might not be.
>

Maybe that should make us question the value of the current draft.

- Rob

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Sep 2013 18:18:21 -0700

On Sep 26, 2013, at 5:54 PM, R S <[email-masked]> wrote:

> Bad suggestion--the charter means what it says. If it doesn't, integrity would compel us to consider all of the suggestions that fall outside of the charter.

Sorry if you don't feel that we are acting in "integrity".

> There is no JSON definition in ECMAScript 3.

Whatever you want to call the third edition:
   [ECMA]    European Computer Manufacturers Association, "ECMAScript
             Language Specification 3rd Edition", December 1999,
             <http://www.ecma-international.org/publications/files/
             ecma-st/ECMA-262.pdf>.

> We are free to cite the current version of ECMAScript, as Tim points out.

Only if we can agree on what that version is. And if we can agree that doing so actually brings value to the document. The latter is more important to me than the coin we use for the former.

> I already have--feel free to reuse it.

It was:

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.

Do others here agree with all three parts? Or is there different suggested wording?

Also: You did not include the second bullet from ECMAScript 5.1, Section 15.12. Is there a reason for that?

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Thu, 26 Sep 2013 18:29:40 -0700

> Sorry if you don't feel that we are acting in "integrity".

Maybe you should explain why you think it's OK to suddenly ignore the
charter? Don't you think it's inconsistent with telling people to go away
because their suggestions don't fit the charter?

I'm sorry--are you nitpicking my term for what you called "3"? Hopefully we
can raise the level of discourse.

> Only if we can agree on what that version is. And if we can agree that
> doing so actually brings value to the document. The latter is more
> important to me than the coin we use for the former.
>

We do agree on the latter--we already have the charter that says so.

> > I already have--feel free to reuse it.

No.

> specifies exactly how to interpret numbers, and can handle "bit sequences

That text is not what I was referring to.

> 15.12. Is there a reason for that?

That bullet point is misleadingly worded. I can tell you this because I
wrote a widely-used JSON implementation for RFC4267 that had to be adjusted
for ECMAScript 5. The two biggest changes were to ban trailing commas in
objects and accept primitive values at the root.

- Rob

---

From: John Cowan <[email-masked]>
Date: Thu, 26 Sep 2013 22:45:54 -0400

> would compel us to consider all of the suggestions that fall outside of the

There is a big difference between not doing what the charter says we
should, and doing what the charter says we should not.  Paul is proposing
that we ask forgiveness for a sin of omission; you are saying that that
is equivalent to arbitrary sins of commission.  It isn't.

-- 
John Cowan <[email-masked]>             http://www.ccil.org/~cowan
Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash
    him with a Cshell!  Vi didn't I mount it on a troff?" --Francis Turner

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Sep 2013 20:49:50 -0600

On 9/26/13 7:05 PM, R S wrote:
> On Thu, Sep 26, 2013 at 5:29 PM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     - He agrees with everything in the document that has his name on it.
>     We cannot tell if that is true, and we suspect it might not be.
> 
> 

It strikes me that we question the value of a document based on its
objective content, not based on the unknowable intentions of a given
participant (or, now, non-participant) in the WG -- no matter how
important that person has been to the work so far.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Cowan <[email-masked]>
Date: Thu, 26 Sep 2013 23:17:32 -0400

Paul Hoffman scripsit:

> If Douglas himself asks to be the lead editor again under normal IETF
> rules, the co-chairs would be happy to have him back and happier to
> have his name where it should be on the eventual RFC. Without any such
> agreement, or even acknowledgement that we have tried to reach him,
> we were forced to move on.

I think section 14 satisfies all authorship concerns.

-- 
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
  --Joyce, Ulysses, "Oxen of the Sun"       [email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 27 Sep 2013 13:03:27 +0900

On 2013/09/27 9:30, Paul Hoffman wrote:
> <no hat>
>
> On Sep 26, 2013, at 4:24 PM, Mark Nottingham<[email-masked]>  wrote:
>

None at all here. If it doesn't obsolete RFC 4627, why would we have 
done all the work?

Regards,   Martin.

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 23:02:52 -0700

<wearing-editor-hat>where do “obsoletes” assertions go in the
draft?</wearing-editor-hat>

On Thu, Sep 26, 2013 at 9:03 PM, "Martin J. Dürst"
<[email-masked]>wrote:

> None at all here. If it doesn't obsolete RFC 4627, why would we have done
> all the work?
>
> Regards,   Martin.
>
>
>  --Paul Hoffman
>>
>> ______________________________**_________________
>> json mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>>
>>  ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Sep 2013 08:07:50 +0200

> draft?</wearing-editor-hat>

In the header of the document.  If you're using xml2rfc, in the <rfc>
element as an attribute <rfc obsoletes="4627"> (but you would add it to
the existing <rfc>.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Sep 2013 08:18:07 +0200

<no hats>

> I think section 14 satisfies all authorship concerns.

I don't agree.  Although he should not be editing now, Mr. Crockford
wrote the bulk of the text and it would be wrong to remove him from the
front.  Section 14 already indicates that only a small number of
revisions have occurred.  Our practice is to leave him in the author
field.  We have mechanisms to deal with getting documents out the door. 
It is important to indicate that he has not actively contributed to this
draft, and thus may not agree with the revision.

Eliot

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 27 Sep 2013 16:00:27 +0900

I agree too that Douglas should continue to be listed as an author.

Paul wrote:

 > As we said not long ago, we have not heard back from Douglas, even 
after multiple attempts to reach him. Leaving his name as a co-author 

He doesn't have to agree with every comma in the draft. He just has to 
agree that he is okay with being listed as an author, even if there are 
details he might have done differently.

 > - He can cause the eventual RFC to never be published by never 
responding during AUTH48, the last step in the RFC publication process. 
That would mean that the hard work that many people have done here would 
be a waste of time and energy.

Peter mentioned how to deal with this below.

 > If Douglas himself asks to be the lead editor again under normal IETF 
rules, the co-chairs would be happy to have him back and happier to have 
his name where it should be on the eventual RFC. Without any such 
agreement, or even acknowledgement that we have tried to reach him, we 
were forced to move on.

There is absolutely no need to have him as a lead editor. Tim is doing 
just fine in that role. Once the text in the document from Douglas drops 
below a certain percentage (e.g. 10% or 20% or so, which I don't expect 
to happen anyway), it may make sense to ask him to hang in there a bit 
more to earn his authorship, but at the moment, he has already 'prepaid' 
for this a long time ago.

So I would definitely prefer to keep Douglas as an editor, and would 
want to make sure that when he's contacted, it's not by saying "we can 
keep you as an editor if you are going to be a lead editor again and are 
going to agree with every single bit of the document" but "we'd like to 
keep you listed as an editor because of what you have done up to now 
(and we are reusing)".

Regards,    Martin.

On 2013/09/27 8:36, Tim Bray wrote:
> On Thu, Sep 26, 2013 at 4:27 PM, Peter Saint-Andre<[email-masked]>wrote:
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 27 Sep 2013 16:09:08 +0900

On 2013/09/27 3:52, R S wrote:
> On Thu, Sep 26, 2013 at 11:50 AM, Tim Bray<[email-masked]>  wrote:
>
> I bet they would take a patch, though.

Please send one, or at least file a bug report on http://bugs.ruby-lang.org.

> I was wondering whether we were

I think the later, mostly.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 27 Sep 2013 16:12:23 +0900

> The link to the consensus call is probably worth removing. The rest should stay because they are, pedantically, changes from RFC 4627.

One way to deal with this is to separate this into two:
- Major changes from RFC 4627 (this stays in the final version)
- Changelog (this gets removed by the RFC editor)

That has worked quite well in other instances.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 27 Sep 2013 16:19:54 +0900

On 2013/09/27 15:07, Eliot Lear wrote:
> In the header of the document.  If you're using xml2rfc, in the<rfc>
> element as an attribute<rfc obsoletes="4627">  (but you would add it to
> the existing<rfc>.

Or directly from the DTD:

<!ELEMENT rfc         (front,middle,back?)>
<!ATTLIST rfc
           number      %NUMBER;           #IMPLIED
           obsoletes   %NUMBERS;          ""
...

I guess you can still read this, Tim? Not everybody likes DTDs, but 
sometimes, they're actually useful :-).

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 27 Sep 2013 18:02:00 +0900

> I think Rob’s right that a large majority of modern implementations do...

I have pretty little experience in this area, but that may indeed be the 
case. And it's probably fair, as Rob says in another mail, that the 
burden of proof is on those who claim there are implementations that 
don't respect the difference between -0 and 0. On the other hand, the 
occurrence of something (i.e. such implementations) is way easier to 
prove than their absence.

> is that enough reason to take out the caution?

What I'd propose is to leave it in, but turn it down a bit. E.g. what 
about changing

 >>>     but

to something like

      but
      not all implementations which read JSON texts
      preserve that distinction.

or

      but a small number of
      implementations which read JSON texts do no
      preserve that distinction.

or something like this.

Regards,   Martin.

> On Thu, Sep 26, 2013 at 11:48 AM, R S<[email-masked]>  wrote:
>
>> On Thu, Sep 26, 2013 at 11:41 AM, Paul Hoffman<[email-masked]>wrote:
>>
>>> On Sep 26, 2013, at 10:31 AM, R S<[email-masked]>  wrote:
>>>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Sep 2013 11:37:38 +0200

> burden of proof

http://www.ietf.org/mail-archive/web/json/current/msg01523.html

I didn't reply to Rob's email because that already had been done.

> a small number of implementations

Since one's complement fell out of favor some 40 years ago, no platform representation of integers has had a distinct negative zero.

A large number of JSON implementations map a subset JSON numbers to platform integers.
(Mostly those on platforms that do not have integers don't.)
(There is less commonality on the exact subset than one would like.)

I would venture the guess that *all* of these implementations lose the distinction of negative zeros for that subset they do map to integers.

*All* of a large subset is not a small number.

Grüße, Carsten

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 27 Sep 2013 16:38:03 +0200

>can be relied upon to preserve signed zeros.

The primary problem with negative zero is that it is very common for
number-to-string algorithms to render `-0` as `0`, and accordingly it
is common that negative zero vanishes accidentally, say when you have

  process_json_string(json_string)

and turn that into

  process_json_string(sanatise(json_string))

where sanatise parses, modifies, and re-serialises the json_string.
As I have mentioned, ecmascript's JSON.stringify is an example of a
JSON serialisation function that does not preserve negative zero.

The secondary problem is that many deployed implementations treat a
value like `-0` as integer value and do not preserve the sign. As an
example,

  % perl -MJSON -e "printf '%g', JSON->new->decode('[-0]')->[0]"
  0

Also in case of Perl, `-0` is not the same as `-0.0`,

  % perl -MJSON -e "printf '%g', JSON->new->decode('[-0.0]')->[0]"
  -0
-- 
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: Pete Resnick <[email-masked]>
Date: Fri, 27 Sep 2013 10:21:15 -0500

As responsible AD for this WG:

> draft, and thus may not agree with the revision.

The chairs and I talked about this prior to the change. Yes, we do have 
ways to override the procedural aspects if Douglas is unresponsive, but 
that involves me as AD intervening and saying, "Yes, let's publish 
anyway." When we currently have no indication on the list that Douglas 
is participating, and he is not responding to repeated attempts by the 
chairs to contact him, I think it is unreasonable to *plan* to make an 
exception. If he returns to working on this, that would be great and I 
think he should be put back on the front page. But until then, it is 
clear that he can not fulfill the responsibilities of an author as 
described in http://www.rfc-editor.org/policy.html and that he is a 
contributor and not an author. We have made exceptions to this in 
special circumstances (an author having passed away and we wanted to 
give him credit posthumously), but I do not think this is one of those 
special circumstances.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Tony Hansen <[email-masked]>
Date: Fri, 27 Sep 2013 11:34:05 -0400

On 9/26/2013 9:29 PM, R S wrote:
> On Thu, Sep 26, 2013 at 6:18 PM, Paul Hoffman <[email-masked]
>     > > But you seem keen on us having such a section. Please provide
>     the full wording for what you
>     specifies exactly how to interpret numbers, and can handle "bit
>     sequences which cannot encode Unicode characters" just fine.
>

Sometimes things bear repeating. Would you please provide again the
exact text you were referring to so that we can discuss the correct
text? Thank you.

>  
>
>
>     Also: You did not include the second bullet from ECMAScript 5.1,
>     Section 15.12. Is there a reason for that?
>
>
> That bullet point is misleadingly worded. I can tell you this because
> I wrote a widely-used JSON implementation for RFC4267 that had to be
> adjusted for ECMAScript 5. The two biggest changes were to ban
> trailing commas in objects and accept primitive values at the root.

RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis. I
don't see a difference there from ECMAScript's definition.

    Tony Hansen

---

From: R S <[email-masked]>
Date: Fri, 27 Sep 2013 09:34:01 -0700

On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <[email-masked]> wrote:

> RFC 4627 does not allow trailing commas in objects. Nor does 4627-bis.
>

RFC 4627 allows parsers to accept non-JSON if they wish, while ECMAScript
does not allow this.

- Rob

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Sep 2013 18:51:06 +0200

> RFC 4627 allows parsers to accept non-JSON if they wish, while ECMAScript does not allow this.

That is not really the difference.

ECMA-262 defines one implementation of JSON (and its API).  Of course, ECMA-262 can go ahead and define all the desired the characteristics of the implementation, including not accepting extensions.

RFC 4627 defines JSON the format.  It could go ahead and put down a "MUST NOT extend".  At best, the result would be for a subset of the implementations to offer a "conforming mode".  All the rest, and the default setting of most implementations, will still accept trailing punctuation, comments in various forms, random variant interpretations of string content depending on whether a character is escaped or not, etc.  The definition of soup.  But that fact of life doesn't have anything to do with the definition of JSON.

Grüße, Carsten

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 27 Sep 2013 20:13:16 +0200

>be a waste of time and energy.

I note that RFC 4627 awards him change control over application/json...
-- 
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: John Cowan <[email-masked]>
Date: Fri, 27 Sep 2013 17:41:37 -0400

"Martin J. Dürst" scripsit:

> I have pretty little experience in this area, but that may indeed be
> the case. And it's probably fair, as Rob says in another mail, that
> the burden of proof is on those who claim there are implementations
> that don't respect the difference between -0 and 0. 

$ python
Python 2.7.3 (default, Dec 18 2012, 13:50:09)
[GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.loads("[-0]")
[0]
>>> json.loads("[-0.0]")
[-0.0]

There you go (and ultrajson behaves the same way).  Saying "most"
involves counting implementations, which is hard.

-- 
John Cowan                                <[email-masked]>
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    --Calvin, giving Newton's First Law "in his own words"

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 27 Sep 2013 21:48:33 +0000

> involves counting implementations, which is hard.

/me dons hat

It appears to me that we are rehashing arguments made when this text was first discussed.  Are we bringing up any new considerations here?

- m&m

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

---

From: R S <[email-masked]>
Date: Fri, 27 Sep 2013 15:12:40 -0700

On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2)
<[email-masked]>wrote:

>
> It appears to me that we are rehashing arguments made when this text was
> first discussed.  Are we bringing up any new considerations here?
>

Yes. The text in the current draft refers to both -0 and -0.0 as though
they are interoperable.

- Rob

---

From: R S <[email-masked]>
Date: Fri, 27 Sep 2013 15:15:09 -0700

On Friday, September 27, 2013, R S wrote:

> On Fri, Sep 27, 2013 at 2:48 PM, Matt Miller (mamille2) <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>wrote:
>
>>

Rather, it refers to them both as though they have the same
interoperability considerations.

- Rob

---

From: R S <[email-masked]>
Date: Fri, 27 Sep 2013 15:20:21 -0700

Further, let me hasten to add that this thread is titled "-0.0" and I wrote:

> I don't think there is a rationale for the text on -0.0.

I did not write "negative zero" or "-0".

I think this thread and the text in the draft shows that the WG didn't
fully understand what the chairs took to be consensus. It was nearly a
mistake, but it would have been *fine* if the WG let the existing
"implementations may place limitations on the range of numbers accepted"
text stand. Why not do that?

- Rob

On Fri, Sep 27, 2013 at 3:15 PM, R S <[email-masked]> wrote:

>> [email-masked]> wrote:
>>
>>>

---

From: John Cowan <[email-masked]>
Date: Fri, 27 Sep 2013 18:41:48 -0400

R S scripsit:

> fully understand what the chairs took to be consensus. It was nearly
> a mistake, but it would have been *fine* if the WG let the existing

Failure to distinguish between zero and negative zero is not a limitation
of range.

Limitations of precision are not limitations of range.

-- 
If you have ever wondered if you are in hell,       John Cowan
it has been said, then you are on a well-traveled   http://www.ccil.org/~cowan
road of spiritual inquiry.  If you are absolutely   [email-masked]
sure you are in hell, however, then you must be
on the Cross Bronx Expressway.          --Alan Feuer, NYTimes, 2002-09-20

---

From: R S <[email-masked]>
Date: Fri, 27 Sep 2013 15:43:36 -0700

> Limitations of precision are not limitations of range.

Do you want to change the text to say "implementations may place
limitations on the range and precision..." ?

That's totally true--I would be in favor.

- Rob

---

From: R S <[email-masked]>
Date: Sat, 28 Sep 2013 14:52:28 -0700

> http://bugs.ruby-lang.org.

I checked this today. Ruby's standard implementation appears to interpret
"-0.0" as -0.0 and "-0" as 0.

- Rob

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 29 Sep 2013 10:31:40 +0200

On Sep 28, 2013, at 00:15, R S <[email-masked]> wrote:

>> Yes. The text in the current draft refers to both -0 and -0.0 as though they are interoperable.
> 
> Rather, it refers to them both as though they have the same interoperability considerations.

Rightly so.

While the probability of being hit is lower (more JSON implementations do seem to implement -0.0 as distinct from 0.0), it would still be foolish to rely on interoperability of any form of negative zero.

(Two minutes of googling:
https://android.googlesource.com/platform/libcore/+/014aa1a70743ae7e6ec0de1555f5b43d43844cf4/json/src/main/java/org/json/JSONObject.java
I haven't investigated further.)

Note also the result on -0e0.

More importantly, the JSON specification so far has been mute on negative zeros (random quote from someone trying to interpret the specification: "The JSON specification allows that number, but does not define what it means"*).

(Going forward, it would probably be a good thing to recommend that JSON decoders represent all of -0, -0e0 etc. in a number representation that keeps negative zeros distinct; that is for most of them, treat -0 as a floating point value.  Examples of implementations that do so: Erlang's, JSONKit, demjson.)

Grüße, Carsten

*) http://deron.meranda.us/python/comparing_json_modules/numbers

---

From: R S <[email-masked]>
Date: Sun, 29 Sep 2013 13:25:40 -0700

On Sun, Sep 29, 2013 at 1:31 AM, Carsten Bormann <[email-masked]> wrote:

> While the probability of being hit is lower (more JSON implementations do
> seem to implement -0.0 as distinct from 0.0), it would still be foolish to
> rely on interoperability of any form of negative zero.
>

I am not sure that file is relevant--the tokenizer in the same directory
looks like it will preserve the sign of -0.0. But please explain further if
I'm wrong about that.

> More importantly, the JSON specification so far has been mute on negative
> zeros

The spec now cites IEEE754, and states that that it will generally
interoperate. I think that's accurate for -0.0 since IEEE754 specifies its
handling, and all of these implementations are winding up in a strtod
implementation that preserves the sign for -0.0.

In other words, the text on -0.0 contradicts

"Since software which implements IEEE 754-2008
[IEEE754]<https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-04.html#IEEE754>
is
generally available and widely used, good interoperability can be
achieved..."

Java, POSIX strtod, ECMAScript, and many more all handle negative zero.

> (random quote from someone trying to interpret the specification: "The
> JSON specification allows that number, but does not define what it means"*).
>

Interestingly, the link you cite shows a table with -0.0 interoperating
perfectly across 5 implementations.

<http://deron.meranda.us/python/comparing_json_modules/numbers#t5-3>

>
> (Going forward, it would probably be a good thing to recommend that JSON
> decoders represent all of -0, -0e0 etc. in a number representation that
> keeps negative zeros distinct; that is for most of them, treat -0 as a
> floating point value.  Examples of implementations that do so: Erlang's,
> JSONKit, demjson.)
>

Oh, that might make some sense, but it's a distinct issue from -0.0 today.

- Rob

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 29 Sep 2013 22:33:25 +0200

On Sep 29, 2013, at 22:25, R S <[email-masked]> wrote:

> I am not sure that file is relevant

It is an example of an implementation that encodes a floating point negative zero as »-0«, which is then decoded as a plain (integer) zero by most implementations.

Summary: If you want wide interoperability, don't rely on negative zero (in any form) staying distinct.  (And if you don't need wide interoperability, the encoded form »-0.0« appears to survive best.)

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Sun, 29 Sep 2013 13:46:18 -0700

Yeah, but my opinion is shifting here... it's starting to feel to me like
there's nothing remotely JSON-specific about the problems around -0.  Let
me see, if I were going to do another draft based on what people have been
saying here, I'd, in Section 6

- Remove "are represented without "frac" or "exp" parts (for example as 3
not 3.0)"
- Lose the whole paragraph beginning "Numbers which represent zero without
a sign...

Less is more. Is anyone passionate about keeping either?

 -T

On Sun, Sep 29, 2013 at 1:33 PM, Carsten Bormann <[email-masked]> wrote:

> It is an example of an implementation that encodes a floating point
> negative zero as »-0«, which is then decoded as a plain (integer) zero by
> most implementations.
>
> Summary: If you want wide interoperability, don't rely on negative zero
> (in any form) staying distinct.  (And if you don't need wide
> interoperability, the encoded form »-0.0« appears to survive best.)
>
> Grüße, Carsten
>

---

From: Peter Patel-Schneider <[email-masked]>
Date: Sun, 29 Sep 2013 15:45:20 -0700

Hmm.   Many other languages, for example C, are not adequately specific
concerning the interpretation of floating point constants, particularly -0.0

However, I don't know of any language or formalism that is used in a way
that is so cavalier about the interpretation of numeric constants in
general, so I would have to say that the breadth of the problems with -0
are specific to JSON.  In all the other languages and formalisms that I
have used -0 is integer 0, and thus the same as 0, and this has been
explicitly or implicitly stated in the definition of the language or
formalism.  Even C with one's complement integers should get this right,
although direct casting to unsigned integers might expose the existence of
signed zeros.

Peter F. Patel-Schneider
Nuance Communications

PS:  Yes, yes, I expect that there are *many* languages and formalisms that
are just as bad as JSON with respect to numbers.  I just haven't had the
displeasure of needing to work with any of them yet.

---

From: John Cowan <[email-masked]>
Date: Sun, 29 Sep 2013 20:28:31 -0400

Tim Bray scripsit:

> Yeah, but my opinion is shifting here... it's starting to feel to me
> like there's nothing remotely JSON-specific about the problems around
> -0.

There isn't, but JSON is what we are working on today.  "It is not
incumbent upon you to complete the work, but neither are you at liberty
to desist from it." (R. Tarfon, _Pirke Avot_ 2:21, ca. 100 C.E.)

> - Remove "are represented without "frac" or "exp" parts (for example
> as 3 not 3.0)"

+1

> - Lose the whole paragraph beginning "Numbers which represent zero
> without a sign...

-1

> Less is more. Is anyone passionate about keeping either?

I do feel that we should warn about negative zero.  Unlike XML, JSON
claims to transmit numbers, and we should warn about the limits of that
capability.

-- 
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
                   --Felix Winkelmann

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Sep 2013 17:38:24 -0700

<no hat>

The additions that we are making about interoperability are about things that a significant number of JSON users might expect. The likely-forthcoming "implementation advice" document can take care of telling implementers of JSON encoders and parsers what they should consider.

> to desist from it." (R. Tarfon, _Pirke Avot_ 2:21, ca. 100 C.E.)

"Don't boil the ocean." (Lots of people, recently.)

+1

> claims to transmit numbers, and we should warn about the limits of that

Number geeks^wspecialsts might expect certain things about -0, but the vast majority of normal JSON users won't. I think it is fine to remove the paragraph and assume that a more in-depth discussion will happen in the companion document.

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Sun, 29 Sep 2013 17:47:26 -0700

> Less is more. Is anyone passionate about keeping either?

Removing that text is a good idea.

Section 9, "Parsers", currently reads:

> An implementation may set limits on the range of numbers.

That text should be adjusted to allow implementations to set limits on
range and precision, since that obviously happens in practice.

- Rob

---

From: John Cowan <[email-masked]>
Date: Sun, 29 Sep 2013 20:58:53 -0400

Paul Hoffman scripsit:

> The additions that we are making about interoperability are about
> things that a significant number of JSON users might expect.

I don't actually think so.  They are edge cases (unpaired surrogates,
too-large or too-precise numbers, duplicate names), but edge cases wind
up being important to somebody.  Negative zero is just another edge case.

> The likely-forthcoming "implementation advice" document can take care
> of telling implementers of JSON encoders and parsers what they should
> consider.

Oh, I agree.  But all the things above, including negative zero, are about
what users can and cannot expect to survive when transmitted by JSON.

> "Don't boil the ocean." (Lots of people, recently.)

In the Middle East, that's where the drinking water comes from.  What's
more, if you have some high-temperature superconductor and need to kill
off a field of sunflowers, boiling the ocean may be just the thing.

> Number geeks^wspecialsts might expect certain things about -0, but the
> vast majority of normal JSON users won't. I think it is fine to remove
> the paragraph and assume that a more in-depth discussion will happen
> in the companion document.

You could make the same argument about Unicode geeks and unpaired
surrogates.  Are you doing so?  If not, why not?

-- 
                Si hoc legere scis, nimium eruditionis habes.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Sep 2013 08:37:29 +0200

On Sep 30, 2013, at 02:47, R S <[email-masked]> wrote:

> That text should be adjusted to allow implementations to set limits on range and precision, since that obviously happens in practice.

Yes!

Grüße, Carsten

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Sep 2013 18:29:11 +0900

> I note that RFC 4627 awards him change control over application/json...

I note that draft-ietf-json-rfc4627bis-04 still awards him change 
control. I'd really like to have Douglas back as an author (even if he 
isn't too much involved in day-to-day work), but I think it's not 
appropriate that an IETF WG produce a Media type definition that doesn't 
list the IETF as Change Controller.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Sep 2013 18:33:07 +0900

> list the IETF as Change Controller.

I only noticed this because some indentation changes make it show up in 
http://www.ietf.org/rfcdiff?url1=rfc4627&url2=draft-ietf-json-rfc4627bis-04 
(posted by Mark, thanks!).

If easily possible, it would be great if the indentation would go back 
to be the same as in the original; that would make the diff shorter. 
Maybe this needs an issue to be raised on the xml2rfc list or somewhere. 
Or is the RFC Editor experimenting with new indents?

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Sep 2013 14:14:26 +0200

> Or is the RFC Editor experimenting with new indents?

xml2rfcv2 has changed some of the indentation logic with respect to v1.

In the documents I have been working on, these changes generally were improvements.

Looking at http://www.ietf.org/rfcdiff?url1=rfc4627&url2=draft-ietf-json-rfc4627bis-04, this generally seems to be the case here as well.

There are a couple of lines that would benefit from more indentation; 
from the XML and the xml2rfcv2 code I cannot see why they look the way they do (i.e., these may be bugs in xml2rfcv2; there also is a spurious newline at the end of the one-liners):

  JSON-text = object / array
  ws = *(
  false null true
  array = begin-array [ value *( value-separator value ) ] end-array

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Sep 2013 14:22:55 +0200

On Sep 30, 2013, at 14:14, Carsten Bormann <[email-masked]> wrote:

> bugs in xml2rfcv2

http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/151

Workaround: have at least one empty line in the artwork element.
(That then makes two spurious empty lines, but at least the indentation is consistent.)

Grüße, Carsten

---

From: Jorge Chamorro <[email-masked]>
Date: Mon, 30 Sep 2013 14:46:13 +0200

On 30/09/2013, at 11:29, Martin J. Dürst wrote:
> I note that draft-ietf-json-rfc4627bis-04 still awards him change control. I'd really like to have Douglas back as an author (even if he isn't too much involved in day-to-day work), but I think it's not appropriate that an IETF WG produce a Media type definition that doesn't list the IETF as Change Controller.

And can't there be a contributors section, as well? :-)

-- 
( Jorge )();

---

From: Tony Hansen <[email-masked]>
Date: Sat, 28 Sep 2013 19:10:21 -0400

On 9/27/2013 12:34 PM, R S wrote:
> On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <[email-masked]
> <mailto:[email-masked]>> wrote:
>

Your claim was that you had to change your parser of JSON to no longer
allow trailing commas because of converting to parsing ECMAScript. I
disagree with that assessment.

You had added your own non-standard extension to JSON (accepting
trailing commas) to your parser. Note that ECMA's restrictions on
parsers are only on implementations of ECMAScript. ECMA does NOT say
that *your* parser may not continue to accept trailing commas, except in
the specific case of your parser being used in an implementation of
ECMAScript's JSON.parse() function. That is, if your function is not
used in an implementation of JSON.parse(), ECMA places no restrictions
on it; it certainly is not restricted in the same ways that ECMAScript's
JSON.parse() is restricted. You chose to remove that non-standard
extension, but only because you chose to *follow* the same restrictions
as ECMAScript's JSON.parse().

Did the JSON spec say you could add your own extension to your parser?
Yes it did. However, if someone wrote JSON using a trailing comma,
they're going into non-interoperable territory.

ECMA also extends 4627-JSON by accepting additional top-level
primitives. ECMA's JSON.parse() is still a 4627-JSON-compliant parser
because it properly interprets 4627-JSON. However, someone writing JSON
using ECMA's extensions will only safely be interoperable with someone
using ECMAScript's JSON.parse() or another parser that's been similarly
extended. But they aren't interoperable with the many other JSON
libraries that haven't been similarly extended.

    Tony Hansen

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Sep 2013 16:47:43 +0200

On Sep 26, 2013, at 20:52, Eliot Lear <[email-masked]> wrote:

> there is the question on whether or not the
> document should simply normatively reference ECMA.

I'm not sure this aspect was picked up yet.

The current draft lists ECMA-262 (1999) as a normative reference.

A quick reading of
http://www.ietf.org/iesg/statement/normative-informative.html
"IESG Statement: Normative and Informative References"
shows that this is an erratum that needs to be corrected.*)
The reference must be informative.

Grüße, Carsten

PS.:  As people sometimes don't have the ability to use links in a message, the juicy sentence is:

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

If we make that true for ECMA-262, we have seriously broken the document.

---

From: John Cowan <[email-masked]>
Date: Mon, 30 Sep 2013 11:55:58 -0400

> If we make that true for ECMA-262, we have seriously broken the document.

Emphatic +1.  Each normative document should be chosen very carefully,
because it's as if you had included the whole thing right there in
the RFC.

-- 
John Cowan  [email-masked]    http://ccil.org/~cowan
Big as a house, much bigger than a house, it looked to [Sam], a grey-clad
moving hill.  Fear and wonder, maybe, enlarged him in the hobbit's eyes,
but the Mumak of Harad was indeed a beast of vast bulk, and the like of him
does not walk now in Middle-earth; his kin that live still in latter days are
but memories of his girth and his majesty.  --"Of Herbs and Stewed Rabbit"

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Sep 2013 09:17:56 -0700

<no hat>

+1 to moving the current reference to the Informative section.

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Sep 2013 09:34:46 -0700

Seems like a no-brainer

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Sep 2013 18:47:42 +0200

+1, assuming the rest of the draft stays as it is.

Eliot

On 9/30/13 6:34 PM, Tim Bray wrote:
>
> Seems like a no-brainer
>
> On Sep 30, 2013 9:17 AM, "Paul Hoffman" <[email-masked]
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Sep 2013 15:45:34 -0700

<hat on>

On Sep 30, 2013, at 2:29 AM, Martin J. Dürst <[email-masked]> wrote:

> . . . I think it's not appropriate that an IETF WG produce a Media type definition that doesn't list the IETF as Change Controller.

It is seeming that way. That is, when an RFC is informational, it is fine for the MIME media type registration to be for the individual who created the document. When it is an IETF-originated document (as this is now becoming), the change controller for the MIME type should be "IESG <[email-masked]>". I have checked with our ADs, and they agree on this.

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Mon, 30 Sep 2013 18:55:54 -0700

On Mon, Sep 30, 2013 at 7:47 AM, Carsten Bormann <[email-masked]> wrote:

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

It is true for RFC 4627. That makes claims that JSON has nothing to do with
ECMAScript rather baseless, at least if one plays the part of spec nerd.

I think we should have a rationale for changing this, since we're not
supposed be changing things without being very careful.

- Rob

---

From: R S <[email-masked]>
Date: Mon, 30 Sep 2013 21:38:39 -0700

my implementation was used for ECMAScript JSON.parse.

- Rob

On Saturday, September 28, 2013, Tony Hansen wrote:

> On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
> You had added your own non-standard extension to JSON (accepting trailing
> commas) to your parser. Note that ECMA's restrictions on parsers are only
> on implementations of ECMAScript. ECMA does NOT say that *your* parser may
> not continue to accept trailing commas, except in the specific case of your
> parser being used in an implementation of ECMAScript's JSON.parse()
> function. That is, if your function is not used in an implementation of
> JSON.parse(), ECMA places no restrictions on it; it certainly is not
> restricted in the same ways that ECMAScript's JSON.parse() is restricted.
> You chose to remove that non-standard extension, but only because you chose
> to *follow* the same restrictions as ECMAScript's JSON.parse().
>
> Did the JSON spec say you could add your own extension to your parser? Yes
> it did. However, if someone wrote JSON using a trailing comma, they're
> going into non-interoperable territory.
>
> ECMA also extends 4627-JSON by accepting additional top-level primitives.
> ECMA's JSON.parse() is still a 4627-JSON-compliant parser because it
> properly interprets 4627-JSON. However, someone writing JSON using ECMA's
> extensions will only safely be interoperable with someone using
> ECMAScript's JSON.parse() or another parser that's been similarly extended.
> But they aren't interoperable with the many other JSON libraries that
> haven't been similarly extended.
>
>     Tony Hansen
>