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

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Jul 1, 2014 at 11:04 PM, Mark Baker <[e-mail]> wrote:

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

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