The "[blebber wolx]" expresses that y.html requires the presence of
   the blebber feature or the wolx feature.  This construct can be used
   in a number of cases:

     1. blebber and wolx actually tag the same feature, but they were
        registered by different people, and some user agents say they
        support blebber while others say they support wolx.




 
RFC 2295            Transparent Content Negotiation           March 1998


     2. blebber and wolx are HTML tags of different vendors which
        implement the same functionality, and which are used together in
        y.html without interference.

     3. blebber and wolx are HTML tags of different vendors which
        implement the same functionality, and y.html uses the tags in a
        conditional HTML construct.

     4. blebber is a complicated HTML tag with only a sketchy
        definition, implemented by one user agent vendor, and wolx
        indicates implementation of a well-defined subset of the blebber
        tag by some other vendor(s).  y.html uses only this well-defined
        subset.

20.2 Use of numeric feature tags

   As an example of negotiation in a numeric area, the following variant
   list describes four variants with title graphics designed for
   increasing screen widths:

     {"home.pda"    1.0 {features screenwidth=[-199] }},
     {"home.narrow" 1.0 {features screenwidth=[200-599] }},
     {"home.normal" 1.0 {features screenwidth=[600-999] }},
     {"home.wide"   1.0 {features screenwidth=[1000-] }},
     {"home.normal"}

   The last element of the list specifies a safe default for user agents
   which do not implement screen width negotiation.  Such user agents
   will reject the first four variants as unusable, as they seem to rely
   on a feature which they do not understand.

20.3 Feature tag design

   When designing a new feature tag, it is important to take into
   account that existing user agents, which do not recognize the new tag
   will treat the feature as absent.  In general, a new feature tag
   needs to be designed in such a way that absence of the tag is the
   default case which reflects current practice.  If this design
   principle is ignored, the resulting feature tag will generally be
   unusable.

   As an example, one could try to support negotiation between
   monochrome and color content by introducing a `color' feature tag,
   the presence of which would indicate the capability to display color
   graphics.  However, if this new tag is used in a variant list, for
   example

      {"rainbow.gif"      1.0 {features color} }




 
RFC 2295            Transparent Content Negotiation           March 1998


      {"rainbow.mono.gif" 0.6 {features !color}}

   then existing user agents, which would not recognize the color tag,
   would all display the monochrome rainbow.  The color tag is therefore
   unusable in situations where optimal results for existing user agents
   are desired.  To provide for negotiation in this area, one must
   introduce a `monochrome' feature tag; its presence indicates that the
   user agent can only render (or the user prefers to view) monochrome
   graphics.

21 Appendix: origin server implementation considerations

21.1 Implementation with a CGI script

   Transparent content negotiation has been designed to allow a broad
   range of implementation options at the origin server side.  A very
   minimal implementation can be done using the CGI interface.  The CGI
   script below is an example.

      #!/bin/sh

      cat - <<'blex'
      TCN: list
      Alternates: {"stats.tables.html" 1.0 {type text/html} {features
      tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95
      {type application/postscript}}
      Vary: *
      Content-Type: text/html