Internet Engineering Task Force (IETF) J. Field
Request for Comments: 8322 Pivotal
Category: Standards Track S. Banghart
ISSN: 2070-1721 D. Waltermire
NIST
February 2018
Internet Engineering Task Force (IETF) J. Field
Request for Comments: 8322 Pivotal
Category: Standards Track S. Banghart
ISSN: 2070-1721 D. Waltermire
NIST
February 2018
Resource-Oriented Lightweight Information Exchange (ROLIE)
面向资源的轻量级信息交换（ROLIE）
Abstract
摘要
This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.
本文档定义了一种面向资源的安全自动化信息发布、发现和共享方法。使用这种方法，生产者可以发布、共享和交换软件描述符、安全事件、攻击指示器、软件漏洞、配置检查表和其他安全自动化信息的表示形式，作为web可寻址资源。此外，消费者和其他利益相关者可以根据需要访问和搜索这些安全信息，为受限内部使用或公共访问存储库建立快速和按需的信息交换网络。本规范扩展了Atom发布协议和Atom联合格式，以传输和共享安全自动化资源表示。
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/rfc8322.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8322.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 ....................................................3
2. Terminology .....................................................4
3. XML-Related Conventions .........................................5
3.1. XML Namespaces .............................................5
3.2. RELAX NG Compact Schema ....................................5
4. Background and Motivation .......................................5
5. ROLIE Requirements for the Atom Publishing Protocol .............7
5.1. AtomPub Service Documents ..................................7
5.1.1. Use of the "app:workspace" Element ..................8
5.1.2. Use of the "app:collection" Element .................8
5.1.3. Service Document Discovery ..........................9
5.2. Category Documents .........................................9
5.3. Transport Layer Security ..................................10
5.4. User Authentication and Authorization .....................10
5.5. "/" (Forward Slash) Resource URL ..........................11
5.6. HTTP Methods ..............................................11
6. ROLIE Requirements for the Atom Syndication Format .............11
6.1. Use of the "atom:feed" Element ............................11
6.1.1. Use of the "atom:category" Element .................13
6.1.2. Use of the "atom:link" Element .....................14
6.1.3. Use of the "atom:updated" Element ..................15
6.2. Use of the "atom:entry" Element ...........................16
6.2.1. Use of the "atom:content" Element ..................17
6.2.2. Use of the "atom:link" Element .....................17
6.2.3. Use of the "rolie:format" Element ..................18
6.2.4. Use of the "rolie:property" Element ................19
6.2.5. Requirements for a Standalone Entry ................20
1. Introduction ....................................................3
2. Terminology .....................................................4
3. XML-Related Conventions .........................................5
3.1. XML Namespaces .............................................5
3.2. RELAX NG Compact Schema ....................................5
4. Background and Motivation .......................................5
5. ROLIE Requirements for the Atom Publishing Protocol .............7
5.1. AtomPub Service Documents ..................................7
5.1.1. Use of the "app:workspace" Element ..................8
5.1.2. Use of the "app:collection" Element .................8
5.1.3. Service Document Discovery ..........................9
5.2. Category Documents .........................................9
5.3. Transport Layer Security ..................................10
5.4. User Authentication and Authorization .....................10
5.5. "/" (Forward Slash) Resource URL ..........................11
5.6. HTTP Methods ..............................................11
6. ROLIE Requirements for the Atom Syndication Format .............11
6.1. Use of the "atom:feed" Element ............................11
6.1.1. Use of the "atom:category" Element .................13
6.1.2. Use of the "atom:link" Element .....................14
6.1.3. Use of the "atom:updated" Element ..................15
6.2. Use of the "atom:entry" Element ...........................16
6.2.1. Use of the "atom:content" Element ..................17
6.2.2. Use of the "atom:link" Element .....................17
6.2.3. Use of the "rolie:format" Element ..................18
6.2.4. Use of the "rolie:property" Element ................19
6.2.5. Requirements for a Standalone Entry ................20
7. Available Extension Points Provided by ROLIE ...................21
7.1. The Category Extension Point ..............................21
7.1.1. General Use of the "atom:category" Element .........22
7.1.2. Identification of Security Automation
Information Types ..................................22
7.2. The "rolie:format" Extension Point ........................24
7.3. The Link Relation Extension Point .........................24
7.4. The "rolie:property" Extension Point ......................24
8. IANA Considerations ............................................26
8.1. XML Namespaces and Schema URNs ............................26
8.2. ROLIE URN Sub-namespace ...................................26
8.3. ROLIE URN Parameters ......................................27
8.4. ROLIE Information Types Registry ..........................29
9. Security Considerations ........................................29
10. Privacy Considerations ........................................31
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................34
Appendix A. RELAX NG Compact Schema for ROLIE .....................37
Appendix B. Examples of Use .......................................37
B.1. Service Discovery ..........................................37
B.2. Feed Retrieval .............................................40
B.3. Entry Retrieval ............................................42
Acknowledgements ..................................................43
Authors' Addresses ................................................43
7. Available Extension Points Provided by ROLIE ...................21
7.1. The Category Extension Point ..............................21
7.1.1. General Use of the "atom:category" Element .........22
7.1.2. Identification of Security Automation
Information Types ..................................22
7.2. The "rolie:format" Extension Point ........................24
7.3. The Link Relation Extension Point .........................24
7.4. The "rolie:property" Extension Point ......................24
8. IANA Considerations ............................................26
8.1. XML Namespaces and Schema URNs ............................26
8.2. ROLIE URN Sub-namespace ...................................26
8.3. ROLIE URN Parameters ......................................27
8.4. ROLIE Information Types Registry ..........................29
9. Security Considerations ........................................29
10. Privacy Considerations ........................................31
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................34
Appendix A. RELAX NG Compact Schema for ROLIE .....................37
Appendix B. Examples of Use .......................................37
B.1. Service Discovery ..........................................37
B.2. Feed Retrieval .............................................40
B.3. Entry Retrieval ............................................42
Acknowledgements ..................................................43
Authors' Addresses ................................................43
This document defines a resource-oriented approach to security automation information sharing that follows the Representational State Transfer (REST) architectural style [REST]. In this approach, computer security resources are maintained in web-accessible repositories structured as Atom Syndication Format [RFC4287] Feeds. Within a given Feed, which may be requested by the consumer, representations of specific types of security automation information are organized, categorized, and described. Furthermore, all collections available to a given user are discoverable, allowing the consumer to search all available content they are authorized to view, and to locate and request the desired information resources. Through the use of granular authentication and access controls, only authorized consumers may be permitted the ability to read or write to a given Feed.
本文档定义了一种面向资源的安全自动化信息共享方法，该方法遵循代表性状态转移（REST）体系结构风格[REST]。在这种方法中，计算机安全资源保存在可通过web访问的存储库中，存储库的结构为Atom联合格式[RFC4287]提要。在消费者可能请求的给定提要中，组织、分类和描述特定类型的安全自动化信息的表示。此外，给定用户可用的所有集合都是可发现的，允许消费者搜索他们有权查看的所有可用内容，并定位和请求所需的信息资源。通过使用细粒度身份验证和访问控制，只有经过授权的使用者才可以读取或写入给定的提要。
The goal of this approach is to increase the communication and sharing of security information between providers and consumers that can be used to automate security processes (e.g., incident reports, vulnerability assessments, configuration checklists, and other security automation information). Such sharing allows human
此方法的目标是增加提供者和使用者之间安全信息的通信和共享，这些信息可用于自动化安全过程（例如，事件报告、漏洞评估、配置检查表和其他安全自动化信息）。这样的分享让人类
operators and computer systems to leverage this standardized communication system to gather information that supports the automation of security processes.
操作员和计算机系统利用此标准化通信系统收集支持安全过程自动化的信息。
To support new types of security automation information being used as time goes on, this specification defines a number of extension points that can be used either privately or globally. These global extensions are IANA-registered by Resource-Oriented Lightweight Information Exchange (ROLIE) extension specifications and provide enhanced interoperability for new use cases and domains. Sections 5 and 6 of this document define the requirements for XML representations of ROLIE; other equivalent representations (e.g. JSON) may be described by other documents. An overview of the extension system is provided in Section 7. Implementers seeking to provide support for specific security automation information types should refer to the specification for that domain as described by the IANA registry found in Section 8.4.
为了支持随着时间的推移而使用的新类型的安全自动化信息，本规范定义了许多扩展点，这些扩展点可以单独使用，也可以全局使用。这些全局扩展是由面向资源的轻量级信息交换（ROLIE）扩展规范注册的IANA，为新的用例和域提供了增强的互操作性。本文件第5节和第6节定义了ROLIE的XML表示要求；其他等效表示（如JSON）可由其他文档描述。第7节概述了扩展系统。寻求为特定安全自动化信息类型提供支持的实现者应参考第8.4节中IANA注册表所述的该域规范。
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]所述进行解释。
The previous key words are used in this document to define only the requirements for implementations of this specification and are not used for recommendations or requirements for the usage of ROLIE. (In other words, a programmer of a ROLIE server MUST implement a given feature, but a user of that ROLIE server needn't use that feature.)
在本文件中，前面的关键词仅用于定义本规范实施的要求，不用于ROLIE使用的建议或要求。（换句话说，ROLIE服务器的程序员必须实现给定的功能，但ROLIE服务器的用户不需要使用该功能。）
Definitions for some of the common computer-security-related terminology used in this document can be found in Section 2 of [RFC7970].
本文件中使用的一些常见计算机安全相关术语的定义见[RFC7970]第2节。
The following term is unique to this specification:
以下术语为本规范所独有：
Information Type: A class of security automation information having one or more associated data models. Often, such security automation information is used in the automation of a security process. See Section 7.1.2 for more information.
信息类型：一类具有一个或多个关联数据模型的安全自动化信息。通常，此类安全自动化信息用于安全过程的自动化。详见第7.1.2节。
This specification uses XML namespaces [W3C.REC-xml-names-20091208] to uniquely identify XML element names. It uses the following namespace prefix mappings for the indicated namespace URI:
本规范使用XML名称空间[W3C.REC-XML-names-20091208]来唯一标识XML元素名称。它对指定的命名空间URI使用以下命名空间前缀映射：
o "app" is used for the "https://www.w3.org/2007/app" namespace defined in [RFC5023].
o “应用程序”用于https://www.w3.org/2007/app[RFC5023]中定义的命名空间。
o "atom" is used for the "https://www.w3.org/2005/Atom" namespace defined in [RFC4287].
o “atom”用于https://www.w3.org/2005/Atom[RFC4287]中定义的命名空间。
o "rolie" is used for the "urn:ietf:params:xml:ns:rolie:1.0" namespace defined in Section 8.1 of this specification.
o “rolie”用于本规范第8.1节中定义的“urn:ietf:params:xml:ns:rolie:1.0”命名空间。
Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact Schema [RELAX-NG]. The text of this specification provides the definition of conformance. Schema for the "https://www.w3.org/2007/app" and "https://www.w3.org/2005/Atom" namespaces appear in Appendix B of [RFC5023] and Appendix B of [RFC4287], respectively.
本规范的某些部分用非标准RELAX-NG紧凑模式[RELAX-NG]的片段进行了说明。本规范的文本提供了一致性的定义。“的架构”https://www.w3.org/2007/app“和”https://www.w3.org/2005/Atom“名称空间分别出现在[RFC5023]的附录B和[RFC4287]的附录B中。
A complete informative RELAX NG Compact Schema for the new elements introduced by ROLIE is provided in Appendix A of this document.
本文件附录A中提供了ROLIE介绍的新元素的完整信息型RELAXNG紧凑模式。
In order to automate security processes, tools need access to sufficient sources of structured security information that can be used to drive security processes. Thus, security information sharing is one of the core components of automating security processes. Vulnerabilities, configurations, software identification, security incidents, and patch data are just a few of the classes of information that are shared today to enable effective security on a wide scale. However, as the scale of defense broadens as networks become larger and more complex, and the volume of information to process makes humans-in-the-loop difficult to scale, the need for automation and machine-to-machine communication becomes increasingly critical.
为了自动化安全流程，工具需要访问足够的结构化安全信息源，这些信息源可用于驱动安全流程。因此，安全信息共享是安全过程自动化的核心组件之一。漏洞、配置、软件识别、安全事件和修补程序数据只是目前为实现大规模有效安全而共享的几类信息。然而，随着网络变得越来越大、越来越复杂，防御规模也越来越大，而且要处理的信息量使得人在回路中难以扩展，自动化和机器对机器通信的需求变得越来越重要。
ROLIE seeks to address this need by providing four major information-sharing benefits:
ROLIE通过提供四大信息共享优势来满足这一需求：
Extensible information type categories and format agnosticism: ROLIE is not bound to any given data format or category of information. Instead, information categories are extensible, and Entries declare the format of the referenced data. In cases where several formats or serializations are available, ROLIE can use link relations to communicate how a consumer can access these formats. For example, clients may request that a given resource representation be returned as XML, JSON, or in some other format or serialization. This approach allows the provider to support multiple isomorphic formats, allowing the consumer to select the most suitable version.
可扩展信息类型类别和格式不可知论：ROLIE不受任何给定数据格式或信息类别的约束。相反，信息类别是可扩展的，条目声明引用数据的格式。在几种格式或序列化可用的情况下，ROLIE可以使用链接关系来传达消费者如何访问这些格式。例如，客户机可能会请求将给定的资源表示返回为XML、JSON或其他格式或序列化。这种方法允许提供者支持多种同构格式，允许使用者选择最合适的版本。
Open and distributed information sharing: Using the Atom Publishing Protocol (AtomPub), ROLIE Feeds can easily aggregate Feeds and accept information posted to them from other sources. Webs of communicating ROLIE servers form ad hoc sharing communities, increasing data availability and the ability to correlate linked data across sources for participating consumers. ROLIE servers needn't be distributed, however, as large ROLIE repositories can function as a central collection or federated collections.
开放和分布式信息共享：使用Atom发布协议（AtomPublishing Protocol，AtomPub），ROLIE提要可以轻松地聚合提要并接受从其他来源发布给它们的信息。通信ROLIE服务器的网络形成了临时共享社区，提高了数据可用性，并增强了为参与用户跨源关联链接数据的能力。然而，ROLIE服务器不需要分布，因为大型ROLIE存储库可以作为中央集合或联合集合。
Stateless communication model: ROLIE, as a RESTful system, is stateless. That is, the server doesn't keep track of client sessions but rather uses link relations for state transitions. In practice, this means that any consumer can find and share information at any organizational level and at any time without needing to execute a long series of requests.
无状态通信模型：ROLIE作为一个RESTful系统，是无状态的。也就是说，服务器不跟踪客户端会话，而是使用链接关系进行状态转换。实际上，这意味着任何消费者都可以在任何组织级别和任何时间查找和共享信息，而无需执行一长串请求。
Information discovery and navigation: ROLIE provides a number of mechanisms to allow clients to programmatically discover and navigate collections of information in order to dynamically discover new or revised content. Extensible information types and other categories provide one way of determining content that is desirable. Link elements, each with a target URI and an established relationship type, provide a means for ROLIE providers to link other information that is relevant to the current Entry or Feed.
信息发现和导航：ROLIE提供了许多机制，允许客户端以编程方式发现和导航信息集合，以便动态发现新的或修订的内容。可扩展信息类型和其他类别提供了一种确定所需内容的方法。Link元素，每个元素都有一个目标URI和一个已建立的关系类型，为ROLIE提供者提供了一种方法来链接与当前条目或提要相关的其他信息。
These benefits result in an information-sharing protocol that is lightweight, interactive, open, and, most importantly, machine readable.
这些好处产生了一个轻量级、交互式、开放的信息共享协议，最重要的是，它是机器可读的。
The requirements in this specification are broken into two major sections: extensions to AtomPub [RFC5023] and extensions to the Atom Syndication Format [RFC4287]. All normative requirements in AtomPub
本规范中的要求分为两个主要部分：对AtomPub[RFC5023]的扩展和对Atom联合格式[RFC4287]的扩展。AtomPub中的所有规范性要求
and Atom Syndication are inherited from their respective specifications and apply here unless the requirement is explicitly overridden in this document. In this way, this document may upgrade the requirement (e.g., make a "SHOULD" a "MUST") but will never downgrade a given requirement (e.g., make a "MUST" a "SHOULD").
和Atom联合从各自的规范中继承并应用于此处，除非本文档中明确覆盖了该需求。通过这种方式，本文件可以升级要求（例如，将“应该”改为“必须”），但不会降级给定要求（例如，将“必须”改为“应该”）。
This section describes a number of restrictions of, and extensions to, AtomPub [RFC5023] that define the use of AtomPub in the context of a ROLIE-based solution. The normative requirements in this section are generally oriented towards client and server implementations. An understanding of the AtomPub specification [RFC5023] is helpful to understand the requirements in this section.
本节描述了AtomPub[RFC5023]的一些限制和扩展，这些限制和扩展定义了在基于ROLIE的解决方案中使用AtomPub。本节中的规范性要求通常面向客户机和服务器实现。理解AtomPub规范[RFC5023]有助于理解本节中的要求。
As described in Section 8 of [RFC5023], a Service Document is an XML-based document format that allows a client to dynamically discover the Collections provided by a publisher. A Service Document consists of one or more "app:workspace" elements that may each contain a number of "app:collection" elements.
如[RFC5023]第8节所述，服务文档是一种基于XML的文档格式，允许客户端动态发现发布者提供的集合。服务文档由一个或多个“app:workspace”元素组成，每个元素可能包含多个“app:collection”元素。
The general structure of a Service Document is as follows (from Section 4.2 of [RFC5023]):
服务文件的一般结构如下（参考[RFC5023]第4.2节）：
Service
o- Workspace
| |
| o- Collection
| | |
| | o- URI, categories, media types
| |
| o- ...
|
o- Workspace
| |
| o- Collection
| | |
| | o- URI, categories, media types
| |
| o- ...
|
o- ...
Service
o- Workspace
| |
| o- Collection
| | |
| | o- URI, categories, media types
| |
| o- ...
|
o- Workspace
| |
| o- Collection
| | |
| | o- URI, categories, media types
| |
| o- ...
|
o- ...
Note that the Internationalized Resource Identifiers (IRIs) in the original diagram have been replaced with URIs.
请注意，原始关系图中的国际化资源标识符（IRI）已替换为URI。
In AtomPub, a workspace, represented by the "app:workspace" element, describes a group of one or more Collections. Building on the AtomPub concept of a workspace, in ROLIE a workspace represents an aggregation of Collections pertaining to security automation information resources. This specification does not restrict the number of workspaces that may be in a Service Document or the specific Collections to be provided within a given workspace.
在AtomPub中，由“app:workspace”元素表示的工作区描述了一组一个或多个集合。基于AtomPub的工作区概念，在ROLIE中，工作区表示与安全自动化信息资源相关的集合的集合。本规范不限制服务文档中可能存在的工作区数量，也不限制给定工作区中要提供的特定集合。
A ROLIE implementation can host Collections containing both public and private information Entries. It is suggested that implementations segregate Collections into different "app:workspace" elements by their client access requirements. With proper naming of workspaces, this reduces the amount of trial and error a human user would need to utilize to discover accessible Collections.
ROLIE实现可以承载包含公共和私人信息条目的集合。建议实现根据客户机访问需求将集合分隔为不同的“app:workspace”元素。通过正确命名工作区，这减少了人工用户发现可访问集合所需的尝试和错误次数。
In AtomPub, a Collection in a Service Document, represented by the "app:collection" element, provides metadata that can be used to point to a specific Atom Feed that contains information Entries that may be of interest to a client. The association between a Collection and a Feed is provided by the "href" attribute of the "app:collection" element. Building on the AtomPub concept of a Collection, in ROLIE a Collection represents a pointer to a group of security automation information resources pertaining to a given type of security automation information. Collections are represented as Atom Feeds as per RFC 5023. Requirements specific to Atom Feed are defined in Section 6.1.
在AtomPub中，服务文档中的集合（由“app:Collection”元素表示）提供元数据，可用于指向特定的Atom提要，该提要包含客户端可能感兴趣的信息条目。集合和提要之间的关联由“app:Collection”元素的“href”属性提供。基于集合的AtomPub概念，在ROLIE中，集合表示指向与给定类型的安全自动化信息相关的一组安全自动化信息资源的指针。根据RFC 5023，集合表示为Atom提要。第6.1节定义了Atom Feed的特定要求。
ROLIE defines specialized data requirements for Collections, Feeds, and Entries containing data related to security automation. The difference between a ROLIE Collection and a non-ROLIE Collection defined in a Service Document can be determined as follows:
ROLIE为包含安全自动化相关数据的集合、提要和条目定义了专门的数据需求。服务文档中定义的ROLIE集合和非ROLIE集合之间的差异可确定如下：
ROLIE Collection: An app:collection is considered a ROLIE Collection when it contains an "app:categories" element that contains only one "atom:category" element with a "scheme" attribute value of "urn:ietf:params:rolie:category:information-type". Further, this category has an appropriate "term" attribute value as defined in Section 7.1.1. This ensures that a given Collection corresponds to a specific type of security automation information.
ROLIE Collection:app:Collection包含一个“app:categories”元素，该元素仅包含一个“atom:category”元素，且“scheme”属性值为“urn:ietf:params:ROLIE:category:information type”，则将其视为ROLIE集合。此外，该类别具有第7.1.1节中定义的适当“术语”属性值。这可确保给定集合对应于特定类型的安全自动化信息。
Non-ROLIE Collection: An app:collection is considered a non-ROLIE Collection when it does not contain an "atom:category" element with a "scheme" attribute value of "urn:ietf:params:rolie:category:information-type".
非ROLIE集合：如果app:Collection不包含“atom:category”元素，且“scheme”属性值为“urn:ietf:params:ROLIE:category:information type”，则将其视为非ROLIE集合。
By distinguishing between ROLIE and non-ROLIE Collections in this way, implementations supporting ROLIE can host Collections pertaining to security automation information alongside Collections of other non-ROLIE information within the same AtomPub instance.
通过以这种方式区分ROLIE和非ROLIE集合，支持ROLIE的实现可以在同一AtomPub实例中托管与安全自动化信息相关的集合以及其他非ROLIE信息的集合。
The following are additional requirements on the use of the "app:collection" element for a ROLIE Collection:
以下是ROLIE系列使用“应用程序：集合”元素的附加要求：
o The child "atom:category" elements contained in the "app:categories" element MUST be the same set of "atom:category" elements used in the Atom Feed resource referenced by the "app:collection" element's "href" attribute value. This ensures that the category metadata associated with the Collection and the associated Feed is discoverable in both of these resources.
o “app:categories”元素中包含的子“atom:categories”元素必须与“app:collection”元素的“href”属性值引用的atom提要资源中使用的“atom:categority”元素相同。这确保了与集合和关联提要关联的类别元数据在这两个资源中都是可发现的。
o The "app:categories" element in an app:collection MAY include additional "atom:category" elements using a scheme other than "urn:ietf:params:rolie:category:information-type". This allows other category metadata to be included.
o app:collection中的“app:categories”元素可能包括使用“urn:ietf:params:rolie:category:information type”以外的方案的其他“atom:category”元素。这允许包含其他类别元数据。
The Service Document serves as the "head" of a given ROLIE repository: from the Service Document, all other repository content can be discovered. A client will need to determine the URL of this Service Document to discover the Collections provided by the repository. The client might determine the URL from a web page, based on out-of-band communication, or through a "service" link relation in a Feed or Entry Document that the client has already retrieved. The latter is a typical scenario if the client learns of a specific Feed or Entry through an out-of-band mechanism and wishes to discover additional information provided by the repository.
服务文档充当给定ROLIE存储库的“头”：从服务文档中可以发现所有其他存储库内容。客户机需要确定此服务文档的URL以发现存储库提供的集合。客户机可以根据带外通信，或通过客户机已经检索到的提要或条目文档中的“服务”链接关系，从网页确定URL。如果客户机通过带外机制了解特定提要或条目，并希望发现存储库提供的其他信息，则后者是一种典型的情况。
This document does not provide a fully automated discovery mechanism. A mechanism may be defined in the future that allows automated clients to discover the URL to use to retrieve a ROLIE Service Document representing the head of the ROLIE repository.
本文档不提供完全自动的发现机制。将来可能会定义一种机制，允许自动客户端发现用于检索代表ROLIE存储库头部的ROLIE服务文档的URL。
As described in Section 7 of [RFC5023], a Category Document is an XML-based document format that allows a client to dynamically discover the categories used within AtomPub Service Documents, Atom Syndication Feeds, and Entry Documents provided by a publisher. A Category Document consists of one "app:categories" element that contains a number of inline "atom:category" elements, or a URI referencing a Category Document.
如[RFC5023]第7节所述，类别文档是一种基于XML的文档格式，允许客户端动态发现AtomPub服务文档、Atom联合提要和发布者提供的条目文档中使用的类别。类别文档由一个“app:categories”元素组成，该元素包含许多内联的“atom:categories”元素，或者一个引用类别文档的URI。
ROLIE is intended to be handled with Transport Layer Security (TLS). TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented according to all recommendations and best practices presented in [RFC7525].
ROLIE将使用传输层安全（TLS）进行处理。必须支持TLS 1.2版。应根据[RFC7525]中提出的所有建议和最佳实践实施TLS 1.2。
It is RECOMMENDED that the most recent published version of TLS be supported. If this version is TLS 1.3 [TLS-1.3], it is suggested that 0-RTT (Zero Round-Trip Time Resumption) not be used, in order to prevent replay attacks. Replay attacks on PUT, POST, or DELETE requests can disrupt repository operation by modifying data unexpectedly.
建议支持最新发布的TLS版本。如果此版本为TLS 1.3[TLS-1.3]，建议不要使用0-RTT（零往返时间恢复），以防止重播攻击。对PUT、POST或DELETE请求的重播攻击会因意外修改数据而中断存储库操作。
For example, an automated ROLIE repository that updates very frequently may receive a PUT request against a given resource a few times an hour (or more). An attacker may store an early PUT request, and at the end of the resumption window replay the PUT request, reverting the resource to an old version. Not only could an attacker be doing this replay continuously to cause havoc on the server, but the client is completely unaware of the attack taking place.
例如，经常更新的自动化ROLIE存储库可能会在一小时（或更长时间）内收到针对给定资源的PUT请求几次。攻击者可能存储早期PUT请求，并在恢复窗口结束时重播PUT请求，将资源还原为旧版本。攻击者不仅可以连续进行此重播以对服务器造成严重破坏，而且客户端完全不知道攻击的发生。
Given the potentially sensitive nature of data handled by ROLIE, all appropriate precautions should be taken at the transport layer to protect forward secrecy and user privacy.
鉴于ROLIE处理的数据具有潜在的敏感性，应在传输层采取所有适当的预防措施，以保护前向保密性和用户隐私。
The server MUST implement certificate-based client authentication. This MAY be enabled on a workspace-by-workspace basis.
服务器必须实现基于证书的客户端身份验证。这可以逐个工作区启用。
Implementations MUST support user authentication. However, a given implementation MAY allow user authentication to be disabled on a Feed-by-Feed or workspace-by-workspace basis.
实现必须支持用户身份验证。但是，给定的实现可能允许逐个提要或逐个工作区禁用用户身份验证。
It is recommended that servers participating in an information-sharing consortium and supporting interactive user logins by members of the consortium support client authentication via a federated identity scheme.
建议参与信息共享联盟并支持联盟成员交互用户登录的服务器通过联合身份方案支持客户端身份验证。
This document does not mandate the use of any specific user authorization mechanisms. However, service implementers SHOULD support appropriate authorization checking for all resource accesses, including individual Atom Entries, Atom Feeds, and Atom Service Documents.
本文件不强制使用任何特定的用户授权机制。但是，服务实现者应该支持对所有资源访问进行适当的授权检查，包括单个Atom条目、Atom提要和Atom服务文档。
The "/" resource MAY be supported for compatibility with existing deployments that are using [RFC6546] ("Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS"). The following requirements apply only to implementations that support both RFC 6546 and the "/" resource as described above:
可能支持“/”资源，以便与使用[RFC6546]（“通过HTTP/TLS传输实时网络间防御（RID）消息”）的现有部署兼容。以下要求仅适用于支持RFC 6546和上述“/”资源的实现：
o Consistent with Erratum ID 3267 [Err3267] for [RFC6546], a client requesting a GET on the "/" resource SHOULD receive an HTTP status code 405 ("Method Not Allowed").
o 与[RFC6546]的勘误表ID 3267[Err3267]一致，请求获取“/”资源的客户端应收到HTTP状态代码405（“不允许方法”）。
o An implementation MAY provide full support for [RFC6546] such that a POST to the "/" resource containing a recognized RID message is handled correctly as a RID request. Alternatively, a client requesting a POST to "/" MAY receive an HTTP status code 307 ("Temporary Redirect"). In this case, the location header in the HTTP response will provide the URL of the appropriate RID endpoint, and the client may repeat the POST method at the indicated location.
o 一个实现可以提供对[RFC6546]的完全支持，从而将包含可识别RID消息的“/”资源的POST作为RID请求正确处理。或者，请求POST to“/”的客户端可以接收HTTP状态代码307（“临时重定向”）。在这种情况下，HTTP响应中的location标头将提供相应RID端点的URL，客户端可以在指定的位置重复POST方法。
If RFC 6546 is unsupported, then a request for the "/" resource may be handled as deemed appropriate by the server.
如果RFC 6546不受支持，则服务器可以视为适当地处理对“/”资源的请求。
Servers MAY accept request methods beyond those specified in this document.
服务器可以接受本文档中指定之外的请求方法。
Clients MUST be capable of recognizing and processing any standard HTTP status code, as defined in Section 5 of [RFC5023].
客户机必须能够识别和处理[RFC5023]第5节中定义的任何标准HTTP状态代码。
This section describes a number of restrictions of, and extensions to, the Atom Syndication Format [RFC4287] that define the valid use of the format in the context of a ROLIE implementation. An understanding of the Atom Syndication Format specification [RFC4287] is helpful to understand the requirements in this section.
本节描述了Atom联合格式[RFC4287]的一些限制和扩展，这些限制和扩展定义了该格式在ROLIE实现上下文中的有效使用。理解Atom联合格式规范[RFC4287]有助于理解本节中的需求。
As described in Section 4.1.1 of [RFC4287], an Atom Feed is an XML-based document format that describes a list of related information items. The Atom Feeds provided by a ROLIE service are listed in the service's Service Document through one or more "app:collection" elements. Each Feed Document, represented using the "atom:feed" element, contains a listing of zero or more Entries.
如[RFC4287]第4.1.1节所述，Atom提要是一种基于XML的文档格式，用于描述相关信息项的列表。ROLIE服务提供的Atom提要通过一个或多个“app:collection”元素列在服务的服务文档中。使用“atom:Feed”元素表示的每个提要文档都包含零个或多个条目的列表。
When applied to the problem domain of security automation information sharing, an Atom Feed may be used to represent any meaningful collection of security automation information resources. Each Entry in a Feed represents an individual resource (e.g., a specific checklist, a software vulnerability record). Additional Feeds can be used to represent other collections of security automation resources.
当应用于安全自动化信息共享的问题域时，Atom提要可用于表示安全自动化信息资源的任何有意义的集合。提要中的每个条目表示一个单独的资源（例如，特定的检查表、软件漏洞记录）。其他提要可用于表示安全自动化资源的其他集合。
As discussed in Section 5.1.2, ROLIE defines specialized data requirements for Feeds containing data related to security automation. The difference between a ROLIE Feed and a non-ROLIE Feed can be determined as follows:
如第5.1.2节所述，ROLIE为包含安全自动化相关数据的提要定义了专门的数据要求。ROLIE进料和非ROLIE进料之间的差异可通过以下方式确定：
ROLIE Feed: For an "atom:feed" to be considered a ROLIE Feed, the "atom:feed" MUST contain only one child "atom:category" element with a "scheme" attribute value of "urn:ietf:params:rolie:category:information-type". This category MUST have an appropriate "term" attribute value as defined in Section 7.1.1. This ensures that a given Feed corresponds to a specific type of security automation information.
ROLIE提要：要将“atom:Feed”视为ROLIE提要，“atom:Feed”必须只包含一个子“atom:category”元素，其“scheme”属性值为“urn:ietf:params:ROLIE:category:information type”。该类别必须具有第7.1.1节中定义的适当“术语”属性值。这确保了给定的提要对应于特定类型的安全自动化信息。
Non-ROLIE Feed: For an "atom:feed" to be considered a non-ROLIE Feed, the "atom:feed" MUST NOT contain an "atom:category" element with a "scheme" attribute value of "urn:ietf:params:rolie:category:information-type".
非ROLIE提要：要将“atom:Feed”视为非ROLIE提要，“atom:Feed”不能包含“scheme”属性值为“urn:ietf:params:ROLIE:category:information type”的“atom:category”元素。
By distinguishing between ROLIE and non-ROLIE Feeds in this way, implementations supporting ROLIE can host Feeds pertaining to security automation information alongside Feeds of other non-ROLIE information within the same AtomPub instance. This is parallel to the handling of Collections as discussed earlier in this specification (Section 5.1.2).
通过以这种方式区分ROLIE和非ROLIE提要，支持ROLIE的实现可以在同一AtomPub实例中托管与安全自动化信息相关的提要以及其他非ROLIE信息的提要。这与本规范前面讨论的收集处理（第5.1.2节）是平行的。
The following Atom Feed definition represents a stricter definition of the "atom:feed" element defined in [RFC4287] when used as a ROLIE Feed. Any element not specified here inherits its definition and requirements from [RFC4287].
以下Atom提要定义表示在[RFC4287]中定义的“Atom:Feed”元素在用作ROLIE提要时的更严格定义。此处未指定的任何元素继承了[RFC4287]的定义和要求。
atomFeed =
element atom:feed {
atomCommonAttributes,
(atomAuthor*
& atomCategory+
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId
& atomLink+
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}
atomFeed =
element atom:feed {
atomCommonAttributes,
(atomAuthor*
& atomCategory+
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId
& atomLink+
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}
The following subsections contain requirements for a ROLIE Feed.
以下小节包含ROLIE提要的要求。
An "atom:feed" can contain one or more "atom:category" elements. In Atom, the naming scheme and the semantic meaning of the terms used to identify an Atom category are application defined.
“atom:feed”可以包含一个或多个“atom:category”元素。在Atom中，用于标识Atom类别的术语的命名方案和语义由应用程序定义。
The following are additional requirements on the use of the "atom:category" element when used in a ROLIE Feed:
以下是在ROLIE提要中使用“atom:category”元素时的附加要求：
o All member Entries in the Feed MUST represent security automation information records of the provided information type category.
o 提要中的所有成员条目必须表示所提供信息类型类别的安全自动化信息记录。
o The "atom:feed" MAY include additional "atom:category" elements using a scheme other than "urn:ietf:params:rolie:category:information-type". This allows other category metadata to be included.
o “atom:feed”可以包括使用“urn:ietf:params:rolie:category:information type”之外的方案的附加“atom:category”元素。这允许包含其他类别元数据。
Link relations defined by the "atom:link" element are used to represent state transitions using a stateless approach. In Atom, a type of link relationship can be defined using the "rel" attribute.
“atom:Link”元素定义的链接关系用于使用无状态方法表示状态转换。在Atom中，可以使用“rel”属性定义一种链接关系。
A ROLIE Feed MUST contain one or more "atom:link" elements with rel="service" and an "href" attribute whose value is a URI that points to an Atom Service Document associated with the Feed. If a client accesses a Feed without first accessing the service's Service Document, a link with the "service" relationship provides a means to discover additional security automation information. The "service" link relationship is defined in the IANA "Link Relations" registry at <https://www.iana.org/assignments/link-relations/>.
ROLIE提要必须包含一个或多个带有rel=“service”的“atom:link”元素和一个“href”属性，该属性的值是指向与提要关联的atom服务文档的URI。如果客户机访问提要时没有首先访问服务的服务文档，那么带有“服务”关系的链接提供了发现其他安全自动化信息的方法。“服务”链接关系在IANA“链接关系”注册表中定义，位于<https://www.iana.org/assignments/link-relations/>.
A Feed can contain an arbitrary number of Entries. In some cases, a complete Feed may consist of a large number of Entries. Additionally, as new and updated Entries are ordered at the beginning of a Feed, a client may only be interested in retrieving the first N Entries in a Feed to process only the Entries that have changed since the last retrieval of the Feed. As a practical matter, a large set of Entries will likely need to be divided into more manageable portions, or pages. Based on Section 3 of [RFC5005], link elements SHOULD be included in all Feeds to support paging using the following link relation types:
提要可以包含任意数量的条目。在某些情况下，完整的提要可能包含大量条目。此外，由于新的和更新的条目是在提要的开头排序的，因此客户机可能只对检索提要中的前N个条目感兴趣，以仅处理自上次检索提要以来已更改的条目。实际上，大量条目可能需要划分为更易于管理的部分或页面。根据[RFC5005]第3节，链接元素应包含在所有提要中，以支持使用以下链接关系类型进行分页：
o "first" - Indicates that the "href" attribute value of the link identifies a resource URI for the furthest preceding page of the Feed.
o “first”-表示链接的“href”属性值标识提要最远前一页的资源URI。
o "last" - Indicates that the "href" attribute value of the link identifies a resource URI for the furthest following page of the Feed.
o “last”-表示链接的“href”属性值为提要的下一个最远页面标识资源URI。
o "previous" - Indicates that the "href" attribute value of the link identifies a resource URI for the immediately preceding page of the Feed.
o “previous”-表示链接的“href”属性值标识提要前一页的资源URI。
o "next" - Indicates that the "href" attribute value of the link identifies a resource URI for the immediately following page of the Feed.
o “next”-表示链接的“href”属性值为提要的下一页标识资源URI。
For example:
例如：
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="https://www.w3.org/2005/Atom">
<id>b7f65304-b63b-4246-88e2-c104049c5fd7</id>
<title>Paged Feed</title>
<link rel="self" href="https://example.org/feedA?page=5"/>
<link rel="first" href="https://example.org/feedA?page=1"/>
<link rel="prev" href="https://example.org/feedA?page=4"/>
<link rel="next" href="https://example.org/feedA?page=6"/>
<link rel="last" href="https://example.org/feedA?page=10"/>
<updated>2012-05-04T18:13:51.0Z</updated>
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="https://www.w3.org/2005/Atom">
<id>b7f65304-b63b-4246-88e2-c104049c5fd7</id>
<title>Paged Feed</title>
<link rel="self" href="https://example.org/feedA?page=5"/>
<link rel="first" href="https://example.org/feedA?page=1"/>
<link rel="prev" href="https://example.org/feedA?page=4"/>
<link rel="next" href="https://example.org/feedA?page=6"/>
<link rel="last" href="https://example.org/feedA?page=10"/>
<updated>2012-05-04T18:13:51.0Z</updated>
<!-- remainder of the Feed's elements -->
</feed>
<!-- remainder of the Feed's elements -->
</feed>
Example Paged Feed
分页提要示例
A reference to a historical Feed may need to be stable, and/or a Feed may need to be divided into a series of defined epochs. Implementations SHOULD support the mechanisms described in Section 4 of [RFC5005] to provide link-based state transitions for maintaining the archiving of Feeds.
对历史提要的引用可能需要稳定，和/或提要可能需要划分为一系列定义的时期。实现应支持[RFC5005]第4节中描述的机制，以提供基于链接的状态转换，以维护提要的存档。
A Feed MAY include additional link relationships not specified in this document. If a client encounters an unknown link relationship type, the client MUST ignore the unrecognized link and continue processing as if the unrecognized link element did not appear. The definition of new link relations that provide additional state transition extensions is discussed in Section 7.3.
提要可能包括本文档中未指定的其他链接关系。如果客户端遇到未知的链接关系类型，则客户端必须忽略无法识别的链接并继续处理，就像未出现无法识别的链接元素一样。第7.3节讨论了提供额外状态转换扩展的新链接关系的定义。
The "atom:updated" element identifies the date and time that a Feed was last updated.
“atom:updated”元素标识提要上次更新的日期和时间。
The "atom:updated" element MUST be populated with the current time at the instant the Feed was last updated by adding, updating, or deleting an Entry, or by changing any metadata for the Feed.
“atom:updated”元素必须通过添加、更新或删除条目或更改提要的任何元数据来填充提要上次更新时的当前时间。
Each Entry in an Atom Feed, represented by the "atom:entry" element, describes a single referenced information record, along with descriptive information about its format, media type, and other publication metadata. The following "atom:entry" schema definition represents a stricter representation of the "atom:entry" element defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in Section 6.1.1.
Atom提要中的每个条目（由“Atom:Entry”元素表示）描述一个引用的信息记录，以及关于其格式、媒体类型和其他发布元数据的描述性信息。以下“atom:entry”模式定义代表了[RFC4287]中定义的“atom:entry”元素的更严格表示，用于第6.1.1节中定义的基于ROLIE的atom提要。
atomEntry =
element atom:entry {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContent
& atomContributor*
& atomId
& atomLink*
& atomPublished?
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& rolieFormat?
& rolieProperty*
& extensionElement*)
}
atomEntry =
element atom:entry {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContent
& atomContributor*
& atomId
& atomLink*
& atomPublished?
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& rolieFormat?
& rolieProperty*
& extensionElement*)
}
The notable changes from [RFC4287] are the addition of "rolieFormat" and "rolieProperty" elements. Also, the "atomContent" element is restricted to the atomOutOfLineContent formulation and is now REQUIRED.
[RFC4287]的显著变化是添加了“rolieFormat”和“rolieProperty”元素。此外，“atomContent”元素仅限于AtomoofLineContent配方，现在是必需的。
The following subsections contain requirements for Entries in a ROLIE Feed.
以下小节包含ROLIE提要中条目的要求。
An "atom:content" element associates its containing Entry with a content resource identified by the "src" attribute.
“atom:content”元素将其包含的条目与由“src”属性标识的内容资源相关联。
There MUST be exactly one "atom:content" element in the Entry. The "atom:content" element MUST adhere to this definition, which is a stricter representation of the "atom:content" element defined in [RFC4287]:
条目中必须只有一个“atom:content”元素。“atom:content”元素必须遵守此定义，这是[RFC4287]中定义的“atom:content”元素的更严格表示形式：
atomContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType },
attribute src { atomUri },
empty
}
atomContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType },
attribute src { atomUri },
empty
}
This restricts atomContent in ROLIE to the atomOutOfLineContent formulation presented in [RFC4287].
这将ROLIE中的原子含量限制为[RFC4287]中所述的原子含量配方。
The "type" attribute MUST identify the serialization type of the content -- for example, "application/xml" or "application/json". A prefixed media type MAY be used to reflect a specific model used with a given serialization approach (e.g., "application/rdf+xml"). The "src" attribute MUST be a URI that can be dereferenced to retrieve the related content data.
“type”属性必须标识内容的序列化类型——例如，“application/xml”或“application/json”。前缀媒体类型可用于反映给定序列化方法使用的特定模型（例如，“应用程序/rdf+xml”）。“src”属性必须是可以取消引用以检索相关内容数据的URI。
Link relations can be included in an Entry to represent state transitions to and from the Entry, as well as to provide links to related information.
链接关系可以包含在条目中，以表示与条目之间的状态转换，以及提供到相关信息的链接。
If there is a need to provide the same information in different data models and/or serialization formats, separate Entry instances can be included in the same Feed or a different Feed. Such an alternate content representation can be indicated using an "atom:link" having a "rel" attribute with the value "alternate".
如果需要以不同的数据模型和/或序列化格式提供相同的信息，则可以在同一个提要或不同的提要中包含单独的条目实例。可以使用具有值为“alternate”的“rel”属性的“atom:link”来指示这种替代内容表示。
A Feed MAY include additional link relationships not specified in this document. If a client encounters an unknown link relationship type, the client MUST ignore the unrecognized link and continue processing as if the unrecognized link element did not appear. The definition of new link relations that provide additional state transition extensions is discussed in Section 7.3.
提要可能包括本文档中未指定的其他链接关系。如果客户端遇到未知的链接关系类型，则客户端必须忽略无法识别的链接并继续处理，就像未出现无法识别的链接元素一样。第7.3节讨论了提供额外状态转换扩展的新链接关系的定义。
As mentioned in Sections 1 and 4, a key goal of this specification is to allow a consumer to review a set of published security automation information resources and then identify and retrieve any resources of interest. The format of the data is a key criteria to consider when deciding what information to retrieve. For a given type of security automation information, it is expected that a number of different formats may be used to represent this information. To support this use case, both the serialization format and the specific data model expressed in that format must be known by the consumer.
如第1节和第4节所述，本规范的一个关键目标是允许使用者查看一组已发布的安全自动化信息资源，然后识别和检索任何感兴趣的资源。数据格式是决定检索什么信息时要考虑的关键标准。对于给定类型的安全自动化信息，可以使用多种不同的格式来表示该信息。为了支持此用例，使用者必须知道序列化格式和以该格式表示的特定数据模型。
In the Atom Syndication Format, a media type can be defined using the "type" attribute of the "atom:content" element of an "atom:entry". The media type can be fully descriptive of the format of the linked document, such as "application/atom+xml". In some cases, however, a format-specific media type may not be defined. An example might be when "application/xml" is used because there is no defined specific media type for the content. In such a case, the exact data model of the content cannot be known without first retrieving the content.
在Atom联合格式中，可以使用“Atom:entry”的“Atom:content”元素的“type”属性定义媒体类型。媒体类型可以完全描述链接文档的格式，例如“application/atom+xml”。但是，在某些情况下，可能无法定义特定于格式的媒体类型。例如，使用“application/xml”是因为没有为内容定义特定的媒体类型。在这种情况下，如果不首先检索内容，就无法知道内容的确切数据模型。
In cases where a specific media type does not exist, the "rolie:format" element is used to describe the data model used to express the information referenced in the "atom:content" element. The "rolie:format" element also allows a schema to be identified that can be used when parsing the content to verify or better understand the structure of the content.
在不存在特定媒体类型的情况下，“rolie:format”元素用于描述用于表示“atom:content”元素中引用的信息的数据模型。“rolie:format”元素还允许识别模式，在解析内容时可以使用该模式来验证或更好地理解内容的结构。
When it appears, the "rolie:format" element MUST adhere to this definition:
“rolie:format”元素出现时必须遵循以下定义：
rolieFormat =
element rolie:format {
atomCommonAttributes,
attribute ns { atomUri },
attribute version { text } ?,
attribute schema-location { atomUri } ?,
attribute schema-type { atomMediaType } ?,
empty
}
rolieFormat =
element rolie:format {
atomCommonAttributes,
attribute ns { atomUri },
attribute version { text } ?,
attribute schema-location { atomUri } ?,
attribute schema-type { atomMediaType } ?,
empty
}
The "rolie:format" element MUST provide a "ns" attribute that identifies the data model of the resource referenced by the "atom:content" element. For example, the namespace used may be an XML namespace URI or an identifier that represents a serialized JSON model. The URI used for the "ns" attribute MUST be absolute. The resource identified by the URI need not be resolvable.
“rolie:format”元素必须提供一个“ns”属性，该属性标识“atom:content”元素引用的资源的数据模型。例如，所使用的名称空间可以是XML名称空间URI或表示序列化JSON模型的标识符。用于“ns”属性的URI必须是绝对的。URI标识的资源不需要是可解析的。
The "rolie:format" element MAY provide a "version" attribute that identifies the version of the format used for the related "atom:content" element.
“rolie:format”元素可以提供一个“version”属性，该属性标识用于相关“atom:content”元素的格式版本。
The "rolie:format" element MAY provide a "schema-location" attribute, which is a URI that identifies a schema resource that can be used to validate the related "atom:content" element.
“rolie:format”元素可以提供一个“schema location”属性，该属性是一个URI，用于标识可用于验证相关“atom:content”元素的模式资源。
The "rolie:format" element MAY provide a "schema-type" attribute, which is a media type (as described in [RFC2045]) identifying the format of the schema resource identified by the "schema-location" attribute.
“rolie:format”元素可以提供一个“schema type”属性，该属性是一种媒体类型（如[RFC2045]中所述），用于标识由“schema location”属性标识的模式资源的格式。
The following nominal example shows how these attributes describe the format of the content:
以下示例显示了这些属性如何描述内容的格式：
<rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"
version="2.0"
schema-location=
"https://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd"
schema-type="text/xml"/>
<rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"
version="2.0"
schema-location=
"https://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd"
schema-type="text/xml"/>
The previous element provides an indication that the content of the given Entry is using the Incident Object Description Exchange Format (IODEF) v2 format.
前面的元素指示给定条目的内容正在使用事件对象描述交换格式（IODEF）v2格式。
An "atom:category" element provides a way to associate a name/value pair of categorical information using the "scheme" and "term" attributes to represent the name and using the "label" attribute to represent the value. When used in this way, an "atom:category" allows a specific label to be selected from a finite set of possible label values that can be used to further classify a given Entry or Feed. Within ROLIE, there may be a need to associate additional metadata with an Entry. In such a case, the use of an "atom:category" is not practical to represent name/value data for which the allowed values are unbounded. Instead, ROLIE introduces a new "rolie:property" element that can represent non-categorical metadata as name/value pairs. Examples include content-specific identifiers, naming data, and other properties that allow for unbounded values.
“atom:category”元素提供了一种方法，使用“scheme”和“term”属性来表示名称，使用“label”属性来表示值，从而关联类别信息的名称/值对。以这种方式使用时，“atom:category”允许从有限的可能标签值集中选择特定标签，这些标签值可用于进一步分类给定条目或提要。在ROLIE中，可能需要将其他元数据与条目相关联。在这种情况下，使用“atom:category”来表示允许值为无界的名称/值数据是不实际的。相反，ROLIE引入了一个新的“ROLIE:property”元素，它可以将非分类元数据表示为名称/值对。示例包括特定于内容的标识符、命名数据和其他允许无界值的属性。
There MAY be zero or more "rolie:property" elements in an "atom:entry".
“atom:entry”中可能有零个或多个“rolie:property”元素。
The element MUST adhere to this definition:
该元素必须符合以下定义：
rolieProperty =
element rolie:property {
atomCommonAttributes,
attribute name { atomUri },
attribute value { text },
empty
}
rolieProperty =
element rolie:property {
atomCommonAttributes,
attribute name { atomUri },
attribute value { text },
empty
}
The "name" attribute provides a URI that identifies the namespace and name of the property as a URI.
“name”属性提供一个URI，该URI将属性的名称空间和名称标识为URI。
The "value" attribute is text that provides a value for the property identified by the "name" attribute.
“value”属性是为“name”属性标识的属性提供值的文本。
For example, the nominal element <rolie:property name="urn:ietf:params:rolie:property:content-id" value="12345"/> would expose an IODEF ID value contained in a given Entry's content. The name used in the example also demonstrates the use of a registered ROLIE property extension, which is described in Section 7.4.
例如，标称元素<rolie:property name=“urn:ietf:params:rolie:property:content id”value=“12345”/>将公开给定条目内容中包含的IODEF id值。示例中使用的名称还演示了注册ROLIE属性扩展的使用，如第7.4节所述。
Implementations MAY use locally defined and namespaced elements in an Entry in order to provide additional information. Clients that do not recognize a property with an unregistered "name" attribute MUST ignore the "rolie:property" element; that is, the client MUST NOT fail parsing content that contains an unrecognized property.
实现可以在条目中使用本地定义和命名空间的元素，以提供附加信息。无法识别具有未注册“name”属性的属性的客户端必须忽略“rolie:property”元素；也就是说，客户端解析包含无法识别属性的内容时不得失败。
If an Entry is ever shared as a standalone resource, separate from its containing Feed, then the following additional requirements apply:
如果某个条目作为独立资源共享，并与其包含的提要分开，则适用以下附加要求：
o The Entry MUST have an "atom:link" element with rel="collection" and href="[URI of the containing Collection]". This allows the Feed or Feeds of which the Entry is a member to be discovered, along with the related information the Feed may contain. In the case where the Entry has multiple containing Feeds, the Entry MUST have one "atom:link" for each related Feed.
o 该条目必须有一个带有rel=“collection”和href=“[URI of The containing collection]”的“atom:link”元素。这允许查找条目所属的一个或多个提要，以及提要可能包含的相关信息。在条目有多个包含提要的情况下，对于每个相关提要，条目必须有一个“atom:link”。
o The Entry MUST declare the information type of the content resource referenced by the Entry (see Section 7.1.2).
o 条目必须声明条目引用的内容资源的信息类型（参见第7.1.2节）。
This specification does not require particular information types or data formats; rather, ROLIE is intended to be extended by additional specifications that define the use of new categories and link relations. The primary point of extension is through the definition of new information type category terms. Additional specifications can register new information type category terms with IANA that serve as the main characterizing feature of a ROLIE Collection/Feed or resource/Entry. These additional specifications defining new information type terms can describe additional requirements for including specific categories and link relations, as well as the use of specific data formats supporting a given information type term.
本规范不要求特定的信息类型或数据格式；相反，ROLIE旨在通过定义新类别和链接关系的使用的附加规范进行扩展。主要的扩展点是通过定义新的信息类型类别术语。附加规范可以向IANA注册新的信息类型类别术语，作为ROLIE收集/馈送或资源/条目的主要特征。这些定义新信息类型术语的附加规范可以描述包括特定类别和链接关系的附加要求，以及支持给定信息类型术语的特定数据格式的使用。
The "atom:category" element, defined in Section 4.2.2 of [RFC4287], provides a mechanism to provide additional categorization information for a content resource in ROLIE. The ability to define new categories is one of the core extension points provided by Atom. A Category Document, defined in Section 7 of [RFC5023], provides a mechanism for an Atom implementation to make discoverable the "atom:category" terms and associated allowed values.
[RFC4287]第4.2.2节中定义的“atom:category”元素提供了一种为ROLIE中的内容资源提供额外分类信息的机制。定义新类别的能力是Atom提供的核心扩展点之一。[RFC5023]第7节中定义的类别文档为Atom实现提供了一种机制，使“Atom:Category”术语和相关的允许值可被发现。
ROLIE further defines the use of the existing Atom extension category mechanism by allowing ROLIE-specific category extensions to be registered with IANA. The "urn:ietf:params:rolie:category:information-type" category scheme, which has special meaning for implementations of ROLIE, has been assigned (see Section 8.3). This allows category scheme namespaces to be managed in a more consistent way, allowing for greater interoperability between content producers and consumers.
ROLIE通过允许ROLIE特定的类别扩展向IANA注册，进一步定义了现有Atom扩展类别机制的使用。已分配“urn:ietf:params:rolie:category:information type”类别方案，该方案对rolie的实现具有特殊意义（见第8.3节）。这允许以更一致的方式管理类别方案名称空间，从而实现内容生产者和消费者之间更大的互操作性。
Any "atom:category" element whose "scheme" attribute uses an unregistered scheme MUST be considered "Private Use" as defined in [RFC8126]. Implementations encountering such a category MUST parse the content without error but MAY otherwise ignore the element.
其“scheme”属性使用未注册方案的任何“atom:category”元素必须被视为[RFC8126]中定义的“私有用途”。遇到此类类别的实现必须无错误地解析内容，但可能会忽略元素。
The use of the "atom:category" element is discussed in the following subsections.
下面的小节将讨论“atom:category”元素的使用。
The "atom:category" element can be used for characterizing a ROLIE resource. An "atom:category" element has a "term" attribute that indicates the assigned category value and a "scheme" attribute that provides an identifier for the category type. The "scheme" provides a means to describe how a set of category terms should be used and provides a namespace that can be used to differentiate terms that are provided by multiple organizations and that have different semantic meaning.
“atom:category”元素可用于描述ROLIE资源的特征。“atom:category”元素有一个“term”属性，表示分配的类别值，还有一个“scheme”属性，为类别类型提供标识符。“方案”提供了一种描述如何使用一组类别术语的方法，并提供了一个名称空间，该名称空间可用于区分由多个组织提供且具有不同语义的术语。
To further differentiate category types used in ROLIE, an IANA subregistry has been established for ROLIE protocol parameters to support the registration of new category "scheme" attribute values by ROLIE extension specifications. The use of this extension point is discussed in Section 8.3, using the "name" field with a type parameter of "category" to indicate a category extension.
为了进一步区分ROLIE中使用的类别类型，已为ROLIE协议参数建立了IANA子区域，以支持通过ROLIE扩展规范注册新类别“方案”属性值。第8.3节讨论了此扩展点的使用，使用类型参数为“category”的“name”字段表示类别扩展。
A ROLIE-specific extension point is provided through the "atom:category" element's "scheme" attribute value "urn:ietf:params:rolie:category:information-type". This value is a Uniform Resource Name (URN) [RFC8141] that is registered with IANA as described in Section 8.3. When used as the "scheme" attribute in this way, the "term" attribute is expected to be a registered value as defined in Section 8.4. Through this mechanism, a given security automation information type can be used to:
通过“atom:category”元素的“scheme”属性值“urn:ietf:params:ROLIE:category:information type”提供特定于ROLIE的扩展点。该值是一个统一资源名（URN）[RFC8141]，如第8.3节所述在IANA注册。当以这种方式用作“方案”属性时，“术语”属性应为第8.4节中定义的注册值。通过此机制，给定的安全自动化信息类型可用于：
1. identify that an "app:collection" element in a Service Document points to an Atom Feed that contains Entries pertaining to a specific type of security automation information (see Section 5.1.2),
1. 确定服务文档中的“app:collection”元素指向Atom提要，该提要包含与特定类型的安全自动化信息相关的条目（请参见第5.1.2节），
2. identify that an "atom:feed" element in an Atom Feed contains Entries pertaining to a specific type of security automation information (see Section 6.1.1), or
2. 确定atom提要中的“atom:feed”元素包含与特定类型的安全自动化信息相关的条目（请参见第6.1.1节），或者
3. identify the information type of a standalone resource (see Section 6.2.5).
3. 确定独立资源的信息类型（见第6.2.5节）。
For example, the notional security automation information type "incident" would be identified as follows:
例如，概念上的安全自动化信息类型“事件”将标识如下：
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>
A security automation information type represents a class of information that represents the same or similar information model [RFC3444]. Note that this document does not register any information types but offers the following as examples of potential information types:
安全自动化信息类型表示表示相同或类似信息模型的一类信息[RFC3444]。请注意，本文档未注册任何信息类型，但提供了以下潜在信息类型示例：
indicator: Computing device- or network-related "observable features and phenomenon that aid in the forensic or proactive detection of malicious activity and associated metadata" (from [RFC7970]).
指标：与计算设备或网络相关的“可观察的特征和现象，有助于对恶意活动和相关元数据进行取证或主动检测”（来自[RFC7970]）。
incident: Information pertaining to or derived from security incidents.
事件：与安全事件有关或源自安全事件的信息。
vulnerability reports: Information identifying and describing a vulnerability in hardware or software.
漏洞报告：识别和描述硬件或软件中漏洞的信息。
configuration checklists: Content that can be used to assess the configuration settings related to installed software.
配置检查列表：可用于评估与已安装软件相关的配置设置的内容。
software tags: Metadata used to identify and characterize installable software.
软件标签：用于识别和描述可安装软件的元数据。
This is a short list to inspire new engineering of information type extensions that support the automation of security processes.
这是一个简短的列表，旨在激发支持安全过程自动化的信息类型扩展的新工程。
This document does not specify any information types. Instead, information types in ROLIE are expected to be registered in extension documents that describe one or more new information types. This allows the information types used by ROLIE implementations to grow over time to support new security automation use cases. These extension documents may also enhance ROLIE Service, Category, Feed, and Entry Documents by defining link relations, other categories, and Format data model extensions to address the representational needs of these specific information types. New information types are added to ROLIE through registrations to the IANA "ROLIE Information Types" registry defined in Section 8.4.
本文档未指定任何信息类型。相反，ROLIE中的信息类型应该在描述一种或多种新信息类型的扩展文档中注册。这允许ROLIE实现使用的信息类型随着时间的推移而增长，以支持新的安全自动化用例。这些扩展文档还可以通过定义链接关系、其他类别和格式数据模型扩展来增强ROLIE服务、类别、提要和条目文档，以满足这些特定信息类型的代表性需求。通过注册第8.4节定义的IANA“ROLIE信息类型”注册，新信息类型被添加到ROLIE。
Security automation data pertaining to a given information type may be expressed using a number of supported formats. As described in Section 6.2.3, the "rolie:format" element is used to describe the specific data model used to represent the resource referenced by a given "atom:entry". The structure provided by the "rolie:format" element provides a mechanism for extension within the "atom:entry" model. ROLIE extensions MAY further restrict which data models are allowed to be used for a given information type.
与给定信息类型相关的安全自动化数据可以使用许多支持的格式表示。如第6.2.3节所述，“rolie:format”元素用于描述用于表示给定“atom:entry”引用的资源的特定数据模型。“rolie:format”元素提供的结构为“atom:entry”模型中的扩展提供了一种机制。ROLIE扩展可能进一步限制允许对给定信息类型使用哪些数据模型。
By declaring the data model used for a given resource, a consumer can choose to download or ignore the resource, or look for alternate formats. This saves the consumer from downloading and parsing resources that the consumer is not interested in or resources expressed in formats that are not supported by the consumer.
通过声明用于给定资源的数据模型，使用者可以选择下载或忽略资源，或者寻找替代格式。这样可以避免使用者下载和解析使用者不感兴趣的资源或以使用者不支持的格式表示的资源。
This document uses several link relations defined in the IANA "Link Relation Types" registry at <https://www.iana.org/assignments/link-relations/>. Additional link relations can be registered in this registry to allow new relationships to be represented in ROLIE according to Section 4.2.7.2 of [RFC4287]. Based on the preceding reference, if the link relation is too specific or limited in its intended use, an absolute URI can be used in lieu of registering a new simple name with IANA.
本文档使用IANA“链接关系类型”注册表中定义的多个链接关系<https://www.iana.org/assignments/link-relations/>. 根据[RFC4287]第4.2.7.2节，可以在此注册表中注册其他链接关系，以允许在ROLIE中表示新的关系。根据前面的参考，如果链接关系在其预期用途方面过于具体或有限，则可以使用绝对URI来代替向IANA注册新的简单名称。
As discussed previously in Section 6.2.3, many formats contain unique identifying and characterizing properties that are vital for sharing information. In order to provide a global reference for these properties, this document establishes an IANA registry that allows ROLIE extensions to register named properties using the "name" field with a type parameter of "property" to indicate a property extension; see Section 8.3. Implementations SHOULD prefer the use of registered properties over implementation-specific properties when possible.
如上文第6.2.3节所述，许多格式包含独特的识别和特征属性，这些属性对于共享信息至关重要。为了提供这些属性的全局引用，本文档建立了IANA注册表，允许ROLIE extensions使用“name”字段注册命名属性，并使用类型参数“property”表示属性扩展；见第8.3节。在可能的情况下，实现应该更喜欢使用注册的属性而不是实现特定的属性。
ROLIE extensions are expected to register new properties and use existing properties to provide valuable identifying and characterizing information for a given information type and/or format.
ROLIE extensions预计将注册新属性，并使用现有属性为给定信息类型和/或格式提供有价值的识别和特征化信息。
Any "rolie:property" element whose "name" attribute has "urn:ietf:params:rolie:property:local" as a prefix MUST be considered "Private Use" as defined in [RFC8126]. Implementations encountering such a property MUST parse the content without error but MAY otherwise ignore the element.
任何“rolie:property”元素，如果其“name”属性的前缀为“urn:ietf:params:rolie:property:local”，则必须将其视为[RFC8126]中定义的“专用”。遇到此类属性的实现必须无错误地解析内容，但可能会忽略元素。
This document also registers a number of general-use properties that can be used to expose content information in any ROLIE use case. The following are descriptions of how to use these registered properties:
本文档还注册了一些通用属性，可用于在任何ROLIE用例中公开内容信息。以下是如何使用这些注册属性的说明：
urn:ietf:params:rolie:property:content-author-name The "value" attribute of this property is a text representation indicating the individual or organization that authored the content referenced by the "src" attribute of the Entry's "atom:content" element. This author may differ from the "atom:author" element when the author of the content and the author of the Entry are different people or entities.
urn:ietf:params:rolie:property:content author name此属性的“value”属性是一种文本表示形式，表示编写条目“atom:content”元素的“src”属性所引用内容的个人或组织。当内容的作者和条目的作者是不同的人或实体时，此作者可能不同于“atom:author”元素。
urn:ietf:params:rolie:property:content-id The "value" attribute of this property is a text representation of an identifier pertaining to or extracted from the content referenced by the "src" attribute of the Entry's "atom:content" element. For example, if the "atom:entry"'s "atom:content" element links to an IODEF document, the "content-id" value would be an identifier of that IODEF document.
urn:ietf:params:rolie:property:content-id此属性的“value”属性是一个标识符的文本表示形式，该标识符与条目的“atom:content”元素的“src”属性所引用的内容相关或从中提取。例如，如果“atom:entry”的“atom:content”元素链接到IODEF文档，“content id”值将是该IODEF文档的标识符。
urn:ietf:params:rolie:property:content-published-date The "value" attribute of this property is a text representation indicating the original publication date of the content referenced by the "src" attribute of the Entry's "atom:content" element. This date may differ from the published date of the ROLIE Entry because publication of the content and publication of the ROLIE Entry represent different events. The date MUST be formatted as specified in [RFC3339].
urn:ietf:params:rolie:property:content published date此属性的“value”属性是一种文本表示形式，表示条目的“atom:content”元素的“src”属性引用的内容的原始发布日期。该日期可能与ROLIE条目的发布日期不同，因为内容的发布和ROLIE条目的发布代表不同的事件。日期的格式必须符合[RFC3339]中的规定。
urn:ietf:params:rolie:property:content-updated-date The "value" attribute of this property is a text representation indicating the date that the content, referenced by the "src" attribute of the Entry's "atom:content" element, was last updated. This date may differ from the updated date of the ROLIE Entry because updates made to the content and to the ROLIE Entry are different events. The date MUST be formatted as specified in [RFC3339].
urn:ietf:params:rolie:property:content updated date此属性的“value”属性是一个文本表示形式，指示条目的“atom:content”元素的“src”属性引用的内容上次更新的日期。该日期可能与ROLIE条目的更新日期不同，因为内容和ROLIE条目的更新是不同的事件。日期的格式必须符合[RFC3339]中的规定。
This document has a number of IANA considerations, as described in the following subsections.
本文件有许多IANA注意事项，如下小节所述。
This document uses URNs to describe XML namespaces and XML schemas conforming to the registry mechanism described in [RFC3688].
本文档使用URN来描述符合[RFC3688]中描述的注册表机制的XML名称空间和XML模式。
ROLIE XML Namespace: The ROLIE namespace (rolie-1.0) has been registered in the "ns" registry.
ROLIE XML命名空间：ROLIE命名空间（ROLIE-1.0）已在“ns”注册表中注册。
URI: urn:ietf:params:xml:ns:rolie-1.0
URI: urn:ietf:params:xml:ns:rolie-1.0
Registrant Contact: IESG
注册联系人：IESG
XML: None. Namespace URIs do not represent an XML specification.
XML：没有。命名空间URI不表示XML规范。
ROLIE XML Schema: The ROLIE schema (rolie-1.0) has been registered in the "schema" registry.
ROLIE XML模式：ROLIE模式（ROLIE-1.0）已在“模式”注册表中注册。
URI: urn:ietf:params:xml:schema:rolie-1.0
URI: urn:ietf:params:xml:schema:rolie-1.0
Registrant Contact: IESG
注册联系人：IESG
XML: See Appendix A of this document.
XML：见本文件附录A。
IANA has added an entry to the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry located at <https://www.iana.org/assignments/params/> as per [RFC3553].
IANA已在位于的“IETF URN注册协议参数标识符子命名空间”注册表中添加了一个条目<https://www.iana.org/assignments/params/>根据[RFC3553]。
The entry is as follows:
参赛作品如下：
Registered Parameter Identifier: rolie
注册参数标识符：rolie
Specification: This document
规格：本文件
Repository: ROLIE URN Parameters. See Section 8.3.
存储库：ROLIE URN参数。见第8.3节。
Index value: See Section 8.4.
索引值：见第8.4节。
A new top-level registry has been created, titled "Resource-Oriented Lightweight Information Exchange (ROLIE) URN Parameters".
创建了一个新的顶级注册表，名为“面向资源的轻量级信息交换（ROLIE）URN参数”。
Registration in the "ROLIE URN Parameters" subregistry is via the Specification Required policy [RFC8126]. Registration requests must be sent to both the MILE Working Group mailing list (mile@ietf.org) and IANA. IANA will forward registration requests to the Designated Expert.
通过规范要求政策[RFC8126]在“ROLIE URN参数”子区域注册。注册请求必须发送至MILE工作组和邮件列表(mile@ietf.org)还有伊安娜。IANA将把注册请求转发给指定的专家。
Each entry in this subregistry must record the following fields:
此子区域中的每个条目必须记录以下字段：
Name: A URN segment that adheres to the pattern {type}:{label}. The keywords are defined as follows:
名称：遵循模式{type}:{label}的URN段。关键字定义如下：
{type}: The parameter type. The allowed values are "category" or "property". "category" denotes a category extension as discussed in Section 7.1. "property" denotes a property extension as discussed in Section 7.4.
{type}：参数类型。允许的值为“类别”或“属性”。“类别”表示第7.1节中讨论的类别扩展。“财产”指第7.4节中讨论的财产扩展。
{label}: A required US-ASCII string that conforms to the URN syntax requirements (see [RFC8141]). This string must be unique within the namespace defined by the {type} keyword. The "local" label for both the "category" and "property" types has been reserved for private use.
{label}：符合URN语法要求的必需US-ASCII字符串（请参见[RFC8141]）。此字符串在{type}关键字定义的命名空间中必须是唯一的。“类别”和“财产”类型的“本地”标签已保留供私人使用。
Extension URI: The identifier to use within ROLIE, which is the full URN using the form "urn:ietf:params:rolie:{name}", where {name} is the "name" field of this registration.
扩展URI：要在ROLIE中使用的标识符，它是使用“URN:ietf:params:ROLIE:{name}”格式的完整URN，其中{name}是此注册的“name”字段。
Reference: A static link to the specification and section where the definition of the parameter can be found.
参考：一个静态链接，指向可以找到参数定义的规范和部分。
Subregistry: An optional field that links to an IANA subregistry for this parameter. If the {type} is "category", the subregistry must contain a "name" field whose registered values MUST be US-ASCII. The list of names are the allowed values of the "term" attribute in the "atom:category" element (see Section 7.1.2).
Subistry：链接到此参数的IANA Subistry的可选字段。如果{type}是“category”，则子区域必须包含一个“name”字段，其注册值必须是US-ASCII。名称列表是“atom:category”元素中“term”属性的允许值（见第7.1.2节）。
This repository has the following initial values:
此存储库具有以下初始值：
+--------------+------------------------+-------------+-------------+
| Name | Extension URI | Reference | Subregistry |
| | | (This | |
| | | Document) | |
+--------------+------------------------+-------------+-------------+
| category: | urn:ietf:params:rolie: | Section 8.4 | See |
| information- | category: | | Section 8.4 |
| type | information-type | | |
| | | | |
| | | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content- | property:content- | | |
| author-name | author-name | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content-id | property:content-id | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content- | property:content- | | |
| published- | published-date | | |
| date | | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content- | property:content- | | |
| updated-date | updated-date | | |
+--------------+------------------------+-------------+-------------+
+--------------+------------------------+-------------+-------------+
| Name | Extension URI | Reference | Subregistry |
| | | (This | |
| | | Document) | |
+--------------+------------------------+-------------+-------------+
| category: | urn:ietf:params:rolie: | Section 8.4 | See |
| information- | category: | | Section 8.4 |
| type | information-type | | |
| | | | |
| | | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content- | property:content- | | |
| author-name | author-name | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content-id | property:content-id | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content- | property:content- | | |
| published- | published-date | | |
| date | | | |
| | | | |
| property: | urn:ietf:params:rolie: | Section 7.4 | None |
| content- | property:content- | | |
| updated-date | updated-date | | |
+--------------+------------------------+-------------+-------------+
A new subregistry has been created to store ROLIE information type values.
已创建一个新的子区域来存储ROLIE信息类型值。
Name of Registry: "ROLIE Information Types"
注册表名称：“ROLIE信息类型”
Location of Registry:
<https://www.iana.org/assignments/rolie/>
Location of Registry:
<https://www.iana.org/assignments/rolie/>
Fields to record in the registry:
要在注册表中记录的字段：
Name: The full name of the security resource information type as a string from the printable ASCII character set [RFC20] with individual embedded spaces allowed. This value must be unique in the context of this table. The ABNF [RFC5234] syntax for this field is:
名称：安全资源信息类型的全名，作为可打印ASCII字符集[RFC20]中的字符串，允许使用单个嵌入空格。此值在此表的上下文中必须是唯一的。此字段的ABNF[RFC5234]语法为：
1*VCHAR *(SP 1*VCHAR)
1*VCHAR *(SP 1*VCHAR)
Index: An IANA-assigned positive integer that identifies the registration. The first entry added to this registry uses the value 1, and this value is incremented for each subsequent entry added to the registry.
索引：IANA分配的正整数，用于标识注册。添加到此注册表的第一个条目使用值1，并且对于添加到此注册表的每个后续条目，该值都会递增。
Reference: A list of one or more URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. The URI SHOULD be a stable reference.
参考：一个或多个URI[RFC3986]的列表，可从中获得注册规范。注册的规范必须随时可从该URI公开获取。URI应该是一个稳定的引用。
Allocation Policy: Specification Required, as per [RFC8126]
分配政策：根据[RFC8126]的规定，需要规范
This document defines a resource-oriented approach for lightweight information exchange using HTTP over TLS, the Atom Syndication Format, and AtomPub. As such, implementers must understand the security considerations described in those specifications. All that follows is guidance; instructions that are more specific are out of scope for this document.
本文档定义了使用HTTP over TLS、Atom联合格式和AtomPub进行轻量级信息交换的面向资源的方法。因此，实现者必须理解这些规范中描述的安全注意事项。接下来就是指导；更具体的说明超出了本文档的范围。
To protect the confidentiality of a given resource provided by a ROLIE implementation, requests for retrieval of the resource need to be authenticated to prevent unauthorized users from accessing the resource (see Section 5.4). It can also be useful to log and audit access to sensitive resources to verify that proper access controls remain in place over time.
为了保护ROLIE实现提供的给定资源的机密性，需要对资源检索请求进行身份验证，以防止未经授权的用户访问资源（参见第5.4节）。记录和审核对敏感资源的访问也很有用，以验证适当的访问控制随着时间的推移仍然有效。
Access control to information published using ROLIE should use mechanisms that are appropriate to the sensitivity of the information. Primitive authentication mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriate for sensitive information. A number of authentication schemes are defined in the "HTTP Authentication Schemes" registry at <https://www.iana.org/assignments/http-authschemes/>. Of these, HTTP Origin-Bound Authentication (HOBA) [RFC7486] and SCRAM-SHA-256 [RFC7804] ("SCRAM" stands for "Salted Challenge Response Authentication Mechanism") provide improved security properties over HTTP Basic [RFC7617]and Digest [RFC7616] authentication schemes. However, sharing communities that are engaged in sensitive collaborative analysis and/or operational response for indicators and incidents targeting high-value information systems should adopt a suitably stronger user authentication solution, such as a risk-based or multi-factor approach.
对使用ROLIE发布的信息的访问控制应使用适合信息敏感性的机制。像HTTP基本身份验证[RFC7617]这样的原始身份验证机制很少适用于敏感信息。在“HTTP身份验证方案”注册表中定义了许多身份验证方案<https://www.iana.org/assignments/http-authschemes/>. 其中，HTTP源绑定身份验证（HOBA）[RFC7486]和SCRAM-SHA-256[RFC7804]（“SCRAM”代表“salt质询-响应身份验证机制”）提供了比HTTP基本[RFC7617]和摘要[RFC7616]身份验证方案更好的安全性。但是，参与针对高价值信息系统的指标和事件的敏感协作分析和/或业务响应的共享社区应采用适当的更强有力的用户认证解决方案，例如基于风险或多因素的方法。
Collaborating consortiums may benefit from the adoption of a federated identity solution, such as those based upon OAuth [RFC6749] with the JSON Web Token (JWT) [RFC7797], or SAML-core [SAML-core] ("SAML" stands for "Security Assertion Markup Language"), SAML-bind [SAML-bind], and SAML-prof [SAML-prof] for web-based authentication and cross-organizational single sign-on. Dependency on a trusted third-party identity provider implies that appropriate care must be exercised to sufficiently secure the identity provider. Any attacks on the federated identity system would present a risk to the consortium, as a relying party. Potential mitigations include deployment of a federation-aware identity provider that is under the control of the information-sharing consortium, with suitably stringent technical and management controls.
合作联盟可能会受益于采用联邦身份解决方案，例如基于OAuth[RFC6749]和JSON Web令牌（JWT）[RFC7797]或SAML core[SAML core]（“SAML”代表“安全断言标记语言”）、SAML bind[SAML bind]和SAML prof[SAML prof]的联盟用于基于web的身份验证和跨组织单点登录。依赖受信任的第三方身份提供程序意味着必须采取适当的措施来充分保护身份提供程序。对联邦身份系统的任何攻击都会给作为依赖方的联合体带来风险。潜在的缓解措施包括部署由信息共享联盟控制的具有联邦意识的身份提供商，并实施适当严格的技术和管理控制。
Authorization of resource representations is the responsibility of the source system, i.e., based on the authenticated user identity associated with an HTTP(S) request. The required authorization policies that are to be enforced must therefore be managed by the security administrators of the source system. Various authorization architectures would be suitable for this purpose, such as Role-Based Access Control (RBAC) <https://csrc.nist.gov/projects/ role-based-access-control> and/or Attribute-Based Access Control (ABAC), as embodied in the eXtensible Access Control Markup Language (XACML) [XACML]. In particular, implementers adopting XACML may benefit from the capability to represent their authorization policies in a standardized, interoperable format. Note that implementers are free to choose any suitable authorization mechanism that is capable of fulfilling the policy enforcement requirements relevant to their consortium and/or organization.
资源表示的授权是源系统的责任，即基于与HTTP（S）请求相关联的经过身份验证的用户标识。因此，要强制执行的所需授权策略必须由源系统的安全管理员管理。各种授权体系结构都适用于此目的，例如基于角色的访问控制（RBAC）<https://csrc.nist.gov/projects/ 基于角色的访问控制>和/或基于属性的访问控制（ABAC），具体体现在可扩展访问控制标记语言（XACML）[XACML]中。特别是，采用XACML的实现者可以受益于以标准化、互操作的格式表示其授权策略的能力。请注意，实施者可以自由选择能够满足与其联盟和/或组织相关的策略实施要求的任何适当授权机制。
Additional security requirements such as enforcing message-level security at the destination system could supplement the security enforcements performed at the source system; however, these destination-provided policy enforcements are out of scope for this specification. Implementers requiring this capability should consider leveraging, for example, the <RIDPolicy> element in the RID schema. Refer to Section 9 of [RFC6545] for more information. Additionally, the underlying serialization approach used in the representation (e.g., XML, JSON) can offer encryption and message authentication capabilities. For example, XML Digital Signatures (XMLDSIG) [RFC3275] for XML, as well as JSON Web Encryption [RFC7516] and JSON Web Signature [RFC7515] for JSON, can provide such mechanisms.
附加的安全要求，如在目的地系统强制执行消息级安全，可以补充在源系统执行的安全强制；但是，这些目标提供的策略实施超出了本规范的范围。需要这种能力的实现者应该考虑杠杆效应，例如，RID模式中的<RIDPrase>元素。更多信息，请参阅[RFC6545]第9节。此外，表示中使用的底层序列化方法（例如，XML、JSON）可以提供加密和消息身份验证功能。例如，XML的XML数字签名（XMLDSIG）[RFC3275]以及JSON的JSON Web加密[RFC7516]和JSON Web签名[RFC7515]可以提供这样的机制。
When security policies relevant to the source system are to be enforced at both the source and destination systems, implementers must take care to avoid unintended interactions of the separately enforced policies. Potential risks will include unintended denial of service and/or unintended information leakage. These problems may be mitigated by avoiding any dependence upon enforcements performed at the destination system. When distributed enforcement is unavoidable, the usage of a standard language (e.g., XACML) for the expression of authorization policies will enable the source and destination systems to better coordinate and align their respective policy expressions.
当与源系统相关的安全策略要在源系统和目标系统上实施时，实现者必须注意避免单独实施的策略的意外交互。潜在风险包括意外拒绝服务和/或意外信息泄漏。这些问题可以通过避免对在目的地系统执行的强制的任何依赖来缓解。当分布式强制不可避免时，使用标准语言（如XACML）表达授权策略将使源系统和目标系统能够更好地协调和调整各自的策略表达式。
A service discovery mechanism is not explicitly specified in this document, but there are several approaches available for implementers. When selecting this mechanism, implementations need to ensure that their choice provides a means for authenticating the server. DNS SRV records [RFC2782] are a possible solution to the discovery problem described in Section 5.1.3.
本文档中未明确指定服务发现机制，但有几种方法可供实现者使用。选择此机制时，实现需要确保其选择提供了验证服务器的方法。DNS SRV记录[RFC2782]是第5.1.3节所述发现问题的可能解决方案。
The optional "author" field may provide an identification privacy issue if populated without the author's consent. This information may become public if posted to a public Feed. When aggregating or sharing Entries from other Feeds or when programmatically generating ROLIE Entries from some data source, special care should be taken to ensure that the author's personal information is not shared without the author's consent.
如果未经作者同意而填充，可选的“作者”字段可能会提供身份隐私问题。如果发布到公共提要，此信息可能会公开。当聚合或共享来自其他提要的条目时，或者从某些数据源以编程方式生成ROLIE条目时，应特别注意确保未经作者同意，不得共享作者的个人信息。
When using AtomPub to POST Entries to a Feed, attackers may use correlating techniques to profile the user. The request time can be compared to the generated "updated" field of the Entry in order to build out information about a given user. This correlation attempt can be mitigated by not using HTTP requests to POST Entries when profiling is a risk and instead using backend control of the Feeds.
当使用AtomPub向提要发布条目时，攻击者可能会使用相关技术来分析用户。可以将请求时间与条目中生成的“更新”字段进行比较，以构建关于给定用户的信息。当分析存在风险时，不使用HTTP请求发布条目，而是使用提要的后端控制，可以减轻这种关联尝试。
Adoption of the information-sharing approach described in this document will enable users to more easily perform correlations across separate, and potentially unrelated, cybersecurity information providers. A client may succeed in assembling a data set that would not have been permitted within the context of the authorization policies of either provider when considered individually. Thus, providers may face a risk of an attacker obtaining an access that constitutes an undetected separation of duties (SOD) violation. It is important to note that this risk is not unique to this specification, and a similar potential for abuse exists with any other cybersecurity information-sharing protocol. However, the wide availability of tools for HTTP clients and Atom Feed handling implies that the resources and technical skills required for a successful exploit may be less than it was previously. This risk can be best mitigated through appropriate vetting of the client at the time of account provisioning. In addition, any increase in the risk of this type of abuse should be offset by the corresponding increase in effectiveness that this specification affords to the defenders.
采用本文档中描述的信息共享方法将使用户能够更轻松地跨独立且可能不相关的网络安全信息提供商进行关联。当单独考虑时，客户机可能会成功组装在任一提供商的授权策略上下文中都不允许的数据集。因此，提供商可能面临攻击者获得构成未检测到的违反职责分离（SOD）的访问权限的风险。需要注意的是，该风险并非本规范所独有，任何其他网络安全信息共享协议也存在类似的滥用可能性。然而，HTTP客户端和Atom提要处理工具的广泛可用性意味着成功利用此漏洞所需的资源和技术技能可能比以前少。通过在帐户设置时对客户进行适当的审查，可以最好地降低此风险。此外，这类滥用风险的任何增加都应通过本规范为辩护人提供的有效性的相应增加予以抵消。
Overall, privacy concerns in ROLIE can be mitigated by following security considerations and by the careful use of the optional personally identifying elements (e.g., author) provided by Atom Syndication and ROLIE.
总的来说，ROLIE中的隐私问题可以通过以下安全考虑和谨慎使用Atom Syndication和ROLIE提供的可选个人识别元素（如作者）来缓解。
[RELAX-NG] Clark, J., Ed., "RELAX NG Compact Syntax", November 2002, <https://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[RELAX-NG]Clark，J.，Ed.，“RELAX-NG紧凑语法”，2002年11月<https://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<https://www.rfc-editor.org/info/rfc20>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<https://www.rfc-editor.org/info/rfc2045>.
[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>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<https://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，DOI 10.17487/RFC3553，2003年6月<https://www.rfc-editor.org/info/rfc3553>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[RFC4287] Nottingham, M., Ed., and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4287]诺丁汉，M.，Ed.，和R.Sayre，Ed.，“原子联合格式”，RFC 4287，DOI 10.17487/RFC4287，2005年12月<https://www.rfc-editor.org/info/rfc4287>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, DOI 10.17487/RFC5005, September 2007, <https://www.rfc-editor.org/info/rfc5005>.
[RFC5005]诺丁汉，M.，“提要分页和归档”，RFC 5005，DOI 10.17487/RFC5005，2007年9月<https://www.rfc-editor.org/info/rfc5005>.
[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>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, DOI 10.17487/RFC6546, April 2012, <https://www.rfc-editor.org/info/rfc6546>.
[RFC6546]特拉梅尔，B.，“通过HTTP/TLS传输实时网络间防御（RID）消息”，RFC 6546，DOI 10.17487/RFC6546，2012年4月<https://www.rfc-editor.org/info/rfc6546>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC7970]Danyliw，R.，“事件对象描述交换格式版本2”，RFC 7970，DOI 10.17487/RFC7970，2016年11月<https://www.rfc-editor.org/info/rfc7970>.
[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>.
[W3C.REC-xml-names-20091208] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <https://www.w3.org/TR/2009/ REC-xml-names-20091208>.
[W3C.REC-xml-names-20091208]Bray，T.，Hollander，D.，Layman，A.，Tobin，R.，和H.Thompson，“xml 1.0中的名称空间（第三版）”，万维网联盟建议REC-xml-names-20091208，2009年12月<https://www.w3.org/TR/2009/ REC-xml-names-20091208>。
[Err3267] RFC Errata, Erratum ID 3267, RFC 6546, <https://www.rfc-editor.org/errata/eid3267>.
[Err3267]RFC勘误表，勘误表ID 3267，RFC 6546<https://www.rfc-editor.org/errata/eid3267>.
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, <http://www.ics.uci.edu/~fielding/pubs/ dissertation/top.htm>.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，2000年<http://www.ics.uci.edu/~fielding/pubs/demission/top.htm>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, DOI 10.17487/RFC3275, March 2002, <https://www.rfc-editor.org/info/rfc3275>.
[RFC3275]Eastlake 3rd，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC 3275，DOI 10.17487/RFC3275，2002年3月<https://www.rfc-editor.org/info/rfc3275>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444]Pras，A.和J.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，DOI 10.17487/RFC3444，2003年1月<https://www.rfc-editor.org/info/rfc3444>.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, DOI 10.17487/RFC6545, April 2012, <https://www.rfc-editor.org/info/rfc6545>.
[RFC6545]Moriarty，K.，“实时网络间防御（RID）”，RFC 6545，DOI 10.17487/RFC65452012年4月<https://www.rfc-editor.org/info/rfc6545>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<https://www.rfc-editor.org/info/rfc6749>.
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <https://www.rfc-editor.org/info/rfc7486>.
[RFC7486]Farrell，S.，Hoffman，P.和M.Thomas，“HTTP源绑定身份验证（HOBA）”，RFC 7486，DOI 10.17487/RFC7486，2015年3月<https://www.rfc-editor.org/info/rfc7486>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<https://www.rfc-editor.org/info/rfc7516>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
[RFC7617]Reschke，J.“基本”HTTP认证方案”，RFC 7617，DOI 10.17487/RFC76172015年9月<https://www.rfc-editor.org/info/rfc7617>.
[RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, <https://www.rfc-editor.org/info/rfc7797>.
[RFC7797]Jones，M.，“JSON Web签名（JWS）未编码有效负载选项”，RFC 7797，DOI 10.17487/RFC7797，2016年2月<https://www.rfc-editor.org/info/rfc7797>.
[RFC7804] Melnikov, A., "Salted Challenge Response HTTP Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, March 2016, <https://www.rfc-editor.org/info/rfc7804>.
[RFC7804]Melnikov，A.，“盐渍挑战响应HTTP认证机制”，RFC 7804，DOI 10.17487/RFC7804，2016年3月<https://www.rfc-editor.org/info/rfc7804>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.
[RFC8141]Saint Andre，P.和J.Klensin，“统一资源名称（URN）”，RFC 8141，DOI 10.17487/RFC81412017年4月<https://www.rfc-editor.org/info/rfc8141>.
[SAML-bind] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-bindings-2.0-os, March 2005, <http://docs.oasis-open.org/ security/saml/v2.0/saml-bindings-2.0-os.pdf>.
[SAML bind]Cantor，S.，Hirsch，F.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（SAML）V2.0的绑定”，OASIS标准SAML-Bindings-2.0-os，2005年3月<http://docs.oasis-open.org/ security/saml/v2.0/saml-bindings-2.0-os.pdf>。
[SAML-core] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/ security/saml/v2.0/saml-core-2.0-os.pdf>.
[SAML core]Cantor，S.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（SAML）V2.0的断言和协议”，OASIS标准SAML-core-2.0-os，2005年3月<http://docs.oasis-open.org/ security/saml/v2.0/saml-core-2.0-os.pdf>。
[SAML-prof] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-profiles-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-profiles-2.0-os.pdf>.
[SAML prof]Hughes，J.，Cantor，S.，Hodges，J.，Hirsch，F.，Mishra，P.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（SAML）V2.0的配置文件”，OASIS标准SAML-Profiles-2.0-os，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-profiles-2.0-os.pdf>。
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-23, January 2018.
[TLS-1.3]Rescorla，E.“传输层安全（TLS）协议版本1.3”，正在进行的工作，草案-ietf-TLS-tls13-23，2018年1月。
[XACML] Rissanen, E., "eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01", July 2017, <http://docs.oasis-open.org/xacml/3.0/ xacml-3.0-core-spec-en.pdf>.
[XACML]Rissanen，E.“可扩展访问控制标记语言（XACML）3.0版加勘误表01”，2017年7月<http://docs.oasis-open.org/xacml/3.0/ xacml-3.0-core-spec-en.pdf>。
This appendix is informative.
本附录为资料性附录。
The RELAX NG schema below defines the "rolie:format" element.
下面的RELAXNG模式定义了“rolie:format”元素。
# -*- rnc -*-
# RELAX NG Compact Syntax Grammar for the rolie ns
# -*- rnc -*-
# RELAX NG Compact Syntax Grammar for the rolie ns
namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0"
namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0"
# import the ATOM Syndication RELAX NG Compact Syntax Grammar include "atomsynd.rnc"
#导入ATOM Syndication RELAXNG压缩语法，包括“atomsynd.rnc”
# rolie:format
rolieFormat =
element rolie:format {
atomCommonAttributes,
attribute ns { atomUri },
attribute version { text } ?,
attribute schema-location { atomUri } ?,
attribute schema-type { atomMediaType } ?,
empty
}
# rolie:format
rolieFormat =
element rolie:format {
atomCommonAttributes,
attribute ns { atomUri },
attribute version { text } ?,
attribute schema-location { atomUri } ?,
attribute schema-type { atomMediaType } ?,
empty
}
# rolie:property
#罗莉：财产
rolieProperty =
element rolie:property {
atomCommonAttributes,
attribute name { atomUri },
attribute value { text },
empty
}
rolieProperty =
element rolie:property {
atomCommonAttributes,
attribute name { atomUri },
attribute value { text },
empty
}
This appendix provides a non-normative example of a client doing service discovery.
本附录提供了一个客户进行服务发现的非规范性示例。
An Atom Service Document enables a client to dynamically discover what Feeds a particular publisher makes available. Thus, a provider uses an Atom Service Document to enable authorized clients to determine what specific information the provider makes available to
Atom服务文档使客户端能够动态发现特定发布者提供的提要。因此，提供者使用Atom服务文档使授权客户端能够确定提供者提供给用户的特定信息
the community. The Service Document should be made accessible from an easily found location, such as a link from the producer's home page.
社区。服务文档应该可以从一个容易找到的位置访问，例如从制作人主页的链接。
A client may format an HTTP GET request to retrieve the Service Document from the specified location:
客户端可以格式化HTTP GET请求以从指定位置检索服务文档：
GET /rolie/servicedocument
Host: www.example.org
Accept: application/atomsvc+xml
GET /rolie/servicedocument
Host: www.example.org
Accept: application/atomsvc+xml
Notice the use of the HTTP Accept: request header, indicating the MIME type for Atom service discovery. The response to this GET request will be an XML document that contains information on the specific Collections that are provided.
请注意HTTP Accept:request标头的使用，它指示Atom服务发现的MIME类型。对此GET请求的响应将是一个XML文档，其中包含有关所提供的特定集合的信息。
Example HTTP GET response:
HTTP GET响应示例：
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:09:11 GMT
Content-Length: 570
Content-Type: application/atomsvc+xml;charset="utf-8"
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:09:11 GMT
Content-Length: 570
Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="https://www.w3.org/2007/app"
xmlns:atom="https://www.w3.org/2005/Atom">
<workspace>
<atom:title type="text">Vulnerabilities</atom:title>
<collection href="https://example.org/provider/vulns">
<atom:title type="text">Vulnerabilities Feed</atom:title>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
</categories>
</collection>
</workspace>
</service>
<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="https://www.w3.org/2007/app"
xmlns:atom="https://www.w3.org/2005/Atom">
<workspace>
<atom:title type="text">Vulnerabilities</atom:title>
<collection href="https://example.org/provider/vulns">
<atom:title type="text">Vulnerabilities Feed</atom:title>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
</categories>
</collection>
</workspace>
</service>
This simple Service Document example shows that the server provides one workspace, named "Vulnerabilities". Within that workspace, the server makes one Collection available.
这个简单的服务文档示例显示服务器提供了一个名为“漏洞”的工作区。在该工作区内，服务器使一个集合可用。
A server may also offer a number of different Collections, each containing different types of security automation information. In the following example, a number of different Collections are provided, each with its own category and authorization scope. This categorization will help the clients to decide which Collections will meet their needs.
服务器还可以提供许多不同的集合，每个集合包含不同类型的安全自动化信息。在下面的示例中，提供了许多不同的集合，每个集合都有自己的类别和授权范围。这种分类将帮助客户决定哪些集合将满足他们的需求。
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:10:11 GMT
Content-Length: 1912
Content-Type: application/atomsvc+xml;charset="utf-8"
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:10:11 GMT
Content-Length: 1912
Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="https://www.w3.org/2007/app"
xmlns:atom="https://www.w3.org/2005/Atom">
<workspace>
<atom:title>Public Security Information Sharing</atom:title>
<collection
href="https://example.org/provider/public/vulns">
<atom:title>Public Vulnerabilities</atom:title>
<atom:link rel="service"
href="https://example.org/rolie/servicedocument"/>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
</categories>
</collection>
</workspace>
<workspace>
<atom:title>Private Consortium Sharing</atom:title>
<collection
href="https://example.org/provider/private/incidents">
<atom:title>Incidents</atom:title>
<atom:link rel="service"
href="https://example.org/rolie/servicedocument"/>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>
</categories>
</collection>
</workspace>
</service>
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="https://www.w3.org/2007/app"
xmlns:atom="https://www.w3.org/2005/Atom">
<workspace>
<atom:title>Public Security Information Sharing</atom:title>
<collection
href="https://example.org/provider/public/vulns">
<atom:title>Public Vulnerabilities</atom:title>
<atom:link rel="service"
href="https://example.org/rolie/servicedocument"/>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
</categories>
</collection>
</workspace>
<workspace>
<atom:title>Private Consortium Sharing</atom:title>
<collection
href="https://example.org/provider/private/incidents">
<atom:title>Incidents</atom:title>
<atom:link rel="service"
href="https://example.org/rolie/servicedocument"/>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>
</categories>
</collection>
</workspace>
</service>
In this example, the provider is making available a total of two Collections, organized into two different workspaces. The first workspace contains a Collection consisting of publicly available software vulnerabilities. The second workspace provides an incident Collection for use by a private sharing consortium. An appropriately authenticated and authorized client may then proceed to make HTTP requests for these Collections. The publicly provided vulnerability information may be accessible with or without authentication. However, users accessing the Collection restricted to authorized members of a private sharing consortium are expected to authenticate before access is allowed.
在本例中，提供程序将总共提供两个集合，并将它们组织到两个不同的工作区中。第一个工作区包含由公开可用的软件漏洞组成的集合。第二个工作区提供事件集合，供私人共享联盟使用。然后，经过适当身份验证和授权的客户端可以继续对这些集合发出HTTP请求。公开提供的漏洞信息可以通过身份验证或不通过身份验证进行访问。但是，仅限私人共享联盟授权成员访问集合的用户在允许访问之前需要进行身份验证。
This appendix provides a non-normative example of a client retrieving a vulnerability Feed.
本附录提供了客户端检索漏洞源的非规范性示例。
Having discovered the available Collections that share security information, a client who is a member of the general public may be interested in receiving the Collection of public vulnerabilities, expressed as Common Vulnerabilities and Exposures (CVEs). The client may retrieve the Feed for this Collection by performing an HTTP GET operation on the URL indicated by the Collection's "href" attribute.
发现共享安全信息的可用集合后，作为普通公众成员的客户可能有兴趣接收公共漏洞集合，表示为常见漏洞和暴露（CVE）。客户端可以通过对集合的“href”属性指示的URL执行HTTP GET操作来检索此集合的提要。
Example HTTP GET request for a Feed:
提要的HTTP GET请求示例：
GET /provider/public/vulns
Host: www.example.org
Accept: application/atom+xml
GET /provider/public/vulns
Host: www.example.org
Accept: application/atom+xml
The corresponding HTTP response would be an XML document containing the vulnerability Feed:
相应的HTTP响应将是包含漏洞源的XML文档：
Example HTTP GET response for a Feed:
提要的HTTP GET响应示例：
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:20:11 GMT
Content-Length: 2882
Content-Type: application/atom+xml;charset="utf-8"
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:20:11 GMT
Content-Length: 2882
Content-Type: application/atom+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="https://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
xml:lang="en-US">
<id>2a7e265a-39bc-43f2-b711-b8fd9264b5c9</id>
<title type="text">
Atom-formatted representation of
a Feed of XML vulnerability documents
</title>
<category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
<updated>2016-05-04T18:13:51.0Z</updated>
<link rel="self"
href="https://example.org/provider/public/vulns"/>
<link rel="service"
href="https://example.org/rolie/servicedocument"/>
<entry>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<id>dd786dba-88e6-440b-9158-b8fae67ef67c</id>
<title>Sample Vulnerability</title>
<published>2015-08-04T18:13:51.0Z</published>
<updated>2015-08-05T18:13:51.0Z</updated>
<summary>A vulnerability issue identified by CVE-...</summary>
<content type="application/xml"
src="https://example.org/provider/vulns/123456/data"/>
</entry>
<entry>
<!-- ...another entry... -->
</entry>
</feed>
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="https://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
xml:lang="en-US">
<id>2a7e265a-39bc-43f2-b711-b8fd9264b5c9</id>
<title type="text">
Atom-formatted representation of
a Feed of XML vulnerability documents
</title>
<category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
<updated>2016-05-04T18:13:51.0Z</updated>
<link rel="self"
href="https://example.org/provider/public/vulns"/>
<link rel="service"
href="https://example.org/rolie/servicedocument"/>
<entry>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<id>dd786dba-88e6-440b-9158-b8fae67ef67c</id>
<title>Sample Vulnerability</title>
<published>2015-08-04T18:13:51.0Z</published>
<updated>2015-08-05T18:13:51.0Z</updated>
<summary>A vulnerability issue identified by CVE-...</summary>
<content type="application/xml"
src="https://example.org/provider/vulns/123456/data"/>
</entry>
<entry>
<!-- ...another entry... -->
</entry>
</feed>
This Feed Document has two Atom Entries, one of which has been elided. The first Entry illustrates an "atom:entry" element that provides a summary of essential details about one particular vulnerability. Based upon this summary information and the provided
此提要文档有两个Atom条目，其中一个已被省略。第一个条目说明了一个“atom:Entry”元素，该元素提供了关于一个特定漏洞的基本细节的摘要。基于此摘要信息和提供的
category information, a client may choose to do an HTTP GET request on the content "src" attribute to retrieve the full details of the vulnerability.
类别信息，客户端可以选择对内容“src”属性执行HTTP GET请求，以检索漏洞的完整详细信息。
This appendix provides a non-normative example of a client retrieving a vulnerability as an Atom Entry.
本附录提供了一个非规范性示例，说明客户端将漏洞检索为Atom条目。
Having retrieved the Feed of interest, the client may then decide, based on the description and/or category information, that one of the Entries in the Feed is of further interest. The client may retrieve this vulnerability Entry by performing an HTTP GET operation on the URL indicated by the "src" attribute of the "atom:content" element.
在检索到感兴趣的提要之后，客户机随后可以基于描述和/或类别信息来决定提要中的条目之一是进一步感兴趣的。客户端可以通过对“atom:content”元素的“src”属性所指示的URL执行HTTP GET操作来检索此漏洞条目。
Example HTTP GET request for an Entry:
对条目的HTTP GET请求示例：
GET /provider/public/vulns/123456
Host: www.example.org
Accept: application/atom+xml;type=entry
GET /provider/public/vulns/123456
Host: www.example.org
Accept: application/atom+xml;type=entry
The corresponding HTTP response would be an XML document containing the Atom Entry for the vulnerability record:
相应的HTTP响应将是一个XML文档，其中包含漏洞记录的Atom条目：
Example HTTP GET response for an Entry:
条目的HTTP GET响应示例：
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:30:11 GMT
Content-Length: 713
Content-Type: application/atom+xml;type=entry;charset="utf-8"
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2016 17:30:11 GMT
Content-Length: 713
Content-Type: application/atom+xml;type=entry;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="https://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
xml:lang="en-US">
<id>f63aafa9-4082-48a3-9ce6-97a2d69d4a9b</id>
<title>Sample Vulnerability</title>
<published>2015-08-04T18:13:51.0Z</published>
<updated>2015-08-05T18:13:51.0Z</updated>
<category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
<summary>A vulnerability issue identified by CVE-...</summary>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<content type="application/xml"
src="https://example.org/provider/vulns/123456/data">
</content>
</entry>
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="https://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
xml:lang="en-US">
<id>f63aafa9-4082-48a3-9ce6-97a2d69d4a9b</id>
<title>Sample Vulnerability</title>
<published>2015-08-04T18:13:51.0Z</published>
<updated>2015-08-05T18:13:51.0Z</updated>
<category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
<summary>A vulnerability issue identified by CVE-...</summary>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<content type="application/xml"
src="https://example.org/provider/vulns/123456/data">
</content>
</entry>
The example response above shows an XML document referenced by the "src" attribute of the "atom:content" element. The client may retrieve the document using this URL.
上面的响应示例显示了由“atom:content”元素的“src”属性引用的XML文档。客户端可以使用此URL检索文档。
Acknowledgements
致谢
The authors gratefully acknowledge the valuable contributions of Tom Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These individuals provided detailed review comments on earlier draft versions of this document and made many suggestions that have helped to improve this document.
作者衷心感谢Tom Maguire、Kathleen Moriarty和Vijayanand Bharadwaj的宝贵贡献。这些人对本文件的早期草案提出了详细的审查意见，并提出了许多有助于改进本文件的建议。
The authors would also like to thank the MILE Working Group, the SACM Working Group, and countless other people from both within the IETF community and outside of it for their excellent review and effort towards constructing this document.
作者还想感谢MILE工作组、SACM工作组以及IETF社区内外无数其他人，感谢他们对构建本文件所做的出色审查和努力。
Authors' Addresses
作者地址
John P. Field Pivotal Software, Inc. 625 Avenue of the Americas New York, New York 10011 United States of America
John P.Field Pivotal Software，Inc.美国纽约市美洲大道625号美国纽约10011
Phone: (646)792-5770 Email: jfield@pivotal.io
电话：（646）792-5770电子邮件：jfield@pivotal.io
Stephen A. Banghart National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 United States of America
Stephen A.Banghart美国马里兰州盖瑟斯堡路100号国家标准与技术研究所，邮编：20877
Phone: (301)975-4288 Email: stephen.banghart@nist.gov
电话：（301）975-4288电子邮件：斯蒂芬。banghart@nist.gov
David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 United States of America
David Waltermire国家标准与技术研究所美国马里兰州盖瑟斯堡路100号局，邮编：20877
Email: david.waltermire@nist.gov
Email: david.waltermire@nist.gov