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

[Tim Bray <[e-mail]>]

On Wed, Jul 2, 2014 at 7:40 AM, Phillip Hallam-Baker <[e-mail]>
wrote:

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

​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.
>
> 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
>
>
>
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>
>


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