Solid Notifications Use Cases and Requirements

Editor’s Draft, 2023-10-18

This version
https://solid.github.io/notifications-panel/notifications-ucr
Latest version
https://solid.github.io/notifications-panel/notifications-ucr
Created
Published
Modified
Repository
GitHub
Language
English
License
MIT License
Document Status
Editor’s Draft
In Reply To
Solid Origin
Notifications Panel Charter
Policy
Rule
Offer
Unique Identifier
https://solid.github.io/notifications-panel/notifications-ucr#document-policy-offer
Target
https://solid.github.io/notifications-panel/notifications-ucr
Permission
Assigner
W3C Solid Community Group
Action

Abstract

Solid Notifications Use Cases and Requirements.

Issue: Update Notifications UCR

UCR needs a review/revision. Solution-centric references have no place in a UCR document. issues/76.

Status of This Document

This section describes the status of this document at the time of its publication.

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
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/