[core] PubSub - Questions round 1

[Jim Schaad]

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?

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.

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?

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.

Jim

[Ari Keränen]

Hi Jim,

Here's finally answers to some of your questions.

Post by Jim Schaad
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.

Post by Jim Schaad
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.

Post by Jim Schaad
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.

Post by Jim Schaad
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

[Michael Koster]

Post by Ari Keränen
Hi Jim,
Here's finally answers to some of your questions.

Post by Jim Schaad
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.

Post by Ari Keränen
But would be great to hear more opinions on this.

Post by Jim Schaad
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.

Post by Jim Schaad
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).

Post by Ari Keränen

Post by Jim Schaad
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
https://www.ietf.org/mailman/listinfo/core

[Jim Schaad]

-----Original Message-----
Sent: Monday, March 19, 2018 7:25 PM
Subject: Re: PubSub - Questions round 1
Hi Jim,
Here's finally answers to some of your questions.

Post by Jim Schaad
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.

Post by Jim Schaad
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.

Post by Jim Schaad
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

Post by Jim Schaad
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

Post by Jim Schaad
"</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

Post by Jim Schaad
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

[Ari Keränen]

Hi Jim,

Post by Jim Schaad

Sent: Monday, March 19, 2018 7:25 PM

Post by Jim Schaad
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.

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]

[Christian Amsüss]

Hello working group,

Post by Jim Schaad
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?

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