idnits 2.17.1 draft-ietf-core-multipart-ct-00.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 (June 25, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-03 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE T. Fossati 3 Internet-Draft Nokia 4 Intended status: Standards Track K. Hartke 5 Expires: December 27, 2018 Ericsson 6 C. Bormann 7 Universitaet Bremen TZI 8 June 25, 2018 10 Multipart Content-Format for CoAP 11 draft-ietf-core-multipart-ct-00 13 Abstract 15 This memo defines application/multipart-core, an application- 16 independent media-type that can be used to combine representations of 17 several different media types into a single CoAP message-body with 18 minimal framing overhead, each along with a CoAP Content-Format 19 identifier. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 27, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Multipart Content-Format Encoding . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Registration of media type application/multipart-core . . 3 59 3.2. Registration of a Content-Format identifier for 60 application/multipart-core . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 5.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This memo defines application/multipart-core, an application- 71 independent media-type that can be used to combine representations of 72 several different media types into a single CoAP [RFC7252] message- 73 body with minimal framing overhead, each along with a CoAP Content- 74 Format identifier. 76 This simple and efficient binary framing mechanism can be employed to 77 create application specific request and response bodies which build 78 on multiple already existing media types. 80 Applications using the application/multipart-core Content-Format 81 define the internal structure of the application/multipart-core 82 representation. 84 For example, one way to structure the sub-types specific to an 85 application/multipart-core container is to always include them at the 86 same fixed position. This specification allows to indicate that an 87 optional part is not present by substituting a null value for the 88 representation of the part. 90 Optionally, an application might use the general format defined here, 91 but also register a new media type and an associated Content-Format 92 identifier -- typically one in the range 10000-64999 -- instead of 93 using application/multipart-core. 95 2. Multipart Content-Format Encoding 97 A representation of media-type application/multipart-core contains a 98 collection of zero or more representations, each along with their 99 respective content format. 101 The collection is encoded as a CBOR [RFC7049] array with an even 102 number of elements. The second, fourth, sixth, etc. element is a 103 byte string containing a representation, or the value "null" if an 104 optional part is indicated as not given. The first, third, fifth, 105 etc. element is an unsigned integer specifying the content format ID 106 of the representation following it. Where needed by an application, 107 each such format identifying element alternatively can be a text 108 string giving the media type name plus potentially some parameters. 110 For example, a collection containing two representations, one with 111 content format ID 42 and one with content format ID 0, looks like 112 this in CBOR diagnostic notation: 114 [42, h'0123456789abcdef', 0, h'3031323334'] 116 For illustration, the structure of an application/multipart-core 117 representation can be described by the CDDL [I-D.ietf-cbor-cddl] 118 specification in Figure 1: 120 multipart-core = [* multipart-part] 121 multipart-part = (type: uint .size 2 / text, part: bytes / null) 123 Figure 1: CDDL for application/multipart-core 125 3. IANA Considerations 127 3.1. Registration of media type application/multipart-core 129 IANA is requested to register the following media type [RFC6838]: 131 Type name: application 133 Subtype name: multipart-core 135 Required parameters: N/A 137 Optional parameters: N/A 139 Encoding considerations: binary 141 Security considerations: See the Security Considerations Section of 142 RFCthis 144 Interoperability considerations: N/A 146 Published specification: RFCthis 148 Applications that use this media type: Applications that need to 149 combine representations of potentially several media types into 150 one, e.g., EST-CoAP [I-D.ietf-ace-coap-est] 152 Fragment identifier considerations: N/A 154 Additional information: 156 Deprecated alias names for this type: N/A 158 Magic number(s): N/A 160 File extension(s): N/A 162 Macintosh file type code(s): N/A 164 Person & email address to contact for further information: 165 iesg&ietf.org 167 Intended usage: COMMON 169 Restrictions on usage: N/A 171 Author: CoRE WG 173 Change controller: IESG 175 Provisional registration? (standards tree only): no 177 3.2. Registration of a Content-Format identifier for application/ 178 multipart-core 180 IANA is requested to register the following Content-Format to the 181 "CoAP Content-Formats" subregistry, within the "Constrained RESTful 182 Environments (CoRE) Parameters" registry, from the IETF Review space 183 (specifically, 256..999): 185 +----------------------------+----------+------+-----------+ 186 | Media Type | Encoding | ID | Reference | 187 +----------------------------+----------+------+-----------+ 188 | application/multipart-core | -- | TBD1 | RFCthis | 189 +----------------------------+----------+------+-----------+ 191 4. Security Considerations 193 The security considerations of [RFC7049] apply. In particular, 194 resource exhaustion attacks may employ large values for the byte 195 string size fields, or deeply nested structures of recursively 196 embedded application/multipart-core representations. 198 5. References 200 5.1. Normative References 202 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 203 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 204 October 2013, . 206 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 207 Application Protocol (CoAP)", RFC 7252, 208 DOI 10.17487/RFC7252, June 2014, 209 . 211 5.2. Informative References 213 [I-D.ietf-ace-coap-est] 214 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 215 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 216 coaps)", draft-ietf-ace-coap-est-03 (work in progress), 217 June 2018. 219 [I-D.ietf-cbor-cddl] 220 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 221 definition language (CDDL): a notational convention to 222 express CBOR data structures", draft-ietf-cbor-cddl-02 223 (work in progress), February 2018. 225 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 226 Specifications and Registration Procedures", BCP 13, 227 RFC 6838, DOI 10.17487/RFC6838, January 2013, 228 . 230 Acknowledgements 232 Most of the text in this draft is from earlier contributions by two 233 of the authors, Thomas Fossati and Klaus Hartke. The re-mix in this 234 document is based on the requirements in [I-D.ietf-ace-coap-est], 235 based on discussions with Michael Richardson, Panos Kampanis and 236 Peter van der Stok. 238 Authors' Addresses 240 Thomas Fossati 241 Nokia 243 Email: thomas.fossati@nokia.com 245 Klaus Hartke 246 Ericsson 247 Torshamnsgatan 23 248 Stockholm SE-16483 249 Sweden 251 Email: klaus.hartke@ericsson.com 253 Carsten Bormann 254 Universitaet Bremen TZI 255 Postfach 330440 256 Bremen D-28359 257 Germany 259 Phone: +49-421-218-63921 260 Email: cabo@tzi.org