protocols.  At the time of writing, it is unclear if or when this
     research will lead to results in the form of complete negotiation
     system specifications.  It is also unclear to which extent possible
     future specifications can or will re-use elements of this
     experimental protocol.

1.1 Background

   The addition of content negotiation to the web infrastructure has
   been considered important since the early days of the web.  Among the
   expected benefits of a sufficiently powerful system for content
   negotiation are

     * smooth deployment of new data formats and markup tags will
       allow graceful evolution of the web

     * eliminating the need to choose between a `state of the art
       multimedia homepage' and one which can be viewed by all web users

     * enabling good service to a wider range of browsing
       platforms (from low-end PDA's to high-end VR setups)




 
RFC 2295            Transparent Content Negotiation           March 1998


     * eliminating error-prone and cache-unfriendly
       User-Agent based negotiation

     * enabling construction of sites without `click here for the X
       version' links

     * internationalization, and the ability to offer multi-lingual
       content without a bias towards one language.

2  Terminology

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
   this document are to be interpreted as described in RFC 2119 [4].

   This specification uses the term `header' as an abbreviation for for
   `header field in a request or response message'.

2.1 Terms from HTTP/1.1

   This specification mostly uses the terminology of the HTTP/1.1
   specification [1].  For the convenience of the reader, this section
   reproduces some key terminology definition from [1].

   request
     An HTTP request message.

   response
     An HTTP response message.

   resource
     A network data object or service that can be identified by a URI.
     Resources may be available in multiple representations (e.g.
     multiple languages, data formats, size, resolutions) or vary in
     other ways.

   content negotiation
     The mechanism for selecting the appropriate representation when
     servicing a request.

   client
     A program that establishes connections for the purpose of sending
     requests.

   user agent
     The client which initiates a request.  These are often browsers,
     editors, spiders (web-traversing robots), or other end user tools.






 
RFC 2295            Transparent Content Negotiation           March 1998


   server
     An application program that accepts connections in order to service
     requests by sending back responses.  Any given program may be
     capable of being both a client and a server; our use of these terms
     refers only to the role being performed by the program for a
     particular connection, rather than to the program's capabilities in
     general.  Likewise, any server may act as an origin server, proxy,
     gateway, or tunnel, switching behavior based on the nature of each
     request.

   origin server
     The server on which a given resource resides or is to be created.

   proxy
     An intermediary program which acts as both a server and a client