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 : 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 : 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-----