HTTP R. Gupta Internet-Draft 22 October 2023 Intended status: Standards Track Expires: 24 April 2024 Per Resource Events draft-gupta-httpbis-per-resource-events-00 Abstract Per Resource Events is a minimal protocol built on top of HTTP that allows clients to receive notifications directly from any resource of interest. The Per Resource Events Protocol (PREP) is predicated on the idea that the most intuitive source for notifications about changes made to a resource is the resource itself. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://CxRes.github.io/prep/draft-gupta-httpbis-per-resource- events.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-gupta-httpbis-per-resource- events/. Discussion of this document takes place on the HTTP Working Group mailing list (mailto:ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/CxRes/prep. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Gupta Expires 24 April 2024 [Page 1] Internet-Draft PREP October 2023 This Internet-Draft will expire on 24 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. How it Works . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Audience . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Known Limitations . . . . . . . . . . . . . . . . . . . . 7 3. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Document Conventions . . . . . . . . . . . . . . . . . . 7 3.2. Requirements Notation . . . . . . . . . . . . . . . . . . 7 3.3. Classes of Products . . . . . . . . . . . . . . . . . . . 7 3.4. Interoperability . . . . . . . . . . . . . . . . . . . . 8 3.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 4. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Accept-Events . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Validity . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Events . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Validity . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Event Fields . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Not Available . . . . . . . . . . . . . . . . . . . . . . 12 Gupta Expires 24 April 2024 [Page 2] Internet-Draft PREP October 2023 6.3. Available . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Response without Notifications . . . . . . . . . . . . . . . 14 8.1. Not Available . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Error Response . . . . . . . . . . . . . . . . . . . . . 14 8.3. Notification Errors . . . . . . . . . . . . . . . . . . . 15 9. Notifications Response . . . . . . . . . . . . . . . . . . . 15 9.1. Common Headers . . . . . . . . . . . . . . . . . . . . . 15 9.2. Only Notifications . . . . . . . . . . . . . . . . . . . 16 9.2.1. Headers . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.2. Body . . . . . . . . . . . . . . . . . . . . . . . . 17 9.3. Composite Response . . . . . . . . . . . . . . . . . . . 17 9.3.1. Headers . . . . . . . . . . . . . . . . . . . . . . . 18 9.3.2. Body . . . . . . . . . . . . . . . . . . . . . . . . 18 9.4. Termination . . . . . . . . . . . . . . . . . . . . . . . 19 10. Semantics for message/rfc822 notifications . . . . . . . . . 19 10.1. Request . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Notification . . . . . . . . . . . . . . . . . . . . . . 19 10.3. Headers . . . . . . . . . . . . . . . . . . . . . . . . 20 10.4. Body . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11.1. Browser Fingerprinting . . . . . . . . . . . . . . . . . 22 11.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 12.1. Header Field Registration . . . . . . . . . . . . . . . 23 12.2. Notifications Protocol Registry . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 25 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction 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 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 Gupta Expires 24 April 2024 [Page 3] Internet-Draft PREP October 2023 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 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 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, * a default representation for notifications and associated semantics when used to transmit notifications. The Per Resource Events Protocol does not specify: Gupta Expires 24 April 2024 [Page 4] Internet-Draft PREP October 2023 * 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 (other than the default case). - Implementations are free to use any media-type for notifications, which can be negotiated just like representations. - Implementations are also free to define additional semantics for a given media-type, when used to transmit notifications using the Per Resource Events Protocol. 1.4. Audience This specification is for: * Server developers (http://data.europa.eu/esco/occupation/a7c1d23d- aeca-4bee-9a08-5993ed98b135) who wish to enable clients to listen for updates to particular resources. * Application developers (http://data.europa.eu/esco/occupation/ c40a2919-48a9-40ea-b506-1f34f693496d) who wish to implement a client to listen for updates to particular resources. 2. Design 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. Gupta Expires 24 April 2024 [Page 5] Internet-Draft PREP October 2023 2.1. Principles 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 The goals of the Per Resource Events Protocol are: * to provide notifications only using the HTTP protocol STD97 (https://www.rfc-editor.org/info/std97) [HTTP] 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 [SSE]. 2.3. Constraints 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. Gupta Expires 24 April 2024 [Page 6] Internet-Draft PREP October 2023 2.4. Known Limitations 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, [WS] 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 [SSE]. 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. Conformance 3.1. Document Conventions All assertions, diagrams, examples and notes in this specification are non-normative. 3.2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 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. 3.3. 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 that builds on HTTP origin server ([HTTP], Section 3.6) by defining header fields ([HTTP], Section 6.3) and media types ([HTTP], Section 8.3.1). Application Client that builds on HTTP user agent ([HTTP], Gupta Expires 24 April 2024 [Page 7] Internet-Draft PREP October 2023 Section 3.5) by defining behaviour in terms of fetching [FETCH] across the platform. 3.4. Interoperability Interoperability occurs between Application Client—Resource Server (Section 3.4) 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. 3.5. Terminology The following terms are defined: 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 ([HTTP], Section 5.1). 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. Gupta Expires 24 April 2024 [Page 8] Internet-Draft PREP October 2023 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 ([HTTP-SF], Section 3.1) 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. The q parameter assigns a relative "weight" to the sender's preference for a notification protocol with semantics as defined in [HTTP], Section 12.4.2. Senders using weights SHOULD send q last (after all protocol parameters). Recipients SHOULD process any parameter named q as weight, regardless of parameter ordering. Gupta Expires 24 April 2024 [Page 9] Internet-Draft PREP October 2023 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. 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. 4.2.2. Syntax Events is a Dictionary structured ([HTTP-SF], Section 3.1) 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 ([HTTP], Section 5) 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. Gupta Expires 24 April 2024 [Page 10] Internet-Draft PREP October 2023 This specification restricts Accept-Events and Events as Structured header fields [HTTP-SF]. From this it follows: * An event field whose value is anything except an item without parameters MUST be specified in an Inner List ([HTTP-SF], Section 3.1.1). * Unless otherwise specified, an event field that is not already defined as a Structured Field, therefore, MUST be handled as a Retrofit Structured Field [HTTP-Retrofit] 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 ([HTTP], Section 9.3.2) and GET ([HTTP], Section 9.3.1) 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 ([HTTP], Section 9.3.1) 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. A 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 ([HTTP], Section 15) to describe the result of the request for notifications and the semantics of notifications in the response. Gupta Expires 24 April 2024 [Page 11] Internet-Draft PREP October 2023 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 ([HTTP], Section 9.3.2) 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. HEAD /foo HTTP/1.1 Host: example.org Figure 1: Discovery Request 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. Gupta Expires 24 April 2024 [Page 12] Internet-Draft PREP October 2023 HTTP/1.1 200 OK Accept: text/html Accept-Events: PREP; accept=message/rfc822 Figure 2: Discovery Response | *Implementation Guidance* | | When resource servers support HTTP/2 [HTTP/2] for a resource, | they are strongly encouraged to advertise it in the response. | | When a resource is accessible from different locations, | resource servers are encouraged to advertise these locations in | the response. | | HTTP Alternative Services [RFC7838], for example, describes a | mechanism for advertising these capabilities. 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. o 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 ([SSE], Section 9.2.4 (SSE#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. | *Implementation Guidance* | | Set the Last-Event-ID to a wildcard * to explicitly request a | resource server to not send the base response body in the | response at all. Gupta Expires 24 April 2024 [Page 13] Internet-Draft PREP October 2023 GET /foo HTTP/1.1 Host: example.org Authorization: DPoP DPoP: Last-Event-ID: * Accept-Encoding: gzip Accept-Events: PREP; accept=message/rfc822; accept-encoding=identity Figure 3: Request for Notifications 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. | *Implementation Guidance* | | Implementations are advised against sending notifications for | long-lived resources. A resource might be considered long- | lived, if the resource server determines that the resource is | unlikely to change in the duration of the notification | response. In such instances, resource servers are strongly | advised to respond with the Cache-Control header and set the | max-age parameter in it. 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) ([HTTP], Section 15.3.1), Gupta Expires 24 April 2024 [Page 14] Internet-Draft PREP October 2023 * 204 (No Content) ([HTTP], Section 15.3.5), * 206 (Partial Content) ([HTTP], Section 15.3.7), * 226 (IM Used) ([Delta], Section 10.4.1). 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) ([HTTP], Section 15.5.13) 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 Section 8.2: * 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 ([HTTP], Section 6.6.1). - Content-Type ([HTTP], Section 8.3) with the media type set to multipart ([HTTP], Section 8.3.3). The subtype will depend on whether the base response is included in the response body. - Events which MUST include the following event fields: Gupta Expires 24 April 2024 [Page 15] Internet-Draft PREP October 2023 o protocol set to the value PREP. o status set to the 200 (OK) ([HTTP], Section 15.3.1) status code. o 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 ([HTTP], Section 12.5.5) which MUST include Accept-Events as one of the values. - Last-Modified ([HTTP], Section 8.8.2). - ETag ([HTTP], Section 8.8.3). * 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: o 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 Section 7, Request. A resource server MUST NOT send the base response, if the request for PREP notifications includes the Last-Event-ID header field ([SSE], Section 9.2.4 (SSE#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 ([HTTP], Section 12.5.5) with Last-Event-ID as one of the values. Gupta Expires 24 April 2024 [Page 16] Internet-Draft PREP October 2023 9.2.2. Body A resource server MUST transmit PREP notifications as a multipart message body ([RFC2046], Section 5.1), with a media type of multipart/digest ([RFC2046], Section 5.1.5) 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 --next-message-- Figure 4: Response with Notifications Only | *Implementation Guidance* | | While not strictly necessary, it is strongly encouraged that | resource servers send notifications in a manner such that the | boundary delimiter ([RFC2046], Section 5.1.2) is always at the | end of a chunk ([HTTP/1.1], Section 7.1) or data frame | ([HTTP/2], Section 6.1) as shown in the example above. This | way an application client does not have to wait until the next | chunk or frame (which might be a while or in cases of error | never arrive) to be certain that the immediate message is | complete. 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 Section 7 Request. Gupta Expires 24 April 2024 [Page 17] Internet-Draft PREP October 2023 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 ([HTTP], Section 12.5.5) 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], Section 5.1) with a media type of multipart/mixed ([RFC2046], Section 5.1.3) 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 Section 9.2. 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 --main-boundary Content-Type: multipart/digest; boundary=next-message --next-message Content-Type: message/rfc822 --next-message-- --main-boundary-- Gupta Expires 24 April 2024 [Page 18] Internet-Draft PREP October 2023 Figure 5: Notification Response with Representation included 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) ([HTTP], Section 15.3.1) or 204 (No Content) ([HTTP], Section 15.3.5) status codes. A resource server MUST properly terminate the multipart response as defined in [RFC2046], Section 5.1.2, before closing the notification response stream. | *Implementation Guidance* | | When a user navigates away from a website or an application | using PREP notifications, application clients are strongly | encouraged to properly close the response stream to ensure that | servers do not keep sending notifications. 10. Semantics for message/rfc822 notifications The multipart/digest multipart media-type ([RFC2046], Section 5.1.5) uses message/rfc822 media-type ([RFC2046], Section 5.2.1, [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. 10.1. 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. 10.2. 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: Gupta Expires 24 April 2024 [Page 19] Internet-Draft PREP October 2023 +=============================+===================================+ | Request Method | Response Status | +=============================+===================================+ | PUT ([HTTP], Section 9.3.4) | 200 (OK) ([HTTP], Section 15.3.1) | +-----------------------------+-----------------------------------+ | PATCH ([RFC5789]) | 204 (No Content) ([HTTP], | | | Section 15.3.5) | +-----------------------------+-----------------------------------+ | DELETE ([HTTP], | | | Section 9.3.5) | | +-----------------------------+-----------------------------------+ +-----------------------------+-----------------------------------+ | POST ([HTTP], | 200 (OK) ([HTTP], Section 15.3.1) | | Section 9.3.3) | | +-----------------------------+-----------------------------------+ | | 204 (No Content) ([HTTP], | | | Section 15.3.5) | +-----------------------------+-----------------------------------+ | | 201 (Created) ([HTTP], | | | Section 15.3.2) | +-----------------------------+-----------------------------------+ | | 205 (Reset Content) ([HTTP], | | | Section 15.3.6) | +-----------------------------+-----------------------------------+ Table 1: Notification Triggers The notification MUST NOT be sent before the success response has been sent to the user agent that initiated the request. 10.3. 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 ([HTTP/2], Section 8.3.1), that specifies the request method that triggered the notification. Date identical to Date header field in a HTTP response ([HTTP], Section 6.6.1), that specifies date and time at which the event that triggered the notification was completed. Event-ID an opaque identifier for the generated notification. 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: Gupta Expires 24 April 2024 [Page 20] Internet-Draft PREP October 2023 ETag identical to ETag header field ([HTTP], Section 8.8.3) 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 Figure 6: `PUT` notification message 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 ([HTTP], Section 8.7). --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 Figure 7: `POST` notification message 10.4. 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 request (Section 7) 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. Gupta Expires 24 April 2024 [Page 21] Internet-Draft PREP October 2023 If the application client specifies a delta parameter associated with a preferred notifications format of message/rfc822 in the accept event field of the request (Section 7) 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 ([HTTP], Section 9.3.4) or a POST ([HTTP], Section 9.3.3) 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 --random-boundary Figure 8: `PATCH` notification with delta representation 11. Security Considerations Since the Per Resource Events Protocol uses HTTP to transmit notifications, it follows that the security and privacy considerations that apply to HTTP also apply to PREP. Considerations relevant to HTTP semantics and its use for transferring information over the Internet are discussed in Section 17 of [HTTP], and considerations related to HTTP/1.1 message syntax and parsing are discussed in Section 11 of [HTTP/1.1]. The following is a non-exhaustive list of security and privacy considerations that become especially pertinent due to the manner in which PREP uses HTTP for transmitting notifications: 11.1. Browser Fingerprinting The Accept-Events header field provides an extra vector that can aid unique identification of user agent. Follow the advice in [HTTP], Section 17.13 to minimize the risk of fingerprinting. Gupta Expires 24 April 2024 [Page 22] Internet-Draft PREP October 2023 11.2. Denial-of-Service Attacks Resources that serve notifications, by virtue of keeping the response stream open for an extended period of time are more susceptible to Denial-of-Service attacks because the effort required to request notifications from the same resource is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the notifications. Servers ought to ignore, coalesce, or reject egregious notification request, such as repeated notification requests to resource from the same origin. 12. IANA Considerations The change controller for the following registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 12.1. Header Field Registration IANA has registered the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry (https://www.iana.org/assignments/http-fields/)" defined by [HTTP]: +====================+=============+===========+ | Header Field Names | Status | Reference | +====================+=============+===========+ | Accept-Events | Provisional | Section 4 | +--------------------+-------------+-----------+ | Events | Provisional | Section 4 | +--------------------+-------------+-----------+ Table 2 12.2. Notifications Protocol Registry The Accept-Events and Events header fields identify specific protocols for notifications. The "HTTP Notifications Protocol Registry", created and maintained by IANA at https://www.iana.org/assignments/http-parameters/ (https://www.iana.org/assignments/http-parameters/), registers identifiers for notification protocols. Notifications protocol registrations MUST include the following fields: * Identifier * Name Gupta Expires 24 April 2024 [Page 23] Internet-Draft PREP October 2023 * Pointer to specification text Initial registrations are given below: +============+==============================+===============+ | Identifier | Name | Reference | +============+==============================+===============+ | PREP | Per Resource Events Protocol | This document | +------------+------------------------------+---------------+ Table 3 Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8). Identified protocols MUST conform to the purpose of sending notifications as defined in Section 4 of this document. 13. References 13.1. Normative References [Delta] Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland, Y., van Hoff, A., and D. Hellerstein, "Delta encoding in HTTP", RFC 3229, DOI 10.17487/RFC3229, January 2002, . [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [HTTP-Retrofit] Nottingham, M., "Retrofit Structured Fields for HTTP", Work in Progress, Internet-Draft, draft-ietf-httpbis- retrofit-06, 31 March 2023, . [HTTP-SF] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", Work in Progress, Internet-Draft, draft-ietf- httpbis-sfbis-03, 3 August 2023, . [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, . Gupta Expires 24 April 2024 [Page 24] Internet-Draft PREP October 2023 [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, August 1982, . [SSE] "Server-Sent Events", W3C REC eventsource, W3C eventsource, . 13.2. Informative References [FETCH] "Fetch - Living Standard", . [REST] Fielding, R. T., "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Dissertation, University of California, Irvine, . [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, . Gupta Expires 24 April 2024 [Page 25] Internet-Draft PREP October 2023 [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, . [WEBSUB] "WebSub", W3C REC websub, W3C websub, . [WS] "The WebSocket API", W3C NOTE websockets, W3C websockets, . Index A B D E N R A Accept-Events Section 1.2, Paragraph 1; Section 3.5, Paragraph 2.6.1; *_Section 4.1_*; Section 4.2, Paragraph 2; Section 4.2, Paragraph 3; Section 4.2.1, Paragraph 1; Section 5.1, Paragraph 2; Section 5.2, Paragraph 2; Section 5.2, Paragraph 4; Section 5.3, Paragraph 2; Section 6.2, Paragraph 1; Section 6.3, Paragraph 1; Section 7, Paragraph 3.1.1; Section 7, Paragraph 6; Section 8.1, Paragraph 3.1.1; Section 9.1, Paragraph 2.2.2.1.1; Section 9.1, Paragraph 2.3.2.1.1; Section 10.1, Paragraph 1; Section 11.1, Paragraph 1; Table 2; Section 12.2, Paragraph 1 application client Section 3.4, Paragraph 2.2.1; Section 3.5, Paragraph 2.2.1; Section 4.1, Paragraph 1; Section 4.1, Paragraph 3; Section 4.1, Paragraph 4; Section 5.2, Paragraph 4; Section 6, Paragraph 1; Section 6.1, Paragraph 1; Section 7, Paragraph 1; Section 7, Paragraph 2; Section 7, Paragraph 3.1.2.1.2.1.1; Section 8.3, Paragraph 1; Section 9.2, Paragraph 1; Section 9.2.2, Paragraph 3.2; Section 9.3, Paragraph 1; Section 9.4, Paragraph 4.2; Section 10, Paragraph 1; Section 10.1, Paragraph 1; Section 10.2, Paragraph 1; Section 10.4, Paragraph 2; Section 10.4, Paragraph 4 B base response Section 7, Paragraph 1; Section 7, Paragraph 3.2.1; Section 7, Paragraph 4.2; Section 9.1, Paragraph 2.1.2.2.1; Section 9.2, Paragraph 1; Section 9.2, Paragraph 2; Section 9.3, Paragraph 1; Section 9.3.2, Paragraph 1 Gupta Expires 24 April 2024 [Page 26] Internet-Draft PREP October 2023 D delta representation *_Section 10.4, Paragraph 1_*; Section 10.4, Paragraph 5.1.1; Section 10.4, Paragraph 5.2.1; Section 10.4, Paragraph 6 E event field Section 4.2, Paragraph 1; Section 5.1, Paragraph 1; Section 5.1, Paragraph 1; Section 5.1, Paragraph 1; Section 5.1, Paragraph 3.1.1; Section 5.1, Paragraph 3.2.1; Section 5.1, Paragraph 3.3.1; Section 6.3, Paragraph 2; Section 7, Paragraph 3.1.2.1.2.1.1; Section 7, Paragraph 3.1.2.1.2.1.1; Section 7, Paragraph 6; Section 8.1, Paragraph 3.2.1; Section 8.2, Paragraph 4.1.2.1.1; Section 8.2, Paragraph 4.1.2.2.1; Section 8.3, Paragraph 3.1.2.1.1; Section 8.3, Paragraph 3.1.2.2.1; Section 9.1, Paragraph 2.1.2.3.1; Section 9.1, Paragraph 2.3.2.1.2.1.1; Section 10.1, Paragraph 1; Section 10.4, Paragraph 2; Section 10.4, Paragraph 4 Events Section 3.5, Paragraph 2.6.1; *_Section 4.2_*; Section 5.1, Paragraph 2; Section 5.2, Paragraph 5; Section 5.2, Paragraph 6; Section 5.3, Paragraph 2; Section 5.3, Paragraph 3; Section 8.1, Paragraph 3.2.1; Section 8.2, Paragraph 4.1.1; Section 8.3, Paragraph 3.1.1; Section 9.1, Paragraph 2.1.2.3.1; Section 9.4, Paragraph 2.1.1; Table 2; Section 12.2, Paragraph 1 N notification Section Abstract, Paragraph 1; Section Abstract, Paragraph 1; Section 1, Paragraph 1; Section 1.1, Paragraph 3; Section 1.1, Paragraph 3; Section 1.1, Paragraph 3; Section 1.2, Paragraph 1; Section 1.2, Paragraph 1; Section 1.3, Paragraph 2.1.1; Section 1.3, Paragraph 2.2.1; Section 1.3, Paragraph 2.3.1; Section 1.3, Paragraph 2.4.1; Section 1.3, Paragraph 2.4.1; Section 1.3, Paragraph 4.2.1; Section 1.3, Paragraph 4.2.2.1.1; Section 1.3, Paragraph 4.2.2.2.1; Section 2, Paragraph 1; Section 2, Paragraph 2; Section 2, Paragraph 2; Section 2, Paragraph 3; Section 2, Paragraph 3; Section 2.1, Paragraph 1; Section 2.1, Paragraph 1; Section 2.2, Paragraph 2.1.1; Section 2.2, Paragraph 2.1.1; Section 2.2, Paragraph 2.2.1; Section 2.2, Paragraph 2.3.1; Section 2.2, Paragraph 2.3.1; Section 2.3, Paragraph 2.2.1; Section 2.3, Paragraph 2.2.1; Section 2.4, Paragraph 1; Section 2.4, Paragraph 1; Section 2.4, Paragraph 1; Section 2.4, Paragraph 2; Section 3.5; Section 3.5, Paragraph 2.4.1; Section 4, Paragraph 1; Gupta Expires 24 April 2024 [Page 27] Internet-Draft PREP October 2023 Section 4.1, Paragraph 1; Section 4.1, Paragraph 1; Section 4.1, Paragraph 2; Section 4.1, Paragraph 3; Section 4.1, Paragraph 4; Section 4.1, Paragraph 4; Section 4.1.1, Paragraph 1; Section 4.1.1, Paragraph 1; Section 4.1.1, Paragraph 2; Section 4.1.1, Paragraph 2; Section 4.1.2, Paragraph 1; Section 4.1.2, Paragraph 2; Section 4.1.2, Paragraph 3; Section 4.2, Paragraph 1; Section 4.2.2, Paragraph 1; Section 4.2.2, Paragraph 1; Section 5.1, Paragraph 1; Section 5.2, Paragraph 1; Section 5.2, Paragraph 3; Section 5.2, Paragraph 3; Section 5.3, Paragraph 1; Section 5.3, Paragraph 1; Section 5.3, Paragraph 2; Section 5.3, Paragraph 2; Section 5.3, Paragraph 3; Section 6, Paragraph 1; Section 6.1, Paragraph 1; Section 6.2, Paragraph 1; Section 6.3, Paragraph 1; Section 6.3, Paragraph 2; Section 7, Paragraph 1; Section 7, Paragraph 2; Section 7, Paragraph 3.1.2.1.1; Section 7, Paragraph 3.1.2.1.2.1.1; Section 7, Paragraph 3.2.1; Section 7, Paragraph 6; Section 8.1, Paragraph 1; Section 8.1, Paragraph 2; Section 8.1, Paragraph 4.2; Section 8.1, Paragraph 4.2; Section 8.2, Paragraph 1; Section 8.2, Paragraph 3; Section 8.3, Paragraph 1; Section 8.3, Paragraph 2; Section 8.3, Paragraph 3.1.2.2.1; Section 9.1, Paragraph 1; Section 9.1, Paragraph 2.1.2.3.2.3.1; Section 9.1, Paragraph 2.1.2.3.3; Section 9.1, Paragraph 2.1.2.3.3; Section 9.1, Paragraph 2.3.2.1.1; Section 9.1, Paragraph 2.3.2.1.2.1.1; Section 9.2, Paragraph 1; Section 9.2, Paragraph 2; Section 9.2.1, Paragraph 1; Section 9.2.2, Paragraph 1; Section 9.2.2, Paragraph 1; Section 9.2.2, Paragraph 3.2; Section 9.3, Paragraph 1; Section 9.3, Paragraph 2; Section 9.3.1, Paragraph 1; Section 9.3.2, Paragraph 1; Section 9.3.2, Paragraph 2.1.1; Section 9.3.2, Paragraph 2.2.1; Section 9.4, Paragraph 1; Section 9.4, Paragraph 2.2.1; Section 9.4, Paragraph 3; Section 9.4, Paragraph 4.2; Section 9.4, Paragraph 4.2; Section 10, Paragraph 1; Section 10.1, Paragraph 1; Section 10.2, Paragraph 1; Section 10.2, Paragraph 3; Section 10.3, Paragraph 1; Section 10.3, Paragraph 2.2.1; Section 10.3, Paragraph 2.4.1; Section 10.3, Paragraph 2.6.1; Section 10.3, Paragraph 3; Section 10.3, Paragraph 6; Section 10.4, Paragraph 1; Section 10.4, Paragraph 2; Section 10.4, Paragraph 2; Section 10.4, Paragraph 2; Section 10.4, Paragraph 3; Section 10.4, Paragraph 4; Section 10.4, Paragraph 4; Section 10.4, Paragraph 5.1.1; Section 10.4, Paragraph 5.2.1; Section 11, Paragraph 1; Section 11, Paragraph 2; Section 11.2, Paragraph 1; Section 11.2, Paragraph 1; Section 11.2, Paragraph 1; Section 11.2, Paragraph 1; Section 11.2, Paragraph 1; Section 12.2, Gupta Expires 24 April 2024 [Page 28] Internet-Draft PREP October 2023 Paragraph 1; Section 12.2, Paragraph 1; Section 12.2, Paragraph 1; Section 12.2, Paragraph 2; Section 12.2, Paragraph 6 R resource server Section 3.4, Paragraph 2.2.1; Section 4.1, Paragraph 2; Section 4.2, Paragraph 1; Section 4.2, Paragraph 2; Section 4.2, Paragraph 3; Section 5.2, Paragraph 2; Section 5.2, Paragraph 5; Section 5.2, Paragraph 6; Section 5.3, Paragraph 2; Section 6, Paragraph 1; Section 6.1, Paragraph 1; Section 6.2, Paragraph 1; Section 6.3, Paragraph 1; Section 6.3, Paragraph 2; Section 6.3, Paragraph 4.2; Section 6.3, Paragraph 4.3; Section 7, Paragraph 2; Section 7, Paragraph 3.2.1; Section 7, Paragraph 4.2; Section 7, Paragraph 6; Section 8.1, Paragraph 1; Section 8.1, Paragraph 2; Section 8.1, Paragraph 4.2; Section 8.1, Paragraph 4.2; Section 8.2, Paragraph 1; Section 8.2, Paragraph 3; Section 8.3, Paragraph 1; Section 8.3, Paragraph 2; Section 9.1, Paragraph 1; Section 9.1, Paragraph 2.3.2.1.1; Section 9.2, Paragraph 2; Section 9.2.1, Paragraph 1; Section 9.2.2, Paragraph 1; Section 9.2.2, Paragraph 3.2; Section 9.3, Paragraph 1; Section 9.3.1, Paragraph 1; Section 9.3.2, Paragraph 1; Section 9.4, Paragraph 1; Section 9.4, Paragraph 3; Section 10.2, Paragraph 1; Section 10.3, Paragraph 1; Section 10.3, Paragraph 3; Section 10.3, Paragraph 6; Section 10.4, Paragraph 4; Section 10.4, Paragraph 6 Author's Address Rahul Gupta Email: cxres+ietf@protonmail.com Gupta Expires 24 April 2024 [Page 29]