Subject: [core] pubsub short-review

From: Christian M. Amsüss <[email-masked]>
Date: Mon, 1 Apr 2019 18:12:39 +0200

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Apr 2019 20:31:02 +0200

Hi Christian,

Thank you for this review.  The below comments focus on architectural and editorial issues in specifying CoAP applications like this; I might have a separate response on the pubsub application itself later.

>  the list can not be exhaustive anyway, and regular CoAP processing

Indeed.  However, if it is the normal result of an application state that results in an error response, it probably is worth to point that out in the definition of the application.

>  idempotent.

Idempotency in a REST context is with respect to the state on the server, not with respect to the response code.  Trivially, doing a DELETE will get you a 2.02 only on the first request and a 4.04 on all following ones.

> A client behind an optimized intermediary or library may

This is indeed an idiosyncrasy of CoAP over UDP, but note that something related happens with HTTP if the TCP connection breaks and you just don’t know whether the first request in an idempotent series was actually executed.

> [don’t do] phrasing requirements from

+1
It is not always wrong to remind the reader of a requirement already posed by a standard that is being used as a dependency, but this always MUST be clearly identified as a reminder and as following from the other standard.
Re-specifying bears the danger of creating something different, which forks the original standard.  (Compare the way ABNF was used in RFC 5988 and is used in RFC 8288 for an example of avoiding the problem.)

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 9 Apr 2019 11:45:40 +0200

Hello Carsten and pubsub authors,

> Indeed.  However, if it is the normal result of an application state
> that results in an error response, it probably is worth to point that
> out in the definition of the application.
> 
> Idempotency in a REST context is with respect to the state on the
> server, not with respect to the response code.  Trivially, doing a
> DELETE will get you a 2.02 only on the first request and a 4.04 on all
> following ones.

You're right, I missed that – implementors might still appreciate a note
that they could receive a 2.04 even if they just created the topic. In
the same vein, the 4.04 one could get on a DELETE is one of the protocol
error codes that would be worth pointing out.

Best regards
Christian

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables