Subject: [Ace] New Version of draft-fossati-core-multipart-ct-04.txt

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Jun 2018 16:55:10 +0200

In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed to introduce a media type for efficiently combining multiple representations, along with the Content-Format numbers of their media types, into a single representation.

I believe we have needed such a media type in other places, so I have extracted the content of that PR, and revved draft-fossati-core-multipart-ct (of 2013 vintage) with that.  This would give us a media type multipart/core for general use.  (Thanks are due to Klaus and Thomas for helping me with this little exercise.)

CoAP-EST is due to be finished very soon, and extracting this media type from the CoAP-EST draft should only be done if we can avoid creating a hazard for CoAP-EST to be delayed by this.

I don’t see such a hazard unless we are having fundamental problems with the approach (but do accept its limited use in the CoAP-EST space).
So it would be useful to get some quick reactions on whether we can go ahead with this.

If you don’t want to read the draft right now, its technical content is:
   multipart-core = [* multipart-part]
   multipart-part = (type: uint .size 2, part: bytes / null)

(Where “type” is the content-format identifier.)

Grüße, Carsten

> Name:		draft-fossati-core-multipart-ct
> Revision:	04
> Title:		Multipart Content-Format for CoAP
> Document date:	2018-06-05
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-fossati-core-multipart-ct-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/
> Htmlized:       https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-fossati-core-multipart-ct-04
> 
> Abstract:
>   This memo defines multipart/core, an application-independent media-
>   type that can be used to combine (even recursively) several different
>   media types into a single CoAP message-body with minimal framing
>   overhead, along with a CoAP Content-Format identifier.

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 05 Jun 2018 17:25:38 +0200

Hi Carsten et al.

I have looked at the multipart draft, and I am happy to see that the
CBOR array is maintained as proposed in est-coaps.
So now we have two drafts that both propose an almost identical new
media type.

The choice will be determined by the delay needed to (pre-)register the
new media type.
Will anyone start doing that for the multipart draft within a
foreseeable delay.
If not, I am happy to pre-register the new media type as specified in
coaps-est to avoid delaying est-coaps.

Looking forward to your reaction,

many thanks for your trouble to create an indenpendent draft.

peter
Carsten Bormann schreef op 2018-06-05 16:55:

> I don't see such a hazard unless we are having fundamental problems with the approach (but do accept its limited use in the CoAP-EST space).
> If you don't want to read the draft right now, its technical content is:
> (Where "type" is the content-format identifier.)
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Jun 2018 14:04:03 -0400

Carsten Bormann <[email-masked]> wrote:
    > I believe we have needed such a media type in other places, so I have
    > extracted the content of that PR, and revved
    > draft-fossati-core-multipart-ct (of 2013 vintage) with that.  This
    > would give us a media type multipart/core for general use.  (Thanks are
    > due to Klaus and Thomas for helping me with this little exercise.) 

    > CoAP-EST is due to be finished very soon, and extracting this media
    > type from the CoAP-EST draft should only be done if we can avoid
    > creating a hazard for CoAP-EST to be delayed by this.

    > I don’t see such a hazard unless we are having fundamental problems
    > with the approach (but do accept its limited use in the CoAP-EST
    > space).
    
    > So it would be useful to get some quick reactions on whether we can go

I'm very happy, as I posted in another message before I sync'ed my inbox
and got yours.

I also have use of this multipart/core in the constrained extensions to
BRSKI contained in 6tisch-dtsecurity-zerotouch.

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