Subject: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter

From: Matt Miller <[email-masked]>
Date: Fri, 14 Mar 2014 17:22:22 -0600

The chairs are seeking comment on whether or not the WG wants to adopt
one or more nomenclature / schema / description documents in the WG
charter. A few such documents have been brought to the WG, but our
initial take is that the WG doesn't want to make any of them WG
documents. They could proceed towards becoming RFCs without any
interaction from the WG, depending on the wishes of the ADs and/or the
Independent Stream Editor. Once a nomenclature document is an RFC, other
RFCs could use it to describe the JSON in those later RFCs.

Please speak up whether or not you believe our charter should be amended
to include a work item that would adopt one or more nomenclature /
schema / description documents.

--Paul Hoffman and Matt Miller

---

From: Tim Bray <[email-masked]>
Date: Fri, 14 Mar 2014 16:27:46 -0700

I’m generally opposed to this work item on the basis that nobody has
provided an example of an existing RFC that would clearly be improved by
the availability of such a thing.

On Fri, Mar 14, 2014 at 4:22 PM, Matt Miller <[email-masked]> wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Mar 2014 20:30:37 -0400

On Fri, Mar 14, 2014 at 7:27 PM, Tim Bray <[email-masked]> wrote:

> I'm generally opposed to this work item on the basis that nobody has

I think RFC 6962 could be improved substantially with some greater
adherence to some structure.

Like many JSON Web services, message data is split between the message
contents and the URL.

More importantly, I would like to kill all the parts of the document that
specify the TLS data format (using a schema) and replace them with JSON
structures. But that isn't going to be possible without a better way to
define structures.

I don't think it is just a JSON issue though. While implementing TRANS I
added support for the TLV format to the parser. I have not yet added it to
any of the encoder or decoder libraries though.

It is pretty clear that the proposers of CT are only interested in
addressing notary services for the certificate application and so they are
obsessed with size and compactness. Which is fine. But I certainly don't
wish to carry that data encoding into any other notary application. So
being able to write a schema that allows the data structures to be rendered
in the legacy TLS encoding and in JSON becomes quite important.

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Mar 2014 19:56:56 -0500

On Fri, Mar 14, 2014 at 7:30 PM, Phillip Hallam-Baker <[email-masked]> wrote:
>> provided an example of an existing RFC that would clearly be improved by the
>> availability of such a thing.
>
> I think RFC 6962 could be improved substantially with some greater adherence
> to some structure.

It would also benefit from JSON text sequences...

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Mar 2014 18:58:27 -0700

On Mar 14, 2014, at 5:30 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> I think RFC 6962 could be improved substantially with some greater adherence to some structure.

Could you maybe take that discussion to the trans working group? It is not relevant to this WG. Thanks!

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Fri, 14 Mar 2014 18:59:42 -0700

Actually, I think it is relevant.  If someone were to show an example of an
RFC where a hypothetical nomenclature/schema spec would have made the RFC
better, that would be a really good argument in the current charter
discussion.

---

From: Tim Bray <[email-masked]>
Date: Fri, 14 Mar 2014 19:08:27 -0700

On Fri, Mar 14, 2014 at 5:30 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> ​​

​Could you be specific?  I just glanced at 6962 and it’s not obvious. ​

​​

​​

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Mar 2014 19:23:32 -0700

On Mar 14, 2014, at 6:59 PM, Tim Bray <[email-masked]> wrote:

> Actually, I think it is relevant.  If someone were to show an example of an RFC where a hypothetical nomenclature/schema spec would have made the RFC better, that would be a really good argument in the current charter discussion.

Phill's proposal is to change the protocol from using ASN.1 to JSON. That's a discussion for the other WG, not here.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Mar 2014 22:55:53 -0400

> relevant to this WG. Thanks!

Tim asked for an example of a JSON specification that would be improved by
a schema. I gave him one.

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Mar 2014 22:02:09 -0500

> Phill's proposal is to change the protocol from using ASN.1 to JSON. That's a discussion for the other WG, not here.

That's not Phil's proposal.  Look carefully!  Search for "array" and
"object" in the RFC.

(I also wondered wth Phil was talking about when I glanced at that RFC.)

Nico
--

---

From: Stefan Drees <[email-masked]>
Date: Sat, 15 Mar 2014 11:57:47 +0100

> schema / description documents.

+0 on opening up for inclusion. I think discussion / inspection of 
additional examples (besides RFC 6962) would help guide us to a 
well-informed consensus in that regard.

> --Paul Hoffman and Matt Miller

"All the best,
Stefan"

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 15 Mar 2014 13:55:43 +0100

On 15 Mar 2014, at 11:57, Stefan Drees <[email-masked]> wrote:

> additional examples (besides RFC 6962) 

How about the ALTO schema language:

http://tools.ietf.org/html/draft-ietf-alto-protocol-27#section-8.2

This is interesting, as its expressivity has been designed (limited) for the specification style at hand.

I haven’t checked this, but it might have worked for the style used in RFC 7071, too.

Grüße, Carsten

---

From: David Rosenborg <[email-masked]>
Date: Sat, 15 Mar 2014 14:21:43 +0100

Hi,

For schema language inspiration you might wan't to have a look at http://blinkprotocol.org/s/BlinkSpec-beta4.pdf. Specifically section 7 covers the overall schema grammar.

Obviously this is outside of IETF but I believe that the schema language has some merits for describing JSON-based protocols. There is a JSON mapping available here: http://blinkprotocol.org/s/BlinkJsonSpec-beta4.pdf

Disclaimer: I'm on the team developing the open source Blink protocol so you could opt to regard this as off topic or simply as a shameless plug ...

Kind regards,

David Rosenborg

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 15 Mar 2014 14:48:16 +0100

>schema / description documents.

There are various efforts in the area and they do not seem to need an
IETF WG at this moment.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Mar 2014 10:45:53 -0400

> There are various efforts in the area and they do not seem to need an

I would like to have consistency if possible.

I would also like to avoid doing what happened with XML where the first six
months of every WG I was part of spent six months at the start discussing
how to use XML.

And I would really like to avoid what happened with SAML where we had to
redo the spec because the approach taken to modularity turned out not to
work.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Mar 2014 08:14:28 -0700

> (I also wondered wth Phil was talking about when I glanced at that RFC.)

Wow, I totally missed that too. My apologies to Phill for cutting him off on the discussion of CT logs.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Mar 2014 09:50:26 -0700

Here's a JSON format that could definitely use a simple JSON description language of some sort. The draft authors went the ABNF route, and it's completely unclear where they are going until you look at the examples and realize how trivial the format really is.

http://tools.ietf.org/html/draft-dulaunoy-kaplan-passive-dns-cof

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 15 Mar 2014 18:03:17 +0100

> Here's a JSON format that could definitely use a simple JSON description language of some sort. The draft authors went the ABNF route, and it's completely unclear where they are going until you loo…

One extremely useful result this WG could have is eliciting an IESG statement that ABNF representations of JSON schemas are verboten.

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Mar 2014 13:33:06 -0400

On Sat, Mar 15, 2014 at 12:50 PM, Paul Hoffman <[email-masked]>wrote:

> Here's a JSON format that could definitely use a simple JSON description
> language of some sort. The draft authors went the ABNF route, and it's
> completely unclear where they are going until you look at the examples and
> realize how trivial the format really is.
>

Yuk.

ABNF should be reserved for describing an encoding scheme. I am pretty
unhappy with the way it is used in RFC2822 and in HTTP. The designer of
each header has complete flexibility to choose whatever whacky encoding
scheme they like.

Remember that standards are agreements on stuff that does not matter.
Whether the tag is encoded one way or the other does not matter. But once a
choice is made, the spec should stick to it.

---

From: Tim Bray <[email-masked]>
Date: Sat, 15 Mar 2014 11:09:25 -0700

That I-D would be greatly improved by tossing the ABNF and just using
English, saying what the names of the fields and the allowed values for
them are.  “Better than ABNF” isn’t what we’re trying for; “Better than
reasonably-well-edited English” is.  I still haven’t seen an example where
a schema language would meet that criterion.

Seriously, if nobody can find an example where schema/nomenclature would
actually improve a real existing non-hypothetical document, I think it
would be silly for the WG to proceed with inventing a solution to a
non-problem.

Also, that I-D does something else that seems really wrong: Says that the
the JSON objects must be expressed on a single line.  Hmmm

 -T

---

From: Tim Bray <[email-masked]>
Date: Sat, 15 Mar 2014 11:10:49 -0700

+1

On Sat, Mar 15, 2014 at 10:03 AM, Carsten Bormann <[email-masked]> wrote:

> One extremely useful result this WG could have is eliciting an IESG
> statement that ABNF representations of JSON schemas are verboten.
>
> Grüße, Carsten
>