CONNEG Working Group Koen Holtman, TUE Internet-Draft Andrew Mutz, Hewlett-Packard Expires: January, 1999 Ted Hardie, NASA July, 1998 Content Feature Tag Registration Procedure draft-ietf-conneg-feature-reg-01.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), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1998). All Rights Reserved. Distribution of this document is unlimited. Please send comments to the MEDFREE working group at . Discussions of the working group are archived at . 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 content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. TABLE OF CONTENTS 1 Introduction 2 Feature tag definitions 2.1 Feature tag purpose 2.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 URL tree 3.1.4 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 content feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible content feature identification and negotiation mechanisms require a common vocabulary in order to positively identify content features. A registration process and authority for content features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of content feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the content feature vocabulary. 2 Feature tag definitions 2.1 Feature tag purpose Feature tags represent individual and simple dimensions of feature capability. Examples of features related to media are: * the color depth of the screen on which something is to be displayed * the type of paper available in a printer * the support of the `floating 5 dimensional tables' feature * the fonts which are available to the recipient * the capability to display graphical content A feature tag identifies a single dimension of characteristic. Feature tag values should use the data types defined in 2.3. Examples of feature tags are defined in detail elsewhere [4]. Examples of feature tags with values are: * the width of a display in pixels per centimeter represented as an integer value. * the fonts available to a recipient as an enumerated list. * the version of a protocol composed of integers "i.j.k", defined as either a value in an enumerated list or with a defined mapping to make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, assuming j<=9 and k<=9). Feature bundles may be composed using a number of individual feature tags [2]. Composition of feature bundles is described elsewhere [2]. Examples of feature bundles requiring multiple feature tags are: * the width and height of a display * the combination of color depth and resolution a display can support This registry presumes the availability of the MIME media type registry, and MIME media types MUST NOT be re-registered as feature tags. Feature tags which are currently in use by individual protocols or applications MAY be registered with this registry if they might be applied outside of their current domain. The feature tag namespace is not bound to a particular transport protocol or capability exchange mechanism. The registry is limited, however, to feature tags which express a capability or preference related to how content is presented. Feature tags related to other axes of negotiation are not appropriate for this registry. Capability exchange mechanisms may, of course, be used to express a variety of capabilities or preferences. 2.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 ("/"), dot (".") percent ("%"), and 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. Feature tags should begin with an alphabetic character. In ABNF [6], this may be represented as: Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" ) 2.2 Feature tag values The registry will initially support the use of the following data types as feature tag values: - integers - rational numbers - tokens, with equality relarionship - strings, with equality relationship - strings, with defined comparison - ordered tokens At the time of registration, each feature tag must be associated with a single data type. If that data type implies a defined comparison or an ordering, the registrant must define the ordering or comparison. For ordered tokens, this may be by full enumeration of the tokens and their order or by reference to an ordering mechanism. For defined comparisons, a full description of the rules for comparison must be provided or included by reference. Feature tags related to spatial or temporal characteristics must be registered with a single canonical unit. It is strongly preferred that units be in the SI system; where current practice has defined units in other systems (such as pixels per inch), a conversion method to SI units must be provided. Conversion methods should include a defined rounding practice. 2.3 ASN.1 identifiers for Feature tags Certain protocols use ASN.1 identifiers rather than human-readable representations for capability exchange. In order to allow both systems to interoperate, registrants may provide an ASN.1 identifier or ask that IANA assign an ASN.1 identifier during registration. These identifiers are not required for registration, but may provide assistance to those building gateways or other cross-protocol systems. Note that ASN.1 identifiers assigned by IANA will be treated as tokens, not as elements from which sub-delegated identifiers may be created or derived. 3 Feature tag registration Feature tags can be registered in several different registration trees, with different requirements as discussed below. The vocabulary for these requirements is taken from [5]. In general, a feature tag registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The feature tag is then registered if the proposal is accepted. Review of a feature tag in the URI tree is not required. 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, and proposals for these tags must meet the "IETF Consensus" policies described in [5]. Registration in the IETF tree requires approval by the IESG and publication of the feature tag specification as an RFC. Submissions for feature tag registration in the IETF tree can originate in any WG of the IETF or as an individual submission to the IESG. Feature tags in the IETF tree normally have names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters. 3.1.2 Global tree Tags in the global tree will be distinguished by the leading facet "g.". That may be followed, at the discretion of the registrar, by either a designation indicative of the feature, (e.g., "g.blinktags") or by an IANA-approved designation of the producer's name which is then followed by a designation of the feature (e.g., g.bigcompany.obscurefeature). Registrations of feature tag in the global tree must meet the "Expert Review" policies described in [5]. In this case, a designated area expert will review the proposed tag, consulting with the members of a related mailing list. A registration may be placed in the global tree by anyone who has the need to allow for communication on a particular capability or preference. 3.1.3 URI tree A feature tag may be defined as a URI using the restricted character set defined above. Feature tags in the URI tree are identified by the leading facet "u.". The author of the URI is assumed to be registration authority regarding features defined and described by the content of the URI. These tags are considered unregistered for the purpose of this document. 3.1.4 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. These trees may be created for external registration and management by (for example) well-known permanent bodies, such as scientific societies for content feature types specific to the sciences they cover. 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 tags will be registered by the IANA after review by an area expert. That review will serve to ensure that the tag meets the technical requirements of this specification. 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. Content feature tag name: ASN.1 identifier associated with feature tag: [optional] | To have IANA assign an ASN.1 identifier, | use the value "New assignment by IANA" here. Summary of the content feature indicated by this feature tag: | Include a short (no longer than 4 lines) description or summary | Examples: | `Use of the xyzzy feature is indicated by ...' | `Support of color display is indicated by ...' | `Number of colors in a palette which can be defined ...' Number of possible values associated with this feature tag: [ ] 1. The feature tag is Boolean and the feature tag has no associated value. The tag indicates presence (or absence) of the feature. [ ] 2. The feature has an associated numeric or enumerated value. For case 1: describe the nature of the `yes' and `no' alternatives: For case 2: Indicate the data type of the value: [ ] 2a. Integer [ ] 2b. Rational number [ ] 2c. Token (equality relationship) [ ] 2d. Token (ordered) [ ] 2e. String (equality relationship) [ ] 2f. String (defined comparison) |IMPORTANT: You may only chose one of the above data types. (Only for case 2) Detailed description of the feature value meaning, and of the format and meaning of the feature tag values for the alternative results. | If you have selected 2d you must provide the ordering mechanism | or a full and ordered enumeration of possible values. If you | have selected 2f, you must provide a defintion of the comparison. | Definitions by included reference must be to stable and readily | available specifications: | | If the number of alternative results is small, you may | enumerate the identifiers of the different results and describe | their meaning. | | If there is a limited useful numeric range of result (2b, 2c), | indicate the range. | | The identifiers of the alternative results could also be | described by referring to another IANA registry, for example | the paper sizes enumerated by the Printer MIB. Expected value or behavior in the absence of the feature tag (if applicable): The feature tag is intended primarily for use in the following 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: Privacy concerns, related to exposure of personal information: Denial of service concerns related to consequences of specifying incorrect values: Other: Additional information: [optional] Keywords: [optional] Related feature tags: [optional] Related media types or data formats: [optional] Related markup tags: [optional] Name(s) & email address(es) of person(s) 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 the global or | IETF 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 Negotiation mechanisms reveal information about one party to other parties. This may raise privacy concerns, and may allow a malicious party to make better guesses about the presence of specific security holes. 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 content features, maintained in a central open registry, is due to discussions on extensible negotiation mechanisms [3] in the IETF HTTP working group. The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, and Martin Duerst for their contributions 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 [2] G. Klyne, An algebra for describing media feature sets, Internet Draft: Work in progress March 1998 [3] Holtman, K., et al, "The Alternates Header Field", Internet-Draft draft-ietf-http-alternates-01.txt, Work in progress, November 1997. [4] Masinter, L., et al, "Media Features for Display, Print, and Fax", Internet-Draft draft-ietf-conneg-media-features-00.txt, Work in progress, March 1998. [5] Norten, T., et al, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Draft draft-iesg-iana-considerations-04.txt, Work in progress, May 1998. [6] Crocker, D., Ed., Augmented BNF for Syntax Specifications: ABNF. RFC 2234, Network Working Group, November 1997. 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 Edward Hardie NASA/STX MS 204-14 Moffett Field, CA 94035 USA hardie@archimedes.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: September 11, 1998