> Why not? One reason not to use multipart might be because the CBOR data transports not multiple content-formats - but just one content-format. (It is CBOR (60). Or if we want to make it more specific, it is 'join-proxy-protocol-format' which is a specific structure encoded in CBOR). But that's just a viewpoint maybe, I can imagine we can also view this as two parts: one part is CBOR 'state' from the Join Proxy and another part is opaque 'DTLS record' binary data. Both would be feasible.
Another reason to say this was that the content-format of what's inside the opaque DTLS data isn't known by the Join Proxy, so it can't attach a numeric 'cf' type to that. Peter mailed me privately that this could be resolved by defining a CoAP content-format for "DTLS-record data". As alternative for this new Content-Format one could also define multipart as follows: [ 60 , <cbor-state-data> , 42 , <DTLS-record-data> ] So the DTLS data is labelled as application/octet-stream. Noting that the above CBOR is 4 bytes longer than [<cbor-state-data> , <DTLS-record-data> ] To consider: what advantage would we get from using the 4-byte-longer variant? Both are extendible in multiple ways ~ about roughly the same level of extendibility. Esko -----Original Message----- From: Carsten Bormann <[email protected]> Sent: Monday, November 30, 2020 14:12 To: Esko Dijk <[email protected]> Cc: [email protected]; peter van der Stok <[email protected]> Subject: Re: [Anima] draft-vanderstok-anima-constrained-join-proxy-04: how can J know the content-format cf On 2020-11-30, at 14:01, Esko Dijk <[email protected]> wrote: > > without using core-multipart Why not? Grüße, Carsten _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
