HTTP Working Group Koen Holtman, TUE
Internet-Draft Andrew Mutz, Hewlett-Packard
Expires: January 28, 1998 Ted Hardie, NASA
Nov 28, 1997
Content Feature Tag Registration Procedure
draft-ietf-http-feature-reg-03.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.
ABSTRACT
Recent Internet applications, such as the World Wide Web, tie
together a great diversity in data formats, client and server
platforms, and communities. This has created a need for negotiation
mechanisms in order to tailor the information form to the
capabilities and preferences of the parties involved.
Extensible negotiation mechanisms need a vocabulary to identify
various things which can be negotiated on. To promote
interoperability, a registration process is needed to facilitate
sharing this vocabulary between the negotiating parties.
This document defines a registration procedure which uses the
Internet Assigned Numbers Authority (IANA) as a central registry
for this content feature vocabulary.
TABLE OF CONTENTS
1 Introduction
2 Feature tag syntax
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 Location of registered feature tag list
3.3 IANA procedures for registering feature tags
3.4 Registration template
4 Security considerations
5 Acknowledgments
6 References
7 Authors' addresses
Appendix A: IANA and RFC editor to-do list
1 Introduction
Recent Internet applications, such as the World Wide Web, tie
together a great diversity in data formats, client and server
platforms, and communities. This has created a need for various
kinds of negotiation mechanisms, which tailor the data which is
exchanged, or the exchange process itself, to the capabilities and
preferences of the parties involved.
Extensible negotiation mechanisms need a vocabulary to identify
various things which can be negotiated on. To promote
interoperability, a registration process is needed to ensure that
that this vocabulary, which can be shared between negotiation
mechanisms, is developed in an orderly, well-specified, and public
manner.
This document defines registration procedures which use the
Internet Assigned Numbers Authority (IANA) as a central registry
for this content feature vocabulary.
2 Feature tag syntax
A feature tag is a string consisting of one or more of the
following US-ASCII characters: uppercase letters, lowercase
letters, digits, colon (":"), slash ("/"), the dot (".") and the
dash ("-"). Feature tags are case-insensitive. Dots are
understood to potentially imply heirarchy; a feature can be
subtyped by describing it as tree.feature.subfeature and by
indicating this in the feature registration.
3 Feature tag registration
Registration of a new feature tag starts with the submission of a
registration proposal. Registration may occur in several different
registration trees, which have different requirements as discussed
below. In general, the new registration proposal is circulated and
reviewed in a fashion appropriate to the tree involved. The
feature tag is then registered if the proposal is acceptable. 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 the creator of an Internet service or product
introduces something new to the Internet Community, and if it is
meaningful to do 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.". That may be followed, at the discretion of the registration,
by either a designation of an area of negotiation, (e.g.,
"g.blinktags") or by an IANA-approved designation of the producer's
name which is then followed by a designation of an area of
negotiation (e.g., g.bigcompany.obscurefeature).
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.
3.1.3 Local or specialized tree
The local tree is intended for feature tags identifying areas
of negotiation which are relevant in a localized, specialized,
restricted, or experimental context.
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 URL trees
A feature tag may be defined as a complete URL. The "owner" of the
domain is assumed to be registration authority regarding features
defined and described by URLs within the domain. These tags are
considered unregistered for the purpose of this document.
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. It is explicitly assumed that these trees may
be created for external registration and management by well-known
permanent bodies, such as scientific societies for media types
specific to the sciences they cover. In general, the quality of
review of specifications for one of these additional registration
trees is expected to be equivalent to that which IETF would give to
registrations in its own tree. Establishment of these new trees
will be announced through RFC publication approved by the IESG.
3.2 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 STD 2,
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.3 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) A feature tag must function as an actual identifier of an area
of negotiation.
(2) All feature tag names must be unique, and must conform to the
syntax in section 2.
(3) An openly available description of the area of negotiation is
minimally required. The specification of a feature tag must
state whether the choice in the indicated area is a simple
yes/no choice, or if it is a choice among multiple values.
If the choice is among multiple values, and a canonical
format for these values is defined, it must be possible to
map this format onto octet strings.
(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.4 Registration template
To: ietf-feature-tags@iana.org (Feature tags mailing list)
(or directly to iana@iana.org)
Subject: Registration of feature tag XXXX
| Instructions are preceded by `|'. Some fields are optional.
Feature tag name:
Summary of the area of negotiation indicated by this feature tag:
| Include a short (no longer than 4 lines) description or summary
| Examples:
| `Negotiation on whether to use the xyzzy feature of ...'
| `Negotiation on the MIME media type of the data which
| is transmitted for ...'
| `Negotiation on whether to use colors in displaying ...'
| `Negotiation on the number of colors to use in displaying ...'
Number of alternative results in this area of negotiation:
[ ] 1. Two alternatives, which can be labeled with `yes' and `no'
[ ] 2. More than two alternatives, or two alternatives with no
natural `yes/no' labeling
For case 1: nature of the `yes' and `no' alternatives:
[ ] 1a. A particular feature is used/invoked/enabled, or not
[ ] 1b. Other
For case 2: How is a single alternative result naturally identified?
[ ] 2a. With a name, keyword, label, or tag (e.g. a language tag)
[ ] 2b. With an integer value
[ ] 2c. With a numeric value of a non-integer type (e.g. float)
[ ] 2d. Other
[ ] 2e. There is no simple way to identify a single result
(Only for case 1a) Description of the feature which is used,
invoked, or enabled if the result is `yes':
| Descriptions may also reference outside material.
(Only for case 1b) Description of the effect of the 'yes' result:
(Only for case 1b) Description of the effect of the 'no' result:
(Only for case 2) Detailed description of the area of negotiation,
and (in cases 2a-2d) of the format and meaning of the identifiers
for the alternative results:
| If the number of alternative results is small, the description
| could simply enumerate the identifiers of the different results
| and describe their meaning.
|
| The identifiers of the alternative results could also be
| described by referring to another IANA registry, for example
| the MIME media type registry.
Default negotiation result (if applicable to the intended
application domain):
The feature tag is intended for use in the applications, protocols,
services, or negotiation mechanisms: [optional]
| For applications, also specify the number of the first version
| which will use the tag, if applicable.
Examples of typical use: [optional]
Related standards or documents: [optional]
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms: [optional]
Interoperability considerations: [optional]
Security considerations:
Additional information: [optional]
Keywords: [optional]
Related feature tags: [optional]
Related media types or data formats: [optional]
Related HTML markup tags: [optional]
Person & email address to contact for further information:
Intended usage:
| one of COMMON, LIMITED USE or OBSOLETE
Author/Change controller:
Requested IANA publication delay: [optional]
| A delay may only be requested for registration in global or
| local trees, with a maximum of two months.
Other information: [optional]
| Any other information that the author deems interesting may be
| added here.
4 Security considerations
When used, negotiation mechanisms usually reveal some information
about one party to other parties. This may raise privacy concerns,
and may allow a malicious party to make more educated guesses about
the presence of security holes in the other party.
5 Acknowledgments
The details of the registration procedure in this document were
directly adapted from [1]. Much of the text in section 3 was
directly copied from this source.
The idea of creating a vocabulary of areas of negotiation, which is
maintained in a central open registry, is due to discussions on
extensible negotiation mechanisms in the IETF HTTP working group.
The authors wish to thank Ted Hardie, Larry Masinter and Graham
Klyne for contributing to discussions about feature tag
registration.
6 References
[1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures. RFC
2048, BCP 13, Network Working Group, November 1996
7 Authors' addresses
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
11000 Wolfe Rd. 42UO
Cupertino CA 95014 USA
Fax +1 408 447 4439
Email: andy_mutz@hp.com
Ted Hardie
NASA
hardie@thornhill.arc.nasa.gov
Appendix A: 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: June 1, 1998