idnits 2.17.1 draft-fossati-core-multipart-ct-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 (June 08, 2018) is 2148 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-01 == 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 C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track June 08, 2018 5 Expires: December 10, 2018 7 Multipart Content-Format for CoAP 8 draft-fossati-core-multipart-ct-05 10 Abstract 12 This memo defines application/multipart-core, an application- 13 independent media-type that can be used to combine representations of 14 several different media types into a single CoAP message-body with 15 minimal framing overhead, each along with a CoAP Content-Format 16 identifier. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 10, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Multipart Content-Format Encoding . . . . . . . . . . . . . . 2 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Registration of media type application/multipart-core . . 3 56 3.2. Registration of a Content-Format identifier for 57 application/multipart-core . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 5.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 This memo defines application/multipart-core, an application- 68 independent media-type that can be used to combine representations of 69 several different media types into a single CoAP [RFC7252] message- 70 body with minimal framing overhead, each along with a CoAP Content- 71 Format identifier. 73 This simple and efficient binary framing mechanism can be employed to 74 create application specific request and response bodies which build 75 on multiple already existing media types. 77 Applications using the application/multipart-core Content-Format 78 define the internal structure of the application/multipart-core 79 representation. 81 For example, one way to structure the sub-types specific to an 82 application/multipart-core container is to always include them at the 83 same fixed position. This specification allows to indicate that an 84 optional part is not present by substituting a null value for the 85 representation of the part. 87 Optionally, an application might use the general format defined here, 88 but also register a new media type and an associated Content-Format 89 identifier -- typically one in the range 10000-64999 -- instead of 90 using application/multipart-core. 92 2. Multipart Content-Format Encoding 94 A representation of media-type application/multipart-core contains a 95 collection of zero or more representations, each along with their 96 respective content format. 98 The collection is encoded as a CBOR [RFC7049] array with an even 99 number of elements. The second, fourth, sixth, etc. element is a 100 byte string containing a representation, or the value "null" if an 101 optional part is indicated as not given. The first, third, fifth, 102 etc. element is an unsigned integer specifying the content format ID 103 of the representation following it. Where needed by an application, 104 each such format identifying element alternatively can be a text 105 string giving the media type name plus potentially some parameters. 107 For example, a collection containing two representations, one with 108 content format ID 42 and one with content format ID 0, looks like 109 this in CBOR diagnostic notation: 111 [42, h'0123456789abcdef', 0, h'3031323334'] 113 For illustration, the structure of an application/multipart-core 114 representation can be described by the CDDL [I-D.ietf-cbor-cddl] 115 specification in Figure 1: 117 multipart-core = [* multipart-part] 118 multipart-part = (type: uint .size 2 / text, part: bytes / null) 120 Figure 1: CDDL for application/multipart-core 122 3. IANA Considerations 124 3.1. Registration of media type application/multipart-core 126 IANA is requested to register the following media type [RFC6838]: 128 Type name: application 130 Subtype name: multipart-core 132 Required parameters: N/A 134 Optional parameters: N/A 136 Encoding considerations: binary 138 Security considerations: See the Security Considerations Section of 139 RFCthis 141 Interoperability considerations: N/A 143 Published specification: RFCthis 144 Applications that use this media type: Applications that need to 145 combine representations of potentially several media types into 146 one, e.g., EST-CoAP [I-D.ietf-ace-coap-est] 148 Fragment identifier considerations: N/A 150 Additional information: 152 Deprecated alias names for this type: N/A 154 Magic number(s): N/A 156 File extension(s): N/A 158 Macintosh file type code(s): N/A 160 Person & email address to contact for further information: 161 iesg&ietf.org 163 Intended usage: COMMON 165 Restrictions on usage: N/A 167 Author: CoRE WG 169 Change controller: IESG 171 Provisional registration? (standards tree only): no 173 3.2. Registration of a Content-Format identifier for application/ 174 multipart-core 176 IANA is requested to register the following Content-Format to the 177 "CoAP Content-Formats" subregistry, within the "Constrained RESTful 178 Environments (CoRE) Parameters" registry, from the IETF Review space 179 (specifically, 256..999): 181 +----------------------------+----------+------+-----------+ 182 | Media Type | Encoding | ID | Reference | 183 +----------------------------+----------+------+-----------+ 184 | application/multipart-core | -- | TBD1 | RFCthis | 185 +----------------------------+----------+------+-----------+ 187 4. Security Considerations 189 The security considerations of [RFC7049] apply. In particular, 190 resource exhaustion attacks may employ large values for the byte 191 string size fields, or deeply nested structures of recursively 192 embedded application/multipart-core representations. 194 5. References 196 5.1. Normative References 198 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 199 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 200 October 2013, . 202 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 203 Application Protocol (CoAP)", RFC 7252, 204 DOI 10.17487/RFC7252, June 2014, 205 . 207 5.2. Informative References 209 [I-D.ietf-ace-coap-est] 210 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 211 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 212 coaps)", draft-ietf-ace-coap-est-01 (work in progress), 213 June 2018. 215 [I-D.ietf-cbor-cddl] 216 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 217 definition language (CDDL): a notational convention to 218 express CBOR data structures", draft-ietf-cbor-cddl-02 219 (work in progress), February 2018. 221 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 222 Specifications and Registration Procedures", BCP 13, 223 RFC 6838, DOI 10.17487/RFC6838, January 2013, 224 . 226 Acknowledgements 228 Most of the text in this draft is from earlier contributions by 229 Thomas Fossati and Klaus Hartke. The re-mix in this document is 230 based on the requirements in [I-D.ietf-ace-coap-est], based on 231 discussions with Michael Richardson, Panos Kampanis and Peter van der 232 Stok. 234 Author's Address 235 Carsten Bormann 236 Universitaet Bremen TZI 237 Postfach 330440 238 Bremen D-28359 239 Germany 241 Phone: +49-421-218-63921 242 Email: cabo@tzi.org