Re: [core] 🔔 WGA multipart/core

+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?)

I also want to +1 an earlier comment by Klaus:

> 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.

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:core-bounces@ietf.org] Im Auftrag von Jaime Jiménez
Gesendet: Montag, 11. Juni 2018 07:02
An: core
Betreff: [core] 🔔 WGA multipart/core

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 <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:

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 <jaime.jimenez@ericsson.com<mailto:jaime.jimenez@ericsson.com>> wrote:

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 <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:

Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:

On Jun 6, 2018, at 19:47, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:

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

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.

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

_______________________________________________
core mailing list
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core