Feature tag registration

 Background and design considerations for feature tag registration
 =================================================================

INTRODUCTION

 This document discusses considerations related to feature tag
 registration.  It intends to initiate a discussion of feature tag
 registration on the http-wg list, so all comments and additions are
 welcome.  Though partially based on remarks from other people, this
 document mainly represents my own limited understanding of the
 issues.

 The two big questions related to feature tag registration are:

    1. How open should the registration process be?

    2. How should the feature tag namespace be structured?

 These questions will have to be answered to some extent before we can
 write a feature tag registration internet draft.


1 Purpose of feature negotiation

 The feature negotiation mechanism in the transparent content
 negotiation draft means to provide a better alternative to content
 negotiation based on the user-agent field.  User-agent negotiation
 has many disadvantages: it is cache-unfriendly, huge amounts of time
 are needed to keep up with new user agent releases, etc.

 An advantage of using user-agent based negotiation is that it can be
 used immediately after a user agent with a new feature is released,
 without waiting for any standardization action by the IETF.  This
 advantage will have to be retained in feature negotiation.  If the
 content creation community can't use feature negotiation to negotiate
 on the new hot feature of the week, feature negotiation will not meet
 its design goal.

 Therefore, feature registration needs to be a very fast process.

 It must be possible to register feature tags in parallel with the
 release of a new browser alpha version.  Maybe there even needs to
 be a mechanism by which browser vendors could reserve some tags for
 the next alpha version without having to make public the tag spec
 yet.

 Parties who would want to register feature tags are:

   - browser vendors, when inventing new features

   - browser component vendors, when creating new browser components

   - the IETF or some other standards body, when creating a new
     standard for a content format

   - content authors who want to label their variants in a new way
     (this presupposes that users can configure their browsers to make
     present new feature tags to indicate a particular preference).


2 The IANA

 With the MIME registration procedures being updated, there has been
 some confusion over what IANA will register.  John Postel recently
 told us that:

   The IANA is pretty good at keeping lists.  It is not so good at
   evaluating the merits (or lack thereof) of the requests to add
   things to lists.   [...] 
   So, yes the IANA would keep the list of "feature tags" provided
   that that there is either a very simple way to decide if requests
   pass muster, or a designated someone else will be available to make
   that decision.

 So from an IANA standpoint, this WG must either

    a) create a feature tag review board, or

    b) define very basic registration rules which do not take the
       merit of the feature tag into account.  To quote
       draft-ietf-822ext-mime-reg-04, this type of registration "does
       not imply endorsement, approval, or recommendation by IANA or
       IETF or even certification that the specification is adequate."

 In Sections 3-4 below, we will see that we can't meet the design
 goals of feature negotiation if we go for a).  Going for b) implies
 that even feature tags without merit will be registered.  Sections 5
 and 7 explore the implications of this.


3 Lack of manpower needed to review all features

 If feature negotiation is to replace user-agent negotiation, it must
 keep up with the development of new browser features in the
 marketplace.  As the marketplace is moving fast, significant manpower
 would be needed to review new tags quickly.  The IETF does not have
 this kind of manpower available.


4 Market driven innovation does not wait for the IETF

 The development of new web features is currently driven by
 marketplace competition.  As history of the HTML 3.0 effort has
 shown, the market will not wait for IETF consensus.

 I feel that it would be a mistake for the IETF to attempt to control
 the introduction of new features by controlling the feature tag
 namespace.  The IETF cannot block the creation of a chaotic
 collection of features by the marketplace.  It _does_ have the power
 to block the creation of a matching chaotic collection of feature
 _tags_, but there is little sense in doing this.


5 Filtering before registration vs. filtering after registration 

 The considerations above lead to a fast feature registration process
 with extremely minimal requirements.   This inevitably leads to a
 feature tag namespace space which contains a lot of 

     a) tags without merit
     b) tags indicating features without merit
     c) tags indicating features which had great potential, but
        which never gained widespread use

 Compare this to the situation in the USENET newsgroup namespace.

 A list of _all_ registered feature tags will generally be too long to
 be useful to any content author.  Third parties could filter the
 feature tag namespace and compile short lists of useful tags.  Web
 indexing robots could, while traversing the web, gather statistics
 about actual use of feature tags; these statistics could help in
 compiling lists.

 Note that this filtering after registration basically follows the
 HTML 3.2 model of creating order _after_ the marketplace battles have
 died down.


6 Feature tag registration timeline

 To summarize the above, this is a timeline for the registration of a
 feature tag which ends up being generally used.

  Time    Action 
 (months)

  t+0    Browser vendor A invents the new feature XY.

  t+1    Vendor A starts implementing XY, and writes a
         feature tag registration form for the `xy' tag.

  t+2    Vendor A submits form and registers the `xy' feature tag.

  t+2    Vendor A releases a new browser version, which
          a) implements the feature XY
          b) has the `xy' tag present when doing feature negotiation.

  t+2.5  `Early adopter' content authors start making variants 
         which use XY.

  t+3    Vendor B starts implementing XY in their own browser.

  t+3    The `xy' tag appears in lists of useful tags maintained by
         third parties.

  t+3.5  Vendor B releases new browser version, which
          a) implements the feature XY
          b) has the `xy' tag present when doing feature negotiation.

  t+3.5  Many content authors start making variants which use XY.

  t+4    Vendor C starts implementing XY, and invents the extension
         XY_COLOR.

  t+4.5  Vendor C registers the `xy_color' feature tag.

  t+4.5  Vendor C releases new browser version, which
          a) implements the features XY and XY_COLOR
          b) has the `xy' and `xy_color' tags present when doing
             feature negotiation.

  t+10   90% of all deployed browsers support XY, content authors
         start using XY it without bothering to provide an alternate
         representation.


7 Potential problems of an open registration process

 Several potential problems connected to having an open registration
 process have been identified.  These are covered in the subsections
 below.


7.1 Excessive registration, trademark fights

 One danger is excessive registration like we have seen in the
 internet domain namespace.

 I think that the various forces which contributed to the domain name
 registration problems are absent for feature tags: feature tags will
 not be very visible to end users, and registration of a feature tag
 does not mean you get exclusive use.

 Therefore, I do not expect that we will see excessive registration as
 with domain names.  Of course, it is always possible to change the
 registration procedure if excessive registration _does_ occur.  A
 part of the namespace could be reserved for use in a `plan B'.

 As a-priori safeguards, IANA could be allowed to reject registrations
 which are `obviously bogus', and be allowed to reject or delay the
 registration of `large collections of tags with questionable value'.
 Such decisions could be appealed to the IESG.

 Note however that the danger of excessive registration is also
 present in the vendor and personal spaces of
 draft-ietf-822ext-mime-reg-04.txt, and that
 draft-ietf-822ext-mime-reg-04.txt does not specify such safeguards.

7.1.1 More closed registration procedures

 Of course, it is possible to invent more closed registration
 procedures,  which could limit excessive registration.

 To meet the design goals of feature negotiation, these closed
 procedures would however have to grant browser and browser component
 vendors the right to register feature tags quickly and without
 review, on release of the first alpha version which implements the
 feature.  Registration by people who are not browser vendors could be
 subject to higher barriers.

 Such closed procedures which grant special rights to some parties are
 however politically unattractive.  Also, there is the problem of
 identifying the actual browser and browser component vendors.  And
 with browsers increasingly becoming open systems with pluggable
 components, everybody with a C compiler would have some claim to
 being a browser component vendor.

7.1.2 Separate registration spaces

 Another way to deal with the `noise' of possible excessive
 registration would be to have multiple registration spaces, for
 example
    1 one for tags defined by IETF standards track documents
    2 one in which browser (component) vendors may register tags
      for new features
    3 one for all other tags which are meant for general use
    4 one for tags which are meant for limited use

 This way, `channel 1 and 2' are kept relatively noise-free.

 A problem with space 2 above is that IANA does not have the resources
 to verify if the checkbox `[X] I intend to add this feature to the
 next release of my browser/browser component' is telling the truth.
 Tags could however be stamped `obsolete' if it is brought to the
 attention of IANA that the promised implementation has not appeared
 after N months.


7.2 Intentional misregistration

 Vendor X could try to pre-emptively block the development of a
 `walking gifs' feature by other vendors by registering a
 `walking_gifs' feature tag which indicates, for example, a preference
 for paragraphs separated by horizontal line .gifs in which little
 smurfs can be seen walking on the line.

 However, I feel that the English language is flexible enough to allow
 the invention of alternative tags to label the real `walking gifs'
 feature, if ever developed.

 Also, the registration rules could allow IANA to reject registration
 `if the tag name is clearly bogus or misleading'.  The rejection
 would have to include a suggestion for a tag name which _would_ be
 acceptable.


8 Partitioning the feature tag namespace

 It has been suggested that a partitioning of the feature tag
 namespace (for example through the definition of a standard prefix
 naming scheme) could help to keep feature negotiation more manageable.
 The partitioning could be based on several criteria, or combinations
 thereof:

     a) who registered the tag ( ietf / vendor / other )

     b) the intended scope ( global / local / personal / experimental )

     c) the area of negotiation:
             - capability / preference
             - related to HTML / not related to HTML
             - specific to one MIME type / not MIME type specific
             - for static content / for dynamic content
             - etc.

 The options for partitioning have not been explored yet, much work
 still needs to be done in this area.  It is not clear whether
 partitioning will actually help to make feature negotiation more
 manageable.  Risks connected to partitioning are

   - that the registration of otherwise useful feature tags could be
     blocked because they do not fit in any predefined category

   - that searching for tags which do not clearly fit into one category
     could be difficult

 The first risk could be eliminated by having a `miscellaneous'
 category.

Received on Tuesday, 8 October 1996 12:50:02 UTC