Subject: Re: [core] Pub/Sub update to use the core multipart content format

From: Michael Koster <[email-masked]>
Date: Sat, 2 Mar 2019 15:23:53 -0800

OK, I read the multipart draft (expired?) For the no data case we will just send an empty multipart payload (cbor x80).

It seems like every implementation of pub/sub will be required to support only link-format and multipart. The subtype support will be on a topic basis and maybe a broker should have some way to list a set of supported subtopics that it can handle. To remind people, a coap pub/sub broker doesn't have any notion of "resource state" other than a stored representation.

Best regards,

Michael

> On Mar 2, 2019, at 5:27 AM, Michael Koster <[email-masked]> wrote:
> 
> Hi,
> 
> I am editing the pub/sub draft today and thinking about the multipart content format as a way to provide a subscribe or retrieve response for the no data case.
> 
> It seems to require that the pub/sub client always support the multipart format, with no content being one of the format options signaled by something like "maybe".
> 
> Does this seem right to you also? Do we need to invent a new empty format code instead of a response code? 
> 
> Best regards,
> 
> Michael
> 
> 
> 
>

---

From: Jim Schaad <[email-masked]>
Date: Sat, 2 Mar 2019 19:41:37 -0800

Michael,

When I was suggesting using multipart I was thinking more in term of
publishing rather than retrieval.  It would allow for multiple formats to be
sent to the pub/sub server which the server would not need to think about
doing format conversion on but could still return only a single format.

I don't think that one wants to do a multipart retrieval as a general rule
unless the content really a multipart thing.  I guess that the server would
need to be told which way to treat things, but that seems to be a reasonable
query parameter for topic creation.

Jim

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Michael Koster
> Sent: Saturday, March 2, 2019 3:24 PM
> To: Ari Keränen <[email-masked]>; Jaime Jiménez
> <[email-masked]>
> Cc: [email-masked] WG <[email-masked]>
> Subject: Re: [core] Pub/Sub update to use the core multipart content
format
> 
> OK, I read the multipart draft (expired?) For the no data case we will
just
> send an empty multipart payload (cbor x80).
> 
> It seems like every implementation of pub/sub will be required to support
> only link-format and multipart. The subtype support will be on a topic
basis
> and maybe a broker should have some way to list a set of supported
> subtopics that it can handle. To remind people, a coap pub/sub broker
> doesn't have any notion of "resource state" other than a stored
> representation.
> 
> Best regards,
> 
> Michael
> 
> > I am editing the pub/sub draft today and thinking about the multipart
> content format as a way to provide a subscribe or retrieve response for
the
> no data case.
> >
> > It seems to require that the pub/sub client always support the multipart
> format, with no content being one of the format options signaled by
> something like "maybe".
> >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Koster <[email-masked]>
Date: Sun, 3 Mar 2019 04:53:59 -0800

Hi Jim,

I am proposing to use the multipart response to indicate that there aren't data to be returned on a subscribe operation.

We were proposing a new response code, but there was a lot of pushback on doing this, so we want to try the multipart format with an empty array (cbor x08).

It does require that a pub/sub client learn a little cbor and be able to unpack the intended payload from the embedded string.

Would the new response code be a better option after all? It it easier to teach clients about a new 2.xx response than a new format?

Best regards,

MIchael

> On Mar 2, 2019, at 7:41 PM, Jim Schaad <[email-masked]> wrote:
> 
> Michael,
>

---

From: Jim Schaad <[email-masked]>
Date: Sun, 3 Mar 2019 11:39:02 -0800

If I am being honest, I would really rather it be returned as "204 (No Content)".  That is, the server successfully processed the request and there is no content to be returned as this time.  I realize that this is not the precise definition of this code, but I think that the problem with using the multipart response is that there are other places where a similar response may be required.  Consider asking a sensor for a reading, but the sensor does not have a current value.  What is the response code that it should return for that?  In some ways it would seem that a better answer might be 5.03 with a suggested retry.

Jim

> From: Michael Koster <[email-masked]>
> Sent: Sunday, March 3, 2019 4:54 AM
> To: Jim Schaad <[email-masked]>
> Cc: Ari Keränen <[email-masked]>; Jaime Jiménez
> <[email-masked]>; [email-masked]
> Subject: Re: [core] Pub/Sub update to use the core multipart content format
> 
> Hi Jim,
> 
> I am proposing to use the multipart response to indicate that there aren't
> data to be returned on a subscribe operation.
> 
> We were proposing a new response code, but there was a lot of pushback on
> doing this, so we want to try the multipart format with an empty array (cbor
> x08).
> 
> It does require that a pub/sub client learn a little cbor and be able to unpack
> the intended payload from the embedded string.
> 
> Would the new response code be a better option after all? It it easier to
> teach clients about a new 2.xx response than a new format?
> 
> Best regards,
> 
> MIchael
> 
> > publishing rather than retrieval.  It would allow for multiple formats
> > to be sent to the pub/sub server which the server would not need to
> > think about doing format conversion on but could still return only a single
> format.
> >
> > I don't think that one wants to do a multipart retrieval as a general
> > rule unless the content really a multipart thing.  I guess that the
> > server would need to be told which way to treat things, but that seems
> > to be a reasonable query parameter for topic creation.
> >
> > Jim
> >
> >
> >> It seems like every implementation of pub/sub will be required to
> >> support only link-format and multipart. The subtype support will be
> >> on a topic
> > basis

---

From: Michael Koster <[email-masked]>
Date: Sun, 3 Mar 2019 13:50:21 -0800

The http semantics for 202 Accepted might be another option. It defers processing until later.

We currently propose 2.07 to be added to signal the no-data subscription response. It could be semantically aligned with HTTP or we could have it mean exactly what we want it to mean.

A broker can always offer the multipart format as an alternate way to interact if we want to allow both. If the client sends multipart in the accept header the server could signal no data through the content format.

Could we allow the client to choose content-centric signaling through content negotiation?

Best regards,

Michael

PS Sending an empty payload might work for some formats, and in some libraries, e.g. with senml+json [] or cbor x80, but it doesn't seem reliable for all possible formats. 

> On Mar 3, 2019, at 11:39 AM, Jim Schaad <[email-masked]> wrote:
> 
> If I am being honest, I would really rather it be returned as "204 (No Content)".  That is, the server successfully processed the request and there is no content to be returned as this time.