Subject: Re: [core] PubSub - Questions round 1

From: Ari Keränen <[email-masked]>
Date: Mon, 19 Mar 2018 19:25:14 +0000

Hi Jim,

Here's finally answers to some of your questions.

> On 14 Sep 2017, at 7.10, Jim Schaad <[email-masked]> wrote:
> 
> 1  I am not clear what the visibility of the intermediate subtopic notes
> should be.  Should these nodes appear in the link list when doing a GET on
> the root of the pub-sub tree?  Should these nodes appear when doing a
> discovery on /.well-known/core?

I think the explicitly created topics should be visible in discovery. However, this includes the "main topics" created with CREATE interface. Perhaps the sub-topics under a main topic could be hidden from the root discovery since they can be discovered from the main topic.

But would be great to hear more opinions on this.

> 2.  I would appreciate a discussion for section 5 (resource directory) on
> what the trade-offs for publishing items into a resource directory?  What
> sets of nodes does it make sense to publish vs not publish - topics of
> discussion would include intermediate nodes and max-age for nodes that might
> disappear quickly.

I think lots of this is going to be implementation dependent. We could perhaps discuss the benefits of sub-topics: that you can expose only the main topic(s), let client discover sub-topics if needed, and this way save bandwidth on discovery is there are lots of sub-topics under different main topics. I'll make a PR out of this.

> 3.  When doing discovery, I am not sure if you examples are correct.  My
> understanding is that since a URI path is being returned as part of the link
> format rather than a full path, the client is supposed to interpret this
> value using the GET path as the context of the path.   This would be rule c
> of section 2.1 of RFC6690.  This rule seems to have been modified for the
> /.well-known/core to say only use the scheme + authority and ignore the path
> to the resource.  However, I do not believe that this rule is suspended in
> this case.  This means that the return value for figure 4 would be
> "</currentTemp>;rt=temperature;ct=50".   Do you believe that I am wrong?

I think you're correct here. But I wonder how can we generate then topics outside of the ps -- or if we want to do that. Let's discuss tomorrow.

> 4.  Just because I don't understand.  In RFC 6690  - what is the origin for
> rule (b)?  I would have thought this was the target URI value itself, but in
> that case I would expect that (b) should be before (a) if it has a schema
> and thus is an absolute path.

I suppose it's the link authority. But let's check with Zach ;)

Cheers,
Ari

---

From: Michael Koster <[email-masked]>
Date: Mon, 19 Mar 2018 20:10:59 +0000

> On Mar 19, 2018, at 7:25 PM, Ari Keränen <[email-masked]> wrote:
> 
> Hi Jim,
> 

Specifically, I would say that the "main" topics are the ones that are created using the resource labeled rt=core.ps. Sub-topics, which are created under "main" topics can in turn have sub-topics created under them, and so on. We propose that only the topics created under the core.ps resource will be returned on discovery using core.ps.discover. Any sub-topics would be discovered by using GET with an accept header option value that specifies link-format content. Each level sub-topic would need to be discovered this way, until there are no links returned indicating theat there are no more sub-topics.
> I think you're correct here. But I wonder how can we generate then topics outside of the ps -- or if we want to do that. Let's discuss tomorrow.

To further discuss:

If the "currentTemp" topic was created by doing POST to the rt-core.ps resource (e.g. "/ps/") with a payload like <currentTemp>;ct=40 then the discovery will return </ps/currentTemp>;ct=40
If we wish to allow clients to create topics anywhere in the broker URI space, they can be created by doing POST to the rt-core.ps resource with a payload like </currentTemp>;ct=40 then the discovery will return </currentTemp>;ct=40
IOW, if the POSTed link contains a relative path (not starting with a slash) then the topic resource is created under the core.ps resource ("/ps/" in the example).
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Jim Schaad <[email-masked]>
Date: Tue, 20 Mar 2018 08:12:51 +0000

> -----Original Message-----
> From: Ari Keränen <[email-masked]>
> Sent: Monday, March 19, 2018 7:25 PM
> To: Jim Schaad <[email-masked]>
> Cc: core <[email-masked]>; [email-masked]
> Subject: Re: PubSub - Questions round 1
> 
> Hi Jim,
> 
> > 1  I am not clear what the visibility of the intermediate subtopic
> > notes should be.  Should these nodes appear in the link list when
> > doing a GET on the root of the pub-sub tree?  Should these nodes
> > appear when doing a discovery on /.well-known/core?
> 
> I think the explicitly created topics should be visible in discovery.
However,
> this includes the "main topics" created with CREATE interface. Perhaps the
> sub-topics under a main topic could be hidden from the root discovery
since
> they can be discovered from the main topic.
> 

No, that is not what I asked.  If I do a create of the topic

/PubSub/Hidden/MyTopic

Hidden has not yet be created as a topic so it will be implicitly created.
When I do the GET, I expect that MyTopic would be visible as part of the
link list but I am not clear that Hidden would be returned in the link list
because nobody explicitly created it.

> 
> > 2.  I would appreciate a discussion for section 5 (resource directory)
> > on what the trade-offs for publishing items into a resource directory?
> > What sets of nodes does it make sense to publish vs not publish -
> > topics of discussion would include intermediate nodes and max-age for
> > nodes that might disappear quickly.
> 
> I think lots of this is going to be implementation dependent. We could
> perhaps discuss the benefits of sub-topics: that you can expose only the
> main topic(s), let client discover sub-topics if needed, and this way save
> bandwidth on discovery is there are lots of sub-topics under different
main
> topics. I'll make a PR out of this.
> 
> > 3.  When doing discovery, I am not sure if you examples are correct.
> > My understanding is that since a URI path is being returned as part of
> > the link format rather than a full path, the client is supposed to
interpret
> this
> > of section 2.1 of RFC6690.  This rule seems to have been modified for
> > the /.well-known/core to say only use the scheme + authority and
> > ignore the path to the resource.  However, I do not believe that this
> > rule is suspended in this case.  This means that the return value for
figure 4
> would be
> I think you're correct here. But I wonder how can we generate then topics
> outside of the ps -- or if we want to do that. Let's discuss tomorrow.

Christian, please verify this for me.

Jim

> 
> > 4.  Just because I don't understand.  In RFC 6690  - what is the
> > origin for rule (b)?  I would have thought this was the target URI
> > value itself, but in that case I would expect that (b) should be
> > before (a) if it has a schema and thus is an absolute path.
>

---

From: Ari Keränen <[email-masked]>
Date: Tue, 20 Mar 2018 14:27:15 +0000

Hi Jim,

> On 20 Mar 2018, at 8.12, Jim Schaad <[email-masked]> wrote:

Yes, "Hidden" part would not be ever visible alone, only as part of the full "/PubSub/Hidden/MyTopic" topic.

The "implicitly created" Hidden topic is not actually a stand-alone topic at all. You can create stand-alone "parent" topics using the link format ct. 

I started yesterday to write a PR on this topic:
https://github.com/core-wg/pubsub/pull/23/files

Also related editorial fixes:
https://github.com/core-wg/pubsub/pull/20/files

Comments very welcome!

Cheers,
Ari

[clipped two other questions that are waiting for answer from someone else]

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 20 Mar 2018 23:24:07 +0000

Hello working group,

On Wed, Sep 13, 2017 at 09:10:34PM -0700, Jim Schaad wrote:
> This would be rule c

There's nothing special about .well-known/core, but Jim did discover
something nasty that I did not spot before:

RFC6690 link-format not only resolves the target relative to the link's
Context, but also has the default Context depend on the target
reference and strips any implicit base URI using the Origin concept of
RFC6454; something known neither from RFC5988 nor the current RFC8288.

This breaks the examples and convenient representations of
core-interfaces, core-coap-pubsub, and contradicts the mental model of
link-format semantics of everyone I have ever talked to about it. Unless
you have an anchor, links need to be absolute or path-absolute to behave
as expected. (resource-directory is largely safe because it exports
absolute URIs in resource lookups due to an already known part of those
issues).

So when you see

  GET coap://host/123/456/ returning
  <789/abc>;rel=member,<777/569>;rel=description

  it expresses links

  coap://hosts/ --(has member)--> coap://host/789/abc
                --(has member)--> coap://host/777/569

  where you would have expected (also in accordance to RFC8288)

  coap://hosts/123/456/ --(has member)--> coap://hosts/123/456/789/abc
                        --(has member)--> coap://hosts/123/456/789/569
  .

On the other hand,

  GET coap://host/123/999/ returning
  <789>;rel=boundto;anchor="coap://other/567/"

  expresses per RFC6690

  coap://other/567/ --(bound to)--> coap://other/567/789

  where a more intuitive interpretation would be

  coap://other/567/ --(bound to)--> coap://host/123/999/789

  .

Also, the rules make it impossible to express the respective RFC8288
links at all in a relative fashion; to make these statements, the server
producing the representation needs to be aware of the host name it is
queried as (and to draw the right conclusions, needs to agree with the
client on this). This is prone to misunderstandings when reverse proxies
are in use, and means that links that can be statically known (and thus
served directly from flash) need to be needlessly assembled by
constrained devices.

There is no motivation for this deviation from web linking in the
document.

It is my impression (and please PLEASE reply if I'm wrong) that nobody
has implemented those rules as they are laid out, at least not in a
system that deals with links where it makes a difference.

6690 is a request for comments. My I comment that its href/anchor
component is broken, and I propse that we do an RFC6690bis that
redefines ct=40 into to be closer to RFC8288.

If my impression about the state of deployment is wrong, my next best
suggestion is to deprecate it in favor of something that has better
defined semantics like CBOR-link-format (it does ... right?).

Best regards
Christian

-- 
Ceterum censeo Carthaginem delendam esse.
  -- M. Porcius Cato