2004/id/draft-ietf-http-feature-reg-00.txt


HTTP Working Group                                     Koen Holtman, TUE
Internet-Draft                              Andrew Mutz, Hewlett-Packard
Expires: April 30, 1997                                 October 30, 1996


                    Feature Tag Registration Procedures

                     draft-ietf-http-feature-reg-00.txt


STATUS OF THIS MEMO

        This document is an Internet-Draft. Internet-Drafts are
        working documents of the Internet Engineering Task Force
        (IETF), its areas, and its working groups. Note that other
        groups may also distribute working documents as
        Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress".

        To learn the current status of any Internet-Draft, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za
        (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
        Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
        West Coast).

        Distribution of this document is unlimited.  Please send
        comments to the HTTP working group at
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> mailing list.

        This draft is part of a document set about transparent content
        negotiation in HTTP.  See
        <URL:http://gewis.win.tue.nl/~koen/conneg/> for related
        documents.


ABSTRACT

   The internet draft draft-holtman-http-negotiation-03.txt
   (Transparent Content Negotiation in HTTP) specifies a `feature
   negotiation' mechanism for negotiation on content characteristics
   other than MIME type, charset, and language.  Feature negotiation
   allows the quick introduction of new dimensions of negotiation
   through the registration of `feature tags'.  A feature tag
   identifies a capability of a user agent or a preference of a user.

   This document discusses considerations related to feature tag
   registration, and contains a proposed definition of a feature tag
   registration procedure.  Feature tag registration is foreseen as an
   ongoing, open process. It should keep pace with the introduction
   of new rendering features by web software vendors, and other
   parties such as standards bodies.


TABLE OF CONTENTS

    1 Introduction

    2 Background and design considerations
     2.1 Purpose of feature negotiation
     2.2 Parties who would want to register feature tags
     2.3 Feature tag registration timeline
     2.4 Volume considerations
     2.5 The IANA
     2.6 Potential problems of a review-less registration process
     2.6.1 Excessive registration, trademark fights
     2.6.2 Intentional misregistration
     2.7 Partitioning the feature tag name-space

    3 Feature tag registration
     3.1 Registration trees
     3.1.1 IETF tree
     3.1.2 Global tree
     3.1.3 Local or specialized tree
     3.1.4 Special `x.' tree
     3.1.5 Additional registration trees
     3.2 Registration requirements
     3.2.1 Functionality requirement
     3.2.2 Naming requirements
     3.2.3 Specification requirements
     3.2.4 Security requirements
     3.2.5 Publication requirements

     3.3 Registration procedure
     3.3.1 Present the feature tag to the community for review
     3.3.2 IESG approval
     3.3.3 IANA registration
     3.3.4 Delayed publication

     3.4 Comments on feature tag registrations
     3.5 Location of registered feature tag list
     3.6 IANA procedures for registering feature tags
     3.7 Change control
     3.8 Registration template
 
    4 Acknowledgments

    5 References

    6 Author's address

    Appendix A: Feature tag summaries

    Appendix B: IANA and RFC editor to-do list


1 Introduction

   The internet draft draft-holtman-http-negotiation-03.txt
   (Transparent Content Negotiation in HTTP) specifies a `feature
   negotiation' mechanism for negotiation on content characteristics
   other than MIME type, charset, and language.  Feature negotiation
   allows the quick introduction of new dimensions of negotiation
   through the registration of `feature tags'.  A feature tag
   identifies a capability of a user agent or a preference of a user.

   This document discusses considerations related to feature tag
   registration, and contains a proposed definition of a feature tag
   registration procedure.  Feature tag registration is foreseen as an
   ongoing, open process which will keep pace with the introduction
   of new rendering features by web software vendors, and other
   parties such as standards bodies.

   Section 2 discusses considerations related to feature tag
   registration.  Section 3 contains a proposed definition of a
   feature tag registration procedure.


2 Background and design considerations

   This section provides background material related to the design of
   the feature tag registration procedures.  It does not contain any
   normative material.  This section will be deleted or moved to an
   appendix in the final version of this document.

   See Section 4 of [2] for an overview of transparent content
   negotiation and feature negotiation.  Section 7 of [2] contains
   some examples of the use of feature tags.  Section 6 of [2] covers
   the technical aspects of feature negotiation mechanism.  This
   document supersedes Section 8 (Feature tag registration) of [2].

   For examples of registration procedures, see [3].


2.1 Purpose of feature negotiation

   The feature negotiation mechanism of transparent content
   negotiation [2] is intended to provide a better alternative to
   content negotiation based on the user-agent field.  User-agent
   negotiation has many disadvantages: it is cache-unfriendly,
   difficult to maintain, and significant time is required to keep up
   with new user agent releases.

   The main advantage of 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 actions.  This
   advantage should 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 succeed in supplanting user-agent based negotiation.

   Therefore the registration of tags related to browser or browser
   component features 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.


2.2 Parties who would want to register feature tags

   Feature negotiation allows the quick introduction of new dimensions
   of negotiation through the registration of `feature tags'.  The
   following parties might want to introduce new dimensions of
   negotiation:

     1. Browser and browser component vendors, when inventing and
        implementing new features or components.

     2. The IETF or some other standards body, when creating a new
        standard for a content format, or when identifying a new type
        of user preference (for example a preference for
        representations without animated gifs).

     3. Content authors, when identifying a new type of user
        preference and creating variants to match.

   Note that if (some) users can configure their browsers to identify
   new feature tags, the introduction of new preferences does
   not require the updating of browser software.

   A fast registration process is mainly needed for registration by
   group 1 and 3.  For 2, a slower process would suffice.  Thus, one
   could create separate registration subtrees for these groups, with
   no review for 1 and 3, and some review for 2.


2.3 Feature tag registration timeline

   This is a timeline for the registration of a feature tag which
   succeeds in 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 the form and the IANA registers the `xy'
           feature tag.

    t+2.1  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 a 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 a 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.


2.4 Volume considerations

   In order to be effective at replacing user-agent negotiation,
   feature tag registration which will have to keep pace with the
   introduction of new rendering features by web software vendors.

   As vendors are moving fast, this inevitably leads to a feature tag
   name-space which contains a lot of tags.  Also, a lot of tags
   will be `dead' tags, tags related to features which failed to take
   off and gain widespread use.  Compare this to the situation in the
   USENET newsgroup name-space.

   A list of _all_ registered feature tags will therefore generally be
   too long to be useful to any content author.  Third parties could
   filter the feature tag name-space 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.

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


2.5 The IANA

   With the MIME registration procedures being updated (see [3]),
   there has been some confusion over what the IANA will register.
   Jon 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 two types of registration name-spaces can be created:

      a) a space with feature tag review process performed by the IETF

      b) a space with very basic registration rules which do not take
         the merit of the feature tag into account.  To quote [3],
         this type of registration "does not imply endorsement,
         approval, or recommendation by the IANA or IETF or even
         certification that the specification is adequate."

   For features introduced by browser and browser component vendors, a
   space with a type b) registration process seems necessary, if only
   because the IETF does not have the manpower required for a review
   process which would meet the speed and volume requirements.


2.6 Potential problems of a review-less registration process

   Several potential problems connected to having a registration
   process without review have been identified.  These are covered in
   the subsections below.


2.6.1 Excessive registration, trademark fights

   One danger is excessive registration as seen in the internet domain
   name-space.

   We speculate 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 we do not expect excessive registration to occur.  Of
   course it is possible to update the registration procedure if
   excessive registration _does_ occur.  A necessary precaution is to
   reserve a part of the feature tag name-space for future use.

   As an a-priori safeguard, the 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 [3], and that [3] does
   not specify such safeguards.


2.6.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 refers to some bogus capability or
   preference.

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

   Also, the registration rules could allow the 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.

   In addition the registration process does mandate a description of 
   the feature in some detail.  


2.7 Partitioning the feature tag name-space

   A partitioning of the feature tag name-space (for example through
   the definition of a standard prefix naming scheme) can help to keep
   the tag registry 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 carefully explored yet,
   much work still needs to be done in this area.  In particular, it
   is not yet clear whether a useful partitioning based on c) can be
   found.


3 Feature tag registration

   [##Note: This section is a proposal only.  Much of the text in this
   section was taken from [3].  Though this section tentatively
   introduces a 4-way top level partitioning of the feature tag
   name-space, it does not discuss any sub-partitioning yet.##]

   Registration of a new feature tag starts with the construction of a
   registration proposal.  Registration may occur in several different
   registration trees, which have different requirements as discussed
   below.  The following sections describe the requirements and
   procedures used for each of the different registration trees.


3.1 Registration trees

   The following subsections define registration "trees",
   distinguished by the use of faceted names (e.g., names of the form
   "tree.feature_name").


3.1.1 IETF tree

   The IETF tree is intended for feature tags of general interest to
   the Internet Community.  Registration in the IETF tree requires
   approval by the IESG and publication of the feature tag
   specification as some form of RFC.

   Feature tags in the IETF tree normally have names that are not
   explicitly faceted, i.e., do not contain period (".", full stop)
   characters.

   The "owner" of a feature tag in the IETF tree is assumed to be the
   IETF itself.  Modification or alteration of the specification
   requires the same level of processing (e.g. standards track)
   required for the initial registration.


3.1.2 Global tree

   The global tree is intended for feature tags of general interest to
   the Internet Community.  Unlike registration in the IETF tree,
   registration in the global tree does not require approval by the
   IESG.  A registration may be placed in the global tree by anyone
   who has the need to allow for feature negotiation on a particular
   capability or preference.

   Typically, if a web browser vendor or browser component vendor
   introduces a new feature to the Internet Community, and if it is
   meaningful to do feature negotiation on it, the vendor can register
   a feature tag in the global tree.

   The owner of "global" tags and associated specifications is the
   person or entity making the registration, or one to whom
   responsibility has been transferred as described below.

   Tags in the global tree will be distinguished by the leading facet
   "g.".  While public exposure and review of feature tags to be
   registered in the global tree is not required, using the
   ietf-feature-tags list for review is strongly encouraged to improve
   the quality of those specifications.  Registrations in the global
   tree may be submitted directly to the IANA.

   [##Note: the name `global' for this tree is only a proposal. It
   could be called the World-wide tree to get a "w." leading facet.##]


3.1.3 Local or specialized tree

   The local tree is intended for feature tags meant to label
   capabilities or preferences which are relevant in a localized,
   specialized, restricted, or experimental context.

   Variant data which is accessible to the whole Internet Community,
   but usable only with locally extended browsing software, is
   typically labeled with tags in the local tree.

   The owner of "local" tags and associated specifications is the
   person or entity making the registration, or one to whom
   responsibility has been transferred as described below.

   Tags in the local tree will be distinguished by the leading facet
   "l.".  While public exposure and review of feature tags to be
   registered in the local tree is not required, using the
   ietf-feature-tags list for review is strongly encouraged to improve
   the quality of those specifications.  Registrations in the local
   tree may be submitted directly to the IANA.


3.1.4 Special `x.' tree

   Feature tags with "x." as the first facet are reserved for use in
   experimental contexts.  These tags are unregistered, experimental,
   and should be used only with the active agreement of the parties
   exchanging them.

   With the low-barrier registration procedures described above for
   global and local trees, it should rarely, if ever, be necessary to
   use experimental tags, and as such use of these tags is
   discouraged.


3.1.5 Additional registration trees

   From time to time and as required by the community, the IANA may,
   with the advice and consent of the IESG, create new top-level
   registration trees.  Establishment of these new trees will be
   announced through RFC publication approved by the IESG.


3.2 Registration requirements

   Feature tag registration proposals are all expected to conform
   to various requirements laid out in the following sections.


3.2.1 Functionality requirement

   A feature tag must function as an actual feature negotiation
   capability or preference indicator.  A feature tag must never
   indicate a property of a representation, but must indicate the
   capability to handle a property of a representation, or the
   preference for property of a representation.

   A feature tag may not simply reproduce the negotiation
   functionality of the existing standardized HTTP negotiation
   dimensions mentioned in Section 4.6 of [2].  In particular, media
   types, character sets, transfer encodings, and languages may not be
   registered as feature tags.

   Sub-properties of media types, character sets, and languages may be
   registered as feature tags, because in [2], negotiation on such
   sub-properties is often only viable within the feature negotiation
   framework.  The power of media type parameter negotiation in [2] is
   very limited.  Therefore, whenever powerful negotiation on a
   sub-property of a media type is desirable, registration of a
   feature tag for this sub-property is allowed even if it can also be
   expressed as a media type parameter.

   [##Question to be resolved: Content negotiation allows a primitive
   form of negotiation on HTTP protocol extensions, by offering a
   choice between a variant which is transferred using the protocol
   extension, and a variant without it.  The planned PEP standard will
   offer a much more powerful and scalable form of negotiation in this
   area.  The wide-spread use of feature negotiation to negotiate on
   protocol extensions could be harmful to caching.  Should the
   registration of feature tags which intend to allow for negotiation
   on HTTP protocol extensions therefore be disallowed?  Or should
   part of the feature tag name-space be reserved to mirror the
   information which is normally conveyed through PEP?##]


3.2.2 Naming requirements

   All feature tag names must be unique, and must conform to the HTTP
   token syntax [1].

   Any predefined feature tag values and any defined tag value formats
   must also conform to the HTTP token syntax [1].

   The IANA may reject tag names which are obviously bogus or
   misleading.  The rejection has to include a suggestion for a tag
   name which would be acceptable.  Note however that other than in
   the IETF tree, the acceptance of a feature tag does not imply
   certification that the tag is adequately named.


3.2.3 Specification requirements

   For feature tags which indicate a preference, a precise and openly
   available specification of the preference is required, and must at
   a minimum be referenced by, if it isn't actually included in, the
   feature tag registration proposal itself.

   For feature tags registered in the IETF tree which indicate a
   capability, a precise and openly available specification of the
   capability is required.  It must at a minimum be referenced by (if
   not actually included in) the feature tag registration
   proposal itself.

   For feature tags in the global and local trees which indicate a
   capability, an openly available description of the capability is
   minimally required.  The specification of detailed syntax and
   processing particulars need not be publicly available.  Such
   registration proposals are explicitly permitted to include a
   specification of which software and version (first) implements the
   indicated capability.  References to or inclusion of specifications
   in these registration proposals is encouraged but not required.

   The registration of feature tags referencing patented technology is
   specifically permitted.  However the restrictions set forth in RFC
   1602 on the use of patented technology in standards-track protocols
   must be respected when the specification of a feature tag is part
   of a standards-track protocol.


3.2.4 Security requirements

   An analysis of security issues is required for all tags
   registered in the IETF tree.  (This is in accordance with the basic
   requirements for all IETF protocols.)  A similar analysis for
   feature tags registered in the global or local trees is encouraged
   but not required.  All descriptions of security issues must
   be as accurate as possible regardless of registration tree.  In
   particular, a statement that there are "no security issues
   associated with the indicated feature" must not be confused with
   "the security issues associates with this feature have not been
   assessed".

   There is absolutely no requirement that feature tags registered
   in any tree be secure or completely free from risks.
   Nevertheless, all known security risks must be identified in
   the registration of a feature tag, again regardless of
   registration tree.

   The security considerations section of all registrations is subject
   to continuing evaluation and modification, and in particular may be
   extended by use of the "comments on feature tags" mechanism
   described in subsequent sections.


3.2.5 Publication requirements

   Proposals for feature tags registered in the IETF tree must be
   published as RFCs.  RFC publication of global and local feature tag
   proposals is not required.  In all cases the IANA will retain
   copies of all feature tag proposals and "publish" them as part of
   the feature tag registration tree itself.

   Other than in the IETF tree, the registration of a feature tag does
   not imply endorsement, approval, or recommendation by the IANA or
   the IETF or even certification that the specification is adequate.

   It is neither possible nor necessary for the IANA to conduct a
   comprehensive review of feature tag registrations.  Nevertheless,
   the IANA has the authority to identify obviously incompetent
   material and exclude it.


3.3 Registration procedure

   The following procedure has been implemented by the IANA for review
   and approval of new feature tags.  This is not a formal standards
   process, but rather an administrative procedure intended to allow
   the fast creation of negotiation capabilities for newly introduced
   features.

   For registration in the IETF tree, the normal IETF processes should
   be followed.  Posting of an internet-draft and announcement
   on the ietf-feature-tags list (as described in the next subsection)
   is a first step.  For registrations in the global or local trees,
   the initial review step described below may be omitted and the tag
   registered directly by submitting the template and an explanation
   to the IANA (at iana@isi.edu).  However, authors of global or local
   feature tag specifications are encouraged to seek community review
   and comment whenever that is feasible.


3.3.1 Present the feature tag to the community for review

   Send a proposed feature tag registration to the
   "ietf-feature-tags@iana.org" mailing list for a two week review
   period.  This mailing list has been established for the purpose of
   reviewing proposed feature tags.  Proposed feature tags are not
   formally registered and must not be used; the "x." prefix can be
   used until registration is complete.

   The intent of the public posting is to solicit comments and
   feedback on the choice of tag name, the clarity of the tag
   specification, and a review of any security considerations.  The
   submitter may submit a revised registration proposal, or withdraw
   the registration proposal completely, at any time.


3.3.2 IESG approval

   Feature tags registered in the IETF tree must be submitted to
   the IESG for approval.


3.3.3 IANA registration

   Provided that the proposed tag meets the requirements for feature
   tags and has obtained whatever approval is necessary, the
   author may submit the registration request to the IANA, which
   will register the feature tag and make the feature tag
   registration available to the community.


3.3.4 Delayed publication

   By default, feature tag registration proposals are published by the
   IANA immediately after registration of the tag.

   In some situations, a software vendor may not wish that a
   specification of a tag for a planned new feature is published
   before the date at which the software implementing this feature is
   released to the Internet Community.  Therefore, when submitting a
   feature tag registration proposal for a planned feature, a vendor
   may request a publication delay of up to four weeks after
   registration of the tag by the IANA.

   Immediately after receiving a notification of registration from the
   IANA, the vendor may release software which recognizes the tag to
   the Internet Community, and make public the tag specification
   though his own channels.


3.4 Comments on feature tag registrations

   Comments on registered feature tags may be submitted by members of
   the community to the IANA.  These comments will be passed on to the
   "owner" of the feature tag if possible.  Submitters of comments may
   request that their comment be attached to the feature tag
   registration itself, and if the IANA approves of this the comment
   will be made accessible in conjunction with the tag registration
   itself.


3.5 Location of registered feature tag list

   Feature tag registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/feature-
   tags/" and all registered feature tags will be listed in the
   periodically issued "Assigned Numbers" RFC [currently RFC- 1700].
   The feature tag description and other supporting material may also
   be published as an Informational RFC by sending it to
   "rfc-editor@isi.edu" (please follow the instructions to RFC authors
   [RFC-1543]).


3.6 IANA procedures for registering feature tags

   The IANA will only register feature tags in the IETF tree in
   response to a communication from the IESG stating that a given
   registration has been approved.

   Global and local tags will be registered by the IANA automatically
   and without any formal review as long as the following minimal
   conditions are met:

    (1)   Feature tags must indicate an actual feature negotiation
          capability or preference.

    (2)   All feature tag names must be unique, and must conform to the
          HTTP token syntax.  Any predefined feature tag values and
          any defined tag value formats must also conform to the HTTP
          token syntax.

    (3)   For feature tags which indicate a preference, a precise and
          openly available specification of the preference is
          required.  For feature tags which indicate a capability, an
          openly available description of the capability is minimally
          required.

    (4)   Any security considerations given must not be obviously
          bogus. (It is neither possible nor necessary for the
          IANA to conduct a comprehensive security review of
          feature tag registrations.  Nevertheless, the IANA has
          the authority to identify obviously incompetent material
          and exclude it.)


3.7 Change control

   Once a feature tag has been published by the IANA, the owner may
   request a change to its definition.  The change request follows the
   following procedure:

    (1) Publish the revised template on the ietf-feature-tags list.

    (2) Leave at least two weeks for comments.

    (3) Publish using the IANA after formal review if required.

   Changes should be requested only when there are serious omissions
   or errors in the published specification.  When review is required,
   a change request may be denied if it renders a use of negotiated
   capabilities that was valid under the previous definition invalid
   under the new definition.

   The owner of a feature tag may pass responsibility for the feature
   tag to another person or agency by informing the IANA and the
   ietf-feature-tags list; this can be done without discussion or
   review.

   The IESG may reassign responsibility for a feature tag.  The most
   common case of this will be to enable changes to be made to tags
   where the author of the registration has died, moved out of contact
   or is otherwise unable to make changes that are important to the
   community.

   Feature tag registrations may not be deleted; feature tags which
   are no longer believed appropriate for use can be declared OBSOLETE
   by a change to their "intended use" field; such feature tags will
   be clearly marked in the lists published by the IANA.


3.8 Registration template

   To:  iana@isi.edu
   Subject: Registration of feature tag XXXX

    | Instructions are preceded by `|'.  Some fields are optional.

   Feature tag name:

   Feature tag summary:

    | See appendix A for the format of a feature tag summary

   Presence of the tag indicates:

   Tag value (if any) indicates:

   Predefined tag values (if any):

   Absence 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]

   Applications or sites which will use this feature tag:       [optional]

    | For applications, also specify the number of the first version
    | which will use the tag.

   Security considerations:

   Additional information:                                      [optional]

     Keywords:                                                  [optional]

     Related feature tags:                                      [optional]

     Related media 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.

     See also:                                                  [optional]

   Person & email address to contact for further information:

   Intended usage:

    | one of COMMON, LIMITED USE or OBSOLETE

   Author/Change controller:


    |  Any other information that the author deems interesting may be
    |  added below.


4 Acknowledgments

   More than half of the text in Section 3 was taken from [3].  The
   authors wish to thank Larry Masinter for contributing to early
   discussions of feature tag registration.


5 References

   [1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1.
       Internet-Draft draft-ietf-http-v11-spec-06.txt, HTTP Working
       Group, July 4, 1996

   [2] K. Holtman, A. Mutz, Transparent Content Negotiation in HTTP,
       Internet-Draft draft-holtman-http-negotiation-03.txt, HTTP
       Working Group, September 6, 1996

   [3] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail
       Extensions (MIME) Part Four: Registration Procedures
       Internet-Draft draft-ietf-822ext-mime-reg-04.txt, Network
       Working Group, June 1996


6 Author's address

   Koen Holtman
   Technische Universiteit Eindhoven
   Postbus 513
   Kamer HG 6.57
   5600 MB Eindhoven (The Netherlands)
   Email: koen@win.tue.nl

   Andrew H. Mutz
   Hewlett-Packard Company
   1501 Page Mill Road 3U-3
   Palo Alto CA 94304, USA
   Fax +1 415 857 4691
   Email: mutz@hpl.hp.com


Appendix A: Feature tag summaries

   [##The text in this appendix will probably be included in the next
   version of [2]##]

   A feature tag summary is a compact description of a feature tag
   which uses the following typographical format:

     <tag declaration>

        <text describing the tag>

   This format was designed to allow for the easy construction of web
   pages listing many feature tags.

   The <tag declaration> part gives the tag name and specifies the
   intended use of the tag.  There are four possible forms:

     Form of tag declaration:        Intended use of tag:
     ==============================  ===========================
      tag_name                        without a value

      tag_name=value_description      with zero or more values

      tag_name={value_description}    with a single value

      tag_name<=value_description     with a numeric range


   The <text describing the tag> part should consist of one to four
   sentences describing the tag.  The text often starts with
   `Indicates support for ....' for tags describing capabilities and
   `Indicates a preference for ....' for tags describing preferences.
   An example of a feature tag summary is:

      html=version

        Indicates support for the given HTML version.  Predefined
        values are 1.0, 2.0, 3.2.  Example: Accept-Features: html=2.0,
        html=3.2, *


Appendix B: IANA and RFC editor to-do list

   VERY IMPORTANT NOTE:  This appendix is intended to communicate
   various editorial and procedural tasks the IANA and the RFC
   Editor should undertake prior to publication of this document
   as an RFC.  This appendix should NOT appear in the actual RFC
   version of this document!

   This document refers to the feature tags mailing list
   ietf-feature-tags@iana.org.  This list does not exist at the
   present time and needs to be created.

   The ftp://ftp.isi.edu/in-notes/iana/assignments/feature-tags/" area
   does not exist at the present time and needs to be created.


Expires: April 30, 1997