[dispatch] Fw: Re: Proposal for Per Resource Events Protocol

[Rahul Gupta <[e-mail]>]

Dale,

Thank you for your interest and criticisms. Please see specific responses below.

------- Original Message -------
On Wednesday, August 9th, 2023 at 1:51 AM, [e-mail] [e-mail] wrote:

> 

> 

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


I accept this criticism and will add a simple explanation of how it works somewhere near the top, soon.

While not an excuse, please bear with me as this is my first attempt. And I appreciate your comment, as I find reading standards similarly hard. It is sometimes unclear based on my how best to structure the document. I will try my best to make changes that the document is more approachable.

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


GET is simpler as it is the default method for Fetch. There is already a precedent for changing the semantics of GET, for example, with the Range header (RFC9110, section 14.2) which already works well with caching.

I am not very aware of SIP. But I have never come across an instance of anyone implementing it for notifications of resource updates.

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


As far as I understand, this is a limitation of any system using HTTP streaming response.

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


The benefit of using multipart is that arbitrary messages formats for notifications can be used and these can be negotiated (unlike, say SSE). These formats as you righly point out cannot be to be mandated by the spec itself. Instead, these indeed need to be specified as mini-specifications (and I expect them to be standardized independently of the main spec). It is for this reason, I have indeed specified one such format for messages. Please see appendix A.

(Incidently, I used the pattern of RFC2046 itself as inspiration for this separation.)

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


Traditional mitigations (which are identical to SSE) are described in "Section 2.4 Known Limitations". However, there is no getting around these problems in that these are limitations of HTTP/1.1 and HTTP/2. In HTTP/2 the TCP connection are shared between subscriptions, but limited typically to 200-256 connections per domain. My proposal is that PREP be used with HTTP/2 and HTTP/3 but can provide backwards compatibility with HTTP/1.1 (with connections limits of 4-6 per domain as is typical for browsers today) in a pinch (with mitigations). Further, that I will propose a PREP-2 at a later time that drops this backwards compatibility in favour of taking advantage of HTTP/2 and/or HTTP/3 only features, circumnavigating these issues altogether. I believe that establishing backwards compatibility with HTTP/1.1 is unfortunately still necessary, despite the drawbacks!

> Dale


BR/Rahul