Re: Media types

> > or that expecting the MIME content-type to convey the action that
> > should be performed by a recipient, rather than a description of
> > the content, is a bit of a mis-application of MIME?
> 
> That's not always true. MIME uses the content-type to indicate what type
> of handler should be selected for the message body.  The same content can
> be sent for different purposes by using different media types. E.g.,
> image/jpeg vs application/octet-stream, multipart/alternative vs
> multipart/mixed, etc.

actually, the dispatching is not implied by the content-type -
the recipient agent is free to dispatch each content as it sees fit.
the content-type really is just labelling the data representation
used by the content.

the same is true for application/octet-stream - this just happens
to be the type name for "unknown", and the multipart/* types just
happen to use MIME framing internally.  

it's not as if labelling a content as image/jpeg implies that the 
image should be displayed whereas labelling it as application/octet-stream 
implies that it should not be displayed (even if it often works out
that way) we have content-disposition to specify presentation hints.

> > the fact that XML picked a means of labelling content that is
> > incompatible with MIME's content-type is hardly MIME's fault.
> 
> I think the mistake is in assigning such messages a type that implies
> it should be handled by a generic XML processor.  There is no such thing,
> even though it is possible to view all XML types via generic XML tools.

well, I'd agree with that.

> A more architecturally fitting course of action would be to create a
> top-level media type of xml and then have xml/* subtypes, but for
> some reason (deployed apps, I presume) the top-level namespace has been
> frozen for ages.

that wouldn't have been consistent with the MIME content-type
labelling architecture either. whether a content uses XML as a
presentation layer is orthogonal to the type of the content.
after all, XML can certainly be used to represent text, images, 
application data, audio or video.

the most "architecturally fitting course of action" (for MIME) would 
have been to define a separate facet for the nature of the underlying
content (say content-presentation-layer to pick a hasty example) 
and put this in a separate header field.  but people wanted to be
able to dispatch on content-type alone (even though that's unrealistic), 
and HTTP doesn't make a clean separation between facets of the content
and attributes of the bearer protocol.  so we're kind of stuck.

Keith

Received on Thursday, 17 January 2002 18:38:35 UTC