3.5 Determining the result

   The best variant, as determined by the remote variant selection
   algorithm, is the one variant with the highest overall quality value,
   or, if there are multiple variants which share the highest overall
   quality, the first variant in the list with this value.

   The end result of the remote variant selection algorithm is
   Choice_response if all of the following conditions are met

      a. the overall quality value of the best variant is greater
         than 0

      b. the overall quality value of the best variant is a definite
         quality value

      c. the variant resource is a neighbor of the negotiable
         resource.  This last condition exists to ensure that a
         security-related restriction on the generation of choice
         responses is met, see sections 10.2 and 14.2 of [2].

   In all other cases, the end result is List_response.

   The requirement for definiteness above affects the interpretation of
   Accept- headers in a dramatic way.  For example, it causes the remote
   algorithm to interpret the header

     Accept: image/gif;q=0.9, */*;q=1.0

   as

     `I accept image/gif with a quality of 0.9, and assign quality




 
RFC 2296                     HTTP RVSA/1.0                    March 1998


     factors up to 1.0 to other media types.  If this information is
     insufficient to make a choice on my behalf, do not make a choice
     but send the list of variants'.

   Without the requirement, the interpretation would have been

     `I accept image/gif with a quality of 0.9, and all other media
     types with a quality of 1.0'.

4  Use of the algorithm

   This section discusses how user agents can use the remote algorithm
   in an optimal way.  This section is not normative, it is included for
   informational purposes only.

4.1 Using quality factors to rank preferences

   Using quality factors, a user agent can not only rank the elements
   within a particular Accept- header, it can also express precedence
   relations between the different Accept- headers.  Consider for
   example the following variant list:

     {"paper.english" 1.0 {language en} {charset ISO-8859-1}},
     {"paper.greek"   1.0 {language el} {charset ISO-8859-7}}

   and suppose that the user prefers "el" over "en", while the user
   agent can render "ISO-8859-1" with a higher quality than "ISO-8859-
   7".  If the Accept- headers are

     Accept-Language: gr, en;q=0.8
     Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, *

   then the remote variant selection algorithm would choose the English
   variant, because this variant has the least overall quality
   degradation.  But if the Accept- headers are

     Accept-Language: gr, en;q=0.8
     Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, *

   then the algorithm would choose the Greek variant.  In general, the
   Accept- header with the biggest spread between its quality factors
   gets the highest precedence.  If a user agent allows the user to set
   the quality factors for some headers, while other factors are hard-
   coded, it should use a low spread on the hard-coded factors and a
   high spread on the user-supplied factors, so that the user settings
   take precedence over the built-in settings.






 
RFC 2296                     HTTP RVSA/1.0                    March 1998


4.2 Construction of short requests

   In a request on a transparently negotiated resource, a user agent
   need not send a very long Accept- header, which lists all of its