[core] pubsub short-review

[Christian M. Amsüss <[e-mail]>]

Hello pubsub authors,

I've gone through the current pubsub version on github, and while this
is not a full review (although in retrospect it has become quite a wall
of text -- if I had the time I'd write a shorter mail), there's some
questions I'd like to raise:

* message passing vs. eventual consistency: I'm getting mixed messages
  when reading the document here. On one side, pub/sub in general is
  described as a messaging paradigm, CoAP pub/sub is not differentiated
  in that property, and a "Broker MUST make a best-effort attempt to
  notify all clients [...] each time it receives a publish". That
  indicates that every single state change matters (though the
  best-effort wording foreshadows the trouble).

  On the other side, the subscribe operation is built on CoAP
  observation, which is an inherently eventually consistent thing. Even
  if the broker and client libraries can be configured to not swallow
  notifications that arrive too fast in sequence, there can always be
  intermediaries that execute their liberties under RFC7641 to poll
  instead or (being a server) "MAY choose to skip sending a notification
  if it knows that it will send another notification soon".

  The ways I see out of this are either to go with a full a messaging
  concept (and implement a reliable message queue), or embrace the
  eventually consistent style, losen up on best-effort on state changes
  and make it clear in the introduction that representations of state,
  not messages, are kept in the topics. I have a preference for the
  latter.

* Failure 4.04 "Not Found": The difference between an empty list
  (empty payload in link-format) and the failure to find a list (4.04
  response) has been pointed out in the resource directory, and applies
  to the discovery interface just as well. (As a side effect, observing
  lists of topics becomes possible). I wouldn't quite classify that case
  as a failure -- both an empty-list result and no response on multicast
  are very successful results.

  (Following parallel discussion in RD, it might be worth reconsidering
  whether listing error codes for each operation really has value, given
  the list can not be exhaustive anyway, and regular CoAP processing
  needs to be applied).

* If I understand correctly, a topic can have sub-topics iff it is
  created with a link-format media type. On such topics the discover
  operation can be executed, while non-linkformat topics can be read.

  Does this allow the publication of general information in link format?
  How will this behave when there are other media types that express
  link-format-ish information?

  (There was the idea around after the presentation in Prague that
  suggests separating the topic metadata from its data -- or is that
  what is hinted at with the distinction between "/ps/parent-topic" and
  "/ps/parent-topic/"? If so, it could be more explicit).

* The create-on-publish operation is executed using PUT, which MUST be
  idempotent according to RFC7252 Section 5.1. Returning 2.01 Created on
  first put and 2.04 Changed on the second put is not exactly
  idempotent. A client behind an optimized intermediary or library may
  receive a 2.04 even on creation if one of the components forgoes
  message deduplication as given license to do in RFC7252 Section 4.5.

* The subscribe operation uses a whole lot of words to say that "CoAP
  observation as defined in RFC7641 can be used on topics".

  I have no issue with having examples for that or using more than 80
  characters to describe it, but this is phrasing requirements from
  other places into normative languages and IMO overspecifying.

* RFC6690 pet peeve: <subtopic> in the context of /ps/parent-topic/ does
  not mean what it appears to be, it resolves to /subtopic rather than
  /ps/parent-topic/subtopic according to the resoluton rules as I
  understand them.

* Brokerless pub-sub: What is the difference between a brokerless node
  with preconfigured topics that are subscribed to by other nodes, and a
  CoAP server? (Should I advertise rt=core.ps on every of my servers so
  I can become a brokerless pubsub server? What information does a
  client gain from discovering a given resource as being part of a
  pubsub server[1] vs.  discovering it on a CoAP server[2]?)

Best regards
Christian

[1]: executing figures 3 and 4 of the current git version
[2]: same with s/?rt=core.ps/?ct=40/ which implements regular gradual
  reveal

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn