rfc2506.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页

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-
   [e-mail]>.  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]