Internet Engineering Task Force (IETF) B. Niven-Jenkins
Request for Comments: 8006 R. Murray
Category: Standards Track Nokia
ISSN: 2070-1721 M. Caulfield
Cisco Systems
K. Ma
Ericsson
December 2016
Internet Engineering Task Force (IETF) B. Niven-Jenkins
Request for Comments: 8006 R. Murray
Category: Standards Track Nokia
ISSN: 2070-1721 M. Caulfield
Cisco Systems
K. Ma
Ericsson
December 2016
Content Delivery Network Interconnection (CDNI) Metadata
内容交付网络互连（CDNI）元数据
Abstract
摘要
The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.
内容交付网络互连（CDNI）元数据接口使互连的内容交付网络（CDN）能够交换内容分发元数据，以实现内容获取和交付。与内容片段相关联的CDNI元数据为下游CDN提供足够的信息，以便下游CDN代表上游CDN服务内容请求。本文档描述了CDNI元数据的基本集和交换该元数据的协议。
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 http://www.rfc-editor.org/info/rfc8006.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8006.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Terminology ................................................5
1.2. Supported Metadata Capabilities ............................6
2. Design Principles ...............................................7
3. CDNI Metadata Object Model ......................................8
3.1. HostIndex, HostMatch, HostMetadata, PathMatch,
PatternMatch, and PathMetadata Objects .....................9
3.2. Generic CDNI Metadata Objects .............................11
3.3. Metadata Inheritance and Override .........................14
4. CDNI Metadata Objects ..........................................15
4.1. Definitions of the CDNI Structural Metadata Objects .......16
4.1.1. HostIndex ..........................................16
4.1.2. HostMatch ..........................................17
4.1.3. HostMetadata .......................................18
4.1.4. PathMatch ..........................................19
4.1.5. PatternMatch .......................................20
4.1.6. PathMetadata .......................................21
4.1.7. GenericMetadata ....................................23
4.2. Definitions of the Initial Set of CDNI
GenericMetadata Objects ...................................24
4.2.1. SourceMetadata .....................................24
4.2.1.1. Source ....................................25
4.2.2. LocationACL Metadata ...............................26
4.2.2.1. LocationRule ..............................28
4.2.2.2. Footprint .................................29
4.2.3. TimeWindowACL ......................................30
4.2.3.1. TimeWindowRule ............................31
4.2.3.2. TimeWindow ................................32
4.2.4. ProtocolACL Metadata ...............................33
4.2.4.1. ProtocolRule ..............................34
4.2.5. DeliveryAuthorization Metadata .....................35
4.2.6. Cache ..............................................35
4.2.7. Auth ...............................................37
4.2.8. Grouping ...........................................38
4.3. CDNI Metadata Simple Data Type Descriptions ...............39
4.3.1. Link ...............................................39
4.3.1.1. Link Loop Prevention ......................40
4.3.2. Protocol ...........................................40
4.3.3. Endpoint ...........................................40
4.3.4. Time ...............................................41
4.3.5. IPv4CIDR ...........................................41
4.3.6. IPv6CIDR ...........................................42
4.3.7. ASN ................................................42
4.3.8. Country Code .......................................42
5. CDNI Metadata Capabilities .....................................42
1. Introduction ....................................................5
1.1. Terminology ................................................5
1.2. Supported Metadata Capabilities ............................6
2. Design Principles ...............................................7
3. CDNI Metadata Object Model ......................................8
3.1. HostIndex, HostMatch, HostMetadata, PathMatch,
PatternMatch, and PathMetadata Objects .....................9
3.2. Generic CDNI Metadata Objects .............................11
3.3. Metadata Inheritance and Override .........................14
4. CDNI Metadata Objects ..........................................15
4.1. Definitions of the CDNI Structural Metadata Objects .......16
4.1.1. HostIndex ..........................................16
4.1.2. HostMatch ..........................................17
4.1.3. HostMetadata .......................................18
4.1.4. PathMatch ..........................................19
4.1.5. PatternMatch .......................................20
4.1.6. PathMetadata .......................................21
4.1.7. GenericMetadata ....................................23
4.2. Definitions of the Initial Set of CDNI
GenericMetadata Objects ...................................24
4.2.1. SourceMetadata .....................................24
4.2.1.1. Source ....................................25
4.2.2. LocationACL Metadata ...............................26
4.2.2.1. LocationRule ..............................28
4.2.2.2. Footprint .................................29
4.2.3. TimeWindowACL ......................................30
4.2.3.1. TimeWindowRule ............................31
4.2.3.2. TimeWindow ................................32
4.2.4. ProtocolACL Metadata ...............................33
4.2.4.1. ProtocolRule ..............................34
4.2.5. DeliveryAuthorization Metadata .....................35
4.2.6. Cache ..............................................35
4.2.7. Auth ...............................................37
4.2.8. Grouping ...........................................38
4.3. CDNI Metadata Simple Data Type Descriptions ...............39
4.3.1. Link ...............................................39
4.3.1.1. Link Loop Prevention ......................40
4.3.2. Protocol ...........................................40
4.3.3. Endpoint ...........................................40
4.3.4. Time ...............................................41
4.3.5. IPv4CIDR ...........................................41
4.3.6. IPv6CIDR ...........................................42
4.3.7. ASN ................................................42
4.3.8. Country Code .......................................42
5. CDNI Metadata Capabilities .....................................42
6. CDNI Metadata Interface ........................................43
6.1. Transport .................................................44
6.2. Retrieval of CDNI Metadata Resources ......................44
6.3. Bootstrapping .............................................45
6.4. Encoding ..................................................46
6.5. Extensibility .............................................46
6.6. Metadata Enforcement ......................................47
6.7. Metadata Conflicts ........................................47
6.8. Versioning ................................................48
6.9. Media Types ...............................................49
6.10. Complete CDNI Metadata Example ...........................50
7. IANA Considerations ............................................54
7.1. CDNI Payload Types ........................................54
7.1.1. CDNI MI HostIndex Payload Type .....................54
7.1.2. CDNI MI HostMatch Payload Type .....................55
7.1.3. CDNI MI HostMetadata Payload Type ..................55
7.1.4. CDNI MI PathMatch Payload Type .....................55
7.1.5. CDNI MI PatternMatch Payload Type ..................55
7.1.6. CDNI MI PathMetadata Payload Type ..................55
7.1.7. CDNI MI SourceMetadata Payload Type ................56
7.1.8. CDNI MI Source Payload Type ........................56
7.1.9. CDNI MI LocationACL Payload Type ...................56
7.1.10. CDNI MI LocationRule Payload Type .................56
7.1.11. CDNI MI Footprint Payload Type ....................56
7.1.12. CDNI MI TimeWindowACL Payload Type ................57
7.1.13. CDNI MI TimeWindowRule Payload Type ...............57
7.1.14. CDNI MI TimeWindow Payload Type ...................57
7.1.15. CDNI MI ProtocolACL Payload Type ..................57
7.1.16. CDNI MI ProtocolRule Payload Type .................57
7.1.17. CDNI MI DeliveryAuthorization Payload Type ........58
7.1.18. CDNI MI Cache Payload Type ........................58
7.1.19. CDNI MI Auth Payload Type .........................58
7.1.20. CDNI MI Grouping Payload Type .....................58
7.2. "CDNI Metadata Footprint Types" Registry ..................58
7.3. "CDNI Metadata Protocol Types" Registry ...................59
8. Security Considerations ........................................60
8.1. Authentication and Integrity ..............................60
8.2. Confidentiality and Privacy ...............................60
8.3. Securing the CDNI Metadata Interface ......................61
9. References .....................................................62
9.1. Normative References ......................................62
9.2. Informative References ....................................63
Acknowledgments ...................................................65
Contributors ......................................................65
Authors' Addresses ................................................66
6. CDNI Metadata Interface ........................................43
6.1. Transport .................................................44
6.2. Retrieval of CDNI Metadata Resources ......................44
6.3. Bootstrapping .............................................45
6.4. Encoding ..................................................46
6.5. Extensibility .............................................46
6.6. Metadata Enforcement ......................................47
6.7. Metadata Conflicts ........................................47
6.8. Versioning ................................................48
6.9. Media Types ...............................................49
6.10. Complete CDNI Metadata Example ...........................50
7. IANA Considerations ............................................54
7.1. CDNI Payload Types ........................................54
7.1.1. CDNI MI HostIndex Payload Type .....................54
7.1.2. CDNI MI HostMatch Payload Type .....................55
7.1.3. CDNI MI HostMetadata Payload Type ..................55
7.1.4. CDNI MI PathMatch Payload Type .....................55
7.1.5. CDNI MI PatternMatch Payload Type ..................55
7.1.6. CDNI MI PathMetadata Payload Type ..................55
7.1.7. CDNI MI SourceMetadata Payload Type ................56
7.1.8. CDNI MI Source Payload Type ........................56
7.1.9. CDNI MI LocationACL Payload Type ...................56
7.1.10. CDNI MI LocationRule Payload Type .................56
7.1.11. CDNI MI Footprint Payload Type ....................56
7.1.12. CDNI MI TimeWindowACL Payload Type ................57
7.1.13. CDNI MI TimeWindowRule Payload Type ...............57
7.1.14. CDNI MI TimeWindow Payload Type ...................57
7.1.15. CDNI MI ProtocolACL Payload Type ..................57
7.1.16. CDNI MI ProtocolRule Payload Type .................57
7.1.17. CDNI MI DeliveryAuthorization Payload Type ........58
7.1.18. CDNI MI Cache Payload Type ........................58
7.1.19. CDNI MI Auth Payload Type .........................58
7.1.20. CDNI MI Grouping Payload Type .....................58
7.2. "CDNI Metadata Footprint Types" Registry ..................58
7.3. "CDNI Metadata Protocol Types" Registry ...................59
8. Security Considerations ........................................60
8.1. Authentication and Integrity ..............................60
8.2. Confidentiality and Privacy ...............................60
8.3. Securing the CDNI Metadata Interface ......................61
9. References .....................................................62
9.1. Normative References ......................................62
9.2. Informative References ....................................63
Acknowledgments ...................................................65
Contributors ......................................................65
Authors' Addresses ................................................66
Content Delivery Network Interconnection (CDNI) [RFC6707] enables a downstream Content Delivery Network (dCDN) to service content requests on behalf of an upstream CDN (uCDN).
内容交付网络互连（CDNI）[RFC6707]使下游内容交付网络（dCDN）能够代表上游CDN（uCDN）为内容请求提供服务。
The CDNI Metadata interface (MI) is discussed in [RFC7336] along with four other interfaces that can be used to compose a CDNI solution (the CDNI Control interface, the CDNI Request Routing Redirection interface, the CDNI Footprint & Capabilities Advertisement interface (FCI), and the CDNI Logging interface). [RFC7336] describes each interface and the relationships between them. The requirements for the CDNI Metadata interface are specified in [RFC7337].
[RFC7336]中讨论了CDNI元数据接口（MI）以及可用于构成CDNI解决方案的四个其他接口（CDNI控制接口、CDNI请求路由重定向接口、CDNI封装外形和功能广告接口（FCI）和CDNI日志记录接口）。[RFC7336]描述了每个接口以及它们之间的关系。[RFC7337]中规定了CDNI元数据接口的要求。
The CDNI Metadata associated with a piece of content (or with a set of content) provides a dCDN with sufficient information for servicing content requests on behalf of a uCDN, in accordance with the policies defined by the uCDN.
根据uCDN定义的策略，与一段内容（或一组内容）关联的CDNI元数据为dCDN提供了代表uCDN服务内容请求的足够信息。
This document defines a CDNI Metadata interface that enables a dCDN to obtain CDNI Metadata from a uCDN so that the dCDN can properly process and respond to:
本文档定义了一个CDNI元数据接口，该接口使dCDN能够从uCDN获取CDNI元数据，以便dCDN能够正确处理和响应：
o Redirection requests received over the CDNI Request Routing Redirection interface [RFC7975].
o 通过CDNI请求路由重定向接口[RFC7975]接收的重定向请求。
o Content requests received directly from User Agents.
o 直接从用户代理接收的内容请求。
Specifically, this document defines:
具体而言，本文件规定：
o A data structure for mapping content requests and redirection requests to CDNI Metadata objects (Sections 3 and 4.1).
o 用于将内容请求和重定向请求映射到CDNI元数据对象的数据结构（第3节和第4.1节）。
o An initial set of CDNI GenericMetadata objects (Section 4.2).
o CDNI GenericMetadata对象的初始集合（第4.2节）。
o An HTTP web service for the transfer of CDNI Metadata (Section 6).
o 用于传输CDNI元数据的HTTP web服务（第6节）。
This document reuses the terminology defined in [RFC6707].
本文件重复使用了[RFC6707]中定义的术语。
Additionally, the following terms are used throughout this document and are defined as follows:
此外，本文件中使用了以下术语，其定义如下：
o Object - a collection of properties.
o 对象-属性的集合。
o Property - a key and value pair where the key is a property name and the value is the property value or another object.
o 属性-键和值对，其中键是属性名称，值是属性值或其他对象。
This document uses the phrase "[Object] A contains [Object] B" for simplicity when a strictly accurate phrase would be "[Object] A contains or references (via a Link object) [Object] B".
当严格准确的短语是“[Object]A包含或引用（通过链接对象）[Object]B”时，为了简单起见，本文档使用短语“[Object]A包含[Object]B”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Only the metadata for a small set of initial capabilities is specified in this document. This set provides the minimum amount of metadata for basic CDN interoperability while still meeting the requirements set forth by [RFC7337].
本文档中只指定了一小部分初始功能的元数据。该集合为基本CDN互操作性提供了最低数量的元数据，同时仍满足[RFC7337]规定的要求。
The following high-level functionality can be configured via the CDNI Metadata objects specified in Section 4:
可以通过第4节中指定的CDNI元数据对象配置以下高级功能：
o Acquisition Source: Metadata for allowing a dCDN to fetch content from a uCDN.
o 获取源：用于允许dCDN从uCDN获取内容的元数据。
o Delivery Access Control: Metadata for restricting (or permitting) access to content based on any of the following factors:
o 传递访问控制：基于以下任何因素限制（或允许）访问内容的元数据：
* Location
* 地方
* Time window
* 时间窗
* Delivery protocol
* 交付协议
o Delivery Authorization: Metadata for authorizing dCDN User Agent requests.
o 传递授权：用于授权dCDN用户代理请求的元数据。
o Cache Control: Metadata for controlling cache behavior of the dCDN.
o Cache Control：用于控制dCDN的缓存行为的元数据。
The metadata encoding described by this document is extensible in order to allow for future additions to this list.
本文档描述的元数据编码是可扩展的，以便将来添加到此列表中。
The set of metadata specified in this document covers the initial capabilities above. It is only intended to support CDNI for the delivery of content by a dCDN using HTTP/1.1 [RFC7230] and for a dCDN to be able to acquire content from a uCDN using either HTTP/1.1 or HTTP/1.1 over Transport Layer Security (TLS) [RFC2818].
本文档中指定的元数据集涵盖了上述初始功能。它仅用于支持CDNI，以便dCDN使用HTTP/1.1[RFC7230]交付内容，并且dCDN能够通过传输层安全性（TLS）使用HTTP/1.1或HTTP/1.1从uCDN获取内容[RFC2818]。
Supporting CDNI for the delivery of content using unencrypted HTTP/2 [RFC7540] (as well as for a dCDN to acquire content using unencrypted HTTP/2 or HTTP/2 over TLS) requires the registration of these protocol names in the "CDNI Metadata Protocol Types" registry (Section 7.3).
支持CDNI使用未加密的HTTP/2[RFC7540]交付内容（以及dCDN通过TLS使用未加密的HTTP/2或HTTP/2获取内容）需要在“CDNI元数据协议类型”注册表中注册这些协议名称（第7.3节）。
Delivery of content using HTTP/1.1 over TLS or HTTP/2 over TLS SHOULD follow the guidelines set forth in [RFC7525]. Offline configuration of TLS parameters between CDNs is beyond the scope of this document.
使用HTTP/1.1 over TLS或HTTP/2 over TLS交付内容应遵循[RFC7525]中规定的准则。CDN之间TLS参数的脱机配置超出了本文档的范围。
The CDNI Metadata interface was designed to achieve the following objectives:
CDNI元数据接口旨在实现以下目标：
1. Cacheability of CDNI Metadata objects;
1. CDNI元数据对象的可缓存性；
2. Deterministic mapping from redirection requests and content requests to CDNI Metadata properties;
2. 从重定向请求和内容请求到CDNI元数据属性的确定性映射；
3. Support for DNS redirection as well as application-specific redirection (for example, HTTP redirection);
3. 支持DNS重定向以及特定于应用程序的重定向（例如，HTTP重定向）；
4. Minimal duplication of CDNI Metadata; and
4. 尽量减少CDNI元数据的重复；和
5. Leveraging of existing protocols.
5. 利用现有协议。
Cacheability can decrease the latency of acquiring metadata while maintaining its freshness and can therefore decrease the latency of serving content requests and redirection requests, without sacrificing accuracy. The CDNI Metadata interface uses HTTP and its existing caching mechanisms to achieve CDNI Metadata cacheability.
可缓存性可以减少获取元数据的延迟，同时保持元数据的新鲜度，因此可以减少服务内容请求和重定向请求的延迟，而不会牺牲准确性。CDNI元数据接口使用HTTP及其现有缓存机制来实现CDNI元数据的可缓存性。
Deterministic mapping from content to metadata properties eliminates ambiguity and ensures that policies are applied consistently by all dCDNs.
从内容到元数据属性的确定性映射消除了歧义，并确保所有DCDN一致地应用策略。
Support for both HTTP and DNS redirection ensures that the CDNI Metadata meets the same design principles for both HTTP-based and DNS-based redirection schemes.
对HTTP和DNS重定向的支持确保CDNI元数据满足基于HTTP和基于DNS的重定向方案的相同设计原则。
Minimal duplication of CDNI Metadata improves storage efficiency in the CDNs.
CDNI元数据的最小重复可提高CDN中的存储效率。
Leveraging existing protocols avoids reinventing common mechanisms such as data structure encoding (by leveraging I-JSON (Internet JSON) [RFC7493]) and data transport (by leveraging HTTP [RFC7230]).
利用现有协议可避免重新发明常见机制，如数据结构编码（通过利用I-JSON（Internet JSON）[RFC7493]）和数据传输（通过利用HTTP[RFC7230]）。
The CDNI Metadata object model describes a data structure for mapping redirection requests and content requests to metadata properties. Metadata properties describe how to acquire content from a uCDN, authorize access to content, and deliver content from a dCDN. The object model relies on the assumption that these metadata properties can be grouped based on the hostname of the content and subsequently on the resource path (URI) of the content. The object model associates a set of CDNI Metadata properties with a hostname to form a default set of metadata properties for content delivered on behalf of that hostname. That default set of metadata properties can be overridden by properties that apply to specific paths within a URI.
CDNI元数据对象模型描述了将重定向请求和内容请求映射到元数据属性的数据结构。元数据属性描述如何从uCDN获取内容、授权对内容的访问以及如何从dCDN交付内容。对象模型依赖于这样一种假设，即这些元数据属性可以根据内容的主机名以及内容的资源路径（URI）进行分组。对象模型将一组CDNI元数据属性与主机名关联，以形成代表该主机名交付的内容的默认元数据属性集。应用于URI中特定路径的属性可以覆盖默认的元数据属性集。
Different hostnames and URI paths will be associated with different sets of CDNI Metadata properties in order to describe the required behavior when a dCDN Surrogate or request router is processing User Agent requests for content at that hostname and URI path. As a result of this structure, significant commonality could exist between the CDNI Metadata properties specified for different hostnames, different URI paths within a hostname, and different URI paths on different hostnames. For example, the definition of which User Agent IP addresses should be grouped together into a single network or geographic location is likely to be common for a number of different hostnames; although a uCDN is likely to have several different policies configured to express geo-blocking rules, it is likely that a single geo-blocking policy could be applied to multiple hostnames delivered through the CDN.
不同的主机名和URI路径将与不同的CDNI元数据属性集相关联，以便描述dCDN代理或请求路由器在该主机名和URI路径上处理用户代理对内容的请求时所需的行为。由于这种结构，为不同主机名、主机名内的不同URI路径以及不同主机名上的不同URI路径指定的CDNI元数据属性之间可能存在显著的共性。例如，对于许多不同的主机名来说，哪些用户代理IP地址应分组到单个网络或地理位置的定义可能是常见的；尽管uCDN可能会配置多个不同的策略来表示地理阻止规则，但单个地理阻止策略可能会应用于通过CDN交付的多个主机名。
In order to enable the CDNI Metadata for a given hostname and URI path to be decomposed into reusable sets of CDNI Metadata properties, the CDNI Metadata interface splits the CDNI Metadata into separate objects. Efficiency is improved by enabling a single CDNI Metadata object (that is shared across hostnames and/or URI paths) to be retrieved and stored by a dCDN once, even if it is referenced by the CDNI Metadata for multiple hostnames and/or URI paths.
为了使给定主机名和URI路径的CDNI元数据能够分解为可重用的CDNI元数据属性集，CDNI元数据接口将CDNI元数据拆分为单独的对象。通过使单个CDNI元数据对象（在主机名和/或URI路径之间共享）能够由dCDN检索和存储一次，即使它被多个主机名和/或URI路径的CDNI元数据引用，也可以提高效率。
Important Note: Any CDNI Metadata object A that contains another CDNI Metadata object B can include a Link object specifying a URI that can be used to retrieve object B, instead of embedding object B within object A. The remainder of this document uses the phrase "[Object] A contains [Object] B" for simplicity when a strictly accurate phrase would be "[Object] A contains or references (via a Link object) [Object] B". It is generally a deployment choice for the uCDN implementation to decide when to embed CDNI Metadata objects and when to reference separate resources via Link objects.
重要提示：任何包含另一个CDNI元数据对象B的CDNI元数据对象A都可以包含一个链接对象，该链接对象指定一个可用于检索对象B的URI，而不是将对象B嵌入对象A中。本文档的其余部分使用短语“[object]A包含[object]B”为了简单起见，当严格准确的短语是“[Object]a包含或引用（通过链接对象）[Object]B”。通常，uCDN实现的部署选择是决定何时嵌入CDNI元数据对象以及何时通过链接对象引用单独的资源。
Section 3.1 introduces a high-level description of the HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch, and PathMetadata objects, and describes the relationships between them.
第3.1节介绍了HostIndex、HostMatch、HostMetadata、PathMatch、PatternMatch和PathMetadata对象的高级描述，并描述了它们之间的关系。
Section 3.2 introduces a high-level description of the CDNI GenericMetadata object, which represents the level at which CDNI Metadata override occurs between HostMetadata and PathMetadata objects.
第3.2节介绍了CDNI GenericMetadata对象的高级描述，它表示HostMetadata和PathMetadata对象之间发生CDNI元数据重写的级别。
Section 4 describes in detail the specific CDNI Metadata objects and properties specified by this document that can be contained within a CDNI GenericMetadata object.
第4节详细描述了本文档指定的特定CDNI元数据对象和属性，这些对象和属性可以包含在CDNI GenericMetadata对象中。
3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch, and PathMetadata Objects
3.1. HostIndex、HostMatch、HostMetadata、PathMatch、PatternMatch和PathMetadata对象
The relationships between the HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch, and PathMetadata objects are described in Figure 1.
图1描述了HostIndex、HostMatch、HostMetadata、PathMatch、PatternMatch和PathMetadata对象之间的关系。
+---------+ +---------+ +------------+
|HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+
+---------+ +---------+ +------+-----+ |
| |
(*) |
| V
--> Contains or references V *****************
(1) One and only one +---------+ *GenericMetadata*
(*) Zero or more +--->|PathMatch| * Objects *
| +----+---++ *****************
| | | ^
(*) (1) (1) +------------+ |
| | +->|PatternMatch| |
| V +------------+ |
| +------------+ |
+--+PathMetadata+-------(*)------+
+------------+
+---------+ +---------+ +------------+
|HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+
+---------+ +---------+ +------+-----+ |
| |
(*) |
| V
--> Contains or references V *****************
(1) One and only one +---------+ *GenericMetadata*
(*) Zero or more +--->|PathMatch| * Objects *
| +----+---++ *****************
| | | ^
(*) (1) (1) +------------+ |
| | +->|PatternMatch| |
| V +------------+ |
| +------------+ |
+--+PathMetadata+-------(*)------+
+------------+
Figure 1: Relationships between CDNI Metadata Objects (Diagram Representation)
图1:CDNI元数据对象之间的关系（图表表示）
A HostIndex object (see Section 4.1.1) contains an array of HostMatch objects (see Section 4.1.2) that contain hostnames (and/or IP addresses) for which content requests might be delegated to the dCDN. The HostIndex is the starting point for accessing the uCDN CDNI Metadata data store. It enables the dCDN to deterministically discover which CDNI Metadata objects it requires in order to deliver a given piece of content.
HostIndex对象（请参见第4.1.1节）包含一个HostMatch对象数组（请参见第4.1.2节），其中包含主机名（和/或IP地址），内容请求可能会委托给dCDN。HostIndex是访问uCDN CDNI元数据数据存储的起点。它使dCDN能够确定地发现交付给定内容所需的CDNI元数据对象。
The HostIndex links hostnames (and/or IP addresses) to HostMetadata objects (see Section 4.1.3) via HostMatch objects. A HostMatch object defines a hostname (or IP address) to match against a requested host and contains a HostMetadata object.
HostIndex通过HostMatch对象将主机名（和/或IP地址）链接到HostMetadata对象（参见第4.1.3节）。HostMatch对象定义主机名（或IP地址）以与请求的主机匹配，并包含HostMetadata对象。
HostMetadata objects contain the default GenericMetadata objects (see Section 4.1.7) required to serve content for that host. When looking up CDNI Metadata, the dCDN looks up the requested hostname (or IP address) against the HostMatch entries in the HostIndex; from there, it can find HostMetadata, which describes the default metadata properties for each host as well as PathMetadata objects (see Section 4.1.6), via PathMatch objects (see Section 4.1.4). PathMatch objects define patterns, contained inside PatternMatch objects (see Section 4.1.5), to match against the requested URI path. PatternMatch objects contain the pattern strings and flags that describe the URI path to which a PathMatch applies. PathMetadata objects contain the GenericMetadata objects that apply to content requests matching the defined URI path pattern. PathMetadata properties override properties previously defined in HostMetadata or less-specific PathMatch paths. PathMetadata objects can contain additional PathMatch objects to recursively define more-specific URI paths to which GenericMetadata properties might be applied.
HostMetadata对象包含为该主机提供内容所需的默认GenericMetadata对象（请参阅第4.1.7节）。在查找CDNI元数据时，dCDN根据HostIndex中的HostMatch条目查找请求的主机名（或IP地址）；从那里，它可以通过PathMatch对象（参见第4.1.4节）找到HostMetadata，它描述了每个主机以及PathMetadata对象（参见第4.1.6节）的默认元数据属性。PathMatch对象定义包含在PatternMatch对象中的模式（参见第4.1.5节），以与请求的URI路径匹配。PatternMatch对象包含描述PathMatch应用到的URI路径的模式字符串和标志。PathMetadata对象包含应用于与定义的URI路径模式匹配的内容请求的GenericMetadata对象。PathMetadata属性覆盖以前在HostMetadata或不太特定的PathMatch路径中定义的属性。PathMetadata对象可以包含其他PathMatch对象，以递归方式定义可能应用GenericMetadata属性的更特定URI路径。
A GenericMetadata object contains individual CDNI Metadata objects that define the specific policies and attributes needed to properly deliver the associated content. For example, a GenericMetadata object could describe the source from which a CDN can acquire a piece of content. The GenericMetadata object is an atomic unit that can be referenced by HostMetadata or PathMetadata objects.
GenericMetadata对象包含单个CDNI元数据对象，这些对象定义了正确传递关联内容所需的特定策略和属性。例如，GenericMetadata对象可以描述CDN可以从中获取内容的源。GenericMetadata对象是可由HostMetadata或PathMetadata对象引用的原子单元。
For example, if "example.com" is a content provider, a HostMatch object could include an entry for "example.com" with the URI of the associated HostMetadata object. The HostMetadata object for "example.com" describes the metadata properties that apply to "example.com" and could contain PathMatches for "example.com/movies/*" and "example.com/music/*", which in turn reference corresponding PathMetadata objects that contain the properties for those more-specific URI paths. The PathMetadata object for "example.com/movies/*" describes the properties that apply to that URI path. It could also contain a PathMatch object for "example.com/movies/hd/*", which would reference the corresponding PathMetadata object for the "example.com/movies/hd/" path prefix.
例如，如果“example.com”是一个内容提供者，那么HostMatch对象可以包含一个“example.com”条目，其中包含关联的HostMetadata对象的URI。“example.com”的HostMetadata对象描述了应用于“example.com”的元数据属性，可以包含“example.com/movies/*”和“example.com/music/*”的路径匹配项，这两个路径匹配项又引用了相应的PathMetadata对象，这些对象包含那些更具体URI路径的属性。“example.com/movies/*”的PathMetadata对象描述了应用于该URI路径的属性。它还可以包含“example.com/movies/hd/*”的PathMatch对象，该对象将引用“example.com/movies/hd/”路径前缀对应的PathMetadata对象。
The relationships in Figure 1 are also represented in tabular format in Table 1 below.
图1中的关系也以表格形式显示在下表1中。
+--------------+----------------------------------------------------+
| Data Object | Objects it contains or references |
+--------------+----------------------------------------------------+
| HostIndex | 0 or more HostMatch objects. |
| | |
| HostMatch | 1 HostMetadata object. |
| | |
| HostMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. |
| | |
| PathMatch | 1 PatternMatch object. 1 PathMetadata object. |
| | |
| PatternMatch | Does not contain or reference any other objects. |
| | |
| PathMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Data Object | Objects it contains or references |
+--------------+----------------------------------------------------+
| HostIndex | 0 or more HostMatch objects. |
| | |
| HostMatch | 1 HostMetadata object. |
| | |
| HostMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. |
| | |
| PathMatch | 1 PatternMatch object. 1 PathMetadata object. |
| | |
| PatternMatch | Does not contain or reference any other objects. |
| | |
| PathMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. |
+--------------+----------------------------------------------------+
Table 1: Relationships between CDNI Metadata Objects (Table Representation)
表1:CDNI元数据对象之间的关系（表表示）
The HostMetadata and PathMetadata objects contain other CDNI Metadata objects that contain properties that describe how User Agent requests for content should be processed -- for example, where to acquire the content from, authorization rules that should be applied, geo-blocking restrictions, and so on. Each such CDNI Metadata object is a specialization of a CDNI GenericMetadata object. The GenericMetadata object abstracts the basic information required for metadata override and metadata distribution, from the specifics of any given property (i.e., property semantics, enforcement options, etc.).
HostMetadata和PathMetadata对象包含其他CDNI元数据对象，这些对象包含描述如何处理用户代理对内容的请求的属性，例如，从何处获取内容、应应用的授权规则、地理阻止限制等。每个这样的CDNI元数据对象都是CDNI GenericMetadata对象的专门化。GenericMetadata对象从任何给定属性（即属性语义、强制选项等）的细节中提取元数据覆盖和元数据分发所需的基本信息。
The GenericMetadata object defines the properties contained within it as well as whether or not the properties are "mandatory-to-enforce". If the dCDN does not understand or support a mandatory-to-enforce property, the dCDN MUST NOT serve the content. If the property is not mandatory-to-enforce, then that GenericMetadata object can be safely ignored and the content request can be processed in accordance with the rest of the CDNI Metadata.
GenericMetadata对象定义其中包含的属性以及这些属性是否是“强制执行的”。如果dCDN不理解或不支持强制执行属性，则dCDN不得提供内容。如果该属性不是强制执行的，那么可以安全地忽略该GenericMetadata对象，并且可以根据其余的CDNI元数据处理内容请求。
Although a CDN MUST NOT serve content to a User Agent if a mandatory-to-enforce property cannot be enforced, it could still be safe to redistribute that metadata (the "safe-to-redistribute" property) to another CDN without modification. For example, in the cascaded CDN case, a transit CDN (tCDN) could convey mandatory-to-enforce metadata to a dCDN. For metadata that does not require customization or translation (i.e., metadata that is safe-to-redistribute), the data representation received off the wire MAY be stored and redistributed without being understood or supported by the tCDN. However, for metadata that requires translation, transparent redistribution of the uCDN metadata values might not be appropriate. Certain metadata can be safely, though perhaps not optimally, redistributed unmodified. For example, a source acquisition address might not be optimal if transparently redistributed, but it might still work.
尽管如果强制执行属性无法强制执行，CDN不得向用户代理提供内容，但不经修改将该元数据（“安全重新分发”属性）重新分发到另一个CDN仍然是安全的。例如，在级联CDN的情况下，传输CDN（tCDN）可以将强制元数据传递给dCDN。对于不需要定制或转换的元数据（即，可以安全地重新分发的元数据），可以存储和重新分发线下接收的数据表示，而无需tCDN理解或支持。然而，对于需要转换的元数据，uCDN元数据值的透明重新分布可能并不合适。某些元数据可以安全地（尽管可能不是最佳的）不经修改地重新分发。例如，如果透明地重新分配源采集地址，则该地址可能不是最优的，但它仍然可以工作。
Redistribution safety MUST be specified for each GenericMetadata property. If a CDN does not understand or support a given GenericMetadata property that is not safe-to-redistribute, the CDN MUST set the "incomprehensible" flag to true for that GenericMetadata object before redistributing the metadata. The "incomprehensible" flag signals to a dCDN that the metadata was not properly transformed by the tCDN. A CDN MUST NOT attempt to use metadata that has been marked as "incomprehensible" by a uCDN.
必须为每个GenericMetadata属性指定重新分发安全性。如果CDN不理解或不支持给定的GenericMetadata属性，且该属性无法安全地重新分发，则CDN必须在重新分发元数据之前将该GenericMetadata对象的“不可理解”标志设置为true。“不可理解”标志向dCDN发出信号，表示tCDN未正确转换元数据。CDN不得尝试使用uCDN标记为“不可理解”的元数据。
tCDNs MUST NOT change the value of mandatory-to-enforce or safe-to-redistribute when propagating metadata to a dCDN. Although a tCDN can set the value of "incomprehensible" to true, a tCDN MUST NOT change the value of "incomprehensible" from true to false.
在将元数据传播到dCDN时，TCDN不得更改强制值或安全值以重新分发。尽管tCDN可以将“不可理解”的值设置为true，但tCDN不能将“不可理解”的值从true更改为false。
Table 2 describes the action to be taken by a tCDN for the different combinations of mandatory-to-enforce ("MtE") and safe-to-redistribute ("StR") properties when the tCDN either does or does not understand the metadata in question:
表2描述了当tCDN理解或不理解相关元数据时，tCDN对强制执行（“MtE”）和安全重新分发（“StR”）属性的不同组合所采取的行动：
+-------+-------+------------+--------------------------------------+
| MtE | StR | Metadata | Action |
| | | Understood | |
| | | by tCDN | |
+-------+-------+------------+--------------------------------------+
| False | True | True | Can serve and redistribute. |
| | | | |
| False | True | False | Can serve and redistribute. |
| | | | |
| False | False | False | Can serve. MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
| | | | |
| False | False | True | Can serve. Can redistribute after |
| | | | transforming the metadata (if the |
| | | | CDN knows how to do so safely); |
| | | | otherwise, MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
| | | | |
| True | True | True | Can serve and redistribute. |
| | | | |
| True | True | False | MUST NOT serve but can redistribute. |
| | | | |
| True | False | True | Can serve. Can redistribute after |
| | | | transforming the metadata (if the |
| | | | CDN knows how to do so safely); |
| | | | otherwise, MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
| | | | |
| True | False | False | MUST NOT serve. MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
+-------+-------+------------+--------------------------------------+
+-------+-------+------------+--------------------------------------+
| MtE | StR | Metadata | Action |
| | | Understood | |
| | | by tCDN | |
+-------+-------+------------+--------------------------------------+
| False | True | True | Can serve and redistribute. |
| | | | |
| False | True | False | Can serve and redistribute. |
| | | | |
| False | False | False | Can serve. MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
| | | | |
| False | False | True | Can serve. Can redistribute after |
| | | | transforming the metadata (if the |
| | | | CDN knows how to do so safely); |
| | | | otherwise, MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
| | | | |
| True | True | True | Can serve and redistribute. |
| | | | |
| True | True | False | MUST NOT serve but can redistribute. |
| | | | |
| True | False | True | Can serve. Can redistribute after |
| | | | transforming the metadata (if the |
| | | | CDN knows how to do so safely); |
| | | | otherwise, MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
| | | | |
| True | False | False | MUST NOT serve. MUST set |
| | | | "incomprehensible" to true when |
| | | | redistributing. |
+-------+-------+------------+--------------------------------------+
Table 2: Action to Be Taken by a tCDN for the Different Combinations of MtE and StR Properties
表2:tCDN针对MtE和StR属性的不同组合采取的行动
Table 3 describes the action to be taken by a dCDN for the different combinations of mandatory-to-enforce and "incomprehensible" (Incomp) properties, when the dCDN either does or does not understand the metadata in question:
表3描述了当dCDN不理解或不理解所讨论的元数据时，dCDN对强制执行的强制属性和“不可理解”（不可理解）属性的不同组合所采取的操作：
+-------+--------+--------------+-----------------------------------+
| MtE | Incomp | Metadata | Action |
| | | Understood | |
| | | by dCDN | |
+-------+--------+--------------+-----------------------------------+
| False | False | True | Can serve. |
| | | | |
| False | True | True | Can serve but MUST NOT |
| | | | interpret/apply any metadata |
| | | | marked as "incomprehensible". |
| | | | |
| False | False | False | Can serve. |
| | | | |
| False | True | False | Can serve but MUST NOT |
| | | | interpret/apply any metadata |
| | | | marked as "incomprehensible". |
| | | | |
| True | False | True | Can serve. |
| | | | |
| True | True | True | MUST NOT serve. |
| | | | |
| True | False | False | MUST NOT serve. |
| | | | |
| True | True | False | MUST NOT serve. |
+-------+--------+--------------+-----------------------------------+
+-------+--------+--------------+-----------------------------------+
| MtE | Incomp | Metadata | Action |
| | | Understood | |
| | | by dCDN | |
+-------+--------+--------------+-----------------------------------+
| False | False | True | Can serve. |
| | | | |
| False | True | True | Can serve but MUST NOT |
| | | | interpret/apply any metadata |
| | | | marked as "incomprehensible". |
| | | | |
| False | False | False | Can serve. |
| | | | |
| False | True | False | Can serve but MUST NOT |
| | | | interpret/apply any metadata |
| | | | marked as "incomprehensible". |
| | | | |
| True | False | True | Can serve. |
| | | | |
| True | True | True | MUST NOT serve. |
| | | | |
| True | False | False | MUST NOT serve. |
| | | | |
| True | True | False | MUST NOT serve. |
+-------+--------+--------------+-----------------------------------+
Table 3: Action to Be Taken by a dCDN for the Different Combinations of MtE and Incomp Properties
表3:dCDN针对MtE和INCUM属性的不同组合采取的措施
In the metadata object model, a HostMetadata object can contain multiple PathMetadata objects (via PathMatch objects). Each PathMetadata object can in turn contain other PathMetadata objects. HostMetadata and PathMetadata objects form an inheritance tree where each node in the tree inherits or overrides the property values set by its parent.
在元数据对象模型中，HostMetadata对象可以包含多个PathMetadata对象（通过PathMatch对象）。每个PathMetadata对象可以依次包含其他PathMetadata对象。HostMetadata和PathMetadata对象形成一个继承树，其中树中的每个节点都继承或重写其父节点设置的属性值。
GenericMetadata objects of a given type override all GenericMetadata objects of the same type previously defined by any parent object in the tree. GenericMetadata objects of a given type previously defined by a parent object in the tree are inherited when no object of the same type is defined by the child object. For example, if
给定类型的GenericMetadata对象覆盖树中任何父对象先前定义的相同类型的所有GenericMetadata对象。当子对象未定义相同类型的对象时，将继承树中父对象先前定义的给定类型的GenericMetadata对象。例如，如果
HostMetadata for the host "example.com" contains GenericMetadata objects of types LocationACL and TimeWindowACL (where "ACL" means "Access Control List") while a PathMetadata object that applies to "example.com/movies/*" defines an alternate GenericMetadata object of type TimeWindowACL, then:
主机“example.com”的HostMetadata包含LocationACL和TimeWindowACL类型的GenericMetadata对象（其中“ACL”表示“访问控制列表”），而应用于“example.com/movies/*”的PathMetadata对象定义了TimeWindowACL类型的备用GenericMetadata对象，然后：
o The TimeWindowACL defined in the PathMetadata would override the TimeWindowACL defined in the HostMetadata for all User Agent requests for content under "example.com/movies/", and
o PathMetadata中定义的TimeWindowACL将覆盖HostMetadata中为“example.com/movies/”下的所有用户代理内容请求定义的TimeWindowACL，并且
o The LocationACL defined in the HostMetadata would be inherited for all User Agent requests for content under "example.com/movies/".
o HostMetadata中定义的LocationACL将为“example.com/movies/”下的所有用户代理请求继承。
A single HostMetadata or PathMetadata object MUST NOT contain multiple GenericMetadata objects of the same type. If an array of GenericMetadata contains objects of duplicate types, the receiver MUST ignore all but the first object of each type.
单个HostMetadata或PathMetadata对象不得包含多个相同类型的GenericMetadata对象。如果GenericMetadata数组包含重复类型的对象，则接收方必须忽略每种类型的第一个对象以外的所有对象。
Section 4.1 provides the definitions of each metadata object type introduced in Section 3. These metadata objects are described as structural metadata objects, as they provide the structure for host and URI path-based inheritance and identify which GenericMetadata objects apply to a given User Agent content request.
第4.1节提供了第3节中介绍的每个元数据对象类型的定义。这些元数据对象被描述为结构化元数据对象，因为它们为基于主机和URI路径的继承提供了结构，并标识哪些GenericMetadata对象应用于给定的用户代理内容请求。
Section 4.2 provides the definitions for a base set of core metadata objects that can be contained within a GenericMetadata object. These metadata objects govern how User Agent requests for content are handled. GenericMetadata objects can contain other GenericMetadata objects as properties; these can be referred to as sub-objects. As with all CDNI Metadata objects, the value of the GenericMetadata sub-objects can be either a complete serialized representation of the sub-object or a Link object that contains a URI that can be dereferenced to retrieve the complete serialized representation of the property sub-object.
第4.2节提供了可以包含在GenericMetadata对象中的核心元数据对象的基本集的定义。这些元数据对象控制如何处理用户代理对内容的请求。GenericMetadata对象可以包含其他GenericMetadata对象作为属性；这些可以称为子对象。与所有CDNI元数据对象一样，GenericMetadata子对象的值可以是子对象的完整序列化表示形式，也可以是包含URI的链接对象，该URI可以被取消引用以检索属性子对象的完整序列化表示形式。
Section 6.5 discusses the ability to extend the base set of GenericMetadata objects specified in this document with additional standards-based or vendor-specific GenericMetadata objects that might be defined in the future in separate documents.
第6.5节讨论了使用其他基于标准或特定于供应商的GenericMetadata对象扩展本文档中指定的基本GenericMetadata对象集的能力，这些对象将来可能在单独的文档中定义。
dCDNs and tCDNs MUST support the parsing of all CDNI Metadata objects specified in this document. A dCDN does not have to implement the underlying functionality represented by non-structural GenericMetadata objects (though that might restrict the content that a given dCDN will be able to serve). uCDNs as generators of CDNI Metadata only need to support generating the CDNI Metadata that they
dCDNs和tCDNs必须支持解析本文档中指定的所有CDNI元数据对象。dCDN不必实现由非结构化GenericMetadata对象表示的底层功能（尽管这可能会限制给定dCDN能够提供的内容）。UCDN作为CDNI元数据的生成器，只需要支持生成它们所需的CDNI元数据
need in order to express the policies required by the content they are describing. See Section 6.4 for more details on the specific encoding rules for CDNI Metadata objects.
需要，以表达所描述内容所需的策略。有关CDNI元数据对象的特定编码规则的更多详细信息，请参见第6.4节。
Note: In the following sections, the term "mandatory-to-specify" is used to convey which properties MUST be included for a given structural or GenericMetadata object. When mandatory-to-specify is specified as "Yes" for an individual property, it means that if the object containing that property is included in a metadata response, then the mandatory-to-specify property MUST also be included (directly or by reference) in the response. For example, a HostMatch property object without a host to match against does not make sense; therefore, the "host" property is mandatory-to-specify inside a HostMatch object.
注意：在以下部分中，术语“必须指定”用于表示给定的structural或GenericMetadata对象必须包含哪些属性。如果将单个属性的“必须指定”指定为“是”，这意味着如果包含该属性的对象包含在元数据响应中，那么必须指定的属性也必须包含在响应中（直接或通过引用）。例如，没有要匹配的主机的HostMatch属性对象没有意义；因此，必须在HostMatch对象内指定“host”属性。
The subsections below describe the structural objects introduced in Section 3.1.
以下小节描述了第3.1节中介绍的结构对象。
The HostIndex object is the entry point into the CDNI Metadata hierarchy. It contains an array of HostMatch objects. An incoming content request is checked against the hostname (or IP address) specified by each of the listed HostMatch objects to find the HostMatch object that applies to the request.
HostIndex对象是CDNI元数据层次结构的入口点。它包含一个HostMatch对象数组。将根据每个列出的HostMatch对象指定的主机名（或IP地址）检查传入的内容请求，以查找应用于该请求的HostMatch对象。
Property: hosts
属性：主机
Description: Array of HostMatch objects. Hosts (HostMatch objects) MUST be evaluated in the order they appear, and the first HostMatch object that matches the content request being processed MUST be used.
描述：主机匹配对象的数组。主机（HostMatch对象）必须按照其出现的顺序进行计算，并且必须使用与正在处理的内容请求匹配的第一个HostMatch对象。
Type: Array of HostMatch objects
类型：主机匹配对象数组
Mandatory-to-Specify: Yes.
必须指定：是。
Example HostIndex object containing two HostMatch objects, where the first HostMatch object is embedded and the second HostMatch object is referenced:
包含两个HostMatch对象的HostIndex对象示例，其中嵌入了第一个HostMatch对象，并引用了第二个HostMatch对象：
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
]
}
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
]
}
The HostMatch object contains a hostname or IP address to match against content requests. The HostMatch object also contains a HostMetadata object to apply if a match is found.
HostMatch对象包含与内容请求匹配的主机名或IP地址。HostMatch对象还包含在找到匹配项时要应用的HostMetadata对象。
Property: host
属性：主机
Description: Hostname or IP address and optional port to match against the requested host, i.e., the host and port as described in [RFC3986]. In order for a hostname or IP address in a content request to match the hostname or IP address in the "host" property, the value from the content request when converted to lowercase MUST be identical to the value of the "host" property when converted to lowercase. All implementations MUST support IPv4 addresses encoded as specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986]. IPv6 addresses MUST be encoded in one of the IPv6 address formats specified in [RFC5952], although receivers MUST support all IPv6 address formats specified in [RFC4291]. Hostnames MUST conform to the Domain Name System (DNS) syntax defined in [RFC1034] and [RFC1123]. Internationalized Domain Names (IDNs) must first be transformed to the A-label form [RFC5890] as per [RFC5891].
描述：主机名或IP地址以及与请求主机匹配的可选端口，即[RFC3986]中描述的主机和端口。为了使内容请求中的主机名或IP地址与“主机”属性中的主机名或IP地址匹配，内容请求转换为小写时的值必须与转换为小写时的“主机”属性值相同。所有实现必须支持[RFC3986]第3.2.2节中“IPv4address”规则指定的编码IPv4地址。IPv6地址必须以[RFC5952]中指定的一种IPv6地址格式进行编码，尽管接收器必须支持[RFC4291]中指定的所有IPv6地址格式。主机名必须符合[RFC1034]和[RFC1123]中定义的域名系统（DNS）语法。国际化域名（IDN）必须首先按照[RFC5891]转换为A标签形式[RFC5890]。
Type: Endpoint
类型：端点
Mandatory-to-Specify: Yes.
必须指定：是。
Property: host-metadata
属性：主机元数据
Description: CDNI Metadata to apply when delivering content that matches this host.
描述：交付与此主机匹配的内容时要应用的CDNI元数据。
Type: HostMetadata
类型：主机元数据
Mandatory-to-Specify: Yes.
必须指定：是。
Example HostMatch object with an embedded HostMetadata object:
具有嵌入式HostMetadata对象的HostMatch对象示例：
{
"host": "video.example.com",
"host-metadata": {
<Properties of embedded HostMetadata object>
}
}
{
"host": "video.example.com",
"host-metadata": {
<Properties of embedded HostMetadata object>
}
}
Example HostMatch object referencing (via a Link object; see Section 4.3.1) a HostMetadata object:
示例HostMatch对象引用（通过链接对象；参见第4.3.1节）HostMetadata对象：
{
"host": "video.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host1234"
}
}
{
"host": "video.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host1234"
}
}
A HostMetadata object contains the CDNI Metadata properties for content served for a particular host (defined in the HostMatch object) and possibly child PathMatch objects.
HostMetadata对象包含为特定主机（在HostMatch对象中定义）服务的内容的CDNI元数据属性，可能还包含子PathMatch对象。
Property: metadata
属性：元数据
Description: Array of host-related metadata.
描述：主机相关元数据的数组。
Type: Array of GenericMetadata objects
类型：GenericMetadata对象数组
Mandatory-to-Specify: Yes.
必须指定：是。
Property: paths
属性：路径
Description: Path-specific rules. Path patterns (PathMatch objects) MUST be evaluated in the order they appear, and the first (and only the first) PathMatch object that matches the content request being processed MUST be used.
描述：特定于路径的规则。必须按照路径模式（PathMatch对象）的显示顺序对其进行求值，并且必须使用与正在处理的内容请求匹配的第一个（且仅第一个）PathMatch对象。
Type: Array of PathMatch objects
类型：PathMatch对象数组
Mandatory-to-Specify: No. Default is that there are no more-specific paths to evaluate (i.e., an empty list).
必须指定：否。默认情况下，没有更具体的路径进行评估（即，空列表）。
Example HostMetadata object containing a number of embedded GenericMetadata objects that will describe the default metadata for the host and an embedded PathMatch object that contains a path for which metadata exists that overrides the default metadata for the host:
示例HostMetadata对象包含多个嵌入式GenericMetadata对象，这些对象将描述主机的默认元数据，以及一个嵌入式PathMatch对象，其中包含一个存在元数据的路径，该路径覆盖主机的默认元数据：
{
"metadata": [
{
<Properties of first embedded GenericMetadata object>
},
{
<Properties of second embedded GenericMetadata object>
},
{
"metadata": [
{
<Properties of first embedded GenericMetadata object>
},
{
<Properties of second embedded GenericMetadata object>
},
...
...
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
A PathMatch object contains a PatternMatch object with a path to match against a resource's URI path, as well as how to handle URI query parameters. The PathMatch object also contains a PathMetadata object with GenericMetadata to apply if the resource's URI matches the pattern within the PatternMatch object.
PathMatch对象包含PatternMatch对象，该对象具有与资源的URI路径匹配的路径，以及如何处理URI查询参数。PathMatch对象还包含一个PathMetadata对象，如果资源的URI与PatternMatch对象中的模式匹配，则该对象将应用GenericMetadata。
Property: path-pattern
属性：路径模式
Description: Pattern to match against the requested resource's URI.
描述：与请求的资源的URI匹配的模式。
Type: PatternMatch
类型：PatternMatch
Mandatory-to-Specify: Yes.
必须指定：是。
Property: path-metadata
属性：路径元数据
Description: CDNI Metadata to apply when delivering content that matches the associated PatternMatch.
描述：交付与关联PatternMatch匹配的内容时要应用的CDNI元数据。
Type: PathMetadata
类型：PathMetadata
Mandatory-to-Specify: Yes.
必须指定：是。
Example PathMatch object referencing the PathMetadata object to use for URIs that match the case-sensitive URI path pattern "/movies/*" (contained within an embedded PatternMatch object):
引用PathMetadata对象的PathMatch对象示例，该对象用于与区分大小写的URI路径模式“/movies/*”（包含在嵌入式PatternMatch对象中）匹配的URI：
{
"path-pattern": {
"pattern": "/movies/*",
"case-sensitive": true
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathDCE"
}
}
{
"path-pattern": {
"pattern": "/movies/*",
"case-sensitive": true
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathDCE"
}
}
A PatternMatch object contains the pattern string and flags that describe the pattern expression.
PatternMatch对象包含描述模式表达式的模式字符串和标志。
Property: pattern
属性：模式
Description: A pattern for matching against the URI path, i.e., against the path-absolute [RFC3986]. The pattern can contain the wildcards "*" and "?", where "*" matches any sequence of pchar [RFC3986] or "/" characters (including the empty string) and "?" matches exactly one pchar character. The three literals "$", "*", and "?" MUST be escaped as "$$", "$*", and "$?" (where "$" is the designated escape character). All other characters are treated as literals.
描述：与URI路径匹配的模式，即与绝对路径匹配[RFC3986]。模式可以包含通配符“*”和“？”，其中“*”匹配任何pchar[RFC3986]或“/”字符序列（包括空字符串），而“？”正好匹配一个pchar字符。三个文本“$”、“*”和“？”必须转义为“$$”、“$*”和“$？”（“$”是指定的转义字符）。所有其他字符都被视为文字。
Type: String
类型：字符串
Mandatory-to-Specify: Yes.
必须指定：是。
Property: case-sensitive
属性：区分大小写
Description: Flag indicating whether or not case-sensitive matching should be used. Note: Case insensitivity applies to ALPHA characters in the URI path prior to percent-decoding [RFC3986].
描述：指示是否应使用区分大小写的匹配的标志。注意：不区分大小写适用于百分比解码之前URI路径中的ALPHA字符[RFC3986]。
Type: Boolean
类型：布尔型
Mandatory-to-Specify: No. Default is case-insensitive match (i.e., a value of False).
必须指定：否。默认值为不区分大小写的匹配（即值False）。
Example PatternMatch object that matches the case-sensitive URI path pattern "/movies/*":
与区分大小写的URI路径模式“/movies/*”匹配的PatternMatch对象示例：
{
"pattern": "/movies/*",
"case-sensitive": true
}
{
"pattern": "/movies/*",
"case-sensitive": true
}
A PathMetadata object contains the CDNI Metadata properties for content requests that match against the associated URI path (defined in a PathMatch object).
PathMetadata对象包含与关联URI路径（在PathMatch对象中定义）匹配的内容请求的CDNI元数据属性。
Note that if DNS-based redirection is employed, then a dCDN will be unable to evaluate any metadata at the PathMetadata level or below because only the hostname of the content request is available at Request Routing time. dCDNs SHOULD still process all PathMetadata for the host before responding to the redirection request to detect if any unsupported metadata is specified. If any metadata not supported by the dCDN is marked as mandatory-to-enforce, the dCDN SHOULD NOT accept the content redirection request, in order to avoid receiving content requests that it will not be able to satisfy/serve.
请注意，如果使用基于DNS的重定向，则dCDN将无法评估PathMetadata级别或更低级别的任何元数据，因为在请求路由时只有内容请求的主机名可用。dCDNs在响应重定向请求之前仍应处理主机的所有PathMetadata，以检测是否指定了任何不受支持的元数据。如果dCDN不支持的任何元数据被标记为强制执行，则dCDN不应接受内容重定向请求，以避免接收其无法满足/服务的内容请求。
Property: metadata
属性：元数据
Description: Array of path-related metadata.
描述：路径相关元数据的数组。
Type: Array of GenericMetadata objects
类型：GenericMetadata对象数组
Mandatory-to-Specify: Yes.
必须指定：是。
Property: paths
属性：路径
Description: Path-specific rules. Path patterns (PathMatch objects) MUST be evaluated in the order they appear, and the first (and only the first) PathMatch object that matches the content request being processed MUST be used.
描述：特定于路径的规则。必须按照路径模式（PathMatch对象）的显示顺序对其进行求值，并且必须使用与正在处理的内容请求匹配的第一个（且仅第一个）PathMatch对象。
Type: Array of PathMatch objects
类型：PathMatch对象数组
Mandatory-to-Specify: No. Default is that there are no more-specific paths to evaluate (i.e., an empty list).
必须指定：否。默认情况下，没有更具体的路径进行评估（即，空列表）。
Example PathMetadata object containing a number of embedded GenericMetadata objects that describe the metadata to apply for the URI path defined in the parent PathMatch object, as well as a more-specific PathMatch object.
示例PathMetadata对象包含许多嵌入式GenericMetadata对象，这些对象描述了要应用于父PathMatch对象中定义的URI路径的元数据，以及一个更具体的PathMatch对象。
{
"metadata": [
{
<Properties of first embedded GenericMetadata object>
},
{
<Properties of second embedded GenericMetadata object>
},
{
"metadata": [
{
<Properties of first embedded GenericMetadata object>
},
{
<Properties of second embedded GenericMetadata object>
},
...
...
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
A GenericMetadata object is a wrapper for managing individual CDNI Metadata properties in an opaque manner.
GenericMetadata对象是一个包装器，用于以不透明的方式管理单个CDNI元数据属性。
Property: generic-metadata-type
属性：泛型元数据类型
Description: Case-insensitive CDNI Metadata object type.
描述：不区分大小写的CDNI元数据对象类型。
Type: String containing the CDNI Payload Type [RFC7736] of the object contained in the generic-metadata-value property (see Table 4).
类型：包含通用元数据值属性中包含的对象的CDNI有效负载类型[RFC7736]的字符串（参见表4）。
Mandatory-to-Specify: Yes.
必须指定：是。
Property: generic-metadata-value
属性：通用元数据值
Description: CDNI Metadata object.
描述：CDNI元数据对象。
Type: Format/Type is defined by the value of the generic-metadata-type property above. Note: generic-metadata-values MUST NOT name any properties "href" (see Section 4.3.1).
类型：格式/类型由上面的泛型元数据类型属性的值定义。注意：通用元数据值不得将任何属性命名为“href”（参见第4.3.1节）。
Mandatory-to-Specify: Yes.
必须指定：是。
Property: mandatory-to-enforce
财产：强制执行
Description: Flag identifying whether or not the enforcement of the property metadata is required.
描述：标识是否需要强制执行属性元数据的标志。
Type: Boolean
类型：布尔型
Mandatory-to-Specify: No. Default is to treat metadata as mandatory-to-enforce (i.e., a value of True).
必须指定：否。默认值是将元数据视为必须强制执行（即，值为True）。
Property: safe-to-redistribute
属性：可以安全地重新分配
Description: Flag identifying whether or not the property metadata can be safely redistributed without modification.
描述：标识属性元数据是否可以不经修改而安全地重新分发的标志。
Type: Boolean
类型：布尔型
Mandatory-to-Specify: No. Default is to allow transparent redistribution (i.e., a value of True).
必须指定：否。默认值是允许透明重新分配（即，值为True）。
Property: incomprehensible
属性：不可理解
Description: Flag identifying whether or not any CDN in the chain of delegation has failed to understand and/or failed to properly transform this metadata object. Note: This flag only applies to metadata objects whose safe-to-redistribute property has a value of False.
描述：标识委派链中的任何CDN是否未能理解和/或正确转换此元数据对象的标志。注意：此标志仅适用于其“安全重新分发”属性的值为False的元数据对象。
Type: Boolean
类型：布尔型
Mandatory-to-Specify: No. Default is comprehensible (i.e., a value of False).
必须指定：否。默认值是可理解的（即，值为False）。
Example GenericMetadata object containing a metadata object that applies to the applicable URI path and/or host (within a parent PathMetadata and/or HostMetadata object, respectively):
示例GenericMetadata对象包含应用于适用URI路径和/或主机的元数据对象（分别位于父PathMetadata和/或HostMetadata对象内）：
{
"mandatory-to-enforce": true,
"safe-to-redistribute": true,
"incomprehensible": false,
"generic-metadata-type": <CDNI Payload Type of this metadata object>,
"generic-metadata-value":
{
<Properties of this metadata object>
}
}
{
"mandatory-to-enforce": true,
"safe-to-redistribute": true,
"incomprehensible": false,
"generic-metadata-type": <CDNI Payload Type of this metadata object>,
"generic-metadata-value":
{
<Properties of this metadata object>
}
}
The objects defined below are intended to be used in the GenericMetadata object's generic-metadata-value field as defined in Section 4.1.7, and their generic-metadata-type property MUST be set to the appropriate CDNI Payload Type as defined in Table 4.
下面定义的对象旨在用于第4.1.7节中定义的GenericMetadata对象的通用元数据值字段，其通用元数据类型属性必须设置为表4中定义的相应CDNI有效负载类型。
Source metadata provides the dCDN with information about content acquisition, i.e., how to contact a uCDN Surrogate or an origin server to obtain the content to be served. The sources are not necessarily the actual origin servers operated by the Content Service Provider (CSP) but might be a set of Surrogates in the uCDN.
源元数据为dCDN提供有关内容获取的信息，即如何联系uCDN代理或源服务器以获取要服务的内容。源不一定是由内容服务提供商（CSP）操作的实际源服务器，但可能是uCDN中的一组代理服务器。
Property: sources
财产：来源
Description: Sources from which the dCDN can acquire content, listed in order of preference.
描述：dCDN可以从中获取内容的源，按优先顺序列出。
Type: Array of Source objects (see Section 4.2.1.1)
类型：源对象数组（见第4.2.1.1节）
Mandatory-to-Specify: No. Default is to use static configuration, out-of-band from the CDNI Metadata interface.
必须指定：否。默认为使用静态配置，从CDNI元数据接口进行带外配置。
Example SourceMetadata object (which contains two Source objects) that describes which servers the dCDN should use for acquiring content for the applicable URI path and/or host:
示例SourceMetadata对象（包含两个源对象），描述dCDN应使用哪些服务器获取适用URI路径和/或主机的内容：
{
"generic-metadata-type": "MI.SourceMetadata",
"generic-metadata-value":
{
"sources": [
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "http/1.1"
},
{
"endpoints": ["origin.service123.example"],
"protocol": "http/1.1"
}
]
}
}
{
"generic-metadata-type": "MI.SourceMetadata",
"generic-metadata-value":
{
"sources": [
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "http/1.1"
},
{
"endpoints": ["origin.service123.example"],
"protocol": "http/1.1"
}
]
}
}
A Source object describes the source to be used by the dCDN for content acquisition (e.g., a Surrogate within the uCDN or an alternate origin server), the protocol to be used, and any authentication method to be used when contacting that source.
源对象描述dCDN用于内容获取的源（例如，uCDN内的代理或备用源服务器）、要使用的协议以及联系该源时要使用的任何身份验证方法。
Endpoints within a Source object MUST be treated as equivalent/equal. A uCDN can specify an array of sources, ordered by preference, within a SourceMetadata object. Then, for each Source object ranked by preference, a uCDN can specify an array of endpoints that are equivalent (e.g., a pool of servers that are not behind a load balancer).
源对象内的端点必须视为等效/相等。uCDN可以在SourceMetadata对象内指定按首选项排序的源数组。然后，对于按首选项排列的每个源对象，uCDN可以指定等效的端点数组（例如，不在负载平衡器后面的服务器池）。
Property: acquisition-auth
属性：获取授权
Description: Authentication method to use when requesting content from this source.
描述：从该源请求内容时使用的身份验证方法。
Type: Auth (see Section 4.2.7)
类型：认证（见第4.2.7节）
Mandatory-to-Specify: No. Default is no authentication required.
必须指定：否。默认为不需要身份验证。
Property: endpoints
属性：端点
Description: Origins from which the dCDN can acquire content. If multiple endpoints are specified, they are all equal, i.e., the list is not ordered by preference.
描述：dCDN可以从中获取内容的来源。如果指定了多个端点，则它们都是相等的，即列表不按首选项排序。
Type: Array of Endpoint objects (see Section 4.3.3)
类型：端点对象数组（见第4.3.3节）
Mandatory-to-Specify: Yes.
必须指定：是。
Property: protocol
属性：协议
Description: Network retrieval protocol to use when requesting content from this source.
描述：从该源请求内容时使用的网络检索协议。
Type: Protocol (see Section 4.3.2)
类型：协议（见第4.3.2节）
Mandatory-to-Specify: Yes.
必须指定：是。
Example Source object that describes a pair of endpoints (servers) the dCDN can use for acquiring content for the applicable host and/or URI path:
描述dCDN可用于获取适用主机和/或URI路径内容的一对端点（服务器）的示例源对象：
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "http/1.1"
}
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "http/1.1"
}
LocationACL metadata defines which locations a User Agent needs to be in, in order to be able to receive the associated content.
LocationACL元数据定义用户代理需要位于哪些位置才能接收关联内容。
A LocationACL that does not include a "locations" property results in an action of "allow all", meaning that delivery can be performed regardless of the User Agent's location; otherwise, a CDN MUST take the action from the first footprint to match against the User Agent's location. If two or more footprints overlap, the first footprint that matches against the User Agent's location determines the action
不包括“locations”属性的LocationACL会导致“allow all”操作，这意味着无论用户代理的位置如何，都可以执行传递；否则，CDN必须从第一个封装外形执行操作，以匹配用户代理的位置。如果两个或多个封装外形重叠，则与用户代理位置匹配的第一个封装外形将确定操作
a CDN MUST take. If the "locations" property is included but is empty or if none of the listed footprints match the User Agent's location, then the result is an action of "deny".
CDN必须采取行动。如果包含“locations”属性但为空，或者如果列出的封装外形中没有一个与用户代理的位置匹配，则结果是“deny”操作。
Although the LocationACL, TimeWindowACL (see Section 4.2.3), and ProtocolACL (see Section 4.2.4) are independent GenericMetadata objects, they can provide conflicting information to a dCDN, e.g., a content request that is simultaneously allowed based on the LocationACL and denied based on the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs (where "allow" is true and "deny" is false) to determine whether or not a request should be allowed.
尽管LocationACL、TimeWindowACL（参见第4.2.3节）和ProtocolACL（参见第4.2.4节）是独立的GenericMetadata对象，但它们可以向dCDN提供冲突信息，例如，基于LocationACL同时允许而基于TimeWindowACL同时拒绝的内容请求。dCDN必须使用所有ACL的逻辑AND（其中“允许”为true，“拒绝”为false）来确定是否应允许请求。
Property: locations
物业：地点
Description: ACL that allows or denies (blocks) delivery based on the User Agent's location.
描述：根据用户代理的位置允许或拒绝（阻止）传递的ACL。
Type: Array of LocationRule objects (see Section 4.2.2.1)
类型：LocationRule对象数组（见第4.2.2.1节）
Mandatory-to-Specify: No. Default is to allow all locations.
必须指定：否。默认为允许所有位置。
Example LocationACL object that allows the dCDN to deliver content to any location / IP address:
允许dCDN将内容传递到任何位置/IP地址的LocationACL对象示例：
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value":
{
}
}
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value":
{
}
}
Example LocationACL object (which contains a LocationRule object that in turn contains a Footprint object) that only allows the dCDN to deliver content to User Agents in the USA:
示例LocationACL对象（其中包含LocationRule对象，该对象又包含Footprint对象），仅允许dCDN向美国的用户代理交付内容：
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value":
{
"locations": [
{
"action": "allow",
"footprints": [
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
]
}
]
}
}
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value":
{
"locations": [
{
"action": "allow",
"footprints": [
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
]
}
]
}
}
A LocationRule contains or references an array of Footprint objects and the corresponding action.
LocationRule包含或引用封装外形对象数组和相应的操作。
Property: footprints
属性：脚印
Description: Array of footprints to which the rule applies.
描述：应用规则的封装外形数组。
Type: Array of Footprint objects (see Section 4.2.2.2)
类型：封装外形对象阵列（见第4.2.2.2节）
Mandatory-to-Specify: Yes.
必须指定：是。
Property: action
性质：行动
Description: Defines whether the rule specifies locations to allow or deny.
描述：定义规则是指定允许还是拒绝的位置。
Type: Enumeration [allow|deny] encoded as a lowercase string
类型：枚举[allow | deny]编码为小写字符串
Mandatory-to-Specify: No. Default is "deny".
必须指定：否。默认值为“拒绝”。
Example LocationRule object (which contains a Footprint object) that allows the dCDN to deliver content to clients in the USA:
示例LocationRule对象（包含Footprint对象），允许dCDN向美国的客户端交付内容：
{
"action": "allow",
"footprints": [
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
]
}
{
"action": "allow",
"footprints": [
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
]
}
A Footprint object describes the footprint to which a LocationRule can be applied, e.g., an IPv4 address range or a geographic location.
Footprint对象描述可以应用LocationRule的封装外形，例如IPv4地址范围或地理位置。
Property: footprint-type
属性：封装外形类型
Description: Registered footprint type (see Section 7.2). The footprint types specified by this document are "ipv4cidr" (IPv4CIDR; see Section 4.3.5), "ipv6cidr" (IPv6CIDR; see Section 4.3.6), "asn" (Autonomous System Number; see Section 4.3.7), and "countrycode" (Country Code; see Section 4.3.8).
说明：注册的封装外形类型（见第7.2节）。本文件规定的封装外形类型为“ipv4cidr”（ipv4cidr；见第4.3.5节）、“ipv6cidr”（ipv6cidr；见第4.3.6节）、“asn”（自主系统编号；见第4.3.7节）和“国家代码”（国家代码；见第4.3.8节）。
Type: Lowercase string
类型：小写字符串
Mandatory-to-Specify: Yes.
必须指定：是。
Property: footprint-value
属性：封装外形值
Description: Array of footprint values conforming to the specification associated with the registered footprint type. Footprint values can be simple strings (e.g., IPv4CIDR, IPv6CIDR, ASN, and Country Code); however, other Footprint objects can be defined in the future, along with a more complex encoding (e.g., GPS coordinate tuples).
描述：符合注册封装外形类型相关规范的封装外形值数组。封装外形值可以是简单的字符串（例如，IPv4CIDR、IPv6CIDR、ASN和国家代码）；但是，将来可以定义其他足迹对象，以及更复杂的编码（例如，GPS坐标元组）。
Type: Array of footprints
类型：封装外形阵列
Mandatory-to-Specify: Yes.
必须指定：是。
Example Footprint object describing a footprint covering the USA:
描述覆盖美国的足迹的足迹对象示例：
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
Example Footprint object describing a footprint covering the IP address ranges 192.0.2.0/24 and 198.51.100.0/24:
描述覆盖IP地址范围192.0.2.0/24和198.51.100.0/24的封装外形对象示例：
{
"footprint-type": "ipv4cidr",
"footprint-value": ["192.0.2.0/24", "198.51.100.0/24"]
}
{
"footprint-type": "ipv4cidr",
"footprint-value": ["192.0.2.0/24", "198.51.100.0/24"]
}
Example Footprint object describing a footprint covering the IP address ranges 2001:db8::/32:
描述覆盖IP地址范围2001:db8:：/32:
{
"footprint-type": "ipv6cidr",
"footprint-value": ["2001:db8::/32"]
}
{
"footprint-type": "ipv6cidr",
"footprint-value": ["2001:db8::/32"]
}
Example Footprint object describing a footprint covering the autonomous system 64496:
描述覆盖自治系统的封装外形的封装外形对象示例64496：
{
"footprint-type": "asn",
"footprint-value": ["as64496"]
}
{
"footprint-type": "asn",
"footprint-value": ["as64496"]
}
TimeWindowACL metadata defines time-based restrictions.
TimeWindowACL元数据定义基于时间的限制。
A TimeWindowACL that does not include a "times" property results in an action of "allow all", meaning that delivery can be performed regardless of the time of the User Agent's request; otherwise, a CDN MUST take the action from the first window to match against the current time. If two or more windows overlap, the first window that matches against the current time determines the action a CDN MUST take. If the "times" property is included but is empty or if none of the listed windows match the current time, then the result is an action of "deny".
不包含“times”属性的TimeWindowACL将导致“allow all”操作，这意味着无论用户代理请求的时间如何，都可以执行传递；否则，CDN必须从第一个窗口执行操作以匹配当前时间。如果两个或多个窗口重叠，则与当前时间匹配的第一个窗口将确定CDN必须采取的操作。如果包含“times”属性但为空，或者如果列出的窗口中没有与当前时间匹配的窗口，则结果是“deny”操作。
Although the LocationACL (see Section 4.2.2), TimeWindowACL, and ProtocolACL (see Section 4.2.4) are independent GenericMetadata objects, they can provide conflicting information to a dCDN, e.g.,
尽管LocationACL（参见第4.2.2节）、TimeWindowACL和ProtocolACL（参见第4.2.4节）是独立的GenericMetadata对象，但它们可以向dCDN提供冲突信息，例如。，
a content request that is simultaneously allowed based on the LocationACL and denied based on the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs (where "allow" is true and "deny" is false) to determine whether or not a request should be allowed.
基于LocationACL同时允许和基于TimeWindowACL同时拒绝的内容请求。dCDN必须使用所有ACL的逻辑AND（其中“允许”为true，“拒绝”为false）来确定是否应允许请求。
Property: times
物业：泰晤士报
Description: ACL that allows or denies (blocks) delivery based on the time of a User Agent's request.
描述：根据用户代理请求的时间允许或拒绝（阻止）传递的ACL。
Type: Array of TimeWindowRule objects (see Section 4.2.3.1)
类型：TimeWindowRule对象数组（见第4.2.3.1节）
Mandatory-to-Specify: No. Default is to allow all time windows.
必须指定：否。默认值是允许所有时间窗口。
Example TimeWindowACL object (which contains a TimeWindowRule object that in turn contains a TimeWindow object) that only allows the dCDN to deliver content to clients between 09:00 01/01/2000 UTC and 17:00 01/01/2000 UTC:
示例TimeWindowACL对象（其中包含一个TimeWindowRule对象，该对象又包含一个TimeWindow对象），该对象仅允许dCDN在09:00 01/01/2000 UTC和17:00 01/01/2000 UTC之间向客户端传递内容：
{
"generic-metadata-type": "MI.TimeWindowACL",
"generic-metadata-value":
{
"times": [
{
"action": "allow",
"windows": [
{
"start": 946717200,
"end": 946746000
}
]
}
]
}
}
{
"generic-metadata-type": "MI.TimeWindowACL",
"generic-metadata-value":
{
"times": [
{
"action": "allow",
"windows": [
{
"start": 946717200,
"end": 946746000
}
]
}
]
}
}
A TimeWindowRule contains or references an array of TimeWindow objects and the corresponding action.
TimeWindowRule包含或引用TimeWindow对象数组和相应的操作。
Property: windows
属性：windows
Description: Array of time windows to which the rule applies.
描述：应用规则的时间窗口数组。
Type: Array of TimeWindow objects (see Section 4.2.3.2)
类型：时间窗口对象数组（见第4.2.3.2节）
Mandatory-to-Specify: Yes.
必须指定：是。
Property: action
性质：行动
Description: Defines whether the rule specifies time windows to allow or deny.
描述：定义规则是否指定允许或拒绝的时间窗口。
Type: Enumeration [allow|deny] encoded as a lowercase string
类型：枚举[allow | deny]编码为小写字符串
Mandatory-to-Specify: No. Default is "deny".
必须指定：否。默认值为“拒绝”。
Example TimeWindowRule object (which contains a TimeWindow object) that only allows the dCDN to deliver content to clients between 09:00 01/01/2000 UTC and 17:00 01/01/2000 UTC:
示例TimeWindowRule对象（包含TimeWindow对象），仅允许dCDN在UTC 09:00 01/01/2000和UTC 17:00 01/01/2000之间向客户端传递内容：
{
"action": "allow",
"windows": [
{
"start": 946717200,
"end": 946746000
}
]
}
{
"action": "allow",
"windows": [
{
"start": 946717200,
"end": 946746000
}
]
}
A TimeWindow object describes a time range that can be applied by a TimeWindowACL, e.g., start 946717200 (i.e., 09:00 01/01/2000 UTC), end: 946746000 (i.e., 17:00 01/01/2000 UTC).
TimeWindow对象描述可由TimeWindowACL应用的时间范围，例如开始946717200（即09:00 01/01/2000 UTC），结束946746000（即17:00 01/01/2000 UTC）。
Property: start
属性：开始
Description: The start time of the window.
描述：窗口的开始时间。
Type: Time (see Section 4.3.4)
类型：时间（见第4.3.4节）
Mandatory-to-Specify: Yes.
必须指定：是。
Property: end
物业:完
Description: The end time of the window.
描述：窗口的结束时间。
Type: Time (see Section 4.3.4)
类型：时间（见第4.3.4节）
Mandatory-to-Specify: Yes.
必须指定：是。
Example TimeWindow object that describes a time window from 09:00 01/01/2000 UTC to 17:00 01/01/2000 UTC:
描述从09:00 01/01/2000 UTC到17:00 01/01/2000 UTC的时间窗口的示例TimeWindow对象：
{
"start": 946717200,
"end": 946746000
}
{
"start": 946717200,
"end": 946746000
}
ProtocolACL metadata defines delivery protocol restrictions.
ProtocolACL元数据定义传递协议限制。
A ProtocolACL that does not include a protocol-acl property results in an action of "allow all", meaning that delivery can be performed regardless of the protocol in the User Agent's request; otherwise, a CDN MUST take the action from the first protocol to match against the request protocol. If two or more request protocols overlap, the first protocol that matches the request protocol determines the action a CDN MUST take. If the protocol-acl property is included but is empty or if none of the listed protocols match the request protocol, then the result is an action of "deny".
不包括协议acl属性的ProtocolACL导致“allow all”操作，这意味着无论用户代理请求中的协议如何，都可以执行传递；否则，CDN必须从第一个协议执行操作，以匹配请求协议。如果两个或多个请求协议重叠，则与请求协议匹配的第一个协议将确定CDN必须采取的操作。如果包含协议acl属性但为空，或者如果列出的协议中没有一个与请求协议匹配，则结果是“拒绝”操作。
Although the LocationACL (see Section 4.2.2), TimeWindowACL (see Section 4.2.3), and ProtocolACL are independent GenericMetadata objects, they can provide conflicting information to a dCDN, e.g., a content request that is simultaneously allowed based on the ProtocolACL and denied based on the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs (where "allow" is true and "deny" is false) to determine whether or not a request should be allowed.
尽管LocationACL（参见第4.2.2节）、TimeWindowACL（参见第4.2.3节）和ProtocolACL是独立的GenericMetadata对象，但它们可以向dCDN提供冲突信息，例如，基于ProtocolACL同时允许而基于TimeWindowACL同时拒绝的内容请求。dCDN必须使用所有ACL的逻辑AND（其中“允许”为true，“拒绝”为false）来确定是否应允许请求。
Property: protocol-acl
属性：协议acl
Description: ACL that allows or denies (blocks) delivery based on delivery protocol.
描述：允许或拒绝（阻止）基于传递协议的传递的ACL。
Type: Array of ProtocolRule objects (see Section 4.2.4.1)
类型：ProtocolRule对象数组（见第4.2.4.1节）
Mandatory-to-Specify: No. Default is to allow all protocols.
必须指定：否。默认值是允许所有协议。
Example ProtocolACL object (which contains a ProtocolRule object) that only allows the dCDN to deliver content using HTTP/1.1:
ProtocolACL对象（包含ProtocolRule对象）示例，仅允许dCDN使用HTTP/1.1交付内容：
{
"generic-metadata-type": "MI.ProtocolACL",
"generic-metadata-value":
{
"protocol-acl": [
{
"action": "allow",
"protocols": ["http/1.1"]
}
]
}
}
{
"generic-metadata-type": "MI.ProtocolACL",
"generic-metadata-value":
{
"protocol-acl": [
{
"action": "allow",
"protocols": ["http/1.1"]
}
]
}
}
A ProtocolRule contains or references an array of Protocol objects and the corresponding action.
ProtocolRule包含或引用协议对象数组和相应的操作。
Property: protocols
属性：协议
Description: Array of protocols to which the rule applies.
描述：规则适用的协议数组。
Type: Array of Protocol objects (see Section 4.3.2)
类型：协议对象数组（见第4.3.2节）
Mandatory-to-Specify: Yes.
必须指定：是。
Property: action
性质：行动
Description: Defines whether the rule specifies protocols to allow or deny.
描述：定义规则是指定允许还是拒绝协议。
Type: Enumeration [allow|deny] encoded as a lowercase string
类型：枚举[allow | deny]编码为小写字符串
Mandatory-to-Specify: No. Default is "deny".
必须指定：否。默认值为“拒绝”。
Example ProtocolRule object (which contains a Protocol object) that allows the dCDN to deliver content using HTTP/1.1:
示例ProtocolRule对象（包含协议对象），允许dCDN使用HTTP/1.1交付内容：
{
"action": "allow",
"protocols": ["http/1.1"]
}
{
"action": "allow",
"protocols": ["http/1.1"]
}
Delivery authorization defines authorization methods for the delivery of content to User Agents.
交付授权定义了将内容交付给用户代理的授权方法。
Property: delivery-auth-methods
属性：传递身份验证方法
Description: Options for authorizing content requests. Delivery for a content request is authorized if any one of the authorization methods in the list is satisfied for that request.
描述：用于授权内容请求的选项。如果列表中的任何一种授权方法满足该请求，则授权内容请求的交付。
Type: Array of Auth objects (see Section 4.2.7)
类型：验证对象数组（见第4.2.7节）
Mandatory-to-Specify: No. Default is no authorization required.
必须指定：否。默认为不需要授权。
Example DeliveryAuthorization object (which contains an Auth object):
示例DeliveryAuthorization对象（包含Auth对象）：
{
"generic-metadata-type": "MI.DeliveryAuthorization",
"generic-metadata-value":
{
"delivery-auth-methods": [
{
"auth-type": <CDNI Payload Type of this Auth object>,
"auth-value":
{
<Properties of this Auth object>
}
}
]
}
}
{
"generic-metadata-type": "MI.DeliveryAuthorization",
"generic-metadata-value":
{
"delivery-auth-methods": [
{
"auth-type": <CDNI Payload Type of this Auth object>,
"auth-value":
{
<Properties of this Auth object>
}
}
]
}
}
A Cache object describes the cache control parameters to be applied to the content by intermediate caches.
缓存对象描述中间缓存应用于内容的缓存控制参数。
Cache keys are generated from the URI of the content request [RFC7234]. In some cases, a CDN or content provider might want certain path segments or query parameters to be excluded from the cache key generation. The Cache object provides guidance on what parts of the path and query string to include.
缓存键是从内容请求[RFC7234]的URI生成的。在某些情况下，CDN或内容提供商可能希望从缓存密钥生成中排除某些路径段或查询参数。Cache对象提供了关于路径和查询字符串的哪些部分要包括的指导。
Property: exclude-path-pattern
属性：排除路径模式
Description: A pattern for matching against the URI path, i.e., against the path-absolute [RFC3986]. The pattern can contain the wildcards "*" and "?", where "*" matches any sequence of pchar [RFC3986] or "/" characters (including the empty string) and "?" matches exactly one pchar character. The three literals "$", "*", and "?" MUST be escaped as "$$", "$*", and "$?" (where "$" is the designated escape character). All other characters are treated as literals. Cache key generation MUST only include the portion of the path-absolute that matches the wildcard portions of the pattern. Note: Inconsistency between the PatternMatch pattern (Section 4.1.5) and the exclude-path-pattern can result in inefficient caching.
描述：与URI路径匹配的模式，即与绝对路径匹配[RFC3986]。模式可以包含通配符“*”和“？”，其中“*”匹配任何pchar[RFC3986]或“/”字符序列（包括空字符串），而“？”正好匹配一个pchar字符。三个文本“$”、“*”和“？”必须转义为“$$”、“$*”和“$？”（“$”是指定的转义字符）。所有其他字符都被视为文字。缓存密钥生成必须仅包括与模式的通配符部分匹配的绝对路径部分。注意：PatternMatch模式（第4.1.5节）和exclude path模式之间的不一致可能导致缓存效率低下。
Type: String
类型：字符串
Mandatory-to-Specify: No. Default is to use the full URI path-absolute to generate the cache key.
必须指定：否。默认值是使用完整URI绝对路径生成缓存密钥。
Property: include-query-strings
属性：包含查询字符串
Description: Allows a Surrogate to specify the URI query string parameters [RFC3986] to include when comparing the requested URI against the URIs in its cache for equivalence. Matching query parameters MUST be case insensitive. If all query parameters should be ignored, then the list MUST be specified and MUST be empty. If a query parameter appears multiple times in the query string, each instance value MUST be aggregated prior to comparison. For consistent cache key generation, query parameters SHOULD be evaluated in the order specified in this array.
描述：允许代理指定URI查询字符串参数[RFC3986]，以便在将请求的URI与其缓存中的URI进行等效性比较时包含该参数。匹配的查询参数必须不区分大小写。如果应忽略所有查询参数，则必须指定列表，并且列表必须为空。如果查询参数在查询字符串中多次出现，则必须在比较之前聚合每个实例值。为了生成一致的缓存密钥，应按照此数组中指定的顺序计算查询参数。
Type: Array of strings
类型：字符串数组
Mandatory-to-Specify: No. Default is to consider all query string parameters when comparing URIs.
默认是在比较URI时考虑所有查询字符串参数。
Example Cache object that instructs the dCDN to use the full URI path and ignore all query parameters:
指示dCDN使用完整URI路径并忽略所有查询参数的缓存对象示例：
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"include-query-strings": []
}
}
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"include-query-strings": []
}
}
Example Cache object that instructs the dCDN to exclude the "CDNX" path prefix and only include the (case-insensitive) query parameters named "mediaid" and "providerid":
指示dCDN排除“CDNX”路径前缀并仅包括名为“mediaid”和“providerid”的（不区分大小写）查询参数的缓存对象示例：
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"exclude-path-pattern": "/CDNX/*",
"include-query-strings": ["mediaid", "providerid"]
}
}
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"exclude-path-pattern": "/CDNX/*",
"include-query-strings": ["mediaid", "providerid"]
}
}
Example Cache object that instructs the dCDN to exclude the "CDNX" path prefix but includes all query parameters:
指示dCDN排除“CDNX”路径前缀但包含所有查询参数的缓存对象示例：
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"exclude-path-pattern": "/CDNX/*"
}
}
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"exclude-path-pattern": "/CDNX/*"
}
}
An Auth object defines authentication and authorization methods to be used during content acquisition and content delivery, respectively.
Auth对象分别定义在内容获取和内容交付期间使用的身份验证和授权方法。
Note: This document does not define any Auth methods. Individual Auth methods are being defined separately (e.g., URI Signing [CDNI-URI-SIGNING]). The GenericMetadata object that contains Auth objects is defined herein for convenience and so as not to be specific to any particular Auth method.
注意：本文档未定义任何身份验证方法。单独定义各个身份验证方法（例如URI签名[CDNI-URI-Signing]）。此处定义包含Auth对象的GenericMetadata对象是为了方便，并且不特定于任何特定的Auth方法。
Property: auth-type
属性：身份验证类型
Description: Auth type (The CDNI Payload Type [RFC7736] of the GenericMetadata object contained in the auth-value property).
Description:Auth type（Auth value属性中包含的GenericMetadata对象的CDNI有效负载类型[RFC7736]）。
Type: String
类型：字符串
Mandatory-to-Specify: Yes.
必须指定：是。
Property: auth-value
属性：auth值
Description: An object conforming to the specification associated with the Auth type.
描述：符合认证类型相关规范的对象。
Type: GenericMetadata object
类型：GenericMetadata对象
Mandatory-to-Specify: Yes.
必须指定：是。
Example Auth object:
验证对象示例：
{
"generic-metadata-type": "MI.Auth",
"generic-metadata-value":
{
"auth-type": <CDNI Payload Type of this Auth object>,
"auth-value":
{
<Properties of this Auth object>
}
}
}
{
"generic-metadata-type": "MI.Auth",
"generic-metadata-value":
{
"auth-type": <CDNI Payload Type of this Auth object>,
"auth-value":
{
<Properties of this Auth object>
}
}
}
A Grouping object identifies a group of content to which a given asset belongs.
分组对象标识给定资产所属的一组内容。
Property: ccid
物业名称：赛迪
Description: Content Collection IDentifier for an application-specific purpose such as logging aggregation.
描述：用于特定于应用程序的内容集合标识符，例如日志聚合。
Type: String
类型：字符串
Mandatory-to-Specify: No. Default is not to apply any grouping.
必须指定：否。默认情况下不应用任何分组。
Example Grouping object that specifies a Content Collection IDentifier for the content associated with the Grouping object's parent HostMetadata and PathMetadata:
为与分组对象的父HostMetadata和PathMetadata关联的内容指定内容集合标识符的分组对象示例：
{
"generic-metadata-type": "MI.Grouping",
"generic-metadata-value":
{
"ccid": "ABCD"
}
}
{
"generic-metadata-type": "MI.Grouping",
"generic-metadata-value":
{
"ccid": "ABCD"
}
}
This section describes the simple data types that are used for properties of CDNI Metadata objects.
本节介绍用于CDNI元数据对象属性的简单数据类型。
A Link object can be used in place of any of the objects described above. Link objects can be used to avoid duplication if the same metadata information is repeated within the metadata tree. When a Link object replaces another object, its "href" property is set to the URI of the resource and its "type" property is set to the CDNI Payload Type of the object it is replacing.
可以使用链接对象代替上述任何对象。如果在元数据树中重复相同的元数据信息，则可以使用链接对象来避免重复。当一个链接对象替换另一个对象时，其“href”属性设置为资源的URI，其“type”属性设置为所替换对象的CDNI有效负载类型。
dCDNs can detect the presence of a Link object by detecting the presence of a property named "href" within the object. This means that GenericMetadata types MUST NOT contain a property named "href" because doing so would conflict with the ability for dCDNs to detect Link objects being used to reference a GenericMetadata object.
dCDNs可以通过检测对象中是否存在名为“href”的属性来检测链接对象的存在。这意味着GenericMetadata类型不能包含名为“href”的属性，因为这样做会与dCDNs检测用于引用GenericMetadata对象的链接对象的能力相冲突。
Property: href
属性：href
Description: The URI of the addressable object being referenced.
描述：被引用的可寻址对象的URI。
Type: String
类型：字符串
Mandatory-to-Specify: Yes.
必须指定：是。
Property: type
属性：类型
Description: The CDNI Payload Type of the object being referenced.
描述：被引用对象的CDNI有效负载类型。
Type: String
类型：字符串
Mandatory-to-Specify: No. If the container specifies the type (e.g., the HostIndex object contains an array of HostMatch objects, so a Link object in the list of HostMatch objects must reference a HostMatch), then it is not necessary to explicitly specify a type.
必须指定：否。如果容器指定类型（例如，HostIndex对象包含HostMatch对象数组，因此HostMatch对象列表中的链接对象必须引用HostMatch），则无需显式指定类型。
Example Link object referencing a HostMatch object:
引用HostMatch对象的链接对象示例：
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
Example Link object referencing a HostMatch object, without an explicit type, inside a HostIndex object:
在HostIndex对象内引用HostMatch对象（无显式类型）的链接对象示例：
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"href": "https://metadata.ucdn.example/hostmatch1234"
}
]
}
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"href": "https://metadata.ucdn.example/hostmatch1234"
}
]
}
When following a link, CDNI Metadata clients SHOULD verify that the CDNI Payload Type of the object retrieved matches the expected CDNI Payload Type, as indicated by the Link object or containing property. For GenericMetadata objects, type checks will prevent self-references; however, incorrect linking can result in circular references for structural metadata objects, specifically PathMatch and PathMetadata objects (Figure 1). To prevent circular references, CDNI Metadata clients SHOULD verify that no duplicate links occur for PathMatch or PathMetadata objects.
跟踪链接时，CDNI元数据客户端应验证检索到的对象的CDNI有效负载类型是否与预期的CDNI有效负载类型匹配，如链接对象或包含属性所示。对于GenericMetadata对象，类型检查将阻止自引用；但是，不正确的链接可能会导致结构元数据对象的循环引用，特别是PathMatch和PathMetadata对象（图1）。为了防止循环引用，CDNI元数据客户端应该验证PathMatch或PathMetadata对象没有重复链接。
Protocol objects are used to specify protocols (from the "CDNI Metadata Protocol Types" registry; see Section 7.3) for content acquisition or delivery.
协议对象用于指定内容获取或交付的协议（来自“CDNI元数据协议类型”注册表；请参见第7.3节）。
Type: String
类型：字符串
Example:
例子：
"http/1.1"
“http/1.1”
A hostname (with optional port) or an IP address (with optional port).
主机名（带可选端口）或IP地址（带可选端口）。
All implementations MUST support IPv4 addresses encoded as specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986]. IPv6 addresses MUST be encoded in one of the IPv6 address formats specified in [RFC5952], although receivers MUST support all IPv6 address formats specified in [RFC4291]. Hostnames MUST conform to
所有实现必须支持[RFC3986]第3.2.2节中“IPv4address”规则指定的编码IPv4地址。IPv6地址必须以[RFC5952]中指定的一种IPv6地址格式进行编码，尽管接收器必须支持[RFC4291]中指定的所有IPv6地址格式。主机名必须符合
the Domain Name System (DNS) syntax defined in [RFC1034] and [RFC1123]. Internationalized Domain Names (IDNs) must first be transformed to the A-label form [RFC5890] as per [RFC5891].
[RFC1034]和[RFC1123]中定义的域名系统（DNS）语法。国际化域名（IDN）必须首先按照[RFC5891]转换为A标签形式[RFC5890]。
Type: String
类型：字符串
Example hostname:
主机名示例：
"metadata.ucdn.example"
“metadata.ucdn.example”
Example IPv4 address:
IPv4地址示例：
"192.0.2.1"
"192.0.2.1"
Example IPv6 address (with port number):
IPv6地址示例（带有端口号）：
"[2001:db8::1]:81"
"[2001:db8::1]:81"
A time value expressed in seconds since the UNIX epoch (i.e., zero hours, zero minutes, zero seconds, on January 1, 1970) Coordinated Universal Time (UTC) [POSIX].
自UNIX纪元（即1970年1月1日的零小时、零分钟、零秒）协调世界时（UTC）[POSIX]以来以秒表示的时间值。
Type: Integer
类型：整数
Example time representing 09:00:00 01/01/2000 UTC:
代表UTC 09:00:00 01/01/2000的时间示例：
946717200
946717200
An IPv4address Classless Inter-Domain Routing (CIDR) block encoded as specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986] followed by a "/" followed by an unsigned integer representing the leading bits of the routing prefix (i.e., IPv4 CIDR notation). Single IP addresses can be expressed as /32.
按照[RFC3986]第3.2.2节中的“IPv4address”规则进行编码的IPv4address无类域间路由（CIDR）块，后跟“/”和表示路由前缀前导位的无符号整数（即IPv4 CIDR表示法）。单个IP地址可以表示为/32。
Type: String
类型：字符串
Example IPv4CIDR:
IPv4CIDR示例：
"192.0.2.0/24"
"192.0.2.0/24"
An IPv6address CIDR block encoded in one of the IPv6 address formats specified in [RFC5952] followed by a "/" followed by an unsigned integer representing the leading bits of the routing prefix (i.e., IPv6 CIDR notation). Single IP addresses can be expressed as /128.
以[RFC5952]中指定的IPv6地址格式之一编码的IPv6address CIDR块，后跟“/”和表示路由前缀前导位的无符号整数（即IPv6 CIDR表示法）。单个IP地址可以表示为/128。
Type: String
类型：字符串
Example IPv6CIDR:
IPv6CIDR示例：
"2001:db8::/32"
"2001:db8::/32"
An ASN value encoded as a string consisting of the characters "as" (in lowercase) followed by the ASN [RFC6793].
编码为字符串的ASN值，由字符“as”（小写）后跟ASN[RFC6793]组成。
Type: String
类型：字符串
Example ASN:
示例ASN：
"as64496"
“as64496”
An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase.
小写的ISO 3166-1 alpha-2代码[ISO3166-1]。
Type: String
类型：字符串
Example Country Code representing the USA:
代表美国的国家代码示例：
"us"
“美国”
CDNI Metadata is used to convey information pertaining to content delivery from the uCDN to the dCDN. For optional metadata, it can be useful for the uCDN to know, prior to delegating any content requests to a given dCDN, if that dCDN supports the underlying functionality described by the metadata. If some metadata is mandatory-to-enforce and the dCDN does not support it, any delegated requests for content that requires that metadata will fail. The uCDN will likely want to avoid delegating those requests to that dCDN. Likewise, for any metadata that might be assigned optional values, it could be useful for the uCDN to know, prior to delegating any content requests to a given dCDN, which values that dCDN supports. If the optional value assigned to a given piece of content's metadata is not supported by
CDNI元数据用于将有关内容交付的信息从uCDN传递到dCDN。对于可选元数据，uCDN在将任何内容请求委托给给定dCDN之前，了解该dCDN是否支持元数据所描述的底层功能是非常有用的。如果强制执行某些元数据，而dCDN不支持它，则对需要该元数据的内容的任何委托请求都将失败。uCDN可能希望避免将这些请求委托给该dCDN。同样，对于任何可能被分配可选值的元数据，uCDN在将任何内容请求委托给给定dCDN之前，了解dCDN支持哪些值可能会很有用。如果指定给给定内容元数据的可选值不受
the dCDN, any delegated requests for that content can fail, so again the uCDN is likely to want to avoid delegating those requests to that dCDN.
在dCDN中，对该内容的任何委托请求都可能失败，因此uCDN可能再次希望避免将这些请求委托给该dCDN。
The CDNI Footprint & Capabilities Advertisement interface (FCI) provides a means of advertising capabilities from the dCDN to the uCDN [RFC8008]. Support for optional metadata types and values can be advertised using the FCI.
CDNI Footprint&Capabilities广告接口（FCI）提供了一种从dCDN到uCDN的广告功能方式[RFC8008]。可以使用FCI公布对可选元数据类型和值的支持。
This section specifies an interface to enable a dCDN to retrieve CDNI Metadata objects from a uCDN.
本节指定一个接口，使dCDN能够从uCDN检索CDNI元数据对象。
The interface can be used by a dCDN to retrieve CDNI Metadata objects in either of two ways:
dCDN可以通过以下两种方式之一使用该接口检索CDNI元数据对象：
o Dynamically, as required by the dCDN to process received requests -- for example, in response to a query from a uCDN over the CDNI Request Routing Redirection interface (RI) [RFC7975] or in response to receiving a request for content from a User Agent.
o 动态地，根据dCDN处理接收到的请求的要求——例如，响应uCDN通过CDNI请求路由重定向接口（RI）[RFC7975]发出的查询，或者响应从用户代理接收的内容请求。
o In advance of being required -- for example, in the case of pre-positioned CDNI Metadata acquisition, initiated through the "CDNI Control interface / Triggers" (CI/T) interface [RFC8007].
o 在需要之前——例如，在预定位CDNI元数据获取的情况下，通过“CDNI控制接口/触发器”（CI/T）接口[RFC8007]启动。
The CDNI Metadata interface is built on the principles of HTTP web services. In particular, this means that requests and responses over the interface are built around the transfer of representations of hyperlinked resources. A resource in the context of the CDNI Metadata interface is any object in the object model (as described in Sections 3 and 4).
CDNI元数据接口基于HTTP web服务的原则构建。特别是，这意味着接口上的请求和响应是围绕超链接资源表示的传输构建的。CDNI元数据接口上下文中的资源是对象模型中的任何对象（如第3节和第4节所述）。
CDNI Metadata servers (i.e., servers in the uCDN) are free to assign whatever structure they desire to the URIs for CDNI Metadata objects, and CDNI Metadata clients MUST NOT make any assumptions regarding the structure of CDNI Metadata URIs or the mapping between CDNI Metadata objects and their associated URIs. Any URIs present in the examples in this document are purely illustrative and are not intended to impose a definitive structure on CDNI Metadata interface implementations.
CDNI元数据服务器（即uCDN中的服务器）可以自由地为CDNI元数据对象的URI分配其所需的任何结构，并且CDNI元数据客户端不得对CDNI元数据URI的结构或CDNI元数据对象与其关联URI之间的映射作出任何假设。本文档中示例中的任何URI都只是说明性的，并不打算在CDNI元数据接口实现上强加一个明确的结构。
The CDNI Metadata interface uses HTTP as the underlying protocol transport [RFC7230].
CDNI元数据接口使用HTTP作为底层协议传输[RFC7230]。
The HTTP method in the request defines the operation the request would like to perform. A server implementation of the CDNI Metadata interface MUST support the HTTP GET and HEAD methods.
请求中的HTTP方法定义请求要执行的操作。CDNI元数据接口的服务器实现必须支持HTTP GET和HEAD方法。
The corresponding HTTP response returns the status of the operation in the HTTP status code and returns the current representation of the resource (if appropriate) in the response body. HTTP responses that contain a response body SHOULD include an entity-tag (ETag) to enable validation of cached versions of returned resources.
相应的HTTP响应返回HTTP状态代码中的操作状态，并返回响应正文中资源的当前表示形式（如果适用）。包含响应主体的HTTP响应应包含实体标记（ETag），以启用对返回资源的缓存版本的验证。
As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata server implementations MAY make use of any HTTP feature when implementing the CDNI Metadata interface; for example, a CDNI Metadata server MAY make use of HTTP's caching mechanisms to indicate that the returned response/representation can be reused without re-contacting the CDNI Metadata server.
由于CDNI元数据接口构建在HTTP之上，CDNI元数据服务器实现在实现CDNI元数据接口时可以使用任何HTTP特性；例如，CDNI元数据服务器可以使用HTTP的缓存机制来指示返回的响应/表示可以重用，而无需重新联系CDNI元数据服务器。
In the general case, a CDNI Metadata server makes CDNI Metadata objects available via unique URIs; thus, in order to retrieve CDNI Metadata, a CDNI Metadata client (i.e., a client in the dCDN) first makes an HTTP GET request for the URI of the HostIndex, which provides an array of hostnames for which the uCDN can delegate content delivery to the dCDN.
在一般情况下，CDNI元数据服务器通过唯一的URI使CDNI元数据对象可用；因此，为了检索CDNI元数据，CDNI元数据客户机（即dCDN中的客户机）首先对HostIndex的URI发出HTTP GET请求，该请求提供了一个主机名数组，uCDN可以将内容传递委托给dCDN。
In order to retrieve the CDNI Metadata for a particular request, the CDNI Metadata client processes the received HostIndex object and finds the corresponding HostMetadata entry (by matching the hostname in the request against the hostnames listed in the HostMatch objects). If the HostMetadata is linked (rather than embedded), the CDNI Metadata client then makes an HTTP GET request for the URI specified in the "href" property of the Link object, which points to the HostMetadata object itself.
为了检索特定请求的CDNI元数据，CDNI元数据客户端处理收到的HostIndex对象并查找相应的HostMetadata条目（通过将请求中的主机名与HostMatch对象中列出的主机名进行匹配）。如果HostMetadata是链接的（而不是嵌入的），CDNI元数据客户端会对链接对象的“href”属性中指定的URI发出HTTP GET请求，该属性指向HostMetadata对象本身。
In order to retrieve the most specific metadata for a particular request, the CDNI Metadata client inspects the HostMetadata for references to more-specific PathMetadata objects (by matching the URI path in the request against the path-pattern property items in any PathMatch objects listed in the HostMetadata object). If a PathMetadata object is found to match (and is linked rather than embedded), the CDNI Metadata client makes another HTTP GET request for the PathMetadata. Each PathMetadata object can also include
为了为特定请求检索最特定的元数据，CDNI元数据客户端将检查HostMetadata以查找对更特定PathMetadata对象的引用（通过将请求中的URI路径与HostMetadata对象中列出的任何PathMatch对象中的路径模式属性项相匹配）。如果发现PathMetadata对象匹配（并且链接而不是嵌入），CDNI元数据客户端将对PathMetadata发出另一个HTTP GET请求。每个PathMetadata对象还可以包括
references to additional more-specific metadata. If this is the case, the CDNI Metadata client continues requesting PathMatch and PathMetadata objects recursively. The CDNI Metadata client repeats this approach of processing metadata objects and retrieving (via HTTP GETs) any linked objects until it has all the metadata objects it requires in order to process the redirection request from the uCDN or the content request from a User Agent.
对其他更具体元数据的引用。如果是这种情况，CDNI元数据客户端将继续递归地请求PathMatch和PathMetadata对象。CDNI元数据客户端重复这种处理元数据对象和检索（通过HTTP GETs）任何链接对象的方法，直到拥有处理uCDN的重定向请求或用户代理的内容请求所需的所有元数据对象。
In cases where a dCDN is not able to retrieve the entire set of CDNI Metadata associated with a User Agent request, or it has retrieved that metadata but it is stale according to standard HTTP caching rules and cannot be revalidated -- for example, because the uCDN is unreachable or returns an HTTP 4xx or 5xx status in response to some or all of the dCDN's CDNI Metadata requests -- the dCDN MUST NOT serve the requested content.
如果dCDN无法检索与用户代理请求关联的整个CDNI元数据集，或者它已检索到该元数据，但根据标准HTTP缓存规则，该元数据已过时且无法重新验证，例如，由于uCDN不可访问或返回HTTP 4xx或5xx状态以响应dCDN的部分或全部CDNI元数据请求，因此dCDN不得提供请求的内容。
Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to determine which uCDN's CDNI Metadata interface should be used to handle a particular User Agent request.
当dCDN与多个uCDN互连时，dCDN需要确定应使用哪个uCDN的CDNI元数据接口来处理特定的用户代理请求。
When HTTP redirection (e.g., HTTP 302 redirects) is being used between CDNs, it is expected that the dCDN will be able to determine the uCDN that redirected a particular request from information contained in the received request (e.g., via the URI). With knowledge of which uCDN routed the request, the dCDN can choose the correct uCDN from which to obtain the HostIndex. Note that the HostIndexes served by each uCDN can be unique.
当在cdn之间使用HTTP重定向（例如，HTTP 302重定向）时，预期dCDN将能够根据接收到的请求中包含的信息（例如，通过URI）确定重定向特定请求的uCDN。知道哪个uCDN路由请求后，dCDN可以选择正确的uCDN来获取主机索引。请注意，每个uCDN提供的主机索引可以是唯一的。
In the case of DNS redirection, there is not always sufficient information carried in the DNS request from User Agents to determine the uCDN that redirected a particular request (e.g., when content from a given host is redirected to a given dCDN by more than one uCDN); therefore, dCDNs will have to apply local policy when deciding which uCDN's CDNI Metadata interface to use.
在DNS重定向的情况下，来自用户代理的DNS请求中并不总是携带足够的信息来确定重定向特定请求的uCDN（例如，当来自给定主机的内容被多个uCDN重定向到给定dCDN时）；因此，在决定使用哪个uCDN的CDNI元数据接口时，dCDNs必须应用本地策略。
The URI for the HostIndex object of a given uCDN needs to be configured in the dCDN. All other objects/resources are then discoverable from the HostIndex object by following any links in the HostIndex object, and through the referenced HostMetadata and PathMetadata objects and their GenericMetadata sub-objects.
需要在dCDN中配置给定uCDN的HostIndex对象的URI。然后，通过遵循HostIndex对象中的任何链接，并通过引用的HostMetadata和PathMetadata对象及其GenericMetadata子对象，可以从HostIndex对象中发现所有其他对象/资源。
Manual configuration of the URI for the HostIndex object is outside the scope of this document.
HostIndex对象的URI的手动配置超出了本文档的范围。
CDNI Metadata objects MUST be encoded as I-JSON objects [RFC7493] containing a dictionary of (key,value) pairs where the keys are the property names and the values are the associated property values.
CDNI元数据对象必须编码为I-JSON对象[RFC7493]，其中包含（键、值）对字典，其中键是属性名称，值是关联的属性值。
The keys of the dictionary are the names of the properties associated with the object and are therefore dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the returned resource). Likewise, the values associated with each property (dictionary key) are dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the returned resource).
字典的键是与对象关联的属性的名称，因此依赖于正在编码的特定对象（即，依赖于返回资源的CDNI有效负载类型）。同样，与每个属性（字典键）相关联的值取决于正在编码的特定对象（即，取决于返回资源的CDNI有效负载类型）。
Dictionary keys (properties) in I-JSON are case sensitive. By convention, any dictionary key (property) defined by this document (for example, the names of CDNI Metadata object properties) MUST be lowercase.
I-JSON中的字典键（属性）区分大小写。按照约定，此文档定义的任何字典键（属性）（例如，CDNI元数据对象属性的名称）必须是小写的。
The set of GenericMetadata objects can be extended with additional (standards-based or vendor-specific) metadata objects through the specification of new GenericMetadata objects. The GenericMetadata object defined in Section 4.1.7 specifies a type field and a type-specific value field that allow any metadata to be included in either the HostMetadata or PathMetadata arrays.
通过指定新的GenericMetadata对象，可以使用其他（基于标准或特定于供应商的）元数据对象扩展GenericMetadata对象集。第4.1.7节中定义的GenericMetadata对象指定了一个类型字段和一个特定于类型的值字段，允许在HostMetadata或PathMetadata数组中包含任何元数据。
As with the initial GenericMetadata types defined in Section 4.2, future GenericMetadata types MUST specify the information necessary for constructing and decoding the GenericMetadata object.
与第4.2节中定义的初始GenericMetadata类型一样，未来的GenericMetadata类型必须指定构造和解码GenericMetadata对象所需的信息。
Any document that defines a new GenericMetadata type MUST:
定义新GenericMetadata类型的任何文档必须：
1. Register the CDNI Payload Type [RFC7736] used to identify the new GenericMetadata type being specified.
1. 注册用于标识指定的新GenericMetadata类型的CDNI有效负载类型[RFC7736]。
2. Define the set of properties associated with the new GenericMetadata object. GenericMetadata MUST NOT contain a property named "href" because doing so would conflict with the ability to detect Link objects (see Section 4.3.1).
2. 定义与新GenericMetadata对象关联的属性集。GenericMetadata不能包含名为“href”的属性，因为这样做会与检测链接对象的能力相冲突（请参见第4.3.1节）。
3. For each property, define a name, description, type, and whether or not the property is mandatory-to-specify.
3. 对于每个特性，定义名称、说明、类型以及是否必须指定该特性。
4. Describe the semantics of the new type, including its purpose, and provide a use case to which it applies, including an example encoded in I-JSON.
4. 描述新类型的语义，包括它的用途，并提供一个应用它的用例，包括一个用I-JSON编码的示例。
5. Describe the security and privacy consequences, for both the User Agent and the CDNs, of the new GenericMetadata object.
5. 描述新GenericMetadata对象对用户代理和CDN的安全和隐私后果。
6. Describe any relation to, conflict with, or obsolescence of other existing CDNI Metadata objects.
6. 描述与其他现有CDNI元数据对象的任何关系、冲突或过时。
Note: In the case of vendor-specific extensions, vendor-identifying CDNI Payload Type names will decrease the possibility of GenericMetadata type collisions. It is RECOMMENDED that any vendor-specific extensions use vendor-identifying CDNI Payload Type names.
注意：对于特定于供应商的扩展，供应商识别CDNI有效负载类型名称将降低GenericMetadata类型冲突的可能性。建议任何特定于供应商的扩展使用供应商标识的CDNI有效负载类型名称。
At any given time, the set of GenericMetadata types supported by the uCDN might not match the set of GenericMetadata types supported by the dCDN.
在任何给定时间，uCDN支持的GenericMetadata类型集可能与dCDN支持的GenericMetadata类型集不匹配。
In cases where a uCDN sends metadata containing a GenericMetadata type that a dCDN does not support, the dCDN MUST enforce the semantics of the mandatory-to-enforce property. If a dCDN does not understand or is unable to perform the functions associated with any mandatory-to-enforce metadata, the dCDN MUST NOT service any requests for the corresponding content.
在uCDN发送包含dCDN不支持的GenericMetadata类型的元数据的情况下，dCDN必须强制执行强制属性的语义。如果dCDN不理解或无法执行与强制执行元数据的任何强制命令相关联的功能，则dCDN不得为相应内容的任何请求提供服务。
Note: Ideally, uCDNs would not delegate content requests to a dCDN that does not support the mandatory-to-enforce metadata associated with the content being requested. However, even if the uCDN has a priori knowledge of the metadata supported by the dCDN (e.g., via the FCI or through out-of-band negotiation between CDN operators), metadata support can fluctuate or be inconsistent (e.g., due to miscommunication, misconfiguration, or temporary outage). Thus, the dCDN MUST always evaluate all metadata associated with redirection and content requests and reject any requests where mandatory-to-enforce metadata associated with the content cannot be enforced.
注意：理想情况下，uCDNs不会将内容请求委托给不支持强制执行与所请求内容关联的元数据的dCDN。然而，即使uCDN对dCDN支持的元数据有先验知识（例如，通过FCI或CDN运营商之间的带外协商），元数据支持也可能波动或不一致（例如，由于通信错误、配置错误或临时中断）。因此，dCDN必须始终评估与重定向和内容请求相关联的所有元数据，并拒绝强制执行与内容相关联的元数据的任何请求。
It is possible that new metadata definitions will obsolete or conflict with existing GenericMetadata (e.g., a future revision of the CDNI Metadata interface could redefine the Auth GenericMetadata object or a custom vendor extension could implement an alternate Auth metadata option). If multiple metadata (e.g., MI.Auth.v2, vendor1.Auth, and vendor2.Auth) all conflict with an existing GenericMetadata object (i.e., MI.Auth) and all are marked as
新的元数据定义可能会过时或与现有的GenericMetadata冲突（例如，CDNI元数据接口的未来版本可能会重新定义Auth GenericMetadata对象，或者自定义供应商扩展可能会实现替代Auth元数据选项）。如果多个元数据（例如MI.Auth.v2、vendor1.Auth和vendor2.Auth）都与现有的GenericMetadata对象（例如MI.Auth）冲突，并且都标记为
mandatory-to-enforce, it could be ambiguous as to which metadata should be applied, especially in the case of overlapping functionality.
强制执行时，对于应应用哪些元数据可能会有歧义，特别是在功能重叠的情况下。
As described in Section 3.3, metadata override only applies to metadata objects of the same exact type found in HostMetadata and nested PathMetadata structures. The CDNI Metadata interface does not support enforcement of dependencies between different GenericMetadata types. It is the responsibility of the CSP and the CDN operators to ensure that metadata assigned to a given piece of content do not conflict.
如第3.3节所述，元数据覆盖仅适用于HostMetadata和嵌套PathMetadata结构中相同类型的元数据对象。CDNI元数据接口不支持强制不同GenericMetadata类型之间的依赖关系。CSP和CDN运营商有责任确保分配给给定内容的元数据不冲突。
Note: Because metadata is inherently ordered in HostMetadata and PathMetadata arrays, as well as in the PathMatch hierarchy, multiple conflicting metadata types MAY be used; however, metadata hierarchies SHOULD ensure that independent PathMatch root objects are used to prevent ambiguous or conflicting metadata definitions.
注意：由于元数据在HostMetadata和PathMetadata数组以及PathMatch层次结构中固有的顺序，因此可能会使用多个冲突的元数据类型；但是，元数据层次结构应确保使用独立的PathMatch根对象来防止不明确或冲突的元数据定义。
The version of CDNI Metadata objects is conveyed inside the CDNI
Payload Type that is included in either (1) the HTTP Content-Type
header (for example, "Content-Type: application/cdni;
ptype=MI.HostIndex" when retrieved via a link) or (2) in the link
type (Section 4.3.1), generic-metadata-type (Section 4.1.7), or
auth-type (Section 4.2.7) properties in the JSON payload. The CDNI
Payload Type uniquely identifies the specification defining that
object, including any relation to, conflicts with, or obsolescence of
other metadata. There is no explicit version mapping requirement;
however, for ease of understanding, metadata creators SHOULD make new
versions of metadata easily visible via the CDNI Payload Type, e.g.,
by appending a version string. Note: A version string is optional on
the first version (e.g., MI.HostIndex) but could be added for
subsequent versions (MI.HostIndex.v2, MI.HostIndex.v3, etc.).
The version of CDNI Metadata objects is conveyed inside the CDNI
Payload Type that is included in either (1) the HTTP Content-Type
header (for example, "Content-Type: application/cdni;
ptype=MI.HostIndex" when retrieved via a link) or (2) in the link
type (Section 4.3.1), generic-metadata-type (Section 4.1.7), or
auth-type (Section 4.2.7) properties in the JSON payload. The CDNI
Payload Type uniquely identifies the specification defining that
object, including any relation to, conflicts with, or obsolescence of
other metadata. There is no explicit version mapping requirement;
however, for ease of understanding, metadata creators SHOULD make new
versions of metadata easily visible via the CDNI Payload Type, e.g.,
by appending a version string. Note: A version string is optional on
the first version (e.g., MI.HostIndex) but could be added for
subsequent versions (MI.HostIndex.v2, MI.HostIndex.v3, etc.).
Except when referenced by a Link object, nested metadata objects (i.e., structural metadata below the HostIndex; and Source, LocationRule, TimeWindowRule, ProtocolRule, Footprint, and TimeWindow objects) can be serialized into a JSON payload without explicit CDNI Payload Type information. The type is inferred from the outer structural metadata, GenericMetadata, or Auth object CDNI Payload Type. To avoid ambiguity when revising nestable metadata objects, any outer metadata object(s) MUST be reversioned and allocated new CDNI Payload Type(s) at the same time. For example, the MI.HostIndex object defined in this document contains an array of MI.HostMatch objects, each of which in turn contains a MI.HostMetadata object. If a new MI.HostMetadata.v2 object were required, the outer MI.HostIndex and MI.HostMatch objects would need to be revised, e.g., to
除非由链接对象引用，否则嵌套元数据对象（即HostIndex下的结构元数据；以及Source、LocationRule、TimeWindowRule、ProtocolRule、Footprint和TimeWindow对象）可以序列化为JSON负载，而无需显式CDNI负载类型信息。该类型是从外部结构元数据、GenericMetadata或身份验证对象CDNI有效负载类型推断出来的。为了避免在修改可嵌套元数据对象时出现歧义，必须同时反转任何外部元数据对象并分配新的CDNI有效负载类型。例如，本文档中定义的MI.HostIndex对象包含一个MI.HostMatch对象数组，每个对象又包含一个MI.HostMetadata对象。如果需要新的MI.HostMetadata.v2对象，则需要修改外部MI.HostIndex和MI.HostMatch对象，例如
MI.HostIndex.v2 and MI.HostMatch.v2, respectively. Similarly, if a new MI.TimeWindowRule.v2 object were required, the outer MI.TimeWindowACL object would need to be revised, e.g., to MI.TimeWindowACL.v2; however, the MI.TimeWindowRule.v2 object could still contain MI.TimeWindow objects, if so specified.
分别为MI.HostIndex.v2和MI.HostMatch.v2。类似地，如果需要新的MI.TimeWindowRule.v2对象，则需要将外部MI.TimeWindowACL对象修改为MI.TimeWindowACL.v2；但是，如果指定，MI.TimeWindowRule.v2对象仍然可以包含MI.TimeWindow对象。
HTTP requests sent to a metadata server SHOULD include an Accept header with the CDNI Payload Type of the expected object. Metadata clients can specify multiple CDNI Payload Types in the Accept header; for example, if a metadata client is capable of processing two different versions of the same type of object (defined by different CDNI Payload Types), it might decide to include both in the Accept header.
发送到元数据服务器的HTTP请求应该包括一个带有预期对象的CDNI有效负载类型的Accept头。元数据客户端可以在Accept头中指定多个CDNI负载类型；例如，如果元数据客户端能够处理同一类型对象（由不同的CDNI有效负载类型定义）的两个不同版本，那么它可能会决定将这两个版本都包含在Accept标头中。
All CDNI Metadata objects use the media type "application/cdni". The CDNI Payload Type for each object then contains the object name of that object as defined by this document, prefixed with "MI.". Table 4 lists the CDNI Payload Types for the metadata objects (resources) specified in this document.
所有CDNI元数据对象都使用媒体类型“application/CDNI”。然后，每个对象的CDNI有效负载类型包含该对象的对象名，该对象名由本文档定义，前缀为“MI”。表4列出了本文档中指定的元数据对象（资源）的CDNI有效负载类型。
+-----------------------+--------------------------+
| Data Object | CDNI Payload Type |
+-----------------------+--------------------------+
| HostIndex | MI.HostIndex |
| HostMatch | MI.HostMatch |
| HostMetadata | MI.HostMetadata |
| PathMatch | MI.PathMatch |
| PatternMatch | MI.PatternMatch |
| PathMetadata | MI.PathMetadata |
| SourceMetadata | MI.SourceMetadata |
| Source | MI.Source |
| LocationACL | MI.LocationACL |
| LocationRule | MI.LocationRule |
| Footprint | MI.Footprint |
| TimeWindowACL | MI.TimeWindowACL |
| TimeWindowRule | MI.TimeWindowRule |
| TimeWindow | MI.TimeWindow |
| ProtocolACL | MI.ProtocolACL |
| ProtocolRule | MI.ProtocolRule |
| DeliveryAuthorization | MI.DeliveryAuthorization |
| Cache | MI.Cache |
| Auth | MI.Auth |
| Grouping | MI.Grouping |
+-----------------------+--------------------------+
+-----------------------+--------------------------+
| Data Object | CDNI Payload Type |
+-----------------------+--------------------------+
| HostIndex | MI.HostIndex |
| HostMatch | MI.HostMatch |
| HostMetadata | MI.HostMetadata |
| PathMatch | MI.PathMatch |
| PatternMatch | MI.PatternMatch |
| PathMetadata | MI.PathMetadata |
| SourceMetadata | MI.SourceMetadata |
| Source | MI.Source |
| LocationACL | MI.LocationACL |
| LocationRule | MI.LocationRule |
| Footprint | MI.Footprint |
| TimeWindowACL | MI.TimeWindowACL |
| TimeWindowRule | MI.TimeWindowRule |
| TimeWindow | MI.TimeWindow |
| ProtocolACL | MI.ProtocolACL |
| ProtocolRule | MI.ProtocolRule |
| DeliveryAuthorization | MI.DeliveryAuthorization |
| Cache | MI.Cache |
| Auth | MI.Auth |
| Grouping | MI.Grouping |
+-----------------------+--------------------------+
Table 4: CDNI Payload Types for CDNI Metadata Objects
表4:CDNI元数据对象的CDNI有效负载类型
A dCDN requests the HostIndex and receives the following object with a CDNI Payload Type of "MI.HostIndex":
dCDN请求HostIndex并接收CDNI有效负载类型为“MI.HostIndex”的以下对象：
{
"hosts": [
{
"host": "video.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host1234"
}
},
{
"host": "images.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host5678"
}
}
]
}
{
"hosts": [
{
"host": "video.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host1234"
}
},
{
"host": "images.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host5678"
}
}
]
}
If the incoming request has a Host header with "video.example.com", then the dCDN would fetch the HostMetadata object from "https://metadata.ucdn.example/host1234" expecting a CDNI Payload Type of "MI.HostMetadata":
如果传入的请求有一个带有“video.example.com”的主机头，那么dCDN将从https://metadata.ucdn.example/host1234应为CDNI有效负载类型“MI.HostMetadata”：
{
"metadata": [
{
"generic-metadata-type": "MI.SourceMetadata",
"generic-metadata-value": {
"sources": [
{
"endpoint": ["acq1.ucdn.example"],
"protocol": "http/1.1"
},
{
"endpoint": ["acq2.ucdn.example"],
"protocol": "http/1.1"
}
]
}
},
{
"metadata": [
{
"generic-metadata-type": "MI.SourceMetadata",
"generic-metadata-value": {
"sources": [
{
"endpoint": ["acq1.ucdn.example"],
"protocol": "http/1.1"
},
{
"endpoint": ["acq2.ucdn.example"],
"protocol": "http/1.1"
}
]
}
},
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value": {
"locations": [
{
"footprints": [
{
"footprint-type": "ipv4cidr",
"footprint-value": ["192.0.2.0/24"]
},
{
"footprint-type": "ipv6cidr",
"footprint-value": ["2001:db8::/32"]
},
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
},
{
"footprint-type": "asn",
"footprint-value": ["as64496"]
}
],
"action": "deny"
}
]
}
},
{
"generic-metadata-type": "MI.ProtocolACL",
"generic-metadata-value": {
"protocol-acl": [
{
"protocols": [
"http/1.1"
],
"action": "allow"
}
]
}
}
],
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value": {
"locations": [
{
"footprints": [
{
"footprint-type": "ipv4cidr",
"footprint-value": ["192.0.2.0/24"]
},
{
"footprint-type": "ipv6cidr",
"footprint-value": ["2001:db8::/32"]
},
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
},
{
"footprint-type": "asn",
"footprint-value": ["as64496"]
}
],
"action": "deny"
}
]
}
},
{
"generic-metadata-type": "MI.ProtocolACL",
"generic-metadata-value": {
"protocol-acl": [
{
"protocols": [
"http/1.1"
],
"action": "allow"
}
]
}
}
],
"paths": [
{
"path-pattern": {
"pattern": "/videos/trailers/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathABC"
}
},
{
"path-pattern": {
"pattern": "/videos/movies/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathDEF"
}
}
]
}
"paths": [
{
"path-pattern": {
"pattern": "/videos/trailers/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathABC"
}
},
{
"path-pattern": {
"pattern": "/videos/movies/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathDEF"
}
}
]
}
Suppose that the path of the requested resource matches the "/videos/movies/*" pattern; the next metadata requested would be for "https://metadata.ucdn.example/host1234/pathDEF" with an expected CDNI Payload Type of "MI.PathMetadata":
假设请求资源的路径与“/videos/movies/*”模式匹配；请求的下一个元数据将用于“https://metadata.ucdn.example/host1234/pathDEF预期CDNI负载类型为“MI.PathMetadata”：
{
"metadata": [],
"paths": [
{
"path-pattern": {
"pattern": "/videos/movies/hd/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href":
"https://metadata.ucdn.example/host1234/pathDEF/path123"
}
}
]
}
{
"metadata": [],
"paths": [
{
"path-pattern": {
"pattern": "/videos/movies/hd/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href":
"https://metadata.ucdn.example/host1234/pathDEF/path123"
}
}
]
}
Finally, if the path of the requested resource also matches the "/videos/movies/hd/*" pattern, the dCDN would also fetch the following object from "https://metadata.ucdn.example/host1234/pathDEF/path123" with a CDNI Payload Type of "MI.PathMetadata":
最后，如果请求资源的路径也与“/videos/movies/hd/*”模式匹配，则dCDN还将从https://metadata.ucdn.example/host1234/pathDEF/path123CDNI有效负载类型为“MI.PathMetadata”：
{
"metadata": [
{
"generic-metadata-type": "MI.TimeWindowACL",
"generic-metadata-value": {
"times": [
"windows": [
{
"start": "1213948800",
"end": "1478047392"
}
],
"action": "allow"
]
}
}
]
}
{
"metadata": [
{
"generic-metadata-type": "MI.TimeWindowACL",
"generic-metadata-value": {
"times": [
"windows": [
{
"start": "1213948800",
"end": "1478047392"
}
],
"action": "allow"
]
}
}
]
}
The final set of metadata that applies to the requested resource includes a SourceMetadata, a LocationACL, a ProtocolACL, and a TimeWindowACL.
应用于请求的资源的最后一组元数据包括SourceMetadata、LocationACL、ProtocolACL和TimeWindowACL。
This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA:
本文件要求在IANA托管的“CDNI有效负载类型”注册表下注册以下条目：
+--------------------------+---------------+
| Payload Type | Specification |
+--------------------------+---------------+
| MI.HostIndex | RFC 8006 |
| MI.HostMatch | RFC 8006 |
| MI.HostMetadata | RFC 8006 |
| MI.PathMatch | RFC 8006 |
| MI.PatternMatch | RFC 8006 |
| MI.PathMetadata | RFC 8006 |
| MI.SourceMetadata | RFC 8006 |
| MI.Source | RFC 8006 |
| MI.LocationACL | RFC 8006 |
| MI.LocationRule | RFC 8006 |
| MI.Footprint | RFC 8006 |
| MI.TimeWindowACL | RFC 8006 |
| MI.TimeWindowRule | RFC 8006 |
| MI.TimeWindow | RFC 8006 |
| MI.ProtocolACL | RFC 8006 |
| MI.ProtocolRule | RFC 8006 |
| MI.DeliveryAuthorization | RFC 8006 |
| MI.Cache | RFC 8006 |
| MI.Auth | RFC 8006 |
| MI.Grouping | RFC 8006 |
+--------------------------+---------------+
+--------------------------+---------------+
| Payload Type | Specification |
+--------------------------+---------------+
| MI.HostIndex | RFC 8006 |
| MI.HostMatch | RFC 8006 |
| MI.HostMetadata | RFC 8006 |
| MI.PathMatch | RFC 8006 |
| MI.PatternMatch | RFC 8006 |
| MI.PathMetadata | RFC 8006 |
| MI.SourceMetadata | RFC 8006 |
| MI.Source | RFC 8006 |
| MI.LocationACL | RFC 8006 |
| MI.LocationRule | RFC 8006 |
| MI.Footprint | RFC 8006 |
| MI.TimeWindowACL | RFC 8006 |
| MI.TimeWindowRule | RFC 8006 |
| MI.TimeWindow | RFC 8006 |
| MI.ProtocolACL | RFC 8006 |
| MI.ProtocolRule | RFC 8006 |
| MI.DeliveryAuthorization | RFC 8006 |
| MI.Cache | RFC 8006 |
| MI.Auth | RFC 8006 |
| MI.Grouping | RFC 8006 |
+--------------------------+---------------+
Purpose: The purpose of this Payload Type is to distinguish HostIndex MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分HostIndex MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.1.1
编码：见第4.1.1节
Purpose: The purpose of this Payload Type is to distinguish HostMatch MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分HostMatch MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.1.2
编码：见第4.1.2节
Purpose: The purpose of this Payload Type is to distinguish HostMetadata MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分主机元数据MI对象（以及任何关联的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.1.3
编码：见第4.1.3节
Purpose: The purpose of this Payload Type is to distinguish PathMatch MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分PathMatch MI对象（以及任何关联的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.1.4
编码：见第4.1.4节
Purpose: The purpose of this Payload Type is to distinguish PatternMatch MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分PatternMatch MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.1.5
编码：见第4.1.5节
Purpose: The purpose of this Payload Type is to distinguish PathMetadata MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分PathMi对象（以及任何关联的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.1.6
编码：见第4.1.6节
Purpose: The purpose of this Payload Type is to distinguish SourceMetadata MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分SourceMetadata MI对象（以及任何关联的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.1
编码：见第4.2.1节
Purpose: The purpose of this Payload Type is to distinguish Source MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分源MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.1.1
编码：见第4.2.1.1节
Purpose: The purpose of this Payload Type is to distinguish LocationACL MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分LocationACL MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.2
编码：见第4.2.2节
Purpose: The purpose of this Payload Type is to distinguish LocationRule MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分LocationRule MI对象（以及任何关联的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.2.1
编码：见第4.2.2.1节
Purpose: The purpose of this Payload Type is to distinguish Footprint MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分Footprint MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.2.2
编码：见第4.2.2.2节
Purpose: The purpose of this Payload Type is to distinguish TimeWindowACL MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分TimeWindowACL MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.3
编码：见第4.2.3节
Purpose: The purpose of this Payload Type is to distinguish TimeWindowRule MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分TimeWindowRule MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.3.1
编码：见第4.2.3.1节
Purpose: The purpose of this Payload Type is to distinguish TimeWindow MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分TimeWindow MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.3.2
编码：见第4.2.3.2节
Purpose: The purpose of this Payload Type is to distinguish ProtocolACL MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分ProtocolACL MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.4
编码：见第4.2.4节
Purpose: The purpose of this Payload Type is to distinguish ProtocolRule MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分ProtocolRule MI对象（以及任何关联的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.4.1
编码：见第4.2.4.1节
Purpose: The purpose of this Payload Type is to distinguish DeliveryAuthorization MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分DeliveryAuthorization MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.5
编码：见第4.2.5节
Purpose: The purpose of this Payload Type is to distinguish Cache MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分缓存MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.6
编码：见第4.2.6节
Purpose: The purpose of this Payload Type is to distinguish Auth MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分身份验证MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.7
编码：见第4.2.7节
Purpose: The purpose of this Payload Type is to distinguish Grouping MI objects (and any associated capability advertisement)
目的：此有效负载类型的目的是区分分组MI对象（以及任何相关的功能公告）
Interface: MI/FCI
接口：MI/FCI
Encoding: see Section 4.2.8
编码：见第4.2.8节
IANA has created a new "CDNI Metadata Footprint Types" subregistry in the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI Metadata Footprint Types" namespace defines the valid Footprint object type values used by the Footprint object described in Section 4.2.2.2. Additions to the "CDNI Metadata Footprint Types" namespace conform to the Specification Required policy as defined in [RFC5226]. The Designated Expert will verify that new type definitions do not duplicate existing type definitions
IANA在“内容交付网络互连（CDNI）参数”注册表中创建了一个新的“CDNI元数据封装类型”子区。“CDNI元数据封装外形类型”命名空间定义了第4.2.2.2节中描述的封装外形对象使用的有效封装外形对象类型值。“CDNI元数据封装外形类型”命名空间的添加符合[RFC5226]中定义的规范要求策略。指定的专家将验证新的类型定义不会与现有类型定义重复
and prevent gratuitous additions to the namespace. New registrations are required to provide a clear description of how to interpret new footprint types.
并防止对命名空间进行不必要的添加。需要进行新的注册，以明确说明如何解释新的封装外形类型。
The following table defines the initial values for the "CDNI Metadata Footprint Types" registry:
下表定义了“CDNI元数据封装外形类型”注册表的初始值：
+----------------+--------------------------------+---------------+
| Footprint Type | Description | Specification |
+----------------+--------------------------------+---------------+
| ipv4cidr | IPv4 CIDR address block | RFC 8006 |
| ipv6cidr | IPv6 CIDR address block | RFC 8006 |
| asn | Autonomous System Number (ASN) | RFC 8006 |
| countrycode | ISO 3166-1 alpha-2 code | RFC 8006 |
+----------------+--------------------------------+---------------+
+----------------+--------------------------------+---------------+
| Footprint Type | Description | Specification |
+----------------+--------------------------------+---------------+
| ipv4cidr | IPv4 CIDR address block | RFC 8006 |
| ipv6cidr | IPv6 CIDR address block | RFC 8006 |
| asn | Autonomous System Number (ASN) | RFC 8006 |
| countrycode | ISO 3166-1 alpha-2 code | RFC 8006 |
+----------------+--------------------------------+---------------+
IANA has created a new "CDNI Metadata Protocol Types" subregistry in the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI Metadata Protocol Types" namespace defines the valid Protocol object values (Section 4.3.2) used by the SourceMetadata and ProtocolACL objects. Additions to the Protocol namespace conform to the Specification Required policy as defined in [RFC5226], where the specification defines the Protocol Type and the protocol to which it is associated. The Designated Expert will verify that new protocol definitions do not duplicate existing protocol definitions and prevent gratuitous additions to the namespace.
IANA在“内容交付网络互连（CDNI）参数”注册表中创建了一个新的“CDNI元数据协议类型”子区。“CDNI元数据协议类型”命名空间定义SourceMetadata和ProtocolACL对象使用的有效协议对象值（第4.3.2节）。对协议名称空间的添加符合[RFC5226]中定义的规范要求策略，其中规范定义了协议类型及其关联的协议。指定专家将验证新协议定义是否与现有协议定义不重复，并防止对命名空间进行无端添加。
The following table defines the initial Protocol values corresponding to the HTTP and HTTPS protocols:
下表定义了与HTTP和HTTPS协议相对应的初始协议值：
+-----------+----------------------+---------------+----------------+
| Protocol | Description | Type | Protocol |
| Type | | Specification | Specifications |
+-----------+----------------------+---------------+----------------+
| http/1.1 | Hypertext Transfer | RFC 8006 | RFC 7230 |
| | Protocol -- HTTP/1.1 | | |
| | | | |
| https/1.1 | HTTP/1.1 over TLS | RFC 8006 | RFC 7230, |
| | | | RFC 2818 |
+-----------+----------------------+---------------+----------------+
+-----------+----------------------+---------------+----------------+
| Protocol | Description | Type | Protocol |
| Type | | Specification | Specifications |
+-----------+----------------------+---------------+----------------+
| http/1.1 | Hypertext Transfer | RFC 8006 | RFC 7230 |
| | Protocol -- HTTP/1.1 | | |
| | | | |
| https/1.1 | HTTP/1.1 over TLS | RFC 8006 | RFC 7230, |
| | | | RFC 2818 |
+-----------+----------------------+---------------+----------------+
A malicious metadata server, proxy server, or attacker impersonating an authentic uCDN CDNI Metadata interface without being detected could provide false metadata to a dCDN that either:
恶意元数据服务器、代理服务器或攻击者在未被检测到的情况下模拟真实的uCDN CDNI元数据接口，可能会向dCDN提供虚假元数据：
o Denies service for one or more pieces of content to one or more User Agents;
o 拒绝向一个或多个用户代理提供一个或多个内容的服务；
o Directs dCDNs to contact malicious origin servers instead of the actual origin servers, so that malware or slanderous alternate content may be substituted for legitimate content; or
o 指示dCDNs联系恶意源服务器，而不是实际的源服务器，以便用恶意软件或诽谤性替代内容替换合法内容；或
o Removes delivery restrictions (e.g., LocationACL, TimeWindowACL, ProtocolACL, or Auth metadata), allowing access to content that would otherwise be denied and thus possibly violating license restrictions and incurring unwarranted delivery costs.
o 删除传递限制（例如LocationACL、TimeWindowACL、ProtocolACL或Auth元数据），允许访问否则将被拒绝的内容，从而可能违反许可证限制并产生不必要的传递成本。
Unauthorized access to metadata could also enable a malicious metadata client to continuously issue metadata requests in order to overload a uCDN's metadata server or servers.
未经授权的元数据访问还可能使恶意元数据客户端不断发出元数据请求，以使uCDN的元数据服务器过载。
Unauthorized access to metadata could further result in leakage of private information. A malicious metadata client could request metadata in order to gain access to origin servers, as well as information pertaining to content restrictions.
未经授权访问元数据可能进一步导致私人信息泄露。恶意元数据客户端可以请求元数据以访问源服务器以及与内容限制相关的信息。
An implementation of the CDNI Metadata interface MUST use mutual authentication and message authentication codes to prevent unauthorized access to, and undetected modification of, metadata (see Section 8.3).
CDNI元数据接口的实现必须使用相互身份验证和消息身份验证代码，以防止未经授权的元数据访问和未被检测到的元数据修改（见第8.3节）。
Unauthorized viewing of metadata could result in leakage of private information. Content provider origin and policy information is conveyed through the CDNI Metadata interface. A third party could intercept metadata transactions in order to gain access to origin servers, as well as information pertaining to content restrictions and usage patterns.
未经授权查看元数据可能导致私人信息泄漏。内容提供商来源和策略信息通过CDNI元数据接口传递。第三方可以拦截元数据事务，以便访问源服务器以及与内容限制和使用模式有关的信息。
Note: The distribution of metadata by a uCDN to dCDNs could introduce privacy concerns for some content providers, e.g., dCDNs accepting content requests for a content provider's content might be able to obtain additional information and usage patterns relating to the users of a content provider's services. Content providers with concerns about divulging information to dCDNs can instruct their uCDN partners not to use CDNI when delivering their content.
注意：uCDN向DCDN分发元数据可能会引起某些内容提供商的隐私问题，例如，接受内容提供商内容的内容请求的DCDN可能能够获得与内容提供商服务用户相关的附加信息和使用模式。担心向dCDNs泄露信息的内容提供商可以指示其uCDN合作伙伴在交付内容时不要使用CDNI。
An implementation of the CDNI Metadata interface MUST use strong encryption to prevent unauthorized interception or monitoring of metadata (see Section 8.3).
CDNI元数据接口的实现必须使用强加密，以防止未经授权的元数据拦截或监控（见第8.3节）。
An implementation of the CDNI Metadata interface MUST support TLS transport as per [RFC2818] and [RFC7230].
根据[RFC2818]和[RFC7230]，CDNI元数据接口的实现必须支持TLS传输。
TLS MUST be used by the server side (uCDN) and the client side (dCDN) of the CDNI Metadata interface, including authentication of the remote end, unless alternate methods are used for ensuring the security of the information in the CDNI Metadata interface requests and responses (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity).
TLS必须由CDNI元数据接口的服务器端（uCDN）和客户端（dCDN）使用，包括远程端的身份验证，除非使用替代方法确保CDNI元数据接口请求和响应中信息的安全性（例如，在两个CDN之间设置IPsec隧道，或者在同一公司实体拥有的两个CDN之间使用物理安全的内部网络）。
The use of TLS for transport of the CDNI Metadata interface messages allows the dCDN and uCDN to authenticate each other.
使用TLS传输CDNI元数据接口消息允许dCDN和uCDN相互验证。
Once the dCDN and uCDN have mutually authenticated each other, TLS allows:
一旦dCDN和uCDN相互验证，TLS允许：
o The dCDN and uCDN to authorize each other (to ensure that they are transmitting/receiving CDNI Metadata requests and responses from an authorized CDN);
o dCDN和uCDN相互授权（以确保它们正在发送/接收来自授权CDN的CDNI元数据请求和响应）；
o CDNI Metadata interface requests and responses to be transmitted with confidentiality; and
o CDNI元数据接口请求和响应应保密传输；和
o The integrity of the CDNI Metadata interface requests and responses to be protected during the exchange.
o 在交换期间要保护的CDNI元数据接口请求和响应的完整性。
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be followed.
使用TLS时，必须遵守[RFC7525]中的一般TLS使用指南。
[ISO3166-1] The International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1:2013, 2013.
[ISO3166-1]国际标准化组织，“国家及其分支机构名称表示代码——第1部分：国家代码”，ISO 3166-1:2013，2013。
[POSIX] Institute of Electrical and Electronics Engineers, "Information Technology Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) [C Language]", IEEE P1003.1, 1990.
[POSIX]电气和电子工程师协会，“信息技术便携式操作系统接口（POSIX）第1部分：系统应用程序接口（API）[C语言]”，IEEE P1003.119990。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<http://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://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月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<http://www.rfc-editor.org/info/rfc5891>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 6707，DOI 10.17487/RFC6707，2012年9月<http://www.rfc-editor.org/info/rfc6707>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <http://www.rfc-editor.org/info/rfc7493>.
[RFC7493]Bray，T.，Ed.，“I-JSON消息格式”，RFC 7493，DOI 10.17487/RFC7493，2015年3月<http://www.rfc-editor.org/info/rfc7493>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7525>.
[CDNI-URI-SIGNING] van Brandenburg, R., Leung, K., Sorber, P., and M. Miller, "URI Signing for CDN Interconnection (CDNI)", Work in Progress, draft-ietf-cdni-uri-signing-10, October 2016.
[CDNI-URI-SIGNING]van Brandenburg，R.，Leung，K.，Sorber，P.，和M.Miller，“CDN互连（CDNI）的URI签名”，正在进行的工作，草案-ietf-CDNI-URI-SIGNING-10，2016年10月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC6793]Vohra，Q.和E.Chen，“BGP对四个八位组自治系统（AS）数字空间的支持”，RFC 6793，DOI 10.17487/RFC6793，2012年12月<http://www.rfc-editor.org/info/rfc6793>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7336]Peterson，L.，Davie，B.，和R.van Brandenburg，编辑，“内容分发网络互连框架（CDNI）”，RFC 7336，DOI 10.17487/RFC7336，2014年8月<http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[RFC7337]Leung，K.，Ed.，和Y.Lee，Ed.“内容分发网络互连（CDNI）要求”，RFC 7337，DOI 10.17487/RFC7337，2014年8月<http://www.rfc-editor.org/info/rfc7337>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>.
[RFC7736]马，K，“内容交付网络互连（CDNI）媒体类型注册”，RFC 7736，DOI 10.17487/RFC7736，2015年12月<http://www.rfc-editor.org/info/rfc7736>.
[RFC7975] Niven-Jenkins, B., Ed., and R. van Brandenburg, Ed., "Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection", RFC 7975, DOI 10.17487/RFC7975, October 2016, <http://www.rfc-editor.org/info/rfc7975>.
[RFC7975]Niven Jenkins，B.，Ed.，和R.van Brandenburg，Ed.，“内容交付网络（CDN）互连的请求路由重定向接口”，RFC 7975，DOI 10.17487/RFC7975，2016年10月<http://www.rfc-editor.org/info/rfc7975>.
[RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers", RFC 8007, DOI 10.17487/RFC8007, December 2016, <http://www.rfc-editor.org/info/rfc8007>.
[RFC8007]Murray，R.和B.Niven Jenkins，“内容交付网络互连（CDNI）控制接口/触发器”，RFC 8007，DOI 10.17487/RFC8007，2016年12月<http://www.rfc-editor.org/info/rfc8007>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, R., and K. Ma, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, <http://www.rfc-editor.org/info/rfc8008>.
[RFC8008]Seedorf，J.，Peterson，J.，Previdi，S.，van Brandenburg，R.，和K.Ma，“内容交付网络互连（CDNI）请求路由：足迹和能力语义”，RFC 8008，DOI 10.17487/RFC8008，2016年12月<http://www.rfc-editor.org/info/rfc8008>.
Acknowledgments
致谢
The authors would like to thank David Ferguson, Francois Le Faucheur, Jan Seedorf, and Matt Miller for their valuable comments and input to this document.
作者要感谢David Ferguson、Francois Le Faucheur、Jan Seedorf和Matt Miller对本文件的宝贵意见和投入。
Contributors
贡献者
The authors would also like to thank Grant Watson and Kent Leung for their contributions to this document.
作者还要感谢Grant Watson和Kent Leung对本文件的贡献。
Authors' Addresses
作者地址
Ben Niven-Jenkins Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
英国剑桥市弥尔顿伊利路3号Ben Niven Jenkins诺基亚CB24 6DD
Email: ben.niven-jenkins@nokia.com
Email: ben.niven-jenkins@nokia.com
Rob Murray Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
Rob Murray Nokia 3 Ely Road Milton，剑桥CB24 6DD英国
Email: rob.murray@nokia.com
Email: rob.murray@nokia.com
Matt Caulfield Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 United States of America
Matt Caulfield Cisco Systems美国马萨诸塞州伯斯堡马萨诸塞大道1414号01719
Phone: +1-978-936-9307
Email: mcaulfie@cisco.com
Phone: +1-978-936-9307
Email: mcaulfie@cisco.com
Kevin J. Ma Ericsson 43 Nagog Park Acton, MA 01720 United States of America
Kevin J.Ma Ericsson 43美国马萨诸塞州纳戈公园阿克顿01720
Phone: +1 978-844-5100
Email: kevin.j.ma@ericsson.com
Phone: +1 978-844-5100
Email: kevin.j.ma@ericsson.com