One document matched: draft-ietf-conneg-requirements-00.txt
IETF media feature registration WG Graham Klyne
Internet draft Integralis Ltd.
3 March 1998
Expires: 3 September 1998
Requirements for protocol-independent content negotiation
<draft-ietf-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 terminology, an abstract framework and
requirements for protocol-independent content negotiation, and
identifies some 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 3 March 1998
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
1.4 Unfinished business ..................................4
2. Terminology and definitions..............................5
3. Framework................................................8
3.1 Abstract framework for content negotiation ...........10
3.1.1 The negotiation process..........................10
3.2 Abstract model for negotiation metadata ..............11
3.3 Text representation for negotiation metadata .........12
3.4 ASN.1 description of negotiation metadata ............12
3.5 Protocol binding guidelines ..........................13
4. Requirements.............................................13
4.1 Generic framework and metadata requirements ..........13
4.2 Protocol-specific deployment requirements ............14
5. Technical issues.........................................15
5.1 Non-message resource transfers .......................15
5.2 End-to-end vs hop-by-hop negotiations ................16
5.3 Third-party negotiation ..............................16
5.4 Use of directory services ............................16
5.5 Billing issues .......................................17
5.6 Performance considerations ...........................17
5.7 Confidence levels in negotiated options ..............17
6. Security considerations..................................18
6.1 Privacy ..............................................18
6.2 Denial of service attacks ............................18
6.3 Mailing list interactions ............................18
6.4 Use of security services .............................18
7. Copyright................................................19
8. Acknowledgements.........................................19
9. References...............................................20
10. Author's address........................................21
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, 2] 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 [4].
Klyne [Page 2]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
This draft sets out terminology, a framework and requirements for a
protocol-independent content negotiation framework, and identifies
some 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.
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 defines some 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 place on the content
negotiation and media feature reagistration mailing list hosted by
the Internet Mail Consortium (IMC):
Please send comments regarding this document to:
ietf-medfree@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-medfree-request@imc.org". You should get a reply as
follows:
Klyne [Page 3]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
The "ietf-medfree" 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-medfree/
To unsubscribe from the ietf-medfree mailing list, send a message
to "ietf-medfree-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.
00c 27-Feb-1998
Update mailing list details.
Updated terminology entries, particularly to distinguish
between a feature and a feature set.
Fleshed out the abstract framework sections.
Added more requirements, and reorganized that section.
Written up technical issues, as identified so far.
1.4 Unfinished business
. Finalize requirements
. Finalize technical issues
. Security considerations section
. Acknowledgements section
Klyne [Page 4]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
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.
Characteristic
Some description of a sender or receiver which indicates
a possible capability or preference.
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)
Content feature
(see Feature)
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, Resource)
Feature A piece of information about a resource.
Klyne [Page 5]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
Feature set
Information about a sender, recipient, data file or other
participant in a message transfer which describes the set
of features that it can handle.
Where a 'feature' describes a single identified attribute
of a resource, a 'feature set' descibes full set of
possible attributes.
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 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.
Message data is distinguished from other transmitted data
by the fact that its content is fully determined before
the start of transmission.
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 6]
Internet draft 3 March 1998
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.
Preference
An attribute of a sender or receiver (often the receiver)
which indicates an preference to generate or process one
particular type of message content over another, even if
both are possible.
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.
Resource a document, data file or facility which is accessed or
transmitted across a network.
(See also: Data resource)
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.
Klyne [Page 7]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
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.
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
For the purposes of this document, message transmission protocol
capabilities are explcitly disregarded: it is presumed that these
will be dealt with separately by some orthogonal mechanism.
Content negotiation covers three elements:
1. expressing the capabilities of the sender and the data resource
to be transmitted (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.
Klyne [Page 8]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
These negotiation 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 ]
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
The negotiation framework provides for an exchange of negotiation
metadata between the sender and receiver of a message which leads
to determination of a data format which the sender can provide and
the recipient can process. Thus, there are three main elements
which are the subjects of the negotiation process and whose
capabilities are described by the negotiation metadata: the sender,
the transmitted data file format and the receiver.
The life of a data resource may be viewed as:
(C) (T) (F)
[A]-->--[S]-->--[R]-->--[U]
where:
[A] = author of document
(C) = original document content
[S] = message sending system
Klyne [Page 9]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
(T) = transmitted data file (representation of (C))
[R] = receiving system
(F) = formatted (rendered) document data (presentation of (C))
[U] = user or consumer of a document
Here, it is [S] and [R] who exchange negotiation metadata to decide
the form of (T), so these elements are the focus of our attention.
Negotiation metadata provided by [S] would take account of
available document content (C) (e.g. availability of resource
variants) as well as its own possible ability to offer that content
in variety of formats.
Negotiation metadata provided by [R] would similarly take account
of the needs and preferences of its user [U] as well as its own
capabilities to process and render received data.
3.1.1 The negotiation process
Negotiation between the sender [S] and the receiver [R] consists of
a series of negotiation metadata exchanges that proceeds until
either party determines a specific data file (T) to be transmitted.
If the sender makes the final determination, it can send the file
directly. Otherwise the receiver must communicate its selection to
the sender who sends the indicated file.
This process implies an open-ended exchange of information between
sender and receiver. Not every implementation is expected to
implent this scheme with the full generality thus implied. Rather,
it is expected that every concrete negotiation can be viewed as a
subset of this process.
For example, Transparent Content Negotiation (TCN) described in [5]
uses a model in which one of the following happens:
. The recipient requests a resource with no variants, in which case
the sender simply sends what is available.
. A variant resource is requested, in which case the server replies
with a list of available variants, and the client chooses one
variant from those offered.
. The recipient requests a variant resource, and also provides
negotiation metadata (in the form 'Accept' headers) which allows
the server to make a choice on the client's behalf.
Each of these can be viewed as a particular case of the general
negotiation process described above. Similar observations can be
made regarding the use of directory services or MIME Multipart/
alternate in conjucntion with e-mail message transmission.
Klyne [Page 10]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
3.2 Abstract model for negotiation metadata
A simple but general negotiation framework has been described,
which is based on the exchange of negotiation metadata between
sender and recipient. The mechanism by which data is exchanged is
not important to the abstract negotiation framework, but something
does need to be said about the general form of the metadata.
The terminology and definitions section of this document places
constraints on the form of negotiation metadata, and the
descriptions that follow should be read in conjunction with the
definitions to which they refer.
Negotiation metadata needs to encompas the following elements:
. Media feature: a way to describe attributes of a data resource.
. Feature set: a description of a range of possible media feature
combinations which can be offered by a sender, represented by a
data file format or processed by a receiver.
. One or more naming schemes for labeling media features and
feature sets. These should probably be backed up by some kind of
registration process to ensure uniqueness of names and to
encourage a common vocabulary for commonly used features.
[[Text and binary format names? Separate name spaces for features
and feature sets?]]
. A framework of data types for media features, indicating the
range and properties of value types which can be represented.
. An algebra for combining media features into feature sets,
capable of expressing feature dependencies within a feature set
(e.g. 640x480 pixel size and 256 colours, or 800x600 pixel size
and 16 colours).
. Mechanisms which provide a way to rank feature sets based upon
sender and receiver preferences for different feature values.
3.3 Text representation for negotiation metadata
A concrete textual representation for media feature values and
feature set descriptions would provide a common vocabulary for
feature data in text-based protocols like HTTP and SMTP.
Use of a common textual representation is not a requirement, but it
would clearly be desirable.
Klyne [Page 11]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
In defining a textual representation, the issue of allowable
character sets needs to be addressed. Whether or not negotiation
metadata needs to support a full gamut of international characters
will depend upon the framework of data types adopted for media
features. As negotiation metadata would be used as a protocol
element (not directly visible to the user) rather than part of the
message content, support for extended character sets may be not
required.
A textual representation for negotiation metadata would imply a
textual representation for media feature names, and also for
expressions of the media feature combining algebra.
3.4 ASN.1 description of negotiation metadata
For use with non-text-based protocols, an ASN.1 description and
encoding designation for negotiation metadata could be helpful for
incorporating the common negotiation framework into ASN.1-derived
protocols like X.400, X.500, LDAP and SNMP.
An ASN.1 description of negotiation metadata formats suggests that
separate media feature naming scheme based on ISO object
identifiers would be valuable.
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.)
4. Requirements
[[This section aims to overstate rather than understate the
requirements, in order to seed a debate about what is *really*
required.]]
These requirements are presented in 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 the deployment of
negotiation 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
Klyne [Page 12]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
selection, etc.). These would be addressed by a specific protocol
binding for the negotiation framework.
4.1 Generic framework and metadata requirements
. A common vocabulary for designating features and feature sets.
. A stable reference for commonly used features.
. An extensible framework, to allow rapid and easy adoption of new
features.
. Permit an indication of quality or preference.
. Capture dependencies between feature values
. A uniform framework mechanism for exchanging negotiation metadata
should be defined that can encompass all existing negotiatiable
features and is extensible to future (unanticipated) features.
. Efficient negotiation should be possible in both receiver
initiated ('pull') and sender initiated ('push') message
transfers.
. The structure of the negotiation procedure framework should stand
independently of any particular message transfer protocol.
. Recognize and address the role of content negotiation in
fulfilling the communication needs of less able computer users.
4.2 Protocol-specific deployment requirements
. A negotiation should generally result in identification of a
mutually acceptable form of message data to be transferred.
. 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 verified and authenticated.
. 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.
. A request for capability information, if sent other than at the
immediate time of delivery of a message, should clearly identify
the requester, the party whose capabilities are being requested,
and the time of the request. It should include sufficient
information to allow the request to be authenticated.
Klyne [Page 13]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
. In the context of a given application, content negotiation may
use one or several methods for transmission, storage, or
distribution of capabilities.
. The negotiation mechanism should include a standardized method
for associating features with resource variants.
. Negotiation should provide a way to indicate provider and
recipient preferences for specific features.
. Negotiation should have the minimum possible impact on network
resource consumption, especially in terms of bandwidth and number
of protocol round-trips required.
. Systems should protect the privacy of users' profiles and
providers' inventories of variants.
. Protocol specifications should identify and permit mechanisms to
verify the reasonable accuracy of any capability data provided.
. Negotiation must not significantly jeopardize the overall
operation or integrity of any system in the face of erroneous
capability data, whether accidentally or maliciously provided.
. Intelligent gateways, proxies, or caches should be allowed to
participate in the negotiation.
. Negotiation metadata should be regarded as cacheable, and
explicit cache control mechanisms provided to forestall the
introduction of ad-hoc cache-busting techniques.
. Automatic negotiation should not pre-empt a user's ability to
choose a document format from those available.
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
The ideas for generic content negotiation have been conceived and
developed in the context of message-oriented data transmissions.
. streamed dat,
. interactive computations,
Klyne [Page 14]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
. real-time data acqisition,
... and any others?
Message data is defined elsewhere as a data whose entire content is
decided before the start of data transmission.
Does a proposed approach to negotiation based on message data
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
process framework may be more difficult.]]
5.2 End-to-end vs hop-by-hop negotiations
Could this distinction place any special demands or constraints on
a generic negotiation framework, or is this simply a protocol
issue?
. End-to-end negotiation gives greatest confidence in the outcome.
. Hop-by-hop may have advantages in a network of occasionally-
connected systems, but will place additional demands on
intervening message transmission agents.
Hop-by-hop negotiation implies that negotiation responses are not
necessarily a definitive indication of an endpoint system's
capabilities. This in turn implies a possible need for time-to-
live and re-verification mechanisms to flush out stale negotiation
data.
Note that one of the stated requirements is to allow proxies and
caches to participate in the negotiation process.
5.3 Third-party negotiation
An extension of the hop-by-hop vs end-to-end negotiation theme is
to consider the implications of allowing any system other than an
endpoint participant in the message transmission to supply
negotiation metadata.
Any use of a third party in the negotiation process inevitably
increases the possibilities for introducing errors into the
negotiation metadata.
One particular exaple of a third party participant in a negotiation
process that is frequently suggested is the use of a directory
service using LDAP or similar protocols. What additional steps need
Klyne [Page 15]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
to be taken to ensure reasonable reliability of negotiation
metadata supplied by this means?
5.4 Use of directory services
(Using existing protocols such as LDAP to exchange content
negotiation metadata.)
(Will it be necessary to define directory schema elements which are
specific to content negotiation. For example, an attribute type
for a media feature set?)
5.5 Billing issues
Negotiation may raise some billing-related issues in some contexts
because it potentially incurs a two-way exchange of data not
necessarily completed during a single connection. There is an
issue of who pays for return messages, etc., in a non-connected
environment like e-mail or fax.
(Dan Wing's internet draft on DSN status code extensions for
Internet fax [6] and others, raise issues in this area.)
5.6 Performance considerations
Negotiation can impact performance in both postive and negative
ways.
The obvious negative impact arises from the exchange of additional
data which necessarily consumes some additional bandwidth. There
is also an issue of round-trip or third-party query delays while
negotiation metadata is being exchanged before transmission of the
message itself is commenced.
Over the Internet, there are some bandwidth/latency trade-offs
which can be made. For example, in Internet e-mail the MIME type
Multipart/alternate can be used to send multiple versions of a
resource: this preserves latency by using aditional bandwidth to
send a greater volume of data. On the other hand, HTTP [7]
suggests a negotiation mechanism which preserves bandwidth at the
cost of introducing a round-trip delay (section 12.2, Agent-driven
negotiation).
To set against the negative performance impact of content
negotiation, it is to be hoped that overall network efficiency is
to be improved if it results in the most useful data format being
delivered to its intended recipient, first time every time.
Klyne [Page 16]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
5.7 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. Here, 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.
A useful pattern, adopted by TCN [5], is to define a negotiation
procedure which guarantees a correct outcome. This forms the
foundation for a procedure which attempts uses easily-obtained but
less reliable information in an attempt to optimize the negotiation
process but that contains checks to guarantee the final result will
be the same as would have been obtained by the full negotiation
procedure. Such procedures sometimes have to resort to the
original "full cycle" negotiation procedure, but in a majority nof
cases are expected to reach their conclusion by an optimized route.
6. Security considerations
[[[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)
Klyne [Page 17]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
(Authenticated protocol session)
(Encrypted protocol session?)
(Authenticated transport connections)
(Encrypted transport connections)
7. Copyright
Copyright (C) The Internet Society 1998. 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 18]
Internet draft 3 March 1998
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, First Virtual
RFC 2045
November 1996
[2] "Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types"
N. Freed, Innosoft
N. Borenstein, First Virtual
RFC 2046
November 1996
[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.
[6] "Extensions to Delivery Status Notifications for Fax"
Dan Wing, Cisco Systems
Internet draft: <draft-ietf-fax-dsn-extensions-00.txt>
Work in progress, November 1997
[7] "Hypertext Transfer Protocol -- HTTP/1.1"
R. Fielding, US Irvine
J. Gettys,
J. Mogul, DEC
H. Frystyk,
T Berners-Lee, MIT/LCS
RFC 2068
January 1997
Klyne [Page 19]
Internet draft 3 March 1998
Requirements for protocol-independent content negotiation
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 20]
| PAFTECH AB 2003-2026 | 2026-04-21 21:19:41 |