Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 8631 July 2019
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 8631 July 2019
Category: Informational
ISSN: 2070-1721
Link Relation Types for Web Services
Web服务的链接关系类型
Abstract
摘要
Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.
Web上提供的许多资源是由一个特定服务提供商管理的上下文中提供的资源集的一部分。通常，这些资源集被称为“Web服务”或“Web API”。本规范定义了链接关系，这些链接关系表示从Web服务或API到为这些资源提供文档、描述、元数据或状态信息的资源之间的关系。文档主要面向人类用户，而描述主要面向自动化用户。元数据提供有关服务上下文的信息。该规范还定义了一个链接关系，以标识用于表示服务状态信息的状态资源。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc8631.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8631.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Web Services . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Documenting Web Services . . . . . . . . . . . . . . . . 5
3.2. Describing Web Services . . . . . . . . . . . . . . . . . 5
3.3. Unified Documentation/Description . . . . . . . . . . . . 5
4. Link Relations for Web Services . . . . . . . . . . . . . . . 5
4.1. The service-doc Link Relation Type . . . . . . . . . . . 6
4.2. The service-desc Link Relation Type . . . . . . . . . . . 6
4.3. The service-meta Link Relation Type . . . . . . . . . . . 6
5. Web Service Status Resources . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. Link Relation Type: service-doc . . . . . . . . . . . . . 7
6.2. Link Relation Type: service-desc . . . . . . . . . . . . 7
6.3. Link Relation Type: service-meta . . . . . . . . . . . . 8
6.4. Link Relation Type: status . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Web Services . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Documenting Web Services . . . . . . . . . . . . . . . . 5
3.2. Describing Web Services . . . . . . . . . . . . . . . . . 5
3.3. Unified Documentation/Description . . . . . . . . . . . . 5
4. Link Relations for Web Services . . . . . . . . . . . . . . . 5
4.1. The service-doc Link Relation Type . . . . . . . . . . . 6
4.2. The service-desc Link Relation Type . . . . . . . . . . . 6
4.3. The service-meta Link Relation Type . . . . . . . . . . . 6
5. Web Service Status Resources . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. Link Relation Type: service-doc . . . . . . . . . . . . . 7
6.2. Link Relation Type: service-desc . . . . . . . . . . . . 7
6.3. Link Relation Type: service-meta . . . . . . . . . . . . 8
6.4. Link Relation Type: status . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
One of the defining aspects of the Web is that it is possible to interact with Web resources without any prior knowledge of the specifics of the resource. Following the practices described in Web architecture [W3C.REC-webarch-20041215] by using URIs, HTTP, and media types, the Web's uniform interface allows interactions with resources without the more complex binding procedures often necessary with other approaches.
Web的一个定义方面是，在事先不知道资源的具体情况的情况下，可以与Web资源交互。按照Web架构[W3C.REC-webarch-20041215]中描述的实践，通过使用URI、HTTP和媒体类型，Web的统一接口允许与资源进行交互，而无需其他方法通常需要的更复杂的绑定过程。
Many resources on the Web are provided as part of a set of resources that are referred to as a "Web service" or a "Web API". In many cases, these services or APIs are defined and managed as a whole, and it may be desirable for clients to be able to discover this service information.
Web上的许多资源是作为一组资源的一部分提供的，这些资源称为“Web服务”或“Web API”。在许多情况下，这些服务或API是作为一个整体定义和管理的，客户机可能希望能够发现这些服务信息。
Service information that provides information on how to use service resources can be broadly separated into two categories: One category primarily targets human users and often uses generic representations for human readable documents, such as HTML or PDF. The other category is structured information that follows a more formalized description model and is primarily intended for consumption by machines -- for example, tools and code libraries.
提供有关如何使用服务资源的信息的服务信息可以大致分为两类：一类主要针对人类用户，通常使用人类可读文档的通用表示，如HTML或PDF。另一类是结构化信息，它遵循一种更为形式化的描述模型，主要供机器使用，例如工具和代码库。
In the context of this memo, the human-oriented variant is referred to as "documentation", and the machine-oriented variant is referred to as "description".
在本备忘录的上下文中，面向人的变体称为“文档”，面向机器的变体称为“说明”。
These two categories are not necessarily mutually exclusive, as representations have been proposed that are intended for both human consumption and interpretation by machine clients. In addition, a typical pattern for service documentation/descriptions is that there is human-oriented, high-level documentation that is intended to put a service in context and explain the general model, which is complemented by machine-level descriptions that are intended as detailed technical descriptions of the service. These two resources could be interlinked, but since they are intended for different audiences, it can make sense to provide entry points for both of them.
这两个类别不一定是相互排斥的，因为已经提出了用于人类消费和机器客户端解释的表示。此外，服务文档/描述的一种典型模式是，存在面向人的高级文档，旨在将服务置于上下文中并解释通用模型，该模型由机器级描述补充，机器级描述旨在作为服务的详细技术描述。这两种资源可以相互关联，但由于它们面向不同的受众，因此为它们提供切入点是有意义的。
In addition, while both documentation and descriptions may be provided as part of a Web service, there may be other information as well. Generally speaking, a Web service may have any metadata/ resources associated with it (with documentation and descriptions being two specific kinds of resources). If there is a way in which all of these metadata/resources can be represented, then it should be possible to find such a resource that provides access to general Web service metadata.
此外，虽然文档和描述都可以作为Web服务的一部分提供，但也可能有其他信息。一般来说，Web服务可能具有与其关联的任何元数据/资源（文档和描述是两种特定的资源）。如果有一种方式可以表示所有这些元数据/资源，那么应该可以找到这样一种资源来提供对通用Web服务元数据的访问。
In addition to these resources about mostly static aspects of a Web service, this memo also defines a link relation that allows providers of a Web service to link to a resource that represents status information about the service. This information often represents operational information that allows service consumers to retrieve information about "service health" and related issues.
除了这些关于Web服务的静态方面的资源外，此备忘录还定义了一个链接关系，允许Web服务的提供者链接到表示服务状态信息的资源。此信息通常表示允许服务使用者检索有关“服务运行状况”和相关问题的信息的操作信息。
This memo places no constraints on the specific representations used for all of these resources. It simply allows providers of a Web service to make the documentation, descriptions, metadata, and status of their services discoverable and defines link relations that serve that purpose.
本备忘录对用于所有这些资源的特定表示形式没有任何限制。它只允许Web服务的提供者发现其服务的文档、描述、元数据和状态，并定义用于此目的的链接关系。
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]所述进行解释。
"Web Services" or "Web APIs" (sometimes also referred to as "HTTP API" or "REST API") expose information and services on the Web. Following the principles of Web architecture [W3C.REC-webarch-20041215], they expose URI-identified resources, which are then accessed and transferred using a specific representation. Many services use representations that contain links, and these links are often typed links.
“Web服务”或“Web API”（有时也称为“HTTP API”或“REST API”）在Web上公开信息和服务。遵循Web架构的原则[W3C.REC-webarch-20041215]，它们公开URI标识的资源，然后使用特定的表示访问和传输这些资源。许多服务使用包含链接的表示，这些链接通常是类型化链接。
Using typed links, resources can identify relationship types to other resources. RFC 8288 [RFC8288] establishes a framework of registered link relation types, which are identified by simple strings and registered in an IANA registry. Any resource that supports typed links according to RFC 8288 can then use these identifiers to represent resource relationships on the Web without having to reinvent registered relation types.
使用类型化链接，资源可以识别与其他资源的关系类型。RFC 8288[RFC8288]建立了已注册链接关系类型的框架，这些类型由简单字符串标识，并在IANA注册表中注册。根据RFC 8288，任何支持类型化链接的资源都可以使用这些标识符来表示Web上的资源关系，而无需重新创建已注册的关系类型。
In recent years, Web services, as well as their documentation and description languages, have gained popularity due to the general popularity of the Web as a platform for providing information and services. However, the design of documentation and description languages varies according to a number of factors, such as the general application domain, the preferred application data model, and the preferred approach for exposing services.
近年来，由于Web作为提供信息和服务的平台的普遍普及，Web服务以及它们的文档和描述语言得到了普及。然而，文档和描述语言的设计根据许多因素而有所不同，例如通用应用程序域、首选应用程序数据模型和首选的服务公开方法。
This specification allows service providers to use a unified method to link to service documentation and/or descriptions. This link should not make any assumptions about the provided type of documentation and/or descriptions, so service providers can choose those that best fit their services and needs.
此规范允许服务提供商使用统一的方法链接到服务文档和/或描述。此链接不应对所提供的文档和/或描述类型进行任何假设，以便服务提供商可以选择最适合其服务和需求的文档和/或描述。
This specification also allows service providers to link to general service metadata. One part of the metadata may have links to documentation and/or description as well as other information about a service, such as deployment or operational information.
该规范还允许服务提供商链接到一般服务元数据。元数据的一部分可以链接到文档和/或描述以及有关服务的其他信息，例如部署或操作信息。
In the context of this specification, "documentation" refers to information that is primarily intended for human consumption. Typical representations of this kind of documentation are HTML and PDF.
在本规范的上下文中，“文档”是指主要用于人类消费的信息。这种文档的典型表示形式是HTML和PDF。
Documentation is often structured, but its structure depends on the structure of the service in question as well as the specific way in which the authors choose to present it.
文档通常是结构化的，但它的结构取决于所讨论的服务的结构以及作者选择的呈现方式。
In the context of this specification, "description" refers to information that is primarily intended for machine consumption. Typical representations are dictated by the technology underlying the service itself, which means that description formats in today's technology landscape are based on XML, JSON, Resource Description Framework (RDF), and a variety of other structured data models. In each of those technologies, there may be a variety of languages defined to serve the same general purpose of describing a Web service.
在本规范的上下文中，“说明”是指主要用于机器消耗的信息。典型的表示由服务本身的底层技术决定，这意味着当今技术环境中的描述格式基于XML、JSON、资源描述框架（RDF）和各种其他结构化数据模型。在这些技术中的每一种技术中，可能定义了多种语言，用于描述Web服务的相同通用目的。
Descriptions are always structured, but the structuring principles depend on the nature of the described service. For example, one of the earlier service description approaches, the Web Services Description Language (WSDL), uses "operations" as its core concept, which are essentially identical to function calls because the underlying model is based on the Remote Procedure Call (RPC) model. Other description languages for non-RPC approaches to services will use different structuring approaches, such as structuring service descriptions by URIs and/or URI patterns.
描述总是结构化的，但结构化原则取决于所描述服务的性质。例如，早期的服务描述方法之一Web服务描述语言（WSDL）使用“操作”作为其核心概念，这与函数调用基本相同，因为底层模型基于远程过程调用（RPC）模型。用于服务的非RPC方法的其他描述语言将使用不同的结构化方法，例如通过URI和/或URI模式结构化服务描述。
If service providers use an approach where there is no distinction between service documentation (Section 3.1) and service description (Section 3.2), then they may not feel the need to use two separate links. In such a case, an alternative approach is to use the previously defined "service" link relation type [RFC5023], which does not indicate whether it links to documentation or description and thus may be a better fit if no such differentiation is required.
如果服务提供商使用的方法在服务文档（第3.1节）和服务描述（第3.2节）之间没有区别，那么他们可能觉得不需要使用两个单独的链接。在这种情况下，另一种方法是使用先前定义的“服务”链接关系类型[RFC5023]，该类型不表示它是否链接到文档或描述，因此如果不需要这样的区分，可能更适合。
In order to allow Web services to represent the relation of individual resources to service documentation/description and metadata, this specification introduces and registers three new link relation types.
为了允许Web服务表示单个资源与服务文档/描述和元数据的关系，本规范引入并注册了三种新的链接关系类型。
The "service-doc" link relation type is used to represent the fact that a resource or a set of resources is documented at a specific URI. The target resource is expected to provide documentation that is primarily intended for human consumption.
“服务文档”链接关系类型用于表示一个资源或一组资源在特定URI中被记录的事实。预期目标资源将提供主要用于人类消费的文档。
The "service-desc" link relation type is used to represent the fact that a resource or a set of resources is described at a specific URI. The target resource is expected to provide a service description that is primarily intended for machine consumption. In many cases, it is provided in a representation that is consumed by tools, code libraries, or similar components.
“service desc”链接关系类型用于表示在特定URI中描述资源或资源集的事实。预期目标资源将提供主要用于机器消耗的服务描述。在许多情况下，它以工具、代码库或类似组件使用的表示形式提供。
The "service-meta" link relation type is used to link to available metadata for the service context of a resource. Service metadata is any kind of data that may be of interest to existing or potential service users, with documentation/description being only two possible facets of service metadata. The target resource is expected to provide a representation that is primarily intended for machine consumption. In many cases, it is provided in a representation that is consumed by tools, code libraries, or similar components.
“服务元”链接关系类型用于链接到资源的服务上下文的可用元数据。服务元数据是现有或潜在服务用户可能感兴趣的任何类型的数据，文档/描述只是服务元数据的两个可能方面。预期目标资源将提供主要用于机器消耗的表示。在许多情况下，它以工具、代码库或类似组件使用的表示形式提供。
Since service metadata can have many different purposes and use many different representations, it may make sense for representations using the "service-meta" link relation to offer additional hints about the specific kind or format of metadata that is being linked.
由于服务元数据可以有许多不同的用途，并使用许多不同的表示，因此使用“服务元数据”链接关系的表示可以提供有关正在链接的元数据的特定类型或格式的额外提示。
This definition of the "service-meta" link relation makes no specific assumptions about how these link hints will be represented, and the specific mechanism will depend on the context where the "service-meta" link relation is being used.
“服务元”链接关系的定义没有对如何表示这些链接提示做出具体假设，具体机制将取决于使用“服务元”链接关系的上下文。
One example is that a "service-desc" link may identify an OpenAPI description, which is supposed to be the machine-readable description of a Web API. A "service-meta" link may identify a resource that contains additional metadata about the Web API, such as labels that classify the API according to a labeling scheme and a privacy policy that makes statements about how the Web API manages personally identifiable information.
一个例子是，“服务描述”链接可以标识OpenAPI描述，该描述被认为是Web API的机器可读描述。“服务元”链接可以识别包含关于Web API的附加元数据的资源，例如根据标签方案对API进行分类的标签和对Web API如何管理个人可识别信息进行声明的隐私策略。
Web services providing access to one or more resources often are hosted and operated in an environment for which status information may be available. This information may be as simple as confirming that a service is operational, or it may provide additional information about different aspects of a service and/or a history of status information, possibly listing incidents and their resolution.
提供对一个或多个资源的访问的Web服务通常在状态信息可用的环境中托管和运行。该信息可以简单到确认服务可运行，也可以提供有关服务不同方面的附加信息和/或状态信息历史记录，可能列出事件及其解决方案。
The "status" link relation type can be used to link to such a status resource, allowing service consumers to retrieve information about a Web service's status. Such a link may not be available for and from all resources provided by a Web service -- only from key resources such as a Web service's metadata resource and/or a service's home resource (i.e., a resource analogous to the home page of a Web site).
“status”链接关系类型可用于链接到此类状态资源，从而允许服务使用者检索有关Web服务状态的信息。这种链接可能不适用于Web服务提供的所有资源，也不适用于Web服务提供的所有资源——仅适用于关键资源，如Web服务的元数据资源和/或服务的主资源（即，类似于Web站点主页的资源）。
This memo does not restrict the representation of a status resource in any way. It may be primarily focused on human or machine consumption or a combination of both. It may be a simple "traffic light" indicator for service health or a more sophisticated representation conveying more detailed information, such as service subsystems and/or a status history.
此备忘录不以任何方式限制状态资源的表示。它可能主要关注人或机器的消耗，或两者的结合。它可以是服务健康的简单“交通灯”指示器，也可以是传达更详细信息的更复杂表示，例如服务子系统和/或状态历史。
The link relation types below have been registered by IANA per Section 4.2 of RFC 8288 [RFC8288].
IANA已根据RFC 8288[RFC8288]第4.2节注册了以下链接关系类型。
Relation Name: service-doc
关系名称：服务单据
Description: Identifies service documentation for the context that is primarily intended for human consumption.
描述：标识主要用于人类消费的上下文的服务文档。
Reference: RFC 8631
参考：RFC 8631
Relation Name: service-desc
关系名称：服务描述
Description: Identifies service description for the context that is primarily intended for consumption by machines.
描述：标识主要供计算机使用的上下文的服务描述。
Reference: RFC 8631
参考：RFC 8631
Relation Name: service-meta
关系名称：服务元
Description: Identifies general metadata for the context that is primarily intended for consumption by machines.
描述：标识主要供计算机使用的上下文的通用元数据。
Reference: RFC 8631
参考：RFC 8631
Relation Name: status
关系名称：status
Description: Identifies a resource that represents the context's status.
描述：标识表示上下文状态的资源。
Reference: RFC 8631
参考：RFC 8631
Web service providers should be aware that service descriptions and documentation may be used by attackers to gain additional information about a service (particularly its implementation) and to test for known security issues. It may thus be advisable to restrict service descriptions and documentation to aspects of a service that are necessary and to exclude any details that are not necessary for using the service.
Web服务提供商应该知道，攻击者可能会使用服务描述和文档来获取有关服务（特别是其实现）的附加信息，并测试已知的安全问题。因此，建议将服务描述和文档限制在服务的必要方面，并排除使用服务不必要的任何细节。
Another potential security issue for Web service providers is that publishing service descriptions and documentation may generally allow clients (both malicious and otherwise) more automated and systematic access to a service. It may therefore be possible that more of a service's potential vulnerabilities are made easier to find and exploit or simply that a service might receive more load because it is accessed by automated clients.
Web服务提供商的另一个潜在安全问题是，发布服务描述和文档通常允许客户端（恶意或其他）更自动化和系统化地访问服务。因此，可能会使更多服务的潜在漏洞更容易被发现和利用，或者简单地说，服务可能会收到更多负载，因为它是由自动客户端访问的。
Web service consumers should be aware that service descriptions and documentation can be out of sync or simply incorrect. Blindly trusting service descriptions and documentation (particularly when descriptions are retrieved and interpreted programmatically) is not a safe practice. Web service consumers SHOULD always assume that service descriptions and documentation may be incorrect and SHOULD therefore be prepared to handle errors at runtime.
Web服务消费者应该知道服务描述和文档可能不同步或根本不正确。盲目信任服务描述和文档（特别是在以编程方式检索和解释描述时）不是一种安全的做法。Web服务使用者应始终假定服务描述和文档可能不正确，因此应准备在运行时处理错误。
[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>.
[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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]诺丁汉，M.，“网络链接”，RFC 8288，DOI 10.17487/RFC8288，2017年10月<https://www.rfc-editor.org/info/rfc8288>.
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, October 2007, <https://www.rfc-editor.org/info/rfc5023>.
[RFC5023]Gregorio，J.，Ed.和B.de hOra，Ed.，“原子出版协议”，RFC 5023，DOI 10.17487/RFC5023，2007年10月<https://www.rfc-editor.org/info/rfc5023>.
[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>.
Acknowledgements
致谢
Thanks to Mike Amundsen, Ben Campbell, Alissa Cooper, Oliver Gierke, Benjamin Kaduk, Sebastien Lambla, Darrell Miller, and Adam Roach for their comments and suggestions.
感谢迈克·阿蒙森、本·坎贝尔、艾莉莎·库珀、奥利弗·吉尔克、本杰明·卡杜克、塞巴斯蒂安·兰布拉、达雷尔·米勒和亚当·罗奇的评论和建议。
Author's Address
作者地址
Erik Wilde
埃里克·王尔德
Email: erik.wilde@dret.net
URI: http://dret.net/netdret/
Email: erik.wilde@dret.net
URI: http://dret.net/netdret/