Re: Fw: Proposal for Per Resource Events Protocol

I have submitted my proposal for the Per Resource Events  <https://github.com/CxRes/prep> Protocol as an Internet-Draft https://datatracker.ietf.org/doc/draft-gupta-httpbis-per-resource-events/
(in the nick of time for IETF118).

Feedback welcome...

Kindly include it in the agenda for IETF118. 

Best Regards,
Rahul
------- Original Message -------
On Wednesday, August 30th, 2023 at 03:19, Rahul Gupta <cxres@protonmail.com> wrote:


> To the IETF HTTP WG,
> 

> 

> I am forwarding my proposal for the Per Resource Events Protocol <https://cxres.github.io/per-resource-events/protocol> made to the Dispatch WG in early August on the advice of Francesca Palombini.
> 

> 

> In the time since I have published this proposal, I was contacted by Michael Toomim on the Dispatch mailing list, who has made a very similar proposal as part of the Braid Protocol (which is already in the consideration of HTTP WG). The primary difference between our proposals is that PREP (which is concerned only with notifications) is more general, in that it supports any message format for notifications, whereas Braid is more specific to communicating merge patches for state synchronization (which is the larger concern of the Braid Protocol). This gives me confidence that the proposal here is a step in the right direction.
> 

> I look forward to your feedback and seek your help in carrying this work forward.
> 

> Best Regards,
> Rahul
> 

> ------- Forwarded Message -------
> From: Rahul Gupta <cxres@protonmail.com>
> Date: On Monday, August 7th, 2023 at 8:03 AM
> Subject: Proposal for Per Resource Events Protocol
> To: dispatch@ietf.org <dispatch@ietf.org>
> 

> 

> > To the IETF Dispatch WG,
> > I would like to propose Per Resource Events <https://cxres.github.io/per-resource-events/protocol> as a protocol for standardization at IETF. The Per Resource Events Protocol (PREP), as the names suggests, allows a server to add notification capability to any resource to provide updates about its own representation changes.
> > 

> > Caveats
> > 

> > + Since this work arose from my work at a W3C Community Group, the specification currently is a W3C format. I shall convert it to an RFC format if IETF will consider this proposal.
> > 

> > + While I have motivated the design of the protocol in the specification document, I shall repeat some of it here to keep this message self-contained.
> > 

> > + Also, this is my first proposal at IETF and first time I am officially proposing a specification to any standards body, so I apologize in advance if I have not addressed the expected considerations.
> > 

> > 

> > Background
> > 

> > This specification has come about as an offshoot of my contribution as a co-author on the Solid Notification Protocol (SNP) <https:/github.com/solid/notifications> which is part of the Solid Project.
> > 

> > The Solid (Social Linked Data) is a web decentralization project led by Tim Berners-Lee which aims to allow users to keep control over their own data by (amongst other things) storing data in Personal Online Data Store (PODS). Solid Notification Protocol (SNP) is intended to add notification capabilities to Solid PODS over multiple messaging protocols (WebSockets, WebHooks, HTTP Streaming etc), though SNP is universal in that it can be used by any HTTP server to provide notifications.
> > 

> > Per Resource Events, similarly, is intended to add Notification capabilities to Solid PODS though again can be used by any HTTP server. PREP is a much simpler protocol built only using HTTP intended to make notifications significantly easier to implement and scale in most common scenarios.
> > 

> > 

> > Motivation
> > 

> > The Per Resource Event Protocol is predicated on a HTTP resource being the most intuitive source for notifications about its own updates.
> > 

> > This is unlike other notification protocols (e.g. WebSockets, WebSub, HTTP Push, SSE etc) that require additional resources to be specifically dedicated as endpoints for delivering notifications. Servers that provide updates are forced to maintain these additional endpoints and process changes to subject resources to dispatch as events. Clients that consume these updates have to discover these end points and then co-ordinate changes between the endpoint and (typically multiple) resources of interest.
> > 

> > By instead giving every resource the ability to send notifications when it updates, the Per Resource Event Protocol aims to reduce the complexity of both servers and clients implementing notifications; thus, making it easier for developers to build and maintain real-time applications.
> > 

> > 

> > 

> > How it works
> > 

> > When using PREP, a user agent desiring notification simply sends a GET request with an additional "Accept-Events" header.
> > 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).
> > 

> > 

> > 

> > Interest
> > 

> > While there are no implementations of PREP yet, there has already been a publicly expressed interest in implementing it by a commercial Solid PODS vendor (I have uploaded the first draft on GitHub only in late June). There have also been a couple of private queries for implementing for client applications, including one by a Solid “Creator”.
> > 

> > 

> > 

> > Limitations
> > 

> > 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. The current proposal is intended to establish backwards compatibility for notifications sent per resource. It is my intention to subsequently introduce PREP-2 (maybe PREP-3) that that advantage of HTTP/2 and HTTP/3 (but are not backwards compatible with HTTP/1.1) to provide more efficient notifications sans the aforementioned limitations. This consideration is already reflected in the current proposal; for example, the "Accept-Events" header is designed to be generic and can be used to negotiate the protocol used for notifications.
> > 

> > 

> > 

> > 

> > Thank you for your kind consideration,
> > 

> > 

> > Yours truly,
> > Rahul
> >