Re: [core] Review of draft-ietf-core-coap-pubsub-06

[Michael Koster <[e-mail]>]

Hi Jim,

Thanks for the review! You hit a lot of the squishy bits 

Sorry for the delay in processing. 

We incorporated some items in the current draft, others we will need to discussin the WG.

> On Jan 9, 2019, at 4:21 PM, Jim Schaad <[e-mail]> wrote:
> 
> Here is a more detailed review of this document:
> 
> 1.  Section 2 - You should update the keywords with text from RFC 8174

Did that
> 
> 2.  Section 2 - I am not sure that I would agree that a top corresponds to a
> valid CoAP URI.  I believe that this is really a CoAP URI-Path as the same
> topic could appear on different brokers or under different schemes.   The
> scheme/URI-host would appear to be the broker and not the topic.  This is
> re-enforced by the topic in section 3.4
> 
Fixed

> 3. Section 3.5 - I think that the brokerless in the title should be
> capitalized.
> 
Did that

> 4. Section 3.5 - I understand the use case for having a broker version of
> this protocol.  I am not clear why the brokerless version is useful.  It
> might be a good idea to include a description of where this would be used as
> opposed to normal CoAP functionality.
> 
Added some use case notes

> 5.  Section 4.1 - Should there be a resource type of 'core.ps.topic' to
> distinguish between resources which are supported by the server directly and
> those which are pub/sub topics.  This would complete the 'core.ps',
> 'core.ps.discover' set of resource types.  Specifically I am trying to map
> the different operations to the different resource types.
> 
See below in the discussion on ps and discover. I think tagging all topics with core.ps may be OK if they support topic creation, otherwise core.ps.topic may also be needed.

> 6. Section 4.1 - The definition of 'ps' implies that topics can be rooted at
> / rather than at /ps.  While I don't have a problem with this I think that
> by saying that it 'ps' is optional seems to be slightly odd.  It would make
> more sense to me to say that '{ps}' is not optional but can be the
> equivalent of '/.' The assumption in this case is that what would be
> returned by .w-k/core would be '</>;rt=core.ps;ct=40' rather than '<>' as
> the refpath.  
> 
Yes, that's what we want. We probably misunderstand URI template syntax. I think we confuse "ps" as a template variable vs. "ps" as a path segment string.
Are there any specific suggestions for how we could reorganize this? 

> 7. Section 4.1 - I am not completely clear on this.  Is DISCOVERY only
> supported by rt=coap.ps.discovery or is it also supported by rt=coap.ps?  

Support for discovery is optional, and indicated by including rt=coap.ps.discovery in the link that describes the "ps" resource.
If the link for the resource has only coap.ps then it is not expected to support discovery. 

The target attributes describe a service entry point. In the case of the pub/sub service and pub/sub topic discovery, we allow the broker to provide the functionality at every topic. More on this in the next comment.

> 8. Section 4.1 - Is discovery only permitted to find those resources which
> are subordinate to it for rt=coap.ps.discovery or can it search all topics
> published in the PS?
> 
The intention is for discovery to list all the topics that are sub-topics of the resource pointed to by the URI of the discovery request. We leave it open whether the server recursively descends, but on further thought we may need to say one way or the other. Maybe just the topics tagged with core.ps.discovery would be recursively listed (see next)

If you do discovery from the root resource ("ps" for example) you get a link-format listing of all topics. If you do discovery at some topic, you get a link-format listing of the subtopics of the target topic.

Perhaps we should explicitly require each topic and sub-topic link to include rt=core.ps (supports topic creation) and optionally core.ps.discovery (if the topic supportssub- topic discovery). If a link has neither, then it points to the content. This is also a way we could support link-format as content. If there are topics that don't support sub-topic creation, then we may also need something like core.ps.topic

Note all topics are technically sub-topics, at least of the "ps" entry point resource.

> 9.  Section 4.1 - Is there a policy of some type about what topics are and
> are not visible under .w-k/core?  I was planning to hide all of them and
> only expose them via the /ps resource.  This seems to be contra-indicated by
> the example in figure 5 but is similar to what happens in RD.
> 
It is intended to be entirely application-dependent which topics have links in well-known/core. Usually it would be only the ps entry point but we didn't want to restrict what may be included in w-k/core or how it must be organized.

> 10.  Section 4.2/3  You should think about what happens if I use a multipart
> content for publishing.  This would allow for publishing multiple content
> types at the same time which might be an interesting feature.  This allows
> for multiple content types w/o the broker having to do the content
> conversions.
> 
I think pub/sub will work with multipart content format as long as the broker can treat the published payloads as opaque. What are some potential issues?

> 11. Section 4.3 - Am I correct in assuming that max-age defaults to 60
> seconds for a publish operation?  There is a different default value
> specified for CREATE but not here.  Another possible default value would
> have been the topic lifetime.
> 
We thought we had a simple solution to lifetime in the last hallway call, but there are a number of issues. Mostly, Max-Age is for responses and we should come up with a different way to transmit data lifetime for push operations. Currently thinking a URI parameter in the query options would be appropriate, some version of "lt".

We also think there is a good case for separate handling of topic expiration and data expiration. Topic expiration should send 4.04 responses to observers and readers, and data ageing should be handled via Max-Age in notifications. We didn't get the design finished before the draft deadline, also it seems like we should have a WG discussion on the proposal. I will write up a github issue and we can go from there.

> 12. Section 5 - I think you need to re-write the text dealing with con as
> this does not appear to be in the RD any more.
> 
Con as in CON/NON? We do have a bit where we say that a READ or SUBSCRIBE maybe ack'ed and queued waiting for first publish.