Re: [core] PubSub - Questions round 1

[Michael Koster <[e-mail]>]

> On Mar 19, 2018, at 7:25 PM, Ari Keränen <[e-mail]> wrote:
> 
> Hi Jim,
> 
> Here's finally answers to some of your questions.
> 
>> On 14 Sep 2017, at 7.10, Jim Schaad <[e-mail]> 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.

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

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).
> 
>> 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
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core