Per Resource Events Protocol

Conformance

Document Conventions

All of the text of this specification is normative except assertions, diagrams, examples, notes and sections explicitly marked as non-normative as described in [RFC2119].

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The above-mentioned key words are used exclusively in the normative parts of this document and appear only in all capitals.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Compliance with Other Specifications

In general, specifications interact with and rely on a wide variety of other specifications. In certain circumstances, unfortunately, conflicting needs require a specification to violate the requirements of other specifications. This specification denotes such transgressions as a wilful violation and records the reason for that violation. Other specifications that rely on this specification SHOULD do the same.

Specification Category

The Per Resource Events Protocol identifies the following Specification Category to distinguish the types of conformance:

• API,

• Notation/syntax,

• Set of events,

• Protocol.

Classes of Products

The Per Resource Events Protocol identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

Resource Server

A resource server that builds on HTTP origin server ([RFC9110] § 3.6 Origin Server) by defining header fields ([RFC9110] § 6.3 Header Fields) and media types ([RFC9110] § 8.3.1 Media Types).

Application Client

An application client that builds on HTTP user Aagent ([RFC9110] § 3.5 User Agents) by defining behaviour in terms of fetching [FETCH] across the platform.

Interoperability

Interoperability occurs between Application Client—Resource Server as defined by the Per Resource Events Protocol.

Application Client—Resource Server Interoperability

Interoperability of implementations for application clients and resource servers is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to the Per Resource Events Protocol.

1. Introduction

This section is non-normative.

The Per Resource Events Protocol defines a minimal HTTP-based framework by which clients can securely receive update notifications directly from any resource of interest on the Open Web Platform.

1.1. Motivation

This section is non-normative.

HTTP was originally designed to transfer a static documents within a single request and response. If the document changes, HTTP does not automatically update clients with the new versions. This design was adequate for web pages that were mostly static and written by hand.

But web-applications today are dynamic. They provide (near-)instantaneous updates across multiple clients and servers. The many workarounds developed over the years to provide real-time updates over HTTP have often proven to be inadequate. Web programmers instead resort to implementing custom messaging systems over alternate protocols such as WebSockets, which requires additional layers of code in the form of non-standard JavaScript frameworks to synchronize changes of state.

Per Resource Events is a minimal protocol built on top of HTTP that allows clients to receive notifications directly from a resource of interest. Unlike other HTTP based solutions, Per Resource Events Protocol supports the use of arbitrary media-types for notifications, which can be negotiated just like representations; thus giving implementers a lot of flexibility to customize notifications according to the needs of their application.

1.2. How it Works

This section is non-normative.

A client application that wishes to receive notifications about updates to a resource simply places a `GET` request on that resource with just one additional `Accept-Events` header. The server responds by sending, first the current representation of the resource (though a client can request for this to be skipped), followed by notifications sent in response to resource events as parts of a multipart response while the request is open.

If a server does not implement the Per Resource Events Protocol, the `Accept Events` header in a `GET` request is simply ignored. The resource returns the current representation thereby preserving backwards compatibility.

1.3. Scope

This section is non-normative.

The Per Resource Events Protocol specifies:

• a mechanism for the discovery of notification capabilities per resource,

• a mechanism to request notifications from a resource,

• representation and semantics for the response that transmits notifications (but not the representation and semantics for notifications themselves, see below),

The Per Resource Events Protocol does not specify:

• a specific authentication and authorization mechanism to be used with the Per Resource Events Protocol. Implementations are encouraged to use existing approaches for authentication and authorization.

• representation and semantics for notifications.

  • Implementations are free to use any media-type for notifications, which can be negotiated just like the content of the representation.

  • Implementations are also free to define additional semantics for a given media-type, when used to transmit notifications using the Per Resource Events Protocol. As an appendix to this specification, we define additional semantics when using the `message/rfc822` media-type to transmit PREP notifications.

1.4. Audience

This section is non-normative.

This specification is for:

• Server developers who wish to enable clients to listen for updates to particular resources.

• Application developers who wish to implement a client to listen for updates to particular resources.

2. Design

This section is non-normative.

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

This is unlike other notification protocols 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 clients that consume these updates have to co-ordinate data between the endpoint and a resource of interest.

By giving every resource the ability to send notifications when it updates, the Per Resource Events 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.

2.1. Principles

This section is non-normative.

The Per Resource Events Protocol treats notifications as a temporally extended representation of any resource. That is, a representation can describe not (just) the state of the resource but events on the resource. With HTTP allowing representations to provide a potentially unbounded stream of data, the Per Resource Events Protocol is able to communicate events on the resource as notifications.

2.2. Goals

This section is non-normative.

The goals of the Per Resource Events Protocol are:

• to provide notifications only using the HTTP protocol STD 97 [RFC9110] so that the clients are able to request for update notifications using the Fetch API [FETCH].

• to provide updates directly from the resource of interest, obliviating the need to connect to another endpoint for notifications, minimizing round-trips between clients and servers and the need to co-ordinate responses between a resource and the endpoint.

• to allow arbitrary representations for notifications. Implementers shall be able to provide notifications that are potentially more expressive when compared to existing HTTP based messaging protocols such as Server Sent Events [EVENTSOURCE].

2.3. Constraints

This section is non-normative.

To the extent feasible, the Per Resource Events Protocol:

• adheres to established practices and conventions. In particular, every attempt has been made to reuse existing protocols and specifications. Implementers shall be able to repurpose existing tools and libraries for implementing this specification.

• conforms to the REST Architectural Style [REST] and best practices for Building Protocols with HTTP [RFC9205]. This specification can, thus, be used to extend the capabilities of any existing HTTP resource to provide notifications. Implementers shall be able to scale notifications along with their data/applications.

2.4. Known Limitations

This section is non-normative.

The Per Resource Events Protocol only allows notifications to be sent for events on a given resource. It is not possible for resources to send notifications for arbitrary events such as state changes on multiple resources or combinations thereof. Implementations using Per Resource Events Protocol have to create separate resources to realize such notification endpoints. But this is no different from APIs built on top of existing messaging protocols (See, for example, [WEBSOCKETS] and [WEBSUB]).

Due to the limits on connections per domain, the Per Resource Events Protocol is not suitable for use with HTTP/1.1, especially when providing notifications for multiple resource from the same domain that might be accessed simultaneously. This limitation is identical to that of other HTTP based streaming based protocols such as Server-Sent Events [EVENTSOURCE]. Implementations are strongly encouraged to adopt HTTP/2 (or later) and implement mitigation strategies, such as to maximize the number of concurrent connections and to provide alternate locations for resources on different domains.

3. Terminology

Notification

A message sent to application clients (that had previously requested it) when an HTTP request made on a resource fulfils some specified criteria.

Base Response

The response that would have been returned were notifications not requested for in an otherwise identical HTTP request.

Event Field

A parameter for a protocol item in the `Accept-Events` header field or a member of the `Events` header field.

4. Header Fields

The Per Resource Events Protocol introduces new header fields. These header fields are not specific to the Per Resource Events Protocol. They can be used by other protocols that augment resources with the ability to send notifications.

Protocols MUST ensure that the semantics be so defined that these header fields are safely ignored by recipients that do not recognize them ([RFC9110] § 5.1 Field Names).

4.1. Accept-Events

The `Accept-Events` header field can be used by application clients to specify their preferred protocol for receiving notifications. For example, the `Accept-Events` header field can be used to indicate that the request is specifically limited to a small set of desired protocols, as in the case for notifications with the Per Resource Events Protocol.

When sent by a resource server in a response, the `Accept-Events` header field provides information about which notification protocols are preferred in a subsequent request to the same resource.

An application client MAY generate a request for notifications regardless of having received an `Accept-Events` header field. The information only provides advice for the sake of improving performance and reducing unnecessary network transfers.

Conversely, an application client MUST NOT assume that receiving an `Accept-Events` header field means that future requests will return notifications. The content might change, the server might only support notifications requests at certain times or under certain conditions, or a different intermediary might process the next request.

4.1.1. Validity

A recipient MUST ignore the `Accept-Events` header field received with a request method that is unrecognized or for which notifications response is not defined for a particular notifications protocol.

A recipient MUST ignore the `Accept-Events` header field received in response to a request method that is unrecognized or for which notifications discovery and/or response is not defined for a particular notifications protocol.

A recipient MUST ignore the `Accept-Events` header field that it does not understand.

A recipient MUST ignore the protocols specified in the `Accept-Events` header field that they are not aware of.

4.1.2. Syntax

`Accept-Events` is a List structured ([STRUCTURED-FIELDS] § 3.1 Lists) header field. Its members MUST be of type string that identifies a notification protocol. A protocol identifier MAY be followed with zero or more parameters defined by the given protocol, which MAY be followed by a `q` parameter.

Could the protocol identifier be a URL?

If the protocol is an identifier, do we need to define a registry?

The `q` parameter assigns a relative "weight" to the sender’s preference for a notification protocol with semantics as defined in [RFC9110] § 12.4.2 Quality Values. Senders using weights SHOULD send `q` last (after all protocol parameters). Recipients SHOULD process any parameter named `q` as weight, regardless of parameter ordering.

Note: Use of the `q` parameter name to negotiate notification protocols would interfere with any parameter having the same name. Hence, protocol parameters named `q` are disallowed.

4.2. Events

The `Events` header field is sent by a resource server to provide event fields in response to a request for notifications.

Where the `Accept-Events` header field sent in the request is ignored, a resource server MUST NOT send the `Events` header field in a response.

Conversely, a resource server MUST send the `Events` header field in a response, if the `Accept-Events` header field sent in the request is not ignored.

4.2.1. Validity

If the `Events` header field is sent in response to a request that does not contain the `Accept-Events` header field, the recipient MUST treat the response as invalid.

Does compliance with HTTP demand that we ignore the `Events` header? How will recipient process such a response that presumably contains notifications that it has not requested?

If the response contains a `Events` header field that the recipient does not understand or the `Events` header field specifies a `protocol` that the recipient does not understand, the recipient MUST NOT process the response. A proxy that receives such a message SHOULD forward it downstream.

Could the constraints on the `Events` field not being understood be more specific?

Such as:
"A recipient MUST ignore the `Events` header field received in response to a request method that is unrecognized or for which notifications response is not defined for a particular notifications protocol."

4.2.2. Syntax

`Events` is a Dictionary structured ([STRUCTURED-FIELDS] § 3.2 Dictionaries) header field. It MUST contain one member with the key `protocol` whose value identifies the notification protocol used in the response. It MAY contain other members that are defined by the given notification protocol.

5. Protocol

5.1. Event Fields

The Per Resource Events Protocol reuses existing HTTP fields ([RFC9110] § 5 Fields) as event fields. Any HTTP field MAY be used as an event field. For the limited context of notifications using the Per Resource Events Protocol, an event field with the same name as an HTTP field MUST have identical semantics to that HTTP field, unless otherwise specified.

This specification restricts `Accept-Events` and `Events` as Structured header fields [STRUCTURED-FIELDS]. From this it follows:

• An event field whose value is anything except an item without parameters MUST be specified in an Inner List ([STRUCTURED-FIELDS] § 3.1.1 Inner List).

• Unless otherwise specified, an event field that is not already defined as a Structured Field, therefore, MUST be handled as a Retrofit Structured Field [RETROFIT-FIELDS] when such handling is defined.

• An event field that is not already defined as a Structured Field but cannot be handled as a Retrofit Structured Field either, MUST be explicitly specified by the implementation.

5.2. Methods

For the Per Resource Events Protocol, `HEAD` ([RFC9110] § 9.3.2 HEAD) and `GET` ([RFC9110] § 9.3.1 GET) are the only methods in response to which notifications are advertised.

A resource server MUST NOT send the `Accept-Events` header field with `PREP` as a protocol in response to a request with any method other than `HEAD` or `GET`.

For the Per Resource Events Protocol, `GET` ([RFC9110] § 9.3.1 GET) is the only method by which notifications are requested and for which notifications response is defined.

An application client MUST NOT send the `Accept-Events` header field with `PREP` as a protocol in a request with any method other than `GET`.

An resource server MUST NOT send the `Events` header field with the parameter `protocol` with a value of `PREP` in response to a request with any method other than `GET`.

A resource server MUST NOT send the `Events` header field except in response to a `GET` request.

5.3. Status Codes

The Per Resource Events Protocol reuses existing HTTP status codes ([RFC9110] § 15 Status Codes) to describe the result of the request for notifications and the semantics of notifications in the response.

In response to a request where `Accept-Events` header field indicates `PREP` as the preferred protocol, a resource server that supports notifications using the Per Resource Events Protocol MUST communicate the status code for the notifications response using the `status` parameter in the `Events` header field.

For the limited context of notifications using the Per Resource Events Protocol, the status code communicated using the `status` parameter in the `Events` header field MUST have identical semantics to the corresponding HTTP status code, unless otherwise specified.

6. Discovery

Application clients can engage in reactive content negotiation to discover if a resource server supports notifications using the Per Resource Events Protocol on a given resource.

6.1. Request

An application client can discover the ability of a resource server to deliver PREP notifications for a target resource by sending a `HEAD` ([RFC9110] § 9.3.2 HEAD) request.

6.2. Not Available

In the response to a `HEAD` request, a resource server that does not provide notifications for the target resource using the Per Resource Events Protocol MUST NOT list `PREP` as as one of the available protocols in the `Accept-Events` header field.

6.3. Available

In response to a `HEAD` request, a resource server that serves notifications for the target resource using the Per Resource Events Protocol SHOULD include the `Accept-Events` header field, which MUST list `PREP` as one of the available protocols.

Associated with `PREP` list item, the resource server MUST include an `accept` event field with at least one acceptable media-type for notifications.

HEAD /foo HTTP/1.1
Host: example.org

HEADERS
  + END_HEADERS
  + END_STREAM
    :method = HEAD
    :scheme = https
    :authority = example.org
    :path = /foo

HTTP/1.1 200 OK
Accept: text/html
Accept-Events: PREP; accept=message/rfc822

HEADERS
  + END_HEADERS
  + END_STREAM
    :status = 304
    accept = text/html
    accept-events: PREP; accept=message/rfc822

7. Request

The Per Resource Events Protocol extends the content negotiation mechanism provided by HTTP allowing application clients to negotiate notifications independent of the base response.

In order to receive notifications using the Per Resource Events Protocol from a resource, an application client sends a `GET` request to resource server, which:

• MUST include the `Accept-Events` header field, which:

  • MUST list `PREP` as a preferred notification protocol.

    • MAY include zero or more event fields. For example, application clients MAY specify an `accept` event field to indicate a preferred media-type for notifications.

• MAY include the `Last-Event-ID` header field ([EVENTSOURCE] § 9.2.4 The `Last-Event-ID` header) requesting the resource server to not send the base response body and resume notifications from the event occurring immediately after the one specified.

GET /foo HTTP/1.1
Host: example.org
Authorization: DPoP <token>
DPoP: <proof>
Last-Event-ID: *
Accept-Encoding: gzip
Accept-Events: PREP; accept=message/rfc822; accept-encoding=identity

HEADERS
  + END_STREAM
  - END_HEADERS
    :method = GET
    :scheme = https
    :authority = example.org
    :path = /foo

CONTINUATION
  + END_HEADERS
    authorization = DPoP <token>
    DPoP = <proof>
    last-event-id = *
    accept-encoding = gzip
    accept-events = PREP; accept=message/rfc822; accept-encoding=identity

A resource server MUST ignore event fields for `PREP` notifications in the `Accept-Events` header that it does not recognize or implement.

8. Response without Notifications

8.1. Not Available

A resource server not implementing the Per Resource Events Protocol (or not supporting it for the target resource) can ignore a request for notifications and respond as if it received a normal request on that resource without impacting interoperability.

A resource server that does not provide notifications using the Per Resource Events Protocol MUST NOT:

• list `PREP` as as one of the available protocols in the `Accept-Events` header field, if sent in the response.

• send the `Events` header field in the response with the `protocol` event field set to `PREP`.

8.2. Error Response

A resource server MUST NOT include PREP notifications in a response, unless request results in one of the following status codes:

• `200 (OK)` ([RFC9110] § 15.3.1 200 OK),

• `204 (No Content)` ([RFC9110] § 15.3.5 204 No Content),

• `206 (Partial Content)` ([RFC9110] § 15.3.7 206 Partial Content),

• `226 (IM Used)` ([RFC3229] § 10.4.1 226 IM Used).

A resource server that does not serve PREP notifications, on account of the response not having one of the above-mentioned status codes:

• SHOULD include the `Events` header fields where:

  • the `protocol` event field MUST be set to a value of `PREP`,

  • the `status` event field MUST be set to `412 (Precondition Failed)` ([RFC9110] § 15.5.13 412 Precondition Failed) status code.

8.3. Notification Errors

A resource server might still not be able to send notifications using the Per Resource Events Protocol requested by an application client despite a valid response.

A resource server unable to serve PREP notifications, even when the request results in a status code mentioned in § 8.2 Error Response:

• SHOULD include the `Events` header fields in the response where:

  • the `protocol` event field MUST be set to a value of `PREP`,

  • the `status` event field MUST be set to appropriate status code indicating the reason for not serving notifications.

9. Notifications Response

9.1. Common Headers

A resource server providing notifications using the Per Resource Events Protocol:

• MUST include the following header fields in the response:

  • `Date` ([RFC9110] § 6.6.1 Date).

  • `Content-Type` ([RFC9110] § 8.3 Content-Type) with the media type set to `multipart` ([RFC9110] § 8.3.3 Multipart Types). The subtype will depend on whether the base response is included in the response body.

  • `Events` which MUST include the following event fields:

    • `protocol` set to the value `PREP`.

    • `status` set to the `200 (OK)` ([RFC9110] § 15.3.1 200 OK) status code.

    • `expires` with an integer value in seconds indicating an interval after `Date` when notifications will no longer be sent and the response stream is closed.

    NOTE: Since caching is meaningless in the context of notifications, this specifications repurposes the deprecated `Expires` header field to specify when the notifications response ends.

• SHOULD include the following header fields in the response:

  • `Vary` ([RFC9110] § 12.5.5 Vary) which MUST include `Accept-Events` as one of the values.

  • `Last-Modified` ([RFC9110] § 8.8.2 Last-Modified).

  • `ETag` ([RFC9110] § 8.8.3 ETag).

• MAY include the following header fields in the response:

  • `Accept-Events` which MUST list `PREP` as one of the available notification protocols. Associated with the `PREP` list item, the resource server:

    • MUST include an `accept` event field with at least one acceptable media-type for notifications.

9.2. Only Notifications

An application client requesting only notifications using the Per Resource Events Protocol needs to explicitly opt out of receiving the base response as described in § 7 Request.

A resource server MUST NOT send the [base response], if the request for PREP notifications includes the `Last-Event-ID` header field ([EVENTSOURCE] § 9.2.4 The `Last-Event-ID` header) which matches the `Event-ID` of the last event on the resource.

9.2.1. Headers

A resource server that provides only notifications using the Per Resource Events Protocol MUST include the `Vary` header field ([RFC9110] § 12.5.5 Vary) with `Last-Event-ID` as one of the values.

9.2.2. Body

A resource server MUST transmit PREP notifications as a multipart message body ([RFC2046] § 5.1 Multipart Media Type), with a media type of `multipart/digest` ([RFC2046] § 5.1.5 Digest Subtype) that MAY include zero or more body parts. Each body part of the multipart message body MAY contain at most one notification.

HTTP/1.1 200 OK
Vary: Accept-Events, Last-Event-ID
Accept-Events: PREP; accept=message/rfc822
Events: protocol=PREP, status=200, vary=accept-encoding
Last-Modified: Sat, 1 April 2023 10:11:12 GMT
Transfer-Encoding: chunked
ETag: 1234abcd
Content-Type: multipart/digest; boundary=next-message

--next-message
Content-Type: message/rfc822

<message>
--next-message-- 

HEADERS
  + END_HEADERS
  - END_STREAM
    :status = 304
    vary = accept-events, last-event-id
    accept-events = PREP; accept=message/rfc822
    events = protocol=PREP, status=200, vary=accept-encoding
    last-modified = Sat, 1 April 2023 10:11:12 GMT
    etag = 1234abcd
    content-type = multipart/digest; boundary=next-message

DATA
  - END_STREAM
--next-message

DATA
  - END_STREAM
content-type = message/rfc822
CRLF<message>
--next-message

DATA
  + END_STREAM
--next-message-- 

9.3. Composite Response

By default, the Per Resource Events Protocol requires a resource server to transmit the base response body before notifications. An application client MAY opt out of this behaviour as described in § 7 Request.

NOTE: Not only does this behaviour ensure interoperability, it is also desirable in most scenarios. It short-circuits an extra round trip that would be otherwise needed to fetch the current representation before notifications and eliminates the need to co-ordinate the two responses.

9.3.1. Headers

If the request for PREP notifications includes the `Last-Event-ID` header field, a resource server MUST include `Vary` header field ([RFC9110] § 12.5.5 Vary) with `last-event-id` as one of the values.

9.3.2. Body

Where the response includes a base response body prior to PREP notifications, a resource server MUST transmit a multipart message body ([RFC2046] § 5.1 Multipart Media Type) with a media type of `multipart/mixed` ([RFC2046] § 5.1.3 Mixed Subtype) with two body parts in the order specified below:

1. the message body that would have been sent had notifications not been requested.

2. the multipart response body with body parts containing notifications as defined in § 9.2 Only Notifications.

HTTP/1.1 200 OK
Vary: Accept-Events
Accept-Events: PREP; accept=message/rfc822
Events: protocol=PREP, status=200, vary=accept-encoding
Last-Modified: Sat, 1 April 2023 10:11:12 GMT
Transfer-Encoding: chunked
ETag: 1234abcd
Content-Type: multipart/mixed; boundary=main-boundary

--main-boundary
Content-Type: text/html
CRLF
<html>
--main-boundary
Content-Type: multipart/digest; boundary=next-message

--next-message
Content-Type: message/rfc822

<message>
--next-message-- 
--main-boundary-- 

HEADERS
  + END_HEADERS
  - END_STREAM
    :status = 304
    vary = accept-events
    accept-events = PREP; accept=message/rfc822
    events = protocol=PREP, status=200, vary=accept-encoding
    last-modified = Sat, 1 April 2023 10:11:12 GMT
    etag = 1234abcd
    content-type = multipart/mixed; boundary=main-boundary

DATA
  - END STREAM
--main-boundary
Content-Type: text/html
CRLF
<html>
--main-boundary

DATA
  - END STREAM
Content-Type: multipart/digest; boundary=next-message
CRLF
--next-message

DATA
  - END STREAM
Content-Type: message/rfc822
CRLF<message>
--next-message

DATA
  + END STREAM
--next-message--
--main-boundary-- 

9.4. Termination

A resource server MUST end the notification response in any one of the following scenarios:

• Once the time specified in the `expires` parameter of the `Events` header field has elapsed.

• Immediately after sending a notification upon a `DELETE` request on the resource that results in a response with 200 (OK) ([RFC9110] § 15.3.1 200 OK) or 204 (No Content) ([RFC9110] § 15.3.5 204 No Content) status codes.

A resource server MUST properly terminate the multipart response as defined in [RFC2046] § 5.1 Multipart Media Type > § 5.1.2 Common Syntax, before closing the notification response stream.

Appendix A: Additional Semantics for `message/rfc822`

The `multipart/digest` multipart media-type ([RFC2046] § 5.1.5 Digest Subtype) uses `message/rfc822` media-type ([RFC2046] § 5.2.1 RFC822 Subtype, [RFC822]) for body parts as default. It follows that the Per Resource Events Protocol transmits notifications as `message/rfc822`, unless the application client requests otherwise.

Request

An application clients MAY specify additional parameters to `message/rfc822` notification media-type in the `accept` event field associated with the `PREP` list item in the `accept-events` header field of the request.

Notification

A resource server implementing the Per Resource Events Protocol SHOULD send a notification to an application client when a request with one of the following methods generates a response with any of the following status codes:

The notification MUST NOT be sent before the success response has been sent to the user agent that initiated the request.

Headers

A resource server MUST include the following header fields in a `message/rfc822` formatted PREP notification:

`Method`

identical to `:method` pseudo-header field in a HTTP/2 request ([RFC9113] § 8.3.1 Request Pseudo-Header Fields), that specifies the request method that triggered the notification.

`Date`

identical to `Date` header field in a HTTP response ([RFC9110] § 6.6.1 Date), that specifies date and time at which the event that triggered the notification was completed.

`Event-ID`

an opaque identifier for the generated notification.

Do we need to make this identical to one of the following:

• `Message-ID` (Internet Message Format § section-3.6.4),

• `id` (Server-Sent Events § section-9.2.6).

A resource server SHOULD include the following headers in a `message/rfc822` formatted PREP notification when the state of the resource or its representation is modified as a result of the event:

`ETag`

identical to `ETag` header field ([RFC9110] § 8.8.3 ETag) in a HTTP response, that is an opaque identifier for the current representation of the state of the resource.

--random-boundary  <- From the previous message (Do not include)
                   <- Empty part response headers & blank line
Method: PUT
Date: Sat, 1 April 2023 10:11:12 GMT
Event-ID: 1234
ETag: "abc123"
--random-boundary

A resource server MUST include the following headers in a `message/rfc822` formatted PREP notification when sent as a result of a `POST` request that modifies another resource:

`Content-Location`

identical to the `Content-Location` header field ([RFC9110] § 8.7 Content-Location).

--random-boundary  <- From the previous message (Do not include)
                   <- Empty part response headers & blank line
Method: POST
Date: Sat, 1 April 2023 10:12:14 GMT
Event-ID: 1235
Content-Location: /foo
--random-boundary

Body

The body of a `message/rfc822` formatted PREP notification might be used to provide a delta representation, the difference between the state of the representation before and after the most recent event on the resource.

If the application client does not specify delta parameter associated with a preferred notifications format of `message/rfc822` in the `accept` event field of the § 7 Request that results in `message/rfc822` formatted PREP notifications, the notifications MUST NOT contain a body.

If state of the resource is not modified as a result of an HTTP operation, the resulting notification MUST NOT contain a body.

If the application client specifies a (`delta`) parameter associated with a preferred notifications format of `message/rfc822` in the `accept` event field of the § 7 Request that results in `message/rfc822` formatted PREP notifications, a resource server:

• SHOULD send the delta representation as the body of the notification generated upon a `PATCH` ([RFC5789]) operation.

• MAY send the delta representation as the body of the notification generated upon a `PUT` ([RFC9110] § 9.3.4 PUT) or a `POST` ([RFC9110] § 9.3.3 POST) operation.

A resource server SHOULD send the delta representation in the content-type preferred by the client as specified by the `delta` parameter.

--random-boundary  <- From the previous message (Do not include)
                   <- Empty part response headers & blank line
Method: PATCH
Date: Sat, 1 April 2023 10:14:16 GMT
Event-ID: 1236
ETag: "xyz987"
Content-type: application/example

<delta>
--random-boundary

Considerations

This section details security and privacy considerations.

Some of the normative references within this specification point to documents with a Living Standard or Draft status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have implications.

Security Considerations

This section is non-normative.

Resource servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature. Application clients are strongly discouraged from exposing information beyond the minimum amount necessary to receive updates about particular resources.

Application clients are discouraged from sending requests for notifications to untrusted resource servers, including localhost or any other loopback IP address, in order to avoid making arbitrary requests.

Privacy Considerations

This section is non-normative.

Security and Privacy Review

This section is non-normative.

These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

There are no known security impacts of the features in this specification.

Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes.

How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

Access to resource server is only granted to authorized access subjects. Notification payloads can contain any data (including that which identifies or refers to agents that control the resource server). Meaningful consent to any personal data that resource servers include about agents associated with themselves or resources of interest are extended to the application client. Resource servers are discouraged from exposing information beyond the amount necessary to enable or use a feature.

How do the features in your specification deal with sensitive information?

The features do not require sensitive information to be obtained or exposed.

Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

Do the features in your specification expose information about the underlying platform to origins?

No.

Does this specification allow an origin to send data to the underlying platform?

No. Resources are described within the framework of HTTP. A resource server might be able to redirect to other resources, (e.g., the https: URLs to file:, data:, or blob: URLs), but no such behaviour is defined by this specification.

Do features in this specification allow an origin access to sensors on a user’s device

No.

What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

No detail about another origin’s state is exposed. When resource servers participate in the CORS protocol [FETCH], HTTP requests from different origins might be allowed. This feature does not add any new attack surface above and beyond normal CORS requests, so no extra mitigation is deemed necessary.

Do features in this specification enable new script execution/loading mechanisms?

No.

Do features in this specification allow an origin to access other devices?

No.

Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No.

What temporary identifiers do the features in this specification create or expose to the web?

No.

How does this specification distinguish between behaviour in first-party and third-party contexts?

Not Applicable.

How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

No different than in the browser’s "normal" state.

Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes, in Security Considerations and Privacy Considerations.

Do features in your specification enable origins to downgrade default security protections?

No.

How does your feature handle non-"fully active" documents?

Not Applicable.