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

[Erik Wilde <[e-mail]>]

hello markus.

On 2014-07-07, 17:36 , Markus Lanthaler wrote:
> On 7 Jul 2014 at 16:49, Erik Wilde wrote:
>> On 2014-07-07, 16:40, Markus Lanthaler 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].
>> 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.
> 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 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).

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

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

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

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.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |