RFC 7975
Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection 🎀
okay bestie, this is part 1 of 7 so don't leave me hanging 🫶 more parts are coming! 💖
RFC 7975 is an Internet Standards Track document dated October 2016 ✨ It was written by B. Niven-Jenkins (Ed.) from Nokia and R. van Brandenburg (Ed.) from TNO, and it's catalogued under ISSN 2070-1721 📚 The title block doesn't list anything it obsoletes or updates, so no drama there 💅
Abstract 🦋
so the Request Routing interface is basically two jobs in one trench coat 🧥 (1) a downstream Content Delivery Network (CDN) advertises its footprint and capabilities asynchronously, which lets an upstream CDN decide whether it's worth redirecting particular user requests to that downstream CDN, and (2) the synchronous part, where the upstream CDN asks whether a downstream CDN is ready to accept a user request, and the downstream CDN answers with how to actually redirect it 🔥 this document is all about that second part, the CDNI Request Routing Redirection interface.
Status of This Memo 🌸
this one's an Internet Standards Track document, so it's officially a big deal 👑 It's an Internet Engineering Task Force (IETF) product, which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚 The current status, any errata, and how to send feedback live at http://www.rfc-editor.org/info/rfc7975 🔗
Copyright Notice 🌈
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved ✨
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the day it was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interface Function and Operation Overview . . . . . . . . . . 4
4. HTTP-Based Interface for the Redirection Interface . . . . . 6
4.1. Information Passed in RI Requests and Responses . . . . . 8
4.2. JSON Encoding of RI Requests and Responses . . . . . . . 9
4.3. MIME Media Types Used by the RI Interface . . . . . . . . 11
4.4. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. DNS Redirection Requests . . . . . . . . . . . . . . 12
4.4.2. DNS Redirection Responses . . . . . . . . . . . . . . 14
4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17
4.5.1. HTTP Redirection Requests . . . . . . . . . . . . . . 17
4.5.2. HTTP Redirection Responses . . . . . . . . . . . . . 19
4.6. Cacheability and Scope of Responses . . . . . . . . . . . 22
4.7. Error Responses . . . . . . . . . . . . . . . . . . . . . 24
4.8. Loop Detection and Prevention . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5.1. Authentication, Authorization, Confidentiality, and
Integrity Protection . . . . . . . . . . . . . . . . . . 29
5.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6.1. CDNI Payload Type Parameter Registrations . . . . . . . . 31
6.1.1. CDNI RI Redirection Request Payload Type . . . . . . 31
6.1.2. CDNI RI Redirection Response Payload Type . . . . . . 31
6.2. RI Error Response Registry . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 351. Introduction 🧚
a Content Delivery Network (CDN) is a system built on top of an existing IP network, used for large-scale content delivery 🌐 It works by prefetching or dynamically caching content on its distributed surrogates (caching servers). [RFC6707] is the one that lays out the problem area of interconnecting CDNs, so go read it if you're curious 🤓
The CDNI Request Routing interface outlined in [RFC7336] has two parts:
- The asynchronous advertisement of footprint and capabilities by a downstream CDN (dCDN) that lets an upstream CDN (uCDN) decide whether to redirect particular user requests to that dCDN.
- The synchronous operation of a uCDN asking whether a dCDN is prepared to accept a user request, and of a dCDN responding with how to actually redirect the user request.
so this document is all about the latter part, aka the CDNI Request Routing Redirection interface (RI) ✨
2. Terminology 💅
okay so the BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are read in this document exactly the way [RFC2119] describes 🔑
no need to reinvent the wheel, so this document reuses the terminology defined in [RFC6707] 🛞
here are the new terms this doc brings to the party 🎉
- Application-Level Redirection: using an app-specific redirection mechanism for a CDN's request routing process. The Redirection Target (RT) is the result of the CDN's routing decision when it gets a content request, delivered through an application-specific protocol response. Examples are HTTP 302 Redirection and Real Time Messaging Protocol (RTMP) [RTMP] 302 Redirection.
- DNS Redirection: using DNS name resolution for a CDN's request routing process. The CDN's DNS name server makes the routing decision based on a local policy, selects one or more Redirection Targets (RTs), and redirects the User Agent (UA) to them by returning the RT details in response to the DNS query from the User Agent's DNS resolver 🌸
- HTTP Redirection: using an HTTP redirection response for a CDN's request routing process. The Redirection Target (RT) is the result of a CDN's routing decision when it receives a content request via HTTP. HTTP Redirection is a particular case of application-level redirection 🦋
- Redirection Target (RT): the endpoint the User Agent gets redirected to. In CDNI, an RT can point to a bunch of different components, like a surrogate in the same CDN as the request router, a request router in a dCDN, or a surrogate in a dCDN 🍓
3. Interface Function and Operation Overview 🌈
the main job of the CDNI Redirection interface (RI) is to let the request routing systems in interconnected CDNs talk to each other, so User Agent requests can get redirected between them 💖
the detailed requirements for the Redirection interface, plus how they're prioritised, are described in Section 5 of [RFC7337] 📋
the User Agent makes a request to a request router in the uCDN using either DNS or HTTP. The RI is used between the uCDN and one or more dCDNs. The dCDN's RI response may contain a Redirection Target with a type that's compatible with the protocol used between the User Agent and the uCDN request router. The dCDN gets to control which Redirection Target it provides. Depending on that returned Redirection Target, the User Agent's request may be redirected to:
- The final surrogate, which may be in the dCDN that returned the RI response to the uCDN or in another CDN (if the dCDN delegates the delivery to another CDN); or
- A request router (in the dCDN or another CDN), which may use a different redirection protocol (DNS or HTTP) than the one included in the RI request.
the Redirection interface runs between the request routing systems of a pair of interconnected CDNs. To make it work, the uCDN needs to know the URI (endpoint) in the dCDN to send CDNI request routing queries to 🔗
the Redirection interface URI may be statically preconfigured, dynamically discovered via the CDNI Control interface, or discovered via other means. Heads up though: those discovery mechanisms aren't specified in this document, because they're considered out of scope for the Redirection interface spec 🙈
the Redirection interface only matters for Recursive Request Redirection, since Iterative Request Redirection doesn't involve any interaction over the Redirection interface between interconnected CDNs. So this document is limited to Recursive Request Redirection 🎀
with Recursive Request Redirection, the uCDN queries the dCDN so the dCDN can pick and provide a Redirection Target for a request it got from a User Agent. When the uCDN has a choice of dCDNs, it's up to the uCDN to decide (for example, through configured policies) which dCDN(s) to query and in what order ✨ There are a bunch of strategies. One is selecting a preferred dCDN based on local policy, possibly falling back to querying an alternative dCDN(s) if the first dCDN doesn't return a Redirection Target or otherwise rejects the uCDN's RI request. A more complex strategy could be to query multiple dCDNs in parallel, then select one and use the Redirection Target that dCDN provides 🧠
the uCDN-to-User-Agent redirection protocols this document addresses are DNS redirection and HTTP redirection. Other types of application-level redirection won't be discussed further here. The Redirection interface is designed to be extensible, though, so it could be extended to support additional application-level redirection protocols 🦋
for both DNS and HTTP redirection, either HTTP or HTTPS could be used to connect to the Redirection Target. When HTTPS is used to connect to the uCDN and the uCDN uses DNS redirection to identify the RT to the User Agent, the new target domain name may not match the domain in the URL dereferenced to reach the uCDN. Without operational precautions, and in the absence of DNSSEC, this can make a legitimate redirection look like a DNS-based attack to a User Agent and trigger security warnings 🚨 When DNS-based redirection with HTTPS is used, this specification assumes that any RT can complete the necessary Transport Layer Security (TLS) handshake with the User Agent. Any operational mechanisms this requires, e.g., private key distribution to surrogates and request routers in dCDNs, are outside the scope of this document 🔐
and last but not least, this document also defines an RI loop prevention and detection mechanism as part of the Redirection interface 🔁
4. HTTP-Based Interface for the Redirection Interface ✨
Okay bestie, this section defines a simple interface for the Redirection interface, and it's built on HTTP [RFC7230] 🌸. The attributes of a User Agent's requests get wrapped up together with any other data that can help the dCDN process them 📦. The RI response then carries the attributes of the RT(s) the uCDN should hand back to the User Agent (if it decides to use the dCDN for delivery), plus the policy for how that response can be reused 🔁. The examples of RI requests and responses below don't include a full set of HTTP headers, because we're keeping things short. Only the pertinent HTTP headers are shown 💅.
The RI between the uCDN and dCDN uses the same HTTP interface for both DNS and HTTP requests from User Agents 🦋. The contents of the RI requests and responses are different depending on whether it's DNS or HTTP redirection, though 🎀.
This approach is giving practicality 💖. CDN operators only have to deploy one interface for the RI between their CDNs, no matter which User Agent redirection method is in play 🙌. So from an operational point of view, there's just one interface to monitor, manage, and build troubleshooting tools for, etc. 🛠️
It also gets even better, because there's a single RI where the attributes of the User Agent's DNS or HTTP request are wrapped up along with the other data the dCDN needs to make a request routing decision 🧚. That means we don't have to do two annoying things: 1) try to encapsulate or proxy DNS/HTTP/RTMP/etc. requests, and 2) find some way to cram the extra CDNI Request Routing Redirection interface properties/data inside those end-user DNS/HTTP/RTMP/etc. requests 🙈.
Finally, the RI is easy to extend so it can support other User Agent request redirection methods (e.g., RTMP 302 redirection) 🌈. You just define additional protocol-specific keys for RI requests and responses, along with a spec for how to process them ✨.
The generic Recursive Request Redirection message flow between Request Routing systems in a pair of interconnected CDNs looks like this 👑:
User Agent CDN B RR CDN A RR
|UA Request (DNS or HTTP) | |
|-------------------------------------------------->| (1)
| | |
| |HTTP POST to CDN B's RI |
| |URI encapsulating UA |
| |request attributes |
| |<------------------------| (2)
| | |
| |HTTP Response with body |
| |containing RT attributes |
| |of the protocol-specific |
| |response to return to UA |
| |------------------------>| (3)
| | |
| Protocol-specific response (redirection)|
|<--------------------------------------------------| (4)
| | |Figure 1: Generic Recursive Request Redirection Message Flow
Here's the play-by-play 🎬:
- The User Agent sends its (DNS or HTTP) request to CDN A. CDN A's Request Routing System processes it and, through local policy, figures out that the request is best served by another CDN, specifically CDN B (or that CDN B might be one of several candidate dCDNs it could use) 🕵️♀️.
- CDN A's Request Routing System sends an HTTP POST to CDN B's RI URI, containing the attributes of the User Agent's request 📨.
- CDN B's Request Routing System processes the RI request and, assuming the request is well-formed, responds with an HTTP "200" response. The message body contains the RT(s) to return to the User Agent, along with parameters that indicate the properties of the response (cacheability and scope) 🫶.
- CDN A's Request Routing System sends a protocol-specific response (containing the returned attributes) to the User Agent, so the User Agent's request gets redirected to the RT(s) CDN B returned 🎉.
4.1. Information Passed in RI Requests and Responses 💜
The information passed in RI requests splits into two basic categories 📋:
- The attributes of the User Agent's request to the uCDN.
- Properties/parameters that the uCDN can use to control the dCDN's response, or that can help the dCDN make its decision.
Generally, dCDNs can make better routing decisions when they have more info about the content request, like the URI of the requested content or the User Agent's IP address or subnet 🔍. The info needed to base a routing decision on can depend a lot on the type of content being delivered 🎀. A uCDN SHOULD only include information that is absolutely necessary for delivering that type of content 🧼. Cookies are especially sensitive from a security/privacy point of view, so in general they SHOULD NOT be conveyed in the RI Requests to the dCDN 🙅♀️. The information that needs to be conveyed for a particular type of request is expected to be conveyed out of band between the uCDN and dCDN 🤫. For more detail on the privacy aspects of using RI Requests to convey information about UA requests, see Section 5.2 🔐.
For the dCDN to determine whether it can deliver any requested content, it needs CDNI metadata related to the content the User Agent is requesting 🧠. That metadata describes the content and any policies attached to it 📜. The RI request is expected to contain enough info for the Request Router in the dCDN to retrieve the required CDNI Metadata via the CDNI Metadata interface 🗝️.
The information passed in RI responses splits into two basic categories too 📦:
- The attributes of the RT to return to the User Agent in the DNS response or HTTP response.
- Parameters/policies that indicate the properties of the response, such as whether it's cacheable, the scope of the response, etc. 🧁
Besides telling the uCDN how to redirect the User Agent, the dCDN may also want to send back extra policy info to the uCDN 💌. For example, the dCDN may wish to return a policy saying "this response can be reused without requiring an RI request for 60 seconds provided the User Agent's IP address is in the range 198.51.100.0 -- 198.51.100.255" 🦋.
These additional policies split into two basic categories 🌷:
- Cacheability information signaled via the HTTP response headers of the RI response (to reduce the number of subsequent RI requests the uCDN needs to make).
- The scope of a cacheable response signaled in the HTTP response body of the RI response. For example, whether the response applies to a wider range of IP addresses than what was included in the RI request 🌍.
The cacheability of the response is indicated using the standard HTTP Cache-Control mechanisms 🫧.
4.2. JSON Encoding of RI Requests and Responses ✨
okay so the body of every RI request and response is a JSON object [RFC7159] 💖, basically a dictionary of key:value pairs, and that dictionary MUST conform to [RFC7493]. 🎀 Senders MUST encode every key in lowercase, both the top-level keys and the keys inside sub-objects, as long as the key is specified in this document. Receivers MUST ignore any keys that are unknown or invalid 🙈 (not your key, not your problem).
Here's the cheat sheet for the top-level keys 🍓. It shows whether each one shows up in RI requests, RI responses, or both:
+----------+------------------+-------------------------------------+
| Key | Request/Response | Description |
+----------+------------------+-------------------------------------+
| dns | Both | The attributes of the UA's DNS |
| | | request or the attributes of the |
| | | RT(s) to return in a DNS response. |
| | | |
| http | Both | The attributes of the UA's HTTP |
| | | request or the attributes of the RT |
| | | to return in an HTTP response. |
| | | |
| scope | Response | The scope of the response (if it is |
| | | cacheable). For example, whether |
| | | the response applies to a wider |
| | | range of IP addresses than what was |
| | | included in the RI request. |
| | | |
| error | Response | Additional details if the response |
| | | is an error response. |
| | | |
| cdn-path | Both | A List of Strings. Contains a list |
| | | of the CDN Provider IDs of previous |
| | | CDNs that have participated in the |
| | | request routing for the associated |
| | | User Agent request. On RI requests, |
| | | it contains the list of previous |
| | | CDNs that this RI request has |
| | | passed through. On RI responses, it |
| | | contains the list of CDNs that were |
| | | involved in obtaining the final |
| | | redirection included in the RI |
| | | response. See Section 4.8. |
| | | |
| max-hops | Request | Integer specifying the maximum |
| | | number of hops (CDN Provider IDs) |
| | | this request is allowed to be |
| | | propagated along. This allows the |
| | | uCDN to coarsely constrain the |
| | | latency of the request routing |
| | | chain. |
+----------+------------------+-------------------------------------+
Table 1: Top-Level Keys in RI Requests/ResponsesA single request or response MUST contain only one of the dns or http keys 🌸. Requests MUST contain a cdn-path key, and responses MAY contain a cdn-path key 🦋. If max-hops isn't there, then there's no limit on how many CDN hops the RI request can get propagated along ✨. And if the first uCDN doesn't want the RI request going any further than the dCDN it's talking to, it MUST set max-hops to 1 💀.
The cdn-path MAY be reflected back in RI responses 👀. Doing so could expose info to the uCDN that a dCDN might not want to share, like business relationships between a dCDN and other CDNs 🤫.
If the cdn-path does get reflected back, it MUST contain the value of the cdn-path from the associated RI request, with the final dCDN's CDN Provider ID tacked onto the end ✨. Transit CDNs MAY remove the cdn-path from RI responses, but they MUST NOT modify the cdn-path in any other way 🙅.
Having an error key in a response that also has a dns or http key does not automatically mean the RI request failed 😭. The error key MAY be used to share extra (e.g., debugging) info. When a response has an error key along with a dns or http key, the error-code SHOULD be 1xx (e.g., 100) 🔥. See Section 4.7 for more on encoding error info in RI responses 🧚.
All implementations that support IPv4 addresses MUST support the encoding specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] 🌈. Likewise, implementations that support IPv6 addresses MUST support all IPv6 address formats specified in [RFC4291] 💜. Server implementations SHOULD use IPv6 address formats specified in [RFC5952] ✨.
4.3. MIME Media Types Used by the RI Interface 🎀
RI requests MUST use a MIME media type of application/cdni as specified in [RFC7736], with the Payload Type (ptype) parameter set to 'redirection-request' 📮.
RI responses MUST use a MIME media type of application/cdni as specified in [RFC7736], with the Payload Type (ptype) parameter set to 'redirection-response' 💌.
4.4. DNS Redirection 🌍
These next bits give you the detailed rundown of the information that should be passed in RI requests and responses for DNS redirection 🧠.
4.4.1. DNS Redirection Requests 📞
For DNS-based redirection, the uCDN needs to pass these five things to the dCDN in the RI request 💅:
- The IP address of the DNS resolver that made the DNS request to the uCDN.
- The type of DNS query made (usually either A or AAAA).
- The class of DNS query made (usually IN).
- The fully qualified domain name for which DNS redirection is being requested.
- The IP address or prefix of the User Agent (if known to the uCDN).
All of that gets encoded as a set of key:value pairs inside the dns dictionary, like this:
+-------------+---------+-----------+-------------------------------+
| Key | Value | Mandatory | Description |
+-------------+---------+-----------+-------------------------------+
| resolver-ip | String | Yes | The IP address of the UA's |
| | | | DNS resolver. |
| | | | |
| qtype | String | Yes | The type of DNS query made by |
| | | | the UA's DNS resolvers in |
| | | | uppercase. The value of this |
| | | | field SHALL be set to either |
| | | | 'A' or 'AAAA'. |
| | | | |
| qclass | String | Yes | The class of DNS query made |
| | | | in uppercase (IN, etc.). |
| | | | |
| qname | String | Yes | The fully qualified domain |
| | | | name being queried. |
| | | | |
| c-subnet | String | No | The IP address (or prefix) of |
| | | | the UA in Classless Inter- |
| | | | Domain Routing (CIDR) format. |
| | | | |
| dns-only | Boolean | No | If True, then dCDN MUST only |
| | | | use DNS redirection and MUST |
| | | | include RTs to one or more |
| | | | surrogates in any successful |
| | | | RI response. CDNs MUST |
| | | | include the dns-only property |
| | | | set to True on any cascaded |
| | | | RI requests. Defaults to |
| | | | False. |
+-------------+---------+-----------+-------------------------------+
Table 2An RI request for DNS-based redirection MUST include a dns dictionary 🫶. That dns dictionary MUST contain the keys resolver-ip, qtype, qclass, and qname 🔑, and the value of each MUST be the value of the matching part of the User Agent's DNS query/request 💅. For internationalized domain names containing non-ASCII characters, the value of the qname field MUST be the ASCII-compatible encoded (ACE) representation (A-label) of the domain name [RFC5890] 🌏.
Here's an example RI request (uCDN->dCDN) for DNS-based redirection 🦋:
POST /dcdn/ri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"dns" : {
"resolver-ip" : "192.0.2.1",
"c-subnet" : "198.51.100.0/24",
"qtype" : "A",
"qclass" : "IN",
"qname" : "www.example.com"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}4.4.2. DNS Redirection Responses ✨
okay so, when a DNS-based redirect works out, the dCDN has to send the uCDN one of two things in the RI response 💅
- The IP address(es) of (or the CNAME of) RTs that are dCDN surrogates, for when the dCDN is doing DNS-based redirection straight to a surrogate; or
- The IP address(es) of (or the CNAME of) RTs that are Request Routers, for when the dCDN is going to handle the request redirection itself. A dCDN MUST NOT return an RT that is a Request Router if the dns-only key is set to True in the RI request. 🙅♀️
All of that info gets packed into a set of key:value pairs inside the dns dictionary. Here's the breakdown 🎀
+-------+-----------+-----------+-----------------------------------+
| Key | Value | Mandatory | Description |
+-------+-----------+-----------+-----------------------------------+
| rcode | Integer | Yes | DNS response code (see |
| | | | [RFC6895]). |
| | | | |
| name | String | Yes | The fully qualified domain name |
| | | | the response relates to. |
| | | | |
| a | List of | No | Set of IPv4 Addresses of RT(s). |
| | String | | |
| | | | |
| aaaa | List of | No | Set of IPv6 Addresses of RT(s). |
| | String | | |
| | | | |
| cname | List of | No | Set of fully qualified domain |
| | String | | names of RT(s). |
| | | | |
| ttl | Integer | No | TTL in seconds of DNS response. |
| | | | Default is 0. |
+-------+-----------+-----------+-----------------------------------+ Table 3Now the rules, and these ones are important bestie, so pay attention 🧚 A successful RI response for DNS-based redirection MUST include a dns dictionary, and it MAY include an error dictionary (see Section 4.7). An unsuccessful RI response for DNS-based redirection MUST include an error dictionary. If a dns dictionary shows up in the RI response, it MUST include the rcode and name keys, and it MUST also include at least one of the following keys: a, aaaa, or cname. The dns dictionary MAY include both a and aaaa keys. If the dns dictionary has a cname key, it MUST NOT contain either an a or aaaa key. And for internationalized domain names with non-ASCII characters, the value of the cname field MUST be the ACE representation (A-label) of the domain name. Not optional, not negotiable 💀
Here's a successful RI response (dCDN->uCDN) for DNS-based redirection with both a and aaaa keys 🌸
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}And here's another one, the cname flavour, where the FQDN of the RT gets handed back instead of IP addresses 🦋
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"cname" : ["rr1.dcdn.example"],
"ttl" : 20
}
}4.5. HTTP Redirection ⭐
Okay, now we're moving on to HTTP redirection! The next sections walk through the information that should be passed in RI requests and responses for it, so get comfy 🫶
The dictionary keys used in HTTP Redirection requests and responses follow some prefix conventions, and they're super useful to know:
c-is prefixed to keys for information related to the Client (User Agent).cs-is prefixed to keys for information passed by the Client (User Agent) to the Server (uCDN).sc-is prefixed to keys for information to be passed by the Server (uCDN) to the Client (User Agent).
4.5.1. HTTP Redirection Requests 💜
For HTTP-based redirection, the uCDN needs to hand the dCDN the following in the RI request:
- The IP address of the User Agent.
- The URI requested by the User Agent.
- The HTTP method requested by the User Agent.
- The HTTP version number requested by the User Agent.
The uCDN may also decide to pass along the presence and value of particular HTTP headers included in the User Agent request to the dCDN 🎀
All of this goes into a set of key:value pairs inside the http dictionary, like so 🍓
+-------------------+--------+-----------+--------------------------+
| Key | Value | Mandatory | Description |
+-------------------+--------+-----------+--------------------------+
| c-ip | String | Yes | The IP address of the |
| | | | UA. |
| | | | |
| cs-uri | String | Yes | The Effective Request |
| | | | URI [RFC7230] requested |
| | | | by the UA. |
| | | | |
| cs-method | String | Yes | The method part of the |
| | | | request-line as defined |
| | | | in Section 3.1.1 of |
| | | | [RFC7230]. |
| | | | |
| cs-version | String | Yes | The HTTP-version part of |
| | | | the request-line as |
| | | | defined in Section 3.1.1 |
| | | | of [RFC7230]. |
| | | | |
| cs-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> as a |
| | | | string, for example, |
| | | | cs-(cookie) would |
| | | | contain the value of the |
| | | | HTTP Cookie header from |
| | | | the UA request. |
+-------------------+--------+-----------+--------------------------+ Table 4Right, the must-haves 👑 An RI request for HTTP-based redirection MUST include an http dictionary. That http dictionary MUST contain the following keys: c-ip, cs-method, cs-version, and cs-uri, and the value of each MUST be the value of the appropriate part of the User Agent's HTTP request.
The http dictionary of an RI request MUST contain a maximum of one cs-(<headername>) key for each unique header field-name (HTTP header field). And <headername> MUST be identical to the equivalent HTTP header field-name, encoded in all lowercase 🌈
Now, if the User Agent request has multiple HTTP header fields with the same field-name, it is RECOMMENDED that the uCDN combine those headers into a single value according to Section 3.2.2 of [RFC7230]. BUT, and this is a big but 🙈 there are loads of already-defined HTTP header fields, and some of them are inconsistent about the combination mechanism defined in RFC 7230. So the uCDN MAY have to deviate from the combination mechanism where appropriate. For example, it might only send the contents of the first occurrence of the HTTP Headers instead. Messy, but that's real life 😭
Here's an example RI request (uCDN->dCDN) for HTTP-based redirection 🧚
POST /dcdn/rrri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"http": {
"c-ip": "198.51.100.1",
"cs-uri": "http://www.example.com",
"cs-version": "HTTP/1.1",
"cs-method": "GET"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}4.5.2. HTTP Redirection Responses
Okay so, for a successful HTTP-based redirection, the dCDN needs to send one of these two things back to the uCDN in the RI response 💖:
- A URI pointing to an RT that is the selected dCDN surrogate(s) (if the dCDN is performing HTTP-based redirection directly to a surrogate); or
- A URI pointing to an RT that is a Request Router (if the dCDN will perform request redirection itself).
All of that info gets encoded as key:value pairs inside the http dictionary 🎀:
+-------------------+---------+-----------+-------------------------+
| Key | Value | Mandatory | Description |
+-------------------+---------+-----------+-------------------------+
| sc-status | Integer | Yes | The status-code part of |
| | | | the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA |
| | | | (usually set to 302). |
| | | | |
| sc-version | String | Yes | The HTTP-version part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| sc-reason | String | Yes | The reason-phrase part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| cs-uri | String | Yes | The URI requested by |
| | | | the UA/client. |
| | | | |
| sc-(location) | String | Yes | The contents of the |
| | | | Location header to |
| | | | return to the UA (i.e., |
| | | | a URI pointing to the |
| | | | RT(s)). |
| | | | |
| sc-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> to return |
| | | | to the UA. For example, |
| | | | sc-(expires) would |
| | | | contain the value of |
| | | | the HTTP Expires |
| | | | header. |
+-------------------+---------+-----------+-------------------------+Table 5
Note: The sc-(location) key in the preceding table is an example of sc-(<headername>) that has been called out separately as its presence is mandatory in RI responses. 🧚
A successful RI response for HTTP-based redirection MUST include an http dictionary and MAY include an error dictionary (see Section 4.7). An unsuccessful RI response for HTTP-based redirection MUST include an error dictionary. If an http dictionary is included in the RI response, it MUST include at least the following keys: sc-status, sc-version, sc-reason, cs-uri, and sc-(location). 🫶
The http dictionary of an RI response MUST contain a maximum of one sc-(<headername>) key for each unique header field-name (HTTP header field). <headername> MUST be identical to the equivalent HTTP header field-name encoded in all lowercase. 💅
The uCDN MAY decide to not return, override, or alter any or all of the HTTP headers defined by sc-(<headername>) keys before sending the HTTP response to the UA. It should be noted that in some cases, sending the HTTP Headers indicated by the dCDN transparently on to the UA might result in, for the uCDN, undesired behavior. 🙈 As an example, the dCDN might include sc-(cache-control), sc-(last-modified), and sc-(expires) keys in the http dictionary, through which the dCDN may try to influence the cacheability of the response by the UA. If the uCDN would pass these HTTP headers on to the UA, this could mean that further requests from the uCDN would go directly to the dCDN, bypassing the uCDN and any logging it may perform on incoming requests. Therefore, the uCDN is recommended to carefully consider which HTTP headers to pass on, and which to either override or not pass on at all. 😭
Here's an example of a successful RI response (dCDN->uCDN) for HTTP-based redirection 🦋:
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
}
}4.6. Cacheability and Scope of Responses
RI responses may be cacheable. 🌸 As long as a cached RI response is not stale according to standard HTTP Cache-Control or other applicable mechanisms, it may be reused by the uCDN in response to User Agent requests without sending another RI request to the dCDN. ✨
An RI response MUST NOT be reused unless the request from the User Agent would generate an identical RI request to the dCDN as the one that resulted in the cached RI response (except for the c-ip field provided that the User Agent's c-ip is covered by the scope in the original RI response, as elaborated upon below). 🚫
Additionally, although RI requests only encode a single User Agent request to be redirected, there may be cases where a dCDN wishes to indicate to the uCDN that the RI response can be reused for other User Agent requests without the uCDN having to make another request via the RI. 👑 For example, a dCDN may know that it will always select the same surrogates for a given set of User Agent IP addresses. To reduce request volume across the RI, or to remove the additional latency associated with an RI request, the dCDN may wish to indicate that set of User Agent IP addresses to the uCDN in the initial RI response. This is achieved by including an optional scope dictionary in the RI response. 🍓
Scope is encoded as a set of key:value pairs within the scope dictionary as follows:
+---------+--------+-----------+------------------------------------+
| Key | Value | Mandatory | Description |
+---------+--------+-----------+------------------------------------+
| iprange | List | No | A List of IP subnets in CIDR |
| | of | | notation that this RI response can |
| | String | | be reused for, provided the RI |
| | | | response is still considered |
| | | | fresh. |
+---------+--------+-----------+------------------------------------+Table 6
If a uCDN has multiple cached responses with overlapping scopes and a UA request comes in for which the User Agent's IP matches with the IP subnets in multiple of these cached responses, the uCDN SHOULD use the most recent cached response when determining the appropriate RI response to use. 🔥
The following is an example of a DNS redirection response from Section 4.4.2 that is cacheable by the uCDN for 30 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24. 🌈
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=30
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}The following is an example of an HTTP redirection response from Section 4.5.2 that is cacheable by the uCDN for 60 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24. 🧁
Note: The response to the UA is only valid for 30 seconds, whereas the uCDN can cache the RI response for 60 seconds. ⏰
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=60
{
"http": {
"sc-status": 302,
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc-(cache-control)" : "public, max-age=30"
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}4.7. Error Responses 💌
okay so there are two kinds of errors that can pop up when a uCDN sends an RI request to a dCDN, and it's giving pick your fighter 🥊
- An HTTP protocol error, signalled with an HTTP status code. This one means something went sideways with receiving or parsing the RI request, or with the dCDN generating the RI response. 😵
- An RI-level error, which is spelled out inside an RI response message. ✨
This section is all about the second kind 💅 The first kind is outside the scope of this doc, so we're leaving it alone bestie.
There are loads of reasons a dCDN might not be able to send back a yes-answer 🙈 Some are internal, like capacity problems. Others are totally outside the dCDN's control, like a malformed RI request. To help figure out what went wrong, RI responses SHOULD include an error dictionary that gives the uCDN extra info about the reason or cause of the error. The whole point is to help with diagnosing issues, whether a human is looking at it or a machine is 🧚 Actually fixing the issue is out of scope here. This doc doesn't say what a uCDN should do after it gets any particular error-code, so that's on the implementers 💜
Error info (if there is any) is encoded as key:value pairs inside a JSON-encoded error dictionary, and it looks like this:
+------------+---------+-----------+--------------------------------+
| Key | Value | Mandatory | Description |
+------------+---------+-----------+--------------------------------+
| error-code | Integer | Yes | A three-digit numeric code |
| | | | defined by the server to |
| | | | indicate the error(s) that |
| | | | occurred. |
| | | | |
| reason | String | No | A string providing further |
| | | | information related to the |
| | | | error. |
+------------+---------+-----------+--------------------------------+
Table 7The first digit of the error-code tells you the class of error. There are 5 classes, sorted by that first digit:
1xx: Informational (no error). The uCDN should not treat this as an error. It's allowed to carry on and redirect the UA based on the values in the RI response. The error-code and its description can be used for informational purposes, like logging 📝2xx: Reserved. 🔒3xx: Reserved. 🔒4xx: uCDN error. The dCDN can't or won't process the request because it looks like the uCDN caused the problem. For example, the dCDN couldn't parse the RI request successfully. The last two digits can be used to point more specifically at where the problem came from. 🎀5xx: dCDN error. The dCDN knows it messed up, or it can't satisfy the RI request for some reason. For example, the dCDN could parse the RI request but then hit an error along the way. Examples include the dCDN not being able to retrieve the associated metadata, or the dCDN being out of capacity 😭
The following error-codes are defined and maintained by IANA (see Section 6). ✨
Error-codes that have a "Reason" of "<reason>" don't have a set value for their 'reason'-key. Depending on what the error-code means, the value of that field might get figured out dynamically 🌈
+------+--------------+---------------------------------------------+
| Code | Reason | Description |
+------+--------------+---------------------------------------------+
| 100 | <reason> | Generic informational error-code meant for |
| | (see | carrying a human-readable string |
| | Description) | |
| | | |
| 400 | <reason> | Generic error-code for uCDN errors where |
| | (see | the dCDN cannot or will not process the |
| | Description) | request due to something that is perceived |
| | | to be a uCDN error. The reason field may |
| | | be used to provide more details about the |
| | | source of the error. |
| | | |
| 500 | <reason> | Generic error-code for dCDN errors where |
| | (see | the dCDN is aware that it has erred or is |
| | Description) | incapable of satisfying the RI request for |
| | | some reason. The reason field may be used |
| | | to provide more details about the source of |
| | | the error. |
| | | |
| 501 | Unable to | The dCDN is unable to retrieve the metadata |
| | retrieve | associated with the content requested by |
| | metadata | the UA. This may indicate a configuration |
| | | error or that the content requested by the |
| | | UA does not exist. |
| | | |
| 502 | Loop | The dCDN detected a redirection loop (see |
| | detected | Section 4.8). |
| | | |
| 503 | Maximum hops | The dCDN detected the maximum number of |
| | exceeded | redirection hops exceeding max-hops (see |
| | | Section 4.8). |
| | | |
| 504 | Out of | The dCDN does not currently have sufficient |
| | capacity | capacity to handle the UA request. |
| | | |
| 505 | Delivery | The dCDN does not support the (set of) |
| | protocol not | delivery protocols indicated in the CDNI |
| | supported | Metadata of the content requested by the |
| | | UA. |
| | | |
| 506 | Redirection | The dCDN does not support the requested |
| | protocol not | redirection protocol. This error-code is |
| | supported | also used when the RI request has the dns- |
| | | only flag set to True and the dCDN is not |
| | | supported or is not prepared to return an |
| | | RT of a surrogate directly. |
+------+--------------+---------------------------------------------+
Table 8Here's an example of an unsuccessful RI response (dCDN->uCDN) for a DNS-based User Agent request 🍓
HTTP/1.1 500 Internal Server Error
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"error" : {
"error-code" : 504,
"description" : "Out of capacity"
}
}And here's a successful RI response (dCDN->uCDN) for an HTTP-based User Agent request, with an error dictionary included for informational purposes 🦋
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
},
"error" : {
"error-code" : 100,
"description" :
"This is a human-readable message meant for debugging purposes"
}
}4.8. Loop Detection and Prevention 🔁
Okay this part is so important. To prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates or cascades. 🫶 When a dCDN receives RI requests, it MUST check the cdn-path and reject any RI request that already has the dCDN's Provider ID in there. Transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (counted before they add their own Provider ID) is equal to or greater than max-hops. 🚫
So what even is a CDN Provider ID? It uniquely identifies each CDN Provider while requests are getting routed and redirected. It's made of the characters AS, followed by the CDN Provider's AS number, then a colon (:), then an extra qualifier. That qualifier is there to guarantee uniqueness in case one AS has multiple independent CDNs deployed. For example: "AS64496:0" 🌸
If a dCDN gets an RI request whose cdn-path already contains that dCDN's Provider ID, the dCDN MUST send an RI error response that SHOULD include an error-code of 502. 💀
If a dCDN gets an RI request where the number of CDN Provider IDs in cdn-path is greater than max-hops, the dCDN MUST send an RI error response that SHOULD include an error-code of 503. 🙅♀️
Now, the loop detection and prevention stuff above only covers loops inside the RI itself. There can also be loops in the data plane 😵💫 For example, if the IP address(es) or URI(s) returned in RI responses don't resolve directly to a surrogate in the final dCDN, a User Agent could get bounced around a loop of CDNs forever. Specifying solutions for data-plane redirection loops between CDNs is outside the scope of this document. 🧵
5. Security Considerations 🔐
Okay, bestie, this section is serious, so let's get into it 🥺 Information passed over the RI could be considered personal or sensitive. For example, RI requests contain parts of a User Agent's original request, and RI responses reveal the dCDN's policy about which surrogates should serve which content and user locations. Big yikes if that leaks 😭
The RI interface also gives a uCDN a way to probe a dCDN and work out the dCDN's edge topology. It can do this by sending repeated RI requests for different content and/or UA IP addresses, then comparing the responses it gets back. On top of that, a dCDN can say that an RI response applies more widely than the original request, using the scope dictionary. That can seriously cut down how many RI requests someone needs to map out the dCDN's edge topology 👀
The same information could be collected without the RI interface, but it would be way harder. You'd need a bunch of machines with lots of different IP addresses, each one making requests directly to the dCDN. The RI makes things easier, though, because a single client can ask the dCDN for a redirection or surrogate selection on behalf of any UA IP address. That's the part that's lowkey concerning 🚨
5.1. Authentication, Authorization, Confidentiality, and Integrity Protection ✨
okay bestie, first things first: an implementation of the CDNI Redirection interface MUST support TLS transport as per [RFC2818] and [RFC7230] 🔐. TLS is what lets the dCDN and uCDN authenticate each other, and once they've mutually authenticated, it unlocks three things:
- the dCDN and uCDN can authorize each other, so they know they're only sending and receiving CDNI Redirection messages with an authorized CDN 💅
- CDNI Redirection interface messages can be sent with confidentiality 🤫
- the integrity of those messages stays protected during the exchange 🛡️
In any environment where that protection is required, mutually authenticated encrypted transport MUST be used to keep the redirection info confidential. To do that, TLS MUST be used (including authentication of the remote end) by the server side (dCDN) and the client side (uCDN) of the CDNI Redirection interface. no shortcuts, periodt 💖
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be followed. 📖✨
5.2. Privacy
okay this section is giving serious privacy vibes 🙈 Information passed over the RI ought to be considered personal and sensitive. The big ones are parts of a User Agent's original request, most notably the UA's IP address and requested URI, which get sent over the RI to the dCDN. mutually authenticated TLS (see the previous section) is what stops anyone other than the authorized dCDN from getting their hands on this info 🔒
here's the twist: regardless of whether the uCDN and dCDN use the RI, a successful redirect from a uCDN to a dCDN will make that dCDN aware of the UA's IP address anyway 🤷♀️ So the fact that this info travels across the RI doesn't let the dCDN learn anything new. BUT, lowkey important: if a uCDN uses the RI to check with multiple candidate dCDNs, the candidates that don't end up getting redirected still get information about end-user IP addresses and requested URIs that they would not have if the RI not been used. that's the part that's a little concerning 😬
you can technically mask some info in the RI Request, like the last bits of the UA IP address, but heads up: this reduces how well the RI works in certain cases 🎀 CDN deployments need to strike a balance between end-user privacy and the features that get impacted by masking. that balance will probably look different from one deployment to another. for example, when the UA and its DNS resolver are behind a Carrier-grade NAT, and the RI is used to find an appropriate delivery node behind the same NAT, the full IP address might be necessary 🌸 Another potential issue with IP anonymization is that it's no longer possible to correlate an RI Request with a subsequent UA request 🧩
6. IANA Considerations 🦋
6.1. CDNI Payload Type Parameter Registrations
IANA has registered the following two new Payload Types in the "Content Delivery Network Interconnection (CDNI) Parameters" registry for use with the application/cdni MIME media type. two new payload types, let's gooo 🎉
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| redirection-request | RFC 7975 |
| | |
| redirection-response | RFC 7975 |
+----------------------+---------------+
Table 96.1.1. CDNI RI Redirection Request Payload Type
- Purpose: The purpose of this payload type is to distinguish RI request messages. 💌
- Interface: RI
- Encoding: See Section 4.4.1 and Section 4.5.1
6.1.2. CDNI RI Redirection Response Payload Type
- Purpose: The purpose of this payload type is to distinguish RI response messages. 💜
- Interface: RI
- Encoding: See Section 4.4.2 and Section 4.5.2
6.2. RI Error Response Registry
IANA has created a new "CDNI RI Error response code" subregistry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry. This is the namespace that defines the valid values for the error-code key in RI error responses 🧾 The CDNI RI Error response code MUST be a three-digit integer. no exceptions, bestie 🔢
Additions to the "RI Error response registry" will be made via "Specification Required" as defined in [RFC5226].
The Designated Expert is the one who checks everything. They will verify that new error-code registrations don't duplicate existing error-code definitions (in name or functionality), make sure the new error-code fits the error classes defined in Section 4.7 of this document, prevent gratuitous additions to the namespace, and prevent any additions that would impair the interoperability of CDNI implementations 👑
New registrations are required to provide the following information:
- Code: A three-digit numeric error-code, in accordance with the error classes defined in Section 4.7 of this document.
- Reason: A string that provides further information related to the error, which will be included in the JSON error dictionary with the
'reason'key. Depending on the error-code semantics, the value of this field may be determined dynamically. In that case, the registration should set this value to'<reason>'and define its semantics in the description field. - Description: A brief description of the error-code semantics.
- Specification: Reference to the specification that defines the error-code in more detail.
The entries in Table 8 are registered by this document, with the value of the 'Specification' field set to RFC 7975 (this document). ✨
7. References 📚
7.1. Normative References
[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>.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>.
[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>.
[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>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <http://www.rfc-editor.org/info/rfc6895>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol
(RTMP) specification", December 2012,
<http://www.adobe.com/go/spec_rtmp>.7.2. Informative References
[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>.
[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>.
[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>.Acknowledgements 💐
The authors would like to thank Taesang Choi, Francois Le Faucheur, Matt Miller, Scott Wainner, and Kevin J. Ma for their valuable comments and input to this document. shoutout to the squad 🫶
Contributors 🌈
The following persons have participated as co-authors to this document:
Wang Danhua
Huawei
Email: wangdanhua@huawei.com
He Xiaoyan
Huawei
Email: hexiaoyan@huawei.com
Ge Chen
China Telecom
Email: cheng@gsta.com
Ni Wei
China Mobile
Email: niwei@chinamobile.com
Yunfei Zhang
Email: hishigh@gmail.com
Spencer Dawkins
Huawei
Email: spencer@wonderhamster.orgAuthors' Addresses ✨
Ben Niven-Jenkins (editor)
Nokia
3 Ely Road
Milton, Cambridge CB24 6DD
United Kingdom
Email: ben.niven-jenkins@nokia.com
Ray van Brandenburg (editor)
TNO
Anna van Buerenplein 1
The Hague 2595DA
The Netherlands
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl📦 where this page comes from
- ietf: rfc7975 2016-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms