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

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

Received on Friday, 20 January 2012 03:00:19 UTC