Re: [p3-payload] Media-Type -- Two Values, One Cup Anti-Pattern?

This is an interesting discussion, but it's getting off-topic for this list.

The apps-discuss list is likely more suitable.

Regards,


On 20/01/2012, at 9:29 PM, Ray Polk wrote:

> 
> 
> On Thu, Jan 19, 2012 at 7:59 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 20/01/2012 7:23 a.m., Ray Polk wrote:
> I look at this group like the founding fathers of the internet.  To think founding fathers would settle for "just interoperable" when there's a chance for "better AND interoperable" makes me kind of sad.
> 
> Obviously doing away with the existing paradigm of content negotiation isn't practical.  I wasn't trying to propose that.  It's not how anyone makes backward compatible changes anyway, right?
> 
> 1) One could add spec defined optional headers analogous to those for Media Type:
> 
> Accept-Format / Content-Format
> Accept-Data-Type / Content-Data-Type
> 
> With IANA registries for each.  Eventually this might become an alternative to Accept / Content-Type.
> 
> 2) One could extend Media Types to include the notion of format somehow.  Add to that the idea of format hierarchies or something.
> 
> format/text/xml/atomsvc (don't need the yucky + xml anymore)
> 
> Then add an optional spec defined header for datatype OR "additional processing instructions beyond format"
> 
> IMHO the place for adding such instructions is not in the HTTP tokens, but in the fields provided by the representation.
> 
> XML itself is perfectly capable of specifying in one of its tags the data type that will be produced after unwrapping/processing. So this "+" syntax is not actually adding "+xml" to a type as it is more along the lines of adding redundant "something+" to the text/xml and application/xml types alongside how the XML coded representation stores that meta data.
> 
> This is in no way the fault of HTTP protocol, but of those designing the sub-protocols not taking into account the 2-value repercussions and nesting options clearly enough.
> ... or perhapse they did, and decided that registering a nested type "text/a+b" was the best way to go given the nature of how a and b interact.
> 
> Either way it seems way beyond the bounds of HTTP to re-define what is or is not allowed to be transferred beyond the basic reserved field characters.
> 
> AYJ
> 
> 
> Sure, you can put whatever you like into the entity body.  But how does the client know to look for it?  Does IANA have a registry of typical xml bodies?  json bodies?  What's more...how does the client negotiate what sort of thing they want from the server?
> 
> Currently, this is entirely the purview of MediaType -- opaque Media Type keys referencing sets of instructions registered with IANA; those instructions always contain format & increasingly contain datatype.
> 
> Why make every single sub protocol bear the burden of specifying format? (all in different, non standard ways)

--
Mark Nottingham
http://www.mnot.net/

Received on Saturday, 21 January 2012 08:04:09 UTC