Subject: [Dots] draft-ietf-dots-signal-channel-23: application/cbor media types

From: Klaus Hartke <[email-masked]>
Date: Wed, 29 Aug 2018 08:11:04 +0000

I've taken a brief look at draft-ietf-dots-signal-channel-23 in preparation for today's CoRE virtual interim meeting and noticed that it uses the media type "application/cbor" throughout the document, with payloads in one of the following shapes:

{ "ietf-dots-signal-channel:mitigation-scope": { ... } }

{ "ietf-dots-signal-channel:signal-config": { ... } }

{ "ietf-dots-signal-channel:redirected-signal": { ... } }

In CoRE, we generally encourage the use of more specific media types. Have you considered defining new media types, such as:

* application/dots-mitigation-scope+cbor

* application/dots-signal-config+cbor

* application/dots-redirected-signal+cbor

and omitting the {"ietf-dots-signal-channel:":...} wrapper?

Klaus

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 29 Aug 2018 09:31:26 +0000

Hi Klaus,

No, the WG has not discussed defining new media types. All the following shapes are mapped to CBOR key values (e.g. ietf-dots-signal-channel:signal-config is mapped to CBOR key value 1). 
I don't see a problem defining 4 specific media types, Can y please provide more details on the benefits of using specific media types in DOTS ?

Best Regards,
-Tiru

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Klaus Hartke
> Sent: Wednesday, August 29, 2018 1:41 PM
> To: [email-masked]
> Subject: [Dots] draft-ietf-dots-signal-channel-23: application/cbor media types
> 
> 
> 
> I've taken a brief look at draft-ietf-dots-signal-channel-23 in preparation for
> today's CoRE virtual interim meeting and noticed that it uses the media type
> "application/cbor" throughout the document, with payloads in one of the
> following shapes:
> 
> In CoRE, we generally encourage the use of more specific media types. Have
> you considered defining new media types, such as:
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 29 Aug 2018 11:01:06 +0000

> No, the WG has not discussed defining new media types. All the following
> shapes are mapped to CBOR key values (e.g. ietf-dots-signal-channel:signal-
> config is mapped to CBOR key value 1).
> I don't see a problem defining 4 specific media types, Can y please provide
> more details on the benefits of using specific media types in DOTS ?

The problem with this approach is: If everyone started using "application/cbor" with CBOR key value 1, how do you know that a payload is a ietf-dots-signal-channel:signal-config and not something else?

Of course, you can infer this from the context somehow; if you're a client talking to a DOTS server, then a CBOR payload will likely be DOTS data. But this implicit assumption usually leads to problems later when you start to extend your application, the data models and formats. It's usually much better to explicitly indicate the precise format of the payload in each message.

Unless there are DOTS-specific reasons against it, I'd recommend you define new media types and matching CoAP content formats. It's not a lot of work, since you're just specializing "application/cbor" and not inventing new media types from scratch.

Klaus

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 29 Aug 2018 12:56:09 +0000

> From: Klaus Hartke <[email-masked]>
> Sent: Wednesday, August 29, 2018 4:31 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]
> Subject: RE: draft-ietf-dots-signal-channel-23: application/cbor media types
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> > No, the WG has not discussed defining new media types. All the
> > following shapes are mapped to CBOR key values (e.g.
> > ietf-dots-signal-channel:signal- config is mapped to CBOR key value 1).
> > I don't see a problem defining 4 specific media types, Can y please
> > provide more details on the benefits of using specific media types in DOTS ?
> 
> The problem with this approach is: If everyone started using "application/cbor"
> with CBOR key value 1, how do you know that a payload is a ietf-dots-signal-
> channel:signal-config and not something else ?

By default DOTS signal Channel uses port number 4646 assigned by IANA and the DOTS server knows only DOTS requests will arrive on this port, and "DOTS Signal Channel Claims" registry will be created (just like it's done in https://tools.ietf.org/html/rfc8392) to accommodate new fields.  Do you still see a need to define specific media types for DOTS ?

-Tiru

> 
> Of course, you can infer this from the context somehow; if you're a client
> talking to a DOTS server, then a CBOR payload will likely be DOTS data. But this
> implicit assumption usually leads to problems later when you start to extend
> your application, the data models and formats. It's usually much better to
> explicitly indicate the precise format of the payload in each message.
> 
> Unless there are DOTS-specific reasons against it, I'd recommend you define
> new media types and matching CoAP content formats. It's not a lot of work,
> since you're just specializing "application/cbor" and not inventing new media
> types from scratch.
> 
> Klaus