Internet DRAFT - draft-klyne-conneg-requirements
draft-klyne-conneg-requirements
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
<draft-klyne-conneg-requirements-00.txt>
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: <draft-ietf-http-alternates-01.txt>
Work in progress, November 1997.
[4] "Scenarios for the Delivery of Negotiated Content"
T. Hardie, NASA Network Information Center
Internet draft: <draft-ietf-http-negotiate-scenario-02.txt>
Work in progress, November 1997.
[5] "Transparent Content Negotiation in HTTP"
Koen Holtman, TUE
Andrew Mutz, Hewlett Packard
Internet draft: <draft-ietf-http-negotiation-02>
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]
