Subject: [core] Protocol Action: 'Multipart Content-Format for CoAP' to Proposed Standard (draft-ietf-core-multipart-ct-04.txt)

From: The IESG <[email-masked]>
Date: Mon, 23 Sep 2019 10:35:27 -0700

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, <[email-masked]>
   Area Director: Alexey Melnikov, <[email-masked]>

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.