RFC 5785: Defining Well-Known Uniform Resource Identifiers (URIs) 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc5785
标题 : RFC 5785
翻译类型 : 自动生成

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 5785                               E. Hammer-Lahav
Updates: 2616, 2818                                           April 2010
Category: Standards Track
ISSN: 2070-1721

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 5785                               E. Hammer-Lahav
Updates: 2616, 2818                                           April 2010
Category: Standards Track
ISSN: 2070-1721

Defining Well-Known Uniform Resource Identifiers (URIs)

定义众所周知的统一资源标识符（URI）

Abstract

摘要

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.

此备忘录为选定的统一资源标识符（URI）方案中的“已知位置”定义路径前缀“/.well-known/”。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5785.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5785.

版权公告

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Appropriate Use of Well-Known URIs  . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
       5.1.1.  Registration Template . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7
   Appendix B.  Frequently Asked Questions . . . . . . . . . . . . . . 7

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Appropriate Use of Well-Known URIs  . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
       5.1.1.  Registration Template . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7
   Appendix B.  Frequently Asked Questions . . . . . . . . . . . . . . 7

1. Introduction

1. 介绍

It is increasingly common for Web-based protocols to require the discovery of policy or other information about a host ("site-wide metadata") before making a request. For example, the Robots Exclusion Protocol <http://www.robotstxt.org/> specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-agents how to discover privacy policy beforehand.

基于Web的协议越来越普遍地要求在发出请求之前发现有关主机的策略或其他信息（“站点范围的元数据”）。例如，机器人排除协议<http://www.robotstxt.org/>指定自动化流程获取访问资源权限的方式；同样，隐私偏好平台[W3C.REC-P3P-20020416]告诉用户代理如何事先发现隐私策略。

While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead (either in terms of client-perceived latency and/or deployment difficulties) associated with them often precludes their use in these scenarios.

虽然有几种方法可以访问每资源元数据（例如HTTP头、WebDAV的PROPFIND[RFC4918]），但与之相关的感知开销（无论是在客户端感知的延迟和/或部署困难方面）通常会妨碍它们在这些场景中的使用。

When this happens, it is common to designate a "well-known location" for such data, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated "well-known locations" and with pre-existing resources.

发生这种情况时，通常会为此类数据指定一个“已知位置”，以便轻松定位。然而，这种方法有可能与其他此类指定的“知名地点”和现有资源发生冲突的缺点。

To address this, this memo defines a path prefix in HTTP(S) URIs for these "well-known locations", "/.well-known/". Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites' URI space.

为了解决这个问题，本备忘录在HTTP（S）URI中为这些“已知位置”定义了路径前缀“/.well-known/”。未来需要为此类站点范围的元数据定义资源的规范可以注册它们的使用，以避免冲突并最大限度地减少对站点URI空间的影响。

1.1. Appropriate Use of Well-Known URIs

1.1. 正确使用众所周知的URI

There are a number of possible ways that applications could use Well-known URIs. However, in keeping with the Architecture of the World-Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended for general information retrieval or establishment of large URI namespaces on the Web. Rather, they are designed to facilitate discovery of information on a site when it isn't practical to use other mechanisms; for example, when discovering policy that needs to be evaluated before a resource is accessed, or when using multiple round-trips is judged detrimental to performance.

应用程序可以通过多种方式使用众所周知的URI。然而，与万维网的体系结构[W3C.REC-webarch-20041215]保持一致，众所周知的URI不用于一般信息检索或在Web上建立大型URI命名空间。相反，它们的设计是为了在不实际使用其他机制的情况下促进站点上信息的发现；例如，当发现在访问资源之前需要评估的策略时，或者当判断使用多个往返对性能有害时。

As such, the well-known URI space was created with the expectation that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata.

因此，创建众所周知的URI空间的目的是希望它将用于直接提供站点范围的策略信息和其他元数据（如果足够简洁），或提供对提供此类元数据的其他URI的引用。

2. Notational Conventions

2. 符号约定

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

3. Well-Known URIs

3. 众所周知的URI

A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", or another scheme that has explicitly been specified to use well-known URIs.

众所周知的URI是URI[RFC3986]，其路径组件以“/.well-known/”字符开头，其方案是“HTTP”、“HTTPS”或已明确指定使用众所周知的URI的其他方案。

Applications that wish to mint new well-known URIs MUST register them, following the procedures in Section 5.1.

希望创建新的知名URI的应用程序必须按照第5.1节中的步骤进行注册。

For example, if an application registers the name 'example', the corresponding well-known URI on 'http://www.example.com/' would be 'http://www.example.com/.well-known/example'.

例如，如果一个应用程序注册了名称“example”，则相应的已知URI将位于http://www.example.com/“将是”http://www.example.com/.well-known/example'.

Registered names MUST conform to the segment-nz production in [RFC3986].

注册名称必须符合[RFC3986]中的新西兰段生产。

Note that this specification defines neither how to determine the authority to use for a particular context, nor the scope of the metadata discovered by dereferencing the well-known URI; both should be defined by the application itself.

注意，该规范既没有定义如何确定用于特定上下文的权限，也没有定义通过取消引用已知URI发现的元数据的范围；两者都应由应用程序本身定义。

Typically, a registration will reference a specification that defines the format and associated media type to be obtained by dereferencing the well-known URI.

通常，注册将引用一个规范，该规范定义了通过取消引用已知URI获得的格式和相关媒体类型。

It MAY also contain additional information, such as the syntax of additional path components, query strings and/or fragment identifiers to be appended to the well-known URI, or protocol-specific details (e.g., HTTP [RFC2616] method handling).

它还可以包含附加信息，例如附加路径组件的语法、要附加到众所周知的URI的查询字符串和/或片段标识符，或者特定于协议的细节（例如，HTTP[RFC2616]方法处理）。

Note that this specification does not define a format or media-type for the resource located at "/.well-known/" and clients should not expect a resource to exist at that location.

请注意，此规范没有为位于“/.well-known/”的资源定义格式或媒体类型，客户端不应期望该位置存在资源。

4. Security Considerations

4. 安全考虑

This memo does not specify the scope of applicability of metadata or policy obtained from a well-known URI, and does not specify how to discover a well-known URI for a particular application. Individual applications using this mechanism must define both aspects.

此备忘录未指定从已知URI获取的元数据或策略的适用范围，也未指定如何为特定应用程序发现已知URI。使用此机制的单个应用程序必须定义这两个方面。

Applications minting new well-known URIs, as well as administrators deploying them, will need to consider several security-related issues, including (but not limited to) exposure of sensitive data, denial-of-service attacks (in addition to normal load issues), server and client authentication, vulnerability to DNS rebinding attacks, and attacks where limited access to a server grants the ability to affect how well-known URIs are served.

应用新的已知URI，以及部署它们的管理员，将需要考虑几个安全相关问题，包括（但不限于）敏感数据的暴露、拒绝服务攻击（除了正常负载问题）、服务器和客户端认证、DNS重新绑定攻击的脆弱性、以及对服务器的有限访问使其能够影响已知URI的服务方式的攻击。

5. IANA Considerations

5. IANA考虑

5.1. The Well-Known URI Registry

5.1. 众所周知的URI注册表

This document establishes the well-known URI registry.

本文档建立了众所周知的URI注册表。

Well-known URIs are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.

众所周知的URI是根据一名或多名指定专家（由IESG或其代表任命）的建议注册的，并附有所需的规范（使用[RFC5226]中的术语）。但是，为了允许在发布前分配值，指定专家可在确信此类规范将发布后批准注册。

Registration requests should be sent to the wellknown-uri-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for well-known URI: example").

注册请求应发送到众所周知的uri-review@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“请求众所周知的URI:示例”）。

Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the

在14天期限过去之前，指定专家将批准或拒绝注册请求，并将该决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何作出拒绝的建议

request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution.

请求成功。超过21天未确定的注册请求可提请IESG注意（使用iesg@iesg.org邮件列表）以供解决。

5.1.1. Registration Template

5.1.1. 注册模板

URI suffix: The name requested for the well-known URI, relative to "/.well-known/"; e.g., "example".

URI后缀：为已知URI请求的名称，相对于“/.well-known/”；e、例如，“例子”。

Change controller: For Standards-Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included.

更改控制器：对于标准跟踪RFC，请注明“IETF”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。

Specification document(s): Reference to the document that specifies the field, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required.

规范文档：对指定字段的文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的说明，但不是必需的。

Related information: Optionally, citations to additional documents containing further relevant information.

相关信息：可选地，引用包含进一步相关信息的其他文件。

6. References

6. 工具书类

6.1. Normative References

6.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。

6.2. Informative References

6.2. 资料性引用

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[RFC4918]Dusseault，L.，“用于Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。

[W3C.REC-P3P-20020416] Marchiori, M., "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", World Wide Web Consortium Recommendation REC-P3P-20020416, April 2002, <http://www.w3.org/TR/2002/ REC-P3P-20020416>.

[W3C.REC-P3P-20020416]Marchiori，M.“隐私偏好平台1.0（P3P1.0）规范”，万维网联盟建议REC-P3P-20020416，2002年4月<http://www.w3.org/TR/2002/ REC-P3P-20020416>。

[W3C.REC-webarch-20041215] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", World Wide Web Consortium Recommendation REC- webarch-20041215, December 2004, <http:// www.w3.org/TR/2004/REC-webarch-20041215>.

[W3C.REC-webarch-20041215]Jacobs，I.和N.Walsh，“万维网的体系结构，第一卷”，万维网联盟建议REC-webarch-20041215，2004年12月，<http://www.w3.org/TR/2004/REC-webarch-20041215>。

Appendix A. Acknowledgements

附录A.确认书

We would like to acknowledge the contributions of everyone who provided feedback and use cases for this document; in particular, Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra, Breno de Medeiros, John Panzer, and Drummond Reed. However, they are not responsible for errors and omissions.

我们要感谢为本文件提供反馈和用例的每个人的贡献；特别是菲尔·阿彻、德克·巴尔芬兹、亚当·巴特、蒂姆·布雷、布赖恩·伊顿、布拉德·菲茨帕特里克、乔·格雷戈里奥、保罗·霍夫曼、巴里·莱巴、阿肖克·马尔霍特拉、布伦诺·德·梅德罗斯、约翰·潘泽和德拉蒙德·里德。但是，他们不对错误和遗漏负责。

Appendix B. Frequently Asked Questions

附录B.常见问题

1. Aren't well-known locations bad for the Web?

1. 众所周知的地点对网络不好吗？

They are, but for various reasons -- both technical and social -- they are commonly used and their use is increasing. This memo defines a "sandbox" for them, to reduce the risks of collision and to minimise the impact upon pre-existing URIs on sites.

是的，但由于各种原因——包括技术和社会原因——它们被广泛使用，而且使用量正在增加。本备忘录为它们定义了一个“沙箱”，以降低冲突风险，并将对站点上预先存在的URI的影响降至最低。

2. Why /.well-known?

2. 为什么，众所周知？

It's short, descriptive, and according to search indices, not widely used.

它是简短的，描述性的，并且根据搜索索引，没有被广泛使用。

3. What impact does this have on existing mechanisms, such as P3P and robots.txt?

3. 这对现有机制（如P3P和robots.txt）有什么影响？

None, until they choose to use this mechanism.

无，除非他们选择使用此机制。

4. Why aren't per-directory well-known locations defined?

4. 为什么没有定义每个目录的已知位置？

Allowing every URI path segment to have a well-known location (e.g., "/images/.well-known/") would increase the risks of colliding with a pre-existing URI on a site, and generally these solutions are found not to scale well, because they're too "chatty".

允许每个URI路径段都有一个众所周知的位置（例如“/images/.well-known/”）会增加与站点上预先存在的URI发生冲突的风险，并且通常会发现这些解决方案无法很好地扩展，因为它们太“健谈”。

Authors' Addresses

作者地址

Mark Nottingham

马克诺丁汉

   EMail: mnot@mnot.net
   URI:   http://www.mnot.net/

   EMail: mnot@mnot.net
   URI:   http://www.mnot.net/

Eran Hammer-Lahav

埃兰·哈默·拉哈夫

   EMail: eran@hueniverse.com
   URI:   http://hueniverse.com/

   EMail: eran@hueniverse.com
   URI:   http://hueniverse.com/