profile
viewpoint
Aaron Coburn acoburn @apache, @inrupt New York, USA

acoburn/moodle-block_vcl 1

A Moodle block for connecting to the Virtual Computing Lab

acoburn/airlines 0

An R package providing access to medium airline flight delay data

acoburn/bookkeeper 0

Apache Bookkeeper

acoburn/clerezza 0

Mirror of Apache Clerezza

acoburn/clerezza-rdf-core 0

Mirror of Apache Clerezza rdf.core

acoburn/commons-rdf 0

Mirror of Apache CommonsRDF

acoburn/community-server 0

Community Solid Server: an open and modular implementation of the Solid specifications

acoburn/curator 0

Mirror of Apache Curator

acoburn/I-D-Profile-Negotiation 0

Internet-Draft: Indicating and Negotiating Profiles in HTTP

push eventsolid/notifications-panel

Aaron Coburn

commit sha 571bb737011342b3ef0cd35931e8a3a3616069aa

Add remaining use cases

view details

push time in a day

push eventsolid/notifications-panel

Aaron Coburn

commit sha 51550b0ba986847005c36881cd01a801200c4fa4

Add 'protocol negotiation' use case

view details

push time in a day

PR opened solid/notifications-panel

Reviewers
Add use cases from notifications protocol document

This adds the first three use cases from the Notifications Protocol document. The intention is to move all these use cases from the protocol document to this document.

+83 -13

0 comment

1 changed file

pr created time in a day

create barnchsolid/notifications-panel

branch : use-cases-part-1

created branch time in a day

PullRequestReviewEvent
PullRequestReviewEvent

push eventsolid/notifications

elf Pavlik

commit sha aaf55fb45ff2f09cb993c585e26d5bfb6f30dac7

Create streaming-http-subscription-2021.md Initial version of Streaming HTTP Subscription type

view details

elf Pavlik

commit sha 1bfb3ba21f5c19056701f2997360184e8020d0e7

Update streaming-http-subscription-2021.md

view details

Aaron Coburn

commit sha 9c71a6c7121b7a360018943767d2d563e3450e88

Apply suggestions from code review

view details

Aaron Coburn

commit sha 548c61ea6f3a2d91122524e053ef5bea8971e098

Merge pull request #31 from elf-pavlik/patch-1 Define StreamingHTTPSubscription2021 type for Solid Notifications

view details

push time in 2 days

PR merged solid/notifications

Define StreamingHTTPSubscription2021 type for Solid Notifications

This document defines the requirements for `StreamingHTTPSubscription2021.

+134 -0

0 comment

1 changed file

elf-pavlik

pr closed time in 2 days

push eventelf-pavlik/notifications

Aaron Coburn

commit sha 9c71a6c7121b7a360018943767d2d563e3450e88

Apply suggestions from code review

view details

push time in 2 days

delete branch solid/notifications

delete branch : websocket-document

delete time in 2 days

push eventsolid/notifications

Aaron Coburn

commit sha 1b8c407ad036c6e7cfde5c4c4bd5a19876e2cc1c

Define WebSocketSubscription2021 type

view details

Aaron Coburn

commit sha b3ef53195b2c53505526a16edf7249d2675f0b17

Update identifier references

view details

Aaron Coburn

commit sha 4d8a4cee787ab47ac34ce0c10c27b3aa74c6c2c1

Rename file

view details

Aaron Coburn

commit sha 49140b41aa657b70d79c431dc82fa0dc2fc46b3b

Adjust diagram location

view details

Aaron Coburn

commit sha c292b0da7117a76ff64dfd00a00bdf01ba66d7b9

Add subprotocol to example Co-authored-by: Sarven Capadisli <info@csarven.ca>

view details

Aaron Coburn

commit sha 2480950c25412e364e3528c2855c0c4578644fb8

Use explicit URI for subscription type

view details

Aaron Coburn

commit sha fdb65a622ac519d3d39cd05b1d72dcc67ccfe437

Merge branch 'websocket-document' of github.com:solid/notifications into websocket-document

view details

Aaron Coburn

commit sha a5968d264771e5a291762ac10210fdcdcbf30d48

Merge pull request #28 from solid/websocket-document Define WebSocketSubscription2021 type for Solid Notifications

view details

push time in 2 days

PR merged solid/notifications

Define WebSocketSubscription2021 type for Solid Notifications

This defines the WebSocketSubscription2021 type in an independent specification document.

+499 -0

1 comment

2 changed files

acoburn

pr closed time in 2 days

delete branch solid/notifications

delete branch : eventsource-document

delete time in 2 days

push eventsolid/notifications

Aaron Coburn

commit sha 78bc0ed9c583c22189efa2d3c7e0531330b14468

Define EventSourceSubscription2021 type for Solid Notifications

view details

Aaron Coburn

commit sha 79eb917ce704b1aae34c1414af970cbdd522bdf0

Use storage in preference to pod

view details

Aaron Coburn

commit sha ffb47cbaccd91abdb9f26389ccc1275b68550b6c

Add non-normative note

view details

Aaron Coburn

commit sha ac7ef42acec5de15a4cba0d353b8408ebdc77352

Rename subscription type

view details

Aaron Coburn

commit sha 0741c8811463cabb1fc7e8845e812067ce31e262

Adjust URL identifiers

view details

Aaron Coburn

commit sha 7cbc56dd0732f1369daf216d108d0b7e41097399

Formatting Co-authored-by: Sarven Capadisli <info@csarven.ca>

view details

Aaron Coburn

commit sha 09a914fc505dab95b789575c02b0aa4de73ff6f1

Add explicit URI for subscription type

view details

Aaron Coburn

commit sha b039caf144da86229b3dd9bfebf41ba84751d035

Merge pull request #27 from solid/eventsource-document Define EventSourceSubscription2021 type for Solid Notifications

view details

push time in 2 days

PR merged solid/notifications

Define EventSourceSubscription2021 type for Solid Notifications

The Solid Notification Protocol refers to an EventSourceSubscription2021 type but there is no detailed description of that type. This document defines the requirements for EventSourceSubscription2021.

+499 -0

0 comment

2 changed files

acoburn

pr closed time in 2 days

delete branch solid/notifications

delete branch : protocol-discovery

delete time in 2 days

issue closedsolid/notifications

Reconsider necessity of gateway API in notification protocol

At present, the Notification Protocol defines a gateway API that acts as a discovery endpoint for clients: agents submit POST JSON-LD requests and receive JSON-LD response bodies. This is an unauthenticated endpoint.

Rather than providing a required request-response gateway API, it would arguably be simpler do just define the subscription types that are supported in a single RDF document. Clients can fetch that RDF document and, given the features supported by the various subscription types, the client can simply choose which path to follow.

One can argue that the current gateway API model already has such an RDF document implicitly and the HTTP API brokers access to that document. Removing that API has several advantages:

  • The server implementation provides what is, effectively, a static document, thereby making the implementation considerably simpler
  • Any client code needs only to fetch and parse a single resource and can then decide on its own what subscription type(s) it uses, which arguably means fewer request/response cycles for the client

closed time in 2 days

acoburn

PR merged solid/notifications

Replace separate gateway endpoint with RDF-based protocol discovery

Resolves #24

This entirely removes the Gateway endpoint, replacing it with an RDF-based resource that can be used by clients to find the appropriate subscription API, based on the features and protocols supported by the client.

For example, the following RDF structure could replace the Gateway endpoint:

@prefix solid: <http://www.w3.org/ns/solid/terms#> .
@prefix notify: <http://www.w3.org/ns/solid/notifications#> .

<>
    a solid:StorageMetadata ;
    notify:hasWebSocketNotification <#websocketNotification> ;
    notify:hasWebHookNotification <#webhookNotification> ;
    notify:hasLinkedDataNotification <https://ldn.example/Metadata> .
<#websocketNotification>
    a notify:WebSocketSubscription2021 ;
    notify:endpoint <https://websocket.example/subscription> ;
    notify:features notify:state, notify:rate, notify:expiration .
<#webhookNotification>
    a notify:WebHookSubscription2021 ;
    notify:endpoint <https://webhook.example/subscription> ;
    notify:features notify:rate, notify:expiration, notify:webookAuth .
+75 -85

13 comments

1 changed file

acoburn

pr closed time in 2 days

push eventsolid/notifications

Aaron Coburn

commit sha 7d2b7ca356ac6d729921d068615956a9f867c997

Replace separate gateway endpoint with RDF-based protocol discovery Resolves #24

view details

Aaron Coburn

commit sha 626876b524dd2dc6fab1754fb0c788fa1abc85c1

Adjust discovery, add namespaces section

view details

Sarven Capadisli

commit sha b2d2ea5d203499c7d2e490edcae10881b92a470e

Minor

view details

Aaron Coburn

commit sha 26527f36947e0616dbd52b80ba887d514c9e38e5

Merge pull request #29 from solid/protocol-discovery Replace separate gateway endpoint with RDF-based protocol discovery

view details

push time in 2 days

push eventsolid/notifications

Aaron Coburn

commit sha 09a914fc505dab95b789575c02b0aa4de73ff6f1

Add explicit URI for subscription type

view details

push time in 2 days

push eventsolid/notifications

Aaron Coburn

commit sha 2480950c25412e364e3528c2855c0c4578644fb8

Use explicit URI for subscription type

view details

Aaron Coburn

commit sha fdb65a622ac519d3d39cd05b1d72dcc67ccfe437

Merge branch 'websocket-document' of github.com:solid/notifications into websocket-document

view details

push time in 2 days

Pull request review commentsolid/notifications

Define LinkedDataNotificationsSubscription2021 type for Solid Notifications

+<!DOCTYPE html>+<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">+  <head>+    <meta charset="utf-8" />+    <title>Solid Notifications: LinkedDataNotificationsSubscription2021</title>+    <meta content="width=device-width, initial-scale=1" name="viewport" />+    <link href="https://www.w3.org/StyleSheets/TR/2021/W3C-ED" media="all" rel="stylesheet" title="W3C-ED" />+<style>+body {+counter-reset:section;+counter-reset:sub-section;+}+em.rfc2119 { color: #900; }+code, samp { color: #c83500; }+pre code, pre samp { color: #000; }+dfn { font-weight:inherit; }+.do.fragment a { border-bottom:0; }+.do.fragment a:hover { background:none; border-bottom:0; }+section figure pre { margin:1em 0; display:block; }+cite .bibref { font-style: normal; }+.tabs nav ul li { margin:0; }+div.issue, div.note, div.warning {+clear: both;+margin: 1em 0;+padding: 1em 1.2em 0.5em;+position: relative;+}+div.issue h3, div.note h3,+div.issue h4, div.note h4,+div.issue h5, div.note h5 {+margin:0;+font-weight:normal;+font-style:normal;+}+div.issue h3 > span, div.note h3 > span,+div.issue h4 > span, div.note h4 > span,+div.issue h5 > span, div.note h5 > span {+text-transform: uppercase;+}+div.issue h3, div.issue h4, div.issue h5 {+color:#ae1e1e;+}+div.note h3, div.note h4, div.note h5 {+color:#178217;+}+figure .example-h {+margin-top:0;+text-align: left;+color:#827017;+}+figure .example-h > span {+text-transform: uppercase;+}++header address a[href] {+float: right;+margin: 1rem 0 0.2rem 0.4rem;+background: transparent none repeat scroll 0 0;+border: medium none;+text-decoration: none;+}+header address img[src*="logos/W3C"] {+background: #1a5e9a none repeat scroll 0 0;+border-color: #1a5e9a;+border-image: none;+border-radius: 0.4rem;+border-style: solid;+border-width: 0.65rem 0.7rem 0.6rem;+color: white;+display: block;+font-weight: bold;+}+main article > h1 {+font-size: 220%;+font-weight:bold;+}++article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id=exit-criteria]) {+counter-increment:section;+counter-reset:sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) {+counter-increment:sub-section;+counter-reset:sub-sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) section {+counter-increment:sub-sub-section;+counter-reset:sub-sub-sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) section section {+counter-increment:sub-sub-sub-section;+counter-reset:sub-sub-sub-sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id=exit-criteria]):not([id^=table-of-]) > h2:before {+content:counter(section) ".\00a0";+}+section:not([id$=references]):not([id^=change-log]):not([id=exit-criteria]) > h3:before {+content:counter(section) "." counter(sub-section) "\00a0";+}+section > h4:before {+content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";+}+#acknowledgements ul { padding: 0; margin:0 }+#acknowledgements li { display:inline; }+#acknowledgements li:after { content: ", "; }+#acknowledgements li:last-child:after { content: ""; }++aside.do { overflow:inherit; }+aside.do blockquote {+padding: 0; border: 0; margin: 0;+}+dl[id^="document-"] ul {+padding-left:0;+list-style-type:none;+}+dl [rel~="odrl:action"],+dl [rel~="odrl:action"] li {+display: inline;+}+dl [rel~="odrl:action"] li:after {+content: ",";+}+dl [rel~="odrl:action"] li:last-child:after {+content: "";+}+</style>+    <link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />+    <script src="https://dokie.li/scripts/dokieli.js"></script>+  </head>++  <body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ doap: http://usefulinc.com/ns/doap# deo: http://purl.org/spar/deo/ fabio: http://purl.org/spar/fabio/ cito: http://purl.org/spar/cito/ as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# earl: http://www.w3.org/ns/earl# spec: http://www.w3.org/ns/spec# rel: https://www.w3.org/ns/iana/link-relations/relation# odrl: http://www.w3.org/ns/odrl/2/" typeof="schema:CreativeWork prov:Entity as:Article">+    <header>+      <address>+        <a class="logo" href="https://solidproject.org/"><img height="66" width="72" alt="Solid Project" src="https://solidproject.org/TR/solid.svg"/></a>+      </address>+    </header>++    <main>+      <article about="" typeof="schema:Article doap:Specification">+        <h1 property="schema:name">LinkedDataNotificationsSubscription2021</h1>+        <h2>Editor’s Draft, 2021-12-23</h2>++        <details open="">+          <summary>More details about this document</summary>++          <dl id="document-identifier">+            <dt>This version</dt>+            <dd><a href="https://solid.github.io/notifications/linkeddatanotifications-subscription-2021" rel="owl:sameAs">https://solid.github.io/notifications/linkeddatanotifications-subscription-2021</a></dd>+          </dl>++          <dl id="document-latest-version">+            <dt>Latest version</dt>+            <dd><a href="https://solid.github.io/notifications/linkeddatanotifications-subscription-2021" rel="rel:latest-version">https://solid.github.io/notifications/linkeddatanotifications-subscription-2021</a></dd>+          </dl>++          <div id="authors">+            <dl id="author-name">+              <dt>Editors</dt>+              <dd id="Sarven-Capadisli"><span about="" rel="schema:creator schema:editor"><span about="https://csarven.ca/#i" typeof="schema:Person"><a rel="schema:url" href="https://csarven.ca/"><span about="https://csarven.ca/#i" property="schema:name"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span></span></dd>+            </dl>+          </div>++          <dl id="document-created">+            <dt>Created</dt>+            <dd><time content="2021-12-23T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-23T00:00:00Z" property="schema:dateCreated">2021-12-23</time></dd>+          </dl>++          <dl id="document-published">+            <dt>Published</dt>+            <dd><time content="2021-12-23T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-23T00:00:00Z" property="schema:datePublished">2021-12-23</time></dd>+          </dl>++          <dl id="document-modified">+            <dt>Modified</dt>+            <dd><time content="2021-12-23T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-23T00:00:00Z" property="schema:dateModified">2021-12-23</time></dd>+          </dl>++          <dl id="document-repository">+            <dt>Repository</dt>+            <dd><a href="https://github.com/solid/notifications" rel="doap:repository">GitHub</a></dd>+            <dd><a href="https://github.com/solid/notifications/issues" rel="doap:bug-database">Issues</a></dd>+          </dl>++          <dl id="document-language">+            <dt>Language</dt>+            <dd><span content="en" lang="" property="dcterms:language" xml:lang="">English</span></dd>+          </dl>++          <dl id="document-license">+            <dt>License</dt>+            <dd><a href="http://purl.org/NET/rdflicense/MIT1.0" rel="schema:license">MIT License</a></dd>+          </dl>++          <dl id="document-status">+            <dt>Document Status</dt>+            <dd prefix="pso: http://purl.org/spar/pso/" rel="pso:holdsStatusInTime" resource="#a23256bd-feda-4af2-a3fb-dfbb2194c377"><span rel="pso:withStatus" resource="http://purl.org/spar/pso/draft" typeof="pso:PublicationStatus">Editor’s Draft</span></dd>+          </dl>++          <dl id="document-in-reply-to">+            <dt>In Reply To</dt>+            <dd><a href="https://solidproject.org/origin" rel="as:inReplyTo">Solid Origin</a></dd>+            <dd><a href="https://solid.github.io/notifications/protocol" rel="as:inReplyTo">Solid Notifications Protocol</a></dd>+            <dd><a href="https://github.com/solid/process/blob/main/notifications-panel-charter.md" rel="as:inReplyTo">Notifications Panel Charter</a></dd>+          </dl>++          <dl id="document-policy">+            <dt>Policy</dt>+            <dd>+              <dl id="document-policy-offer" rel="odrl:hasPolicy" resource="#document-policy-offer" typeof="odrl:Policy">+                <dt>Rule</dt>+                <dd><a about="#document-policy-offer" href="https://www.w3.org/TR/odrl-vocab/#term-Offer" typeof="odrl:Offer">Offer</a></dd>+                <dt>Unique Identifier</dt>+                <dd><a href="https://solid.github.io/notifications/linkeddatanotifications-subscription-2021#document-policy-offer" rel="odrl:uid">https://solid.github.io/notifications/linkeddatanotifications-subscription-2021#document-policy-offer</a></dd>+                <dt>Target</dt>+                <dd><a href="https://solid.github.io/notifications/linkeddatanotifications-subscription-2021" rel="odrl:target">https://solid.github.io/notifications/linkeddatanotifications-subscription-2021</a></dd>+                <dt>Permission</dt>+                <dd>+                  <dl id="document-permission" rel="odrl:permission" resource="#document-permission" typeof="odrl:Permission">+                    <dt>Assigner</dt>+                    <dd><a rel="odrl:assigner" href="https://www.w3.org/community/solid/">W3C Solid Community Group</a></dd>+                    <dt>Action</dt>+                    <dd>+                      <ul rel="odrl:action">+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-aggregate" resource="odrl:aggregate">Aggregate</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-archive" resource="odrl:archive">Archive</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-concurrentUse" resource="odrl:concurrentUse">Concurrent Use</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-DerivativeWorks" resource="http://creativecommons.org/ns#DerivativeWorks">Derivative Works</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-derive" resource="odrl:derive">Derive</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-digitize" resource="odrl:digitize">Digitize</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-display" resource="odrl:display">Display</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-Distribution" resource="http://creativecommons.org/ns#Distribution">Distribution</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-index" resource="odrl:index">Index</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-inform" resource="odrl:inform">Inform</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-install" resource="odrl:install">Install</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-Notice" resource="http://creativecommons.org/ns#Notice">Notice</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-present" resource="odrl:present">Present</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-print" resource="odrl:print">Print</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-read" resource="odrl:read">Read</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-reproduce" resource="odrl:reproduce">Reproduce</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-Reproduction" resource="http://creativecommons.org/ns#Reproduction">Reproduction</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-stream" resource="odrl:stream">Stream</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-synchronize" resource="odrl:synchronize">Synchronize</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-textToSpeech" resource="odrl:textToSpeech">Text-to-speech</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-transform" resource="odrl:transform">Transform</a></li>+                        <li><a href="https://www.w3.org/TR/odrl-vocab/#term-translate" resource="odrl:translate">Translate</a></li>+                      </ul>+                    </dd>+                  </dl>+                </dd>+              </dl>+            </dd>+          </dl>+        </details>++        <p class="copyright">Copyright © 2021 <a href="http://www.w3.org/community/solid/">W3C Solid Community Group</a>.</p>++        <div datatype="rdf:HTML" id="content" property="schema:description">+          <section id="abstract">+            <h2>Abstract</h2>+            <div datatype="rdf:HTML" property="schema:abstract">+              <p>The <cite><a href="https://solid.github.io/notifications/protocol" rel="cito:discusses">Solid Notifications Protocol</a></cite> defines a set of interaction patterns for agents to establish subscriptions to resources in a <cite><a href="https://solidproject.org/TR/2021/protocol-20211217#storage" rel="cito:discusses">Solid Storage</a></cite>. This specification defines a <em>subscription type</em> to enable the delivery of change notifications about a resource to an <cite><a href="https://www.w3.org/TR/ldn/" rel="cito:discusses">Linked Data Notifications</a></cite> inbox.</p>+            </div>+          </section>++          <section id="sotd" inlist="" rel="schema:hasPart" resource="#sotd">+            <h2 property="schema:name">Status of This Document</h2>+            <div property="schema:description" datatype="rdf:HTML">+              <p>This section describes the status of this document at the time of its publication.</p>++              <p>This document was published by the <a href="https://www.w3.org/community/solid/">Solid Community Group</a> as an <em>Editor’s Draft</em>. The sections that have been incorporated have been reviewed following the <a href="https://github.com/solid/process">Solid process</a>. However, the information in this document is still subject to change. You are invited to <a href="https://github.com/solid/specification/issues">contribute</a> any feedback, comments, or questions you might have.</p>++              <p>Publication as an <em>Editor’s Draft</em> does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> 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.</p>++              <p>This document was produced by a group operating under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available.</p>+            </div>+          </section>++          <nav id="toc">+            <h2 id="table-of-contents">Table of Contents</h2>+            <div>+              <ol class="toc">+                <li class="tocline">+                  <a class="tocxref" href="#abstract">Abstract</a>+                </li>+                <li class="tocline">+                  <a class="tocxref" href="#sotd">Status of This Document</a>+                </li>+                <li class="tocline">+                  <a class="tocxref" href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>+                  <ol>+                    <li><a href="#terminology"><span class="secno">1.2</span> <span class="content">Terminology</span></a></li>+                    <li><a href="#overview"><span class="secno">1.3</span> <span class="content">Overview</span></a></li>+                    <li><a href="#conformance"><span class="secno">1.4</span> <span class="content">Conformance</span></a></li>+                  </ol>+                </li>+                <li class="tocline">+                  <a class="tocxref" href="#subscription-type"><span class="secno">2</span> <span class="content">LinkedDataNotificationsSubscription2021 Type</span></a>+                  <ol>+                    <li class="tocline">+                      <a class="tocxref" href="#linkeddatanotifications-subscription"><span class="secno">2.1</span> Subscription Example</a>+                    </li>+                  </ol>+                </li>+                <li class="tocline">+                  <a class="tocxref" href="#authentication-authorization"><span class="secno">3</span> <span class="content">Authentication and Authorization</span></a>+                </li>+                <li class="tocline">+                  <a class="tocxref" href="#references"><span class="secno"></span> <span class="content">References</span></a>+                  <ol>+                    <li><a href="#normative-references"><span class="secno"></span> <span class="content">Normative References</span></a></li>+                  </ol>+                </li>+              </ol>+            </div>+          </nav>++          <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction">+            <h2 about="#introduction" property="schema:name" typeof="deo:Introduction">Introduction</h2>+            <div datatype="rdf:HTML" property="schema:description">+              <p><em>This section is non-normative.</em></p>++              <p id="motivation" rel="schema:hasPart" resource="#motivation" typeof="deo:Motivation"><span datatype="rdf:HTML" property="schema:description">The <cite><a href="https://solid.github.io/notifications/protocol">Solid Notifications Protocol</a></cite> describes a general pattern by which agents can be notified when a Solid Resource changes. This specification defines a <em>subscription type</em> to enable the delivery of change notifications about a resource to <cite><a href="https://www.w3.org/TR/ldn/" rel="cito:discusses">Linked Data Notifications</a></cite> inbox.</span></p>++              <p>This specification is for:</p>++              <ul rel="schema:audience">+                <li><a href="http://data.europa.eu/esco/occupation/a7c1d23d-aeca-4bee-9a08-5993ed98b135">Resource server developers</a> who wish to enable clients to listen for updates to particular resources.</li>+                <li><a href="http://data.europa.eu/esco/occupation/c40a2919-48a9-40ea-b506-1f34f693496d">Application developers</a> who wish to implement a client to listen for updates to particular resources.</li>+              </ul>++              <!-- TODO define terminology -->+              <section class="todo" id="terminology" inlist="" rel="schema:hasPart" resource="#terminology" typeof="skos:ConceptScheme">+                <h3 property="schema:name skos:prefLabel">Terminology</h3>+                <div datatype="rdf:HTML" property="schema:description">+                  <p><em>This section is non-normative.</em></p>++                  <p>This document uses terminology from the <cite><a href="https://solid.github.io/notifications/protocol">Solid Notification Protocol</a></cite>, including <q cite="https://solid.github.io/notifications/protocol#notification-subscription-api">subscription API</q>. This document also uses terms from <cite><a href="https://datatracker.ietf.org/doc/html/rfc6749">The OAuth 2.0 Authorization Framework</a></cite> specification, including <q>resource server</q>, <q>authorization server</q>, <q>access token</q>, and <q>client</q>, as well as terms from the <cite><a href="https://www.w3.org/TR/websub/">WebSub</a></cite> specification, including <q cite="https://www.w3.org/TR/websub/#dfn-topic">topic</q>.</p>+                </div>+              </section>++              <section class="todo" id="overview" inlist="" rel="schema:hasPart" resource="#overview">+                <h3 property="schema:name">Overview</h3>+                <div datatype="rdf:HTML" property="schema:description">+                  <p><em>This section is non-normative.</em></p>++                  <p>The following diagram shows the high-level interactions involved in this flow. How a client retrieves an access token for step 5 is outside the scope of this document.</p>++                  <figure id="solid-linkeddatanotifications-flow" rel="schema:hasPart" resource="#solid-linkeddatanotifications-flow">+                    <img src="linkeddatanotifications-subscription-2021-flow.png" height="318" rel="schema:image" width="640" />

This png file doesn't seem to be present in this PR

csarven

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentsolid/notifications

Define StreamingHTTPSubscription2021 type for Solid Notifications

+# StreamingHTTPSubscription2021++The [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)+defines a set of interaction patterns for agents to establish subscriptions to resources in a Solid Storage.++This specification defines a subscription type that applies these patterns to the Fetch API.++## Introduction++*This section is non-normative.*++The [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)+describes a general pattern by which agents can be notified when a Solid Resource changes.+In the context of a Web Browser, the Streaming HTTP API provides a convenient mechanism for a Solid Storage+to alert a subscribing client of these changes.++This document describes a Solid Notifications subscription type that makes use of the Fetch API.++This specification is for:++* Resource 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.++### Terminology++**This section is non-normative.**++This document uses terminology from the Solid Notification Protocol, including "subscription API", "gateway API".+This document also uses terms from The OAuth 2.0 Authorization Framework specification,+including "resource server", "authorization server", "access token", and "client",+as well as terms from the WebSub specification, including "topic".++### Conformance++++All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative.+Everything else is normative.++The key words “MUST” and “MUST NOT” are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14)+[[RFC2119]](https://datatracker.ietf.org/doc/html/rfc2119) [[RFC8174]](https://datatracker.ietf.org/doc/html/rfc8174) when,+and only when, they appear in all capitals, as shown here.+++## StreamingHTTPSubscription2021 Type++This specification defines the StreamingHTTPSubscription2021 type for use with Solid Notifications subscriptions.+that use the Fetch API.++An StreamingHTTPSubscription2021 API MUST conform to the [Solid Notifications Protocol](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/7cbc56dd0732f1369daf216d108d0b7e41097399/eventsource-subscription-2021.html#discovery).++An StreamingHTTPSubscription2021 API SHOULD support the [Solid Notifications Features](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/7cbc56dd0732f1369daf216d108d0b7e41097399/eventsource-subscription-2021.html#notification-features).++The StreamingHTTPSubscription2021 type defines the following properties:++#### endpoint+The endpoint property is used in the body of the subscription response.+The value of this property MUST be a URI, using the `https` scheme.+A JavaScript client would use the entire value as input to the `fetch` function.++A client establishes a subscription using the StreamingHTTPSubscription2021 type by sending an authenticated subscription request+to the hypermedia API retrieved via Solid Notifications discovery.++For StreamingHTTPSubscription2021 interactions, the client sends a JSON-LD payload to the appropriate hypermedia API via POST.+The only required fields in this interaction are type and topic. The type field MUST contain the type of subscription being requested.+The topic field MUST contain the URL of the resource a client wishes to subscribe to changes.++### Subscription Example++*This section is non-normative.*++An example `POST` request using a `DPoP` bound access token is below:++```http+POST /subscription+Authorization: DPoP <token>+DPoP: <proof>+Content-Type: application/ld+json+```+```jsonld+{+  "@context": ["https://www.w3.org/ns/solid/notification/v1"],+  "type": "StreamingHTTPSubscription2021",+  "topic": "https://storage.example/resource",+  "state": "opaque-state",+  "expiration": "2021-12-23T12:37:15Z",+  "rate": "PT10s"+}+```+> POST request including type and topic targeting the Notification Subscription API.++A successful response will contain a URL to the subscription API that can be used directly with a JavaScript client.++```http+Content-Type: application/ld+json+```+```jsonld+{+  "@context": "https://www.w3.org/ns/solid/notification/v1",+  "type": "StreamingHTTPSubscription2021",+  "endpoint": "https://fetch.example/?auth=Ys3KiUq"+}+```+> Response to the POST request including type and endpoint.++In JavaScript, a client can use the data in the response to establish a connection to the Fetch API.+And define how to handle notifications++```js+ (async function () {+        const request = await fetch('https://fetch.example/?auth=Ys3KiUq')+        const reader = request.body.getReader()+        const decoder = new TextDecoder()+        reader.read().then(function handle({done, value}) {+            console.log(decoder.decode(value))+            return reader.read().then(handle)+        })+      })()++```++## Authentication and Authorization++Streaming HTTP Subscription has advantage of being able to authenticate with notification endpoint+not only subscription endpoint. Same *access token* can be used with both endpoints.
not only the subscription endpoint. The same *access token* can be used with both endpoints.
elf-pavlik

comment created time in 2 days

Pull request review commentsolid/notifications

Define StreamingHTTPSubscription2021 type for Solid Notifications

+# StreamingHTTPSubscription2021++The [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)+defines a set of interaction patterns for agents to establish subscriptions to resources in a Solid Storage.++This specification defines a subscription type that applies these patterns to the Fetch API.++## Introduction++*This section is non-normative.*++The [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)+describes a general pattern by which agents can be notified when a Solid Resource changes.+In the context of a Web Browser, the Streaming HTTP API provides a convenient mechanism for a Solid Storage+to alert a subscribing client of these changes.++This document describes a Solid Notifications subscription type that makes use of the Fetch API.++This specification is for:++* Resource 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.++### Terminology++**This section is non-normative.**++This document uses terminology from the Solid Notification Protocol, including "subscription API", "gateway API".+This document also uses terms from The OAuth 2.0 Authorization Framework specification,+including "resource server", "authorization server", "access token", and "client",+as well as terms from the WebSub specification, including "topic".++### Conformance++++All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative.+Everything else is normative.++The key words “MUST” and “MUST NOT” are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14)+[[RFC2119]](https://datatracker.ietf.org/doc/html/rfc2119) [[RFC8174]](https://datatracker.ietf.org/doc/html/rfc8174) when,+and only when, they appear in all capitals, as shown here.+++## StreamingHTTPSubscription2021 Type++This specification defines the StreamingHTTPSubscription2021 type for use with Solid Notifications subscriptions.+that use the Fetch API.++An StreamingHTTPSubscription2021 API MUST conform to the [Solid Notifications Protocol](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/7cbc56dd0732f1369daf216d108d0b7e41097399/eventsource-subscription-2021.html#discovery).++An StreamingHTTPSubscription2021 API SHOULD support the [Solid Notifications Features](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/7cbc56dd0732f1369daf216d108d0b7e41097399/eventsource-subscription-2021.html#notification-features).++The StreamingHTTPSubscription2021 type defines the following properties:++#### endpoint+The endpoint property is used in the body of the subscription response.+The value of this property MUST be a URI, using the `https` scheme.+A JavaScript client would use the entire value as input to the `fetch` function.++A client establishes a subscription using the StreamingHTTPSubscription2021 type by sending an authenticated subscription request+to the hypermedia API retrieved via Solid Notifications discovery.++For StreamingHTTPSubscription2021 interactions, the client sends a JSON-LD payload to the appropriate hypermedia API via POST.+The only required fields in this interaction are type and topic. The type field MUST contain the type of subscription being requested.+The topic field MUST contain the URL of the resource a client wishes to subscribe to changes.++### Subscription Example++*This section is non-normative.*++An example `POST` request using a `DPoP` bound access token is below:++```http+POST /subscription+Authorization: DPoP <token>+DPoP: <proof>+Content-Type: application/ld+json+```+```jsonld+{+  "@context": ["https://www.w3.org/ns/solid/notification/v1"],+  "type": "StreamingHTTPSubscription2021",+  "topic": "https://storage.example/resource",+  "state": "opaque-state",+  "expiration": "2021-12-23T12:37:15Z",+  "rate": "PT10s"+}+```+> POST request including type and topic targeting the Notification Subscription API.++A successful response will contain a URL to the subscription API that can be used directly with a JavaScript client.++```http+Content-Type: application/ld+json+```+```jsonld+{+  "@context": "https://www.w3.org/ns/solid/notification/v1",+  "type": "StreamingHTTPSubscription2021",+  "endpoint": "https://fetch.example/?auth=Ys3KiUq"+}+```+> Response to the POST request including type and endpoint.++In JavaScript, a client can use the data in the response to establish a connection to the Fetch API.+And define how to handle notifications++```js+ (async function () {+        const request = await fetch('https://fetch.example/?auth=Ys3KiUq')+        const reader = request.body.getReader()+        const decoder = new TextDecoder()+        reader.read().then(function handle({done, value}) {+            console.log(decoder.decode(value))+            return reader.read().then(handle)+        })+      })()++```++## Authentication and Authorization++Streaming HTTP Subscription has advantage of being able to authenticate with notification endpoint+not only subscription endpoint. Same *access token* can be used with both endpoints.+This doesn't just rely on notification endpoint being a [Capability URL](https://www.w3.org/TR/capability-urls/)
This doesn't just rely on the notification endpoint being a [Capability URL](https://www.w3.org/TR/capability-urls/)
elf-pavlik

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentsolid/notifications

Define StreamingHTTPSubscription2021 type for Solid Notifications

+# StreamingHTTPSubscription2021++The [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)+defines a set of interaction patterns for agents to establish subscriptions to resources in a Solid Storage.++This specification defines a subscription type that applies these patterns to the Fetch API.++## Introduction++*This section is non-normative.*++The [Solid Notifications Protocol](https://solid.github.io/notifications/protocol)+describes a general pattern by which agents can be notified when a Solid Resource changes.+In the context of a Web Browser, the Streaming HTTP API provides a convenient mechanism for a Solid Storage+to alert a subscribing client of these changes.++This document describes a Solid Notifications subscription type that makes use of the Fetch API.++This specification is for:++* Resource 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.++### Terminology++**This section is non-normative.**++This document uses terminology from the Solid Notification Protocol, including "subscription API", "gateway API".+This document also uses terms from The OAuth 2.0 Authorization Framework specification,+including "resource server", "authorization server", "access token", and "client",+as well as terms from the WebSub specification, including "topic".++### Conformance++++All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative.+Everything else is normative.++The key words “MUST” and “MUST NOT” are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14)+[[RFC2119]](https://datatracker.ietf.org/doc/html/rfc2119) [[RFC8174]](https://datatracker.ietf.org/doc/html/rfc8174) when,+and only when, they appear in all capitals, as shown here.+++## StreamingHTTPSubscription2021 Type++This specification defines the StreamingHTTPSubscription2021 type for use with Solid Notifications subscriptions.+that use the Fetch API.++An StreamingHTTPSubscription2021 API MUST conform to the [Solid Notifications Protocol](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/7cbc56dd0732f1369daf216d108d0b7e41097399/eventsource-subscription-2021.html#discovery).++An StreamingHTTPSubscription2021 API SHOULD support the [Solid Notifications Features](https://htmlpreview.github.io/?https://github.com/solid/notifications/blob/7cbc56dd0732f1369daf216d108d0b7e41097399/eventsource-subscription-2021.html#notification-features).++The StreamingHTTPSubscription2021 type defines the following properties:++#### endpoint+The endpoint property is used in the body of the subscription response.+The value of this property MUST be a URI, using the `https` scheme.+A JavaScript client would use the entire value as input to the `fetch` function.++A client establishes a subscription using the StreamingHTTPSubscription2021 type by sending an authenticated subscription request+to the hypermedia API retrieved via Solid Notifications discovery.++For StreamingHTTPSubscription2021 interactions, the client sends a JSON-LD payload to the appropriate hypermedia API via POST.+The only required fields in this interaction are type and topic. The type field MUST contain the type of subscription being requested.+The topic field MUST contain the URL of the resource a client wishes to subscribe to changes.++### Subscription Example++*This section is non-normative.*++An example `POST` request using a `DPoP` bound access token is below:++```http+POST /subscription+Authorization: DPoP <token>+DPoP: <proof>+Content-Type: application/ld+json+```+```jsonld+{+  "@context": ["https://www.w3.org/ns/solid/notification/v1"],+  "type": "StreamingHTTPSubscription2021",+  "topic": "https://storage.example/resource",+  "state": "opaque-state",+  "expiration": "2021-12-23T12:37:15Z",+  "rate": "PT10s"+}+```+> POST request including type and topic targeting the Notification Subscription API.++A successful response will contain a URL to the subscription API that can be used directly with a JavaScript client.++```http+Content-Type: application/ld+json+```+```jsonld+{+  "@context": "https://www.w3.org/ns/solid/notification/v1",+  "type": "StreamingHTTPSubscription2021",+  "endpoint": "https://fetch.example/?auth=Ys3KiUq"+}+```+> Response to the POST request including type and endpoint.++In JavaScript, a client can use the data in the response to establish a connection to the Fetch API.+And define how to handle notifications++```js+ (async function () {+        const request = await fetch('https://fetch.example/?auth=Ys3KiUq')+        const reader = request.body.getReader()+        const decoder = new TextDecoder()+        reader.read().then(function handle({done, value}) {+            console.log(decoder.decode(value))+            return reader.read().then(handle)+        })+      })()++```++## Authentication and Authorization++Streaming HTTP Subscription has advantage of being able to authenticate with notification endpoint
Streaming HTTP Subscription has the advantage of being able to authenticate with the notification endpoint
elf-pavlik

comment created time in 2 days

PullRequestReviewEvent
more