Re: [core] CoRE Pub/Sub proposal to resolve the one remaining major issue

Michael Koster <michael.koster@smartthings.com> Tue, 09 July 2019 03:03 UTC

Return-Path: <michael.koster@smartthings.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 C4F511200E5 for <core@ietfa.amsl.com>; Mon, 8 Jul 2019 20:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.704
X-Spam-Level:
X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smartthings.com
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 blsoiwYXM8s1 for <core@ietfa.amsl.com>; Mon, 8 Jul 2019 20:03:31 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159AB1200DB for <core@ietf.org>; Mon, 8 Jul 2019 20:03:31 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id z75so8664630pgz.5 for <core@ietf.org>; Mon, 08 Jul 2019 20:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bjz5IJnH5K//FHfkhTAPOruaBeem7vzOXQyx5kHjY7U=; b=PbcacKzE1y6MX/rAgEFMBZBRJmCGT8lxHhYFiAAHe5L/u/N9yurJ87AS9djkIHX4rw kaFu/nWKBDNfbwvR3XjktLgOj0RCYl4AA+mN7jXNTX0CjaKOu/NwlARlQJE9N11gc5Ux P4emI8bRpmZKlrrm6QD8rYoI52Ii6RGXaqHxOx9JaWeNLGS2mqJHXBdNlLG22ZstWX7c tsLb//WjPSSKDnM5/mafcJbGPMM2WpvhzKoVgjsgUIHVcGA0L2N+auLjUBQBWFutlhbS beVVkKE9j1z9BgWX8MFsWPCfD7geiprmv7ClOhNw72+c7p1IED3eAJZz1yW7xCoL6gp8 47fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bjz5IJnH5K//FHfkhTAPOruaBeem7vzOXQyx5kHjY7U=; b=rXh9FpSzGlDHdet9QrF4fkh0bYjhDbA8XVsXXVR/+dknPCVAkEO9lB9li7hBi7ylTB IRf+gHI/6z6yLOEGhZoSdVoMA0rCD8sehxlwV+dHVVTFCZpp/9xQLV9nQR+zK9l4Oyuh JcSUMRGCWOuZQmbsIp0nJeMm8lnIPPCHDk1id68cr2x8YOBg8yZoSQNE6ciyXZdo7mqM 3woyQrdRwmMxtYoaP/RKOtvIdSyF0pHKbS/cKIM+IIjPSBJabivQy+xUFAJAHuc57z/c /Oy2ky1qz+4yOOcArZqeP4KTsv0U+5pUvseRt2B3d434oBVud1fMnDk3kkEXndYIQ6mU vmng==
X-Gm-Message-State: APjAAAUZkkdgA7940ngGt4q/QIBv4r34YWLR2FP0mlj8tfLCDcK1GChL 1Aegd3qpRJ8ajDb19VsFdscKL5JxXMzguA==
X-Google-Smtp-Source: APXvYqzWtBOHaSvXRBUkE56ThHWd9sPYF+7SjNZN6nOj29bqR7c7gP9wpH9gRD3uVw+Zjm2v8wOzpg==
X-Received: by 2002:a65:610a:: with SMTP id z10mr27894455pgu.178.1562641410188; Mon, 08 Jul 2019 20:03:30 -0700 (PDT)
Received: from [172.16.0.7] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id n140sm20021998pfd.132.2019.07.08.20.03.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 20:03:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Koster <michael.koster@smartthings.com>
In-Reply-To: <009301d53601$23259370$6970ba50$@augustcellars.com>
Date: Mon, 08 Jul 2019 20:03:27 -0700
Cc: core <core@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <18401305-0378-4BC2-B062-D5D3DA98B9C8@smartthings.com>
References: <92FE42DF-31BF-49FA-A309-AFA1933BCF97@smartthings.com> <009301d53601$23259370$6970ba50$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/IZokOBoKfwvkVOkXPHUb7YBSmSs>
Subject: Re: [core] CoRE Pub/Sub proposal to resolve the one remaining major issue
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: Tue, 09 Jul 2019 03:03:33 -0000

Hi Jim,

Thanks for the quick review.

> On Jul 8, 2019, at 7:50 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> I have a couple of clarifications that I would to get on this proposal:
> 
> 1.  It is not clear from the document, but I assume that the concept of
> topics as children of topics is still supported.    Thus  GET
> </ps/topic/1234/5677>  is a viable thing.
> 
We didn't work through this aspect in detail, but I would expect that the entry point of the create operation could be any topic and would result in a path as in your example. This is something we should work through a little more perhaps at the WISHI Hackathon session.

> 2.  Are we completely dumping link format in favor of CoRAL at this point?
> This is not something that I would object to I just want to be clear.
> 
Yes, we seemed to run into limitations trying to use link-format when we decided to use the control resource. Since the control resource needs a content-format it seems like CoRAL would be suited. The choice seems to be between a new response code (low appeal) and a common content-format (somewhat less objectionable). We point out that a CBOR library would already have most of the code for this and one wouldn't need an entire CoRAL processor.

> 3.  The picture in the overview and the examples given do not present the
> same picture.  I assume that there does not need to be any link between the
> path where the data exists and the path for the topic description.  It could
> be a child, as in the picture in the overview, in a parallel tree with the
> same naming, as in the examples in the document, or it could have a
> completely different location - including a URL to a different RS.  Is this
> right?
> 
I agree, there shouldn't need to be any URL pattern dependence between control resource and topic resource. It's an implementation question because the server returns the location for all topics. We'll need to flesh out topic discovery but it will be mostly the same. More food for the Hackathon session.

> Jim
> 
> 
> From: core <core-bounces@ietf.org> On Behalf Of Michael Koster
> Sent: Monday, July 8, 2019 1:42 PM
> To: core <core@ietf.org>
> Subject: [core] CoRE Pub/Sub proposal to resolve the one remaining major
> issue
> 
> Hi,
> 
> Klaus, Ari, and I created a proposal to resolve the "empty topic" issue (and
> others) without using a new status code or multipart content format.
> 
> Rather than update the draft, which technically requires WG consensus, we
> decided to publish the proposal and collect review comments between now and
> Montreal:
> https://github.com/core-wg/pubsub/blob/master/proposal.txt
> 
> We will take time at the WISHI hackathon to further refine it, and prepare a
> summary for the CoRE WG session.
> 
> We would like implementers in particular to review the proposal.
> 
> Best regards,
> 
> Michael
> 
> 
>