Re: Using CONNEG instead of MIME types for compound types & references

[Graham Klyne <[e-mail]>]

Coming a little late to this particular debate, I'd like to add another
reference to those that Larry has cited, that potentially provides an extra
piece to complete the picture:

- "Indicating media features for MIME content"
  <draft-ietf-conneg-content-features-01.txt>

This describes a header for attaching content feature information to
MIME-encapsulated data.

This proposal, together with the rest of the CONNEG framework, can be used
to expose selected information about the inner content of an arbitrary
document type.

#g
--


At 10:38 10/05/99 PDT, Larry Masinter wrote:
>There are a number of situations where MIME types don't solve the
>problem
for "content negotiation" because the XML bodies that are
>transferred will
be compound objects that contain multiple kinds
>of markup. In such
situations, having a "top level" type other
>than "application/xml" doesn't
do any good, since there's no useful
>way to use MIME to describe the
combination of elements that are
>contained within.
>
>For example, if, as
it seems, there will be XML body parts which
>contain XHTML and, embedded
within (not using multipart), contain
>equations using the MathML and
molecular diagrams using ChemML,
>and some Dublin Core metadata using RDF,
there is no useful
>designation of the entire top level type that
accurately describes
>the content, or allows you to say that you accept
XHTML,
>MathML but don't accept ChemML.
>
>For *these* kind of XML bodies
where multiple applications are
>intermixed, having new MIME types doesn't
solve the problem.
>
>In this situation, though adding additional MIME
types doesn't solve
>the problem, the media feature mechanisms *do* allow
content negotiation
>and are appropriate.
>
>I want to distinguish between
a "protocol" (rules of engagement)
>and a "protocol element" (a string or
data structure used within
>one or more protocols).
>
>CONNEG developed
content negotiation *protocol elements* for
>describing data, sender and
recipient capabilities,
>characteristics and preferences. Most of the work
on different content
>negotiation *protocols* has happened outside of the
CONNEG working group,
>since content negotiation is usually in the context
of some other
>communication protocol. HTTP and Internet Fax both have some
kind of
>"content negotiation". The Internet Fax mechanisms are, IMHO, the
best
>you can do for email. (Section 3 of RFC 2532 describes how a
sender
>may determine an email recipient's capabilities.) HTTP has both
"accept"
>requests, "Vary" responses, and some experimental protocols
(Transparent
>Content Negotiation and RVSA).
>
>------
>RFC 2506 Media
Feature Tag Registration Procedure. March 1999. 
> (Also BCP0031) (Status:
BEST CURRENT PRACTICE)
>
>How to register features. The simplest thing to
do would be
>to define an "XML namespace" feature and a "XML DTD"
feature,
>whose values are the pointer to the XML namespace and
DTD
>respectively.
>-------
>RFC 2533 A Syntax for Describing Media Feature
Sets. March 1999.
>    (Status: PROPOSED STANDARD)
>
>How to combine a set
of features into a feature
set
>--------
>draft-ietf-conneg-feature-hash-01.txt: Identifying composite
media features
>April 1999.
>
>How to use URLs or hashes to indentify
complex sets of features
>or feature profiles.
>
>
>and, while you're at it
(although only relevant to some XML
>applications):
>-------
>RFC 2534
Media Features for Display, Print, and Fax. March 1999.
>  (Status:
PROPOSED STANDARD)
>
>This is as useful for HTML as it is for anything. In
fact, it
>was originally motivated by wanting to do better than
the
>"screen size" in the User Agent field.
>------
>RFC 2530 Indicating
Supported Media Features Using Extensions to DSN and
>     MDN.March 1999.
(Status: PROPOSED STANDARD)
>
>This is a way of adding content negotiation
to email.
>------
>RFC 2531 Content Feature Schema for Internet Fax. March
1999. 
>    (Status: PROPOSED STANDARD)
>
>The color space description
protocol elements here are applicable to
>any calibrated-color application,
even though designed originally
>for "fax".
>------
>Two proposals for
content negotiation *protocols* in HTTP:
>
>RFC 2295 Transparent Content
Negotiation in HTTP. March 1998. 
>   (Status: EXPERIMENTAL)
>
>RFC 2296
HTTP Remote Variant Selection Algorithm -- RVSA/1.0. March 1998. 
>
(Status: EXPERIMENTAL)
>
>
>
------------
Graham Klyne
([e-mail])