JSON WG - IETF 88 Vancouver
==============================================================
2013-11-05 @ 13:00-14:00 PST

[ Thanks to Andrew Biggs for taking minutes, Joe Hildebrand for
  Jabber monitoring ]

1. WG Draft Status
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Chairs summarized state of working group since IETF 87. Virtual
meeting held in late August, where WG decided on an approach to
completing 4627bis.  For each major issue:

* discuss what the most interoperable approach is
* note the known common interoperability challenges

The current document reflects the consensus of the WG to date.
AD completed review just before the meeting, with a couple of
nits:

* Update the abstract
* Update the UNICODE reference

Regarding the UNICODE reference, there is a question of which
reference the document should use:

1) Use UNICODE preferred "latest version" URL
   (aka "version-less")
2) Use UNICODE version 4.0
   (what RFC 4627 contains today)
3) Use UNICODE version 6.3
   (what EMCA-404 contains)

The consensus in the room is for #1, but to also include a short
rationale for using a version-less reference.  The suggestion in
the room is for something like:

""""
We do not expect future changes in the UNICODE specification
to impact the grammar
""""

The next step is for Tim to publish 4627bis-07 with the AD nits
addressed, then the Chairs will request Pete Resnick to move
forward with IETF Last Call.

Joe Hildebrand suggested that we (either as individuals or as
the IETF) should file an erratum with Ecma on their use of a
specific UNICODE version.  He also suggested that we should
have a formal liaison relationship with Ecma TC-39 even if it
is for this one purpose.  Barry Leiba to discuss this with the
Internet Architecture Board (IAB).

2. SDO Interaction Status
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Ecma International recently published ECMA-404: The JSON Data
Interchange Format.  The document matches the syntax of 4627
(and 4627bis) except for what is allowed at the top-level:
4627bis keeps the limitation from 4627 of only object or array,
and EMCA-404 allows for any JSON value.  ECMA-404 does not
contain any the semantics or interoperability discussions.

Ecma International and W3C Technical Architecture Group (TAG)
expressed some concern about forking of specifications, but
neither group has formally requested a change or discussion.
Wendy Seltzer (W3C liaison to IETF) stated that she does not
expect a formal statement to come from the W3C.

3. I-JSON
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Tim Bray presented on I-JSON, a profile of 4627bis that
enforces certain limits that match the interoperability
suggestions from 4627bis.

Some discussion on the technical merits and weaknesses of
I-JSON, however the Chairs requested the meeting focus on the
interest or objection to such work in general. In the room,
there appears to be interest in moving forward on a profile of
JSON.  Mark Nottingham (IETF liaison to W3C) suggested that
there would be significant interest in this from the W3C TAG.

4. Documenting JSON in Protocols
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Barry Leiba presented on the need for a standard format that
protocol documents follow to describe their JSON data.
Included in the presentation was one possible approach.

Andy Newton pointed out that he has a (now expired) draft that
defines a formal language (draft-newton-json-content-rules).
There was general consensus in the room that some type of
description format is worthwhile.

5. JSON Schema Requirements
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Paul Hoffman presented on a possible approach for defining
schema requirements (but not the schema itself).  The proposal
does not itself call for an actual document to be ratified,
per se, but to be used as input on defining a schema.

Some came to the microphone to describe actual harm done by
schemas for other formats (most notably XML).  The consensus
in the room is that working on schema requirements is not a
worthwhile activity of the WG, and might be harmfully
distracting.

6. Wrapping up - Other Items
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Larry Masinter requested the WG consider a Guidelines document
for not only how to use JSON, but also describe when it might
be appropriate (or not) to use JSON versus other common data
formats.  The Chairs agreed to bring this item up to the
Working Group.

No other requests for Working Group items were made in the
room.

7. Wrapping up - Questions to WG
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Because of the large amount of participation on the mailing
list, no questions on specific work items was made in the
room.  The chairs did ask the following:

* Is anyone interested in reviewing documents?
  (several hands)
* Is anyone interested in providing text or authoring
  documents? (much fewer hands)

The Chairs and AD will come up with a list of specific
questions, then provide an initial charter proposal to submit
to the WG.