Re: [core] I-D Action: draft-ietf-core-coap-pubsub-13.txt

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

Hello pubsub authors, group,

(this starts as a public resubmit of an earlier direct message to Jaime,
and also discussed during [1], and goes into new examples),

The current pubsub draft appears to do the things well that it is
setting out to do -- and we should finish it already.

At the same time, I think it conflates things in a way I've generally
been uneasy about for some time, and that I'm more and more finding the
words to phrase: At the same time, pubsub does

* metadata about resources ("topic name", expiration management that
  exceeds max-age)
* delegation of authority (in a sense a pubsub topic is just a reverse
  proxy for a resource the publisher has, even though thanks to reversal
  of control flow that is rarely accessible directly),
* population of proxy caches in role reversal mode,
* and by combination of the latter two, sleepy devices (which we had a
  document on, and apparently that was such a patent mine field that
  everyone left it).

I don't think that those should lead to large alteration of the
document, but maybe the awareness of those components can help us toward
a structure that has more easily reusable parts.

To give examples of easy to address parts, I'd appreciate if
"topic-name" and "topic type" were phrased in a way that are compatible
with discovery: Is topic-name different from the title link-format
attribute of the data resource? Is topic-type different from the
resource type of the data resource? Is observer-check a variant that was
missed in conditional-attributes (c.pminconf)? These might be achievable
by some subtle renaming of parameters that are called TBDn so far
anyway.

Examples of the authority / proxying part are: Can a pubsub broker also
be used as a forward proxy without altering the authority component, so
that if a publisher `coap://device1.example.com` creates a topic and
announces that it would publish its own `/sensor1` resource in the
topic, the pubsub broker could be contacted by a subscriber to please
get `coap://device1.example.com/sensor1`, and the broker would send the
most recent published data? Can a publisher (under the same condition of
having the own-`/sensor1` metadata) tell the broker that it prefers not
to bother the broker with updates on each and every resource, but the
broker may start observing the relevant resources as soon as subscribers
are around? Sure: That's not the classical pubsub model. But to the
consumers it looks the same modulo some initial latency, and I think
that's what should matter in our specifications: Interface, not
implementation. Discussing the whole area is probably out of scope for
the document, but maybe we could point out something like:

> 1.4 Extensions from a collection of interfaces
>
> A pubsub broker fulfills multiple roles at once, providing interfaces
> for configuration, for publishers and subscribers. In addition to
> those interfaces, alternative interfaces may be provided. For example,
> publishers might configure a broker to observe their resources into a
> topic using the methods of {{?I-D.ietf-core-dynlink}}. Clients could
> be allowed to use the broker as a proxy to access resources on their
> original URIs (provided that metadata is deposited in the broker).
>
> Such extensions are out of scope of this document, as is discussing
> whether the resulting system would still be designated as a pubsub
> broker.

Best regards
Christian

[1]: https://datatracker.ietf.org/meeting/interim-2023-core-15/session/core

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom