Quick Notifications

README.md

@@ -12,6 +12,12 @@ These reports are incubated by the [Solid Notifications Panel](https://github.co
 * Editors Draft:
   * [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)
 
+### Quick Protocol
+* Latest Published Version:
+  * [Solid Quick Notifications Protocol](https://solidproject.org/TR/quick-notifications-protocol)
+* Editors Draft:
+  * [Solid Quick Notifications Protocol](https://solid.github.io/notifications/quick-protocol)
+
 ### Notification Channel Types
 
 The Solid Notification Protocol makes it possible to define [notification channel types](https://solid.github.io/notifications/protocol#notification-channel-types). In order to help with the discovery of notification channel types that can be used with the Solid Notifications Protocol, it is encouraged to register them for maximum global interoperability at [Solid Technical Reports](https://solidproject.org/TR/#notification-channel-type-registry).

protocol.html

@@ -451,20 +451,20 @@ <h3 property="schema:name">Overview</h3>
 
                   <p>A notification channel allows a Notification Sender to send notifications to a Notifications Receiver. A notification channel builds upon one of many established web protocols to exchange data, determining its <em>type</em>.</p>
 
-                  <p>The following diagram illustrates the flow of data for those notification channel types in which a client establishes a subscription and then maintains a persistent connection to a notifications source are illustrated by the following diagram.</p>
+                  <p>The following diagram illustrates the flow of data for those notification channel types in which a client establishes a subscription and then maintains a persistent connection to a notifications source.</p>
 
                   <figure id="solid-notifications-flow-receivefrom" rel="schema:hasPart" resource="#solid-notifications-flow-receivefrom">
                     <img rel="schema:image" src="notifications-flow-receivefrom.mmd.svg" width="800" />
 
-                    <figcaption property="schema:name">Solid Notifications Flow Receive From, where the receiver establishes connection to sender.</figcaption>
+                    <figcaption property="schema:name">Solid Notifications Flow Receive From, where the a receiver establishes connection to a sender.</figcaption>
                   </figure>
 
                   <p>The following diagram illustrates the flow of data for those Notification channel types in which a client establishes a subscription and does not maintain a persistent connection to a notifications source:</p>
 
                   <figure id="solid-notifications-flow-sendto" rel="schema:hasPart" resource="#solid-notifications-flow-sendto">
                     <img rel="schema:image" src="notifications-flow-sendto.mmd.svg" width="800" />
 
-                    <figcaption property="schema:name">Solid Notifications Flow Send To, where the sender delivers notifications to receiver.</figcaption>
+                    <figcaption property="schema:name">Solid Notifications Flow Send To, where the sender delivers notifications to a receiver.</figcaption>
                   </figure>
                 </div>
               </section>
@@ -532,7 +532,7 @@ <h4 property="schema:name skos:prefLabel">Classes of Products</h4>
                         <dt about="#NotificationSender" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="NotificationSender">Notification Sender</dfn></dt>
                         <dd about="#NotificationSender" property="skos:definition" rel="skos:broadMatch" resource="spec:ProducerOfContent">A <em>Notification Sender</em> is the sender of a notification acting in conformance to the product class of a notification channel type.</dd>
                         <dt about="#NotificationReceiver" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="NotificationReceiver">Notification Receiver</dfn></dt>
-                        <dd about="#NotificationReceiver" property="skos:definition" rel="skos:broadMatch" resource="spec:Consumer">A <em>Notification Receiver</em> is the recipient of a notification acting in conformance to the product class of a notification channel type.</dd>
+                        <dd about="#NotificationReceiver" property="skos:definition" rel="skos:broadMatch" resource="spec:Consumer">A <em>Notification Receiver</em> is the recipient of a notification acting in conformance with the product class of a notification channel type.</dd>
                        </dl>
                     </div>
                   </section>
@@ -567,7 +567,7 @@ <h2 property="schema:name">Protocol</h2>
 
               <p id="json-ld-format">This specification uses JSON-LD [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>] as the preferred data format, and <code>https://www.w3.org/ns/solid/notifications-context/v1</code> as a URI for the JSON-LD context and as a value of the <code>profile</code> parameter used for content negotiation.</p>
 
-              <p id="authentication-authorization">This specification does not require a specific authentication and authorization mechanism to be used with the Solid Notification Protocol. Implementations are encouraged to use existing approaches, such as those described in the Solid Protocol sections on <cite><a href="https://solidproject.org/TR/protocol#authentication" rel="cito:discusses">Authentication</a></cite> and <cite><a href="https://solidproject.org/TR/protocol#authorization" rel="cito:discusses">Authorization</a></cite> [<cite><a class="bibref" href="#bib-solid-protocol">SOLID-PROTOCOL</a></cite>].</p>
+              <p id="authentication-authorization">This specification does not require a specific authentication and/or authorization mechanisms to be used with the Solid Notification Protocol. Implementations are encouraged to use existing approaches, such as those described in the Solid Protocol sections on <cite><a href="https://solidproject.org/TR/protocol#authentication" rel="cito:discusses">Authentication</a></cite> and <cite><a href="https://solidproject.org/TR/protocol#authorization" rel="cito:discusses">Authorization</a></cite> [<cite><a class="bibref" href="#bib-solid-protocol">SOLID-PROTOCOL</a></cite>].</p>
 
               <section id="discovery" inlist="" rel="schema:hasPart" resource="#discovery">
                 <h3 property="schema:name">Discovery</h3>
@@ -581,14 +581,14 @@ <h3 property="schema:name">Discovery</h3>
                   <p>Resource Servers can advertise <a href="#subscription-service">subscription services</a> that can be used to create notification channels:</p>
 
                   <ul>
-                    <li>for protected resource, which relies on capability URL to protect the channel;</li>
+                    <li>for a protected resource, which relies on a capability URL to protect the channel;</li>
                     <li>with specific features required by the subscribing client.</li>
                   </ul>
 
                   <p>Resource Servers can advertise existing <a href="#notification-channel">notification channels</a> to provide notifications:</p>
 
                   <ul>
-                    <li>for protected resource, which does not rely on capability URL to protect the channel;</li>
+                    <li>for a protected resource, which does not rely on a capability URL to protect the channel;</li>
                     <li>for public read resource.</li>
                   </ul>
 

quick-notifications-flow-discovery.mmd

@@ -0,0 +1,7 @@
+sequenceDiagram
+  participant Subscription Client
+  participant Resource Server
+
+  Subscription Client ->> Resource Server: HEAD Resource (topic)
+  Resource Server ->> Subscription Client: Existing Notifications Channels
+  Resource Server ->> Subscription Client: Subscription Discovery

quick-notifications-flow-subscription.mmd

@@ -0,0 +1,7 @@
+sequenceDiagram
+  participant Subscription Client
+  participant Resource Server
+
+  Resource Server -->> Subscription Client: Discovery Response
+  Subscription Client ->> Resource Server: Subscription Request
+  Resource Server ->> Subscription Client: Subscription Response (with Notification Channel)