RFC 2506

Media Feature Tag Registration Procedure

📅 published March 1999, from ietf

Media Feature Tag Registration Procedure 🎀

okay bestie, here's the header rundown ✨ This is RFC 2506 from the Network Working Group, published in March 1999 📅. It's a Best Current Practice (BCP 31), so it's the community's recommended way of doing things, not a standard you're forced into. The authors are K. Holtman (TUE), A. Mutz (Hewlett-Packard), and T. Hardie (Equinix) 🫶. The header doesn't list anything it obsoletes or updates, so it stands on its own 💅

Status of This Memo

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited 📬

Copyright (C) The Internet Society (1999). All Rights Reserved. ©️

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 media 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 media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration 🧚

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary 🏛️

Please send comments to the CONNEG working group at <ietf-medfree@imc.org>. Discussions of the working group are archived at <URL: http://www.imc.org/ietf-medfree/>. 💌

TABLE OF CONTENTS 📋

   1 Introduction .................................................  2
   2 Media feature tag definitions ................................  3
    2.1 Media feature tag purpose .................................  3
    2.2 Media feature tag syntax ..................................  4
    2.3 Media feature tag values ..................................  4
    2.4  ASN.1 identifiers for media feature tags .................  5
   3 Media feature tag registration ...............................  5
    3.1 Registration trees ........................................  6
    3.1.1 IETF tree ...............................................  6
    3.1.2 Global tree .............................................  6
    3.1.3 URL tree ................................................  6
    3.1.4 Additional registration trees ...........................  7
    3.2 Location of registered media feature tag list .............  7
    3.3 IANA procedures for registering media feature tags ........  7
    3.4 Registration template .....................................  7
   4 Security Considerations ...................................... 10
   5 Acknowledgments .............................................. 10
   6 References ................................................... 10
   7 Authors' Addresses ........................................... 11
   8 Full Copyright Statement ..................................... 12

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 media 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 media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration 🌸

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary 👑

This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY according to usage described in [8]. 🔥

2. Media feature tag definitions 🍓

2.1. Media feature tag purpose

Media feature tags represent individual and simple characteristics related to media capabilities or properties associated with the resource to which they are applied. Examples of such features 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

Each media feature tag identifies a single characteristic. Values associated with a specific tag must use the data type defined for that tag. The list of allowed data types is presented below, in section 2.3 📝

Examples of media feature tags with values are: 🎯

  • the width of a display in pixels per centimeter represented as an integer value.
  • a font available to a recipient, selected from 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).

Further examples of media feature tags are defined in detail elsewhere [4]. 🔍

Feature collections may be composed using a number of individual feature tags [2]. Composition of feature collections is described elsewhere [2]. Examples of feature collections requiring multiple media feature tags are: 🫧

  • the set of all fonts used by a document
  • 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 media feature tags. Media 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 media 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. Media feature tag syntax

A media 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 hierarchy; a feature can be subtyped by describing it as tree.feature.subfeature and by indicating this in the registration. Tags should begin with an alphabetic character. 🔤

In ABNF [6], this may be represented as: 🧩

   Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )

Registrants should take care to avoid creating tags which might conflict with the creation of new registration trees; in general this means avoiding tags which begin with an alphabetic character followed by a dot. The current registration trees are described in section 3 below. 🧭

2.3. Media feature tag values

The registry will initially support the use of the following data types as tag values: 🎨

  • signed integers
  • rational numbers
  • tokens, with equality relationship
  • tokens, with defined ordering relationship
  • strings, with standard (octet-by-octet) equality relationship
  • strings, with defined equality and/or comparison relationship

"Token" here means the token data type as defined by [7], which may be summarized as: 🪄

   token          = 1*<any CHAR except CTLs or tspecials>

   tspecials      = "(" / ")" / "<" / ">" / "@"
                  / "," / ";" / ":" / "\" / <">
                  / "/" / "[" / "]" / "?" / "="
                  / "{" / "}" / SP / HT

At the time of registration, each 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. ⚖️

Media 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.4. ASN.1 identifiers for media 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. Media feature tag registration 🗂️

Media 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 media 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 ✨

okay so the global tree is where tags get the leading facet "g." 🎀 An organization can propose either a plain designation that describes the feature, like g.blinktags, or a faceted one that includes the organization name, like g.organization.blinktags. 💖 If an organization already registered media types under the MIME vendor tree, it should use the same organizational name for its media feature tags when it goes faceted. 🫶

The IANA gets the final say on whether a proposed designation is accepted. 💅 If the IANA thinks a designation needs clarification, it may ask the proposing organization for a new proposal, or it may just coordinate with them to come up with a good one. 🦋

Global registrations have to pass the "Expert Review" policies described in [5]. 🔥 That means a designated area expert looks over the proposed tag and checks in with the members of a related mailing list. 😭 Literally anyone who needs a way to talk about a particular capability or preference can propose a tag for the global tree. 🌈

3.1.3. URI tree

a feature tag can also be defined as a URI, as long as it sticks to the restricted character set we defined above. 🦋 URI-tree tags carry the leading facet "u.", and that facet is followed by a URI [9] that follows the character limits in this document. 🧚 The author of that URI is treated as the registration authority for the features described by its content. ✨ These tags count as unregistered for the purposes of this document. 🍓

3.1.4. Additional registration trees

every now and then, when the community needs it, the IANA may create new top-level registration trees, but only with the advice and consent of the IESG. 🌸 These trees can be handed off for external registration and management to things like well-known permanent bodies, for example scientific societies that handle media feature types for their own sciences. 🔬 Setting up any new tree gets announced through an RFC publication that the IESG approves. 📣

3.2. Location of registered feature tag list

all the feature tag registrations get posted in an anonymous FTP directory, which is ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/ 📂 Every registered feature tag also gets listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. 📜 The feature tag description and other supporting material can be published as an Informational RFC too, if you send it to rfc-editor@rfc-editor.org. 💌

3.3. IANA procedures for registering feature tags

the IANA only registers feature tags in the IETF tree after the IESG sends a message saying a given registration has been approved. 🏛️ No skipping the line, bestie 🙅‍♀️

Global tags get registered by the IANA after a designated expert reviews them. ✅ That review is there to make sure the tag meets the technical requirements of this specification. 🧐

3.4. Registration template

okay this is the template you fill out to register a tag 📝 Anything with a | in front is an instruction for you, and you can delete it before you send. Some fields are optional, so don't stress if you skip one 🫶

To: media-feature-tags@apps.ietf.org (Media feature tags mailing list)
Subject: Registration of media feature tag XXXX

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

Media 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 media 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 ...'

Values appropriate for use with this feature tag:

  [ ] 1. The feature tag is Boolean and may have values of
       TRUE or FALSE.   A value of TRUE indicates an available
       capability.  A value of FALSE indicates the capability
       is not available.

 | If you wish to indicate two mutually exclusive possibilities
 | that cannot be expressed as the availability or lack of a
 | capability, use a two-token list, rather than a Boolean value.


  [ ] 2. The feature has an associated numeric or enumerated value.

For case 2: Indicate the data type of the value:

   [ ] 2a. Signed 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 definition 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.

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 final placement in the global
 | or IETF trees, with a maximum of two months.  Organizations
 | requesting a registration with a publication delay should note
 | that this delays only the official publication of the tag
 | and does not prevent information on it from being disseminated
 | by the members of the relevant mailing list.

Other information:                                     [optional]

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

4. Security Considerations 🙈

okay, this part is serious bestie 😭 Negotiation mechanisms reveal information about one party to the other parties. 🕵️‍♀️ That can raise privacy concerns, and it can also let a malicious party make better guesses about whether specific security holes are present. 💀 Don't ignore this one!!

5. Acknowledgments 🫶

the registration procedure in this document was directly adapted from [1], and a lot of the text in section 3 was directly copied from that source. 📚

the idea of building a vocabulary of areas of media features, kept in a central open registry, comes from discussions about extensible negotiation mechanisms [3] in the IETF HTTP working group. 🌈

the authors want to thank Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, and Martin Duerst for their contributions to discussions about media feature tag registration. 💖 Thank you, queens 👑

6. References

[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.

[2] Klyne, G., "An algebra for describing media feature sets", Work in Progress.

[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP. RFC 2295, March 1998.

[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.

[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[7] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC 1630, June 1994.

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
Equinix
901 Marshall Street
Redwood City, CA 94063 USA

EMail: hardie@equinix.com

Copyright (C) The Internet Society (1999). All Rights Reserved.

okay the legal bit, so please read it 🥹 This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. 🌸 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English. 🦋

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

📦 where this page comes from