[core] Review on draft-ietf-core-coap-pubsub-02

[Jim Schaad <[e-mail]>]

Status:  This document is not yet ready for a WGLC in my opinion. 

I have copied forward some comments from past reviews where I have not seem
them addressed or do not believe that they are sufficiently  dealt with.



* Section 3.4 - s/are hosted at the broker and all clients using the broker
share/are hosted by a broker and all clients using that broker share/ - a)
you can have multiple brokers and b) the name spaces in that case are going
to be distinct and potentially overlapping in name w/different values.

* Section 3.4 - "zero or more stored representations with a content-format"
I think this is supposed to be  "zero or more values - one content-format".
But the first time I read this, I read this as" zero or more representations
- each representation has a content format - may be zero or one (?) value".
I always worry about what is "current" not what is "history" and assume that
observe is correctly implemented.  Note this does go back to the question of
"is this a queue of values" that Hannes has raised in the past.

* Section 4.2 - cut and paste error for topic and q as template variables.
I believe that q should be removed from the template as it makes no sense.

* Section 4.2 - Is the following legal for payload of a create
"<mainTopic/subTopic>;ct=50"  - this is a legal link but may not be legal
for creation of a topic.  

* Section 4.2 - Is the following legal for the payload of a create
"<coap://localhost/ps/maintopic/subtopic>;ct=50" - The text current says the
target of the link is a "URI formatted string" rather than a fragment.

* Section 4.2 - I cannot tell if the requirement for returning 4.04 (not
found) is new in this document or should be part of RFC 6690 or not.  I
cannot seem to find this requirement in that document.  Are you sure you
want to do this rather than just return an empty content?  Should there be
an errata on RFC 6690?

* Section 4.2 - There is an implicit statement in section 4.3 that a single
content type is expected.  However, there is no explicit statement here that
a request with multiple content types is forbidden.  Is there really a
requirement that a single content type be required when creating a topic?
What happens if no 'ct' is specified?

* Section 4.3 - Is a server supposed to accept a publish operation to a
non-existent location with a POST method? 

* Section 4.3 - Is there any reason to accept publish via POST and not PUT?
Or the other way around?
 
* Section 4.3 - If no Max-Age is on the publish request, should the default
value be used or should an infinite value (i.e. absent) be used.  If a
Max-Age was supplied at the time the subject was created, does that change
things?  If a publish is done with a Max-Age greater than that provided at
creation, what should happen.  Which wins?

* Section 4.3 - Copy and paste error on the topic and q template variables.
Does 'q' even make sense here?

* Section 4.3 - Text dealing with propagating publish events up the tree to
keep nodes alive is missing.

* Section 4.4 - Copy and paste error on the topic and q template variables.
Does 'q' even make sense here?

* Section 4.4 - Is it permitted that a broker remove a subscription due to
lack of ACK for a CON w/o sending the "unsubscribed" message?  The document
does not seem to allow that.

* Section 4.5 - Copy and paste error on the topic and q template variables.
Does 'q' even make sense here?

* Section 4.6 - Copy and paste error on the topic and q template variables.
Does 'q' even make sense here?

* Section 4.7 - Is remove recursive?   

* Section 4.7 - What would the correct content be to send an unsubscribe
notification on a remove operation?  '2.07 no content' or '2.02' deleted or
'4.04' not found?

* Section 8 - If enforcing access policies is of importance, how are they
set?

* Section 8 - It may be that '4.01 Unauthorized' is a better response than
'4.04 Not Found' in some cases.  Doing this does not allow for probing of
what topics exist when one does not have access to the directory of topics.


* Consider the following scenario
  - Create node foo - ct=40, Max-Age=10
  - Create node foo/bar - ct=0, Max-Age=20
  - Publish to foo/bar @ time=5
  When you get to time=15, should the node foo be deleted or does the
max-age of foo/bar change that answer?

* Currently an application can use CON to ensure that a server will get a
message in the long run.  The fact that this is no doable here should be
briefly discussed as an client cannot know that a server has or has not
received a message.


Minor:

* Section 3.4 -  s$"EP-33543/sen$"/EP-35543/sen$ - either that or remove the
leading slash for sensors


Philosophy problem:

I am not happy with the way that 2119 language is sprinkled throughout this
document.  That is not a statement that you need to change it, but it is a
request that you revisit and look at what is there.  
* MUST and SHOULD statements need to be able to have some type of test
written from them.  If you cannot write a test, then using the key words is
probably incorrect.
* SHOULD and MAY statements ought to have some type of language about when
the action under consideration would not be done.  
* MAY statements are almost always a waste of time and should be written in
a different manner. 
    *  Consider the first sentence in section 4.3.  Is there a reason why
this is not changed to "This section is optional to implement." and leave it
at that?  
    *  Consider the second sentence in section 4.3.  It implies that there
is a third method that the client can use to publish, what is that method?
I don't currently know of one.  This saying "A client uses the POST or PUT
method to publish ..." seems to be an adequate statement w/o the MAY.  
* Once upon a time, there was a requirement to extract and test all of the
MUSTs in a document and a strong suggestion to test all of the SHOULDs in a
document.  Too many make things hard to see if you have adequate coverage.
Too few and you might not have interop working correctly.  In many cases, a
MUST can be expressed w/o the key work.  Consider the 2.04 sentence in
section 4.3 paragraph 1 - It can be written as "The broker returns a "2.04
Changed" response if the publish request is accepted".  This has the same
information as the current statement but w/o the MUST.  The two following
sentences should probably also be a MUST type statement so that a client
knows what is going on rather than returning something strange.  (That can
be countered in the case of '4.04 Not Found' to maybe be '4.01 Unauthorized'
as a reasonable response to prevent knowledge of what topics exist.)


Jim