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

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"

3) something one of you smarter and more experienced guys than me can think
of

If a better design is possible, isn't it our duty to at least _try_?

-Ray the tryhard

On Thu, Jan 19, 2012 at 11:01 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 19/01/2012, at 11:53 PM, Ray Polk wrote:
>
> > Maybe discussion out band is less apt to receive a response?
> >
> > ...and does anyone else have any thoughts in this area?  Am I talking
> nonsense?  Or is everyone just scared to gainsay Dr. Fielding?  ;-)
> >
> > To summarize my position:
> >
> > Two+ values in one cup/bucket/variable/column/header is bad.
>
> Yes, but (as I think Roy covered), it's not practical to change things
> now. We're not trying for perfect, just interoperable.
>
> Cheers,
>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
>