rfc2717.txt

RFC 的详细文档！


RFC 2717      Registration Procedures for URL Scheme Names November 1999


   will not accept it.  (For instance, if an IANA registration mechanism
   is proposed, IESG might reject the tree if its mechanism would create
   undue liability on the part of IANA.)

   While the template in section 6 of this document is intended to apply
   to URL scheme names in the IETF tree, it is also offered as a
   guideline for those documenting alternative trees.

5.0 Change Control

5.1 Schemes in the IETF Tree

   URL schemes created in the IETF tree are "owned" by the IETF itself
   and may be changed, as needed, by updating the RFC that describes
   them.  Schemes described by Standards Track RFC but be replaced with
   new Standards Track RFCs.  Informational RFCs may be replaced by new
   Informational RFCs or Standards Track RFCs.

5.2 Schemes in Alternative Trees

   URL schemes in an alternative tree that are undocumented (as allowed
   by that tree's rules) may be changed by their owner at any time
   without notifying the IETF.

   URL schemes created in an alternative tree that have been documented
   by an Informational RFC, may be changed at any time by the owner,
   however, an updated Informational RFC which details the changes made,
   must be submitted to the IESG.

   The owner of a URL scheme registered in an alternative tree and
   documented by an Informational RFC may pass responsibility for the
   registration to another person or agency by informing the IESG.

   The IESG may reassign responsibility for a URL scheme registered in
   an alternative tree and documented by an Informational RFC.  The most
   common case of this will be to enable changes to be made to schemes
   where the scheme name is privately owned by the rules of its tree,
   and the owner of the scheme name has died, moved out of contact or is
   otherwise unable to make changes that are important to the community.

   The IESG may reclassify a URL scheme created in an alternative tree
   and documented via an Informational RFC as "historic" if it
   determines that the scheme is no longer in use.








Petke & King             Best Current Practice                  [Page 6]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


6.0  Registration Template

   The following issues should be addressed when documenting a new URL
   scheme:

      URL scheme name.

      URL scheme syntax.  This should be expressed in a clear and
      concise manner.  The use of ABNF is encouraged.  Please refer to
      RFC 2718 for guidance on designing and explaining your scheme's
      syntax.

      Character encoding considerations.  It is important to identify
      what your scheme supports in this regard.  It is obvious that for
      interoperability, it is best if there is a means to support
      character sets beyond USASCII, but especially for private schemes,
      this may not be the case.

      Intended usage.  What sort of resource is being identified?  If
      this is not a 'resource' type of URL (e.g. mailto:), explain the
      action that should be initiated by the consumer of the URL.  If
      there is a MIME type associated with this resource, please
      identify it.

      Applications and/or protocols which use this URL scheme name.
      Including references to documentation which defines the
      applications and/or protocols cited is especially useful.

      Interoperability considerations.  If you are aware of any details
      regarding your scheme which might impact interoperability, please
      identify them here.  For example: proprietary or uncommon encoding
      method; inability to support multibyte character sets;
      incompatibility with types or versions of underlying protocol (if
      scheme is tunneled over another protocol).

      Security considerations.

      Relevant publications.

      Person & email address to contact for further information.

      Author/Change controller.

   Applications and/or protocols which use this URL scheme name.







Petke & King             Best Current Practice                  [Page 7]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


7.0 Security Considerations

   Information that creates or updates a registration needs to be
   authenticated.

   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URL scheme may change as well.
   As new vulnerabilities are discovered, information about such
   vulnerabilities may need to be attached to existing documentation, so
   that users are not misled as to the true security properties of a
   registered URL scheme.

   If the IESG agrees to delegate the registration and change control
   functions of an alternative tree to a group or individual outside of
   the IETF, that group or individual should have sufficient security
   procedures in place to authenticate registration changes.

8.0 References

   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [2]  Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
        "Guidelines for new URL Schemes", RFC 2718, November 1999.

   [3]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
        2223, October 1997.























Petke & King             Best Current Practice                  [Page 8]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


9.0  Authors' Addresses

   Rich Petke
   UUNET Technologies
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Ian King
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA
   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]





























Petke & King             Best Current Practice                  [Page 9]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


10.  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Petke & King             Best Current Practice                 [Page 10]