Solid Notifications Use Cases and Requirements

This document was published by the Solid Community Group as an Editor’s Draft. The information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.

Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Introduction

This section is non-normative.

Motivation...

This document is for:

Technical communicators that want to develop information and media concepts, standards, structures and software tool support.

Terminology

This section is non-normative.

This document defines the following terms. These terms are referenced throughout this document.

Foo Bar Baz: Foo Bar Baz...

Use Cases

This section is non-normative.

Immediate Notification of Data Changes

For many clients, it is important to know when a resource state changes. This includes collaborative editing apps, chat apps or any client that expects the underlying data to change frequently based on updates made by others.

Requirements: Create Events; Update Events; Delete Events; Authorization; Handling Subscription Requests

Notification of Data Changes on Multiple Resources

Clients might want to know state changes of multiple resources at the same time. For example, an app may simultaneously receive notifications from a container, resource(s) within the container, and/or resource(s) linked to the container.

Requirements: Create Events; Update Events; Delete Events; Authorization; Handling Subscription Requests

Amend List of Resources for Notification of Data Changes

Clients might want to amend the list of resources from which they receive notifications of data change. This allows the client to respond to modifications made to a container, such as a resource being created or removed from within it.

Requirements: Create Events; Update Events; Delete Events; Authorization; Handling Subscription Modifications

Frequency of Notifications

Sometimes a client doesn't need to be alerted for every change. If a client only needs infrequent updates (for example, every 5 minutes), it should be possible to avoid floods of data that might otherwise place a higher burden on the client application. Ideally, a client should be able to define what that aggregation window would be: for some clients, 10 seconds might be appropriate; for others, several minutes might be more appropriate.

Requirements: Create Events; Update Events; Delete Events; Event Filtering; Authorization; Handling Subscription Requests; Handling Subscription Modifications

Filtered Notifications

Certain categories of notifications may be more or less interesting to clients. For example, a client may not care about UPDATE operations or may only care about notifications for resources of certain types.

Requirements: Create Events; Update Events; Delete Events; Event Filtering; Authorization; Handling Subscription Requests; Handling Subscription Modifications

Time-bound Subscriptions

Occasionally, a client only needs a subscription to be in effect for a limited period of time. While a client may easily close a WebSocket itself, subscriptions for other, more asynchronous forms of notifications, such as LDN alerts or WebHook operations, may be more difficult to terminate.

Requirements: Create Events; Update Events; Delete Events; Authorization; Handling Subscription Requests; Handling Subscription Modifications

Lost Update Notifications

For WebSockets and subscriptions that rely on an active, live connection to a notification server, the subscription channel needs to make sure that clients do not miss notifications in the event of a dropped connection.

Requirements: Create Events; Update Events; Delete Events; Authorization

Capability Discovery

A given Solid Notification server may support certain technologies (e.g., WebSockets and LDN) but not others (e.g., EventSource and WebSub). Likewise, a client may not support the same set of technologies that are implemented by a server. As such, there needs to be a mechanism for clients and servers to agree on a mutually supported subscription type. In addition to simply determining the set of protocols that work for client and server, there may be particular features (e.g., notification aggregation, notification filtering) that are required by the client. This could be used to further filter the protocol selection.

Requirements: Capability Discovery

Requirements

This section is non-normative.

This section lists the functional and non-functional requirements arising from the use-cases catalogued in this document. Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out.

The use cases and their requirements are tabulated below, followed by a definition of each requirement.

Table of Use Cases and Requirements
Use Case	Functional Requirements								Non-Functional Requirements
Use Case	F1	F2	F3	F4	F5	F6	F7	F8	NF1
Immediate Notification of Data Changes	✔	✔	✔	⌙	✔	⌙	✔	⌙	⌙
Notification of Data Changes on Multiple Resources	✔	✔	✔	⌙	✔	⌙	✔	⌙	⌙
Amend List of Resources for Notification of Data Changes	✔	✔	✔	⌙	✔	⌙	⌙	✔	⌙
Frequency of Notifications	✔	✔	✔	✔	✔	⌙	✔	✔	⌙
Filtered Notifications	✔	✔	✔	✔	✔	⌙	✔	✔	⌙
Time-Bound Subscriptions	✔	✔	✔	⌙	✔	⌙	✔	✔	⌙
Lost Update Notifications	✔	✔	✔	⌙	✔	⌙	⌙	⌙	⌙
Capability Discovery	⌙	⌙	⌙	⌙	⌙	✔	⌙	⌙	⌙
✔ Required ⌙ Inapplicable

Functional Requirements

This section is non-normative.

F1. Create Events: A subscribed entity is alerted when a new resource is created.
F2. Update Events: A subscribed entity is alerted when an existing resource is updated.
F3. Delete Events: A subscribed entity is alerted when an existing resource is deleted.
F4. Event Filtering: A subscribed entity can request a subset of all notifications.
F5. Authorization: Authorization is enforced on all subscriptions.
F6. Capability Discovery: A client is able to discover the notification capabilities of a Solid Storage.
F7. Handling Subscription Requests: >When a subscriber makes request for a new subscription, the Solid storage must be able to process the request including the parameters for subscription provided by the client.
F8. Handling Subscription Modifications: When a subscriber requests for parameters of a subscription to be modified, the Solid storage must be able to process the request.

Non-Functional Requirements

This section is non-normative.

NF1. Baz: Baz

Considerations

This section details privacy, accessibility and ethical considerations.

Privacy Considerations

This section is non-normative.

Accessibility Considerations

This section is non-normative.

Ethical Considerations

This section is non-normative.

References

Informative References

[ETHICAL-WEB]: W3C TAG Ethical Web Principles. Daniel Appelquist; Hadley Beeman. W3C. 27 October 2020. TAG Finding. URL: https://www.w3.org/2001/tag/doc/ethical-web-principles/
[RFC3986]: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
[RFC6454]: The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
[RFC7231]: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[SOLID-PROTOCOL]: Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor’s Draft. URL: https://solidproject.org/TR/protocol
[WEBARCH]: Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/