Skip to main content

Multipart Content-Format for the Constrained Application Protocol (CoAP)
draft-ietf-core-multipart-ct-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
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
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/


Ballot Text

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

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.