Re: [core] CoRE Pub/Sub proposal to resolve the one remaining major issue
Jim Schaad <ietf@augustcellars.com> Tue, 23 July 2019 12:42 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 5C8C412024E for <core@ietfa.amsl.com>; Tue, 23 Jul 2019 05:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Kx-g4KUudLBm for <core@ietfa.amsl.com>; Tue, 23 Jul 2019 05:42:04 -0700 (PDT)
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 948F212013D for <core@ietf.org>; Tue, 23 Jul 2019 05:42:01 -0700 (PDT)
Received: from Jude (31.133.136.216) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 05:41:52 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Koster' <michael.koster=40smartthings.com@dmarc.ietf.org>
CC: 'core' <core@ietf.org>
References: <92FE42DF-31BF-49FA-A309-AFA1933BCF97@smartthings.com> <009301d53601$23259370$6970ba50$@augustcellars.com>
In-Reply-To: <009301d53601$23259370$6970ba50$@augustcellars.com>
Date: Tue, 23 Jul 2019 08:41:48 -0400
Message-ID: <01a901d54154$001e9440$005bbcc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHAyqZRr7ggpAGaGf0p3w2i6qQHVQFRWHropvaGwGA=
Content-Language: en-us
X-Originating-IP: [31.133.136.216]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/riVLZaymWtgLclfUBz9zdeauSWw>
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, 23 Jul 2019 12:42:05 -0000
Ok - Another item One of the really nice features that the old system had was the ability to have a hierarchy of topics. I think that we may want to change the proposal so that items are created in a tree and not have random names assigned to the topic description node. This would allow for a CoRAL navigation of topics to occur with child nodes being advertised. This is nice not only for the navigation abilities, but even more because it eases the settings of security on topics for creation and assignment of various topics. This would allow for both specifications of "Create is allowed for topic /foo/*" and also allow for some security settings to be propagated down a tree - such as "The ACE group identifier for this node and all child nodes to be BLAH". I don't know if inheritance of attributes is a generally desirable feature but it seems reasonable to me. Jim -----Original Message----- From: core <core-bounces@ietf.org> On Behalf Of Jim Schaad Sent: Monday, July 8, 2019 10:51 PM To: 'Michael Koster' <michael.koster=40smartthings.com@dmarc.ietf.org> Cc: 'core' <core@ietf.org> Subject: Re: [core] CoRE Pub/Sub proposal to resolve the one remaining major issue 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. 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. 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? 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 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core
- [core] CoRE Pub/Sub proposal to resolve the one r… Michael Koster
- Re: [core] CoRE Pub/Sub proposal to resolve the o… Jim Schaad
- Re: [core] CoRE Pub/Sub proposal to resolve the o… Michael Koster
- Re: [core] CoRE Pub/Sub proposal to resolve the o… Ari Keränen
- Re: [core] CoRE Pub/Sub proposal to resolve the o… Jim Schaad