Subject: [Json] Proposed rechartering for the JSON WG

From: Matt Miller <[email-masked]>
Date: Fri, 17 Jan 2014 15:50:04 -0700

Greetings again.  Now that the WG has completed its single goal (on
time! yay!), a decision needs to be made on what to do next.

Based on our earlier discussions, the Chairs believe the WG has two
items they want to work on:

- - I-JSON, the current draft of which is draft-bray-i-json-01.txt
- - Suggested guidelines for developers using JSON

In the latter category we have "guidelines for defining JSON objects
in other documents/protocols, to make sure that we use JSON primitives
for those definitions, and don't try to duplicate JSON grammar in ABNF".
We may have others as time goes on.

We propose the following charter:

- -----BEGIN CHARTER-----

Javascript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the
ECMAScript Programming Language Standard and was published in RFC 4627,
an Informational document. JSON has come into very broad use, often
instead of or in addition to XML. The JSON WG has already published
a standards-track update to RFC 4627.

The WG will work on two items:

- - a restricted profile of JSON designed to maximize interoperability;
  the starting point will be draft-bray-i-json

- - a set of guidelines for developers who use JSON

Milestones:

May 2014:    WG LC on a restricted profile of JSON
May 2014:    WG LC on a set of guidelines for developers who use JSON
June 2014:   IETF LC on a restricted profile of JSON
June 2014:   IETF LC on a set of guidelines for developers who use JSON

- -----END CHARTER-----

Does anyone have comments, questions, or other feedback on this proposal?

- -- Paul Hoffman and Matt Miller

---

From: Tim Bray <[email-masked]>
Date: Fri, 17 Jan 2014 16:01:58 -0800

> - - Suggested guidelines for developers using JSON

It sounds from your narrative that the latter might be rephrased as
“suggested guidelines for spec authors using JSON”?  The guideline for
developer is simple: “Don’t do anything that 4627bis identifies as getting
in the way of interoperability”.  What I heard at the Vancouver F2F was
more along the lines of “what terminology should RFC writers use to
describe the parts of a JSON message?

To be clear: I am unconvinced that the suggested-guidelines-for-developers
is really worth doing, if you have 4627bis identifying the problems and
I-JSON providing a maximally-interoperable profile.  I’m
neutral-to-positive on guidelines-for-spec-authors.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJS2bOcAAoJEDWi+S0W7cO1RGsIAJUfUETL8ZZEC4QH3gkS9m4x
> 1bqUuxln0Hjsp4TnAJ/Jc+r82wRiuq+ow/QcrY696haA8SwD1ktGn5890nNIVthb
> kpNImQY20sRMOCNZvlRyvf3+AstHmTar1Pve7CNSX07VX3VF8SeQGcA7vKiR5qNH
> K+2VJRNzPpyg3YPyg7t60aAxhuvupK1jWzfzmkJtQ+TTJ65REk2V+ScDXe3nnllT
> nqgp36XmZDfEQLOix4VUu67kAFwpgpfXj8a0n7zeE7ipYmYALM2bPKHy1NupFXtY
> nqTNmGEiJO/HgzZmW4+rhClJNcCJRaQVOkBsKISimC8B96PUZdEVkvQFhgap5/Y=
> =EmeZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 20 Jan 2014 19:51:44 +0900

On 2014/01/18 7:50, Matt Miller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

I have looked at this draft. The actual technical content (no duplicate 
names, no lone surrogates,...) is just fine. However, I strongly doubt 
the point of creating a separate Media type suffix
("application/XXX+i-json"). I think this will cause more confusion and 
fragmentation than benefit.

There is nothing explicit in the current charter that requires a 
separate Media type suffix, but I'm voicing this concern here because it 
may be seen as implied by the charter by some people.

Regards,    Martin.

---

From: Erik Wilde <[email-masked]>
Date: Tue, 21 Jan 2014 10:45:58 +0100

hello martin.

> may be seen as implied by the charter by some people.

i think i have made this point before, but i'll briefly repeat it. it 
would be possible to go a different route, and i am wondering what you 
think about this one:

- allow a "profile" media type parameter for the json media type (it 
could be added to JSONbis, and could look similar to the media type 
parameter drafted in http://tools.ietf.org/html/draft-wilde-atom-profile)

- define a profile URI for I-JSON in the I-JSON spec, and then define 
I-JSON to use the regular JSON media type. the fact that some JSON 
actually is I-JSON then could be (optionally) indicated by adding a 
profile media type parameter with that specific profile URI.

- any JSON-based media type then could simply use the +json suffix, and 
could allow the profile media type parameter to indicate I-JSON, if 
that's something that the media type wants to allow.

kind regards,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 21 Jan 2014 20:15:25 +0900

Hello Erik,

> that's something that the media type wants to allow.

I guess the following point also has been made before:

If you label the differences (it doesn't matter much whether that's done 
with a Media type suffix, with a parameter, with an URI, or what), you 
have the problem that something may be JSON, but not I-JSON, but still 
labeled as such. You then either check, which means people will just use 
JSON to not get errors, or you don't check, in which case I-JSON is 
useless from the start.

What we want to get to is that parsers have a setting so that for 
certain applications, where so specified, the input can be checked to 
avoid problems later on. In some cases, e.g. security-related stuff, 
"application" may be a whole Media type (e.g. 
application/securefoo+json). In other cases, it may be just an agreement 
between two parties, or a condition of using a service, to always send 
I-JSON, even if the same kind of data is used without necesarily 
adhering to I-JSON between other parties.

Regards,   Martin.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 22 Jan 2014 10:09:51 -0500

> - - Suggested guidelines for developers using JSON

Wasn't there also my item about language for representing JSON data
structures in other documents? (I presented that at IETF 88, and there
seemed to be interest, and Andy Newton also has a version of that.)

Barry

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jan 2014 16:21:22 +0100

> seemed to be interest, and Andy Newton also has a version of that.)

I am certainly interested in exploring that space.

Grüße, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jan 2014 08:31:37 -0800

> seemed to be interest, and Andy Newton also has a version of that.)

That was certainly part of what the second bullet, "- a set of guidelines for developers who use JSON", was meant to cover. I guess we were unclear about "developers" being both application developers and protocol developers". How about:

- a set of guidelines for application and protocol developers who use JSON

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Jan 2014 08:32:28 -0800

Barry, I think possibly you and I are saying the same thing.  What I
thought we talked about at IETF88 was a standardized way to refer to the
constructs found in JSON texts, to be used by people drafting specs for
protocols with JSON payloads.   If that’s what you mean by “representing
JSON data structures in other documents”, I agree that’s a better use of WG
time than “guidelines for developers”

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Jan 2014 08:34:59 -0800

> - a set of guidelines for application and protocol developers who use JSON

I still think that’s not what we talked about at IETF 88.   I think Barry
and others talked specifically about language for describing JSON
constructs for use by protocol developers.  I also think that I-JSON,
assuming we get consensus, represents “guidelines for developers”.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Jan 2014 11:19:43 -0800

On Jan 22, 2014, at 8:34 AM, Tim Bray <[email-masked]> wrote:

> I still think that’s not what we talked about at IETF 88.   I think Barry and others talked specifically about language for describing JSON constructs for use by protocol developers.  

Yes, exactly. I thought that would be part of the above. If there is better wording to get Barry's point in there, please suggest.

> I also think that I-JSON, assuming we get consensus, represents “guidelines for developers”.

The current draft isn't a "guideline", it is a specific profile with MUSTs.

--Paul Hoffman

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 22 Jan 2014 20:45:20 +0000

On 1/22/14 9:34 AM, "Tim Bray" <[email-masked]> wrote:

>I still think that¹s not what we talked about at IETF 88.   I think Barry
>constructs for use by protocol developers.

Yes.  The way I remembered this was "something like ABNF for JSON-based
protocols".

>I also think that I-JSON, assuming we get consensus, represents
>³guidelines
> for developers².

+1

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Jan 2014 13:06:05 -0800

On Wed, Jan 22, 2014 at 11:19 AM, Paul Hoffman <[email-masked]>wrote:

> “guidelines for developers”.
>

Right. So, the guideline is: “For maximum interoperability, specify the use
of I-JSON”.   My concern is that a best-practices doc is going to end up
just echoing I-JSON: No dupes, no busted Unicode, no top-level primitives,
etc...

---

From: Stefan Drees <[email-masked]>
Date: Thu, 23 Jan 2014 10:35:47 +0100

> Yes.  The way I remembered this was "something like ABNF for JSON-based

I second, that we should aid future specification writers to write ABNF 
for JSON-based protocols with ease.

>> I also think that I-JSON, assuming we get consensus, represents

As I-JSON IMO names everything important (with assumed consensus) in the 
developer arena, I see no benefit in working on "guidelines for 
developers", but only disadvantages (as it might cost momentum needed 
for finding consensus on I-JSON).

"Stefan"

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 23 Jan 2014 18:07:43 +0000

>for finding consensus on I-JSON).

If there *are* other important considerations for developers that are not
currently in I-JSON, we could decide to add them to that document,
couldn't we?

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Jan 2014 10:58:48 -0800

What Joe said.  I think that I-JSON constitutes advice for protocol
designers on how to achieve maximum interoperability.  That’s an obvious
80/20 point and has the virtue of being mechanically verifiable; once you
get past it, you get heavily into opinion-space. For example, should your
protocol be versioned and where should the version number go?  Eek!  Here
be bikesheds.

Perhaps the word “nomenclature” would be useful.  Let me try to re-spin
Matt’s original draft. I’m also going to take out the relationship-to-XML
piece, which adds no useful information.  Also, I think JSON was actually
originally derived from de-facto JavaScript Object Notation independent of
any standardization activity, but whatever.
===========================================================
Javascript Object Notation (JSON) is a lightweight, text-based,
language-independent
data interchange format. It was derived from the ECMAScript Programming
Language Standard and was published in RFC 4627, an Informational document.
JSON has come into very broad use. The JSON WG has already published a
standards-track update to RFC 4627.

- - a restricted profile of JSON designed to maximize interoperability;
the starting point will be draft-bray-i-json.

- - a standardized nomenclature for referring to the constructs in a JSON
text, for use by those specifying protocols with JSON payloads.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 24 Jan 2014 04:06:38 +0000

With respect to guidelines for using JSON, one model might be BCP 70 / RFC 3470, "Guidelines for the use of XML within IETF Protocols". 

You might question the utility of such a document, but RFC 3470 seems to be reasonably popular in citations from Internet Drafts and a few RFCs here and there.

More controversial but also useful would be to point out the considerations for using JSON vs. alternatives (much as section 3 of RFC 3470 talks about alternatives to XML).

Larry
--
http://larry.masinter.net

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Jan 2014 20:37:46 -0800

Hm, I just looked through 3470 again, and it’s a fine piece of work.
 Having said that, the vast majority of the material there is very specific
to XML’s idiosyncracies, and it’s hard to think of what the corresponding
guidance would be in JSON, since JSON is so much simpler.

The single exception that struck me was section 4.11, about embedding
binary data in an XML document; I can believe that there might be useful
guidance for designers of JSON-based protocols that wouldn’t bikeshed
horribly.  I guess the default position would be “If you can’t use separate
message bodies with their own media-types, then use base64”?

On Thu, Jan 23, 2014 at 8:06 PM, Larry Masinter <[email-masked]> wrote:

> With respect to guidelines for using JSON, one model might be BCP 70 / RFC
> 3470, "Guidelines for the use of XML within IETF Protocols".
>
> You might question the utility of such a document, but RFC 3470 seems to
> be reasonably popular in citations from Internet Drafts and a few RFCs here
> and there.
>
> More controversial but also useful would be to point out the
> considerations for using JSON vs. alternatives (much as section 3 of RFC
> 3470 talks about alternatives to XML).
>
> Larry
> --

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 24 Jan 2014 15:47:10 +0900

> guidance would be in JSON, since JSON is so much simpler.

Well, one important point may be that because it's so simple, it invites 
people to invent things on top of it. People try to invent conventions 
for comments, convents for encoding textual markup (where in most cases 
XML would be the better solution), and so on.

Some of the ways of doing such things make sense in some situations, but 
in other situations, or done other ways, or also just in general, may 
not make much sense, and a document could point this out.

Regards,   Martin.