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

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)