tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 8006

 
 
 

Content Delivery Network Interconnection (CDNI) Metadata

Part 2 of 3, p. 15 to 43
Prev Section       Next Section

 


prevText      Top      ToC       Page 15 
4.  CDNI Metadata Objects

   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.

   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.

   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.

   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

Top      Up      ToC       Page 16 
   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.

   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.

4.1.  Definitions of the CDNI Structural Metadata Objects

   The subsections below describe the structural objects introduced in
   Section 3.1.

4.1.1.  HostIndex

   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.

      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.

         Type: Array of HostMatch objects

         Mandatory-to-Specify: Yes.

Top      Up      ToC       Page 17 
   Example HostIndex object containing two HostMatch objects, where the
   first HostMatch object is embedded and the second HostMatch object is
   referenced:

   {
     "hosts": [
       {
         <Properties of embedded HostMatch object>
       },
       {
         "type": "MI.HostMatch",
         "href": "https://metadata.ucdn.example/hostmatch1234"
       }
     ]
   }

4.1.2.  HostMatch

   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.

      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].

         Type: Endpoint

         Mandatory-to-Specify: Yes.

Top      Up      ToC       Page 18 
      Property: host-metadata

         Description: CDNI Metadata to apply when delivering content
         that matches this host.

         Type: HostMetadata

         Mandatory-to-Specify: Yes.

   Example HostMatch object with an embedded HostMetadata object:

   {
     "host": "video.example.com",
     "host-metadata": {
       <Properties of embedded HostMetadata object>
     }
   }

   Example HostMatch object referencing (via a Link object; see
   Section 4.3.1) a HostMetadata object:

   {
     "host": "video.example.com",
     "host-metadata": {
       "type": "MI.HostMetadata",
       "href": "https://metadata.ucdn.example/host1234"
     }
   }

4.1.3.  HostMetadata

   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.

      Property: metadata

         Description: Array of host-related metadata.

         Type: Array of GenericMetadata objects

         Mandatory-to-Specify: Yes.

Top      Up      ToC       Page 19 
      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.

         Type: Array of PathMatch objects

         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:

   {
     "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>
       }
     ]
   }

4.1.4.  PathMatch

   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.

Top      Up      ToC       Page 20 
      Property: path-pattern

         Description: Pattern to match against the requested
         resource's URI.

         Type: PatternMatch

         Mandatory-to-Specify: Yes.

      Property: path-metadata

         Description: CDNI Metadata to apply when delivering content
         that matches the associated PatternMatch.

         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):

   {
     "path-pattern": {
       "pattern": "/movies/*",
       "case-sensitive": true
     },
     "path-metadata": {
         "type": "MI.PathMetadata",
         "href": "https://metadata.ucdn.example/host1234/pathDCE"
     }
   }

4.1.5.  PatternMatch

   A PatternMatch object contains the pattern string and flags that
   describe the pattern expression.

      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.

Top      Up      ToC       Page 21 
         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].

         Type: Boolean

         Mandatory-to-Specify: No.  Default is case-insensitive match
         (i.e., a value of False).

   Example PatternMatch object that matches the case-sensitive URI path
   pattern "/movies/*":

   {
     "pattern": "/movies/*",
     "case-sensitive": true
   }

4.1.6.  PathMetadata

   A PathMetadata object contains the CDNI Metadata properties for
   content requests that match against the associated URI path (defined
   in a PathMatch object).

   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.

      Property: metadata

         Description: Array of path-related metadata.

         Type: Array of GenericMetadata objects

         Mandatory-to-Specify: Yes.

Top      Up      ToC       Page 22 
      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.

         Type: Array of PathMatch objects

         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.

   {
     "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>
       }
     ]
   }

Top      Up      ToC       Page 23 
4.1.7.  GenericMetadata

   A GenericMetadata object is a wrapper for managing individual CDNI
   Metadata properties in an opaque manner.

      Property: generic-metadata-type

         Description: Case-insensitive CDNI Metadata object type.

         Type: String containing the CDNI Payload Type [RFC7736] of the
         object contained in the generic-metadata-value property (see
         Table 4).

         Mandatory-to-Specify: Yes.

      Property: generic-metadata-value

         Description: CDNI Metadata object.

         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).

         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).

      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).

Top      Up      ToC       Page 24 
      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.

         Type: Boolean

         Mandatory-to-Specify: No.  Default is comprehensible (i.e., a
         value of 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):

 {
   "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>
     }
 }

4.2.  Definitions of the Initial Set of CDNI GenericMetadata Objects

   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.2.1.  SourceMetadata

   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.

      Property: sources

         Description: Sources from which the dCDN can acquire content,
         listed in order of preference.

Top      Up      ToC       Page 25 
         Type: Array of Source objects (see Section 4.2.1.1)

         Mandatory-to-Specify: No.  Default is to use static
         configuration, out-of-band from the CDNI Metadata interface.

   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:

   {
     "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"
           }
         ]
       }
   }

4.2.1.1.  Source

   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.

   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).

      Property: acquisition-auth

         Description: Authentication method to use when requesting
         content from this source.

Top      Up      ToC       Page 26 
         Type: Auth (see Section 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.

         Type: Array of Endpoint objects (see Section 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)

         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:

   {
     "endpoints": [
       "a.service123.ucdn.example",
       "b.service123.ucdn.example"
     ],
     "protocol": "http/1.1"
   }

4.2.2.  LocationACL Metadata

   LocationACL metadata defines which locations a User Agent needs to be
   in, in order to be able to receive the associated content.

   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

Top      Up      ToC       Page 27 
   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".

   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.

      Property: locations

         Description: ACL that allows or denies (blocks) delivery based
         on the User Agent's location.

         Type: Array of LocationRule objects (see Section 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:

   {
     "generic-metadata-type": "MI.LocationACL",
     "generic-metadata-value":
       {
       }
   }

Top      Up      ToC       Page 28 
   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"]
               }
             ]
           }
         ]
       }
   }

4.2.2.1.  LocationRule

   A LocationRule contains or references an array of Footprint objects
   and the corresponding action.

      Property: footprints

         Description: Array of footprints to which the rule applies.

         Type: Array of Footprint objects (see Section 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".

Top      Up      ToC       Page 29 
   Example LocationRule object (which contains a Footprint object) that
   allows the dCDN to deliver content to clients in the USA:

   {
     "action": "allow",
     "footprints": [
       {
         "footprint-type": "countrycode",
         "footprint-value": ["us"]
       }
     ]
   }

4.2.2.2.  Footprint

   A Footprint object describes the footprint to which a LocationRule
   can be applied, e.g., an IPv4 address range or a geographic location.

      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).

         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).

         Type: Array of footprints

         Mandatory-to-Specify: Yes.

Top      Up      ToC       Page 30 
   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:

   {
     "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:

   {
     "footprint-type": "ipv6cidr",
     "footprint-value": ["2001:db8::/32"]
   }

   Example Footprint object describing a footprint covering the
   autonomous system 64496:

   {
     "footprint-type": "asn",
     "footprint-value": ["as64496"]
   }

4.2.3.  TimeWindowACL

   TimeWindowACL metadata defines time-based restrictions.

   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".

   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.,

Top      Up      ToC       Page 31 
   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.

      Property: times

         Description: ACL that allows or denies (blocks) delivery based
         on the time of a User Agent's request.

         Type: Array of TimeWindowRule objects (see Section 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:

   {
     "generic-metadata-type": "MI.TimeWindowACL",
     "generic-metadata-value":
       {
         "times": [
           {
             "action": "allow",
             "windows": [
               {
                 "start": 946717200,
                 "end": 946746000
               }
             ]
           }
         ]
       }
   }

4.2.3.1.  TimeWindowRule

   A TimeWindowRule contains or references an array of TimeWindow
   objects and the corresponding action.

      Property: windows

         Description: Array of time windows to which the rule applies.

         Type: Array of TimeWindow objects (see Section 4.2.3.2)

Top      Up      ToC       Page 32 
         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:

   {
     "action": "allow",
     "windows": [
       {
         "start": 946717200,
         "end": 946746000
       }
     ]
   }

4.2.3.2.  TimeWindow

   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).

      Property: start

         Description: The start time of the window.

         Type: Time (see Section 4.3.4)

         Mandatory-to-Specify: Yes.

      Property: end

         Description: The end time of the window.

         Type: Time (see Section 4.3.4)

         Mandatory-to-Specify: Yes.

Top      Up      ToC       Page 33 
   Example TimeWindow object that describes a time window from 09:00
   01/01/2000 UTC to 17:00 01/01/2000 UTC:

   {
     "start": 946717200,
     "end": 946746000
   }

4.2.4.  ProtocolACL Metadata

   ProtocolACL metadata defines delivery protocol restrictions.

   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".

   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.

      Property: protocol-acl

         Description: ACL that allows or denies (blocks) delivery based
         on delivery protocol.

         Type: Array of ProtocolRule objects (see Section 4.2.4.1)

         Mandatory-to-Specify: No.  Default is to allow all protocols.

Top      Up      ToC       Page 34 
   Example ProtocolACL object (which contains a ProtocolRule object)
   that only allows the dCDN to deliver content using HTTP/1.1:

   {
     "generic-metadata-type": "MI.ProtocolACL",
     "generic-metadata-value":
       {
         "protocol-acl": [
           {
             "action": "allow",
             "protocols": ["http/1.1"]
           }
         ]
       }
   }

4.2.4.1.  ProtocolRule

   A ProtocolRule contains or references an array of Protocol objects
   and the corresponding action.

      Property: protocols

         Description: Array of protocols to which the rule applies.

         Type: Array of Protocol objects (see Section 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:

   {
     "action": "allow",
     "protocols": ["http/1.1"]
   }

Top      Up      ToC       Page 35 
4.2.5.  DeliveryAuthorization Metadata

   Delivery authorization defines authorization methods for the delivery
   of content to User Agents.

      Property: delivery-auth-methods

         Description: Options for authorizing content requests.
         Delivery for a content request is authorized if any one of the
         authorization methods in the list is satisfied for that
         request.

         Type: Array of Auth objects (see Section 4.2.7)

         Mandatory-to-Specify: No.  Default is no authorization
         required.

   Example DeliveryAuthorization object (which contains an Auth object):

   {
     "generic-metadata-type": "MI.DeliveryAuthorization",
     "generic-metadata-value":
       {
         "delivery-auth-methods": [
           {
             "auth-type": <CDNI Payload Type of this Auth object>,
             "auth-value":
             {
               <Properties of this Auth object>
             }
           }
         ]
       }
   }

4.2.6.  Cache

   A Cache object describes the cache control parameters to be applied
   to the content by intermediate caches.

   Cache keys are generated from the URI of the content request
   [RFC7234].  In some cases, a CDN or content provider might want
   certain path segments or query parameters to be excluded from the
   cache key generation.  The Cache object provides guidance on what
   parts of the path and query string to include.

Top      Up      ToC       Page 36 
      Property: exclude-path-pattern

         Description: A pattern for matching against the URI path, i.e.,
         against the path-absolute [RFC3986].  The pattern can contain
         the wildcards "*" and "?", where "*" matches any sequence of
         pchar [RFC3986] or "/" characters (including the empty string)
         and "?" matches exactly one pchar character.  The three
         literals "$", "*", and "?"  MUST be escaped as "$$", "$*", and
         "$?" (where "$" is the designated escape character).  All other
         characters are treated as literals.  Cache key generation MUST
         only include the portion of the path-absolute that matches the
         wildcard portions of the pattern.  Note: Inconsistency between
         the PatternMatch pattern (Section 4.1.5) and the
         exclude-path-pattern can result in inefficient caching.

         Type: String

         Mandatory-to-Specify: No.  Default is to use the full URI
         path-absolute to generate the cache key.

      Property: include-query-strings

         Description: Allows a Surrogate to specify the URI query string
         parameters [RFC3986] to include when comparing the requested
         URI against the URIs in its cache for equivalence.  Matching
         query parameters MUST be case insensitive.  If all query
         parameters should be ignored, then the list MUST be specified
         and MUST be empty.  If a query parameter appears multiple times
         in the query string, each instance value MUST be aggregated
         prior to comparison.  For consistent cache key generation,
         query parameters SHOULD be evaluated in the order specified in
         this array.

         Type: Array of strings

         Mandatory-to-Specify: No.  Default is to consider all query
         string parameters when comparing URIs.

   Example Cache object that instructs the dCDN to use the full URI path
   and ignore all query parameters:

   {
     "generic-metadata-type": "MI.Cache",
     "generic-metadata-value":
     {
       "include-query-strings": []
     }
   }

Top      Up      ToC       Page 37 
   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:

   {
     "generic-metadata-type": "MI.Cache",
     "generic-metadata-value":
     {
       "exclude-path-pattern": "/CDNX/*"
     }
   }

4.2.7.  Auth

   An Auth object defines authentication and authorization methods to be
   used during content acquisition and content delivery, respectively.

   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.

      Property: auth-type

         Description: Auth type (The CDNI Payload Type [RFC7736] of the
         GenericMetadata object contained in the auth-value property).

         Type: String

         Mandatory-to-Specify: Yes.

      Property: auth-value

         Description: An object conforming to the specification
         associated with the Auth type.

Top      Up      ToC       Page 38 
         Type: GenericMetadata object

         Mandatory-to-Specify: Yes.

   Example Auth object:

   {
     "generic-metadata-type": "MI.Auth",
     "generic-metadata-value":
     {
       "auth-type": <CDNI Payload Type of this Auth object>,
       "auth-value":
         {
           <Properties of this Auth object>
         }
     }
   }

4.2.8.  Grouping

   A Grouping object identifies a group of content to which a given
   asset belongs.

      Property: ccid

         Description: Content Collection IDentifier for an application-
         specific purpose such as logging aggregation.

         Type: String

         Mandatory-to-Specify: No.  Default is not to apply any
         grouping.

   Example Grouping object that specifies a Content Collection
   IDentifier for the content associated with the Grouping object's
   parent HostMetadata and PathMetadata:

   {
     "generic-metadata-type": "MI.Grouping",
     "generic-metadata-value":
     {
       "ccid": "ABCD"
     }
   }

Top      Up      ToC       Page 39 
4.3.  CDNI Metadata Simple Data Type Descriptions

   This section describes the simple data types that are used for
   properties of CDNI Metadata objects.

4.3.1.  Link

   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.

   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.

      Property: href

         Description: The URI of the addressable object being
         referenced.

         Type: String

         Mandatory-to-Specify: Yes.

      Property: type

         Description: The CDNI Payload Type of the object being
         referenced.

         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.

   Example Link object referencing a HostMatch object:

   {
     "type": "MI.HostMatch",
     "href": "https://metadata.ucdn.example/hostmatch1234"
   }

Top      Up      ToC       Page 40 
   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"
       }
     ]
   }

4.3.1.1.  Link Loop Prevention

   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.

4.3.2.  Protocol

   Protocol objects are used to specify protocols (from the "CDNI
   Metadata Protocol Types" registry; see Section 7.3) for content
   acquisition or delivery.

   Type: String

   Example:

   "http/1.1"

4.3.3.  Endpoint

   A hostname (with optional port) or an IP address (with optional
   port).

   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

Top      Up      ToC       Page 41 
   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].

   Type: String

   Example hostname:

   "metadata.ucdn.example"

   Example IPv4 address:

   "192.0.2.1"

   Example IPv6 address (with port number):

   "[2001:db8::1]:81"

4.3.4.  Time

   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].

   Type: Integer

   Example time representing 09:00:00 01/01/2000 UTC:

   946717200

4.3.5.  IPv4CIDR

   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.

   Type: String

   Example IPv4CIDR:

   "192.0.2.0/24"

Top      Up      ToC       Page 42 
4.3.6.  IPv6CIDR

   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.

   Type: String

   Example IPv6CIDR:

   "2001:db8::/32"

4.3.7.  ASN

   An ASN value encoded as a string consisting of the characters "as"
   (in lowercase) followed by the ASN [RFC6793].

   Type: String

   Example ASN:

   "as64496"

4.3.8.  Country Code

   An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase.

   Type: String

   Example Country Code representing the USA:

   "us"

5.  CDNI Metadata Capabilities

   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

Top      Up      ToC       Page 43 
   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.

   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.



(page 43 continued on part 3)

Next Section