Minutes for JSON at IETF-89
minutes-89-json-1

JSON WG  - IETF 89 London
==============================================================
2014-03-07 @ 11:50 - 13:30 GMT

[ Thanks to Tony Hansen for minutes, and Joe Hildebrand for
  XMPP MUC room relaying ]

1. WG Status
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
draft-ietf-json-rfc4627bis published as RFC 7159 on Monday
(2014-03-03), which obsoletes RFC 7158 which obsoletes
RFC 4627.

At this point, the JSON WG has completed all of its chartered
items.

2. I-JSON
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Tim Bray (via Matt Miller) gave a presentation on I-JSON.  The
discussion in the room focused almost exclusively on the pros
and cons of an explicit indicator (media-type, media-type
suffix, embedded property).  The primary arguments for having
some form of indicator were to provide a way for producers to
indicate the conformance level of the content.  The primary
arguments against having some form of indicator were that it
would lead to interoperability problems with existing software
that is not already aware of I-JSON but might still be
conformant.

No form of consensus was reach in the room; discussion
will continue on the list.

3. Nomenclature
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Two presentations on nomenclature approaches were given:
ProtoGen by Phil Hallam-Baker (via Paul Hoffman), and JSON
content rules by Andy Newton.  The discussion in the room
focused mostly on the arguments for and against defining a
specific approach; prose-like text, a schema language, or a
concise ABNF-inspired format.

No form of consensus was reach in the room; discussion will
continue on the list.

4. OMA Request for Stable JSON Schema Reference
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Pete Resnick talked about a request from OMA (Open Mobile
Alliance) for a stable reference to JSON Schema by Chris Zip
(et al).  The sense in the room was that Zyp's draft can move
forward as Informational to satisfy OMA's needs, and for the
discussion on whether or not to define others (schemas,
notations, et al) to continue.

Eliot Lear (in his role as a coordinator of liaisons in the
IAB) requested that anyone with good contacts within OMA to
talk to him.  There is no relationship in place between the
IETF and the OMA to date.

-----BEGIN RAW LOGS-----

# I-JSON - 20 min
     draft-bray-i-json

## Media type

ACTIONS:
* Discuss on the list, especially the use of a media-type
* No hums taken, no decisions made

Arguments against inclusion:
    - doubtful how widely this will be used
    - "application/json" consumers might not be able to participate
    - other ways to deal with this (error codes, etc)

Arguments for inclusion:
    - "moral hazard" for those that assume they can use existing JSON parser
    and have it always work (even in error conditions)

# Charter question: standardized nomenclature for JSON constructs - 60 min

## Presentation by Phill Hallam-Baker
* channeled by Paul Hoffman

## Presentation by Andy Newton

## General Discussion

ACTIONS:
* No hums taken, no decisions made
* Discussion to continue on the list

Tim Bray: Anything that ventures even slightly into schema territory is
actively harmful because it distracts WG from getting the normative English
text right. TB: Any sane protocol is going to have lots of constraints that
can’t be expressed in any schema language. TB: Haven’t seen an example of a
JSON-based APi where a schema would have improved the specification. Larry
Masinter: Are there examples? Andy Newton: WEIRDS had this happen because the
prose was not precise enough. Tony Hansen: I like some of those examples from
reputon where the ABNF as very difficult to read.  Understanding what the
WEIRDS JSON looked like, you needed to look one level above the
bits-on-the-wire.  I found it useful to think at that level.  Another topic, we
had discussion on CBOR decriptor language, and now we are talking about JSON
schema language.  There ought to be synergy between these efforts.  The
conceptual level for both CBOR and JSON should be very similar. Lief Johansson:
What makes the stack for JSON so much different from XML?  There is a
difference from protocol specifications and extension points.  Schema helps
with extension points. Mark Nottingham: I strongly agree with Tim that schema
languages is not the right direction.  The prose language is quite interesting.
 There is a tendency to describe things as higher-level constructs you are
encouraging some patterns and discouraging others, which might be too broad for
the JSON WG to do. Paul Hoffman <no hat>: I agree with you.  But one output is
not a single one, and others could use whichever they wanted.  Would you only
want to read the prose, or would you be willing to learn the schema. MNOT: Some
WG that I care about wanting schema I would jump up and down against, but
another I wouldn't really care. Julian Reschke: I think we hvae consensus not
to develop schema.  As for formalisms, I think that's a good idea. I don't know
if it's necessary to have a single one, but it would be useful to have a good
example for that.  As an aside, this is similar to what we are doing with the
XML2RFC schema. PH <no hat>: The XML2RFC draft includes a DTD generated from
RelaxNG, but there is a tool that breaks out the prose.  I have a v3 tool that
does something similar. Justin Richer: My experience, I have never once liked a
schema; I have never once gotten something useful out of it.  I just want a
formal description of the object mobel.  Sometimes that's a schema, but
sometimes it's not.  Developers don't read schemas, they are for tools.  I
would strongly encourage to keep that developer mindset in mind. Yoav Nir: +1
to Justin.  The thing with schema is that they are meant for computers, but not
for developers.  We would get better result if we possibly restricted what the
prose ought to say. Dave from Couch: As a developer, I agree that reading
examples are what most people do.  But as a way to comply with the definition,
it is very useful. Dave from Couch: I think for IETF documents, a formal
grammar is very useful. Lief Johansson:  I wasn't really arguing for schema as
much for method models.  Why is this very very different from other
communities? Tony Hansen: When I'm writing an RFC with XML2RFC and I get a
strange message from the parser, I go to the schema to see what I was supposed
to do.  The schema told the XML2RFC parser what was valid, and it told me.  I
was part of a team that implemented SASL SCRAM specs, and members of the team
were trying to figure out why they couldn't get the hash right, but they hadn't
actually looked as the ABNF. Chris Newman: I strongly agree that schema
languages constrain the solution space.  ABNF is great for octets on the wire,
but bad for higher constructs.  What is the primary purpose of an RFC?  It is
to improve interoperability, and this is something ABNF does.  I think examples
are great, even corner cases, but schema do help. Tim Bray: An open source test
harness is way better than a schema. John Levine: I find ABNF but others do
not.  I don't think we'll find consesnsus here. MNOT: Shcema can be used to
improve interoperability, but there is a lot of experience here with the bad
results of XML. I think that XML experience is informing a lot of people in
this list.  I don't think anyone is saying "Thou Shalt Not Use," but if they
are that's not defensible.

No hums taken, no decisions made

# Other stuff - Remainder of time

## About OMA wanting a JSON Schema
 (Pete Resnick)

MNOT: I think it's fine to publish Zyp's draft as informational.  Do they need
a Standard, or just a stable reference?  An Informational RFC is sufficient for
a stable reference. Joe Hildebrand: I agree with Mark, and I think Andy should
maybe see about getting that [content rules] published as an Informational RFC,
et al.  If we were to say "Schemas are bad, and you are a bad person" (which is
fine here), then we need to document that.  We can state this in a way where
the IETF never wants to be involved, or state it in a way where we might want
to be. Eliot Lear: We do not have good contacts with OMA, please come speak
with me if you know some good contacts to them. MNOT: I'm not sure we are
onboard with saying schemas are verboten, but if we are, then we need to write
that down somewhere. Pete Resnick: What I am hearing is that we are not onboard
doing this work now, but we might be interested in doing that in the future.
Paul Hoffman: We need to be clear that JSON Schema is one possible approach,
not the approach.

No hums taken, no decisions made

## Best Practices for JSON?

<< ran out of time >>

-----END RAW LOGS-----