[dispatch] Proposal for Per Resource Events Protocol

[Rahul Gupta <[e-mail]>]

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