W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Feature tag registration

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 21 Aug 1996 12:48:51 +0200 (MET DST)
Message-Id: <199608211048.MAA08816@wsooti04.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1437

The current content negotiation draft does not completely specify the
feature tag registration process, because when I wrote it, I did not
know what needed to be in such a specification.  Reading RFC 1602 (The
Internet Standards Process -- Revision 2) and RFC 1341 (MIME
(Multipurpose Internet Mail Extensions)) as an example, I gather that
such a specification can consist of

 1) a discussion of the purpose of feature tags in the content
    negotiation draft
 2) a form to register feature tags

Quoting from RFC 1602:

      Many protocol specifications include numbers, keywords, and other
      parameters that must be uniquely assigned.  Examples include
      version numbers, protocol numbers, port numbers, and MIB numbers.
      The IAB has delegated to the Internet Assigned Numbers Authority
      (IANA) the task of assigning such protocol parameters for the
      The IANA is expected to avoid frivolous assignments and to
      distinguish different assignments uniquely.  The IANA accomplishes
      both goals by requiring a technical description of each protocol
      or service to which a value is to be assigned.  Judgment on the
      adequacy of the description resides with the IANA.  In the case of
      a standards track or Experimental protocol, the corresponding
      technical specifications provide the required documentation for

If I understand the above correctly, this WG will not have to specify
any rules to distinguish `frivolous assignments' from real
assignments, IANA will infer these rules from the conneg spec.
Feature tag registration is intended as a very open process, and this
has some disadvantages, but it seems that IANA will act as a filter to
stop weirdness like we have seen in the domain name registration rush
of the last 2 years.

Based on my current understanding of how IANA works, I propose to
change the start of Section 8 of the current draft to the following


8  Feature tag registration

   Feature tags are registered with IANA using the form in Appendix
   [TBA].  Feature negotiation intends to allow for the registration
   of a feature tag before an area of negotiation is standardized or
   even well-understood.  A requirement for registration is that the
   tag name follows the syntax rules, and that a definition of the
   meaning of the tag is supplied.  Registration will not require
   actual implementation of a feature, and there will be no test on
   whether the feature definition overlaps (partially) with another
   feature definition.


I don't see a great need to put some kind of `how to name your
feature' guidelines in the draft.  The collection of feature names in
a `core feature set' can act as a style guide.

Getting the nature of the registration process right is crucial to the
success of feature negotiation.

The MIME type system has failed to deliver the kind of fine-grained
information we need for the web not just because of technical
limitations, but also because the MIME type registration process was
designed to resist expressing such fine-grained information as a MIME
type parameters.

The form below is at least as important as the technical details of
feature negotiation.  Many people who register feature tags will only
read the form below, they will not read the conneg spec itself.

Making a good form is an exercise in applied psychology more than
anything else.  For example, the use of BNF instead of plain English
in the syntax instructions means to get the user into a
technical/scientific mindset rather than a marketing-speak or `the
bright idea I had this morning' mindset.  As a non-native speaker, I
am not particularly qualified to play such language games, so please
look very carefully at the form and mail any improvements you can
think of.

Note that in the end, this form will probably have a web-version and
an e-mail version.  Imagine <input> and <textarea> elements below.


Appendix [TBA]:


 | Instructions are preceded by `|'.

Feature tag name:

 | The name is case-insensitive, may not start with "x-", and must fit
 | the ftag syntax rules:
 |     ftag = 1*<any CHAR except CTLs or tspecials or "!">
 |     tspecials      = "(" | ")" | "<" | ">" | "@"
 |                    | "," | ";" | ":" | "\" | <">
 |                    | "/" | "[" | "]" | "?" | "="
 |                    | "{" | "}" | SP | HT
 | Example: html_5dtables


 | Supply one or two sentences.
 | Example: The html 5 dimensional tables tag indicates the capability
 | to render 5 dimensional tables in text/html documents.


 | Optional.

Intends to label: [ ] a capability
                  [ ] a preference
                  [ ] a capability or preference

 | Check one.

Intends to be used as: [ ] tag without a value
                       [ ] tag with a single numeric value
                       [ ] tag with a single value 
                       [ ] tag with one or more values

 | Check one or many.

Presence of the tag indicates:

Tag value (if any) indicates:

Predefined tag values (if any):                              

 | Tag values must fit the HTML/1.1 syntax rule for tokens:
 |     token = 1*<any CHAR except CTLs or tspecials>

Absence (default case) of the tag indicates:                

 | Optional.

Intended typical use:

 | Optional.
 | Supply examples of Accept-Features headers, variant
 | descriptions, and/or variant lists.  Add comments if
 | necessary.

Detailed description of indicated capability or preference:  [optional]

 | If more than 100 lines are needed, a reference to a related
 | standard or document is preferred.

Related standards or documents:

 | Optional.

Related media types (MIME types):

 | Optional.
 | For example text/html if the tag indicates the capability
 | to handle some HTML extension.

Related markup tags:

 | Optional.
 | For example <table>.  Note that the markup language does not
 | need to be text/html.  Add comments if necessary.

Related feature tags:

 | Optional.
 | Add comments if necessary.


 | Optional.

See also:

 | Optional.

Registered on:                          

 | Date will be supplied by IANA.

Person & email address to contact for further information:


Received on Wednesday, 21 August 1996 03:52:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:18 UTC