Re: [Json] Minimal edit proposal, second round

[R S <[e-mail]>]

This looks good to me. +1.

- Rob


On Wed, Jun 26, 2013 at 8:47 AM, Paul Hoffman <[e-mail]> wrote:

> <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/>.
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>