Re: [core] PubSub - Questions round 1

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Ari Keränen <[e-mail]>
> Sent: Monday, March 19, 2018 7:25 PM
> To: Jim Schaad <[e-mail]>
> Cc: core <[e-mail]>; [e-mail]
> Subject: Re: PubSub - Questions round 1
> 
> 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.
> 
> But would be great to hear more opinions on this.

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

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.
> 
> I suppose it's the link authority. But let's check with Zach ;)
> 
> 
> Cheers,
> Ari