Subject: [core] multipart/core

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Jun 2018 13:49:25 -0400

Jaime...

Carsten, Thomas and Klaus have just updated:
   <https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04>
which says very succintly:

   The collection is encoded as a CBOR [RFC7049] array with an even
   number of elements.  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.

   For example, a collection containing two representations, one with
   content format ID 42 and one with content format ID 0, looks like
   this in CBOR diagnostic notation:

      [42, h'0123456789abcdef', 0, h'3031323334']

EST-COAP (in the ACE WG) needs a multipart reply for the corner case of
server generated (private) keys. Servergen is supported in RFC7030, greatly
desired by some parties, although some parties deem it a mis-feature.

I can't see anything wrong with the draft as it is, and I'd like to see it
quickly adopted and WGLC'ed....

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 6 Jun 2018 09:10:37 +0000

Hi Michael,

the draft does indeed pretty straightforward and short, EST-COAP is not yet in WCLC or similar but if the ACE Chairs have some deadline in mind please let us know, to give enough time to the group to move this document forward.

Ciao,
- - Jaime Jiménez

> On 5 Jun 2018, at 20.49, Michael Richardson <[email-masked]> wrote:
> 
> 
> Jaime...
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 06 Jun 2018 11:14:38 +0200

Hi Jaime,

The draft est-coaps is an ACE WG draft
The multipart core is a personal draft; not CoRE yet.
I would be very much reassured if the WG adoption of multipart core
takes place shortly.

The WGLC of est-coaps may well be around ietf102.

greetings,

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Jun 2018 11:34:17 +0200

On Jun 6, 2018, at 11:14, Peter van der Stok <[email-masked]> wrote:
> I would be very much reassured if the WG adoption of multipart core takes place shortly.
> 

Right, and there is little reason to wait finishing multipart/core until est-coaps is finished.
The idea of multipart/core is really well-aged now; I think the only reason why we haven’t written it down yet was that we didn’t have a use case.
Now we seem to have two, and we should be able to go ahead with multipart/core very quickly.

Grüße, Carsten

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 6 Jun 2018 15:44:15 +0100

Hi,
I would like to quickly insert AD interrupt.

I had a quick look at draft-fossati-core-multipart-ct-04 and I think the 
proposed definition of multipart/core is syntactically incompatible with 
MIME. Please read sections 5.1 and 5.1.1 of RFC 2046. In particular, all 
multipart media types have to use syntax specified in RFC 2046, which 
this proposal violates.

To be clear, I am not against registering a media type which uses CBOR 
syntax for a collection of other media types. However this media type 
name can't use the "multipart" top level media type. You can either 
define a new "application" media type (e.g. application/multipart-core) 
or you can define a new top level media type different from "multipart". 
The process for definining a new top level media type is slightly more 
comlicated, so you should evaluate whether you want to do this.

Best Regards,
Alexey

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Jun 2018 16:54:54 +0200

Hi Alexey,

> I would like to quickly insert AD interrupt.

getting input from the media type (and core-parameters) experts would have been next on the list.
Thank you for accelerating that input a lot :-)

> I had a quick look at draft-fossati-core-multipart-ct-04 and I think the proposed definition of multipart/core is syntactically incompatible with MIME. Please read sections 5.1 and 5.1.1 of RFC 2046. In particular, all multipart media types have to use syntax specified in RFC 2046, which this proposal violates.
> 
> To be clear, I am not against registering a media type which uses CBOR syntax for a collection of other media types. However this media type name can't use the "multipart" top level media type. You can either define a new "application" media type (e.g. application/multipart-core) or you can define a new top level media type different from "multipart". The process for definining a new top level media type is slightly more comlicated, so you should evaluate whether you want to do this.

There is no particular need to use the top-level “multipart” (or any other top-level for that matter), so we would go for an application/ top-level.

(The draft from 2013 that this new version continues wasn’t suggesting a media type name, so the not-so-well-thought-out suggestion to use multipart/ was new in this version.) 

Questions to the WG:

Anyone have a problem with the name application/multipart-core?
(It’s not visible in the CoAP exchanges, we just see the content-format identifier there.
We could discuss whether that should be a single-byte identifier; the current draft goes for a two-byte one.)

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 06 Jun 2018 18:00:17 +0200

I'm fine with application/multipart-core

Peter
Carsten Bormann schreef op 2018-06-06 16:54:

> (It's not visible in the CoAP exchanges, we just see the content-format identifier there.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Wed, 6 Jun 2018 16:12:06 +0000

> draft goes for a two-byte one.)

I'd go with 1 byte, but I guess in this case - given the need to align with ACE
EST timing - the choice ultimately depends on the ETA for Expert vs IETF review?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jun 2018 13:47:24 -0400

> Anyone have a problem with the name application/multipart-core?

I have no objection to the name.
The only other name I might imagine is application/multipart-cbor, as
slightly more descriptive, but it's a bikeshed question.

    > current draft goes for a two-byte one.) 

I don't have a problem with a two-byte ID as the places where it will be used
will already be returning ~1k of data.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Jun 2018 20:35:59 +0200

Hi Michael,

> On Jun 6, 2018, at 19:47, Michael Richardson <[email-masked]> wrote:
> 

There is not that much CBOR there….  But the interesting point about this specific format is not so much the razor-thin CBOR envelope, but that this is using Content-Format identifiers from the CoRE Parameters registry — hence the “core” in the proposed name.  We may want to create similar formats that use string-based media-type names.  (We also could put in string-based media-types as an alternative to Content-Format Identifiers into this media type, though, if we want to reduce the number of such formats:

multipart-core = [* multipart-part]
multipart-part = (type: uint .size 2 / text, part: bytes / null)

Where “text” is a media type string (possibly including parameters).  Does this have a use case we care about?)

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 6 Jun 2018 20:51:27 +0200

> Where “text” is a media type string (possibly including parameters).  Does this have a use case we care about?)

For evolvability, we should add rules for processing parts that look
invalid at the moment. I can imagine the need for other representation
metadata in addition to the content format in the future, so there
might be a map in place of the uint. I wouldn't want to bloat the
format right now, though. Let's keep it small and focused, and allow
for evolving it later should the need arise.

Klaus

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jun 2018 18:10:50 -0400

> There is not that much CBOR there….  But the interesting point about
    > this specific format is not so much the razor-thin CBOR envelope, but
    > that this is using Content-Format identifiers from the CoRE Parameters
    > registry — hence the “core” in the proposed name.  We may want to

That's a reasonable argument for calling it multipart-core.

---

From: Jaime Jiménez <[email-masked]>
Date: Thu, 7 Jun 2018 07:33:09 +0000

Hi,

Thank you all for the constructive discussion. To summarise some of the raised points so far:

- Dependency on EST-COAP, which is targeted for WGLC in next IETF.
- Multipart/core can't be registered. AD pointed out that it is not possible to register "multipart" as a top-level media type. Author's proposal to rename it under application (i.e. - "application/multipart-core").
- Should the identifier be a single byte or two?
- Expert media-type review confirmation needed.

If the authors could submit a new version soon, I’ll trigger the WGA call so that we have consensus on the draft before next IETF.

Ciao!
- - Jaime Jiménez

> On 7 Jun 2018, at 1.10, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jun 2018 15:41:23 +0200

I updated the draft based on the input we have so far (thanks to everyone replying!).
(I added alternative text media-type labels as a trial balloon; we can always remove them in the WG discussion.
We can also decide between single-byte and two-byte identifier.)

Name:		draft-fossati-core-multipart-ct
Revision:	05
Title:		Multipart Content-Format for CoAP
Htmlized:       https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fossati-core-multipart-ct-05

This should be ready for working-group adoption call now.

Grüße, Carsten

Please initiate 

> On Jun 7, 2018, at 09:33, Jaime Jiménez <[email-masked]> wrote:
> 
> Hi,
>

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 11 Jun 2018 05:02:19 +0000

Dear all,

based on the ongoing discussion on the Multipart Content-Format for CoAP and the dependency with ACE, we will issue a 2 week Working group Adoption call for this draft.

Ciao!
- - Jaime Jiménez

> On 8 Jun 2018, at 16.41, Carsten Bormann <[email-masked]> wrote:
>

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 11 Jun 2018 09:02:14 +0200

I fully support the adoption of this document.
It is necessary for the publication of ietf--ace-est-coaps  draft in ACE

peter
Jaime Jiménez schreef op 2018-06-11 07:02:

> If the authors could submit a new version soon, I'll trigger the WGA call so that we have consensus on the draft before next IETF.
> 
> Ciao!
> - - Jaime Jiménez
> 

> There is not that much CBOR there....  But the interesting point about
> registry -- hence the "core" in the proposed name.  We may want to

-- 
]               Never tell me the odds!                 | ipv6 mesh
networks [ 
]   Michael Richardson, Sandelman Software Works        | network
architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on
rails    [

---

From: Padmakumar Subramani <[email-masked]>
Date: Thu, 14 Jun 2018 14:19:38 +0530

+1

On Mon, Jun 11, 2018 at 10:32 AM Jaime Jiménez <[email-masked]>
wrote:

> Dear all,
>
> based on the ongoing discussion on the Multipart Content-Format for CoAP
> and the dependency with ACE, we will issue a 2 week Working group Adoption
> call for this draft.
>
> Ciao!
> - - Jaime Jiménez
>
> Htmlized:
> https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-fossati-core-multipart-ct-05
>
> - Multipart/core can't be registered. AD pointed out that it is not
> possible to register "multipart" as a top-level media type. Author's
> proposal to rename it under application (i.e. -
> "application/multipart-core").
> If the authors could submit a new version soon, I’ll trigger the WGA call
> so that we have consensus on the draft before next IETF.
>
> Ciao!
> - - Jaime Jiménez
>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 18 Jun 2018 10:35:33 +0200

+1

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 18 Jun 2018 11:26:24 +0200

+1

Best,
Alexander

> Le 18 juin 2018 à 10:35, Klaus Hartke <[email-masked]> a écrit :
> 
> +1
>

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 18 Jun 2018 11:26:40 +0200

+1

Best,
Alexander

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jun 2018 14:09:50 +0200

On Mon, Jun 11, 2018 at 05:02:19AM +0000, Jaime Jiménez wrote:
> based on the ongoing discussion on the Multipart Content-Format for
> CoAP and the dependency with ACE, we will issue a 2 week Working group
> Adoption call for this draft.

Sounds like a good idea to me.

I would have expected such a media type to be evolved out of SenML or
CoRAL (like "two fat self links"), but having a way to do express the
simple case with a simple data structure and a timely standardization is
probably the better way indeed.

Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Shahid Raza <[email-masked]>
Date: Mon, 18 Jun 2018 12:28:16 +0000

+1

As a co-author of the EST-CoAPs draft, I support this as it is needed to finalise our draft. 
We will implement this, as a part of EST-CoAPs, as soon as it becomes official. 

Best,
Shahid

> On 18 Jun 2018, at 14:09, Christian Amsüss <[email-masked]> wrote:
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Fri, 22 Jun 2018 16:08:37 +0000

+1

This proposal also solves an issue with Observe when a change in the Content Format is needed (e.g., to send an error representation in the final notification).

It also contains the functionality https://tools.ietf.org/html/draft-bormann-core-maybe-00, which is interesting for CoAP PubSub. (Were there other use cases?)

> for evolving it later should the need arise.

OCF, for instance, uses a custom version option that must go along with the Content-Format option. Hence, the need for supporting a number of payload-defining elements appears valid.

The memo currently mentions the “format identifying element alternatively can be a text string giving the media type name plus potentially some parameters”. This looks like a side feature/hack to add string support in CoAP. However, this opens up a can of worms, as it invites to use undefined names and the parameters would lack proper definition. Parameters should rather use the option mechanism (properly define an option number) and be passed using a map mechanism as proposed by Klaus.

Best wishes,
Matthias

Von: core [mailto:[email-masked]] Im Auftrag von Jaime Jiménez
Gesendet: Montag, 11. Juni 2018 07:02
An: core
Betreff: [core] 🔔 WGA multipart/core

Dear all,

Ciao!
- - Jaime Jiménez

On 8 Jun 2018, at 16.41, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

Please initiate

On Jun 7, 2018, at 09:33, Jaime Jiménez <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Ciao!
- - Jaime Jiménez

On 7 Jun 2018, at 1.10, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 6, 2018, at 19:47, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 25 Jun 2018 12:10:53 +0000

Dear all,

seems that there is consensus to adopt the draft on "Multipart Content-Format for CoAP"
https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05 <https://tools.ietf.org/html/draft-fossati-core-multipart-ct-05>
 
The authors should submit a new version under draft-ietf. 

Thank you all!
- - Jaime Jiménez