W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: Ray Polk <raypolk@gmail.com>
Date: Fri, 20 Jan 2012 07:29:22 -0700
Message-ID: <CABqtACY6K1fzApULurVST7mhOpq4giPiU5xONOp1Cov_7u-8kA@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
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.
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)
Received on Friday, 20 January 2012 14:29:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:50 UTC