HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:34:34 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 29 Dec 1997 19:35:00 GMT ETag: "323fb1-6a56-34a7fb64" Accept-Ranges: bytes Content-Length: 27222 Connection: close Content-Type: text/plain IETF content negotiation BOF Graham Klyne Internet draft Integralis Ltd. 6 December 1997 Expires: 6 June 1997 Requirements for protocol-independent content negotiation Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) 1997, The Internet Society Abstract A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1, 2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. The case for a cross-protocol negotiation framework is set out in [4]. This draft sets out an abstract framework and requirements for protocol-independent content negotiation, and identifies a number of technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The requirements set out the desired properties of a content negotiation mechanism. Klyne [Page 1] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Table of contents 1. Introduction.............................................2 1.1 Structure of this document ...........................3 1.2 Discussion of this document ..........................3 1.3 Ammendment history ...................................4 2. Terminology and definitions..............................4 3. Framework................................................7 3.1 Abstract framework for content negotiation ...........8 3.2 Abstract model for negotiation metadata ..............8 3.3 Text representation for negotiation metadata .........8 3.4 ASN.1 description of negotiation metadata ............8 3.5 Protocol binding guidelines ..........................8 4. Requirements.............................................9 5. Technical issues.........................................10 5.1 Non-message resource transfers .......................10 5.2 End-to-end vs hop-by-hop negotiations ................10 5.3 Billing issues .......................................11 5.4 Use of directory services ............................11 5.5 Performance considerations ...........................11 5.6 Confidence levels in negotiated options ..............11 5.7 Messages vs streamed data ............................12 6. Security considerations..................................12 6.1 Privacy ..............................................12 6.2 Denial of service attacks ............................12 6.3 Mailing list interactions ............................12 6.4 Use of security services .............................12 7. Copyright................................................13 8. Acknowledgements.........................................13 9. References...............................................14 10. Author's address........................................14 1. Introduction A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. While MIME media types [1] provide a standard method for handling one major axis of variation, resources also vary in ways which cannot be expressed using currently available MIME headers. The case for a cross-protocol negotiation framework is set out in [2]. This draft sets out a framework and requirements for a protocol- independent content negotiation framework, and identifies a number of technical issues which may need to be addressed. The framework does not attempt to specify the content negotiation process; rather it gives an indication of the anticipated scope and form of any such specifications. Klyne [Page 2] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation The statement of requirements is intended to set out the desired properties of a content negotiation framework, while trying to avoid any assumption of the form that framework may take. In its present form, this draft attempts to overstate rather than understate the requirements. The intention is that a wide range of requirements can be considered, and those considered inappropriate will be removed from this draft (or demoted to an explanatory statement explaining why they were dropped). 1.1 Structure of this document The main part of this draft addresses four main areas: Section 2 definessome of the terms which are used with special meaning. Section 3 outlines a proposed framework for describing protocol- independent content negotiation. Section 4 describes and explains the various requirements. A list of requirements is given at the start of section 4, with subsections containing more detailed explanations where required. Section 5 discusses some of the technical issues which are raised by this document, with cross-references to other work where appropriate. 1.2 Discussion of this document Discussion of this document should take plae on the content negotiation mailing list hosted by the Internet Mail Consortium (IMC): Please send comments regarding this document to: ietf-conneg@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-conneg-request@imc.org". You should get a reply as follows: The "ietf-conneg" mailing list is to discuss negotiating elements of the presentation of documents that are not naturally captured by the MIME Media Type. To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-conneg/ Klyne [Page 3] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation To unsubscribe from the ietf-conneg mailing list, send a message to "ietf-conneg-request@imc.org" containing the message 'unsubscribe'. If you need to contact a human about this mailing list, please send a message to: phoffman@imc.org 1.3 Ammendment history 00a 06-Dec-1997 Document initially created. 00b 07-Dec-1997 Added definition of "transmission".~ Copied and adapted requirements from Internet fax requirements draft. Updated framework with details from Internet fax requirements draft. 2. Terminology and definitions This section introduces a number of terms which are used with specific meaning in the content negotiation drafts. Many of these have been copied and adapted from [5]. The terms are listed in alphabetical order. Capability An attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content. Choice message A choice message returns a representation of some selected variant or variants, together with the variant list of the negotiable resource. It can be generated when the sender has sufficient information to select a variant for the receiver, and also requires to inform the receiver about the other variants available. Connected mode A mode of operation in which sender and receiver are directly connected, and hence are not prevented from definitively determining each other's capabilities. (See also: Session mode) Klyne [Page 4] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Content negotiation An exchange of information (negotiation metadata) which leads to selection of the appropriate representation (variant) when transferring a data resource. Data resource A network data object that can be transferred. Data resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. (See also: message) Feature A piece of information about a sender, receiver or resource which is exchanged during content negotiation. List message A list message sends the variant list of a negotiable resource, but no variant data. It can be generated when the sender does not want to, or is not allowed to, send a particular variant. Message The data which is transmitted from a sender to a receiver, together with any encapsulation which may be applied. Where a data resource is the original data which may be available in a number of representations, a message contains those representation(s) which are actually transmitted. Negotiation metadata is not generally considered to be part of a message. Negotiated content Message content which has been selected by content negotiation. Negotiation (See: content negotiation) Negotiable resource A data resource which has multiple representations (variants) associated with it. Selection of an appropriate variant for transmission in a message is accomplished by content negotiation between the sender and recipient. Negotiation metadata Information which is exchanged between the sender and receiver of a message by content negotiation in order to determine the variant which should be transferred. Klyne [Page 5] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Neighbouring variant A particular representation (variant) of a variant resource which can safely be assumed to be subject to the same access controls as the variant resource itself. Not all variants of a given variant resource are necessarily neighbouring variants. The fact that a particular variant is or is not a neighbouring variant has implications for security considerations when determining whether that variant can be sent to a receiver in place of the corresponding variant resource. It may also have implications when determining whether or not a sender is authorized to transmit a particular variant. Receiver A system component (device or program) which receives a message. Receiver-initiated transmission A message transmission which is requested by the eventual receiver of the message. Sometimes described as 'pull' messaging. E.g. an HTTP GET operation. Sender A system component (device or program) which transmits a message. Sender-initiated transmission A message transmission which is invoked by the sender of the message. Sometimes described as 'push' messaging. E.g. sending an e-mail. Session mode A mode of message transmission in which confirmation of message delivery is received by the sender in the same application session (usually the same transport connection) that is used to transmit the message. (See also: connected mode, store and forward mode) Store and forward mode A mode of message transmission in which the message is held in storage for an unknown period of time on message transfer agents before being delivered. Transmission The process of transferring a message from a sender t a receiver. This may include content negotiation. User agent A system component which prepares and transmits a message, or receives a message and displays, prints or otherwise processes its contents. Klyne [Page 6] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Variant One of several possible representations of a data resource. Variant list A list containing variant descriptions, which can be bound to a negotiable resource. Variant description A machine-readable description of a variant resource, usually found in a variant list. A variant description contains a variant resource identifier and various attributes which describe properties of the variant. Variant resource A data resource for which multiple representations (variants) are available. 3. Framework Content negotiation covers three elements: 1. expressing the capabilities of the sender (as far as a particular message is concerned), 2. expressing the capabilities of a receiver (in advance of the transmission of the message), and 3. a protocol by which capabilities are exchanged. These elements are addressed by a negotiation framework incorporating a number of design elements with dependencies as shown below. [ Abstract ] [ Abstract ] [negotiation] [ negotiation ] [ process ] [ metadata ] | | V V [Negotiation] [ Negotiation ] [ protocol ] [ metadata ] [ binding ] [representation] | | ------- ------- | | V V [Application protocol] [ incorporating ] [content negotiation ] Klyne [Page 7] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Within this overall framework, expressing the capabilities of sender and receiver is covered by negotiation metadata. The protocol for exchanging capabilities is covered by the abstract negotiation framework its binding to a specific application protocol. Application protocol independence is addressed by separating the abstact negotiation process and metadata from concrete representations and protocol bindings. 3.1 Abstract framework for content negotiation [[Describe arbitrary exchange of information leading to confirmed message transmission]] 3.2 Abstract model for negotiation metadata [[Naming]] [[Values (data types)]] 3.3 Text representation for negotiation metadata [[For use with text-based protocols like MIME, etc.]] [[Also reference the character set[s] to be used: USASCII, UTF-8, UTF-7, etc. Pick up this point under requirements.]] 3.4 ASN.1 description of negotiation metadata Concrete ASN.1 description and encoding designation for the negotiation metadata. [[For use with ASN.1-derived protocols like X.400, X.500, LDAP, SNMP, etc.]] 3.5 Protocol binding guidelines Specific protocol bindings will be needed to use the abstract framework for negotiation. Details of protocol bindings would be beyond the scope of this work, but guidelines would probably not. (SASL might provide a useful model here.) Klyne [Page 8] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation 4. Requirements [[[The following adapted from Internet Fax requirements]]] . If capabilities are being sent at times other than the time of message transmission, then they should include sufficient information to allow them to be validated, authenticated, etc. . In the context of a given application, content negotiation may use one or several methods for transmission, storage, or distribution of capabilities. . A request for capability information, if sent to a party at any time other than the immediate time of delivery of the message, should clearly identify the requester, the party whose capabilities are being requested, and the time of the request. Some kind of signature would also be advisable. . A capability assertion should clearly identify the party to whom the capabilities apply, the party to whom they are being sent, and some indication of their date/time or range of validity. To be secure, capability assertions SHOULD be protected against interception and substitution of valid data by invalid data. [[[The plan is to trawl existing documents for relevant requirements, and assemble them here for debate. I intend to start by going "over the top" and later culling the inappropriate ones.]]] [[Sources to check: draft-ietf-http-negotiate-scenario-xx.txt ]] Some requirements might be: - The negotiation process must result in an agreed form of message data to be transferred. - A uniform mechanism for exchanging negotiation metadata should be provided which can encompass all existing negotiatiable features and is extensible to future (unanticipated) features. Klyne [Page 9] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation - Efficient negotiation should be possible in both receiver initiated ('pull') and sender initiated ('push') message transfers. - Negotiation metadata should be regarded as cacheable, and explicit cache control mechanisms provided to forestall the introduction of ad-hoc cache-busting techniques. - The structure of the negotiation procedure should stand independently of any particular message transfer protocol. I note that the requirements might be separated into two categories: (1) Negotiation framework and metadata requirements which address the broad goals of negotiation in a protocol-independent fashion. (2) Specific requirements which relate to negotiation issues specific to operating in the context of a specific protocol (e.g. relation to HTTP protocol operations, cache interactions, security issues, existing HTTP negotiation mechanisms, application to variant selection, etc.). These would be dealt with by a document dealing with a specific protocol binding for the negotiation framework. 5. Technical issues [[[The idea of this is to highlight any additional technical issues which might fall out of the requirements or out of other discussions which don't fit comfortably in the previous sections.]]] 5.1 Non-message resource transfers (Can this make sense?) 5.2 End-to-end vs hop-by-hop negotiations End-to-end negotiation gives greatest confidence in the outcome. Klyne [Page 10] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Hop-by-hop may have advantages in a network of occasionally- connected systems, but will pace additional demands on intervening message transmission agents. 5.3 Billing issues (Dan Wing's internet draft on DSN status code extensions for Internet fax, and others, raise issues in this area.) (Also there is an issue of who pays for return messages, etc., in a non-connected environment like e-mail or fax.) 5.4 Use of directory services (Using existing protocols such as LDAP to exchange content negotiation metadata.) 5.5 Performance considerations (Number of round trips.) (Volume of data transferred.) (Latency/bandwidth/cost trade-offs.) 5.6 Confidence levels in negotiated options In some cases (e.g. when there has been a direct exchange of information with the remote system) the communicating parties will have a high degree of confidence in the negotiation options obtained. In such, a data exchange can be performed without need for subsequent confirmation that the options used were acceptable. In other cases, the options will be a best-guess, and it may be necessary to make provision for parties to reject the options actually used in preference for some other set. This consideration is likely to interact with performance considerations. Klyne [Page 11] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation 5.7 Messages vs streamed data The debate to date has focussed mainly on message data (i.e. data whose entire content is decided before the start of data transmission). Does this proposed approach to negotiation reasonably extend to streamed data (e.g. data whose content is not fully determined by the time the first data items are transmitted)? [[I suspect the metadata will be OK, but the abstract negotiation framework may be more difficult.]] 6. Security considerations [[[Again, trawl through existing documents. Later, this should be used as a checklist and cross-referenced to the requirements which address them.]]] 6.1 Privacy (Unintended disclosure of personal information.) (Spoofed requests for negotiation data.) 6.2 Denial of service attacks 6.3 Mailing list interactions 6.4 Use of security services (Authenticated requests) (Authenticated responses) (Encrypted responses) (Authenticated protocol session) (Encrypted protocol session?) (Authenticated transport connections) (Encrypted transport connections) Klyne [Page 12] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation 7. Copyright Copyright (C) The Internet Society 1997. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Acknowledgements Material in this draft has been taken from [....] (Koen Holtman/Andrew Mutz, TCN and feature drafts). (Ted Hardie, scenarios for negotiated content). (Larry Masinter, display attributes) (Dan Wing/Neil Joffe, SMTP Capabilities) Klyne [Page 13] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation 9. References [1] "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" N. Freed, Innosoft N. Borenstein,... RFC 2045 [2] "Multipurpose Internet Mail Extensions (MIME) Part One: ...." N. Freed, Innosoft N. Borenstein,... RFC 2046 [3] "The Alternates Header Field" K. Holtman, TUV, et al. Internet draft: Work in progress, November 1997. [4] "Scenarios for the Delivery of Negotiated Content" T. Hardie, NASA Network Information Center Internet draft: Work in progress, November 1997. [5] "Transparent Content Negotiation in HTTP" Koen Holtman, TUE Andrew Mutz, Hewlett Packard Internet draft: Work in progress, May 1997. [[[Lots more to come]]] 10. Author's address Graham Klyne Integralis Ltd Brewery Court 43-45 High Street Theale Reading, RG7 5AH United Kingdom Telephone: +44 118 930 6060 Facsimile: +44 118 930 2143 E-mail: GK@ACM.ORG Klyne [Page 14] Internet draft 6 December 1997 Requirements for protocol-independent content negotiation Klyne [Page 15]