Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard

[Tim Bray <[e-mail]>]

On Thu, Dec 5, 2013 at 7:34 AM, Paul Hoffman <[e-mail]> wrote:

> <no hat>
>
> >   This document makes no changes to the definition of JSON; it repairs
> >   specification errors and offers experience-based interoperability
> >   guidance.
> >
> > I believe historical considerations do not belong into the abstract (but
> into the Introduction)
>
> This seems like bikeshedding, and the text has been where it is for a long
> time.
>

Let me introduce an argument whiich I’ll label LNS.

LNS: This is not obviously incorrect, the text is reasonably idiomatic and
clear, and we’ve had excellent interoperability. Let’s not screw around
with it.

> Are we sure that we do not need the "pre-5378 escape clause" here?
> (Section 4 of <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>)
>
> Good catch, yes.
>

Uh, I looked at that doc and I’m not sure I get it. What do you want to
change?


> > Maybe note which productions are imported as well (HEXDIG and DIGIT it
> seems).
>
> Sure.
>

LNS


> > s/fix errata/apply errata/ ?
>
> Sure.
>

An erratum is a description of an error.  We want to fix the error.
Also, LNS.


> >   JSON text SHALL be encoded in Unicode...
> >
> > That's a bit misleading. How do I "encode in Unicode"? I think what it
> tries to say is that one of the Unicode-compatible character encoding
> schemes needs to be used.
>
> This was a swamp where consensus seemed impossible to reach.
>

I thought about this one quite a bit.  Yes, this is flawed, but the actual
state of affairs is that per 4627, JSON can be encoded in any encoding of
Unicode and what’s being encoded aren’t code points but code units, and I
could write a 3-and-a-half sentence introduction which would make people
say WTF, but in fact this sentence fragment makes it reasonably obvious
what’s going on. Let’s not change it.

>   An implementation may set limits on the size of texts that it
> >   accepts.  An implementation may set limits on the maximum depth of
> >   nesting.  An implementation may set limits on the range and precision
> >   of numbers.  An implementation may set limits on the length and
> >   character contents of strings.
> >
> > Maybe this should be a bullet list?
>
> Bikeshed
>

LNS.


> > 10.  Generators
> >
> >   A JSON generator produces JSON text.  The resulting text MUST
> >   strictly conform to the JSON grammar.
> >
> > "strictly"?
>
> You would prefer "squishily"?
>

LNS.


> >   o  Changed Working Group attribution to JSON Working Group.
> >
> > ...this is a change that will not be visible in the RFC.
>
> OK. Oh, and drat, I totally forgot to update this section per -08.
>
> --Paul Hoffman