rfc2703.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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 explicitly disregarded:  it is presumed that these
   will be dealt with separately by some orthogonal mechanism.









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


   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.

   These negotiation elements are addressed by a negotiation framework
   incorporating a number of design elements with dependencies shown:

             [ 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 and its binding to a specific application protocol.

   Application protocol independence is addressed by separating the
   abstract 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.




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


   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
     (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 a 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
   implement 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) [5] uses a model
   in which one of the following happens:

   o  The recipient requests a resource with no variants, in which case
      the sender simply sends what is available.




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


   o  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.

   o  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.

   Another, simpler example is that of fax negotiation:  in this case
   the intended recipient declares its capabilities, and the sender
   chooses a message variant to match.

   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/alternative' in conjunction with e-mail message
   transmission.

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 encompass the following elements:

   o  Media feature: a way to describe attributes of a data resource.

   o  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.

   o  One or more naming schemes for labelling media features and
      feature sets.  These should be backed up by some kind of
      registration process to ensure uniqueness of names and to
      encourage a common vocabulary for commonly used features.

   o  A framework of data types for media features, indicating the range
      and properties of value types which can be represented.





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


   o  A way to combine 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).

   o  Some 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.

   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 maybe not.  (SASL might provide a useful model here.)






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


4. Goals

   These goals are presented in two categories:

   1. Negotiation framework and metadata goals which address the broad
      goals of negotiation in a protocol-independent fashion.

   2. Specific goals 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 selection, etc.).
      These would be addressed by a specific protocol binding for the
      negotiation framework.

4.1 Generic framework and metadata goals

   o  A common vocabulary for designating features and feature sets.

   o  A stable reference for commonly used features.

   o  An extensible framework, to allow rapid and easy adoption of new
      features.

   o  Permit an indication of quality or preference.

   o  Capture dependencies between feature values

   o  A uniform framework mechanism for exchanging negotiation metadata
      should be defined that can encompass existing negotiable features
      and is extensible to future (unanticipated) features.

   o  Efficient negotiation should be possible in both receiver
      initiated ('pull') and sender initiated ('push') message
      transfers.

   o  The structure of the negotiation procedure framework should stand
      independently of any particular message transfer protocol.

   o  Be capable of addressing the role of content negotiation in
      fulfilling the communication needs of less able computer users.

4.2 Protocol-specific deployment goals

   o  A negotiation should generally result in identification of a
      mutually acceptable form of message data to be transferred.






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


   o  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.

   o  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.

   o  A request for capability information, if sent other than in
      response to 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.

   o  In the context of a given application, content negotiation may use
      one or several methods for transmission, storage, or distribution
      of capabilities.

   o  The negotiation mechanism should include a standardized method for
      associating features with resource variants.

   o  Negotiation should provide a way to indicate provider and
      recipient preferences for specific features.

   o  Negotiation should have the minimum possible impact on network
      resource consumption, particularly in terms of bandwidth and
      number of protocol round-trips required.

   o  Systems should protect the privacy of users' profiles and
      providers' inventories of variants.

   o  Protocol specifications should identify and permit mechanisms to
      verify the reasonable accuracy of any capability data provided.

   o  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.

   o  Intelligent gateways, proxies, or caches should be allowed to
      participate in the negotiation.

   o  Negotiation metadata should be regarded as cacheable, and explicit
      cache control mechanisms provided to forestall the introduction of
      ad-hoc cache-busting techniques.





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


   o  Automatic negotiation should not pre-empt a user's ability to
      choose a document format from those available.

5. Technical issues

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.

   Message data is defined elsewhere as a data whose entire content is
   decided before the start of data transmission.  The following are
   examples of non-message data transfers.

   o  streamed data,