As per Relevance of the word registration, we have this rfc below:
Network Working Group K.
Request for Comments: 2506
BCP: 31 A.
Category: Best Current Practice Hewlett-
T.
March 1999
Media Feature Tag Registration
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
Recent Internet applications, such as the World Wide Web,
together a great diversity in data formats, client and
platforms, and communities. This has created a need for
feature descriptions and negotiation mechanisms in order to
and reconcile the form of information to the capabilities
preferences of the parties involved
Extensible media feature identification and negotiation
require a common vocabulary in order to positively identify
features. A registration process and authority for media features
defined with the intent of sharing this vocabulary
communicating parties. In addition, a URI tree is defined to
sharing of media feature definitions without registration
This document defines a registration procedure which uses
Internet Assigned Numbers Authority (IANA) as a central registry
the media feature vocabulary
Please send comments to the CONNEG working group at
medfree@imc.org>. Discussions of the working group are archived
.
Holtman, et. al. Best Current Practice [Page 1]
RFC 2506 Media Feature Tag Registration Procedure March 1999
TABLE OF
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
Recent Internet applications, such as the World Wide Web,
together a great diversity in data formats, client and
platforms, and communities. This has created a need for
feature descriptions and negotiation mechanisms in order to
and reconcile the form of information to the capabilities
preferences of the parties involved
Extensible media feature identification and negotiation
require a common vocabulary in order to positively identify
features. A registration process and authority for media features
defined with the intent of sharing this vocabulary
communicating parties. In addition, a URI tree is defined to
sharing of media feature definitions without registration
This document defines a registration procedure which uses
Internet Assigned Numbers Authority (IANA) as a central registry
the media feature vocabulary
This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT
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
2.1 Media feature tag
Media feature tags represent individual and simple
related to media capabilities or properties associated with
resource to which they are applied. Examples of such features are
* the color depth of the screen on which something is to be
* the type of paper available in a
* the support of the `floating 5 dimensional tables'
* the fonts which are available to the
* the capability to display graphical
Each media feature tag identifies a single characteristic.
associated with a specific tag must use the data type defined
that tag. The list of allowed data types is presented below,
section 2.3.
Examples of media feature tags with values are
* the width of a display in pixels per centimeter represented as
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
either a value in an enumerated list or with a defined mapping
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
elsewhere [4].
Feature collections may be composed using a number of
feature tags [2]. Composition of feature collections is
elsewhere [2]. Examples of feature collections requiring
media feature tags are
* the set of all fonts used by a
* the width and height of a
* the combination of color depth and resolution a display can
This registry presumes the availability of the MIME media
registry, and MIME media types MUST NOT be re-registered as
feature tags. Media feature tags which are currently in use
individual protocols or applications MAY be registered with
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
transport protocol or capability exchange mechanism. The registry
limited, however, to feature tags which express a capability
preference related to how content is presented. Feature tags
to other axes of negotiation are not appropriate for this registry
Capability exchange mechanisms may, of course, be used to express
variety of capabilities or preferences
2.2 Media feature tag
A media feature tag is a string consisting of one or more of
following US-ASCII characters: uppercase letters, lowercase letters
digits, colon (":"), slash ("/"), dot (".") percent ("%"), and
("-"). Feature tags are case-insensitive. Dots are understood
potentially imply hierarchy; a feature can be subtyped by
it as tree.feature.subfeature and by indicating this in
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
conflict with the creation of new registration trees; in general
means avoiding tags which begin with an alphabetic character
by a dot. The current registration trees are described in section 3
below
2.3 Media feature tag
The registry will initially support the use of the following
types as tag values
- signed
- rational
- tokens, with equality
- tokens, with defined ordering
- strings, with standard (octet-by-octet) equality
- strings, with defined equality and/or comparison
"Token" here means the token data type as defined by [7], which
be summarized as
Holtman, et. al. Best Current Practice [Page 4]
RFC 2506 Media Feature Tag Registration Procedure March 1999
token = 1*
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP /
At the time of registration, each tag must be associated with
single data type. If that data type implies a defined comparison
an ordering, the registrant must define the ordering or comparison
For ordered tokens, this may be by full enumeration of the tokens
their order or by reference to an ordering mechanism. For
comparisons, a full description of the rules for comparison must
provided or included by reference
Media feature tags related to spatial or temporal
must be registered with a single canonical unit. It is
preferred that units be in the SI system; where current practice
defined units in other systems (such as pixels per inch),
conversion method to SI units must be provided. Conversion
should include a defined rounding practice
2.4 ASN.1 identifiers for media feature
Certain protocols use ASN.1 identifiers rather than human-
representations for capability exchange. In order to allow
systems to interoperate, registrants may provide an ASN.1
or ask that IANA assign an ASN.1 identifier during registration
These identifiers are not required for registration, but may
assistance to those building gateways or other cross-
systems. Note that ASN.1 identifiers assigned by IANA will
treated as tokens, not as elements from which sub-
identifiers may be created or derived
3 Media feature tag
Media feature tags can be registered in several
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
fashion appropriate to the tree involved. The feature tag is
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
The following subsections define registration "trees",
by the use of faceted names (e.g., names of the form "tree.feature
name").
3.1.1 IETF
The IETF tree is intended for media feature tags of general
to the Internet Community, and proposals for these tags must meet
"IETF Consensus" policies described in [5].
Registration in the IETF tree requires approval by the IESG
publication of the feature tag specification as an RFC.
for feature tag registration in the IETF tree can originate in any
of the IETF or as an individual submission to the IESG
Feature tags in the IETF tree normally have names that are
explicitly faceted, i.e., do not contain period (".", full stop
characters
3.1.2 Global
Tags in the global tree will be distinguished by the leading
"g.". An organization may propose either a designation indicative
the feature, (e.g., "g.blinktags") or a faceted designation
the organization name (e.g., "g.organization.blinktags").
Organizations which have registered media types under the MIME
tree should use the same organizational name for media feature
if they propose a faceted designation. The acceptance of the
designation is at the discretion of the IANA. If the IANA
that a designation needs clarification it may request a new
from the proposing organization or otherwise coordinate
development of an appropriate designation
Registrations of feature tags in the global tree must meet
"Expert Review" policies described in [5]. In this case,
designated area expert will review the proposed tag, consulting
the members of a related mailing list. A registration may
proposed for the global tree by anyone who has the need to allow
communication on a particular capability or preference
3.1.3 URI
A feature tag may be defined as a URI using the restricted
set defined above. Feature tags in the URI tree are identified by
leading facet "u.". The leading facet u. is followed by a URI [9]
which conforms to the character limitations specified in
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
authority regarding features defined and described by the content
the URI. These tags are considered unregistered for the purpose
this document
3.1.4 Additional registration
From time to time and as required by the community, the IANA may
with the advice and consent of the IESG, create new top-
registration trees. These trees may be created for
registration and management by (for example) well-known
bodies, such as scientific societies for media feature types
to the sciences they cover. Establishment of these new trees will
announced through RFC publication approved by the IESG
3.2 Location of registered feature tag
Feature tag registrations will be posted in the anonymous
directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media
feature-tags/" and all registered feature tags will be listed in
periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
1700]. The feature tag description and other supporting material
also be published as an Informational RFC by sending it to "rfc
editor@rfc-editor.org".
3.3 IANA procedures for registering feature
The IANA will only register feature tags in the IETF tree in
to a communication from the IESG stating that a given
has been approved
Global tags will be registered by the IANA after review by
designated expert. That review will serve to ensure that the
meets the technical requirements of this specification
3.4 Registration
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list
Subject: Registration of media feature tag
| 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
| 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
TRUE or FALSE. A value of TRUE indicates an
capability. A value of FALSE indicates the
is not available
| If you wish to indicate two mutually exclusive
| that cannot be expressed as the availability or lack of
| 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
[ ] 2b. Rational
[ ] 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
alternative results
| If you have selected 2d you must provide the ordering
| or a full and ordered enumeration of possible values. If
| have selected 2f, you must provide a definition of the comparison
| Definitions by included reference must be to stable and
| available specifications
|
| If the number of alternative results is small, you
| enumerate the identifiers of the different results and
| 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
| described by referring to another IANA registry, for
| the paper sizes enumerated by the Printer MIB
The feature tag is intended primarily for use in the
applications, protocols, services, or negotiation mechanisms
[optional
| For applications, also specify the number of the first
| 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
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
further information
Intended usage
| one of COMMON, LIMITED USE or
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
| or IETF trees, with a maximum of two months.
| requesting a registration with a publication delay should
| that this delays only the official publication of the
| and does not prevent information on it from being
| by the members of the relevant mailing list
Other information: [optional
| Any other information that the author deems interesting may
| added here
4 Security
Negotiation mechanisms reveal information about one party to
parties. This may raise privacy concerns, and may allow a
party to make better guesses about the presence of specific
holes
5
The details of the registration procedure in this document
directly adapted from [1]. Much of the text in section 3
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
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
discussions about media feature tag registration
6
[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Extensions (MIME) Part Four: Registration Procedures", BCP 13,
RFC 2048, November 1996.
[2] Klyne, G., "An algebra for describing media feature sets",
in Progress
[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation
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
for Display, Print, and Fax", RFC 2534, March 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an
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,
1997.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW,"
1630, June 1994.
7 Authors'
Koen
Technische Universiteit
Postbus 513
Kamer HG 6.57
5600 MB
The
EMail: koen@win.tue.
Andrew H.
Hewlett-Packard
11000 Wolfe Rd. 42
Cupertino CA 95014
Fax +1 408 447 4439
EMail: andy_mutz@hp.
Ted
901 Marshall
Redwood City, CA 94063
EMail: hardie@equinix.
Holtman, et. al. Best Current Practice [Page 11]
RFC 2506 Media Feature Tag Registration Procedure March 1999
8 Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Holtman, et. al. Best Current Practice [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
