Using CONNEG instead of MIME types for compound types & references
"Larry Masinter" <masinter@parc.xerox.com> Mon, 10 May 1999 17:36 UTC
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03731 for ietf-xml-mime-bks; Mon, 10 May 1999 10:36:12 -0700 (PDT)
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA03727 for <ietf-xml-mime@imc.org>; Mon, 10 May 1999 10:36:08 -0700 (PDT)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <53001(5)>; Mon, 10 May 1999 10:38:34 PDT
Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <100596>; Mon, 10 May 1999 10:38:24 PDT
From: Larry Masinter <masinter@parc.xerox.com>
To: ietf-xml-mime@imc.org
Subject: Using CONNEG instead of MIME types for compound types & references
Date: Mon, 10 May 1999 10:38:16 -0700
Message-ID: <000101be9b0b$e2c8ab60$aa66010d@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
In-reply-to: <199905101414.KAA14873@hesketh.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
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>
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)
- Re: Negotiated Content Delivery: Maxmimizing Info… Chris Lilley
- Re: Negotiated Content Delivery: Maxmimizing Info… Ned Freed
- Re: Using CONNEG instead of MIME types for compou… Rick Jelliffe
- Re: Using CONNEG instead of MIME types for compou… Frank Boumphrey
- Re: Using CONNEG instead of MIME types for compou… Simon St.Laurent
- Re: Negotiated Content Delivery: Maxmimizing Info… Simon St.Laurent
- Re: Using CONNEG instead of MIME types for compou… Shane P. McCarron
- Re: Negotiated Content Delivery: Maxmimizing Info… Ned Freed
- Re: Negotiated Content Delivery: Maxmimizing Info… Rick Jelliffe
- RE: Using CONNEG instead of MIME types for compou… Larry Masinter
- Re: Negotiated Content Delivery: Maxmimizing Info… Ned Freed
- Re: Using CONNEG instead of MIME types for compou… Paul Hoffman / IMC
- Re: Using CONNEG instead of MIME types for compou… Rick Jelliffe
- Re: Negotiated Content Delivery: Maxmimizing Info… Rick Jelliffe
- Using CONNEG instead of MIME types for compound t… Larry Masinter
- Re: Negotiated Content Delivery: Maxmimizing Info… Ned Freed
- Re: Negotiated Content Delivery: Maxmimizing Info… Simon St.Laurent
- RE: Top-level media type xml desirable? (WAS: RE:… Ned Freed
- Re: Negotiated Content Delivery: Maxmimizing Info… Ned Freed
- RE: Top-level media type xml desirable? (WAS: RE:… Paul Hoffman / IMC
- Re: Negotiated Content Delivery: Maxmimizing Info… Paul Hoffman / IMC
- RE: Top-level media type xml desirable? (WAS: RE:… Ned Freed
- Re: Negotiated Content Delivery: Maxmimizing Info… Ned Freed
- Re: Negotiated Content Delivery: Maxmimizing Info… Paul Hoffman / IMC
- Negotiated Content Delivery: Maxmimizing Informat… Simon St.Laurent
- RE: Top-level media type xml desirable? (WAS: RE:… Ned Freed
- RE: Top-level media type xml desirable? (WAS: RE:… Paul Hoffman / IMC
- RE: Top-level media type xml desirable? (WAS: RE:… Larry Masinter
- RE: Top-level media type xml desirable? (WAS: RE:… Scott Lawrence
- RE: Top-level media type xml desirable? (WAS: RE:… Simon St.Laurent
- RE: Top-level media type xml desirable? (WAS: RE:… Larry Masinter
- Re: Top-level media type xml desirable? (WAS: RE:… Simon St.Laurent
- Re: Top-level media type xml desirable? (WAS: RE:… Simon St.Laurent
- Re: Top-level media type xml desirable? (WAS: RE:… Shane P. McCarron
- RE: Top-level media type xml desirable? (WAS: RE:… Larry Masinter
- Top-level media type xml desirable? (WAS: RE: Par… Langer, Paul