Re: [dispatch] Proposal for Per Resource Events Protocol

[[e-mail]]

Some comments:

Rahul Gupta <cxres=[e-mail]> writes:
> I would like to propose Per Resource Events
> <https://cxres.github.io/per-resource-events/protocol> as a protocol
> for standardization at IETF.

Looking at that web page, I have to say I found it difficult to read.
It provides endless detail, but doesn't provide a clear summary that the
naive reader can read to grasp the big picture (and then fill in the
details reading the rest of the text).  Put something like your "How it
works" at the top.  Otherwise new readers will lose interest before
learning enough to understand why the proposal is valuable.

> How it works
>
> When using PREP, a user agent desiring notification simply sends a GET
> request with an additional "Accept-Events" header.

Why not use a new method rather than overloading GET?  For instance
SUBSCRIBE is already used in SIP with approximately the semantics you
want.  Using a separate method would ensure that caches, etc. could
treat subscription requests specially; by default, they wouldn't cache
them at all.

> If the resource is capable of and allowed to send notifications, the
> user agent receives these notifications as a multipart (RFC2046)
> response on an open-ended HTTP stream (for a fixed period or until the
> resource is deleted).

To add detail, "as an open-ended multipart response on an open-ended
HTTP stream".

Interestingly, this ensures that the subscription is terminated if the
subscriber fails, because the subscriber will no longer provide ACKs on
the TCP connection.

However, it looks like you don't specify what the notifications (the
body parts of the multipart) will look like.  That may be intended or
even necessary for this specification, but it means that every
implementation for an object has to design what its notifications will
look like.  As Mnot says, that's a negative:  "Intermediaries can't
understand application-specific semantics, so they can't add much value
to them without making some big assumptions."

> Mark Nottingham correctly points out on his blog
> <https://www.mnot.net/blog/2022/02/20/websockets> that HTTP based
> pub/sub protocols have not fulfilled their potential due to
> connections limits in HTTP/1.1 and head-of-line blocking in
> HTTP/2.

OK, how does PREP avoid these problems?  Given that is the first problem
that Mnot lists about event subscriptions, it would seem that would be
the key to getting PREP adopted.  But my naive reading suggests that
each active subscription occupies a single TCP connection.

Dale