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

From: Michael Koster <[email-masked]>
Date: Mon, 8 Jul 2019 13:41:34 -0700

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 <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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Jul 2019 19:50:56 -0700

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 <[email-masked]> On Behalf Of Michael Koster
Sent: Monday, July 8, 2019 1:42 PM
To: core <[email-masked]>
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.

Best regards,

Michael

---

From: Michael Koster <[email-masked]>
Date: Mon, 8 Jul 2019 20:03:27 -0700

Hi Jim,

Thanks for the quick review.

> On Jul 8, 2019, at 7:50 PM, Jim Schaad <[email-masked]> wrote:
> 
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.

> 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.

> completely different location - including a URL to a different RS.  Is this
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.

---

From: Ari Keränen <[email-masked]>
Date: Thu, 11 Jul 2019 17:59:53 +0000

Hi Jim,

One clarification: we are not planning to completely dump link format but the idea is that it can be still supported for topic discovery (RD style):
https://github.com/core-wg/pubsub/blob/master/proposal.txt#L119

For the more complex things you would use CoRAL instead.

Cheers,
Ari

On 09/07/2019, 5.51, "core on behalf of Jim Schaad" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Jim Schaad <[email-masked]>
Date: Tue, 23 Jul 2019 08:41:48 -0400

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 <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, July 8, 2019 10:51 PM
To: 'Michael Koster' <michael.koster=[email-masked]>
Cc: 'core' <[email-masked]>
Subject: Re: [core] CoRE Pub/Sub proposal to resolve the one remaining major
issue

Jim

Hi,

Best regards,

Michael

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core