rfc2718.txt

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


RFC 2718             Guidelines for new URL Schemes        November 1999


      NOTE: It is perfectly valid to say that "no operation apart from
      GET is defined for this URL".  It is also valid to say that
      "there's only one operation defined for this URL, and it's not
      very GET-like".  The important point is that what is defined on
      this type is described.

2.3 Demonstrated utility

      URL schemes should have demonstrated utility.  New URL schemes are
      expensive things to support.  Often they require special code in
      browsers, proxies, and/or servers.  Having a lot of ways to say
      the same thing needless complicates these programs without adding
      value to the Internet.

      The kinds of things that are useful include:

   o  Things that cannot be referred to in any other way.

   o  Things where it is much easier to get at them using this scheme
      than (for instance) a proxy gateway.

2.3.1 Proxy into HTTP/HTML

   One way to provide a demonstration of utility is via a gateway which
   provides objects in the new scheme for clients using an existing
   protocol.  It is much easier to deploy gateways to a new service than
   it is to deploy browsers that understand the new URL object.

   Things to look for when thinking about a proxy are:

   o  Is there a single global resolution mechanism whereby any proxy
      can find the referenced object?
   o  If not, is there a way in which the user can find any object of
      this type, and "run his own proxy"?
   o  Are the operations mappable one-to-one (or possibly using
      modifiers) to HTTP operations?
   o  Is the type of returned objects well defined?
      - as MIME content-types?
      - as something that can be translated to HTML?
   o  Is there running code for a proxy?











Masinter, et al.             Informational                      [Page 6]

RFC 2718             Guidelines for new URL Schemes        November 1999


2.4 Are there security considerations?

   Above and beyond the security considerations of the base mechanism a
   scheme builds upon, one must think of things that can happen in the
   normal course of URL usage.

   In particular:

   o  Does the user need to be warned that such a thing is happening
      without an explicit request (GET for the source of an IMG tag, for
      instance)?  This has implications for the design of a proxy
      gateway, of course.

   o  Is it possible to fake URLs of this type that point to different
      things in a dangerous way?

   o  Are there mechanisms for identifying the requester that can be
      used or need to be used with this mechanism (the From: field in a
      mailto: URL, or the Kerberos login required for AFS access in the
      AFS: URL, for instance)?

   o  Does the mechanism contain passwords or other security information
      that are passed inside the referring document in the clear (as in
      the "ftp" URL, for instance)?

2.5 Does it start with UR?

   Any scheme starting with the letters "U" and "R", in particular if it
   attaches any of the meanings "uniform", "universal" or "unifying" to
   the first letter, is going to cause intense debate, and generate much
   heat (but maybe little light).

   Any such proposal should either make sure that there is a large
   consensus behind it that it will be the only scheme of its type, or
   pick another name.

2.6 Non-considerations

   Some issues that are often raised but are not relevant to new URL
   schemes include the following.











Masinter, et al.             Informational                      [Page 7]

RFC 2718             Guidelines for new URL Schemes        November 1999


2.6.1 Are all objects accessible?

   Can all objects in the world that are validly identified by a scheme
   be accessed by any UA implementing it?

   Sometimes the answer will be yes and sometimes no; often it will
   depend on factors (like firewalls or client configuration) not
   directly related to the scheme itself.

3. Security Considerations

   New URL schemes are required to address all security considerations
   in their definitions.

4. References

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

   [2] Petke, R. and I. King, "Registration Procedures for URL Scheme
       Names", BCP 35, RFC 2717, November 1999.

   [3] Yergeau, F., "UTF-8, A Transformation Format of Unicode and ISO
       10646", RFC 2279, January 1998.



























Masinter, et al.             Informational                      [Page 8]

RFC 2718             Guidelines for new URL Schemes        November 1999


5. Authors' Addresses

   Larry Masinter
   Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   URL: http://purl.org/NET/masinter
   EMail: [e-mail]


   Harald Tveit Alvestrand
   Maxware, Pirsenteret
   N-7005 Trondheim
   NORWAY

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


   Dan Zigmond
   WebTV Networks, Inc.
   305 Lytton Avenue
   Palo Alto, CA 94301
   USA

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


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

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











Masinter, et al.             Informational                      [Page 9]

RFC 2718             Guidelines for new URL Schemes        November 1999


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



















Masinter, et al.             Informational                     [Page 10]