Network Working Group L. Masinter
Request for Comments: 2718 Xerox Corporation
Category: Informational H. Alvestrand
Maxware, Pirsenteret
D. Zigmond
WebTV Networks, Inc.
R. Petke
UUNET Technologies
November 1999
Network Working Group L. Masinter
Request for Comments: 2718 Xerox Corporation
Category: Informational H. Alvestrand
Maxware, Pirsenteret
D. Zigmond
WebTV Networks, Inc.
R. Petke
UUNET Technologies
November 1999
Guidelines for new URL Schemes
新网址计划指引
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes.
统一资源定位器（URL）是可通过Internet访问的资源位置的紧凑字符串表示形式。本文档提供了定义新URL方案的指南。
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. RFC 2396 [1] defines the general syntax and semantics of URIs, and, by inclusion, URLs. URLs are designated by including a "<scheme>:" and then a "<scheme-specific-part>". Many URL schemes are already defined.
统一资源定位器（URL）是可通过Internet访问的资源位置的紧凑字符串表示形式。RFC 2396[1]定义了URI的一般语法和语义，并通过包含定义了URL。URL通过包含“<scheme>：”和“<scheme-specific-part>”来指定。许多URL方案已经定义。
This document provides guidelines for the definition of new URL schemes, for consideration by those who are defining and registering or evaluating those definitions.
本文件提供了定义新URL方案的指南，供定义、注册或评估这些定义的人员参考。
The process by which new URL schemes are registered is defined in RFC 2717 [2].
注册新URL方案的过程在RFC 2717[2]中定义。
Because new URL schemes potentially complicate client software, new schemes must have demonstrable utility and operability, as well as compatibility with existing URL schemes. This section elaborates these criteria.
由于新的URL方案可能使客户端软件复杂化，因此新方案必须具有可证明的实用性和可操作性，以及与现有URL方案的兼容性。本节阐述了这些标准。
New URL schemes should follow the same syntactic conventions of existing schemes when appropriate. If a URI scheme that has embedded links in content accessed by that scheme does not share syntax with a different scheme, the same content cannot be served up under different schemes without rewriting the content. This can already be a problem, and with future digital signature schemes, rewriting may not even be possible. Deployment of other schemes in the future could therefore become extremely difficult.
适当时，新的URL方案应遵循与现有方案相同的语法约定。如果在该方案访问的内容中嵌入了链接的URI方案不与其他方案共享语法，则在不重写内容的情况下，无法在不同方案下提供相同的内容。这可能已经是一个问题，而对于未来的数字签名方案，重写甚至可能是不可能的。因此，将来部署其他计划可能会变得极其困难。
Why should new URL schemes share as much of the generic URI syntax (that makes sense to share) as possible? Consider the following:
为什么新的URL方案应该尽可能多地共享通用URI语法（这对共享很有意义）？考虑以下事项：
o If fragment syntax isn't shared between two schemes, (e.g. "<a href="#foo">"), you can't move individual completely self referential documents between schemes without rewriting the embedded references within the document. In the Web, the fragment syntax is a property of the media type, and evaluated by the client.
o 如果两个方案之间没有共享片段语法（例如“<a href=“#foo”>”），则如果不重写文档中的嵌入引用，就无法在方案之间移动单个完全自引用文档。在Web中，片段语法是媒体类型的属性，由客户端进行计算。
o If fragment syntax is not shared between different media types of the same capability (e.g. HTML, XML, Word, or image types such as GIF, JPEG, PNG) then you can't have a URI reference that can evolve to superior media types as they become available, or even likely work properly today with content negotiation.
o 如果具有相同功能的不同媒体类型（例如HTML、XML、Word或图像类型，如GIF、JPEG、PNG）之间没有共享片段语法，那么您就无法拥有一个URI引用，该URI引用可以在可用时演变为更优的媒体类型，甚至可能在今天的内容协商中正常工作。
o If relative syntax (to the extent of understanding the URI is relative, and what part of the URI string is relative) isn't shared between two schemes, (e.g. "<a href="foo">"), you can't move sets of documents that are internally self referential between schemes without rewriting the embedded URIs.
o 如果两个方案之间没有共享相对语法（就理解URI是相对的，并且URI字符串的哪个部分是相对的而言），（例如“<a href=“foo”>”），则在不重写嵌入的URI的情况下，无法在方案之间移动内部自引用的文档集。
o If the ".." syntax as a path component in relative URI's isn't shared between schemes, you can't easily have sets of document sets and refer to them between schemes without rewriting the embedded references.
o 如果在相对URI中作为路径组件的“.”语法在方案之间没有共享，那么在不重写嵌入引用的情况下，您就不能轻松地拥有文档集集集并在方案之间引用它们。
o If the "/" syntax (to the extent of understanding that the URI refers to a path relative to the current naming authority, see section 2.1.1) isn't shared, you can't have multiple sets of documents easily be moved up or down in a relative hierarchy of names and share a common set of documents between them, without rewriting the content, shared either in that scheme or between schemes. The best example is a site that has a common set of GIF's, JPEG and PNG images, and you want to reorganize the site changing the depth of a subtree from one depth to another, or from one directory to another where the depth isn't the same.
o 如果“/”语法（就理解URI指的是相对于当前命名机构的路径而言，请参见第2.1.1节）未共享，则在不重写内容的情况下，无法在名称的相对层次结构中轻松上下移动多个文档集并在它们之间共享一组公共文档，在该方案中或在方案之间共享。最好的例子是一个站点，它有一组通用的GIF、JPEG和PNG图像，您希望重新组织该站点，将子树的深度从一个深度更改为另一个深度，或者从一个目录更改为另一个深度不相同的目录。
o If naming authority syntax (e.g. what comes after "//" in most URL schemes, see section 2.1.1) and relative path syntax is shared, to the extent of understanding that the URI has a naming authority, and what part of the URI string is the naming authority vs. path), isn't shared between two schemes, you can't share identical name spaces and serve them up via different schemes. (The naming authority syntax is a property of the scheme). The fact that HTTP, and FTP have the same syntax, for example, has often been exploited by sites transitioning from ftp archive service to HTTP archive service so that the URL's can be identical between schemes except for the scheme; the same content can be served via two schemes simultaneously.
o 如果命名机构语法（例如，在大多数URL方案中“/”之后的内容，请参见第2.1.1节）和相对路径语法是共享的，在理解URI具有命名机构以及URI字符串的哪一部分是命名机构与路径的程度上，两个方案之间不共享，您不能共享相同的名称空间并通过不同的方案提供它们。（命名机构语法是方案的一个属性）。例如，HTTP和FTP具有相同语法这一事实经常被从FTP存档服务转换到HTTP存档服务的站点所利用，因此，除了方案之外，方案之间的URL可以相同；相同的内容可以通过两个方案同时提供。
Contrary to some examples set in past years, the use of double slashes as the first component of the <scheme-specific-part> of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's <scheme-specific-part> contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their <scheme-specific-part> should not use double slashes following the "<scheme>:" string.
与过去几年的一些示例相反，使用双斜杠作为URL的<scheme-specific part>的第一个组件不仅仅是一个艺术指标，表明下面是URL：只有当URL的<scheme-specific part>的语法包含RFC 2396中描述的层次结构时，才使用双斜杠。在这些方案的URL中，使用双斜杠表示下面是命名机构的顶级层次元素。（有关详细信息，请参阅RFC 2396第3节。）在其<scheme specific part>中不包含一致层次结构的URL方案不应在“<scheme>：”字符串后使用双斜杠。
URL schemes should use the generic URL syntax if they are intended to be used with relative URLs. A description of the allowed relative forms should be included in the scheme's definition. Many applications use relative URLs extensively. Specifically,
如果要与相对URL一起使用，URL方案应使用通用URL语法。方案定义中应包括允许的相对形式的说明。许多应用程序广泛使用相对URL。明确地
o Can the scheme be parsed according to RFC 2396 - for example, if the tokens "//", "/", ";", or "?" are used, do they have the meaning given in RFC 2396?
o 是否可以根据RFC 2396解析方案-例如，如果使用了“//”、“/”、“；”或“？”标记，它们是否具有RFC 2396中给出的含义？
o Does the scheme make sense to use it in relative URLs like those RFC 2396 specifies?
o 在RFC2396指定的相对URL中使用该方案有意义吗？
o If the scheme syntax is designed to be broken into pieces, does the documentation for the scheme's syntax specify what those pieces are, why it should be broken in this way, and why the breaks aren't where RFC 2396 says that they usually should be?
o 如果方案语法被设计成分段，那么方案语法的文档是否指定了这些分段是什么，为什么应该以这种方式分段，以及为什么分段不是RFC 2396通常所说的那样？
o If the scheme has a hierarchy, does it go left-to-right and with slash separators like RFC 2396?
o 如果方案有一个层次结构，它会从左到右，并使用像RFC2396这样的斜杠分隔符吗？
It is important that the semantics of the "resource" that a URL "locates" be well defined. This might mean different things depending on the nature of the URL scheme.
很重要的一点是，URL“定位”的“资源”的语义必须得到很好的定义。根据URL方案的性质，这可能意味着不同的事情。
In many cases, new URL schemes are defined as ways to translate other protocols and name spaces into the general framework of URLs. The "ftp" URL scheme translates from the FTP protocol, while the "mid" URL scheme translates from the Message-ID field of messages.
在许多情况下，新的URL方案被定义为将其他协议和名称空间转换为URL通用框架的方法。“ftp”URL方案从ftp协议转换而来，“mid”URL方案从消息的消息ID字段转换而来。
In either case, the description of the mapping must be complete, must describe how characters get encoded or not in URLs, must describe exactly how all legal values of the base standard can be represented using the URL scheme, and exactly which modifiers, alternate forms and other artifacts from the base standards are included or not included. These requirements are elaborated below.
在任何一种情况下，映射的描述都必须完整，必须描述字符如何在URL中编码或不编码，必须准确描述如何使用URL方案表示基本标准的所有法律值，以及到底包括或不包括来自基本标准的哪些修改器、替代形式和其他工件。这些要求详述如下。
Most new URL schemes are associated with network resources that have one or several network protocols that can access them. The 'ftp', 'news', and 'http' schemes are of this nature. For such schemes, the specification should completely describe how URLs are translated into protocol actions in sufficient detail to make the access of the network resource unambiguous. If an implementation of the URL scheme requires some configuration, the configuration elements must be clearly identified. (For example, the 'news' scheme, if implemented using NTTP, requires configuration of the NTTP server.)
大多数新的URL方案都与具有一个或多个可以访问它们的网络协议的网络资源相关联。“ftp”、“新闻”和“http”方案就是这种性质的。对于此类方案，规范应充分详细地描述如何将URL转换为协议操作，以使网络资源的访问明确无误。如果URL方案的实现需要一些配置，则必须清楚地标识配置元素。（例如，如果使用NTTP实现“新闻”方案，则需要配置NTTP服务器。）
In some cases, URL schemes do not have particular network protocols associated with them, because their use is limited to contexts where the access method is understood. This is the case, for example, with the "cid" and "mid" URL schemes. For these URL schemes, the specification should describe the notation of the scheme and a complete mapping of the locator from its source.
在某些情况下，URL方案没有与之关联的特定网络协议，因为它们的使用仅限于理解访问方法的上下文。例如，“cid”和“mid”URL方案就是这种情况。对于这些URL方案，规范应该描述方案的符号和定位器从其源的完整映射。
Most URL schemes locate Internet resources that correspond to data objects that can be retrieved or modified. This is the case with "ftp" and "http", for example. However, some URL schemes do not; for example, the "mailto" URL scheme corresponds to an Internet mail address.
大多数URL方案定位与可检索或修改的数据对象相对应的Internet资源。例如，“ftp”和“http”就是这种情况。但是，有些URL方案不支持；例如，“mailto”URL方案对应于Internet邮件地址。
If a new URL scheme does not locate resources that are data objects, the properties of names in the new space must be clearly defined.
如果新的URL方案没有找到作为数据对象的资源，则必须明确定义新空间中名称的属性。
When describing URL schemes in which (some of) the elements of the URL are actually representations of sequences of characters, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URL characters. Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279) [3] and then subsequently using the %HH encoding for unsafe octets is recommended.
在描述URL方案时，URL的（某些）元素实际上是字符序列的表示，应注意不要在字符编码为八位字节然后再编码为URL字符的方式中引入不必要的变化。除非有令人信服的理由要求特定方案采用其他方式，否则建议将字符序列转换为UTF-8（RFC 2279）[3]，然后对不安全的八位字节使用%HH编码。
In some contexts (for example, HTML forms) it is possible to specify any one of a list of operations to be performed on a specific URL. (Outside forms, it is generally assumed to be something you GET.)
在某些上下文（例如HTML表单）中，可以指定要在特定URL上执行的操作列表中的任何一个。（在表单之外，通常假定它是您得到的东西。）
The URL scheme definition should describe all well-defined operations on the URL identifier, and what they are supposed to do.
URL方案定义应该描述URL标识符上所有定义良好的操作，以及它们应该做什么。
Some URL schemes (for example, "telnet") provide location information for hooking onto bi-directional data streams, and don't fit the "infoaccess" paradigm of most URLs very well; this should be documented.
一些URL方案（例如，“telnet”）提供位置信息以连接到双向数据流，并且不太适合大多数URL的“infoaccess”范例；这应该记录在案。
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.
注意：可以说“除了GET之外，没有为这个URL定义任何操作”。也可以这样说：“这个URL只定义了一个操作，而且不太像GET”。重要的一点是，描述了在该类型上定义的内容。
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.
URL方案应该具有实用性。新的URL方案需要昂贵的支持。它们通常需要浏览器、代理和/或服务器中的特殊代码。有很多方法说同样的话，不必要使这些程序复杂化，而不会增加互联网的价值。
The kinds of things that are useful include:
有用的东西包括：
o Things that cannot be referred to in any other way.
o 不能以任何其他方式提及的事物。
o Things where it is much easier to get at them using this scheme than (for instance) a proxy gateway.
o 使用此方案比（例如）代理网关更容易获得的东西。
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.
提供实用程序演示的一种方法是通过网关，该网关为使用现有协议的客户端提供新方案中的对象。将网关部署到新服务要比部署理解新URL对象的浏览器容易得多。
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?
o 是否有一个单一的全局解析机制，任何代理都可以通过该机制找到引用的对象？o如果没有，用户是否有办法找到任何此类对象，并“运行自己的代理”？o操作是否可以一对一（或可能使用修饰符）映射到HTTP操作？o返回对象的类型是否定义良好？-作为MIME内容类型作为可以翻译成HTML的东西？o是否有代理的运行代码？
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.
除了方案所基于的基本机制的安全考虑之外，还必须考虑正常URL使用过程中可能发生的事情。
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 用户是否需要在没有明确请求的情况下（例如，获取IMG标记的来源）被警告这种事情正在发生？当然，这对代理网关的设计有影响。
o Is it possible to fake URLs of this type that point to different things in a dangerous way?
o 有没有可能以危险的方式伪造指向不同事物的此类URL？
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 是否有机制用于标识可以使用或需要使用此机制的请求者（例如，mailto:URL中的From:字段，或AFS:URL中的AFS访问所需的Kerberos登录）？
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)?
o 该机制是否包含在引用文档中以明文形式传递的密码或其他安全信息（例如，在“ftp”URL中）？
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).
任何以字母“U”和“R”开头的方案，特别是如果它在第一个字母上附加了“统一”、“普遍”或“统一”的任何含义，都将引起激烈的争论，并产生大量的热量（但可能很少发光）。
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.
任何这样的提案都应该确保其背后有一个很大的共识，即它将是唯一一个类似的方案，或者选择另一个名称。
Some issues that are often raised but are not relevant to new URL schemes include the following.
一些经常提出但与新URL方案无关的问题包括以下内容。
Can all objects in the world that are validly identified by a scheme be accessed by any UA implementing it?
世界上由方案有效标识的所有对象是否都可以由实现该方案的UA访问？
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.
有时答案是肯定的，有时是否定的；它通常取决于与方案本身没有直接关系的因素（如防火墙或客户端配置）。
New URL schemes are required to address all security considerations in their definitions.
需要新的URL方案来解决其定义中的所有安全问题。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[1] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[2] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[2] Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年11月。
[3] Yergeau, F., "UTF-8, A Transformation Format of Unicode and ISO 10646", RFC 2279, January 1998.
[3] “UTF-8，Unicode和ISO10646的转换格式”，RFC2279，1998年1月。
Larry Masinter Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
美国加利福尼亚州帕洛阿尔托郊狼山路3333号帕洛阿尔托研究中心
URL: http://purl.org/NET/masinter
EMail: masinter@parc.xerox.com
URL: http://purl.org/NET/masinter
EMail: masinter@parc.xerox.com
Harald Tveit Alvestrand Maxware, Pirsenteret N-7005 Trondheim NORWAY
挪威特隆赫姆Pirsenteret N-7005阿尔韦斯特兰德马克斯韦尔酒店
Phone: +47 73 54 57 00
EMail: harald.alvestrand@maxware.no
Phone: +47 73 54 57 00
EMail: harald.alvestrand@maxware.no
Dan Zigmond WebTV Networks, Inc. 305 Lytton Avenue Palo Alto, CA 94301 USA
Dan Zigmond WebTV Networks，Inc.美国加利福尼亚州帕洛阿尔托市利顿大道305号，邮编94301
Phone: +1-650-614-6071
EMail: djz@corp.webtv.net
Phone: +1-650-614-6071
EMail: djz@corp.webtv.net
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000
Rich Petke UUNET Technologies俄亥俄州希利亚德市布里顿路5000号邮政信箱，邮编43026-5000
Phone: +1-614-723-4157
Fax: +1-614-723-8407
EMail: rpetke@wcom.net
Phone: +1-614-723-4157
Fax: +1-614-723-8407
EMail: rpetke@wcom.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。