summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2506.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2506.txt')
-rw-r--r--doc/rfc/rfc2506.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc2506.txt b/doc/rfc/rfc2506.txt
new file mode 100644
index 0000000..0d1daae
--- /dev/null
+++ b/doc/rfc/rfc2506.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group K. Holtman
+Request for Comments: 2506 TUE
+BCP: 31 A. Mutz
+Category: Best Current Practice Hewlett-Packard
+ T. Hardie
+ Equinix
+ March 1999
+
+
+ Media Feature Tag Registration Procedure
+
+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 Notice
+
+ 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/>.
+
+
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 1]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+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].
+
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 2]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+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.
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 3]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ 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:
+
+
+
+
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 4]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ 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.
+
+
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 5]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+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
+
+ Tags in the global tree will be distinguished by the leading facet
+ "g.". An organization may propose either a designation indicative of
+ the feature, (e.g., "g.blinktags") or a faceted designation including
+ the organization name (e.g., "g.organization.blinktags").
+ Organizations which have registered media types under the MIME vendor
+ tree should use the same organizational name for media feature tags
+ if they propose a faceted designation. The acceptance of the proposed
+ designation is at the discretion of the IANA. If the IANA believes
+ that a designation needs clarification it may request a new proposal
+ from the proposing organization or otherwise coordinate the
+ development of an appropriate designation.
+
+ Registrations of feature tags 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
+ proposed for 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 leading facet u. is followed by a URI [9]
+ which conforms to the character limitations specified in this
+
+
+
+Holtman, et. al. Best Current Practice [Page 6]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ document. 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 media 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/media-
+ 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@rfc-editor.org".
+
+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 a
+ designated expert. That review will serve to ensure that the tag
+ meets the technical requirements of this specification.
+
+3.4 Registration template
+
+ 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.
+
+
+
+Holtman, et. al. Best Current Practice [Page 7]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ 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),
+
+
+
+Holtman, et. al. Best Current Practice [Page 8]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ | 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
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 9]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ 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
+
+ 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 media 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 media feature tag registration.
+
+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.
+
+
+
+Holtman, et. al. Best Current Practice [Page 10]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+ [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
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 11]
+
+RFC 2506 Media Feature Tag Registration Procedure March 1999
+
+
+8 Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation 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, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holtman, et. al. Best Current Practice [Page 12]
+