Subject: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter

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

The chairs are seeking comment on whether we should adopt I-JSON
(http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our
charter. Remember that adopting this draft does not mean it is done;
changes can happen based on the consensus of the WG.

Note that the current draft does *not* have the new MIME type nor the
reserved field name that was heavily debated in London; that could be
added later if there is WG consensus to do so.

Please speak up whether or not you believe our charter should be amended
to include this work item.

--Paul Hoffman and Matt Miller

---

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

(unsurprisingly) +1

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: John Cowan <[email-masked]>
Date: Fri, 14 Mar 2014 19:31:17 -0400

> to include this work item.

+1

-- 
Business before pleasure, if not too bloomering long before.
        --Nicholas van Rijn
                John Cowan <[email-masked]>
                    http://www.ccil.org/~cowan

---

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

+1

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

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 15 Mar 2014 11:43:29 +0900

+1 

=nat via iPhone

---

From: "John Levine" <[email-masked]>
Date: 15 Mar 2014 03:26:50 -0000

>>> to include this work item.

Yes.

R's,
John

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 15 Mar 2014 15:12:30 +0900

> to include this work item.

Okay with me.

> added later if there is WG consensus to do so.

It's great that these are gone, and they shouldn't come back.

Regards,    Martin.

---

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

> changes can happen based on the consensus of the WG.

Yes, please do so.

> added later if there is WG consensus to do so.

A gentle "Please do not come back" from my side.

> --Paul Hoffman and Matt Miller

"All the best,
Stefan"

---

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

>changes can happen based on the consensus of the WG.

No, not without changing the nature of the document considerably. These
are just best practises and not a separate format with its own name.
-- 
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: John Cowan <[email-masked]>
Date: Sat, 15 Mar 2014 10:35:53 -0400

> are just best practises and not a separate format with its own name.

The idea, I think, is that if the receiver sees the new name it can make
more stringent assumptions about the input.  Indeed, given a name, certain
receivers can say they will *only* accept I-JSON.  It is analogous to the
"strict" declaration in JavaScript (or Perl, for that matter).

-- 
John Cowan       http://www.ccil.org/~cowan        <[email-masked]>
        You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
        You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
                Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)

---

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

>"strict" declaration in JavaScript (or Perl, for that matter).

For human-readable documentation purposes it is entirely sufficient to
say "follows RFC XXXX conventions" and implementations can just assume
the conventions are being followed until they detect otherwise (which
"I-JSON" implementations are required to do as currently proposed).
-- 
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: Tim Bray <[email-masked]>
Date: Sat, 15 Mar 2014 09:24:12 -0700

On Mar 15, 2014 9:17 AM, "Bjoern Hoehrmann" <[email-masked]> wrote:

> say "follows RFC XXXX conventions" and

What is XXXX?

implementations can just assume

---

From: John Cowan <[email-masked]>
Date: Sat, 15 Mar 2014 12:37:58 -0400

> > say "follows RFC XXXX conventions" and

The as yet unassigned number for the I-JSON RFC.  Bjoern is IIUC arguing
against a new MIME type specific to I-JSON.

-- 
If I read "upcoming" in [the newspaper]              John Cowan
once more, I will be downcoming                      http://www.ccil.org/~cowan
and somebody will be outgoing.                       [email-masked]

---

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

>against a new MIME type specific to I-JSON.

Yes, and also against inline identifiers and the name "I-JSON" (or any
other name) and anything else that makes avoiding the things the JSON
RFC says are an interoperability problem appear a format on its own.
-- 
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: Dave Cottlehuber <[email-masked]>
Date: Sat, 15 Mar 2014 18:53:56 +0100

> changes can happen based on the consensus of the WG.

+1 yes please.

> added later if there is WG consensus to do so.

FWIW I attended the Friday session in London; my main concern was having an interoperable approach that *didn’t* require developing an application/XXX+i-json for each application. 

--  
Dave Cottlehuber
Sent from my PDP11

---

From: Larry Masinter <[email-masked]>
Date: Mon, 17 Mar 2014 00:53:56 +0000

> * Matt Miller wrote:
> >.. adopt I-JSON
> >(http://tools.ietf.org/html/draft-bray-i-json-01) 

> are just best practises and not a separate format with its own name.

+1, no new name. best practices if you want to be a conservative sender.
Possibly validated in spoof-prevention scenarios.

---

From: Tony Hansen <[email-masked]>
Date: Sun, 16 Mar 2014 22:38:22 -0400

> are just best practises and not a separate format with its own name.

Based on the conversation that we had at the WG session in London, I 
came away convinced that:

     *) it does need to be a WG item
     *) we need neither a new media type nor a mandatory internal-tag 
indicating compliance with i-json, so that stuff needs to be removed 
from the document
     *) an optional internal-tag might need some more discussion
     *) the document should really just reflect a set of restrictions on 
the json format that can be (optionally?) validated against

- Tony Hansen

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Mar 2014 22:51:28 -0500

My main complaint is with the recommendation/requirement that JSON
texts be objects at the top-level.

Instead I would say that if there's reason to need to signal "schema"
metadata in-band then a) application should specify how they do that,
b) here's a few ways in which they might, and all their pros and cons.

Note too that there are many apps where there's no need to signal
schema metadata in-band because they always have some way to
communicate relevant metadata out of band.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Mar 2014 07:56:59 -0400

> communicate relevant metadata out of band.

I have no problem with this as a convention in a protocol. But I don't see
the need for that restriction in I-JSON.

In a protocol design the spec is going to say something like 'the encoding
is in the I-JSON subset of JSON'. Then its going to describe the format of
the data which for a protocol is almost always gonna be an object per
message at the top level. Though it could be an array of objects if
multiple requests per message are supported.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Mar 2014 10:21:34 -0500

> the need for that restriction in I-JSON.

If the purpose is to signal schema metadata then I'd like to explore
other conventions and go for a "you must provide such metadata"
statement in order to make yours an I-JSON usage.

> message at the top level. Though it could be an array of objects if multiple
> requests per message are supported.

Right, imagine wrapping an array of objects in an object just to
denote schema metadata.  What a pain.  You're probably streaming the
array, so now you gotta add an object around it -- and remove it -also
in a streaming manner- on the parser side.

Or perhaps you have a sequence of objects to return... should you mark
up every one of those objects?  While streaming them?  More pain.

We should consider how this markup happens.

Incidentally, we could say that the first text in a JSON text sequence
should denote schema metadata for the rest...  That would not be so
painful.  (although it would still interfere with existing usage).

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Mar 2014 13:48:56 -0400

> painful.  (although it would still interfere with existing usage).

As a general rule, whenever I see a proposal that depends on the order of
JSON objects, I think that either an Array or an Object needs to be
introduced.

I very much prefer this

{ "get-request" : {  .... request data here .... } }

to this:

{ "jscommand" : "get-request",
   ... rest of request data follows ...
   }

One of the things I have come to detest in HTTP is that it does not
separate protocol headers from content metadata. There really should be a
separation between the two so that it is possible to do things like signing
the content metadata.