Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8615 May 2019
Obsoletes: 5785
Updates: 7230, 7595
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8615 May 2019
Obsoletes: 5785
Updates: 7230, 7595
Category: Standards Track
ISSN: 2070-1721
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/”。
In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.
在这样做时，它淘汰了RFC 5785，并更新RFC 7230中定义的URI方案以保留该空间。它还更新了RFC7595，以跟踪在其注册表中支持知名URI的URI方案。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8615.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8615.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4.1. Protecting Well-Known Resources . . . . . . . . . . . . . 6
4.2. Interaction with Web Browsing . . . . . . . . . . . . . . 6
4.3. Scoping Applications . . . . . . . . . . . . . . . . . . 7
4.4. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 8
5.2. The Uniform Resource Identifier (URI) Schemes Registry . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 12
Appendix B. Changes from RFC 5785 . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4.1. Protecting Well-Known Resources . . . . . . . . . . . . . 6
4.2. Interaction with Web Browsing . . . . . . . . . . . . . . 6
4.3. Scoping Applications . . . . . . . . . . . . . . . . . . 7
4.4. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 8
5.2. The Uniform Resource Identifier (URI) Schemes Registry . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 12
Appendix B. Changes from RFC 5785 . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
Some applications on the Web require the discovery of information about an origin [RFC6454] (sometimes called "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 [P3P] tells user agents how to discover privacy policy before interacting with an origin server.
Web上的某些应用程序需要在发出请求之前发现有关源[RFC6454]（有时称为“站点范围的元数据”）的信息。例如，机器人排除协议(http://www.robotstxt.org)指定自动化流程获取访问资源权限的方式；同样，隐私偏好平台[P3P]告诉用户代理如何在与源服务器交互之前发现隐私策略。
While there are several ways to access per-resource metadata (e.g., HTTP header fields, PROPFIND in Web Distributed Authoring and Versioning (WebDAV) [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头字段、Web分布式创作和版本控制（WebDAV）[RFC4918]中的PROPFIND），但与之相关的感知开销（无论是客户端感知的延迟还是/或部署困难）通常会妨碍它们在这些场景中的使用。
At the same time, it has become more popular to use HTTP as a substrate for non-Web protocols. Sometimes, such protocols need a way to locate one or more resources on a given host.
同时，使用HTTP作为非Web协议的基础已变得越来越流行。有时，此类协议需要一种方法来定位给定主机上的一个或多个资源。
When this happens, one solution is to designate a "well-known location" for data or services related to the origin overall, 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 resources that the origin has created (or wishes to create). Furthermore, defining well-known locations usurps the origin's control over its own URI space [RFC7320].
当这种情况发生时，一种解决方案是为与源站整体相关的数据或服务指定一个“已知位置”，以便可以轻松地定位它。然而，这种方法的缺点是有可能与其他此类指定的“知名地点”以及与原产地已创建（或希望创建）的资源发生碰撞。此外，定义已知位置会篡夺源站对其自己的URI空间的控制权[RFC7320]。
To address these uses, this memo reserves a path prefix in HTTP, HTTPS, WebSocket (WS), and Secure WebSocket (WSS) URIs for these "well-known locations", "/.well-known/". Future specifications that need to define a resource for such metadata can register their use to avoid collisions and minimise impingement upon origins' URI space.
为了解决这些使用问题，本备忘录在HTTP、HTTPS、WebSocket（WS）和Secure WebSocket（WSS）URI中为这些“已知位置”和“/.well-known/”保留路径前缀。未来需要为此类元数据定义资源的规范可以注册它们的使用，以避免冲突并最大限度地减少对源URI空间的影响。
Well-known URIs can also be used with other URI schemes, but only when those schemes' definitions explicitly allow it.
众所周知的URI也可以与其他URI方案一起使用，但只有在这些方案的定义明确允许的情况下。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/", provided that the scheme is explicitly defined to support well-known URIs.
众所周知的URI是一个URI[RFC3986]，其路径组件以字符“/.well-known/”开头，前提是该方案被明确定义为支持众所周知的URI。
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'.
This specification updates the "http" [RFC7230] and "https" [RFC7230] schemes to support well-known URIs. Other existing schemes can use the appropriate process for updating their definitions; for example, [RFC8307] does so for the "ws" and "wss" schemes. The "Uniform Resource Identifier (URI) Schemes" registry tracks which schemes support well-known URIs; see Section 5.2.
本规范更新了“http”[RFC7230]和“https”[RFC7230]方案，以支持众所周知的URI。其他现有方案可采用适当的程序更新其定义；例如，[RFC8307]对“ws”和“wss”方案是这样做的。“统一资源标识符（URI）方案”注册表跟踪哪些方案支持众所周知的URI；见第5.2节。
Applications that wish to mint new well-known URIs MUST register them, following the procedures in Section 5.1, subject to the following requirements.
希望创建新的知名URI的应用程序必须按照第5.1节中的程序进行注册，并符合以下要求。
Registered names MUST conform to the "segment-nz" production in [RFC3986]. This means they cannot contain the "/" character.
注册名称必须符合[RFC3986]中的“新西兰段”生产。这意味着它们不能包含“/”字符。
Registered names for a specific application SHOULD be correspondingly precise; "squatting" on generic terms is not encouraged. For example, if the Example application wants a well-known location for metadata, an appropriate registered name might be "example-metadata" or even "example.com-metadata", not "metadata".
特定应用的注册名称应相应准确；不鼓励泛指“蹲坐”。例如，如果示例应用程序需要元数据的已知位置，则适当的注册名称可能是“示例元数据”甚至是“example.com元数据”，而不是“元数据”。
At a minimum, a registration will reference a specification that defines the format and associated media type(s) to be obtained by dereferencing the well-known URI, along with the URI scheme(s) that the well-known URI can be used with. If no URI schemes are explicitly specified, "http" and "https" are assumed.
至少，注册将引用一个规范，该规范定义了通过解引用已知URI获得的格式和相关媒体类型，以及该已知URI可与之一起使用的URI方案。如果没有明确指定URI方案，则假定为“http”和“https”。
Typically, applications will use the default port for the given scheme; if an alternative port is used, it MUST be explicitly specified by the application in question.
通常，应用程序将使用给定方案的默认端口；如果使用替代端口，则必须由相关应用程序明确指定。
Registrations 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 [RFC7231] method handling).
注册还可以包含附加信息，例如附加到众所周知的URI的附加路径组件、查询字符串和/或片段标识符的语法，或特定于协议的细节（例如，HTTP[RFC7231]方法处理）。
Note that this specification defines neither how to determine the hostname to use to find the well-known URI for a particular application, nor the scope of the metadata discovered by dereferencing the well-known URI; both should be defined by the application itself.
请注意，该规范既没有定义如何确定用于查找特定应用程序的已知URI的主机名，也没有定义通过取消引用已知URI而发现的元数据的范围；两者都应由应用程序本身定义。
Also, 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/”的资源定义格式或媒体类型，客户端不应期望该位置存在资源。
Well-known URIs are rooted in the top of the path's hierarchy; they are not well-known by definition in other parts of the path. For example, "/.well-known/example" is a well-known URI, whereas "/foo/.well-known/example" is not.
众所周知的URI植根于路径层次结构的顶部；根据定义，它们在路径的其他部分并不广为人知。例如，“/.well-known/example”是一个众所周知的URI，而“/foo/.well-known/example”不是。
See also Section 4 for Security Considerations regarding well-known locations.
关于知名地点的安全注意事项，另见第4节。
The "Well-Known URIs" registry is located at <https://www.iana.org/assignments/well-known-uris/>. Registration requests can be made by following the instructions located there or by sending an email to the <wellknown-uri-review@ietf.org> mailing list.
“众所周知的URI”注册表位于<https://www.iana.org/assignments/well-known-uris/>. 注册请求可以按照此处的说明进行，也可以通过向<wellknown uri]发送电子邮件进行-review@ietf.org>邮件列表。
Registration requests consist of at least the following information:
注册请求至少包含以下信息：
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., email 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。也可以包括相关章节的说明，但不是必需的。
Status: One of "permanent" or "provisional". See guidance below.
状态：“永久”或“临时”之一。见下面的指南。
Related information: Optionally, citations to additional documents containing further relevant information.
相关信息：可选地，引用包含进一步相关信息的其他文件。
General requirements for registered values are described in Section 3.
注册价值的一般要求见第3节。
Values defined by Standards Track RFCs and other open standards (in the sense of [RFC2026], Section 7.1.1) have a status of "permanent". Other values can also be registered as permanent, if the experts find that they are in use, in consultation with the community. Other values should be registered as "provisional".
标准跟踪RFC和其他开放标准（在[RFC2026]第7.1.1节的意义上）定义的值具有“永久”状态。如果专家与社区协商发现其他价值观正在使用，也可以将其注册为永久性价值观。其他值应登记为“临时值”。
Provisional entries can be removed by the experts if -- in consultation with the community -- the experts find that they are not in use. The experts can change a provisional entry's status to permanent; in doing so, the experts should consider how widely used a value is and consult the community beforehand.
如果专家在与社区协商后发现临时条目未被使用，则可以将其删除。专家可以将临时条目的状态更改为永久条目；在这样做时，专家们应该考虑如何广泛使用价值，并事先咨询社区。
Note that "consult the community" above refers to those responsible for the URI scheme(s) in question. Generally, this would take place on the mailing list(s) of the appropriate Working Group(s) (possibly concluded), or on <art@ietf.org> if no such list exists.
请注意，上面的“咨询社区”是指负责所讨论的URI方案的人员。通常情况下，这将发生在相应工作组（可能已结束）的邮件列表上，或<art@ietf.org>如果不存在这样的清单。
Well-known URIs can be registered by third parties (including the expert(s)), if the expert(s) determine that an unregistered well-known URI is widely deployed and not likely to be registered in a timely manner otherwise. Such registrations still are subject to the requirements defined, including the need to reference a specification.
如果第三方（包括专家）确定广泛部署了未注册的众所周知的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
应用新的已知URI，以及部署它们的管理员，将需要考虑几个安全相关问题，包括（但不限于）敏感数据的暴露、拒绝服务攻击（除了正常负载问题）、服务器。
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.
客户端身份验证、DNS重新绑定攻击的漏洞，以及对服务器的访问受限会影响知名URI的服务方式的攻击。
[RFC3552] contains some examples of potential security considerations that may be relevant to application protocols and administrators deploying them.
[RFC3552]包含一些可能与应用程序协议和部署它们的管理员相关的潜在安全注意事项示例。
Because well-known locations effectively represent the entire origin, server operators should appropriately control the ability to write to them. This is especially true when more than one entity is co-located on the same origin. Even for origins that are controlled by and represent a single entity, due care should be taken to assure that write access to well-known locations is not granted unwittingly, either externally through server configuration or locally through implementation permissions (e.g., on a filesystem).
因为众所周知的位置有效地代表了整个源站，所以服务器操作员应该适当地控制对它们的写入能力。当多个实体位于同一来源地时，情况尤其如此。即使是由单个实体控制并代表单个实体的源，也应注意确保不会无意中授予对已知位置的写访问权，无论是通过服务器配置外部还是通过实现权限（例如，在文件系统上）本地授予。
Applications using well-known URIs for "http" or "https" URLs need to be aware that well-known resources will be accessible to Web browsers, and therefore are able to be manipulated by content obtained from other parts of that origin. If an attacker is able to inject content (e.g., through a Cross-Site Scripting vulnerability), they will be able to make potentially arbitrary requests to the well-known resource.
为“http”或“https”URL使用已知URI的应用程序需要知道，Web浏览器可以访问已知资源，因此可以通过从该来源的其他部分获取的内容进行操作。如果攻击者能够注入内容（例如，通过跨站点脚本漏洞），他们将能够向已知资源发出潜在的任意请求。
HTTP and HTTPS also use origins as a security boundary for many other mechanisms, including (but not limited to) cookies [RFC6265], Web Storage [WEBSTORAGE], and various capabilities.
HTTP和HTTPS还使用源代码作为许多其他机制的安全边界，包括（但不限于）Cookie[RFC6265]、Web存储[WEBSTORAGE]和各种功能。
An application that defines well-known locations should not assume that it has sole access to these mechanisms or that it is the only application using the origin. Depending on the nature of the application, mitigations can include:
定义已知位置的应用程序不应假定它只能访问这些机制，或者它是使用源代码的唯一应用程序。根据应用程序的性质，缓解措施可包括：
o Encrypting sensitive information
o 加密敏感信息
o Allowing flexibility in the use of identifiers (e.g., cookie names) to avoid collisions with other applications
o 允许灵活使用标识符（例如cookie名称），以避免与其他应用程序发生冲突
o Using the 'HttpOnly' flag on cookies to assure that cookies are not exposed to browser scripting languages [RFC6265]
o 在cookie上使用“HttpOnly”标志以确保cookie不会暴露于浏览器脚本语言[RFC6265]
o Using the 'Path' parameter on cookies to assure that they are not available to other parts of the origin [RFC6265]
o 在Cookie上使用“Path”参数以确保它们不可用于源站的其他部分[RFC6265]
o Using X-Content-Type-Options: nosniff [FETCH] to assure that content under attacker control can't be coaxed into a form that is interpreted as active content by a Web browser
o 使用X-Content-Type-Options:nosniff[FETCH]确保攻击者控制下的内容不会被诱骗成被Web浏览器解释为活动内容的形式
Other good practices include:
其他良好做法包括：
o Using an application-specific media type in the Content-Type header field, and requiring clients to fail if it is not used
o 在内容类型标头字段中使用特定于应用程序的媒体类型，如果未使用，则要求客户端失败
o Using Content-Security-Policy [CSP] to constrain the capabilities of active content (such as HTML [HTML5]), thereby mitigating Cross-Site Scripting attacks
o 使用内容安全策略[CSP]约束活动内容（如HTML[HTML5]）的功能，从而减轻跨站点脚本攻击
o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data in URLs from being leaked in the Referer request header field
o 使用Referer Policy[Referer-Policy]防止URL中的敏感数据在Referer请求头字段中泄漏
o Avoiding use of compression on any sensitive information (e.g., authentication tokens, passwords), as the scripting environment offered by Web browsers allows an attacker to repeatedly probe the compression space; if the attacker has access to the path of the communication, they can use this capability to recover that information.
o 避免对任何敏感信息（例如，身份验证令牌、密码）使用压缩，因为Web浏览器提供的脚本环境允许攻击者重复探测压缩空间；如果攻击者可以访问通信路径，他们可以使用此功能恢复该信息。
This memo does not specify the scope of applicability for the information obtained from a well-known URI, and does not specify how to discover a well-known URI for a particular application.
此备忘录没有指定从已知URI获得的信息的适用范围，也没有指定如何为特定应用程序发现已知URI。
Individual applications using this mechanism must define both aspects; if this is not specified, security issues can arise from implementation deviations and confusion about boundaries between applications.
使用此机制的单个应用程序必须定义这两个方面；如果未指定此项，则实现偏差和应用程序之间边界的混淆可能会导致安全问题。
Applying metadata discovered in a well-known URI to resources other than those co-located on the same origin risks administrative as well as security issues. For example, allowing "https://example.com/.well-known/example" to apply policy to "https://department.example.com", "https://www.example.com", or even "https://www.example.com:8000" assumes a relationship between hosts where there might be none, thereby giving control to a potential attacker.
将在已知URI中发现的元数据应用于位于同一来源上的资源以外的资源会带来管理和安全问题。例如，允许“https://example.com/.well-known/example“将策略应用于”https://department.example.com", "https://www.example.com“，甚至”https://www.example.com:8000“假设主机之间可能没有关系，从而控制潜在的攻击者。
Likewise, specifying that a well-known URI on a particular hostname is to be used to bootstrap a protocol can cause a large number of undesired requests. For example, if a well-known HTTPS URI is used to find policy about a separate service such as email, it can result
同样，指定特定主机名上的已知URI用于引导协议可能会导致大量不希望的请求。例如，如果使用一个众所周知的HTTPS URI来查找有关单独服务（如电子邮件）的策略，则可能会导致
in a flood of requests to Web servers, even if they don't implement the well-known URI. Such undesired requests can resemble a denial-of-service attack.
在对Web服务器的大量请求中，即使它们没有实现众所周知的URI。这种不受欢迎的请求可能类似于拒绝服务攻击。
Applications using well-known locations should consider that some server administrators might be unaware of their existence (especially on operating systems that hide directories whose names begin with "."). This means that if an attacker has write access to the .well-known directory, they would be able to control its contents, possibly without the administrator realising it.
使用众所周知的位置的应用程序应该考虑到一些服务器管理员可能不知道它们的存在（特别是在隐藏名称为“.”的目录的操作系统上）。这意味着，如果攻击者具有对.well-known目录的写访问权限，他们将能够控制其内容，管理员可能不会意识到这一点。
This specification updates the registration procedures for the "Well-Known URI" registry, first defined in [RFC5785]; see Section 3.1.
本规范更新了[RFC5785]中首次定义的“众所周知的URI”注册表的注册程序；见第3.1节。
Well-known URIs are registered on the advice of one or more experts, with a Specification Required (using terminology from [RFC8126]).
众所周知的URI是根据一位或多位专家的建议注册的，需要一个规范（使用[RFC8126]中的术语）。
The experts' primary considerations in evaluating registration requests are:
专家们在评估登记申请时的主要考虑因素是：
o Conformance to the requirements in Section 3
o 符合第3节的要求
o The availability and stability of the specifying document
o 指定文档的可用性和稳定性
o The considerations outlined in Section 4
o 第4节概述的注意事项
IANA will direct the senders of any incoming registry requests to this document and, if defined, the processes established by the expert(s); typically, this will mean referring them to the registry Web page.
IANA将指导任何传入注册请求的发送者使用本文件，如果有定义，还将指导专家建立的流程；通常，这意味着将它们引用到注册表网页。
Per this document, IANA has:
根据本文件，IANA有：
o Updated the registration procedure to Specification Required.
o 根据要求更新注册程序。
o Added a "Status" column to the registry and marked all of the existing registrations as "permanent".
o 在注册表中添加“状态”列，并将所有现有注册标记为“永久”。
This specification adds a field to the registration template of the "Uniform Resource Identifier (URI) Schemes" registry, with the name "Well-Known URI Support" and a default value of "-".
本规范在“统一资源标识符（URI）方案”注册表的注册模板中添加了一个字段，名称为“众所周知的URI支持”，默认值为“-”。
If a URI scheme explicitly has been specified to use well-known URIs as per Section 3, the value changes to a reference to that specification. Initial values not equal to "-" are given in Table 1.
如果已根据第3节明确指定URI方案使用已知URI，则该值将更改为对该规范的引用。表1给出了不等于“-”的初始值。
+------------+------------------------+
| URI Scheme | Well-Known URI Support |
+------------+------------------------+
| coap | [RFC7252] |
| coap+tcp | [RFC8323] |
| coap+ws | [RFC8323] |
| coaps | [RFC7252] |
| coaps+tcp | [RFC8323] |
| coaps+ws | [RFC8323] |
| http | [RFC8615] |
| https | [RFC8615] |
| ws | [RFC8307] |
| wss | [RFC8307] |
+------------+------------------------+
+------------+------------------------+
| URI Scheme | Well-Known URI Support |
+------------+------------------------+
| coap | [RFC7252] |
| coap+tcp | [RFC8323] |
| coap+ws | [RFC8323] |
| coaps | [RFC7252] |
| coaps+tcp | [RFC8323] |
| coaps+ws | [RFC8323] |
| http | [RFC8615] |
| https | [RFC8615] |
| ws | [RFC8307] |
| wss | [RFC8307] |
+------------+------------------------+
Table 1: Rows in URI Scheme Registry with Nonempty New Column
表1:URI方案注册表中具有非空新列的行
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<https://www.rfc-editor.org/info/rfc6454>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[CSP] West, M., "Content Security Policy Level 3", World Wide Web Consortium WD WD-CSP3-20160913, September 2016, <https://www.w3.org/TR/2016/WD-CSP3-20160913>.
[CSP]West，M.，“内容安全策略级别3”，万维网联盟WD-CSP3-20160913，2016年9月<https://www.w3.org/TR/2016/WD-CSP3-20160913>.
[FETCH] WHATWG, "Fetch - Living Standard", <https://fetch.spec.whatwg.org>.
[FETCH]WHATWG，“FETCH-生活标准”<https://fetch.spec.whatwg.org>.
[HTML5] WHATWG, "HTML - Living Standard", <https://html.spec.whatwg.org>.
[HTML5]WHATWG，“HTML-生活标准”<https://html.spec.whatwg.org>.
[P3P] 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>.
[P3P]Marchiori，M.，“隐私偏好平台1.0（P3P1.0）规范”，万维网联盟建议REC-P3P-20020416，2002年4月<http://www.w3.org/TR/2002/REC-P3P-20020416>.
[REFERRER-POLICY] Eisinger, J. and E. Stark, "Referrer Policy", World Wide Web Consortium CR CR-referrer-policy-20170126, January 2017, <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[REFERRER-POLICY]Eisinger，J.和E.Stark，“REFERRER POLICY”，万维网联盟CR-REFERRER-POLICY-20170126，2017年1月<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，DOI 10.17487/RFC2026，1996年10月<https://www.rfc-editor.org/info/rfc2026>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<https://www.rfc-editor.org/info/rfc3552>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.
[RFC4918]Dusseault，L.，Ed.“Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC 4918，DOI 10.17487/RFC4918，2007年6月<https://www.rfc-editor.org/info/rfc4918>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<https://www.rfc-editor.org/info/rfc5785>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<https://www.rfc-editor.org/info/rfc6265>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <https://www.rfc-editor.org/info/rfc7320>.
[RFC7320]诺丁汉，M.，“URI设计和所有权”，BCP 190，RFC 7320，DOI 10.17487/RFC7320，2014年7月<https://www.rfc-editor.org/info/rfc7320>.
[RFC8307] Bormann, C., "Well-Known URIs for the WebSocket Protocol", RFC 8307, DOI 10.17487/RFC8307, January 2018, <https://www.rfc-editor.org/info/rfc8307>.
[RFC8307]Bormann，C.，“WebSocket协议的著名URI”，RFC 8307，DOI 10.17487/RFC8307，2018年1月<https://www.rfc-editor.org/info/rfc8307>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323]Bormann，C.，Lemay，S.，Tschofenig，H.，Hartke，K.，Silverajan，B.，和B.Raymor，Ed.，“TCP，TLS和WebSocket上的CoAP（受限应用协议）”，RFC 8323，DOI 10.17487/RFC83232018年2月<https://www.rfc-editor.org/info/rfc8323>.
[WEBSTORAGE] Hickson, I., "Web Storage (Second Edition)", World Wide Web Consortium Recommendation REC-webstorage-20160419, April 2016, <http://www.w3.org/TR/2016/REC-webstorage-20160419>.
[WEBSTORAGE]Hickson，I.，“Web存储（第二版）”，万维网联盟建议REC-WEBSTORAGE-20160419，2016年4月<http://www.w3.org/TR/2016/REC-webstorage-20160419>.
Aren't well-known locations bad for the Web? They are, but for various reasons -- both technical and social -- they are sometimes necessary. This memo defines a "sandbox" for them, to reduce the risks of collision and to minimise the impact upon preexisting URIs on sites.
众所周知的地点对网络不好吗？是的，但出于各种原因——包括技术和社会原因——它们有时是必要的。本备忘录为他们定义了一个“沙箱”，以降低冲突风险，并将对站点上先前存在的URI的影响降至最低。
Why "/.well-known?" It's short, descriptive, and according to search indices, not widely used.
为什么“/.well-known？”它简短、描述性，而且根据搜索索引，没有广泛使用。
What impact does this have on existing mechanisms, such as P3P and robots.txt? None, until they choose to use this mechanism.
这对现有机制（如P3P和robots.txt）有什么影响？无，除非他们选择使用此机制。
Why aren't per-directory well-known locations defined? Allowing every URI path segment to have a well-known location (e.g., "/images/.well-known/") would increase the risks of colliding with a preexisting URI on a site, and generally these solutions are found not to scale well because they're too "chatty".
为什么没有定义每个目录的已知位置？允许每个URI路径段都有一个众所周知的位置（例如“/images/.well-known/”）会增加与站点上先前存在的URI发生冲突的风险，并且通常会发现这些解决方案由于过于“闲聊”而无法很好地扩展。
o Allowed non-Web well-known locations
o 允许的非Web已知位置
o Adjusted IANA instructions
o 调整IANA指令
o Updated references
o 更新的参考资料
o Made various other clarifications
o 作出了各种其他澄清
o Tracked supporting schemes in the "Uniform Resource Identifier (URI) Schemes" registry
o 在“统一资源标识符（URI）方案”注册表中跟踪支持方案
Author's Address
作者地址
Mark Nottingham
马克诺丁汉
Email: mnot@mnot.net
URI: https://www.mnot.net/
Email: mnot@mnot.net
URI: https://www.mnot.net/