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

The IESG <iesg-secretary@ietf.org> Mon, 23 September 2019 17:35 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Multipart Content-Format for CoAP' to Proposed Standard (draft-ietf-core-multipart-ct-04.txt)
Auto-Submitted: auto-generated
Precedence: bulk
Cc: The IESG <iesg@ietf.org>, jaime.jimenez@ericsson.com, draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez <jaime.jimenez@ericsson.com>, core@ietf.org, alexey.melnikov@isode.com, core-chairs@ietf.org, rfc-editor@rfc-editor.org
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <156926012745.17094.14388659649525020899.idtracker@ietfa.amsl.com>
Date: Mon, 23 Sep 2019 10:35:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/-JVSqNhqmvCMICli678IRFTeS6o>

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, <jaime.jimenez@ericsson.com>
   Area Director: Alexey Melnikov, <aamelnikov@fastmail.fm>


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.

Protocol Action: 'Multipart Content-Format for Co… The IESG