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
(GK(_at_)ACM(_dot_)ORG)