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 . Discussions of the working group are archived at . General discussions about HTTP and the applications which use HTTP should take place on the mailing list. This draft is part of a document set about transparent content negotiation in HTTP. See 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 . 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: This format was designed to allow for the easy construction of web pages listing many feature tags. The 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 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