<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-cdni-metadata-05" ipr="trust200902">
  <front>
    <title abbrev="CDN Interconnect Metadata">CDN Interconnect
    Metadata</title>

    <author fullname="Ben Niven-Jenkins" initials="B" surname="Niven-Jenkins">
      <organization>Velocix (Alcatel-Lucent)</organization>

      <address>
        <postal>
          <street>3 Ely Road</street>

          <city>Milton</city>

          <region>Cambridge</region>

          <code>CB24 6AA</code>

          <country>UK</country>
        </postal>

        <email>ben@velocix.com</email>
      </address>
    </author>

    <author fullname="Rob Murray" initials="R" surname="Murray">
      <organization>Velocix (Alcatel-Lucent)</organization>

      <address>
        <postal>
          <street>3 Ely Road</street>

          <city>Milton</city>

          <region>Cambridge</region>

          <code>CB24 6AA</code>

          <country>UK</country>
        </postal>

        <email>rmurray@velocix.com</email>
      </address>
    </author>

    <author fullname="Grant Watson" initials="G" surname="Watson">
      <organization>Velocix (Alcatel-Lucent)</organization>

      <address>
        <postal>
          <street>3 Ely Road</street>

          <city>Milton</city>

          <region>Cambridge</region>

          <code>CB24 6AA</code>

          <country>UK</country>
        </postal>

        <email>gwatson@velocix.com</email>
      </address>
    </author>

    <author fullname="Matt Caulfield" initials="M" surname="Caulfield">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>1414 Massachusetts Avenue</street>

          <city>Boxborough</city>

          <region>MA</region>

          <code>01719</code>

          <country>USA</country>
        </postal>

        <phone>+1 978 936 9307</phone>

        <email>mcaulfie@cisco.com</email>
      </address>
    </author>

    <author fullname="Kent Leung" initials="K" surname="Leung">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>3625 Cisco Way</street>

          <city>San Jose</city>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 526 5030</phone>

        <email>kleung@cisco.com</email>
      </address>
    </author>

    <author fullname="Kevin J. Ma" initials="K.J." surname="Ma">
      <organization>Azuki Systems, Inc.</organization>

      <address>
        <postal>
          <street>43 Nagog Park</street>

          <city>Acton</city>

          <region>MA</region>

          <code>01720</code>

          <country>USA</country>
        </postal>

        <phone>+1 978-844-5100</phone>

        <email>kevin.ma@azukisystems.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>The CDNI Metadata Interface enables interconnected 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 the core set of CDNI metadata and the protocol for
      exchanging that metadata.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>CDNI enables a downstream CDN to service content requests on behalf
      of an upstream CDN. The CDNI metadata associated with a piece of content
      (or with a set of contents) provides a downstream CDN with sufficient
      information for servicing content requests on behalf of an upstream CDN
      in accordance with the policies defined by the upstream CDN.</t>

      <t>The CDNI Metadata Interface is introduced by <xref
      target="RFC6707"></xref> along with three other interfaces that may be
      used to compose a CDNI solution (Control, Request Routing and Logging).
      <xref target="I-D.ietf-cdni-framework"></xref> expands on the
      information provided in <xref target="RFC6707"></xref> and describes
      each interface, and the relationships between them, in more detail. The
      requirements for the CDNI metadata interface are specified in <xref
      target="I-D.ietf-cdni-requirements"></xref>.</t>

      <t>This document focuses on the CDNI Metadata interface which enables a
      downstream CDN to obtain CDNI Metadata from an upstream CDN so that the
      downstream CDN can properly process and respond to:</t>

      <t><list style="symbols">
          <t>Redirection Requests received over the CDNI Request Routing
          protocol.</t>

          <t>Content Requests received directly from User Agents.</t>
        </list></t>

      <t>Specifically, this document proposes:</t>

      <t><list style="symbols">
          <t>A data structure for mapping content requests to CDNI Metadata
          properties (<xref target="data-model"></xref>).</t>

          <t>An initial set of CDNI Metadata properties (<xref
          target="property-objects"></xref>).</t>

          <t>A RESTful web service for the transfer of CDNI Metadata (<xref
          target="metadata-interface"></xref>).</t>
        </list></t>

      <section anchor="terminology" title="Terminology">
        <t>This document reuses the terminology defined in <xref
        target="RFC6707"></xref>.</t>

        <t>Additionally, the following terms are used throughout this document
        and are defined as follows:<list style="symbols">
            <t>Object - a collection of properties</t>

            <t>Property - a key and value pair where the key is a property
            name and the value is the property value or an object.</t>
          </list></t>
      </section>
    </section>

    <section title="Design Principles">
      <t>The proposed CDNI Metadata Interface was designed to achieve the
      following objectives:</t>

      <t><list style="numbers">
          <t>Cacheability of CDNI metadata objects</t>

          <t>Deterministic mapping from redirection and content requests to
          CDNI metadata properties</t>

          <t>Support for DNS redirection as well as application-specific
          redirection (for example HTTP redirection)</t>

          <t>Minimal duplication of CDNI metadata</t>

          <t>Leverage existing protocols</t>
        </list></t>

      <t>Cacheability improves the latency of acquiring metadata while
      maintaining its freshness and therefore improves the latency of serving
      content requests. The CDNI Metadata Interface uses HTTP to achieve
      cacheability.</t>

      <t>Deterministic mappings from content to metadata properties eliminates
      ambiguity and ensures that policies are applied consistently by all
      downstream CDNs.</t>

      <t>Support for both HTTP and DNS redirection ensures that the CDNI
      Metadata Interface can be used for HTTP and DNS redirection and also
      meets the same design principles for both HTTP and DNS based redirection
      schemes.</t>

      <t>Minimal duplication of CDNI metadata provides space efficiency on
      storage in the CDNs, on caches in the network, and across the network
      between CDNs.</t>

      <t>Leveraging existing protocols avoids reinventing common mechanisms
      such as data structure encoding (e.g. XML, JSON) and data transport
      (e.g. HTTP).</t>
    </section>

    <section anchor="data-model" title="CDNI Metadata Data Model">
      <t>The CDNI Metadata Model describes a data structure for mapping
      redirection requests and content requests to metadata properties.
      Metadata properties describe how to acquire content from an upstream CDN, 
      authorize access to content, and deliver
      content from a downstream CDN. The data model relies on the assumption
      that these metadata properties may be aggregated based on the hostname
      of the content and subsequently on the resource path of the content. The
      data 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.</t>

      <t>Different Hostnames and URI paths will be associated with different
      sets of CDNI Metadata properties in order to describe the required
      behaviour when a dCDN surrogate is processing User Agent requests for
      content at that Hostname or URI path. As a result of this structure,
      significant commonality may 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 treated as being
      grouped together into a single network or geographic location is likely
      to be common for a number of different Hostnames. Another example is
      that 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 would be applied to multiple Hostnames delivered
      through the CDN.</t>

      <t>In order to enable the CDNI Metadata for a given Hostname or URI Path
      to be decomposed into sets of CDNI Metadata properties that can be
      reused by multiple Hostnames and URI Paths, the CDNI Metadata interface
      specified in this document splits the CDNI Metadata into a number of
      objects. Efficiency is improved by enabling a single CDNI Metadata
      object (that is shared across Hostname and/or URI paths) to be retrieved
      by a dCDN once, even if it is referenced by the CDNI Metadata of
      multiple Hostnames.</t>

      <t><xref target="hostindex-intro"></xref> introduces a high level
      description of the HostIndex, HostMetadata and PathMetadata objects and
      describes the relationships between those objects.</t>

      <t><xref target="other-objects-intro"></xref> 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.</t>

      <t><xref target="abstract-metadata-description"></xref> describes in
      detail the specific CDNI Metadata objects and properties which may be
      contained within a CDNI GenericMetadata object.</t>

      <section anchor="hostindex-intro"
               title="HostIndex, HostMetadata &amp; PathMetadata objects">
        <t>A HostIndex object contains a list of Hostnames (and/or IP
        addresses) for which content requests may be delegated to the
        downstream CDN. The HostIndex is the starting point for accessing the
        uCDN's CDNI Metadata data store. It enables surrogates in the dCDN to
        deterministically discover, on receipt of a User Agent request for
        content, which other CDNI Metadata objects it requires in order to
        deliver the requested content.</t>

        <t>The HostIndex links Hostnames (and/or IP addresses) to HostMetadata
        objects via HostMatch objects. HostMetadata objects contain (or
        reference) the default CDNI Metadata required to serve content for
        that host. When looking up CDNI Metadata, the downstream CDN looks up
        the requested Hostname (or IP address) in the HostIndex, from there it
        can find HostMetadata which describes properties for a host and
        PathMetadata which may override those properties for given URI paths
        within the host.</t>

        <t>Besides containing the default CDNI Metadata for the specified
        Hostname, HostMetadata and PathMetadata objects may also contain
        PathMatch objects which in turn contain PathMetadata objects.
        PathMatch objects override the CDNI Metadata in the HostMetadata
        object or one or more preceding PathMetadata objects with more
        specific CDNI Metadata that applies to content requests matching the
        pattern defined in that PathMatch object.</t>

        <t>For the purposes of retrieving CDNI Metadata all other required
        CDNI Metadata objects and their properties are discoverable from the
        appropriate HostMetadata, PathMatch and PathMetadata objects for the
        requested content.</t>

        <t>The relationships between the HostIndex, HostMatch, HostMetadata,
        PathMatch and PathMetadata objects are described in <xref
        target="metadata-model-figure-top"></xref>.</t>

        <t><figure anchor="metadata-model-figure-top"
            title="Relationships between the HostIndex, HostMetadata &amp; PathMetadata CDNI Metadata Objects">
            <artwork><![CDATA[
+---------+      +---------+      +------------+
|HostIndex+-(*)->|HostMatch|-(1)->|HostMetadata+-------(*)------+
+---------+      +---------+      +------+-----+                |
                                         |                      |
                                        (*)                     |
                                         |                      |
--> References                           V                      V
(1) One and only one                +---------+    **************************
(*) Zero or more               +--->|PathMatch|    *Generic Metadata Objects*
                               |    +---------+    **************************
                               |         |                      ^
                              (*)       (1)                     |
                               |         |                      |
                               |         V                      |
                               |  +------------+                |
                               +--|PathMetadata+-------(*)------+         
                                  +------------+
]]></artwork>

          </figure></t>

        <t>The relationships in <xref
        target="metadata-model-figure-top"></xref> are summarised in <xref
        target="metadata-model-table"></xref> below.</t>

        <texttable anchor="metadata-model-table"
                   title="Relationships between CDNI Metadata Objects">
          <ttcol>Data Object</ttcol>

          <ttcol>Objects it References</ttcol>

          <c>HostIndex</c>

          <c>0 or more HostMatch objects.</c>

          <c>HostMatch</c>

          <c>1 HostMetadata object.</c>

          <c>HostMetadata</c>

          <c>0 or more PathMatch objects. 0 or more GenericMetadata
          objects.</c>

          <c>PathMatch</c>

          <c>1 PathMetadata object.</c>

          <c>PathMetadata</c>

          <c>0 or more PathMatch objects. 0 or more GenericMetadata
          objects.</c>
        </texttable>

        <t>The table below describes the HostIndex, HostMetadata and
        PathMetadata objects in more detail.</t>

        <texttable anchor="hostindex-objects-table"
                   title="HostIndex, HostMetadata and PathMetadata CDNI Metadata Objects">
          <ttcol>Data Object</ttcol>

          <ttcol>Description</ttcol>

          <c>HostIndex</c>

          <c>A HostIndex object lists HostMatch objects</c>

          <c>HostMatch</c>

          <c>A HostMatch object defines a hostname to match against a
          requested host, and contains or references a HostMetadata object
          which contains CDNI Metadata objects to be applied when a request
          matches against the hostname. For example, if "example.com" is a
          content provider, a HostMatch object may include an entry for
          "example.com" with the URI of the associated HostMetadata
          object.</c>

          <c>HostMetadata</c>

          <c>A HostMetadata object contains (or references) the default CDNI
          Metadata objects for content served from that host, i.e. the CDNI
          Metadata objects for content requests that do not match any of the
          PathMatch objects contained or referenced by that HostMetadata
          object. For example, a HostMetadata object may describe the metadata
          properties which apply to "example.com" and may contain PathMatches
          for "example.com/movies/*" and "example.com/music/*" which reference
          corresponding PathMetadata objects that contain the CDNI Metadata
          objects for those more specific URI paths.</c>

          <c>PathMatch</c>

          <c>A PathMatch object defines a pattern to match against the
          requested URI path, and contains or references a PathMetadata object
          which contains (or references) the CDNI Metadata objects to be
          applied when a content request matches against the defined URI path
          pattern. For example, a PathMatch object may include a pattern
          for the path "/movies/*" and may reference a PathMetadata object which
          contains the CDNI Metadata for content with that path.</c>

          <c>PathMetadata</c>

          <c>A PathMetadata object contains the CDNI GenericMetadata objects
          for content served with the associated URI path (defined in a
          PathMatch object). A PathMetadata object may also contain PathMatch
          objects in order to recursively define more specific URI paths that
          require different (e.g. more specific) CDNI Metadata to this one.
          For example, the PathMetadata object which applies to
          "example.com/movies/*" may describe CDNI Metadata which apply to
          that resource path and may contain a PathMatch object for
          "example.com/movies/hd/*" which would reference the corresponding
          PathMetadata object for the "example.com/movies/hd/" path
          prefix.</c>

          <c>GenericMetadata</c>

          <c>A GenericMetadata object contains individual CDNI Metadata
          objects which define the specific policies and attributes needed to
          properly deliver the associated content. For example, a GenericMetadata
          object may describe the source from which a CDN may acquire a piece of
          content.</c>
        </texttable>

        <t></t>
      </section>

      <section anchor="other-objects-intro"
               title="Generic CDNI Metadata Object Properties">
        <t>The HostMetadata and PathMetadata objects contain or can reference
        other CDNI Metadata objects that contain properties which describe how
        User Agent requests for content should be processed, for example where
        to acquire the content, authorization rules that should be applied,
        delivery location 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 (e.g., property semantics, enforcement options,
        etc.).</t>

        <t>The GenericMetadata object defines the type of properties contained
        within it as well as whether or not the properties are mandatory to
        enforce. If the dCDN does not understand or support the property type
        and the property type is mandatory to enforce, the dCDN MUST NOT serve
        the content to the User Agent. If the dCDN does not understand or
        support the property type it is also not going to be able to properly
        propagate the Metadata for cascaded distribution. If the dCDN does not
        understand or support the property type and the property type is not
        mandatory to enforce, then the GenericMetadata object may be safely
        ignored.</t>

        <t>Although a CDN cannot serve content to a User Agent if a mandatory
        property cannot be enforced, it may be safe to redistribute that
        metadata to another CDN without modification. For example, in the
        cascaded CDN case, a transit CDN may pass through mandatory-to-enforce
        metadata to the delivery CDN. For Metadata which does not require
        customization, the data representation received off the wire MAY be
        stored and redistributed without being natively understood or
        supported by the transit CDN. However, for Metadata which require
        translations, transparent redistribution of the uCDN Metadata values
        may not be appropriate. Certain Metadata may be safely, though
        possibly not optimially, redistributed unmodified, e.g., source
        acquisition address may not be optimal if transparently redistributed,
        but may still work. Redistribution safety MUST be specified for each
        GenericMetadata.</t>
      </section>

      <section anchor="metadata-inheritance"
               title="Metadata Inheritance and Override">
        <t>In the data model, a HostMetadata object may contain (or reference)
        multiple PathMetadata objects (via PathMatch objects). Each
        PathMetadata object may in turn contain (or reference) 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.</t>

        <t>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 type LocationACL and TimeWindowACL, while a
        PathMetadata object which applies to "example.com/movies/*" defines an
        alternate GenericMetadata object of type TimeWindowACL, then: <list>
            <t>the TimeWindowACL defined in the PathMetadata would override
            the TimeWindowACL defined in the HostMetadata</t>

            <t>the LocationACL defined in the HostMetadata would be inherited
            for all User Agent requests for content under
            "example.com/movies".</t>
          </list>The PathMetadata defined TimeWindowACL would override the
        TimeWindowACL defined in the HostMetadata for all User Agent requests
        for movies.</t>
      </section>

      <section anchor="metadata-naming" title="Metadata Naming">
        <t>GenericMetadata objects are identified by their type. The type
        SHOULD be descriptive, and MAY be hierarchical to support aggregating
        groups of properties for the purpose of readability and for avoiding
        name conflicts between vendor extensions. A dotted alpha-numeric
        notation is suggested for human readability.</t>

        <t>Metadata types defined by this document are not hierarchical.</t>
      </section>
    </section>

    <section anchor="abstract-metadata-description"
             title="Encoding-Independent CDNI Metadata Object Descriptions">
      <t><xref target="structural-objects"></xref> provides the definitions of
      each object type declared in <xref target="data-model"></xref>. These
      objects are described as structural objects as they provide the
      structure for the inheritance tree and identifying which specific
      properties apply to a given User Agent content request.</t>

      <t><xref target="property-objects"></xref> provides the definitions for
      the set of core metadata objects which may be contained within a
      GenericMetadata object. These objects are described as property objects
      as they define the semantics, enforcement options, and serialization
      rules for specific properties. These properties govern how User Agent
      requests for content are handled. Property objects may be composed of or
      contain references to other objects. In those cases the value of the
      property can be either an object of that type (the object is embedded)
      or a Link object that contains a URI and relationship that can be
      dereferenced to retrieve the CDNI Metadata object that represents the
      value of that property.</t>

      <t>Note: In the following sections, the term "mandatory-to-specify" is
      used to convey which objects or properties must be specified for a given
      parent object or property. When mandatory-to-specify is set to true, it
      implies that if the parent object is specified, then the defined object
      or property MUST also be specified, e.g., a HostMatch object without a
      host to match against does not make sense, therefore, the host is
      mandatory-to-specify inside a parent HostMatch object.</t>

      <section anchor="structural-objects"
               title="CDNI Metadata Structural Object Descriptions">
        <t>Each of the sub-sections below describe the structural objects
        defined in <xref target="hostindex-objects-table"></xref>.</t>

        <section anchor="HostIndex" title="HostIndex">
          <t>The HostIndex object is the entry point into the CDNI Metadata
          hierarchy. It contains a list of HostMatch objects. An incoming
          content request is matched against the hostname inside of each of
          the listed HostMatch objects to find the HostMatch object which
          applies to the request.</t>

          <t><list style="empty">
              <t>Property: hosts<list style="empty">
                  <t>Description: List of HostMatch objects, in priority
                  order.</t>

                  <t>Type: List of HostMatch objects</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="HostMatch" title="HostMatch">
          <t>The HostMatch object contains a hostname or IP address to match
          against content requests. The HostMatch object also contains a
          reference to Metadata objects to apply if a match is found.</t>

          <t><list style="empty">
              <t>Property: host<list style="empty">
                  <t>Description: String (hostname or IP address) to match
                  against the requested host.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: host-metadata<list style="empty">
                  <t>Description: CDNI Metadata to apply when delivering
                  content that matches this host.</t>

                  <t>Type: HostMetadata</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="HostMetadata" title="HostMetadata">
          <t>The HostMetadata object contains both Metadata that applies to
          content requests for a particular host and a list of pattern matches
          for finding more specific Metadata based on the resource path in a
          content request.</t>

          <t><list style="empty">
              <t>Property: metadata<list style="empty">
                  <t>Description: List of host related metadata.</t>

                  <t>Type: List of GenericMetadata objects</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: paths<list style="empty">
                  <t>Description: Path specific rules. First match
                  applies.</t>

                  <t>Type: List of PathMatch objects</t>

                  <t>Mandatory-to-Specify: No.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="PathMatch" title="PathMatch">
          <t>The PathMatch object contains an expression given as a
          PatternMatch object to match against a resource URI path and
          Metadata objects to apply if a match is found.</t>

          <t><list style="empty">
              <t>Property: path-pattern<list style="empty">
                  <t>Description: Pattern to match against the requested path,
                  i.e. against the <xref target="RFC3986"></xref>
                  path-absolute.</t>

                  <t>Type: PatternMatch</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: path-metadata<list style="empty">
                  <t>Description: CDNI Metadata to apply when delivering
                  content that matches this pattern.</t>

                  <t>Type: PathMetadata</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="PathMetadata" title="PathMetadata">
          <t>A PathMetadata object contains the CDNI Metadata properties for
          content served with the associated URI path (defined in a PathMatch
          object). Note that if CDNI metadata is used as an input to CDNI
          request routing and DNS-based redirection is employed, then any
          metadata at the PathMetadata level or below will be inaccessible at
          request routing time.</t>

          <t><list style="empty">
              <t>Property: metadata<list style="empty">
                  <t>Description: List of path related metadata.</t>

                  <t>Type: List of GenericMetadata objects</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: paths<list style="empty">
                  <t>Description: Path specific rules. First match
                  applies.</t>

                  <t>Type: List of PathMatch objects</t>

                  <t>Mandatory-to-Specify: No.</t>
                </list></t>
            </list></t>
        </section>

        <section title="PatternMatch">
          <t>A PatternMatch object contains the pattern string and flags that
          describe the PathMatch expression.</t>

          <t><list style="empty">
              <t>Property: pattern<list style="empty">
                  <t>Description: A pattern for string matching. The pattern
                  may contain the wildcards * and ?, where * matches any
                  sequence of characters (including the empty string) and ?
                  matches exactly one character. The three literals \ , * and
                  ? should be escaped as \\, \* and \?. All other characters
                  are treated as literals.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: case-sensitive<list style="empty">
                  <t>Description: Flag indicating whether or not
                  case-sensitive matching should be used.</t>

                  <t>Type: Boolean</t>

                  <t>Mandatory-to-Specify: No. Default is case-insensitive
                  match.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: ignore-query-string<list style="empty">
                  <t>Description: List of query parameters which should be
                  ignored when searching for a pattern match. If all query
                  parameters should be ignored then the list MUST be
                  empty.</t>

                  <t>Type: List of String</t>

                  <t>Mandatory-to-Specify: No. Default is to include query
                  strings when matching.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="generic-metadata" title="GenericMetadata">
          <t>A GenericMetadata object is a abstraction for managing individual
          CDNI Metadata properties in an opaque manner.</t>

          <t><list style="empty">
              <t>Property: type<list style="empty">
                  <t>Description: CDNI Metadata property object type.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: value<list style="empty">
                  <t>Description: CDNI Metadata property object.</t>

                  <t>Type: matches the type property above</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: mandatory-to-enforce<list style="empty">
                  <t>Description: Flag identifying whether or not the
                  enforcement of the property Metadata is required.</t>

                  <t>Type: Boolean</t>

                  <t>Mandatory-to-Specify: No. Default is to treat metadata as
                  mandatory to enforce.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: safe-to-redistribute<list style="empty">
                  <t>Description: Flag identifying whether or not the property
                  Metadata may be safely redistributed without
                  modification.</t>

                  <t>Type: Boolean</t>

                  <t>Mandatory-to-Specify: No. Default is allow transparent
                  redistribution.</t>
                </list></t>
            </list></t>
        </section>
      </section>

      <section anchor="property-objects"
               title="CDNI Metadata Property Object Descriptions">
        <t>The property objects defined below are intended to be used in the
        GenericMetadata object value field as defined in <xref
        target="generic-metadata"></xref>. All of the objects defined below
        are considered both mandatory to enforce and safe to redistribute.</t>

        <section anchor="SourceMetadata" title="Source Metadata">
          <t>Source Metadata provides the dCDN information about content
          acquisition e.g. how to contact an 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 CSP but might
          be a set of Surrogates in the uCDN.</t>

          <t><list style="empty">
              <t>Property: sources<list style="empty">
                  <t>Description: Sources from which the dCDN can acquire
                  content, listed in priority order.</t>

                  <t>Type: List of Source objects</t>

                  <t>Mandatory-to-Specify: No. Default is to use static
                  configuration, out of band of the metadata interface.</t>
                </list></t>
            </list></t>

          <section anchor="Source" title="Source">
            <t>A Source object describes the Source which should 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.</t>

            <t><list style="empty">
                <t>Property: auth<list style="empty">
                    <t>Description: Authentication method to use when
                    requesting content from this source.</t>

                    <t>Type: Auth</t>

                    <t>Mandatory-to-Specify: No. Default is no authentication
                    is required.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: endpoints<list style="empty">
                    <t>Description: Origins from which the dCDN can acquire
                    content.</t>

                    <t>Type: List of EndPoint objects</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: protocol<list style="empty">
                    <t>Description: Network retrieval protocol to use when
                    requesting content from this source.</t>

                    <t>Type: Protocol</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list></t>
          </section>
        </section>

        <section anchor="LocationACL" title="LocationACL Metadata">
          <t>LocationACL Metadata defines location-based restrictions.</t>

          <t><list style="empty">
              <t>Property: locations<list style="empty">
                  <t>Description: Access control list which applies
                  restrictions to delivery based on client location.</t>

                  <t>Type: List of LocationRule objects</t>

                  <t>Mandatory-to-Specify: No. Default is allow all
                  locations.</t>
                </list></t>
            </list></t>

          <section anchor="LocationRule" title="LocationRule">
            <t>A LocationRule contains or references a list of Footprint
            objects and the corresponding action.</t>

            <t><list style="empty">
                <t>Property: footprints<list style="empty">
                    <t>Description: List of footprints to which the rule
                    applies.</t>

                    <t>Type: List of Footprint objects</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: action<list style="empty">
                    <t>Description: Defines whether the rule specifies
                    locations to allow or deny.</t>

                    <t>Type: Enumeration [allow|deny]</t>

                    <t>Mandatory-to-Specify: No. Default is deny.</t>
                  </list></t>
              </list></t>
          </section>

          <section anchor="Footprint" title="Footprint">
            <t>A Footprint object describes the footprint to which a
            LocationRule may be applied by, e.g. an IPv4 address range or a
            geographic location.</t>

            <t><list style="empty">
                <t>Property: type<list style="empty">
                    <t>Description: Registered footprint type (see <xref
                    target="FootprintReg"></xref>).</t>

                    <t>Type: String</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: value<list style="empty">
                    <t>Description: Footprint object conforming to the
                    specification associated with the registered footprint
                    type.</t>

                    <t>Type: String</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list></t>
          </section>
        </section>

        <section anchor="TimeWindowACL" title="TimeWindowACL Metadata">
          <t>TimeWindowACL Metadata defines time-based restrictions.</t>

          <t><list style="empty">
              <t>Property: times<list style="empty">
                  <t>Description: Access control list which applies
                  restrictions to delivery based on request time.</t>

                  <t>Type: List of TimeWindowRule objects</t>

                  <t>Mandatory-to-Specify: No. Default is allow all time
                  windows.</t>
                </list></t>
            </list></t>

          <section anchor="TimeWindowRule" title="TimeWindowRule">
            <t>A TimeWindowRule contains or references a list of TimeWindow
            objects and the corresponding action.</t>

            <t><list style="empty">
                <t>Property: times<list style="empty">
                    <t>Description: List of time windows to which the rule
                    applies.</t>

                    <t>Type: List of TimeWindow objects</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: action<list style="empty">
                    <t>Description: Defines whether the rule specifies time
                    windows to allow or deny.</t>

                    <t>Type: Enumeration [allow|deny]</t>

                    <t>Mandatory-to-Specify: No. Default is deny.</t>
                  </list></t>
              </list></t>
          </section>

          <section anchor="TimeWindow" title="TimeWindow">
            <t>A TimeWindow object describes a time range which may be applied
            by an ACLRule, e.g. Start 09:00AM 01/01/2000 UTC End 17:00PM
            01/01/2000 UTC.</t>

            <t><list style="empty">
                <t>Property: start<list style="empty">
                    <t>Description: The start time of the window.</t>

                    <t>Type: Time</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: end<list style="empty">
                    <t>Description: The end time of the window.</t>

                    <t>Type: Time</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list></t>
          </section>
        </section>

        <section anchor="ProtocolACL" title="ProtocolACL Metadata">
          <t>ProtocolACL Metadata defines delivery protocol restrictions.</t>

          <t><list style="empty">
              <t>Property: protocols<list style="empty">
                  <t>Description: Access control list which applies
                  restrictions to delivery based on delivery protocol.</t>

                  <t>Type: List of ProtocolRule objects</t>

                  <t>Mandatory-to-Specify: No. Default is allow all
                  protocols.</t>
                </list></t>
            </list></t>

          <section anchor="ProtocolRule" title="ProtocolRule">
            <t>A ProtocolRule contains or references a list of Protocol
            objects. ProtocolRule objects are used to construct a ProtocolACL
            to apply restrictions to content acquisition or delivery.</t>

            <t><list style="empty">
                <t>Property: protocols<list style="empty">
                    <t>Description: List of protocols to which the rule
                    applies.</t>

                    <t>Type: List of protocol objects</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: action<list style="empty">
                    <t>Description: Defines whether the rule specifies
                    protocols to allow or deny.</t>

                    <t>Type: Enumeration [allow|deny]+</t>

                    <t>Mandatory-to-Specify: No. Default is allow all
                    protocols.</t>
                  </list></t>
              </list><list style="empty">
                <t>Property: direction<list style="empty">
                    <t>Description: Defines whether the ProtocolRule specifies
                    protocols for acquisition or delivery.</t>

                    <t>Type: Enumeration [acquisition|delivery]</t>

                    <t>Mandatory-to-Specify: No. Default is to apply the rule
                    to both acquisition and delivery.</t>
                  </list></t>
              </list></t>
          </section>
        </section>

        <section anchor="Authorization" title="Authorization Metadata">
          <t>Authorization Metadata define content authorization methods.</t>

          <t><list style="empty">
              <t>Property: methods<list style="empty">
                  <t>Description: Options for authenticating content requests.
                  All options in the list are equally valid.</t>

                  <t>Type: List of Auth objects</t>

                  <t>Mandatory-to-Specify: No. Default is no authorization
                  required.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="Auth" title="Auth">
          <t>An Auth object defines authentication and authorization methods
          to be used during content delivery and content acquisition.</t>

          <t><list style="empty">
              <t>Property: type<list style="empty">
                  <t>Description: Registered Auth type (see <xref
                  target="AuthReg"></xref>).</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: value<list style="empty">
                  <t>Description: Auth object conforming to the specification
                  associated with the registered Auth type.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: Yes.</t>
                </list></t>
            </list></t>

          <section anchor="CredentialsAuth" title="Credentials Auth Type">
            <t>Credentials Auth is a type of Auth object with type
            "credentials" (see <xref target="AuthReg"></xref>). The
            CredentialsAuth object contains the following properties:</t>

            <t><list style="empty">
                <t>Property: username<list style="empty">
                    <t>Description: Identification of user.</t>

                    <t>Type: String</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>

                <t>Property: password<list style="empty">
                    <t>Description: Password for user identified by username
                    property.</t>

                    <t>Type: String</t>

                    <t>Mandatory-to-Specify: Yes.</t>
                  </list></t>
              </list></t>
          </section>
        </section>

        <section anchor="Cache" title="Cache">
          <t>A Cache object describes the cache control parameters to be
          applied to the content by intermediate caches.</t>

          <t><list style="empty">
              <t>Property: ignore-query-string<list style="empty">
                  <t>Description: Allows a cache to ignore URI query string
                  parameters while comparing URIs for equivalence. Each query
                  parameter to ignore is specified in the list. If all query
                  parameters should be ignored, then the list MUST be
                  empty.</t>

                  <t>Type: List of String</t>

                  <t>Mandatory-to-Specify: No. Default is to consider query
                  string parameters when comparing URIs or to rely on other
                  properties of the Cache object.</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="Grouping" title="Grouping">
          <t>A Grouping object identifies a large group of content to which
          this content belongs.</t>

          <t><list style="empty">
              <t>Property: ccid<list style="empty">
                  <t>Description: Content Collection identifier for an
                  application-specific purpose such as logging.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: No. Default is an empty string.</t>
                </list></t>
            </list><list style="empty">
              <t>Property: sid<list style="empty">
                  <t>Description: Session identifier for an
                  application-specific purpose such as logging.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: No. Default is an empty string.</t>
                </list></t>
            </list></t>
        </section>
      </section>

      <section anchor="simple-data-types"
               title="CDNI Metadata Simple Data Type Descriptions">
        <t>This section describes the simpler data types that are used for
        properties of CDNI Metadata objects.</t>

        <section anchor="Link" title="Link">
          <t>A link object may be used in place of any of the objects or
          properties described above. Links can be used to avoid duplication
          if the same metadata information is repeated within the metadata
          tree. When a link replaces an object, its href property is set to
          the URI of the resource and its type property is set to the type
          of the object it is replacing.</t>

          <t><list style="empty">
              <t>Property: href<list style="empty">
                  <t>Description: The URI of the of the addressable object
                  being referenced.</t>

                  <t>Type: URI</t>

                  <t>Mandatory-to-Specify: Yes</t>
                </list></t>
            </list><list style="empty">
              <t>Property: type<list style="empty">
                  <t>Description: The type of the object being referenced.</t>

                  <t>Type: String</t>

                  <t>Mandatory-to-Specify: No</t>
                </list></t>
            </list></t>
        </section>

        <section anchor="Protocol" title="Protocol">
          <t>Protocol objects are used to specify registered protocols for
          content acquisition or delivery (see <xref
          target="ProtocolReg"></xref>).</t>

          <t>Type: String</t>

          <t>Mandatory-to-Specify: Yes</t>
        </section>

        <section title="Endpoint">
          <t>A hostname (with optional port) or an IP address (with optional
          port).</t>

          <t>Note: All implementations MUST support IPv4 addresses encoded as
          specified by the 'IPv4address' rule in Section 3.2.2 of <xref
          target="RFC3986"></xref> and MUST support all IPv6 address formats
          specified in <xref target="RFC4291"></xref>. Server implementations
          SHOULD use IPv6 address formats specified in <xref
          target="RFC5952"></xref>.</t>
        </section>

        <section title="URI">
          <t>A URI as specified in <xref target="RFC3986"></xref>.</t>
        </section>

        <section title="Time">
          <t>A time value expressed in seconds since Unix epoch in the UTC
          timezone.</t>
        </section>
      </section>
    </section>

    <section anchor="metadata-capabilities" title="CDNI Metadata Capabilities">
      <t>CDNI Metadata is used to convey information pertaining to content
      delivery from uCDN to dCDN. For optional metadata, it may be useful for
      the uCDN to know if the dCDN supports the metadata, prior to delegating
      any content requests to the dCDN. If optional-to-implement metadata is
      mandatory-to-enforce and the dCDN does not support it, any delegated
      requests for that content will fail, so there is no reason to delegate
      those requests. Likewise, for any metadata which may be assigned
      optional values, it may be useful for the uCDN to know which values the
      dCDN supports, prior to delegating any content requests to the dCDN. If
      a the optional value assigned to a given piece of content's metadata is
      not supported by the dCDN, any delegated requests for that content may
      fail, so there is likely no reason to delegate those requests.</t>

      <t>The CDNI Footprint and Capabilities Interface provides a means of
      advertising capabilities from dCDN to uCDN. Support for optional
      metadata and support for optional metadata values may be advertised
      using the capabilities interface. This section describes the
      capabilities advertisement requirements for the metadata defined in
      <xref target="property-objects"></xref></t>

      <section anchor="ProtocolACLCapabilities"
               title="Protocol ACL Capabilities">
        <t>The ProtoclACL object contains a list of Protocol values. The dCDN
        MUST advertise which delivery protocols it supports so that the uCDN
        knows what type of content requests it can redirect to the dCDN. If
        the dCDN does not support a given acquisition or delivery protocol,
        the uCDN should not delegate requests requiring those protocols to the
        dCDN as the dCDN will not be able to properly acquire or deliver the
        content.</t>

        <t>ProtocolRules are defined for either acquisition or delivery. For
        some CDNs, certain combinations of acquisition and delivery protocols
        may not make sense (e.g., RTSP acquisition for HTTP delivery), while
        other CDNs may support customized protocol adaptation. ProtocolACL
        capabilities are not intended to define which combinations of
        protocols should be used. ProtocolACL capabilties are only intended to
        describe which protocols the dCDN does or does not support. Protocol
        combination restrictions are specified in the metadata itself and
        associated with specific groups of content assets.</t>
      </section>

      <section anchor="AuthorizationCapabilities"
               title="Authorization Metadata Capabilities">
        <t>The Authorization object contains a list of Auth values. The dCDN
        MUST advertise which authorization algorithms it supports so that the
        uCDN knows what type of content requests it can redirect to the dCDN.
        If the dCDN does not support a given authorization algorithm, the uCDN
        should not delegate requests requiring that algorithm to the dCDN as
        the dCDN will not be able to properly acquire the content or enforce
        delivery restrictions.</t>
      </section>
    </section>

    <section anchor="metadata-interface" title="CDNI Metadata interface">
      <t>This section specifies an interface to enable a Downstream CDN to
      retrieve CDNI Metadata objects from an Upstream CDN.</t>

      <t>The interface can be used by a Downstream CDN to retrieve CDNI
      Metadata objects either dynamically as required by the Downstream CDN to
      process received requests (for example in response to receiving a CDNI
      Request Routing request from an Upstream CDN or in response to receiving
      a request for content from a User Agent) or in advance of being required
      (for example in case of prepositioned CDNI Metadata acquisition).</t>

      <t>The CDNI Metadata interface is built on the principles of RESTful web
      services. 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 Data Model (as described in <xref target="data-model"></xref>
      through <xref target="abstract-metadata-description"></xref>).</t>

      <t>In the general case a CDNI Metadata server makes each instance of an
      addressable CDNI Metadata object available via a unique URI that returns
      a representation of that instance of that CDNI Metadata object. When an
      object needs to reference another addressable CDNI Metadata object (for
      example a HostIndex object referencing a HostMetadata object) it does so
      by including a link to the referenced object.</t>

      <t>CDNI Metadata servers 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. Therefore any URIs present in the examples below are purely
      illustrative and are not intended to impose a definitive structure on
      CDNI Metadata interface implementations.</t>

      <section title="Transport">
        <t>The CDNI Metadata interface uses HTTP as the underlying protocol
        transport.</t>

        <t>The HTTP Method in the request defines the operation the request
        would like to perform. Servers implementing the CDNI Metadata
        interface MUST support the HTTP GET and HEAD methods.</t>

        <t>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 from
        servers implementing the CDNI Metadata interface that contain a
        response body SHOULD include an ETag to enable validation of cached
        versions of returned resources.</t>

        <t>The CDNI Metadata interface specified in this document is a
        read-only interface. Therefore support for other HTTP methods such as
        PUT, POST and DELETE etc. is not specified. Server implementations of
        this interface SHOULD reject all methods other than GET and HEAD.</t>

        <t>As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata
        servers 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.</t>
      </section>

      <section title="Retrieval of CDNI Metadata resources">
        <t>In the general case a CDNI Metadata server makes each instance of
        an addressable CDNI Metadata object available via a unique URI and
        therefore in order to retrieve CDNI Metadata, a CDNI Metadata client
        first makes a HTTP GET request for the URI of the HostIndex which
        provides the CDNI Metadata client with a list of Hostnames for which
        the upstream CDN may delegate content delivery to the downstream
        CDN.</t>

        <t>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 in the HostMatch). If the HostMetadata
        is linked (rather than embedded), the CDNI metadata client then makes
        a GET request for the URI specified in the href property of the Link
        object which points to the HostMetadata object itself.</t>

        <t>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. If any PathMetadata
        match the request (and are linked rather than embedded), the CDNI
        metadata client makes another GET request for the PathMetadata. Each
        PathMetadata object may also include references to yet more specific
        metadata. If this is the case, the CDNI metadata client continues
        requesting PathMetadata recursively.</t>

        <t>Where a downstream CDN is interconnected with multiple upstream
        CDNs, the downstream CDN must decide which upstream CDN's CDNI
        metadata should be used to handle a particular User Agent request.</t>

        <t>When application level redirection (e.g. HTTP 302 redirects) is
        being used between CDNs, it is expected that the downstream CDN will
        be able to determine the upstream CDN that redirected a particular
        request from information contained in the received request (e.g. via
        the URI). With knowledge of which upstream CDN routed the request, the
        downstream CDN can choose the correct metadata server from which to
        obtain the HostIndex. Note that the HostIndex served by each uCDN may
        be unique.</t>

        <t>In the case of DNS redirection there is not always sufficient
        information carried in the DNS request from User Agents to determine
        the upstream CDN that redirected a particular request (e.g. when
        content from a given host is redirected to a given downstream CDN by
        more than one upstream CDN) and therefore downstream CDNs may have to
        apply local policy when deciding which upstream CDN's metadata to
        apply.</t>
      </section>

      <section title="Bootstrapping">
        <t>The URI for the HostIndex object of a given upstream CDN needs to
        be either discovered by or configured in the downstream CDN. All other
        objects/resources are then discoverable from the HostIndex object by
        following the links in the HostIndex object and the referenced
        HostMetadata and PathMetadata objects.</t>

        <t>If the URI for the HostIndex object is not manually configured in
        the downstream CDN then the HostIndex URI could be discovered. A
        mechanism allowing the downstream CDN to discover the URI of the
        HostIndex is outside the scope of this document.</t>
      </section>

      <section title="Encoding">
        <t>Object are resources that may be:</t>

        <t><list style="symbols">
            <t>Addressable, where the object is a resource that may be
            retrieved or referenced via its own URI.</t>

            <t>Embedded, where the object is contained (or inlined) within a
            property of an addressable object.</t>
          </list></t>

        <t>In the descriptions of objects we use the term "X contains Y" to
        mean either Y is directly embedded in X or that Y is linked to by X.
        It is generally a deployment choice for the uCDN implementation to
        decide when and which CDNI Metadata objects to embed and which are
        separately addressable.</t>

        <section anchor="media-types" title="MIME Media Types">
          <t>All MIME types are prefixed with "application/cdni." The MIME
          type for each object matches the type name of that object as defined
          by this document. The object type name is followed by ".v" and the version
          number of the object type (e.g. &ldquo;.v1&rdquo;). Finally, the encoding
          type "+json" is appended. <xref target="metadata-media-types-table"></xref>
          lists a few examples of the MIME Media Type for each object
          (resource) that is retrievable through the CDNI Metadata
          interface. </t>

          <texttable anchor="metadata-media-types-table"
                     title="Example MIME Media Types for CDNI Metadata objects">
            <ttcol>Data Object</ttcol>

            <ttcol>MIME Media Type</ttcol>

            <c>HostIndex</c>
            <c>application/cdni.HostIndex.v1+json</c>

            <c>HostMatch</c>
            <c>application/cdni.HostMatch.v1+json</c>

            <c>HostMetadata</c>
            <c>application/cdni.HostMetadata.v1+json</c>

            <c>PathMatch</c>
            <c>application/cdni.PathMatch.v1+json</c>

            <c>PathMetadata</c>
            <c>application/cdni.PathMetadata.v1+json</c>

            <c>Source</c>
            <c>application/cdni.Source.v1+json</c>

            <c>LocationACL</c>
            <c>application/cdni.LocationACL.v1+json</c>

            <c>LocationRule</c>
            <c>application/cdni.LocationRule.v1+json</c>
          </texttable>

          <t>See http://www.iana.org/assignments/media-types/index.html for
          reference.</t>
        </section>

        <section title="JSON Encoding of Objects">
          <t>CDNI Metadata objects are encoded as JSON objects containing a
          dictionary of (key,value) pairs where the keys are the property
          names and the values are the associated property values.</t>

          <t>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 MIME Media Type
          of the returned resource). Likewise, the values associated with each
          key are dependent on the specific object being encoded (i.e.
          dependent on the MIME Media Type of the returned resource).</t>

          <t>Dictionary keys in JSON are case sensitive and therefore by
          convention any dictionary key defined by this document (for example
          the names of CDNI Metadata object properties) MUST be represented in
          lowercase.</t>

          <t>In addition to the properties specific to each object type, the
          keys defined below may be present in any object.</t>

          <t><list style="empty">
              <t>Key: base<list style="empty">
                  <t>Description: Provides a prefix for any relative URLs in
                  the object. This is similar to the XML base tag <xref
                  target="XML-BASE"></xref>. If absent, all URLs in the
                  remainder of the document must be absolute URLs.</t>

                  <t>Type: URI</t>

                  <t>Mandatory: No</t>
                </list></t>
            </list></t>

          <t><list style="empty">
              <t>Key: _links<list style="empty">
                  <t>Description: The links of this object to other
                  addressable objects. Any property may be replaced by a link
                  to an object with the same type as the property it
                  replaces. The keys of the _links dictionary are the names of
                  the properties being replaced. The values of the dictionary are
                  Link objects with href set to the URI of the object and type
                  set to the MIME type of the object being replaced.</t>

                  <t>Type: Dictionary object of Link objects</t>

                  <t>Mandatory: Yes</t>
                </list></t>
            </list></t>

          <section title="JSON Example">
            <t>A downstream CDN may request the HostIndex and receive the
            following object of type "application/cdni.HostIndex.v1+json":</t>

            <t><figure>
                <artwork><![CDATA[{
  "hosts": [
    {
      "host": "video.example.com",
      "_links": {
        "host-metadata" : {
          "type": "application/cdni.HostMetadata.v1+json",
          "href": "http://metadata.example.ucdn.com/video"
        }
      }
    },
    {
      "host": "images.example.com",
      "_links": {
        "host-metadata" : {
          "type": "application/cdni.HostMetadata.v1+json",
          "href": "http://metadata.example.ucdn.com/images"
        }
      }
    }
  ]
}]]></artwork>
              </figure></t>

            <t>If the incoming request has a Host header with
            "video.example.com" then the downstream CDN would fetch the
            next metadata object from "http://metadata.ucdn.example.com/video"
            expecting a MIME type of "application/cdni.HostMetadata.v1+json":</t>

            <t><figure>
                <artwork><![CDATA[{
  "metadata": [
    {
      "type": "application/cdni.SourceMetadata.v1+json",
      "value": {
        "sources": [
          {
            "_links": {
              "auth": {
                "type": "application/cdni.Auth.v1+json",
                "href": "http://metadata.ucdn.example.com/auth1234"
              }
            },
            "endpoint": "acq1.ucdn.example.com",
            "protocol": "ftp"
          },
          {
            "_links": {
              "auth": {
                "type": "application/cdni.Auth.v1+json",
                "href": "http://metadata.ucdn.example.com/auth1234"
              }
            },
            "endpoint": "acq2.ucdn.example.com",
            "protocol": "http"
          }
        ]
      }
    },
    {
      "type": "application/cdni.LocationACL.v1+json",
      "value": {
        "locations": [
          {
            "locations": [
              { "iprange": "192.168.0.0/16" }
            ],
            "action": "deny"
          }
        ]
      }
    },
    {
      "type": "application/cdni.ProtocolACL.v1+json",
      "value": {
        "protocols": [
          {
            "protocols": [
              "ftp"
            ],
            "action": "deny"
          }
        ]
      }
    }
  ],
  "paths": [
    {
      "path-pattern": {
        "pattern": "/videos/trailers/*"
      },
      "_links": {
        "path-metadata": {
          "type": "application/cdni.PathMetadata.v1+json",
          "href": "http://metadata.ucdn.example.com/videos/trailers"
        }
      }
    },
    {
      "path-pattern": {
        "pattern": "/videos/movies/*"
      },
      "_links": {
        "pathmetadata": {
          "type": "application/cdni.PathMetadata.v1+json",
          "href": "http://metadata.ucdn.example.com/videos/movies"
        }
      }
    }
  ]
}]]></artwork>
              </figure></t>

            <t>Suppose the path of the requested resource matches the
            "/video/movies/*" pattern, the next metadata requested would be
            for "http://metadata.ucdn.example.com/video/movies" with an
            expected type of "application/cdni.PathMetadata.v1+json":</t>

            <t><figure>
                <artwork><![CDATA[{
  "metadata": [],
  "paths": [
    {
      "path-pattern": {
        "pattern": "/videos/movies/hd/*"
      },
      "_links": {
        "pathmetadata": {
          "type": "application/cdni.PathMetadata.v1+json",
          "href": "http://metadata.ucdn.example.com/videos/movies/hd"
        }
      }
    }
  ]
}]]></artwork>
              </figure></t>

            <t>Finally, if the path of the requested resource also matches the
            "/videos/movies/hd/*" pattern, the downstream CDN would also fetch
            the following object from
            "http://metadata.ucdn.example.com/videos/movies/hd" with MIME type
            "application/cdni.PathMetadata.v1+json":</t>

            <t><figure>
                <artwork><![CDATA[{
  "metadata": [
    {
      "type": "application/cdni.TimeWindowACL.v1+json",
      "value": {
        "times": [
          "times": [
            {
              "start": "1213948800",
              "end": "1327393200"
            }
          ],
          "type": "allow"
        ]
      }
    }
  ]
}]]></artwork>
              </figure></t>
          </section>
        </section>
      </section>

      <section anchor="extensibility" title="Extensibility">
        <t>The set of property Metadata may be extended with proprietary
        and/or custom property Metadata. The GenericMetadata object defined in
        <xref target="generic-metadata"></xref> allows any Metadata property
        to be included in either the HostMetadata or PathMetadata lists.</t>

        <t>Note: Identification of the property Metadata defining organization
        in the property Metadata type decreases the possibility of property
        Metadata type collision. The fully-qualified domain name of the
        organization in reverse order may be used for this purpose.</t>

        <section title="Metadata Enforcement">
          <t>At any given time, the set of property Metadata supported by the
          uCDN may not match the set of property Metadata supported by the
          dCDN. The uCDN may or may not know which property Metadata the dCDN
          supports. In cases where the uCDN supports Metadata that the dCDN
          does not, the dCDN MUST be aware of any Metadata marked as
          "mandatory-to-enforce". If a CDN does not understand or is unable to
          perform the functions associated with any "mandatory-to-enforce"
          Metadata, the CDN MUST NOT service any requests for the
          corresponding content.</t>

          <t>Any standard which defines a new GenericMetadata Type MUST also
          define whether or not the new metadata is mandatory-to-enforce.</t>

          <t>Note: Ideally, uCDNs would not delegate content requests to a
          dCDN which 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 CDNI capabilities interface or through out-of-band
          negotiation between CDN operators) Metadata support may fluctuate or
          be inconsistent (e.g., due to mis-communication, mis-configuration,
          or temporary outage). Thus, the dCDN MUST evaluate all Metadata
          associated with content requests and reject any requests where
          "mandatory-to-enforce" Metadata associated with the content cannot
          be enforced.</t>
        </section>

        <section title="Metadata Override">
          <t>It is possible that new Metadata definitions may obsolete or
          override existing property Metadata (e.g., a future revision of the
          CDNI Metadata interface may redefine the Auth Metadata or a custom
          vendor extension may implement an alternate Auth Metadata option).
          If multiple Metadata (e.g., cdni.v2.Auth, vendor1.Auth, and
          vendor2.Auth) all override an existing Metadata (e.g., cdni.Auth)
          and all are marked as "mandatory-to-enforce", it may be ambiguous
          which Metadata should be applied, especially if the functionality of
          the Metadata conflict.</t>

          <t>As described in <xref target="metadata-inheritance"></xref>,
          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 Metadata types. It is the responsibility of the
          CSP and the CDN operators to ensure that Metadata assigned to a
          given content do not conflict.</t>

          <t>Note: Because Metadata is inherently ordered in GenericMetadata
          lists, as well as in the PathMetadata hierarchy and PathMatch lists,
          multiple conflicting Metadata types MAY be used, however, Metadata
          hierarchies MUST ensure that independent PathMatch root objects are
          used to prevent ambiguous or conflicting Metadata definitions.</t>
        </section>
      </section>

      <section title="Versioning">
        <t>The version of CDNI Metadata Structural objects is specified by the
        HTTP Content-Type header. Upon responding to a request for an object,
        a metadata server MUST include a Content-Type header with the
        MIME-type and version number of the object. HTTP requests sent to a
        metadata server SHOULD include an Accept header with the MIME-type and
        version of the expected object. Unless stated otherwise, the version
        of each object defined by this document is version 1. For example:
        "Content-Type: application/cdni.HostIndex.v1+json".</t>

        <t>GenericMetadata objects include a "type" property which specifies
        the MIME-type of the GenericMetadata value. This MIME-type should also
        include a version. Any document which defines a new type of
        GenericMetadata should specify the version number which it describes.
        For example: "application/cdni.Location.v1+json".</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests the registration of the prefix "application/cdni"
      MIME Media Type under the IANA MIME Media Type registry
      (http://www.iana.org/assignments/media-types/index.html).</t>

      <section title="GenericMetadata Type Registry">
        <t>CDNI Metadata is distributed as a list of GenericMetadata objects
        which specify a type field and a type-specific value field, as
        described in <xref target="generic-metadata"></xref>. In order to
        prevent namespace collisions for GenericMetadata object types a new
        IANA registry is requested for "CDNI GenericMetadata Types" namespace.
        The namespace shall be split into two partitions: standard and vendor
        defined.</t>

        <t>The standard namespace partition is intended to contain mandatory
        to implement capabilities and MUST conform to the "IETF Review" policy
        as defined in <xref target="RFC5226"></xref>. The registry SHALL
        contain the generic metadata type name, the RFC number of the
        specification defining the metadata type, the version number of the
        GenericMetadata set to which the standard capability applies, and
        boolean values indicating whether or not the new type is considered
        mandatory-to-enforce or safe-to-redistribute (as defined in <xref
        target="generic-metadata"></xref>).</t>

        <t>The following table defines the initial values for the standard
        partition:</t>

        <texttable>
          <ttcol align="left">Type name</ttcol>

          <ttcol align="left">Specification</ttcol>

          <ttcol align="left">Version</ttcol>

          <ttcol align="left">MTE</ttcol>

          <ttcol align="left">STR</ttcol>

          <c>SourceMetadata</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>

          <c>LocationACL</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>

          <c>TimeWindowACL</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>

          <c>ProtocolACL</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>

          <c>Auth</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>

          <c>Cache</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>

          <c>Grouping</c>

          <c>RFCthis</c>

          <c>1</c>

          <c>true</c>

          <c>true</c>
        </texttable>

        <t>The initial MI version number is set to 1. All of the initial
        GenericMetadata types are considered mandatory to implement for
        version 1. The version field should be incremented when new
        GenericMetadata type sets are added to the registry.</t>

        <t>The "vendor defined" namespace partition SHOULD conform to the
        "Expert Review" policy as defined in <xref target="RFC5226"></xref>.
        The expert review is intended to prevent namespace hoarding and to
        prevent the definition of redundant GenericMetadata types. Vendors
        defining new GenericMetadata types which conflict with existing
        GenericMetadata types SHOULD follow the guidelines for the
        "Specification Required" policy as defined in <xref
        target="RFC5226"></xref>. The Version field in the registry MUST be
        set to "-1" (negative one) for non-standard GenericMetadata types.</t>

        <t>As with the initial GenericMetadata types defined in <xref
        target="property-objects"></xref>, future GenericMetadata type
        registrations SHOULD specify the information necessary for
        constructing and decoding the GenericMetadata object. This information
        SHOULD include the list of properties contained within the
        GenericMetadata object, and for each property, the specification
        should include a description, a type, and whether or not the given
        property is mandatory to specify.</t>

        <t>Any document which defines a new GenericMetadata type MUST:<list
            style="numbers">
            <t>Allocate a new type in the <xref target="IANA">GenericMetadata
            Type Registry</xref>.</t>

            <t>Define the set of properties associated with the new type.</t>

            <t>For each property, define a name, description, type, and
            whether or not the property is mandatory-to-specify.</t>

            <t>Specify whether or not the new type is mandatory-to-enforce (vs
            optional-to-enforce).</t>

            <t>Describe the semantics of the new type including its purpose
            and example of a use case to which it applies.</t>
          </list></t>


        <section title="GenericMetadata Sub-Registries">
          <t>Some of the initial standard GenericMetadata objects contain
          enumerated types which require registration (i.e., LocationACL
          footprint types, ProtocolACL protocols, and Auth protocols). The
          following sections define the initial values for these
          GenericMetadata type sub-registries.</t>

          <section anchor="FootprintReg" title="Footprint Sub-Registry">
            <t>The "CDNI Metadata Footprint Types" namespace defines the valid
            Footprint object type values used by the Footprint object in <xref
            target="Footprint"></xref>. Additions to the Footprint type
            namespace MUST conform to the "Expert Review" policy as defined in
            <xref target="RFC5226"></xref>. The expert review should verify
            that new type definitions do not duplicate existing type
            definitions and prevent gratuitous additions to the namespace.</t>

            <t>The following table defines the initial Footprint type
            values:</t>

            <texttable>
              <ttcol align="left">Type name</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="left">Specification</ttcol>

              <c>IPv4</c>

              <c>Single IPv4 address</c>

              <c>RFCthis</c>

              <c>IPv6</c>

              <c>Single IPv6 address</c>

              <c>RFCthis</c>

              <c>IPv4Range</c>

              <c>List of contiguous IPv4 addresses denoted by a start address
              and an end address separated by a dash (e.g.,
              192.168.0.1-192.168.0.20), inclusive.</c>

              <c>RFCthis</c>

              <c>IPv6Range</c>

              <c>List of contiguous IPv6 addresses denoted by a start address
              and an end address separated by a dash (e.g.,
              fc80::0001-fc80::0014), inclusive.</c>

              <c>RFCthis</c>

              <c>IPv4CIDR</c>

              <c>IPv4 address block using slash prefix length notation (e.g.,
              192.168.0.16/28).</c>

              <c>RFCthis</c>

              <c>IPv6CIDR</c>

              <c>IPv6 address block using slash prefix length notation (e.g.,
              fc80::0010/124).</c>

              <c>RFCthis</c>

              <c>ASN</c>

              <c>Autonomous System (AS) Number</c>

              <c>RFCthis</c>

              <c>CountryCode</c>

              <c>ISO 3166-1 alpha-2 code</c>

              <c>RFCthis</c>

              <c>DVDRegion</c>

              <c>DVD Region code (i.e., integer in the range 0-6).</c>

              <c>RFCthis</c>
            </texttable>
          </section>

          <section anchor="ProtocolReg" title="Protocol Sub-Registry">
            <t>The "CDNI Metadata Protocols" namespace defines the valid
            Protocol object values in <xref target="Protocol"></xref>, used by
            the SourceMetadata and ProtocolACL objects. Additions to the
            Protocol namespace MUST conform to the "Expert Review" policy as
            defined in <xref target="RFC5226"></xref>. The expert review
            should verify that new type definitions do not duplicate existing
            type definitions and prevent gratuitous additions to the
            namespace.</t>

            <t>The following table defines the initial Protocol values:</t>

            <texttable>
              <ttcol align="left">Protocol</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="left">Specification</ttcol>

              <c>HTTP</c>

              <c>Hypertext Transfer Protocol -- HTTP/1.1</c>

              <c>RFC2616</c>

              <c>HTTPS</c>

              <c>HTTP Over TLS</c>

              <c>RFC2818</c>

              <c>RTSP</c>

              <c>Real Time Streaming Protocol</c>

              <c>RFC2326</c>

              <c>RTMP</c>

              <c>Real-Time Messaging Protocol</c>

              <c>http://www.adobe.com/devnet/rtmp.html</c>

              <c>FTP</c>

              <c>FILE TRANSFER PROTOCOL</c>

              <c>RFC959</c>

              <c>SFTP</c>

              <c>SSH File Transfer Protocol</c>

              <c>N/A</c>

              <c>SCP</c>

              <c>Secure Copy</c>

              <c>N/A</c>

              <c>fasp</c>

              <c>Aspera fast, adaptive, secure protocol</c>

              <c>N/A</c>
            </texttable>
          </section>

          <section anchor="AuthReg" title="Authentication Sub-Registry">
            <t>The "CDNI Metadata Auth" namespace defines the valid Auth
            object types used by the Auth object in <xref
            target="Auth"></xref>. Additions to the Auth namespace MUST
            conform to the "Expert Review" policy as defined in <xref
            target="RFC5226"></xref>. The expert review should verify that new
            type definitions do not duplicate existing type definitions and
            prevent gratuitous additions to the namespace.</t>

            <t>The following table defines the initial Auth type values:</t>

            <texttable>
              <ttcol align="left">Type name</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="left">Specification</ttcol>

              <c>credentials</c>

              <c>Simple username and password authentication as defined by
              <xref target="CredentialsAuth"></xref>.</c>

              <c>RFCthis</c>
            </texttable>
          </section>
        </section>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The CDNI Metadata Interface is expected to be secured as a function
      of the transport protocol (e.g. <xref target="RFC2617">HTTP
      authentication</xref>, <xref target="RFC2818">HTTPS</xref>, or
      inter-domain IPSec).</t>

      <t>If a malicious metadata server is contacted by a downstream CDN, the
      malicious server may provide metadata to the downstream CDN which denies
      service for any piece of content to any user agent. The malicious server
      may also provide metadata which directs a downstream CDN to a malicious
      origin server instead of the actual origin server. The dCDN is expected
      to authenticate the server to prevent this situation (e.g. by using
      HTTPS and validating the server's certificate).</t>

      <t>A malicious metadata client could request metadata for a piece of
      content from an upstream CDN. The metadata information may then be used
      to glean information regarding the uCDN or to contact an upstream origin
      server. The uCDN is expected to authenticate client requests to prevent
      this situation.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank David Ferguson and Francois le
      Faucheur for their valuable comments and input to this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>

      <?rfc include="reference.RFC.2617" ?>

      <?rfc include="reference.RFC.5226" ?>

      <?rfc include="reference.RFC.4291" ?>

      <?rfc include="reference.RFC.2818" ?>

      <?rfc include="reference.RFC.5952" ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-cdni-requirements"?>

      <?rfc include="reference.I-D.ietf-cdni-framework"?>

      <?rfc include="reference.RFC.6707" ?>

      <?rfc include="reference.RFC.3986" ?>

      <reference anchor="XML-BASE">
        <front>
          <title>XML Base (Second Edition) -
          http://www.w3.org/TR/xmlbase/</title>

          <author fullname="Jonathan" initials="J" role="editor"
                  surname="Marsh">
            <organization></organization>
          </author>

          <author fullname="Richard" initials="R" role="editor"
                  surname="Tobin">
            <organization></organization>

            <address>
              <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date day="28" month="January" year="2009" />
        </front>
      </reference>
    </references>

    <section title="Relationship to the CDNI Requirements">
      <t>Section 6 of <xref target="I-D.ietf-cdni-requirements"></xref> lists
      the requirements for the CDNI Metadata Distribution interface. This
      section outlines which of those requirements are met by the CDNI
      Metadata interface specified in this document.</t>

      <t>All metadata requirements are met either directly or indirectly by
      the CDNI Metadata Interface described in this document, with the
      clarifications or exceptions described in the following paragraphs.</t>

      <t>Requirements related to pre-positioning of metadata are met by this
      document on the assumption that other CDNI Interfaces are to be used by
      the upstream CDN to trigger the pre-positioning of metadata by the
      downstream CDN via the CDNI Metadata Interface. Triggering metadata
      pre-positioning is beyond the scope of the CDNI Metadata interface.
      However, the interface as described by this document supports pulling
      metadata on-demand for the purpose of pre-positioning.</t>

      <t>Requirement META-7 relating to modification of metadata by the
      upstream CDN is met both by allowing timeouts on the cacheability of
      metadata objects and by allowing other CDNI interfaces to initiate a
      refetch or purge of metadata.</t>

      <t>Requirement META-18 relating to surrogate cache behavior parameters
      is supported via extensibility. However, the example parameters in
      META-18 are not described in this document.</t>
    </section>
  </back>
</rfc>
