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

[Jim Schaad <[e-mail]>]

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


> -----Original Message-----
> From: Michael Koster <[e-mail]>
> Sent: Sunday, March 3, 2019 4:54 AM
> To: Jim Schaad <[e-mail]>
> Cc: Ari Keränen <[e-mail]>; Jaime Jiménez
> <[e-mail]>; [e-mail]
> 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
> 
> > On Mar 2, 2019, at 7:41 PM, Jim Schaad <[e-mail]> wrote:
> >
> > 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 <[e-mail]> On Behalf Of Michael Koster
> >> Sent: Saturday, March 2, 2019 3:24 PM
> >> To: Ari Keränen <[e-mail]>; Jaime Jiménez
> >> <[e-mail]>
> >> Cc: [e-mail] WG <[e-mail]>
> >> 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
> >>
> >>> On Mar 2, 2019, at 5:27 AM, Michael Koster
> >> <[e-mail]> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> core mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/core
> >