Subject: [Json] AD Review of draft-ietf-json-rfc4627bis-06

From: Pete Resnick <[email-masked]>
Date: Thu, 31 Oct 2013 11:28:53 -0500

Summary: I am fine issuing the last call on this document. Below are a 
few minor things. Fix them if you agree with them. Don't if you don't. 
I'll pull the trigger on the Last Call when the chairs say, "Go!"

Abstract: Suggest adding the first sentence of 1.2 and/or some piece of 
1.3 to the end.

Section 1 and 2: Neither "serialization" nor "serialized" is defined. 
Might be useful.

Section 1.1:  I am amused by the fact that the uses of MUST/SHOULD/MAY 
in this document (the original uses) all appear to be conformance uses, 
whereas all of the new interoperability language avoids MUST/SHOULD/MAY, 
even though 2119 says that it should be used for the latter, rather than 
the former. I will hold my nose.

Section 15.1: Unicode reference still says version 4.

Good work folks.

pr

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

---

From: Tim Bray <[email-masked]>
Date: Thu, 31 Oct 2013 09:59:23 -0700

Thanks, Pete.

On Thu, Oct 31, 2013 at 9:28 AM, Pete Resnick <[email-masked]>wrote:

> Summary: I am fine issuing the last call on this document. Below are a few
> minor things. Fix them if you agree with them. Don't if you don't. I'll
> pull the trigger on the Last Call when the chairs say, "Go!"
>

To avoid duplication, I suggest adding this to the abstract:

 “This document makes no changes to the definition of JSON; it repairs
specification errors and offers experience-based interoperability guidance.”

> Section 1 and 2: Neither "serialization" nor "serialized" is defined.

It hasn’t harmed interoperability for the last decade or so, let’s assume
the readership is capable of working around this.

> Section 1.1:  I am amused by the fact that the uses of MUST/SHOULD/MAY in
> this document (the original uses) all appear to be conformance uses,

<snicker>

Oops, will fix unless anyone objects.

> Good work folks.
>
> pr
>
> --
> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >
> ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 Oct 2013 10:25:51 -0700

> Oops, will fix unless anyone objects.

Hold that thought. Let's let the WG have some days to look at these, we can discuss them at the f2f next week, you can then make the changes, and then Matt and I ask  Pete to send this to IETF LC.

--Paul Hoffman

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 31 Oct 2013 19:22:18 +0000

>Oops, will fix unless anyone objects.

What would you change it to?  The versionless reference from here:

http://www.unicode.org/versions/index.html#References

is one way to go.

-- 
Joe Hildebrand

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 Oct 2013 12:40:50 -0700

<hat on>

> http://www.unicode.org/versions/index.html#References

In the earlier thread, there were three proposals:

a) Leave as-is from RFC 4627

b) Point to the latest published version

c) Point to the versionless reference

The document to date has left it as (a), and is thus backward-compatible with RFC 4627. ECMA-404 chose (b). No evidence has been presented that there are any JSON encoders that refuse to write out characters that are unallocated in any particular version, nor any parsers that indicate an error if a JSON text contains such a character.

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Thu, 31 Oct 2013 12:49:37 -0700

Yes, the versionless one would be my choice.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 31 Oct 2013 20:06:00 +0000

> The document to date has left it as (a), and is thus backward-compatible with RFC 4627. ECMA-404 chose (b). No evidence has been presented that there are any JSON encoders that refuse to write out…

/me dons hat

Just to point out that 4627bis-04 includes the URL for the versionless reference, but describes version 4.0.  Given that no one objected to changing to the versionless reference in past discussions (although it should be noted that no one strongly advocated for it, either) and no evidence of harm of existing software has been demonstrated, it would seem the proper change is to go with c).

- m&m

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Oct 2013 15:05:56 -0500

On Thu, Oct 31, 2013 at 11:28:53AM -0500, Pete Resnick wrote:
> Section 1.1:  I am amused by the fact that the uses of
> MUST/SHOULD/MAY in this document (the original uses) all appear to
> be conformance uses, whereas all of the new interoperability
> language avoids MUST/SHOULD/MAY, even though 2119 says that it
> should be used for the latter, rather than the former. I will hold
> my nose.

It's informative text, not normative.  Normally we'd want such text to
be normative, not merely interop advice.  We couldn't get consensus to
make any changes to the normative language, therefore all interop advice
had to be informative.  This is bad wordsmithing or a failure to
understand RFC2119 and the Standards Track -- it's just an explicit
failure to get consensus.

Perhaps the I-D should actually state that "...after some sturm und
drang (over 1,000 messages to the WG mailing list), no consensus could
be reached for substantial changes to the normative description of
JSON...".  

Nico
--

---

From: Pete Resnick <[email-masked]>
Date: Thu, 31 Oct 2013 14:12:38 -0700

On 10/31/13 9:59 AM, Tim Bray wrote:
> On Thu, Oct 31, 2013 at 9:28 AM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Abstract: Suggest adding the first sentence of 1.2 and/or some
>     piece of 1.3 to the end.
>
>
>  "This document makes no changes to the definition of JSON; it repairs 
> specification errors and offers experience-based interoperability 
> guidance."

Remember that Abstracts get pulled out and put other places where the 
rest of the document does not appear. I think the important thing to 
note is that this is a replacement for 4627.

No need to worry about duplication. It's common, and IMO reasonable, in 
the Abstract.

>     Section 1 and 2: Neither "serialization" nor "serialized" is
>     defined. Might be useful.
>
>
> It hasn't harmed interoperability for the last decade or so, let's 
> assume the readership is capable of working around this.

The question of what it means has come up in other contexts. Might be 
nice to have a definition. If it will cause grief to come up with a 
non-controversial one, it's not a big deal.

pr

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 01 Nov 2013 12:54:06 +0900

Hello Pete,

> No need to worry about duplication. It's common, and IMO reasonable, in

In terms of content, some overlap between abstract and intro obviously 
is necessary. However, I'd like to remind you of the discussion starting at
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09936.html.

Regards,   Martin.