CONNEG Working Group                                     Koen Holtman, TUE
Internet-Draft                                Andrew Mutz, Hewlett-Packard
Expires: January, 1999                                Ted Hardie, NASA/STX
                                                                July, 1998

                    Media Feature Tag Registration Procedure

                     draft-ietf-conneg-feature-reg-03.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), ftp.ietf.org (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
CONNEG working group at <ietf-medfree@imc.org>.  Discussions of the
working group are archived at <URL: http://www.imc.org/ietf-medfree/>.



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.


TABLE OF CONTENTS

   1 Introduction

   2 Media feature tag definitions
    2.1 Media feature tag purpose
    2.2 Media feature tag syntax

   3 Media 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 media feature tag list
    3.3 IANA procedures for registering media 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 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:

  * teh 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 heirarchy; 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.3  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

  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
  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@isi.edu".


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: ietf-media-feature-tags@iana.org (Media feature tags mailing list)
        (or directly to iana@iana.org)
   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 possiblities
    | 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 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.

  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

   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] 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: <draft-ietf-conneg-feature-algebra-00.txt> Work in progress
     March 1998

  [3] Holtman, K., et al, Transparent Content Negotiation in HTTP.
      RFC 2295, Network Working Group, March 1998.

  [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] Fielding, R. et al, Hypertext Transfer Protocol -- HTTP/1.1.
     RFC 2068, Network Working Group, January 1997.

  [8] Bradner, S. Key words for use in RFCs to Indicate Requirement
     Levels. RFC 2119, Network Working Group, March 1997.

  [9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC
     1630, Network Working Group, 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

   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-media-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/media-feature-tags/
   area does not exist at the present time and needs to be created.


Expires: September 11, 1998