
Message-Id: <3.0.32.19990802184256.009828b0@pop.dial.pipex.com>
Date: Mon, 02 Aug 1999 18:45:50 +0100
To: <ietf-xml-mime@imc.org>
From: Graham Klyne <GK@dial.pipex.com>
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-xml-mime@imc.org
Precedence: bulk

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@ACM.ORG)


Received: by mail.proper.com (8.9.3/8.9.3) id IAA29085 for ietf-xml-mime-bks; Sun, 1 Aug 1999 08:47:11 -0700 (PDT)
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA29081 for <ietf-xml-mime@imc.org>; Sun, 1 Aug 1999 08:47:11 -0700 (PDT)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52248(4)>; Sun, 1 Aug 1999 08:49:47 PDT
Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <98073>; Sun, 1 Aug 1999 08:49:36 PDT
From: "Larry Masinter" <masinter@parc.xerox.com>
To: "Chris Lilley" <chris@w3.org>, "John Cowan" <cowan@locke.ccil.org>
Cc: <ietf-xml-mime@imc.org>, "Roy Fielding" <fielding@ics.uci.edu>, "Ned Freed" <Ned.Freed@INNOSOFT.COM>
Subject: RE: Media types and XPointer, XLink, XPath, and XSLT
Date: Sun, 1 Aug 1999 08:49:43 PDT
Message-ID: <000101bedc35$79250800$15d0000d@copper.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <37A36BF3.DEA0FD49@w3.org>
Importance: Normal
Sender: owner-ietf-xml-mime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>

> When a new media type is registered, that registration gets to define
> what a fragment identifier means.

While RFC 2396 says:

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result. 

we didn't include an "IANA considerations" section that required
the addition of a "Fragment Identifier definition" for MIME
media types, or a retrospective definition for any other
media type.

In retrospect, this was an oversight, but it's correctable.
We would want to extend the media type registration form of
RFC 2048, either through an 'additional information' suggestion
in 2.2.9 or by an explicit addition to the registration template.

If XPointer updates the interpretation of fragment identifiers
for application/xml and text/xml, it should say so explicitly,
and the revision of RFC 2376 ("XML Media Types") should update
the template used.

It's also possible to update the text/xml & text/html template
explicitly.

> So, the language in the XPointer draft is clearly saying, for text/xml
> and application/xml, this is the syntax. It doesn't say anything about
> other media types, presumably because it can't speak for them.
>
> Other media types can define their own fragment identifiers, which may
> have very different requirements to Xlink or may have exactly the same
> ones. So they might well say that they use XLink, too.
> 
>  Or they might say something like "we will allow only links to a given
> ID but we will use the exact same syntax XPointer uses for that, for
> compatibility". In other words, all valid fragment identifiers for thast
> type would use XLink, but not all possible uses of XLink would be valid
> for that media type.

I agree with all of this.