Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2020-02-24
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-02-06
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-01-06
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-09-30
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-09-26
04 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2019-09-26
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-09-26
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-09-24
04 (System) RFC Editor state changed to EDIT
2019-09-24
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-09-24
04 (System) Announcement was received by RFC Editor
2019-09-23
04 (System) IANA Action state changed to In Progress
2019-09-23
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-09-23
04 Cindy Morgan IESG has approved the document
2019-09-23
04 Cindy Morgan Closed "Approve" ballot
2019-09-23
04 Cindy Morgan Ballot approval text was generated
2019-09-23
04 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-09-23
04 Alexey Melnikov RFC Editor Note was changed
2019-09-23
04 Benjamin Kaduk [Ballot comment]
Thank you for addressing my Discuss point!
2019-09-23
04 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-09-23
04 Alexey Melnikov RFC Editor Note was changed
2019-09-23
04 Alexey Melnikov RFC Editor Note for ballot was generated
2019-09-23
04 Alexey Melnikov RFC Editor Note for ballot was generated
2019-08-21
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-21
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-08-21
04 Carsten Bormann New version available: draft-ietf-core-multipart-ct-04.txt
2019-08-21
04 (System) New version approved
2019-08-21
04 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Thomas Fossati , Klaus Hartke
2019-08-21
04 Carsten Bormann Uploaded new revision
2019-08-13
03 Tero Kivinen Assignment of request for Last Call review by SECDIR to Matthew Miller was rejected
2019-05-02
03 Magnus Westerlund
[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 …
[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.
2019-05-02
03 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2019-05-02
03 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-05-02
03 Magnus Westerlund
[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 …
[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.
2019-05-02
03 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2019-05-02
03 Éric Vyncke
[Ballot comment]
Thank you to the authors for their work. Short and clear document, I have appreciated the example of CBOR encoding.

== comments == …
[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/  ?
2019-05-02
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-05-01
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-05-01
03 Benjamin Kaduk
[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 …
[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?
2019-05-01
03 Benjamin Kaduk
[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 …
[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.
2019-05-01
03 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-04-30
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-04-30
03 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-04-30
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-04-30
03 Alissa Cooper
[Ballot comment]
Please respond to the Gen-ART review.

= Section 2 =

"The second, fourth, sixth, etc. element is a
  byte string containing a …
[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."
2019-04-30
03 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-04-29
03 Adam Roach
[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 …
[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.
2019-04-29
03 Adam Roach Ballot comment text updated for Adam Roach
2019-04-29
03 Adam Roach
[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 …
[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.
2019-04-29
03 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-04-29
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-04-29
03 Martin Vigoureux
[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 …
[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
2019-04-29
03 Martin Vigoureux Ballot comment text updated for Martin Vigoureux
2019-04-29
03 Martin Vigoureux
[Ballot comment]
I guess 0x82 0x00 0x4b H e l l o 0x20 w o r l d / should be 0x82 0x00 0x4b H …
[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
2019-04-29
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-04-29
03 Mirja Kühlewind
[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? …
[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...
2019-04-29
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-04-24
03 Alexey Melnikov Ballot writeup was changed
2019-04-24
03 Roman Danyliw
[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) …
[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/
2019-04-24
03 Roman Danyliw Ballot comment text updated for Roman Danyliw
2019-04-24
03 Roman Danyliw
[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) …
[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/
2019-04-24
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-04-22
03 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2019-04-15
03 Cindy Morgan Placed on agenda for telechat - 2019-05-02
2019-04-15
03 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2019-04-15
03 Alexey Melnikov Ballot has been issued
2019-04-15
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-04-15
03 Alexey Melnikov Created "Approve" ballot
2019-04-15
03 Alexey Melnikov Ballot writeup was changed
2019-04-08
03 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-04-06
03 Scott Bradner Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Scott Bradner. Sent review to list.
2019-04-06
03 Stewart Bryant Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Stewart Bryant. Sent review to list.
2019-04-04
03 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-04-04
03 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-04-04
03 Sabrina Tanamal
(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 …
(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
2019-04-03
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-04-03
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-03-28
03 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2019-03-28
03 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2019-03-22
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Matthew Miller
2019-03-22
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Matthew Miller
2019-03-20
03 Jaime Jimenez
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 …
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?
2019-03-20
03 Jaime Jimenez
##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 …
##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?
2019-03-18
03 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-03-18
03 Amy Vezza
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, …
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.




2019-03-18
03 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-03-18
03 Amy Vezza Last call announcement was changed
2019-03-17
03 Alexey Melnikov Last call was requested
2019-03-17
03 Alexey Melnikov Last call announcement was generated
2019-03-17
03 Alexey Melnikov Ballot approval text was generated
2019-03-17
03 Alexey Melnikov Ballot writeup was generated
2019-03-17
03 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2019-03-12
03 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2019-03-08
03 Jaime Jimenez To be added in the coming days
2019-03-08
03 Jaime Jimenez Responsible AD changed to Alexey Melnikov
2019-03-08
03 Jaime Jimenez IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2019-03-08
03 Jaime Jimenez IESG state changed to Publication Requested from I-D Exists
2019-03-08
03 Jaime Jimenez IESG process started in state Publication Requested
2019-03-08
03 Jaime Jimenez To be added in the coming days
2019-03-08
03 Jaime Jimenez TBD
2019-03-08
03 Jaime Jimenez Notification list changed to Jaime Jimenez <jaime.jimenez@ericsson.com>
2019-03-08
03 Jaime Jimenez Document shepherd changed to Jaime Jimenez
2019-03-08
03 Jaime Jimenez Changed consensus to Yes from Unknown
2019-03-08
03 Jaime Jimenez Intended Status changed to Proposed Standard from None
2019-03-08
03 Carsten Bormann New version available: draft-ietf-core-multipart-ct-03.txt
2019-03-08
03 (System) New version approved
2019-03-08
03 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Thomas Fossati , core-chairs@ietf.org, Klaus Hartke
2019-03-08
03 Carsten Bormann Uploaded new revision
2019-02-08
02 (System) Document has expired
2018-10-24
02 Carsten Bormann (this state change is housekeeping only, WG last call was issued 2018-10-17 by Jaime Jiménez)
2018-10-24
02 Carsten Bormann IETF WG state changed to In WG Last Call from WG Document
2018-08-07
02 Carsten Bormann New version available: draft-ietf-core-multipart-ct-02.txt
2018-08-07
02 (System) New version approved
2018-08-07
02 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Thomas Fossati , Klaus Hartke
2018-08-07
02 Carsten Bormann Uploaded new revision
2018-07-02
01 Carsten Bormann New version available: draft-ietf-core-multipart-ct-01.txt
2018-07-02
01 (System) New version approved
2018-07-02
01 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Thomas Fossati , Klaus Hartke
2018-07-02
01 Carsten Bormann Uploaded new revision
2018-06-25
00 Jaime Jimenez This document now replaces draft-bormann-core-maybe, draft-fossati-core-multipart-ct instead of None
2018-06-25
00 Carsten Bormann New version available: draft-ietf-core-multipart-ct-00.txt
2018-06-25
00 (System) WG -00 approved
2018-06-25
00 Carsten Bormann Set submitter to "Carsten Bormann ", replaces to draft-bormann-core-maybe, draft-fossati-core-multipart-ct and sent approval email to group chairs: core-chairs@ietf.org
2018-06-25
00 Carsten Bormann Uploaded new revision