The application/json Media Type for JavaScript Object Notation (JSON)
draft-crockford-jsonorg-json-04

[Ballot comment]
If for any action, it would be an Note to the RFC Editor, but this
is mainly for the APP intellectual apparatus:

Out of curiosity - I'm surprised by RFC 20 being this doc's cite
for ASCII.  I see that Wikipedia includes this reference (also RFC 1345,
which was not yet made Historic, but maybe should be).  RFC 20 is very
short and clear - is it still an accurate* source for ASCII?

[Ballot comment]
Not for action coming back to me:

Just a comment our of curiosity - I'm surprised by RFC 20 being this doc's cite
for ASCII.  I see that Wikipedia includes this reference (also RFC 1345, which
it seems we should make Historic).  RFC 20 looks very short and clear - is
it still an accurate* reference?

[Ballot comment]
I had to read quite a bit of the document before I realized that this document basically is just requesting a MIME-type registration and has good documentation to go with it first.

So I wondered if the title would be better changed to somethinge like:

  The application/json media Type for JavaScript Object Notation (JSON)

Bert

[Ballot discuss]
RFC 2045 states that any text subtype must specify whether or not it will use the
charset parameter and what, if any, restrictions are placed on it.  I believe this
text:

      JSON may be represented using UTF-8, UTF-16 or UTF-32. When JSON
      is written in UTF-8, JSON is 8bit-compatible. When JSON is written
      in UTF-16 or UTF-32, the binary content-transfer-encoding must be
      used.

indicatest that the authors do want to restrict the available charsets.  I believe
that means that they need to specify that parameter; if not, then the text
needs to be updated to indicate how this works with the default text charset,
US-ASCII.  See section 4.1.2 or RFC 2046.

I agree with Sam that this looks more like an application/ registration to me,
and if the author chooses, this can be resolved by making this application/json.

AD evaluation comments:

The title should include the JSON acronym used elsewhere in the document.  Please use this:  "JavaScript Object Notation (JSON)".

Abstract: Please change the JSON acronym expansion to match the title.  That is, please change this:

JSON (JavaScript Object Notation)

to this:

JavaScript Object Notation (JSON)

Section 1: Please cite the appropriate Unicode standard where Unicode is first mentioned.

Some examples would be a nice addition to the text in some appropriate place.

Please strike section 7 and put it in section 6 with appropriate updates.

Section 7: Please describe the applications that use this type instead of pointing to a URL.  Please add contact info for yourself in the template as that info appears in the IANA registry.  Please put the Security Considerations from section 8 into the template itself for the same reason.  You can then point to the text in section 6 from the document's Security Considerations section.

Two-week review on the ietf-types@iana.org list is required.  Please send a note to that list describing your request for review of this media type registration request.  You can just point to the I-D instead of copying lots of text in your note.

id-nits output:

tmp/draft-crockford-jsonorg-json-02.txt(121): Line has weird spacing: '...  false  null...'


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
   
    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - The page length should not exceed 58 lines per page, but there was 1
    longer page, the longest (page 1) being 407 lines

  Miscellaneous warnings:
  - The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation
    clause.

    No nits found.