Re: [Json] Two Documents

[Tim Bray <[e-mail]>]

I think we have widely-shared agreement on two documents, a JSON spec and a
best-practices doc.  Just a word of caution, though: Our profession has
ample experience with the notion of “abstract syntax” - in ASN.1 and in
SGML.  Neither of which ever exhibited good usability in Internet
protocols.

One of the central defining virtues of the Internet and the Web is that
there are no object models or APIs, just messages. It is the job of the
IETF to define the message formats and interchange patterns.  Which is to
say, a document that defines a syntax but omits discussion of how that
syntax is expressed in bytes for transmission on the wire is not really
appropriate subject matter for the IETF.

The end-goal is pretty clear, I think: As someone who regularly works on
the design of network protocols based on JSON, I want an RFC to turn to
that will have nice crisp definitions of “JSON text”, “object”, “array”,
“string”, “number” and “boolean” so I can use those confidently in my
protocol design, and also sufficient precision about byte encoding that I
can rely on infrastructure builders to have created interoperable libraries
that work well on a variety of platforms and architectures.

It would also be nice if there were a best-practices document so that
someone could review my design and berate me for something stupid like
allowing the use of duplicate keys, and have something to point to.

So... two documents, yes.  Abstract syntax, no.

 -T


On Thu, Jun 13, 2013 at 8:50 AM, Douglas Crockford <[e-mail]>wrote:

> The confusion and controversy around this work is due to a mistake that I
> made in RFC 4627. The purpose of the RFC, which is clearly indicated
> in the title, was to establish a MIME type. I also gave a description of
> the JSON Data Interchange Format. My mistake was in conflating the two,
> putting details about the MIME type into the description of the format. My
> intention was to add clarity. That obviously was not the result.
>
> JSON is just a format. It describes a syntax of brackets and commas that
> is useful in many contexts, profiles, and applications. JSON is agnostic
> about all of that stuff. JSON shouldn't even care about character encoding.
> Its only dependence on Unicode in the hex numbers used in the \u notation.
> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can
> be used in contexts where there is no character encoding at all, such as
> paper documents and marble monuments.
>
> There are uses of JSON however in which such choices matter, and where
> behavior needs to be attached to or derived from the syntax. That is
> important stuff, and it belongs in different documents. Such documents
> will place necessary restrictions on JSON's potential. No such document
> can fit all applications, which causes much of the controversy we've seen
> here. One size cannot fit all. JSON the format is universal. But real
> applications require reasonable restrictions.
>
> So we should be working on at least two documents, which is something we
> have
> discussed earlier. The first is The JSON Data Interchange Format, which is
> a simple grammar. The second is a best practices document, which recommends
> specific conventions of usage.
>
> ______________________________**_________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>