New feature negotiation syntax

In Memphis and at WWW6, a number of us talked about synchronising the
negotiation metadata models for PEP, transparent content negotiation,
and possibly user-agent side rendering scripts.

What came out was that transparent content negotiation would place its
feature tags in the URI namespace, like PEP does for its extension
identifiers.  

Basically, there would be only a single database of supported
feature/extension identifiers inside the browser.  Support for the PEP
extension http://whatever.com/blah would equal presence of the TCN
feature tag http://whatever.com/blah, and vice versa.  This eases
metadata aministration, and gives people the choice to use either
negotiation scheme for those things for which either would be usable. 

Note that, in my opinion, the overlap area in which both TCN and PEP
are usable is not very big.  It is certainly not so big that one could
easily unify the protocols.

I include the revised feature negotiation sections for the upcoming
draft-ietf-http-negotiation-02.txt, with changebars, below.  Comments
are welcome.

Koen.

---snip--
6  Feature negotiation

   This section defines the feature negotiation mechanism.  Feature
   negotiation has been introduced in section 4.8.  Appendix 18
   contains examples of feature negotiation.


6.1 Feature tags

   A feature tag (ftag) identifies a capability of a user agent or a
   preference of a user.  A feature is said to be `present' in a user
   agent if the corresponding capability is implemented, or if the
   user has expressed corresponding preference.

|      ftag = <absolute URI, as defined in [1], not containing any "#">
|
|  Examples of feature tags are
|
|       http://x.org/tables, mid:33829%7e432, x:tables, x:fonts,
|       x:screenwidth, x:colordepth
|
|    [##Note: TCN feature tags and PEP extension identifiers share the
|    same namespace.  We may want to synchronize terminology.##]
|
|    [##Note: The `x:' scheme in the examples could belong to an
|    IANA-maintained namespace, as in the feature tag registration
|    draft (draft-ietf-http-feature-reg-00.txt).  `x:' stands for
|    `extension', and was mainly chosen because of editorial
|    considerations (it is short, so it does not lead to much
|    reformatting of examples).  More discussion about the issue of
|    having an IANA-managed space of shorter-than-http-url feature
|    tags is needed.##]
|
|    [##Note: We may want to specify a default scheme, so that
|    "screenwidth" is the same as "x:screenwidth".##]

   An example of the use of feature tags in a variant description is:

     {"index.html" 1.0 {type text/html} 
|        {features "http://x.org/tables" "x:frames"}}
|
|  Equality comparison for feature tags MUST be done with the URI
|  comparison rules in [1].  Note that this comparison is largely
|  case-sensitive.  Because of this, the use of uppercase characters
|  in feature tags is discouraged.
|
|    [##Issue: does [1] actually define comparison of non-http URIs
|    and URIs with unknown schemes in an unambiguous way?##]

   Note that context may determine whether a feature tag expresses a
|  capability or a preference.  An "x:textonly" tag would be naturally
   present for a text-only user agent, but the user of a graphical
   user agent could set the tag to be present if text-only content is
   preferred to graphical content.

|  As feature creation will be an ongoing process, it is generally not
   possible for a user agent to know the meaning of all feature tags
   it can possibly encounter in a variant description.  A user agent
   SHOULD treat all features with tags unknown to it as absent.

|6.1.1 Feature tag values
|
|  The definition of a feature tag may state that a feature tag, if
|  present, can have associated with it one or more values which
|  reflect a particular capability or preference.  Such values have
|  the syntax of URI fragment identifiers as defined in [1]:
|
|      ftag-val = fragment
|
|  For example, a feature tag "x:paper" could be present with the
|  values "A4" and "A5".  This is commonly written as "x:paper#A4" and
|  "x:paper#A5".  Equality comparison for tag values MUST be done with
|  the URI comparison rules in [1] as they apply to fragment
|  identifiers.


6.2 Accept-Features header

   The Accept-Features request header can be used by a client to give
   information about the presence or absence of certain features.

       Accept-Features = "Accept-Features" ":"
                   #( feature-expr *( ";" feature-extension ) )

|      feature-expr = [ "!" ] <"> ftag <">
|                   | [ "!" ] <"> ftag "#" ftag-val <">
|                   |   "1"   <"> ftag "#" ftag-val <">
|                   | <"> ftag "#" number "#" [ number | "inf" ] <">
|                   | "*"

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

|  No feature extensions are defined in this specification.  An
   example is:

|      Accept-Features: "x:blex", !"x:blebber", "x:colordepth#0#5",
|                 !"x:screenwidth", 1"x:ua-media#stationary", 
|                 "x:paper#A4", ! "paper#A0", "x:x_version#100#205", 
|                 "x:screenwidth#5000#inf", *

   The different feature expressions have the following meaning:

|     "ftag"     ftag is present
|
|     !"ftag"    ftag is absent
|
|     "ftag#V"   ftag is present with the value V (it may also be
                 present with other values)

|     !"ftag#V"  ftag is present, but not with the value V
|
|     1"ftag#V"  ftag is present with the value V, and not with any
                 other values

|     "ftag#N#M" ftag is present with the numeric values from N up to
|                and including M, and not with any other values.  The
|                special value "inf" for M stands for positive
                 infinity.

      *          makes true all feature predicates (section 6.3) which
                 were not assigned truth values by other elements of
                 the header

   Absence of the Accept-Features header in a request is equivalent to
   the inclusion of

       Accept-Features: *


6.3 Feature predicates

   Feature predicates are used in the features attribute of a variant
   description.

|     fpred = [ "!" ] <"> ftag <">
|           | [ "!" ] <"> ftag "#" ftag-val <">
|           | <"> ftag "#" number "#" number <">

   Examples of feature predicates are

|     "x:blebber", !"x:blebber", "x:paper#A4", "x:paper#%414"
|     "x:colordepth#5", !"x:blex#54", "x:dpi#300#599"

   A server can compute the truth value of a feature predicate by
   using the knowledge gained from the Accept-Features header in the
   current request.  The truth value MUST be assigned as follows,
   depending on the form of the predicate:

|     "ftag"     true if the feature is known to be present

                 false if the feature is known to be absent

|     !"ftag"    true if the feature is known to be absent

                 false if the feature is known to be present

|     "ftag#V"   true if the feature is known to be present with
                 the value V,

                 false if the feature is known not to be present with
                 the value V

|     !"ftag#V"  true if the feature is known to be present, but known
                 not to be present with the value V,

                 false if the feature is known to be absent or present
                 with the value V

|     "ftag#N#M" true if the feature is known to be present with some
                 numeric values, while the highest value with which it
                 is present is known and in the range N-M,

                 false if the feature is known to be absent, or if it
                 is known to be present with some numeric values,
                 while the highest value with which it is present is
                 known and not in the range N-M.

|                The special value "inf" for M stands for positive
                 infinity.

   If the information in the Accept-Features header does not provide
   sufficient knowledge to assign a value to a predicate using the
   above rules, then the value is true if there is a "*" in the
   Accept-Features header, false otherwise.

   As an example, the header

|      Accept-Features: "x:blex", !"x:blebber", "x:colordepth#0#5",
|                 !"x:screenwidth", 1"x:ua-media#stationary", 
|                 "x:paper#A4", ! "paper#A0", "x:x_version#100#205", *

   makes the following predicates true:

|      "x:blex", "x:colordepth#4", !"x:colordepth#6", "x:colordepth",
|      ! "x:screenwidth", "x:ua-media#stationary",
|      !"x:ua-media#screen", "x:paper#A4", "x:paper#%414",
|      !"x:paper#A0", "x:colordepth#4#6", "x:x_version#101"

   The * in the header makes all of the following predicates true:

|      "x:blex#wox", !"x:blex#wox", "x:paper#A5", "x:frtnbf",
|      !"x:frtnbf", "x:frtnbf#4", !"x:frtnbf#4", "x:frtnbf#1#42#"

   The header makes the following predicates false:

|      !"x:blex", "x:blebber", "x:colordepth#6", "x:colordepth#foo",
|      !"x:colordepth", "x:screenwidth", "x:screenwidth#640",
|      !"x:screenwidth#640", "x:x_version#99", "x:ua-media#screen",
|      "x:paper#A0"

Received on Tuesday, 6 May 1997 12:32:11 UTC