rfc2506.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

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


   Andrew H. Mutz
   Hewlett-Packard Company
   11000 Wolfe Rd. 42UO
   Cupertino CA 95014 USA

   Fax [phone]
   EMail: [e-mail]


   Ted Hardie
   Equinix
   901 Marshall Street
   Redwood City, CA 94063 USA

   EMail: [e-mail]





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]