interpretation of the response or the available representations. It
   is expected that Alternates will provide a significant improvement
   over the server-driven negotiation provided by the Vary field for
   those resources that vary over common dimensions like type and
   language.

   The Alternates header field will be defined in a future
   specification.

19.6.2.2 Content-Version

   The Content-Version entity-header field defines the version tag
   associated with a rendition of an evolving entity. Together with the
   Derived-From field described in section 19.6.2.3, it allows a group
   of people to work simultaneously on the creation of a work as an
   iterative process. The field should be used to allow evolution of a
   particular work along a single path rather than derived works or
   renditions in different representations.

          Content-Version = "Content-Version" ":" quoted-string

   Examples of the Content-Version field include:

          Content-Version: "2.1.2"
          Content-Version: "Fred 19950116-12:26:48"
          Content-Version: "2.5a4-omega7"

19.6.2.3 Derived-From

   The Derived-From entity-header field can be used to indicate the
   version tag of the resource from which the enclosed entity was
   derived before modifications were made by the sender. This field is
   used to help manage the process of merging successive changes to a
   resource, particularly when such changes are being made in parallel
   and from multiple sources.

          Derived-From   = "Derived-From" ":" quoted-string

   An example use of the field is:

          Derived-From: "2.1.1"

   The Derived-From field is required for PUT and PATCH requests if the
   entity being sent was previously retrieved from the same URI and a
   Content-Version header was included with the entity when it was last
   retrieved.




 
RFC 2068                        HTTP/1.1                    January 1997


19.6.2.4 Link

   The Link entity-header field provides a means for describing a
   relationship between two resources, generally between the requested
   resource and some other resource. An entity MAY include multiple Link
   values. Links at the metainformation level typically indicate
   relationships like hierarchical structure and navigation paths. The
   Link field is semantically equivalent to the  element in
   HTML.[5]

          Link           = "Link" ":" #("<" URI ">" *( ";" link-param )

          link-param     = ( ( "rel" "=" relationship )
                             | ( "rev" "=" relationship )
                             | ( "title" "=" quoted-string )
                             | ( "anchor" "=" <"> URI <"> )
                             | ( link-extension ) )

          link-extension = token [ "=" ( token | quoted-string ) ]

          relationship   = sgml-name
                         | ( <"> sgml-name *( SP sgml-name) <"> )

          sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )

   Relationship values are case-insensitive and MAY be extended within
   the constraints of the sgml-name syntax. The title parameter MAY be
   used to label the destination of a link such that it can be used as
   identification within a human-readable menu. The anchor parameter MAY
   be used to indicate a source anchor other than the entire current
   resource, such as a fragment of this resource or a third resource.

   Examples of usage include:

       Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"

       Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"

   The first example indicates that chapter2 is previous to this
   resource in a logical navigation path. The second indicates that the
   person responsible for making the resource available is identified by
   the given e-mail address.

19.6.2.5 URI

   The URI header field has, in past versions of this specification,