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

Jim Schaad <ietf@augustcellars.com> Sun, 03 March 2019 19:39 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2277D12E04D for <core@ietfa.amsl.com>; Sun, 3 Mar 2019 11:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m0n_6hYoo4Z for <core@ietfa.amsl.com>; Sun, 3 Mar 2019 11:39:11 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AEB124D68 for <core@ietf.org>; Sun, 3 Mar 2019 11:39:10 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 3 Mar 2019 11:39:03 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Koster' <michaeljohnkoster@gmail.com>
CC: =?utf-8?Q?'Ari_Ker=C3=A4nen'?= <ari.keranen@ericsson.com>, =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= <jaimejim@gmail.com>, <core@ietf.org>
References: <BAB1B7EB-825F-4A4E-B33F-9E46A8952752@gmail.com> <904CFCA3-F10A-4018-88AB-E859743B3E70@gmail.com> <006101d4d173$036f3150$0a4d93f0$@augustcellars.com> <27BF3A10-B9D8-435D-BA4E-64C244E516B2@gmail.com>
In-Reply-To: <27BF3A10-B9D8-435D-BA4E-64C244E516B2@gmail.com>
Date: Sun, 3 Mar 2019 11:39:02 -0800
Message-ID: <006e01d4d1f8$c30ed210$492c7630$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQL/ukJMv7OBeAhozsYlCRblR68qjAJlYhGfAZ8INPoB4zUm9aN1PPVQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/RHecB6200oMOkVdT2x1RKCraQGM>
Subject: Re: [core] Pub/Sub update to use the core multipart content format
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Mar 2019 19:39:14 -0000

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 <michaeljohnkoster@gmail.com>
> Sent: Sunday, March 3, 2019 4:54 AM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: Ari Keränen <ari.keranen@ericsson.com>om>; Jaime Jiménez
> <jaimejim@gmail.com>om>; core@ietf.org
> 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 <ietf@augustcellars.com> 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 <core-bounces@ietf.org> On Behalf Of Michael Koster
> >> Sent: Saturday, March 2, 2019 3:24 PM
> >> To: Ari Keränen <ari.keranen@ericsson.com>om>; Jaime Jiménez
> >> <jaimejim@gmail.com>
> >> Cc: core@ietf.org WG <core@ietf.org>
> >> 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
> >> <michaeljohnkoster@gmail.com> 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
> >> core@ietf.org
> >> https://www.ietf.org/mailman/listinfo/core
> >