[要約] RFC 8006は、CDN間のメタデータの相互接続に関する標準化されたプロトコルを提案しています。その目的は、異なるCDN間でのメタデータの共有と相互運用性を向上させることです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
CDNIメタデータインターフェイス（MI）は、[RFC7336]で説明されており、CDNIソリューションを構成するために使用できる他の4つのインターフェイス（CDNI制御インターフェイス、CDNI要求ルーティングリダイレクションインターフェイス、CDNIフットプリントおよび機能アドバタイズメントインターフェイス（FCI）） 、およびCDNI Loggingインターフェース）。 [RFC7336]は、各インターフェースとそれらの間の関係について説明しています。 CDNIメタデータインターフェイスの要件は、[RFC7337]で指定されています。
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.
コンテンツ（またはコンテンツのセット）に関連付けられたCDNIメタデータは、uCDNによって定義されたポリシーに従って、uCDNに代わってコンテンツ要求を処理するための十分な情報をdCDNに提供します。
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:
このドキュメントでは、dCDNが適切に処理して応答できるように、dCDNがuCDNからCDNIメタデータを取得できるようにするCDNIメタデータインターフェイスを定義します。
o Redirection requests received over the CDNI Request Routing Redirection interface [RFC7975].
o CDNI Request Routing Redirectionインターフェイス[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".
このドキュメントでは、厳密に正確な語句が「[オブジェクト] Aを含むまたは参照（リンクオブジェクトを介して）[オブジェクト] B」である場合に、単純にするために「[オブジェクト] Aは[オブジェクト] 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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].
このドキュメントでは、初期機能の小さなセットのメタデータのみを指定しています。このセットは、[RFC7337]で規定された要件を満たしながら、基本的なCDN相互運用性のための最小限のメタデータを提供します。
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 キャッシュ制御：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].
このドキュメントで指定されているメタデータのセットは、上記の初期機能をカバーしています。 HTTP / 1.1 [RFC7230]を使用したdCDNによるコンテンツの配信と、CD / Nがトランスポート層セキュリティ（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).
暗号化されていないHTTP / 2 [RFC7540]を使用してコンテンツを配信するためのCDNIをサポートするには（暗号化されていないHTTP / 2またはTLS経由のHTTP / 2を使用してdCDNがコンテンツを取得するため）、これらのプロトコル名を "CDNI Metadata Protocol"に登録する必要があります。タイプ」レジストリ（セクション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]で規定されているガイドラインに従う必要があります（SHOULD）。 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（インターネット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.
dCDNサロゲートまたはリクエストルーターがそのホスト名とURIパスのコンテンツに対するユーザーエージェントリクエストを処理しているときに必要な動作を説明するために、さまざまなホスト名とURIパスがCDNIメタデータプロパティのさまざまなセットに関連付けられます。この構造の結果として、さまざまなホスト名に指定されたCDNIメタデータプロパティ、ホスト名内のさまざまなURIパス、およびさまざまなホスト名のさまざまなURIパスの間に重要な共通性が存在する可能性があります。たとえば、どのユーザーエージェントIPアドレスを1つのネットワークまたは地理的な場所にグループ化するかの定義は、多くの異なるホスト名に共通する可能性があります。 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メタデータを個別のオブジェクトに分割します。複数のホスト名やURIパスのCDNIメタデータによって参照されている場合でも、単一のCDNIメタデータオブジェクト（ホスト名やURIパスで共有されている）をdCDNで一度に取得して保存できるようにすることで、効率が向上します。
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には、オブジェクトA内にオブジェクトBを埋め込む代わりに、オブジェクトBを取得するために使用できるURIを指定するリンクオブジェクトを含めることができます。このドキュメントの残りの部分では、「 [オブジェクト] Aは、厳密に正確なフレーズが「[オブジェクト] Aが含むか、または（リンクオブジェクトを介して）[オブジェクト] Bを参照する」の場合の単純化のために[オブジェクト] Bを含みます。通常、CDNIメタデータオブジェクトを埋め込むタイミングとリンクオブジェクトを介して個別のリソースを参照するタイミングを決定するのは、uCDN実装の展開の選択です。
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 GenericMetadataオブジェクト内に含めることができる、このドキュメントで指定されている特定のCDNIメタデータオブジェクトとプロパティについて詳しく説明します。
3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch, and PathMetadata Objects
3.1. HostIndies、HostMatch、HostMatch、PatchMatch、FifthMatch、OldMatchオブジェクト
The relationships between the HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch, and PathMetadata objects are described in Figure 1.
HostIndex、HostMatch、HostMetadata、PathMatch、PatternMatch、およびPathMetadataオブジェクト間の関係を図1に示します。
+---------+ +---------+ +------------+
|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を参照）には、コンテンツ要求がdCDNに委任される可能性があるホスト名（またはIPアドレス）を含むHostMatchオブジェクト（セクション4.1.2を参照）の配列が含まれます。 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を参照）を介して、各ホストのデフォルトのメタデータプロパティとPathMetadataオブジェクト（セクション4.1.6を参照）を記述するHostMetadataを見つけることができます。 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オブジェクトには、関連付けられたHostMetadataオブジェクトのURIを含む「example.com」のエントリを含めることができます。 「example.com」のHostMetadataオブジェクトは、「example.com」に適用されるメタデータプロパティを記述し、「example.com/movies/*」と「example.com/music/*」のPathMatchesを含むことができます。より具体的なURIパスのプロパティを含む対応するPathMetadataオブジェクト。 「example.com/movies/*」のPathMetadataオブジェクトは、そのURIパスに適用されるプロパティを記述します。また、「example.com/movies/hd/」パスプレフィックスの対応するPathMetadataオブジェクトを参照する「example.com/movies/hd/*」のPathMatchオブジェクトを含めることもできます。
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. |
+--------------+----------------------------------------------------+
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 Metadataオブジェクトが含まれています。たとえば、コンテンツの取得先、適用する承認ルール、ジオブロッキング制限などです。オン。このような各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がenforcement-to-enforceプロパティを理解またはサポートしない場合、dCDNはコンテンツを提供してはなりません（MUST NOT）。プロパティが強制する必要がない場合、その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に設定する必要があります。 「理解不能」フラグは、メタデータがtCDNによって適切に変換されなかったことをdCDNに通知します。 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.
tCDNは、メタデータをdCDNに伝播するときに、強制する必要がある値または再配布する安全な値を変更してはなりません（MUST NOT）。 tCDNは「incomprehensible」の値をtrueに設定できますが、tCDNは「incomprehensible」の値をtrueからfalseに変更してはなりません（MUST NOT）。
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がメタデータを理解しているか理解していない場合に、強制強制（「MtE」）プロパティと再配布安全（「StR」）プロパティのさまざまな組み合わせに対してtCDNが実行するアクションを示しています質問：
+-------+-------+------------+--------------------------------------+
| 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：MtEおよびStRプロパティのさまざまな組み合わせに対してtCDNが実行するアクション
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が問題のメタデータを理解するか理解しない場合に、強制する必要のあるプロパティと「理解できない」（Incomp）プロパティのさまざまな組み合わせに対して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. |
+-------+--------+--------------+-----------------------------------+
Table 3: Action to Be Taken by a dCDN for the Different Combinations of MtE and Incomp Properties
表3：MtEとIncompプロパティのさまざまな組み合わせに対してdCDNが実行するアクション
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オブジェクトに（PathMatchオブジェクトを介して）複数のPathMetadataオブジェクトを含めることができます。各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 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:
特定のタイプのGenericMetadataオブジェクトは、ツリー内の親オブジェクトによって以前に定義された同じタイプのすべてのGenericMetadataオブジェクトをオーバーライドします。同じタイプのオブジェクトが子オブジェクトによって定義されていない場合、ツリー内の親オブジェクトによって以前に定義された特定のタイプのGenericMetadataオブジェクトが継承されます。たとえば、ホスト「example.com」のHostMetadataにタイプLocationACLおよびTimeWindowACL（「ACL」は「アクセス制御リスト」を意味する）のGenericMetadataオブジェクトが含まれているが、「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は、「example.com/movies/」の下のコンテンツに対するすべてのユーザーエージェントリクエストについて、HostMetadataで定義された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を含むLinkオブジェクトのいずれかにすることができます。オブジェクト。
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 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.
dCDNおよびtCDNは、このドキュメントで指定されているすべてのCDNIメタデータオブジェクトの解析をサポートする必要があります。 dCDNは、非構造的なGenericMetadataオブジェクトによって表される基本的な機能を実装する必要はありません（特定のdCDNが提供できるコンテンツを制限する可能性があります）。 CDNIメタデータのジェネレーターとしてのuCDNは、記述しているコンテンツに必要なポリシーを表現するために必要なCDNIメタデータの生成をサポートする必要があるだけです。 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.
注：以下のセクションでは、「指定が必須」という用語は、特定の構造オブジェクトまたはGenericMetadataオブジェクトにどのプロパティを含める必要があるかを示すために使用されます。個別プロパティに対して指定必須が「はい」と指定されている場合、そのプロパティを含むオブジェクトがメタデータ応答に含まれている場合、指定必須プロパティも（直接または参照により）含める必要があります。 ）レスポンス内。たとえば、照合するホストがないHostMatchプロパティオブジェクトは意味がありません。したがって、「ホスト」プロパティは、HostMatchオブジェクト内で指定する必要があります。
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オブジェクト）は出現順に評価する必要があり、処理されるコンテンツ要求に一致する最初のHostMatchオブジェクトを使用する必要があります。
Type: Array of HostMatch objects
タイプ：HostMatchオブジェクトの配列
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:
2つのHostMatchオブジェクトを含むHostIndexオブジェクトの例。最初のHostMatchオブジェクトが埋め込まれ、2番目のHostMatchオブジェクトが参照されています。
{
"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アドレスが「host」プロパティのホスト名またはIPアドレスと一致するためには、小文字に変換されたときのコンテンツ要求の値は、変換されたときの「host」プロパティの値と同じでなければなりません。小文字に。すべての実装は、[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
プロパティ：host-metadata
Description: CDNI Metadata to apply when delivering content that matches this host.
説明：このホストに一致するコンテンツを配信するときに適用するCDNIメタデータ。
Type: HostMetadata
タイプ：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>
}
}
Example HostMatch object referencing (via a Link object; see Section 4.3.1) a HostMetadata object:
HostMetadataオブジェクトを参照する（Linkオブジェクトを介して、セクション4.3.1を参照）HostMatchオブジェクトの例：
{
"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 Metadataプロパティと、場合によっては子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:
ホストのデフォルトメタデータを記述する多数の埋め込みGenericMetadataオブジェクトを含むHostMetadataオブジェクトの例と、ホストのデフォルトメタデータをオーバーライドするメタデータが存在するパスを含む埋め込みPathMatchオブジェクト：
{
"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>
}
]
}
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オブジェクトには、リソースのURIパスと照合するパスを含むPatternMatchオブジェクトと、URIクエリパラメータの処理方法が含まれています。 PathMatchオブジェクトには、リソースのURIがPatternMatchオブジェクト内のパターンと一致する場合に適用するGenericMetadataを含むPathMetadataオブジェクトも含まれています。
Property: path-pattern
プロパティ：パスパターン
Description: Pattern to match against the requested resource's URI.
説明：要求されたリソースのURIと照合するパターン。
Type: 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
タイプ：パスファインダー
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"
}
}
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]または「/」文字（空の文字列を含む）と「？」のシーケンスと一致します。正確に1つのpchar文字に一致します。 3つのリテラル "$"、 "*"、および "？" 「$$」、「$ *」、および「$？」としてエスケープする必要があります。 （「$」は指定されたエスケープ文字です）。他のすべての文字はリテラルとして扱われます。
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
}
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 Metadataプロパティが含まれています。
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レベル以下のメタデータを評価できません。 dCDNは、サポートされていないメタデータが指定されているかどうかを検出するためにリダイレクト要求に応答する前に、ホストのすべてのPathMetadataを処理する必要があります（SHOULD）。 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.
親PathMatchオブジェクトで定義されたURIパスに適用するメタデータと、より具体的なPathMatchオブジェクトを記述する、いくつかの埋め込まれたGenericMetadataオブジェクトを含むPathMetadataオブジェクトの例。
{
"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>
}
]
}
A GenericMetadata object is a wrapper for managing individual CDNI Metadata properties in an opaque manner.
GenericMetadataオブジェクトは、個々のCDNIメタデータプロパティを不透明な方法で管理するためのラッパーです。
Property: generic-metadata-type
プロパティ：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).
Type：generic-metadata-valueプロパティに含まれるオブジェクトの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).
タイプ：形式/タイプは、上記のgeneric-metadata-typeプロパティの値によって定義されます。注：generic-metadata-valuesは、プロパティに「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がこのメタデータオブジェクトを理解できなかったか、正しく変換できなかったかどうかを識別するフラグ。注：このフラグは、redisto-to-redistributeプロパティの値が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):
該当するURIパスまたはホスト、あるいはその両方に適用されるメタデータオブジェクトを含むGenericMetadataオブジェクトの例（それぞれ、親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>
}
}
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オブジェクトのgeneric-metadata-valueフィールドで使用することを意図しており、それらのgeneric-metadata-typeプロパティは、表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:
該当するURIパスまたはホスト、あるいはその両方のコンテンツを取得するためにdCDNが使用する必要があるサーバーを説明するSourceMetadataオブジェクト（2つのSourceオブジェクトを含む）の例：
{
"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.
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).
Sourceオブジェクト内のエンドポイントは、同等/同等として扱わなければなりません（MUST）。 uCDNは、SourceMetadataオブジェクト内で、優先順に並べられたソースの配列を指定できます。次に、優先順位でランク付けされた各Sourceオブジェクトに対して、uCDNは同等のエンドポイントの配列を指定できます（たとえば、ロードバランサーの背後にないサーバーのプール）
Property: acquisition-auth
プロパティ：取得認証
Description: Authentication method to use when requesting content from this source.
説明：このソースからコンテンツを要求するときに使用する認証方法。
Type: Auth (see Section 4.2.7)
タイプ：Auth（セクション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:
該当するホストやURIパスのコンテンツを取得するためにdCDNが使用できるエンドポイント（サーバー）のペアを記述するソースオブジェクトの例：
{
"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 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".
「locations」プロパティを含まないLocationACLは「すべて許可」のアクションを引き起こします。つまり、ユーザーエージェントの場所に関係なく配信を実行できます。そうでない場合、CDNは最初のフットプリントからアクションを実行して、ユーザーエージェントの場所と照合する必要があります。 2つ以上のフットプリントが重複する場合、ユーザーエージェントの場所と一致する最初のフットプリントが、CDNが実行する必要があるアクションを決定します。 「locations」プロパティが含まれているが空の場合、またはリストされたフットプリントのいずれもユーザーエージェントの場所と一致しない場合、結果は「拒否」のアクションになります。
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（「allow」がtrue、「deny」がfalse）の論理ANDを使用して、リクエストを許可するかどうかを決定する必要があります。
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":
{
}
}
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:
{
"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は、Footprintオブジェクトの配列と対応するアクションを含むか参照します。
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
タイプ：小文字の文字列としてエンコードされた列挙[許可|拒否]
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:
dCdnがコンテンツを米国のクライアントに配信できるようにするLocationRuleオブジェクト（Footprintオブジェクトを含む）の例：
{
"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を参照）、および"countrycode"（国コード。セクション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、国コードなど）にすることができます。ただし、他のFootprintオブジェクトは、より複雑なエンコーディング（GPS座標タプルなど）とともに将来的に定義される可能性があります。
Type: Array of footprints
タイプ：フットプリントの配列
Mandatory-to-Specify: Yes.
指定が必須：はい。
Example Footprint object describing a footprint covering the USA:
米国をカバーするフットプリントを記述するフットプリントオブジェクトの例：
{
"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"]
}
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"]
}
Example Footprint object describing a footprint covering the autonomous system 64496:
自律システム64496をカバーするフットプリントを記述するフットプリントオブジェクトの例：
{
"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".
「時間」プロパティを含まないTimeWindowACLは「すべて許可」のアクションを引き起こします。つまり、ユーザーエージェントのリクエストの時間に関係なく配信を実行できます。それ以外の場合、CDNは現在の時間と照合するために最初のウィンドウからアクションを実行する必要があります。 2つ以上のウィンドウが重複している場合、現在の時刻と一致する最初のウィンドウが、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., 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（セクション4.2.2を参照）、TimeWindowACL、およびProtocolACL（セクション4.2.4を参照）は独立したGenericMetadataオブジェクトですが、それらは競合する情報をdCDNに提供できます。たとえば、LocationACLに基づいて同時に許可されるコンテンツ要求とTimeWindowACLに基づいて拒否されました。 dCDNは、すべてのACL（「allow」がtrue、「deny」がfalse）の論理ANDを使用して、リクエストを許可するかどうかを決定する必要があります。
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
}
]
}
]
}
}
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)
タイプ：TimeWindowオブジェクトの配列（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
タイプ：小文字の文字列としてエンコードされた列挙[許可|拒否]
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:
dCDNがクライアントにコンテンツを配信できるのは、TimeWindowRuleオブジェクト（TimeWindowオブジェクトを含む）の例で、09：00 01/01/2000 UTCから17:00 01/01/2000 UTCの間のみです。
{
"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
プロパティ：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 2000/01/01 UTCから17:00 01/01/2000 UTCまでの時間ウィンドウを記述するTimeWindowオブジェクトの例：
{
"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".
protocol-aclプロパティを含まないProtocolACLは「すべて許可」のアクションを引き起こします。つまり、ユーザーエージェントのリクエストのプロトコルに関係なく配信を実行できます。それ以外の場合、CDNは要求プロトコルと照合するために最初のプロトコルからアクションを実行する必要があります。 2つ以上の要求プロトコルが重複する場合、要求プロトコルに一致する最初のプロトコルが、CDNが実行する必要があるアクションを決定します。 protocol-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（「allow」がtrue、「deny」がfalse）の論理ANDを使用して、リクエストを許可するかどうかを決定する必要があります。
Property: protocol-acl
プロパティ：protocol-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:
HTTP / 1.1を使用してdCDNのみがコンテンツを配信できるようにするProtocolACLオブジェクト（ProtocolRuleオブジェクトを含む）の例：
{
"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は、Protocolオブジェクトの配列と対応するアクションを含むか参照します。
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
タイプ：小文字の文字列としてエンコードされた列挙[許可|拒否]
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:
dCDNがHTTP / 1.1を使用してコンテンツを配信できるようにするProtocolRuleオブジェクト（Protocolオブジェクトを含む）の例：
{
"action": "allow",
"protocols": ["http/1.1"]
}
Delivery authorization defines authorization methods for the delivery of content to User Agents.
配信承認は、ユーザーエージェントへのコンテンツ配信の承認方法を定義します。
Property: delivery-auth-methods
プロパティ：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)
タイプ：Authオブジェクトの配列（セクション4.2.7を参照）
Mandatory-to-Specify: No. Default is no authorization required.
指定が必須：いいえ。デフォルトでは許可は不要です。
Example DeliveryAuthorization object (which contains an Auth object):
DeliveryAuthizationオブジェクトの例（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>
}
}
]
}
}
A Cache object describes the cache control parameters to be applied to the content by intermediate caches.
Cacheオブジェクトは、中間キャッシュによってコンテンツに適用されるキャッシュ制御パラメーターを記述します。
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.
キャッシュキーは、コンテンツリクエストのURI [RFC7234]から生成されます。場合によっては、CDNまたはコンテンツプロバイダーは、特定のパスセグメントまたはクエリパラメーターをキャッシュキーの生成から除外したい場合があります。 Cacheオブジェクトは、パスとクエリ文字列のどの部分を含めるかについてのガイダンスを提供します。
Property: exclude-path-pattern
プロパティ：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]または「/」文字（空の文字列を含む）と「？」のシーケンスと一致します。正確に1つのpchar文字に一致します。 3つのリテラル "$"、 "*"、および "？" 「$$」、「$ *」、および「$？」としてエスケープする必要があります。 （「$」は指定されたエスケープ文字です）。他のすべての文字はリテラルとして扱われます。キャッシュキーの生成には、パターンのワイルドカード部分と一致する絶対パスの部分のみを含める必要があります。注：PatternMatchパターン（セクション4.1.5）とexclude-path-patternの間の不整合により、キャッシュが非効率になる可能性があります。
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
プロパティ：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をキャッシュ内のURIと比較して同等かどうかを比較するときに含めるURIクエリ文字列パラメーター[RFC3986]を指定できるようにします。一致するクエリパラメータは、大文字と小文字を区別しないでください。すべてのクエリパラメータを無視する必要がある場合は、リストを指定する必要があり、空にする必要があります。クエリパラメータがクエリ文字列に複数回出現する場合は、各インスタンス値を比較前に集約する必要があります。一貫したキャッシュキー生成のために、クエリパラメータはこの配列で指定された順序で評価されるべきです（SHOULD）。
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:
フルURIパスを使用してすべてのクエリパラメータを無視するようにdCDNに指示するキャッシュオブジェクトの例：
{
"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":
{
"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:
「CDNX」パス接頭辞を除外するようにdCDNに指示するが、すべてのクエリパラメータを含むキャッシュオブジェクトの例：
{
"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.
注：このドキュメントでは、Authメソッドを定義していません。個々のAuthメソッドは個別に定義されています（例：URI署名[CDNI-URI-SIGNING]）。 Authオブジェクトを含むGenericMetadataオブジェクトは、便宜上、ここでは特定のAuthメソッドに固有ではないように定義されています。
Property: auth-type
プロパティ：auth-type
Description: Auth type (The CDNI Payload Type [RFC7736] of the GenericMetadata object contained in the auth-value property).
説明：認証タイプ（auth-valueプロパティーに含まれるGenericMetadataオブジェクトのCDNIペイロードタイプ[RFC7736]）。
Type: String
タイプ：文字列
Mandatory-to-Specify: Yes.
指定が必須：はい。
Property: auth-value
プロパティ：auth-value
Description: An object conforming to the specification associated with the Auth type.
説明：Authタイプに関連付けられた仕様に準拠するオブジェクト。
Type: GenericMetadata object
タイプ：GenericMetadataオブジェクト
Mandatory-to-Specify: Yes.
指定が必須：はい。
Example Auth object:
Authオブジェクトの例：
{
"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.
Groupingオブジェクトは、特定のアセットが属するコンテンツのグループを識別します。
Property: ccid
プロパティ：ccid
Description: Content Collection IDentifier for an application-specific purpose such as logging aggregation.
説明：ログ収集など、アプリケーション固有の目的のためのコンテンツコレクションID。
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:
Groupingオブジェクトの親HostMetadataおよびPathMetadataに関連付けられたコンテンツのコンテンツコレクションIDを指定するGroupingオブジェクトの例：
{
"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.
Linkオブジェクトは、上記のオブジェクトの代わりに使用できます。メタデータツリー内で同じメタデータ情報が繰り返される場合、リンクオブジェクトを使用して重複を回避できます。 Linkオブジェクトが別のオブジェクトを置き換えると、その「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.
dCDNは、オブジェクト内の「href」という名前のプロパティの存在を検出することにより、Linkオブジェクトの存在を検出できます。これは、GenericMetadataタイプに「href」という名前のプロパティが含まれていてはならないことを意味します。これを行うと、GenericMetadataオブジェクトの参照に使用されているLinkオブジェクトをdCDNが検出する機能と競合するためです。
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オブジェクトのリスト内のLinkオブジェクトはHostMatchを参照する必要があります）、明示的に指定する必要はありません。タイプを指定します。
Example Link object referencing a HostMatch object:
Example Link object referencing a HostMatch object:
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
Example Link object referencing a HostMatch object, without an
explicit type, inside a HostIndex object:
{
"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ペイロードタイプが、Linkオブジェクトまたはそれを含むプロパティで示されている予想されるCDNIペイロードタイプと一致することを確認する必要があります。 GenericMetadataオブジェクトの場合、型チェックにより自己参照が防止されます。ただし、正しくリンクしないと、構造メタデータオブジェクト、特にPathMatchオブジェクトとPathMetadataオブジェクトが循環参照される可能性があります（図1）。循環参照を防ぐために、CDNIメタデータクライアントは、PathMatchまたはPathMetadataオブジェクトに重複リンクが発生しないことを確認する必要があります（SHOULD）。
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 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].
すべての実装は、[RFC3986]のセクション3.2.2の「IPv4address」ルールで指定されているようにエンコードされたIPv4アドレスをサポートする必要があります。 IPv6アドレスは、[RFC5952]で指定されているIPv6アドレス形式のいずれかでエンコードする必要がありますが、受信者は[RFC4291]で指定されているすべてのIPv6アドレス形式をサポートする必要があります。ホスト名は、[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"
”１９２。０。２。１”
Example IPv6 address (with port number):
IPv6アドレスの例（ポート番号付き）：
"[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日の0時間、0分、0秒）からの秒数で表された時刻値。協定世界時（UTC）[POSIX]。
Type: Integer
タイプ：整数
Example time representing 09:00:00 01/01/2000 UTC:
2000年1月1日09:00:00 UTCを表す時間の例：
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 Classless Inter-Domain Routing（CIDR）ブロックの後に「/」が続き、その後にルーティングプレフィックスの先頭ビットを表す符号なし整数（つまり、IPv4 CIDR表記）。単一のIPアドレスは/ 32として表すことができます。
Type: String
タイプ：文字列
Example IPv4CIDR:
IPv4CIDRの例：
"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"
An ASN value encoded as a string consisting of the characters "as" (in lowercase) followed by the ASN [RFC6793].
「as」（小文字）の文字とその後に続くASN [RFC6793]で構成される文字列としてエンコードされたASN値。
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 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.
CDNIメタデータは、コンテンツ配信に関する情報をuCDNからdCDNに伝えるために使用されます。オプションのメタデータの場合、コンテンツ要求を特定のdCDNに委任する前に、そのdCDNがメタデータによって記述された基本機能をサポートしているかどうかをuCDNが知っていると便利です。一部のメタデータが強制する必要があり、dCDNがそれをサポートしていない場合、そのメタデータを必要とするコンテンツに対する委任された要求は失敗します。 uCDNは、それらの要求をそのdCDNに委任することを避けたいと思うでしょう。同様に、オプションの値が割り当てられる可能性のあるメタデータの場合、コンテンツ要求を特定のdCDNに委任する前に、uCDNが、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 Advertisementインターフェース（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で使用して、次の2つの方法のいずれかで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が受信した要求を処理するために必要な場合-たとえば、CDNI要求ルーティングリダイレクトインターフェイス（RI）[RFC7975]を介したuCDNからのクエリへの応答、またはユーザーエージェントからのコンテンツの要求の受信への応答。
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制御インターフェース/トリガー」（CI / T）インターフェース[RFC8007]を介して開始される、事前配信のCDNIメタデータ取得の場合。
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）を含めて、返されたリソースのキャッシュバージョンの検証を有効にする必要があります（SHOULD）。
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 Metadataクライアントは、HostMetadataオブジェクト自体を指すLinkオブジェクトの "href"プロパティで指定されたURIに対してHTTP GET要求を発行します。
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 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メタデータクライアントはHostMetadataを検査して、より具体的なPathMetadataオブジェクトへの参照を探します（要求のURIパスを、にリストされているPathMatchオブジェクトのパスパターンプロパティ項目と照合します） HostMetadataオブジェクト）。 PathMetadataオブジェクトが一致することが判明した（埋め込まれているのではなくリンクされている）場合、CDNIメタデータクライアントはPathMetadataに対して別のHTTP GET要求を行います。各PathMetadataオブジェクトには、追加のより具体的なメタデータへの参照を含めることもできます。この場合、CDNIメタデータクライアントはPathMatchおよびPathMetadataオブジェクトを再帰的に要求し続けます。 CDNIメタデータクライアントは、uCDNからのリダイレクト要求またはユーザーエージェントからのコンテンツ要求を処理するために必要なすべてのメタデータオブジェクトが得られるまで、メタデータオブジェクトの処理とリンクされたオブジェクトの取得（HTTP GETを介して）のこのアプローチを繰り返します。
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に到達できないか、dCDNのCDNIメタデータ要求の一部またはすべてに応答してHTTP 4xxまたは5xxステータスを返します-dCDNは要求されたコンテンツを提供してはなりません（MUST NOT）。
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.
HTTPリダイレクション（HTTP 302リダイレクトなど）がCDN間で使用されている場合、dCDNは、受信したリクエストに含まれる情報から（たとえば、URIを介して）特定のリクエストをリダイレクトしたuCDNを判別できることが期待されます。どのuCDNが要求をルーティングしたかを知っていると、dCDNはHostIndexを取得するための正しいuCDNを選択できます。各uCDNによって提供されるHostIndexesは一意にすることができます。
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リダイレクトの場合、特定のリクエストをリダイレクトしたuCDNを特定するために、ユーザーエージェントからのDNSリクエストに常に十分な情報が含まれているとは限りません（たとえば、特定のホストからのコンテンツが複数のuCDNによって特定のdCDNにリダイレクトされた場合） ）;したがって、使用するuCDNのCDNIメタデータインターフェイスを決定するときに、dCDNはローカルポリシーを適用する必要があります。
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.
特定のuCDNのHostIndexオブジェクトのURIは、dCDNで設定する必要があります。他のすべてのオブジェクト/リソースは、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.
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.
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. ユーザーエージェントとCDNの両方について、新しいGenericMetadataオブジェクトのセキュリティとプライバシーの影響について説明します。
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は、対応するコンテンツに対する要求を処理してはなりません（MUST NOT）。
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.
注：理想的には、uCDNはコンテンツ要求を、要求されているコンテンツに関連付けられた強制する必要があるメタデータをサポートしない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 mandatory-to-enforce, it could be ambiguous as to which metadata should be applied, especially in the case of overlapping functionality.
新しいメタデータ定義が廃止されたり、既存のGenericMetadataと競合したりする可能性があります（たとえば、CDNI Metadataインターフェースの将来のリビジョンでは、Auth GenericMetadataオブジェクトが再定義されるか、カスタムベンダー拡張が代替のAuthメタデータオプションを実装する可能性があります）。複数のメタデータ（MI.Auth.v2、vendor1.Auth、vendor2.Authなど）がすべて既存のGenericMetadataオブジェクト（つまり、MI.Auth）と競合し、すべて強制必須としてマークされている場合、あいまいになる可能性があります特に重複する機能の場合、どのメタデータを適用する必要があるかについて。
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 Metadataインターフェースは、異なる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階層で順序付けられているため、競合する複数のメタデータタイプを使用できます（MAY）。ただし、メタデータ階層では、メタパス定義があいまいまたは競合しないように、独立したPathMatchルートオブジェクトを使用する必要があります（SHOULD）。
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 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.
Linkオブジェクトによって参照される場合を除き、ネストされたメタデータオブジェクト（つまり、HostIndexの下の構造メタデータ、およびSource、LocationRule、TimeWindowRule、ProtocolRule、Footprint、TimeWindowオブジェクト）は、明示的なCDNIペイロードタイプ情報なしでJSONペイロードにシリアル化できます。タイプは、外部構造メタデータ、GenericMetadata、またはAuthオブジェクトのCDNIペイロードタイプから推測されます。ネスト可能なメタデータオブジェクトを改訂するときのあいまいさを回避するために、すべての外部メタデータオブジェクトを元に戻し、同時に新しいCDNIペイロードタイプを割り当てる必要があります。たとえば、このドキュメントで定義されているMI.HostIndexオブジェクトには、MI.HostMatchオブジェクトの配列が含まれており、それぞれにMI.HostMetadataオブジェクトが含まれています。新しいMI.HostMetadata.v2オブジェクトが必要な場合、外側のMI.HostIndexオブジェクトとMI.HostMatchオブジェクトを、たとえばそれぞれ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ヘッダーを含める必要があります（SHOULD）。メタデータクライアントは、Acceptヘッダーで複数のCDNIペイロードタイプを指定できます。たとえば、メタデータクライアントが同じタイプのオブジェクト（異なるCDNIペイロードタイプで定義されている）の2つの異なるバージョンを処理できる場合、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 |
+-----------------------+--------------------------+
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を要求し、CDMIペイロードタイプが「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"
}
}
]
}
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」のHostヘッダーがある場合、dCDNは「MI.HostMetadata」のCDNIペイロードタイプを想定して「https：//metadata.ucdn.example/host1234」から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"
}
]
}
},
{
"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"
}
}
]
}
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"
}
}
]
}
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":
{
"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 Types」レジストリの下の次のエントリの登録を要求します。
+--------------------------+---------------+
| 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)
目的：このペイロードタイプの目的は、HostMetadata 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)
目的：このペイロードタイプの目的は、PathMetadata MIオブジェクト（および関連する機能アドバタイズメント）を区別することです。
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)
目的：このペイロードタイプの目的は、フットプリント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)
目的：このペイロードタイプの目的は、Auth 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 and prevent gratuitous additions to the namespace. New registrations are required to provide a clear description of how to interpret new footprint types.
IANAは、「コンテンツ配信ネットワーク相互接続（CDNI）パラメータ」レジストリに新しい「CDNIメタデータフットプリントタイプ」サブレジストリを作成しました。 「CDNI Metadata Footprint Types」ネームスペースは、4.2.2.2項で説明されているFootprintオブジェクトによって使用される有効なFootprintオブジェクトタイプ値を定義します。 「CDNIメタデータフットプリントタイプ」名前空間への追加は、[RFC5226]で定義されている仕様必須ポリシーに準拠しています。 Designated Expertは、新しい型定義が既存の型定義と重複していないことを確認し、名前空間への不必要な追加を防止します。新しいフットプリントタイプの解釈方法を明確に説明するには、新しい登録が必要です。
The following table defines the initial values for the "CDNI Metadata Footprint Types" registry:
次の表は、「CDNI Metadata Footprint Types」レジストリの初期値を定義しています。
+----------------+--------------------------------+---------------+
| 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]で定義されている仕様必須ポリシーに準拠しています。この仕様では、プロトコルタイプとそれに関連付けられているプロトコルが定義されています。 Designated Expertは、新しいプロトコル定義が既存のプロトコル定義と重複していないことを確認し、名前空間への不必要な追加を防止します。
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 |
+-----------+----------------------+---------------+----------------+
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 1つ以上のユーザーエージェントに対する1つ以上のコンテンツのサービスを拒否します。
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 実際のオリジンサーバーではなく悪意のあるオリジンサーバーに接続するようにdCDNに指示し、マルウェアまたは中傷的な代替コンテンツを正当なコンテンツの代わりに使用できるようにします。または
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は、コンテンツプロバイダーのサービスのユーザーに関する追加の情報と使用パターンを取得できる場合があります。 。情報をdCDNに漏らすことを懸念するコンテンツプロバイダーは、コンテンツを配信するときにCDNIを使用しないようにuCDNパートナーに指示できます。
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].
CDNIメタデータインターフェースの実装は、[RFC2818]および[RFC7230]に従って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メタデータインターフェイス要求の情報のセキュリティを確保するために代替の方法が使用されていない限り、リモートエンドの認証を含む、CDNIメタデータインターフェイスのサーバー側（uCDN）およびクライアント側（dCDN）で使用する必要があります。応答（2つのCDN間のIPsecトンネルのセットアップ、または同じ企業エンティティが所有する2つのCDN間の物理的に保護された内部ネットワークの使用など）
The use of TLS for transport of the CDNI Metadata interface messages allows the dCDN and uCDN to authenticate each other.
CDNIメタデータインターフェイスメッセージの転送にTLSを使用すると、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] 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。
[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。、編、「インターネットホストの要件-アプリケーションとサポート」、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、「Uniform Resource Identifier（URI）：Generic Syntax」、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 / RFC4291、2006年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、「RFCで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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、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。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、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. 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> 。
[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、「Content Distribution Network Interconnection（CDNI）Problem Statement」、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。、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>。
[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]ブレイ、T。、編、「The I-JSON Message Format」、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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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署名」、作業中、draft-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。、「HTTP Over TLS」、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 Support for Four-Octet Autonomous System（AS）Number Space」、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。、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>。
[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、編、「Framework for Content Distribution Network Interconnection（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。、編、およびY. Lee、編、「Content Distribution Network Interconnection（CDNI）Requirements」、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.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 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] Ma、K。、「Content Delivery Network Interconnection（CDNI）Media Type Registration」、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。、「Request Routing Redirection Interface for Content Delivery Network（CDN）Interconnection」、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、「Content Delivery Network Interconnection（CDNI）Control Interface / Triggers」、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、「Content Delivery Network Interconnection（CDNI）Request Routing：Footprint and Capabilities Semantics」、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.
著者はまた、この文書への貢献に対してグラント・ワトソンとケント・レングに感謝したいと思います。
Authors' Addresses
著者のアドレス
Ben Niven-Jenkins Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
Ben Niven-Jenkins Nokia 3 Ely Road Milton、Cambridge CB24 6DDイギリス
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、Cambridge CB24 6DDイギリス
Email: rob.murray@nokia.com
Matt Caulfield Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 United States of America
Matt Caulfield Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719アメリカ合衆国
Phone: +1-978-936-9307
Email: mcaulfie@cisco.com
Kevin J. Ma Ericsson 43 Nagog Park Acton, MA 01720 United States of America
ケビンJ. Maエリクソン43 Nagog Parkアクトン、MA 01720アメリカ合衆国
Phone: +1 978-844-5100
Email: kevin.j.ma@ericsson.com