[Json] Minimal edit proposal, second round

[Paul Hoffman <[e-mail]>]

<chair hats on>

The thread the last few days showed some confusion about what Rob's proposal was. This new thread is an attempt to clarify so that we can see if there is enough agreement to go down this path for the WG's first document. This message is *not* to say "we will go that way instead of the previous way", but instead to ask "does the WG want to go this way, given more explicit information".

First, the proposal is an alternative to the proposals so far in the WG, not in addition to them. That is, the list of changes in the proposal would be the *entire* set of changes; even the current document title remains the same. If there is consensus to go this way, we drop all the current consensus calls. We have made that clearer below.

Second, it is quite clear that there is disagreement on what RFC 4627 means with respect to the content of strings. Many people have forcefully asserted what RFC 4627 meant, and yet many of them disagree. Thus, we think it would be valuable to capture the fact that there is disagreement in a factual manner. We have changed the proposed wording for this below.

Third, the WG's charter is clear that we don't get to start work on additional documents until we finish 4627-bis. Having said that, there seems to be near-universal agreement that an implementation guidance document is needed. (I don't want to use the IETF-centric term "best practices" because we don't have consensus on which practice is best.) We can assume that the document will be produced, even if it isn't in the charter and we have not agreed to the content of that document.

Fourth, we have incorporated the editorial changes from the thread.

The proposal below, then, is meant to be a way to determine if the WG wants to go down the "minimal edit" route, or return to what we were doing before, making non-minimal additions to the document by WG consensus.

Thoughts?

--Matt Miller and Paul Hoffman



Begin with http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-02.

Change Section 1.2, "Changes from RFC 4627", to read:

 This section lists all changes between this document and the text in
 RFC 4627.

 - Applied erratum #607 from RFC 4627 to correctly align the artwork for the definition of
   "object".

 - Applied erratum #3607 from RFC 4627 by removing the security consideration that begins "A JSON
   text can be safely passed" and the JavaScript code that went with that consideration.

 - Added Section 1.3, "Differences from the JSON Definition in ECMAScript".

 - Updated the [ECMA] reference, and changed the [UNICODE] references to be
   non-version-specific.

Add Section 1.3, "Differences Between This Document the JSON Definition in ECMAScript"

 The following lists the known major differences between this document and the definition of JSON
 in Section 15.12 of [ECMA].

 - ECMAScript implementations produce and consume primitive JSON values at the root level of JSON
   documents.

 - ECMAScript implementations can generate and consume all code points in JSON strings, while there
   is disagreement about whether this document prohibits some specific code points in JSON strings.

 - When there are duplicate names within an object, ECMAScript JSON parsers overwrite the value
   corresponding to such names with the value that appears last in the serialization.

In Section 6, remove "A JSON text can be safely passed" and the JavaScript code in the following
paragraph.

In Section 9, change the title in the reference to [ECMA] to be to the latest version with JSON:

 [ECMA]    Ecma International, "ECMAScript Language Specification, 5.1 Edition / June 2011",
           <http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf>.

In Section 9, change the reference to [UNICODE] to be be non-version-specific:

 [UNICODE]  The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.