Re: [apps-discuss] proposal: adding profile support to JSON

["Rushforth, Peter" <[e-mail]>]

Hey Mark,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Mark Baker
> Sent: November 6, 2013 09:21
> To: Erik Wilde
> Cc: [e-mail] application-layer protocols
> Subject: Re: [apps-discuss] proposal: adding profile support to JSON
> 
> Hi Erik,
> 
> On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde <[e-mail]> wrote:
> > hello mark.
> >
> >
> > On 2013-11-05, 08:59 , Mark Baker wrote:
> >>
> >> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray 
> <[e-mail]> wrote:
> >>>
> >>> Well, for example, 
> >>> http://www.tbray.org/tmp/draft-bray-i-json-01.html
> >>
> >> I'm with Martin. What that spec is trying to do with 
> profiles is to 
> >> supplant the typical role of a media type. If it's 
> representative of 
> >> what Erik has in mind for the use of a profile parameter with Atom 
> >> (or anywhere), then I think that needs to be reconsidered too.
> >
> >
> > i understand your concerns, but profiles do not attempt to "replace 
> > media types", even though they could be (mis-)used to try 
> to do just 
> > that. [1] tries to explain the goal: they are for 
> specializing and/or 
> > constraining existing media types; representing both the 
> nature of the 
> > underlying type ("this is an atom feed and can be processed as a 
> > generic feed") as well as the specialized/constrained 
> profile ("this 
> > feed carries podcast data, and can be processed as a podcast feed").
> 
> I've read your RFC, and both referenced blog posts, but still 
> find myself asking the same question; what problem does it 
> solve? Yes, media types have their issues, but in my many 
> years in Web development and standardization, I've yet to 
> encounter a problem that didn't have a workable solution 
> through the correct use of link relations and media types. 
> This includes my time advising on the development of a 
> compound document editor at Justsystem, and representing them 
> on the W3C Compound Document Formats WG.
> 
> We agree that a document containing some OPDS extensions is 
> still an Atom document that can be delivered as 
> application/atom+xml, I believe. You appear to suggest that 
> there's value in exposing the existence of those OPDS 
> extensions using an additional external metadata protocol 

> element. I believe that this is at best an optimization, 
> since the consumer can easily detect the existence of the 
> extension by inspecting the content 

How can the consumer *request* the extended semantics, if not through the media type?
Lots of stuff gets transmitted under guise of text/html, application/xml, application/json
that should be encouraged to register.

> But at worst, it's a 
> recipe for interop problems; does the meaning of the document 
> change if the profile is declared vs not? 

According to RFC 2045, it falls back to the base media type/subtype without 
that parameter.

"   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content. 
...
   MIME implementations must ignore any parameters whose names they do not
   recognize."

> What if the v2 
> profile URI is declared and the document contains a v1 
> extension? .

That would be an error, unless v1 is wholly included in v2.

Furthermore, media type parameters are meant to help the
client interpret the meaning of the message.  An optional parameter should not
be not a 'slot', it should be a recommendation to future registrations to define
values of it.  I think the recommended use of a URI perhaps
leads one to think it can be assigned ad hoc.  I think values 
should be registered, like what Tim is doing.

> > james snell blogged about the bigger problem [2] that media 
> types as 
> > they are today are not a terribly well-designed concept.
> 
> I strongly disagree with that post (blog commenting seems 
> broken, but I won't respond in detail here except to say 
> "rel=icon" :). I believe media types are far better designed 
> than is commonly appreciated; a single label for a compatible 
> evolution of a document format is a simple yet extremely 
> powerful protocol that promotes compatibility in extensions 
> and penalizes incompatible deviations... but still permits 
> them when required.

+1


> 
> And FWIW, this is coming from the guy who, AFAIK, started the 
> whole profile parameter ball rolling in RFC 3236. That went 
> in there only as a compromise with the WAPforum, but was 
> never/rarely used in practice.

Interesting, thanks for pointing that out.

Regards,
Peter Rushforth