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

Received changes through RFC Editor sync (created alias RFC 8710, changed title to 'Multipart Content-Format for the Constrained Application Protocol (CoAP)', changed abstract to '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 (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.', changed pages to 9, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-02-28, changed IESG state to RFC Published)

[Ballot comment]
Thanks for the rapid response. I am happy to clear. However, I think it would be good to be explict about that nesting is allowed in the definition even if the formal language implies it.

[Ballot discuss]
Are recursive application of the multipart format allowed? I don't find anyting disallowing that. I just want check that it is intentional before No Objection.

[Ballot comment]
Thank you to the authors for their work. Short and clear document, I have appreciated the example of CBOR encoding.

== comments ==

In section 2, I wonder the error in CBOR decoding: should it stop or completely ignore all parts of the message? Is there any use case where decoding only part of the messsage causes problem?


== nits ==

section 2, s/ specification: An/ specification: an/  ?

[Ballot discuss]
It's not clear to me that we're really specifying the semantics of a
single media-type.  The introduction discusses how we may want multiple
representations to appear in a sequence, potentially representing
different content.  Or we may have a set of related representations that
conceptually are the same content (but are they literally the same
resource, or related content?).  And there is yet a third option -- one
that I'm not sure I fully understand -- wherein the representation is
not important, but rather which format is chosen of the several
possibilities, to the extent that extreme compression of the
representation is possible, with the compression just outputting the
format indicator.

I don't see that any of these three cases are mutually compatible with
each other -- are we not defining three different semantical
representations that share a common syntax?  How does a receiver know
which semantics to apply, if they share a common media-type codepoint?

[Ballot comment]
The security considerations seem incomplete, at least given my
understanding of the intended technical semantics for the media-type.
Specifically, there is no discussion of how the recipient chooses which
semantics to apply (and the risks of choosing incorrectly), or
discussion of the latent risk when there are supposed to be multiple
equivalent or related components but that's not validated or the
recipient only acts on part of the data.

[Ballot comment]
Please respond to the Gen-ART review.

= Section 2 =

"The second, fourth, sixth, etc. element is a
  byte string containing a representation, or the value "null" if an
  optional part is indicated as not given.  The first, third, fifth,
  etc. element is an unsigned integer specifying the content format ID
  of the representation following it."

I think it would be more precise to refer to the "even-numbered elements" and the "odd-numbered elements" rather than enumerating the elements and saying "etc."

[Ballot comment]
Thanks for the work everyone put in on this document.

The "Usage Examples" section seems a bit odd, since it only describes the use of
this new content type for sending a response prior to the response body becoming
available. The introduction does not give the impression that this is the
primary use case -- it implies that this new format is primarily intended to
be used in a similar fashion as the traditional multipart/* media types.
Perhaps there should be some additional examples in section 3 that outline these
more common cases?

Alternately, if I have misunderstood the primary use case for this mechanism,
then I would humbly offer that the introduction needs substantial revision.

[Ballot comment]
Thanks for the work every put in on this document.

The "Usage Examples" section seems a bit odd, since it only describes the use of
this new content type for sending a response prior to the response body becoming
available. The introduction does not give the impression that this is the
primary use case -- it implies that this new format is primarily intended to
be used in a similar fashion as the traditional multipart/* media types.
Perhaps there should be some additional examples in section 3 that outline these
more common cases?

Alternately, if I have misunderstood the primary use case for this mechanism,
then I would humbly offer that the introduction needs substantial revision.

[Ballot comment]
I guess
0x82 0x00 0x4b H e l l o 0x20 w o r l d
should be
0x82 0x00 0x4b H e l l o 0x20 W o r l d

[Ballot comment]
I guess 0x82 0x00 0x4b H e l l o 0x20 w o r l d / should be 0x82 0x00 0x4b H e l l o 0x20 W o r l d

[Ballot comment]
One minor question: I don't fully understand why the new content format is called "application/multipart-core". Does "core" stand for the core working group? Shouldn't it rather be "application/multipart-coap"? Also why "multipart" and not e.g. "multicontent"? I guess it doesn't matter that much but was mainly wondering where the naming came from...

[Ballot comment]
A few minor nits/points:

(1) Section 1.  Grammar Nit.

s/This specification allows to indicate that/
This specification allows one to indication that/

(2) Section 1.  Per “A third situation that is common only ever has a single representation in the sequence, which is one of a set of formats possible”, it isn’t clear to me what the dependent clause, “which is one of the a set of formats”, is suggesting.  If there is only a single representation, how is there a “union of formats” as suggested by the follow-on sentence?

(3) Section 2.  The provided example of two representations is helpful.  It would be useful to carry this example through and use it again in Implementation Hints section.

(4) Section 2.  Per “(This generally means the representation is not processes at all except if some stream processing has already happened.)”, the target of this observation isn’t clear to me – perhaps the third clause from the previous sentence about left over data?

(5) Section 4.  Nits.  Make the section title case, like the other sections.

s/Implementation hints/Implementation Hints/

[Ballot comment]
A few minor nits/points:

(1) Section 1.  Grammar Nit.
s/This specification allows to indicate that/
This specification allows one to indication that/

(2) Section 1.  Per “A third situation that is common only ever has a single representation in the sequence, which is one of a set of formats possible”, it isn’t clear to me what the dependent clause, “which is one of the a set of formats”, is suggesting.  If there is only a single representation, how is there a “union of formats” as suggested by the follow-on sentence?

(3) Section 2.  The provided example of two representations is helpful.  It would be useful to carry this example through and use it again in Implementation Hints section.

(4) Section 2.  Per “(This generally means the representation is not processes at all except if some stream processing has already happened.)”, the target of this observation isn’t clear to me – perhaps the third clause from the previous sentence about left over data?

(5) Section 4.  Nits.  Make the section title case, like the other sections.

s/Implementation hints/Implementation Hints/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-multipart-ct-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new registration will be made as follows:

Name: multipart-core
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single, new registration will be made from the Expert Review range as follows:

Media Type: application/multipart-core
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

More readable here: http://jaimejim.github.io/temp/draft-ietf-core-multipart-ct.html

##Status Multipart CT


###Summary draft-ietf-core-multipart-ct-03

[Multipart Content-Format for CoAP](https://tools.ietf.org/html/draft-ietf-core-multipart-ct-03)

The purpose of the draft is to define how to combine representations of various media types into a single message.
The draft explains how the encoding is made, which is in form of a collection of CBOR entries with the various media types. For example: `[42, h'0123456789abcdef', 0, h'3031323334']`

multipart ct can be very useful when observing resources of which no representation is available at the time of the observation. The coap server may use the `application/multipart-core` media type in order to maintain the same Content-Format until the actual response (2.05, 2.03) is produced.

----


## Shepherd Writeup

###Summary

Document Shepherd: Jaime Jiménez,

Area Director: Alexey Melnikov,

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.

The document is intended for Standards Track.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
`Mail sent to media-types@iana.org, waiting for answer. New entry multipart-core needs verification by media-types@iana.org.`
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
`no issues found`
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
`Both seem correct to me`
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
`Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`The new application/multipart-core media type seems well defined. So is TBD1, which is the requested Content-Format, as shown on section 5.2.`
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
`no new registries`
* [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

##Status Multipart CT


###Summary draft-ietf-core-multipart-ct-03

[Multipart Content-Format for CoAP](https://tools.ietf.org/html/draft-ietf-core-multipart-ct-03)

The purpose of the draft is to define how to combine representations of various media types into a single message.
The draft explains how the encoding is made, which is in form of a collection of CBOR entries with the various media types. For example: `[42, h'0123456789abcdef', 0, h'3031323334']`

multipart ct can be very useful when observing resources of which no representation is available at the time of the observation. The coap server may use the `application/multipart-core` media type in order to maintain the same Content-Format until the actual response (2.05, 2.03) is produced.

----


## Shepherd Writeup

###Summary

Document Shepherd: Jaime Jiménez,

Area Director: Alexey Melnikov,

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.

The document is intended for Standards Track.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
`Mail sent to media-types@iana.org, waiting for answer. New entry multipart-core needs verification by media-types@iana.org.`
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
`no issues found`
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
`Both seem correct to me`
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
`Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered?
`Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`The new application/multipart-core media type seems well defined. So is TBD1, which is the requested Content-Format, as shown on section 5.2.`
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
`no new registries`
* [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

The following Last Call announcement was sent out (ends 2019-04-08):

From: The IESG
To: IETF-Announce
CC: jaime.jimenez@ericsson.com, draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com, core-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multipart Content-Format for CoAP) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Multipart Content-Format for
CoAP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ballot/


No IPR declarations have been submitted directly on this I-D.