idnits 2.17.1 draft-ietf-cdni-media-type-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2015) is 3116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI K. Ma 3 Internet-Draft Ericsson 4 Intended status: Informational October 8, 2015 5 Expires: April 10, 2016 7 CDNI Media Type Registration 8 draft-ietf-cdni-media-type-05 10 Abstract 12 This document defines the standard media type used by the Content 13 Delivery Network Interconnection (CDNI) protocol suite, including the 14 registration procedure and recommended usage of the required payload- 15 type parameter . 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 10, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 52 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. CDNI Media Type . . . . . . . . . . . . . . . . . . . . . 2 54 2.2. CDNI Payload Type Parameter Registry . . . . . . . . . . 4 55 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Normative References . . . . . . . . . . . . . . . . . . 5 57 3.2. Informative References . . . . . . . . . . . . . . . . . 6 58 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction and Scope 63 The Content Delivery Network Interconnection (CDNI) working group is 64 developing a set of protocols to enable the interconnection of 65 multiple content delivery networks (CDNs), as discussed in [RFC6770]. 66 The CDNI protocol suite consists of multiple HTTP-based interfaces, 67 many of which transfer various JSON (JavaScript Object Notation) 68 encoded payloads [RFC7159]. The main interfaces (i.e., CDNI Control 69 interface, CDNI Footprint & Capabilities Advertisement interface, 70 CDNI Request Routing Redirection interface, CDNI Metadata interface, 71 and CDNI Logging interface) are described in [RFC7336]. It is 72 desirable to be able to indicate the type of object carried in the 73 HTTP entity-body without having to register separate media types for 74 each CDNI object. To accomplish this aims, this document defines a 75 single new media type for CDNI that includes a required payload-type 76 parameter. A separate registry of CDNI payload-type parameters is 77 also defined. CDNI protocol specifications may register interface- 78 specific payload-types, specifying the payload encoding and parsing 79 semantics for that message (e.g., JSON serialization for a CDNI 80 metadata object). The same payload-type parameter may also be used 81 as references for other purposes (e.g., referencing CDNI metadata 82 objects from CDNI capability advertisement objects). 84 2. IANA Considerations 86 This section contains the CDNI media type registration request for 87 IANA, as well as the payload-type parameter registry definition for 88 IANA. 90 2.1. CDNI Media Type 92 Type name: application 94 Subtype name: cdni 96 Required parameters: 98 ptype 100 The required parameter "ptype" describes the type of CDNI 101 message contained in the message payload, as registered in the 102 CDNI Payload Type Parameter Registry (Section 2.2) defined 103 below. 105 Optional parameters: none 107 Encoding considerations: 109 The CDNI protocol suite includes interfaces with encoded messages 110 which may be 8bit or binary, as well as generic logging 111 information which may be 7bit or binary. 113 Security considerations: 115 CDNI interfaces that return encoded data may be (mis)interpreted 116 if parsed by non-CDNI or non-compliant CDNI implementations. In 117 addition, CDNI logging information is likely to transfer large 118 amounts of data which may overload unexpecting clients. The 119 individual CDNI interface specifications provide more detailed 120 analysis of security and privacy concerns, and define the 121 requirements for authentication, authorization, confidentiality, 122 integrity, and privacy for each interface. 124 The application/cdni media type is a generic media type to be used 125 by multiple CDNI interfaces for transporting different types of 126 control and logging information. Proper validation of message 127 data requires parsing and understanding the ptype parameter and 128 the associated data encoding. Failure to properly validate 129 payloads may allow data extrusion under the auspices of the 130 application/cdni media type. 132 Interoperability considerations: 134 The required ptype field is intended to fully describe the 135 structure and parsing of CDNI messages, as enforced by the ptype 136 registry designated expert. 138 Published specification: RFCthis 140 Applications that use this media type: 142 CDNI is intended for use between interconnected CDNs for sharing 143 configuration and logging data, as well as for issuing content 144 management and redirection requests. 146 Fragment identifier considerations: N/A 148 Additional information: N/A 150 Deprecated alias names for this type: N/A 152 Magic number(s): N/A 154 File extension(s): N/A 156 Macintosh file type code(s): N/A 158 Person & email address to contact for further information: 160 Kevin Ma 162 Intended usage: LIMITED USE 164 Restrictions on usage: 166 This media type is intended only for use in CDNI protocol message 167 exchanges. 169 Author: IETF CDNI working group 171 Change controller: IETF CDNI working group 173 Provisional registration: no 175 2.2. CDNI Payload Type Parameter Registry 177 The IANA is requested to create a new "CDNI Payload Type" registry. 178 The "CDNI Payload Type" namespace defines the valid values for the 179 required "ptype" parameter of the "application/cdni" media type. The 180 CDNI Payload Type is an ASCII string value, consisting of only 181 visible (printing) characters, but excluding equal signs (=), double 182 quotes ("), and semicolons (;), and not exceeding 256 characters in 183 length. 185 ptype = 1*256(ptype-char) 186 ptype-char = %x21 / %x23-3A / %x3C / %x3E-7E 187 ; Includes ALPHA, DIGIT, and other printables 188 ; Excludes equal signs (=), double quotes ("), semicolons (;) 190 Additions to the CDNI Payload Type namespace will conform to the 191 "Specification Required" policy as defined in [RFC5226]. The 192 designated expert will verify that new type definitions do not 193 duplicate existing type definitions (in name or functionality), 194 prevent gratuitous additions to the namespace, and prevent any 195 additions to the namespace which would impair the interoperability of 196 CDNI implementations. The designated expert will review the 197 specification, even if it is a Standards Track RFC, to verify that it 198 contains the following information: 200 o The review will verify that the specification contains a 201 reasonably defined purpose for the new payload type, where the 202 purpose is related to an existing or proposed CDNI interface and 203 does not duplicate the functionality of any existing CDNI protocol 204 feature without specifying a rational reason (e.g., updating an 205 obsolete feature), a method for detecting and handling conflicts 206 (e.g., a versioning system with prioritization matrix), and a 207 suggested migration path (e.g., deprecation of the overlapped 208 feature, or justification for co-existence). 210 o The review will verify that the specification contains information 211 as to which CDNI interface the new payload type pertains/affects. 212 The payload type may be applicable to multiple CDNI interfaces, 213 but the justification for the new payload type will include a 214 reasonable relationship to at least one standards track CDNI 215 interface. 217 o The review will verify that the specification contains sufficient 218 detail about the data encoding (e.g., JSON serialization for new 219 CDNI metadata or capability advertisement objects, or ABNF and 220 description for new CDNI logging file formats) to allow senders 221 and receivers of the new payload type to implement compliant and 222 interoperable payload parsers. 224 The registry contains the Payload Type, and the specification 225 describing the Payload Type. The registry will initially be 226 unpopulated. 228 +--------------+---------------+ 229 | Payload Type | Specification | 230 +--------------+---------------+ 231 +--------------+---------------+ 233 3. References 235 3.1. Normative References 237 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 238 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 239 DOI 10.17487/RFC5226, May 2008, 240 . 242 3.2. Informative References 244 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 245 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 246 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 247 November 2012, . 249 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 250 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 251 2014, . 253 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 254 "Framework for Content Distribution Network 255 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 256 August 2014, . 258 Appendix A. Acknowledgment 260 This document is the culmination of the efforts of many in the CDNI 261 working group, including (in alphabetical order): Francois Le 262 Faucheur, Daryl Malas, Rob Murray, Ben Niven-Jenkins, Iuniana 263 Oprescu, Jon Peterson, and Jan Seedorf. 265 Author's Address 267 Kevin J. Ma 268 Ericsson 269 43 Nagog Park 270 Acton, MA 01720 271 USA 273 Phone: +1 978-844-5100 274 Email: kevin.j.ma@ericsson.com