Re: [core] pubsub short-review

[Carsten Bormann <[e-mail]>]

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.

>  (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).

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.

> * 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.

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
>  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.

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
>  other places into normative languages and IMO overspecifying.

+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