Rewrite of feature tag syntax rules

In response to discussions on and off this list, I have done an
interim rewrite of the TCN feature tag syntax sections.  The new text
prepares for an `optional quotes' rule, and changes the equality test
rules.

It also extends the scope of feature tags, and makes some comments on
how to define tags.

I don't expect this to be the last version.  Comments are welcome.

Koen.

--snip--


6.1 Feature tags

   A feature tag (ftag) identifies something which can be negotiated
   on, for example a property of a representation, a capability of a
   user agent, or a preference of a user.  The use of feature tags
   need not be limited to transparent content negotiation, and not
   every feature tag needs to be usable in the HTTP transparent
   content negotiation framework.

   Examples of feature tags are

        http://x.org/tables, mid:33829%7e432, tables, ftag:fonts,
        screenwidth, colordepth

   At the protocol level, transparent content negotiation does not
   distinguish between different uses of feature tags: a tag will be
   processed in the same way, no matter whether it identifies a
   property, capability, or preference.  Note that context may
   determine the exact way in which a tag is used.  A "textonly" tag
   would identify a capability in a text-only user agent, but the user
   of a graphical user agent may use this tag to when specifying that
   text-only content is preferred over graphical content.  While the
   usage of some tags may be fluid, it is expected that other tag
   definitions will strictly limit the usage of a tag to expressing a
   property, capability, or preference only.  The protocol does
   however not contain any facilities which could enforce such
   limitations.  Feature tag definitions SHOULD describe the tag from
   the viewpoint of a variant author.  For example, a definition could
   start with `the X tag labels variants which are intended for...'.

   Feature tags are all in the URI namespace.

       ftag = <absoluteURI, as defined in [1], not containing
               any characters in ftag-reserved>
            | abbrev-ftag-scheme-URI

       short-ftag-scheme-URI = 
              <*( uchar | reserved ), as defined in [1], 
               not containing any characters in ftag-reserved, 
               and not containing any ":">

       ftag-reserved = "#" | "=" | "@"

   A short-ftag-scheme-URI "U" is equivalent to the absoluteURI
   "ftag:U".  Equality comparison for feature tags MUST be done by
   first extending any short-ftag-scheme-URI to an absolute URI by
   prefixing it with "ftag:", and then doing a case-insensitive
   octet-by-octet equality comparison.  Any ""%" HEX HEX" encodings
   in the tag MUST NOT be processed.

     [##Note: The `ftag:' scheme would belong to an IANA-maintained
     namespace, as in the feature tag registration draft
     (draft-ietf-http-feature-reg-00.txt).  More discussion about the
     issue of having an IANA-managed space of shorter-than-http-url
     feature tags is needed.##]

     [##Note: TCN feature tags and PEP extension identifiers share the
     same namespace.  We may want to synchronize terminology.##]

   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 frames}}


6.1.1 Feature tag values

   The definition of a feature tag may state that a feature tag can
   have zero, one, or more values associated with it.  These values
   specialise the meaning of the tag.

       ftag-val = <*( uchar | reserved ), as defined in [1], 
                  not containing any characters in ftag-reserved>

   For example, a feature tag "x:paper" could at some point have the
   values "A4" and "A5" associated with it.  This is commonly written
   as "paper=A4" and "paper=A5".  Equality comparison for tag values
   MUST be done with a case-sensitive, octet-by-octet comparison,
   where any ""%" HEX HEX" encodings MUST be processed.

Received on Wednesday, 14 May 1997 11:14:44 UTC