Multipart Content-Format for the Constrained Application Protocol (CoAP)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: The IESG <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Jaime Jimenez <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Protocol Action: 'Multipart Content-Format for CoAP' to Proposed Standard (draft-ietf-core-multipart-ct-04.txt) The IESG has approved the following document: - 'Multipart Content-Format for CoAP' (draft-ietf-core-multipart-ct-04.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/
Technical Summary This memo defines application/multipart-core, an application-independent media-type that can be used to combine representations of zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. Working Group Summary The document has gone through multiple expert reviews and has been discussed at multiple face-to-face IETF meetings. This document was not controversial. Document Quality At least a couple of implementations are interested in implementing this document. Personnel Document Shepherd: Jaime Jiménez, <firstname.lastname@example.org> Area Director: Alexey Melnikov, <email@example.com>
RFC Editor Note Change the 3rd sentence in the 3 para of Section 1: OLD: In this respect, the basic intent of the application/multipart-core media type is like that of multipart/mixed (Section 5.1.3 of [RFC2046]). NEW: In this respect, the basic intent of the application/multipart-core media type is like that of multipart/mixed (Section 5.1.3 of [RFC2046]), however the semantics is relaxed to allow for both ordered and unordered collections of media types (*). ADD after the 3rd para: (*) Historical Note: Experience with multipart/mixed in email has shown that recipients that care about order of included body parts will process them in the order they are listed inside multipart/mixed and recipients that don't care about the order will ignore it anyway. The media type multipart/parallel that was intended for unordered collections didn't deploy.