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

On Jan 17, 2012, at 1:27 PM, Ray Polk wrote:

> Thanks for the correction.  To be sure I understand, I'll paraphrase your response:
> 
> Media types are a key used by user agents to look up processing instructions with a registered authority (iana for http).  Though these processing instructions might include anything, many (all?) include format information; further, many include _only_ format information.  As a result, a practice arose of naming the key after the format.
> 
> Perhaps my mistake confused the main point I was trying to make, though.  I wasn't concerned with the number of media types that are applicable to an end point.  My concern was with the ramifications of including data semantics in the processing mechanism along with the format information.

I understood that.  However, that concern left the barn some 20 years ago.

> By combining the two, the number of total registered types can/could increase geometrically.  The vnd.openxmlformats-*+xml formats are an example of that potential.  Imagine if someone registers openjsonformats & openyamlformats.  Then they want both text and binary formats.  The list of ~75 types at the end of this email becomes 400+.

They could, but in practice they don't.  The reason is simply that getting
people to agree on a common processing mechanism to use on receipt of a
message is much harder than registering a type.

> Now imagine the growth as such a practice spreads to other domains AND as the number of popular text formats grows...
> 
> Endpoints and clients dealing with format+datatype media types would be repeating themselves over and over again.  Imagine the Accept headers...
> 
> To put it another way, can I register vnd.cat-jpeg? :-)  Should I?

If you have a need for the recipient to process that type is a way
that is different than how they would normally process jpeg, then
the answer is yes.  For example, text/html and text/plain are two
different ways to process the same data.

> Sure, a design that allows endpoints to supply user agents a key to lookup processing instructions maximizes flexibility.  Catch-all text columns, member variables and void pointers all also maximize flexibility.
> 
> When in practice, though, ~100% of those catch-alls include format information.  Isn't it time for a more strongly typed header/column/member?  (to go along witth the catch all)

The format information is not the most significant information needed
by the recipient in order to process a MIME message.  While someone
could come up with a better design, I suppose, it is certainly not
within scope for HTTPbis.  Regardless, since the exact same sequence
of octets *is* processed differently depending on the media type metadata,
it is fair to say that format information is not the key concern even
if most data formats have a type named after them.

....Roy

Received on Tuesday, 17 January 2012 21:55:01 UTC