Subject: [Json] Media types, extensibility in draft-ietf-json-i-json-02

From: Mark Baker <[email-masked]>
Date: Tue, 1 Jul 2014 20:04:01 -0700

Greetings,

There's no mention of which media type I-JSON content should use. A
quick check of the archives shows recent discussion about
application/xxx+i-json and application/i-json, but I don't know why it
isn't yet in the draft. I think it's essential to get this correct,
given the compatibility goals of the format.

FWIW, I agree that a non +json type is required, and also agree that
its short name should be usable as a suffix. So I'd personally go with
application/ijson and application/*+ijson as I expect many will find
the use of "-" confusing in suffix form.

The must-ignore/must-understand section also seems out of place here.
"must understand" has historically not referred to a lack of
extensibility, but to an inline declaration that some particular
extension cannot be safely ignored (see SOAP). Instead it's used here
as the opposite of "must ignore". And I also don't particularly care
for the characterization of the extensibility of a data format in
terms of implementation behaviour; the point is not that
implementations "must ignore" unknown extensions, it's that the format
is designed so it can be interpreted piecemeal[1], and that seems to
already be part of the assumed fabric of JSON (luckily, schema-think
hasn't yet taken over JSON-land) so doesn't seem worth mentioning. I'd
suggest removing this section.

 [1] http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Jul 2014 10:40:37 -0400

> given the compatibility goals of the format.

I disagree.

The only use for Content-Type is for content negotiation. There is no
situation in which a negotiation that makes a distinction between JSON and
I-JSON makes any sense.

Content identification that tells me a document is JSON is useless unless I
know the schema or purpose of the document.

If I write a protocol then I am going to tell people to use I-JSON encoding
or there is no value to it. If the sender has an option to choose between
JSON and I-JSON then I have to implement both and nothing is saved or
simplified.

There is one situation in which I might use a content type and that is
where a protocol is offered in more than one encoding. For example, SAML in
JSON. If I have an application that has no XML except for one Web Service I
might well offer that service in JSON or XML. Another case where
negotiation is frequently desirable is where a protocol designer has become
confused by REST ideology and has the idea that request parameters should
be URI encoded and responses returned in JSON. Many of us would much prefer
to do everything in one format.

So I don't see any reason to revisit the issue of a content-type. JSON and
I-JSON are the same thing as far as content negotiation is concerned and
the distinction is useless for content identification.

Where it would be useful to revise things would be to define a particular
way to specify the semantics of a JSON document, or at least the protocol
family.

For example, I have a protocol that allows a client to retrieve the current
phinger (.phb) document corresponding to a phingerprint (hash of the public
key info). The content is encoded in JSON. But it is not just any JSON, it
is JSON encoding of a phinger which is a personal PKI root file.

Since the mechanism being used here is the /.well-known convention
(/.well-known/ppe at the moment for testing), it would make sense to re-use
the prefix assigned for that as a modifier to the content-type

Content-Type: application/json; protocol=ppe

---

From: Tim Bray <[email-masked]>
Date: Wed, 2 Jul 2014 08:54:55 -0700

> situation in which a negotiation that makes a distinction between JSON and

​Well, the “only use is for content negotiation” assertion is just wrong,
Content-type is used to dispatch to various software modules depending on
what kind of thing you receive.  ​

I’ll say that just on Web-architectural grounds, I think distinct data
formats should have distinct Internet Media Types, and so it bothers me
that we don’t have one for i-json.  But the WG couldn’t perceive any real
value in having one that’s distinct from JSON’s and I didn’t have  a
forceful-enough argument to move the consensus on this.

>
> Content identification that tells me a document is JSON is useless unless
> I know the schema or purpose of the document.
>
>
> If I write a protocol then I am going to tell people to use I-JSON
> encoding or there is no value to it. If the sender has an option to choose
> between JSON and I-JSON then I have to implement both and nothing is saved
> or simplified.
>
> For example, I have a protocol that allows a client to retrieve the
> current phinger (.phb) document corresponding to a phingerprint (hash of
> the public key info). The content is encoded in JSON. But it is not just
> any JSON, it is JSON encoding of a phinger which is a personal PKI root
> file.
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: John Cowan <[email-masked]>
Date: Wed, 2 Jul 2014 11:49:52 -0400

Phillip Hallam-Baker scripsit:

> The only use for Content-Type is for content negotiation.

This isn't true in general, unless you consider mere announcement to
be a subtype of negotiation.  ("Let's negotiate: you do what I say,
mmmkay?")  One and the same entity body could be JSON, plain text, HTML,
or some binary format, and only the Content-Type: header can say which.
It's perfectly reasonable to imagine an application which can accept any
of these.

> There is no situation in which a negotiation that makes a distinction
> between JSON and I-JSON makes any sense.

That's true, but it doesn't mean that there is no point in labeling
I-JSON as such.

> Content identification that tells me a document is JSON is useless
> unless I know the schema or purpose of the document.

Not so.  For example, it may be your job to deserialize the JSON into
some internal format for processing by someone else.

> encoding or there is no value to it. If the sender has an option to
> choose between JSON and I-JSON then I have to implement both and
> nothing is saved or simplified.

+1 to that.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
O beautiful for patriot's dream that sees beyond the years
Thine alabaster cities gleam undimmed by human tears!
America! America!  God mend thine every flaw,
Confirm thy soul in self-control, thy liberty in law!
        --one of the verses not usually taught in U.S. schools

---

From: Mark Baker <[email-masked]>
Date: Wed, 2 Jul 2014 15:42:59 -0400

On Wed, Jul 2, 2014 at 11:54 AM, Tim Bray <[email-masked]> wrote:
> formats should have distinct Internet Media Types, and so it bothers me that
> we don’t have one for i-json.  But the WG couldn’t perceive any real value
> in having one that’s distinct from JSON’s and I didn’t have  a

Were there driving use cases behind I-JSON? I could imagine a
(atypical) scenario where it's used as a "publishing profile",
defining a best practice for publishers (Postel-ian style), with no
regard for what happens once it's consumed. You wouldn't need to say
anything about media types then.

But if you want to be able to exchange I-JSON over the Web or
Internet, so that recipients know, e.g., not to add duplicate keys,
then that can only practically be indicated with a new media type.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sat, 5 Jul 2014 01:30:34 +0000

There are times when, in the documentation for a service that is producing
JSON, I would like to say:

"If you receive a message from me that is not strictly I-JSON, I would
prefer you treat it as an error on my part, and therefore treat my message
as invalid, because if something went wrong enough that what I sent you
wasn't valid I-JSON my server room is likely on fire."

On 7/2/14, 1:42 PM, "Mark Baker" <[email-masked]> wrote:

>>that

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Fri, 4 Jul 2014 19:04:10 -0700

So, would an I-JSON media type help in producing the desired effect? Not
obvious to me.  In practice, I’m supposing that if I’m writing a consumer
for JIP (Joe’s Internet Protocol) I’d toggle my JSON parser into I-JSON
mode because I know that’s what the RFC said.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sat, 5 Jul 2014 02:31:48 +0000

That's what I'd want you to do as a consumer of my service.  In a perfect
world, ECMAscript would have a third parameter on JSON.parse that was
either a boolean controlling IJSON mode (defaulted to the old behavior),
or the second parameter could either be the existing reviver function or
an object with reviver:function, ijson:bool, and whatever else needs to be
added later.  Other language/library mechanisms would then follow suit
eventually.

On 7/4/14, 8:04 PM, "Tim Bray" <[email-masked]> wrote:

>for JIP (Joe’s Internet Protocol) I’d toggle my JSON parser
> into I-JSON mode because I know that’s what the RFC said.
>
>
>
>On Fri, Jul 4, 2014 at 6:30 PM, Joe Hildebrand (jhildebr)
><[email-masked]> wrote:
>
>https://keybase.io/timbray <https://keybase.io/timbray>)
>
>
>

-- 
Joe Hildebrand

---

From: Larry Masinter <[email-masked]>
Date: Sat, 5 Jul 2014 07:02:58 +0000

There is an advantage to using application/json for I-JSON
because many components can/should treat I-JSON as
JSON.  So there actually should be a use case which
NEEDS the distinction.

for a service that is producing JSON, I would like to say:

In this particular case, I can't think of a situation
where you wouldn't also want to validate other constraints
as well.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sun, 6 Jul 2014 04:48:33 +0000

>where you wouldn't also want to validate other constraints

I think the implication of us publishing I-JSON at all is that there are
many people that might want to start with this set of constraints.  If we
don't think that is the case, we shouldn't publish the doc as an RFC.
None of the I-JSON constraints are domain-specific, unlike most of the
other constraints you will want to check.

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Sat, 5 Jul 2014 22:12:56 -0700

So, question: Is there anyone else who agrees with Mark's original argument
that there ought to be a Media type for i-json. I wouldn't be wildly
against it, but frankly can't see much of a practical upside.
On Jul 5, 2014 9:48 PM, "Joe Hildebrand (jhildebr)" <[email-masked]>

---

From: Mark Baker <[email-masked]>
Date: Sun, 6 Jul 2014 15:45:31 -0400

> wasn't valid I-JSON my server room is likely on fire."

Other than pre-arranging that with the human behind "you", the only
existing way to achieve that goal is to use a new media type.

Also, creating an I-JSON specific media type doesn't mean that I-JSON
can't be delivered as application/json (or application/*+json). It
just makes I-JSON useful in more situations IMO, like this one.

---

From: Nico Williams <[email-masked]>
Date: Mon, 7 Jul 2014 00:35:06 -0500

> wasn't valid I-JSON my server room is likely on fire."

Shades of "secure bit".  This is not appropriate for a protocol, IMO.

Nico
--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Jul 2014 14:40:10 +0900

> mode because I know that’s what the RFC said.

I fully agree here. They way I see it, there would then be a media type 
for JIP, which e.g. could be application/jip+json. The JIP RFC would say 
that JIP uses I-JSON, and receivers that had a choice would toggle as 
explained above. But still the +json suffix would mean that the 
documents could take advantage of generic JSON processing (whatever that 
is).

Another way to express this is to say that in as far as there is a JSON 
'ecosystem', it would be a bad idea to try and split that ecosystem into 
two (JSON and I-JSON) at the top.

Regards,   Martin.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Mon, 7 Jul 2014 16:40:45 +0200

On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote:
> So, question: Is there anyone else who agrees with Mark's original
> argument that there ought to be a Media type for i-json. I wouldn't
> be wildly against it, but frankly can't see much of a practical upside.

I don't think it makes much sense to define a separate media type for i-json and even less a media type suffix. It *might*, however, make sense to mint a profile URI as defined by RFC6906 [1] for i-json and register it according RFC7284 [2].

Cheers,
Markus

For your convenience, the links to the two RFCs:

[1] http://tools.ietf.org/html/rfc6906
[2] http://tools.ietf.org/html/rfc7284

--
Markus Lanthaler
@markuslanthaler

---

From: Erik Wilde <[email-masked]>
Date: Mon, 07 Jul 2014 16:49:29 +0200

hello markus.

> I don't think it makes much sense to define a separate media type for i-json and even less a media type suffix. It *might*, however, make sense to mint a profile URI as defined by RFC6906 [1] for i…

that would have made a lot of sense if JSON had chosen to support 
profiles in its recently published update, which it unfortunately 
didn't. i guess the problem now is that there is no agreed-upon way how 
profiles are signaled in JSON, which makes the profile mechanism only 
moderately useful. but i still agree that it would be useful to include 
such a profile URI for I-JSON in the spec, so that JSON-based formats 
that have an agreed-upon way of signaling profiles can use it.

cheers,

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: Mark Baker <[email-masked]>
Date: Mon, 7 Jul 2014 11:27:59 -0400

On Mon, Jul 7, 2014 at 10:40 AM, Markus Lanthaler
<[email-masked]> wrote:
> I don't think it makes much sense to define a separate media type for i-json and even less a media type suffix.

Whether a I-JSON media type is required or not depends entirely on the
use cases for I-JSON's existence. The only use case I've seen, from
Joe, suggests a new media type would have some utility. But then
others reject that use case.

When I hear "a separate media type isn't needed", to me that means
that I-JSON is to be used - and published - as a strict subset of
JSON, aka it will not be part of the protocol spoken by Web clients
and servers. One implication is that an I-JSON-unaware
client/intermediary could consume some I-JSON, and e.g. add content
with a duplicate key, then process and/or republish as non-I-JSON
JSON.

If the group doesn't consider that a problem, then great, you don't
need a new media type. If it does, then you do.

I hope it's clear that I'm not arguing for or against a media type any
more. I'm just trying to tease out of the group the criteria that
would permit a principled decision to be made.

> It *might*, however, make sense to mint a profile URI as defined by RFC6906 [1] for i-json and register it according RFC7284 [2].

Don't go there. Those kinds of profiles have never worked in their
many, many guises.

Mark.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Mon, 7 Jul 2014 17:36:00 +0200

On 7 Jul 2014 at 16:49, Erik Wilde wrote:
>> I don't think it makes much sense to define a separate media type for
i-json
>> and even less a media type suffix. It *might*, however, make sense to
mint
>> a profile URI as defined by RFC6906 [1] for i-json and register it
according
>> RFC7284 [2].
> didn't.

You mean adding a "profile" media type parameter, right? I don't really know
what the process is but I think now that json-bis was published as an RFC
(it was out of scope for that work), the JSON WG could re-register the media
type and add such a parameter

> i guess the problem now is that there is no agreed-upon way how
> moderately useful.

The server can signal it to the client using an HTTP Link header using the
"profile" link relation. What's currently not possible, is for the client to
request i-json instead of json from the server. I don't think that's a big
problem in practice though as I don't expect a server to support both i-json
and json at the same time anyway.

> but i still agree that it would be useful to include

Minting and registering such a URI is extremely cheap and has no negative
side effects I can think of. We can figure out later if we need to do more
(e.g. adding a profile parameter to application/json).

Cheers,
Markus

--
Markus Lanthaler
@markuslanthaler

---

From: mike amundsen <[email-masked]>
Date: Mon, 7 Jul 2014 11:52:54 -0400

we should use media type registration to define well-formedness --
"shannon-message" style
we should use profile registration establishing app semantics and validity

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Jul 2014 11:59:40 -0400

Exactly

I-JSON is a subset of JSON.

We have two choices for I-Json content:

1) Use the content type application/json and not tell the application they
are getting I-JSON

2) Use the content type application/i-json and risk having parsers that
accept JSON but don't do special processing for I-JSON reject it.

I can't see any advantage to choice #2, it risks breaking things for a
distinction that does not provide leverage.

Now the story for JSON-B is completely different as that is a superset. So
even though a I-JSON document will be accepted by a JSON-B parser the
reverse is not the case as JSON-B has optional binary encodings. And so in
that case it is essential that the application know what the content type
is.

On Mon, Jul 7, 2014 at 10:49 AM, Erik Wilde <[email-masked]> wrote:

>> i-json and even less a media type suffix. It *might*, however, make sense
>> to mint a profile URI as defined by RFC6906 [1] for i-json and register it
>> according RFC7284 [2].
>>
>
> that would have made a lot of sense if JSON had chosen to support profiles
> in its recently published update, which it unfortunately didn't. i guess
> the problem now is that there is no agreed-upon way how profiles are
> signaled in JSON, which makes the profile mechanism only moderately useful.
> but i still agree that it would be useful to include such a profile URI for
> I-JSON in the spec, so that JSON-based formats that have an agreed-upon way
> of signaling profiles can use it.
>
> cheers,
>
> dret.
>
> --

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 8 Jul 2014 11:48:14 +0000

>others reject that use case.

To be clear, I wasn't suggesting a media type, but an explicit flag in the
parsing library that is set by the programmer because of prior knowledge.

-- 
Joe Hildebrand

---

From: Erik Wilde <[email-masked]>
Date: Tue, 08 Jul 2014 14:36:28 +0200

hello markus.

> type and add such a parameter

i don't think it was explicitly out of scope, and it was briefly 
mentioned on this list. i think it just wasn't considered to be 
important enough. technically speaking, i think you need to re-register 
the media type with an added profile parameter.

http://tools.ietf.org/html/draft-wilde-atom-profile is a draft where i 
am trying to do this for atom. the idea was that this draft could be 
used as a template for any media that would like to start supporting 
profile as a media type parameter (the source is available at 
http://tools.ietf.org/html/draft-wilde-atom-profile).

> and json at the same time anyway.

you're right, signaling them as RFC5988-style links is always a possibility.

> (e.g. adding a profile parameter to application/json).

yes, and that's the standards argument for using profiles: they are a 
lightweight way for being more specific about a representation, and they 
can be ignored (treat the representation as just using the media type), 
or can be interpreted (assume that the representation follows additional 
constraints).

http://tools.ietf.org/html/rfc6906#section-3.1

cheers,

dret.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 8 Jul 2014 17:05:52 +0000

+1 to identifying i-json by a profile 

-1 to defining a new media type or adding a new parameter.
   (I'd change my mind if someone had a compelling concrete
    use case).