Proposed Standard for Alternates header

In the Munich IETF meeting, Jim Gettys suggested that, if the
Alternates header definition is taken out of the transparent content
negotiation draft (draft-ietf-http-negotiation-03.txt) it would be
possible for this WG to quickly reach consensus on making the
Alternates header a Proposed Standard.

There was some agreement on this from the room.  The purpose of this
message is to see if there is agreement on the mailing list too.
Please speak up now, before I start seriously editing stuff, if you
are (currently) opposed to creating a Proposed Standard for
Alternates.

I have made a preliminary go at putting together the Alternates header
specification I think people want to proceed with.  The result is
below.  Note that there are some loose ends with respect to syntax and
terminology definitions.  Comments are welcome.

Koen.

--snip--


1 Alternates header definition

   When returning a particular piece of content, a server may wish to
   notify the client that this content is available in multiple
   versions, called variants.  This can be done by including an
   Alternates header, which lists the available variants, in the
   response.  The Alternates header can also be used in a response
   which does not include a version itself, but simply informs the
   client that multiple versions are available.

   The Alternates header describes all available variants the server
   has available.  The description for each variant includes an URI
   from which this variant can be retrieved.  The Alternates header can
   also contain directives for any subsequent negotiation process.

       Alternates = "Alternates" ":" variant-list

       variant-list = 1#( variant-description ; see section 2
                        | fallback-variant
                        | list-directive )

       fallback-variant = "{" <"> URI <"> "}"

       list-directive = extension-list-directive

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

   An example is

     Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
                 {"paper.html.fr" 0.7 {type text/html} {language fr}},
                 {"paper.ps.en"   1.0 {type application/postscript}
                     {language en}},
                 {"paper.html.en"}, x=y

   Any relative URI specified in a variant-description or
   fallback-variant field is relative to the request-URI.  Only one
   fallback-variant field may be present.  If the variant selection
   algorithm of the user agent finds that all described variants are
   unacceptable, then it SHOULD choose the fallback variant, if
   present, as the best variant.  If the user agent computes the
   overall quality values of the described variants, and finds that
   several variants share the highest value, then the first variant
   with this value in the list SHOULD be chosen as the best variant.

   A variant list may contain multiple differing descriptions of the
   same variant.  This can be convenient if the variant uses
   conditional rendering constructs, or if the variant resource
   returns multiple representations using a multipart media type.


2  Variant descriptions

2.1 Syntax

   A variant can be described in a machine-readable way with a variant
   description.

       variant-description =
                  "{" <"> URI <"> source-quality *variant-attribute"}"

       source-quality = qvalue

       variant-attribute = "{" "type" media-type "}"
                         | "{" "charset" charset "}"
                         | "{" "language"  1#language-tag "}"
                         | "{" "length" 1*DIGIT "}"
                         | extension-attribute

       extension-attribute = "{" extension-name extension-value "}"
       extension-name      = token
       extension-value     = *( token | quoted-string | LWS
                              | extension-specials )

       extension-specials  =
                          <any element of tspecials except <"> and "}">

   Examples are

      {"paper.2" 0.7 {type text/html} {language fr}}

      {"paper.5" 0.9 {type text/html} {length 1002}}

      {"paper.1" 0.001}

   The various attributes which can be present in a variant
   description are covered in the subsections below.  Each attribute
   may appear only once in a variant description.


2.2 URI

   The URI attribute gives the URI of the resource from which the
   variant can be retrieved with a GET request.  It can be absolute or
   relative to the Request-URI.  The variant resource may vary (on the
   Cookie request header, for example), but MUST NOT engage in
   transparent content negotiation itself.


2.3 Source-quality

   The source-quality attribute gives the quality of the variant, as a
   representation of the negotiable resource, when this variant is
   rendered with a perfect rendering engine on the best possible
   output medium.

   If the source-quality is less than 1, it often expresses a quality
   degradation caused by a lossy conversion to a particular data
   format.  For example, a picture originally in JPEG form would have
   a lower source quality when translated to the XBM format, and a
   much lower source quality when translated to an ASCII-art variant.
   Note however, that degradation is a function of the source; an
   original piece of ASCII-art may degrade in quality if it is
   captured in JPEG form.

   The source-quality could also represent a level of quality caused
   by skill of language translation, or ability of the used media type
   to capture the intended artistic expression.

   It is important that content providers do not assign very low
   source quality values without good reason, as this would limit the
   ability of users to influence the negotiation process with their
   own preference settings.  The following table SHOULD be used as a
   guide when assigning source quality values:

       1.000  perfect representation
       0.900  threshold of noticeable loss of quality
       0.800  noticeable, but acceptable quality reduction
       0.500  barely acceptable quality
       0.300  severely degraded quality
       0.000  completely degraded quality

   Note that most meaningful values in this table are close to 1.
   This is due to the fact that quality factors are generally combined
   by multiplying them, not by adding them.

   When assigning source-quality values, content providers MUST NOT
   account for the size of the variant and its impact on transmission
   and rendering delays.  Any constant rendering delay for a
   particular media type (for example due to the startup time of a
   helper application) SHOULD be accounted for by the user agent, when
   assigning a quality factor to that media type.


2.4 Type, charset, language, and length

   The type attribute of a variant description carries the same
   information as its Content-Type response header counterpart defined
   in [1], except for any charset information, which MUST be carried
   in the charset attribute.  For, example, the header

      Content-Type: text/html; charset=ISO-8859-4

   has the counterpart attributes

     {type text/html} {charset ISO-8859-4}

   The language and length attributes carry the same information as
   their Content-* response header counterparts in [1].  The length
   attribute, if present, MUST thus reflect the length of the variant
   alone, and not the total size of the variant and any objects
   inlined or embedded by the variant.

   Though all of these attributes are optional, it is often desirable
   to include as many attributes as possible, as this will increase
   the quality of the negotiation process.

      Note: A server is not required to maintain a one-to-one
      correspondence between the attributes in the variant description
      and the Content-* headers in the variant response.  For example,
      if the variant description contains a language attribute, the
      response does not necessarily have to contain a Content-Language
      header. If a Content-Language header is present, it does not
      have to contain an exact copy of the information in the language
      attribute.


2.5 Extension-attribute

   The extension-attribute allows future specifications to
   incrementally define dimensions of negotiation which cannot be
   created by using the feature negotiation framework, and eases
   content negotiation experiments.  In experimental situations,
   servers MUST ONLY generate extension-attributes whose names start
   with "x-".  User agents SHOULD ignore all extension attributes they
   do not recognize.  Proxies SHOULD NOT do any negotiation processing
   for a response if an extension attribute unknown to them is present
   in the variant list.  They SHOULD forward the response unchanged
   towards the user agent instead.

   The extension names "features" and "description" are reserved by
   this specification for use in experiments with `transparent content
   negotiation'.


---snip---

Received on Tuesday, 2 September 1997 11:31:09 UTC