rfc2703.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页

Network Working Group                                         G. Klyne
Request for Comments: 2703                    5GM/Content Technologies
Category: Informational                                 September 1999


           Protocol-independent Content Negotiation Framework

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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.

   This memo sets out terminology, an abstract framework and goals 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 goals set out the desired
   properties of a content negotiation mechanism.

Table of Contents

   1. Introduction.............................................2
     1.1 Structure of this document ...........................3
     1.2 Discussion of this document ..........................3
   2. Terminology and definitions..............................3
   3. Framework................................................7
     3.1 Abstract framework for content negotiation ...........8
        3.1.1 The negotiation process..........................9
     3.2 Abstract model for negotiation metadata .............10
     3.3 Text representation for negotiation metadata ........11
     3.4 ASN.1 description of negotiation metadata ...........11
     3.5 Protocol binding guidelines .........................11
   4. Goals...................................................12



Klyne                        Informational                      [Page 1]

RFC 2703        Protocol-independent Content Negotiation  September 1999


     4.1 Generic framework and metadata goals ................12
     4.2 Protocol-specific deployment goals ..................12
   5. Technical issues........................................14
     5.1 Non-message resource transfers ......................14
     5.2 End-to-end vs hop-by-hop negotiations ...............14
     5.3 Third-party negotiation .............................15
     5.4 Use of generic directory and resolution services ....15
     5.5 Billing issues ......................................15
     5.6 Performance considerations ..........................15
     5.7 Confidence levels in negotiated options .............16
   6. Security Considerations.................................16
     6.1 Privacy .............................................16
     6.2 Denial of service attacks ...........................17
     6.3 Mailing list interactions ...........................17
     6.4 Use of security services ............................17
     6.5 Disclosure of security weaknesses ...................18
        6.5.1 User agent identification.......................18
        6.5.2 Macro viruses...................................18
        6.5.3 Personal vulnerability..........................18
     6.6 Problems of negotiating security ....................18
   7. Acknowledgements........................................18
   8. References..............................................19
   9. Author's Address........................................19
   10. Full Copyright Statement...............................20

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.

   This memo sets out terminology, a framework and some goals 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 goals 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.







Klyne                        Informational                      [Page 2]

RFC 2703        Protocol-independent Content Negotiation  September 1999


1.1 Structure of this document

   The main part of this memo 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 various goals for content negotiation.

   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 registration mailing list hosted by the
   Internet Mail Consortium (IMC).

   Please send comments regarding this document to:

      [e-mail]

   To subscribe to this list, send a message with the body 'subscribe'
   to "[e-mail]".

   To see what has gone on before you subscribed, please see the mailing
   list archive at:

      http://www.imc.org/ietf-medfree/

2. Terminology and definitions

   This section introduces a number of terms which are used with
   specific meaning in the content negotiation documents. 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.






Klyne                        Informational                      [Page 3]

RFC 2703        Protocol-independent Content Negotiation  September 1999


   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 the media handling properties
             of a message passing system component or of a data
             resource.

   Feature tag
             A name that identifies a "feature".

   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' describes full set of
             possible attributes.




Klyne                        Informational                      [Page 4]

RFC 2703        Protocol-independent Content Negotiation  September 1999


   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.

   Media feature
             information that indicates facilities assumed to be
             available for the message content to be properly rendered
             or otherwise presented.  Media features are not intended to
             include information that affects message transmission.

   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.

   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



Klyne                        Informational                      [Page 5]

RFC 2703        Protocol-independent Content Negotiation  September 1999


             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.

   Syntax    The form used to express some value;  especially the format
             used to express a media feature value, or a feature set.
             (See also: feature value, feature set, type.)




Klyne                        Informational                      [Page 6]

RFC 2703        Protocol-independent Content Negotiation  September 1999


   Transmission
             The process of transferring a message from a sender to a
             receiver.  This may include content negotiation.

   Type      The range of values that can be indicated by some
             identifier of variable;  especially the range of values
             that can be indicated by a feature tag.  (See also:
             feature, syntax.)

             NOTE:  this differs from usage employed by the LDAP/X.500
             directory community, who use the terms "attribute type" to
             describe an identifier for a value in a directory entry,
             and "attribute syntax" to describe a range of allowed
             attribute values.

   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.