RFC 8007
Content Delivery Network Interconnection (CDNI) Control Interface / Triggers
6. Examples
The following subsections provide examples of different CI/T objects encoded as JSON. Discovery of the CI/T interface is out of scope for this document. In an implementation, all CI/T URLs are under the control of the dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual elements of the path. In examples in this section, the URL "https://dcdn.example.com/ triggers" is used as the location of the collection of all Trigger Status Resources, and the CDN PID of the uCDN is "AS64496:1".
6.1. Creating Triggers
Examples of the uCDN triggering activity in the dCDN:6.1.1. Preposition
Below is an example of a CI/T "preposition" command -- a POST to the collection of all Trigger Status Resources. Note that "metadata.patterns" and "content.patterns" are not allowed in a pre-position Trigger Specification. REQUEST: POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 352 { "trigger": { "type": "preposition", "metadata.urls": [ "https://metadata.example.com/a/b/c" ], "content.urls": [ "https://www.example.com/a/b/c/1", "https://www.example.com/a/b/c/2", "https://www.example.com/a/b/c/3", "https://www.example.com/a/b/c/4" ] }, "cdn-path": [ "AS64496:1" ] }
RESPONSE:
HTTP/1.1 201 Created
Date: Wed, 04 May 2016 08:48:10 GMT
Content-Length: 467
Content-Type: application/cdni; ptype=ci-trigger-status
Location: https://dcdn.example.com/triggers/0
Server: example-server/0.1
{
"ctime": 1462351690,
"etime": 1462351698,
"mtime": 1462351690,
"status": "pending",
"trigger": {
"content.urls": [
"https://www.example.com/a/b/c/1",
"https://www.example.com/a/b/c/2",
"https://www.example.com/a/b/c/3",
"https://www.example.com/a/b/c/4"
],
"metadata.urls": [
"https://metadata.example.com/a/b/c"
],
"type": "preposition"
}
}
6.1.2. Invalidate
Below is an example of a CI/T "invalidate" command -- another POST to the collection of all Trigger Status Resources. This instructs the dCDN to revalidate the content at "https://www.example.com/a/ index.html", as well as any metadata and content whose URLs are prefixed by "https://metadata.example.com/a/b/" using case-insensitive matching, and "https://www.example.com/a/b/" using case-sensitive matching, respectively. REQUEST: POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 387 { "trigger": { "type": "invalidate", "metadata.patterns": [ { "pattern": "https://metadata.example.com/a/b/*" } ], "content.urls": [ "https://www.example.com/a/index.html" ], "content.patterns": [ { "pattern": "https://www.example.com/a/b/*", "case-sensitive": true } ] }, "cdn-path": [ "AS64496:1" ] }
RESPONSE:
HTTP/1.1 201 Created
Date: Wed, 04 May 2016 08:48:11 GMT
Content-Length: 545
Content-Type: application/cdni; ptype=ci-trigger-status
Location: https://dcdn.example.com/triggers/1
Server: example-server/0.1
{
"ctime": 1462351691,
"etime": 1462351699,
"mtime": 1462351691,
"status": "pending",
"trigger": {
"content.patterns": [
{
"case-sensitive": true,
"pattern": "https://www.example.com/a/b/*"
}
],
"content.urls": [
"https://www.example.com/a/index.html"
],
"metadata.patterns": [
{
"pattern": "https://metadata.example.com/a/b/*"
}
],
"type": "invalidate"
}
}
6.2. Examining Trigger Status
Once Trigger Status Resources have been created, the uCDN can check their status as shown in the following examples.6.2.1. Collection of All Triggers
The uCDN can fetch the collection of all Trigger Status Resources it has created that have not yet been deleted or removed as expired. After creation of the "preposition" and "invalidate" triggers shown above, this collection might look as follows: REQUEST: GET /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* RESPONSE: HTTP/1.1 200 OK Content-Length: 341 Expires: Wed, 04 May 2016 08:49:11 GMT Server: example-server/0.1 ETag: "-936094426920308378" Cache-Control: max-age=60 Date: Wed, 04 May 2016 08:48:11 GMT Content-Type: application/cdni; ptype=ci-trigger-collection { "cdn-id": "AS64496:0", "coll-active": "/triggers/active", "coll-complete": "/triggers/complete", "coll-failed": "/triggers/failed", "coll-pending": "/triggers/pending", "staleresourcetime": 86400, "triggers": [ "https://dcdn.example.com/triggers/0", "https://dcdn.example.com/triggers/1" ] }
6.2.2. Filtered Collections of Trigger Status Resources
The filtered collections are also available to the uCDN. Before the dCDN starts processing the two CI/T Trigger Commands shown above, both will appear in the collection of pending triggers. For example: REQUEST: GET /triggers/pending HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* RESPONSE: HTTP/1.1 200 OK Content-Length: 152 Expires: Wed, 04 May 2016 08:49:11 GMT Server: example-server/0.1 ETag: "4331492443626270781" Cache-Control: max-age=60 Date: Wed, 04 May 2016 08:48:11 GMT Content-Type: application/cdni; ptype=ci-trigger-collection { "staleresourcetime": 86400, "triggers": [ "https://dcdn.example.com/triggers/0", "https://dcdn.example.com/triggers/1" ] } At this point, if no other Trigger Status Resources had been created, the other filtered views would be empty. For example: REQUEST: GET /triggers/complete HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 54
Expires: Wed, 04 May 2016 08:49:11 GMT
Server: example-server/0.1
ETag: "7958041393922269003"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:11 GMT
Content-Type: application/cdni; ptype=ci-trigger-collection
{
"staleresourcetime": 86400,
"triggers": []
}
6.2.3. Individual Trigger Status Resources
The Trigger Status Resources can also be examined for details about
individual CI/T Trigger Commands. For example, for the CI/T
"preposition" and "invalidate" commands from previous examples:
REQUEST:
GET /triggers/0 HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 467
Expires: Wed, 04 May 2016 08:49:10 GMT
Server: example-server/0.1
ETag: "6990548174277557683"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:10 GMT
Content-Type: application/cdni; ptype=ci-trigger-status
{
"ctime": 1462351690,
"etime": 1462351698,
"mtime": 1462351690,
"status": "pending",
"trigger": {
"content.urls": [
"https://www.example.com/a/b/c/1",
"https://www.example.com/a/b/c/2",
"https://www.example.com/a/b/c/3",
"https://www.example.com/a/b/c/4"
],
"metadata.urls": [
"https://metadata.example.com/a/b/c"
],
"type": "preposition"
}
}
REQUEST:
GET /triggers/1 HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 545
Expires: Wed, 04 May 2016 08:49:11 GMT
Server: example-server/0.1
ETag: "-554385204989405469"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:11 GMT
Content-Type: application/cdni; ptype=ci-trigger-status
{
"ctime": 1462351691,
"etime": 1462351699,
"mtime": 1462351691,
"status": "pending",
"trigger": {
"content.patterns": [
{
"case-sensitive": true,
"pattern": "https://www.example.com/a/b/*"
}
],
"content.urls": [
"https://www.example.com/a/index.html"
],
"metadata.patterns": [
{
"pattern": "https://metadata.example.com/a/b/*"
}
],
"type": "invalidate"
}
}
6.2.4. Polling for Changes in Status
The uCDN SHOULD use the ETags of collections or Trigger Status
Resources when polling for changes in status, as shown in the
following examples:
REQUEST:
GET /triggers/pending HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
If-None-Match: "4331492443626270781"
RESPONSE:
HTTP/1.1 304 Not Modified
Content-Length: 0
Expires: Wed, 04 May 2016 08:49:11 GMT
Server: example-server/0.1
ETag: "4331492443626270781"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:11 GMT
Content-Type: application/cdni; ptype=ci-trigger-collection
REQUEST:
GET /triggers/0 HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
If-None-Match: "6990548174277557683"
RESPONSE:
HTTP/1.1 304 Not Modified
Content-Length: 0
Expires: Wed, 04 May 2016 08:49:10 GMT
Server: example-server/0.1
ETag: "6990548174277557683"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:10 GMT
Content-Type: application/cdni; ptype=ci-trigger-status
When the CI/T Trigger Command is complete, the contents of the
filtered collections will be updated along with their ETags. For
example, when the two example CI/T Trigger Commands are complete, the
collections of pending and complete Trigger Status Resources might
look like:
REQUEST:
GET /triggers/pending HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 54
Expires: Wed, 04 May 2016 08:49:15 GMT
Server: example-server/0.1
ETag: "1337503181677633762"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:15 GMT
Content-Type: application/cdni; ptype=ci-trigger-collection
{
"staleresourcetime": 86400,
"triggers": []
}
REQUEST:
GET /triggers/complete HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 152
Expires: Wed, 04 May 2016 08:49:22 GMT
Server: example-server/0.1
ETag: "4481489539378529796"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:22 GMT
Content-Type: application/cdni; ptype=ci-trigger-collection
{
"staleresourcetime": 86400,
"triggers": [
"https://dcdn.example.com/triggers/0",
"https://dcdn.example.com/triggers/1"
]
}
6.2.5. Deleting Trigger Status Resources
The uCDN can delete completed and failed Trigger Status Resources to
reduce the size of the collections, as described in Section 4.4. For
example, to delete the "preposition" request from earlier examples:
REQUEST:
DELETE /triggers/0 HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 204 No Content
Date: Wed, 04 May 2016 08:48:22 GMT
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Server: example-server/0.1
This would, for example, cause the collection of completed Trigger
Status Resources shown in the example above to be updated to:
REQUEST:
GET /triggers/complete HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 105
Expires: Wed, 04 May 2016 08:49:22 GMT
Server: example-server/0.1
ETag: "-6938620031669085677"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:22 GMT
Content-Type: application/cdni; ptype=ci-trigger-collection
{
"staleresourcetime": 86400,
"triggers": [
"https://dcdn.example.com/triggers/1"
]
}
6.2.6. Error Reporting
In this example, the uCDN has requested pre-positioning of
"https://newsite.example.com/index.html", but the dCDN was unable to
locate metadata for that site:
REQUEST:
GET /triggers/2 HTTP/1.1
User-Agent: example-user-agent/0.1
Host: dcdn.example.com
Accept: */*
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 486
Expires: Wed, 04 May 2016 08:49:26 GMT
Server: example-server/0.1
ETag: "5182824839919043757"
Cache-Control: max-age=60
Date: Wed, 04 May 2016 08:48:26 GMT
Content-Type: application/cdni; ptype=ci-trigger-status
{
"ctime": 1462351702,
"errors": [
{
"content.urls": [
"https://newsite.example.com/index.html"
],
"description": "newsite.example.com not in HostIndex",
"error": "emeta"
}
],
"etime": 1462351710,
"mtime": 1462351706,
"status": "active",
"trigger": {
"content.urls": [
"https://newsite.example.com/index.html"
],
"type": "preposition"
}
}
7. IANA Considerations
7.1. CDNI Payload Type Parameter Registrations
The IANA is requested to register the following new Payload Types in
the "CDNI Payload Types" registry defined by [RFC7736], for use with
the "application/cdni" MIME media type.
+-----------------------+---------------+
| Payload Type | Specification |
+-----------------------+---------------+
| ci-trigger-command | RFC 8007 |
| ci-trigger-status | RFC 8007 |
| ci-trigger-collection | RFC 8007 |
+-----------------------+---------------+
7.2. "CDNI CI/T Trigger Types" Registry
The IANA is requested to create a new "CDNI CI/T Trigger Types" subregistry under the "Content Delivery Network Interconnection (CDNI) Parameters" registry. Additions to the "CDNI CI/T Trigger Types" registry will be made via the RFC Required policy as defined in [RFC5226]. The initial contents of the "CDNI CI/T Trigger Types" registry comprise the names and descriptions listed in Section 5.2.2 of this document, with this document acting as the specification.7.3. "CDNI CI/T Error Codes" Registry
The IANA is requested to create a new "CDNI CI/T Error Codes" subregistry under the "Content Delivery Network Interconnection (CDNI) Parameters" registry. Additions to the "CDNI CI/T Error Codes" registry will be made via the Specification Required policy as defined in [RFC5226]. The Designated Expert will verify that new Error Code registrations do not duplicate existing Error Code definitions (in name or functionality), prevent gratuitous additions to the namespace, and prevent any additions to the namespace that would impair the interoperability of CDNI implementations. The initial contents of the "CDNI CI/T Error Codes" registry comprise the names and descriptions of the Error Codes listed in Section 5.2.7 of this document, with this document acting as the specification.8. Security Considerations
The CI/T interface provides a mechanism to allow a uCDN to generate requests into the dCDN and to inspect its own CI/T requests and their current states. The CI/T interface does not allow access to, or modification of, the uCDN or dCDN metadata relating to content delivery or to the content itself. It can only control the presence of that metadata in the dCDN, and the processing work and network utilization involved in ensuring that presence. By examining "preposition" requests to a dCDN, and correctly interpreting content and metadata URLs, an attacker could learn the uCDN's or content owner's predictions for future content popularity. By examining "invalidate" or "purge" requests, an attacker could learn about changes in the content owner's catalog.
By injecting CI/T Commands, an attacker or a misbehaving uCDN would generate work in the dCDN and uCDN as they process those requests. So would a man-in-the-middle attacker modifying valid CI/T Commands generated by the uCDN. In both cases, that would decrease the dCDN's caching efficiency by causing it to unnecessarily acquire or reacquire content metadata and/or content. A dCDN implementation of CI/T MUST restrict the actions of a uCDN to the data corresponding to that uCDN. Failure to do so would allow uCDNs to detrimentally affect each other's efficiency by generating unnecessary acquisition or reacquisition load. An origin that chooses to delegate its delivery to a CDN is trusting that CDN to deliver content on its behalf; the interconnection of CDNs is an extension of that trust to dCDNs. That trust relationship is a commercial arrangement, outside the scope of the CDNI protocols. So, while a malicious CDN could deliberately generate load on a dCDN using the CI/T interface, the protocol does not otherwise attempt to address malicious behavior between interconnected CDNs.8.1. Authentication, Authorization, Confidentiality, Integrity Protection
A CI/T implementation MUST support Transport Layer Security (TLS) transport for HTTP (HTTPS) as per [RFC2818] and [RFC7230]. TLS MUST be used by the server side (dCDN) and the client side (uCDN) of the CI/T interface, including authentication of the remote end, unless alternate methods are used for ensuring the security of the information in the CI/T interface requests and responses (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). The use of TLS for transport of the CI/T interface allows the dCDN and the uCDN to authenticate each other using TLS client authentication and TLS server authentication.
Once the dCDN and the uCDN have mutually authenticated each other,
TLS allows:
o The dCDN and the uCDN to authorize each other (to ensure that they
are receiving CI/T Commands from, or reporting status to, an
authorized CDN).
o CDNI commands and responses to be transmitted with
confidentiality.
o Protection of the integrity of CDNI commands and responses.
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
followed.
The mechanisms for access control are dCDN-specific and are not
standardized as part of this CI/T specification.
HTTP requests that attempt to access or operate on CI/T data
belonging to another CDN MUST be rejected using, for example,
HTTP 403 ("Forbidden") or 404 ("Not Found"). This is intended to
prevent unauthorized users from generating unnecessary load in dCDNs
or uCDNs due to revalidation, reacquisition, or unnecessary
acquisition.
When deploying a network of interconnected CDNs, the possible
inefficiencies related to the diamond configuration discussed in
Section 2.2.1 should be considered.
8.2. Denial of Service
This document does not define a specific mechanism to protect against
Denial-of-Service (DoS) attacks on the CI/T interface. However, CI/T
endpoints can be protected against DoS attacks through the use of TLS
transport and/or via mechanisms outside the scope of the CI/T
interface, such as firewalling or the use of Virtual Private Networks
(VPNs).
Depending on the implementation, triggered activity may consume
significant processing and bandwidth in the dCDN. A malicious or
faulty uCDN could use this to generate unnecessary load in the dCDN.
The dCDN should consider mechanisms to avoid overload -- for example,
by rate-limiting acceptance or processing of CI/T Commands, or by
performing batch processing.
8.3. Privacy
The CI/T protocol does not carry any information about individual end users of a CDN; there are no privacy concerns for end users. The CI/T protocol does carry information that could be considered commercially sensitive by CDN operators and content owners. The use of mutually authenticated TLS to establish a secure session for the transport of CI/T data, as discussed in Section 8.1, provides confidentiality while the CI/T data is in transit and prevents parties other than the authorized dCDN from gaining access to that data. The dCDN MUST ensure that it only exposes CI/T data related to a uCDN to clients it has authenticated as belonging to that uCDN.9. References
9.1. Normative References
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, <http://www.rfc-editor.org/info/rfc1930>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>. [RFC7232] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>. [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, <http://www.rfc-editor.org/info/rfc8006>.9.2. Informative References
[CBOR-CDDL] Vigano, C. and H. Birkholz, "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", Work in Progress, draft-greevenbosch-appsawg-cbor-cddl-09, September 2016. [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>. [RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>. [RFC7975] Niven-Jenkins, B., Ed., and R. van Brandenburg, Ed., "Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection", RFC 7975, DOI 10.17487/RFC7975, October 2016, <http://www.rfc-editor.org/info/rfc7975>.
Appendix A. Formalization of the JSON Data
This appendix is non-normative. The JSON data described in this document has been formalized using the CBOR Data Definition Language (CDDL) [CBOR-CDDL] (where "CBOR" means "Concise Binary Object Representation"), as follows: CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection CIT-command ; use media type application/cdni; ptype=ci-trigger-command = { ? trigger: Triggerspec ? cancel: [* URI] cdn-path: [* Cdn-PID] } Trigger-Status-Resource ; application/cdni; ptype=ci-trigger-status = { trigger: Triggerspec ctime: Absolute-Time mtime: Absolute-Time ? etime: Absolute-Time status: Trigger-Status ? errors: [* Error-Description] } Trigger-Collection ; application/cdni; ptype=ci-trigger-collection = { triggers: [* URI] ? staleresourcetime: int ; time in seconds ? coll-all: URI ? coll-pending: URI ? coll-active: URI ? coll-complete: URI ? coll-failed: URI ? cdn-id: Cdn-PID } Triggerspec = { ; see Section 5.2.1 type: Trigger-Type ? metadata.urls: [* URI] ? content.urls: [* URI] ? content.ccid: [* Ccid] ? metadata.patterns: [* Pattern-Match] ? content.patterns: [* Pattern-Match] }
Trigger-Type = "preposition" / "invalidate"
/ "purge" ; see Section 5.2.2
Trigger-Status = "pending" / "active" / "complete" / "processed"
/ "failed" / "cancelling" / "cancelled" ; see Section 5.2.3
Pattern-Match = { ; see Section 5.2.4
pattern: tstr
? case-sensitive: bool
? match-query-string: bool
}
Absolute-Time = number ; seconds since UNIX epoch (Section 5.2.5)
Error-Description = { ; see Section 5.2.6
error: Error-Code
? metadata.urls: [* URI]
? content.urls: [* URI]
? metadata.patterns: [* Pattern-Match]
? content.patterns: [* Pattern-Match]
? description: tstr
}
Error-Code = "emeta" / "econtent" / "eperm" / "ereject"
/ "ecdn" / "ecanceled" ; see Section 5.2.7
Ccid = tstr ; see RFC 8006
Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+"
URI = tstr
Acknowledgments
The authors thank Kevin Ma for his input, and Carsten Bormann for his review and formalization of the JSON data.Authors' Addresses
Rob Murray Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom Email: rob.murray@nokia.com Ben Niven-Jenkins Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom Email: ben.niven-jenkins@nokia.com