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