RFC 2295            Transparent Content Negotiation           March 1998


       round5 ( qs  * qt  * qc  * ql  * qf  * qa ) = Q
                ---   ---   ---   ---   ---   ---
      paper.1:  0.9 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0  = 0.90000
      paper.1:  0.7 * 1.0 * 1.0 * 0.5 * 1.0 * 1.0  = 0.35000
      paper.3:  1.0 * 0.8 * 1.0 * 1.0 * 1.0 * 1.0  = 0.80000

19.2 Determining the result

   Using all computed overall quality values, the end result of the
   local variant selection algorithm is determined as follows.

   If all overall quality values are 0, then the best variant is the
   fallback variant, if there is one in the list, else the result is the
   conclusion that none of the variants are acceptable.

   If at least one overall quality value is greater than 0, then the
   best variant is the variant which has the description with the
   highest overall quality value, or, if there are multiple variant
   descriptions which share the highest overall quality value, the
   variant of the first variant description in the list which has this
   highest overall quality value.

19.3 Ranking dimensions

   Consider the following variant list:

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

   It could be the case that the user prefers the language "el" over
   "en", while the user agent can render "ISO-8859-1" better than "ISO-
   8859-7".  The result is that in the language dimension, the first
   variant is best, while the second variant is best in the charset
   dimension.  In this situation, it would be preferable to choose the
   first variant as the best variant: the user settings in the language
   dimension should take precedence over the hard-coded values in the
   charset dimension.

   To express this ranking between dimensions, the user agent
   configuration database should have a higher spread in the quality
   values for the language dimension than for the charset dimension.
   For example, with

     languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ...

     charsets:  ISO-8859-1;q=1.0, ISO-8859-7;q=0.95,
                ISO-8859-5;q=0.97, unicode-1-1;q=0, ...





 
RFC 2295            Transparent Content Negotiation           March 1998


   the first variant will have an overall quality of 0.95000, while the
   second variant will have an overall quality 0.70000.  This makes the
   first variant the best variant.

20 Appendix: feature negotiation examples

   This appendix contains examples of the use of feature tags in variant
   descriptions.  The tag names used here are examples only, they do not
   in general reflect the tag naming scheme proposed in [4].

20.1 Use of feature tags

   Feature tags can be used in variant lists to express the quality
   degradation associated with the presence or absence of certain
   features.  One example is

     {"index.html.plain" 0.7 },
     {"index.html"       1.0 {features tables frames}}

   Here, the "{features tables frames}" part expresses that index.html
   uses the features tagged as tables and frames.  If these features are
   absent, the overall quality of index.html degrades to 0.  Another
   example is

     {"home.graphics" 1.0 {features !textonly}},
     {"home.textonly" 0.7 }

   where the "{features !textonly}" part expresses that home.graphics
   requires the absence of the textonly feature.  If the feature is
   present, the overall quality of home.graphics degrades to 0.

   The absence of a feature need not always degrade the overall quality
   to 0.  In the example

     {"x.html.1" 1.0 {features fonts;-0.7}}

   the absence of the fonts feature degrades the quality with a factor
   of 0.7.  Finally, in the example

      {"y.html" 1.0 {features [blebber wolx] }}