notifications-protocol.html

<!DOCTYPE html>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta charset="utf-8" />
    <title>Solid Notifications Protocol</title>
    <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport" />
<style>
main,
main>article,
main>article>div {
background:inherit;
}
body {
counter-reset:section sub-section appendix sub-appendix;
}
code, samp { color: #e00; }
pre code, pre samp { color: var(--text); }
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;
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;
font-size:1em;
}
div.issue h3 > span, div.note h3 > span,
div.issue h4 > span, div.note h4 > span,
div.issue h5 > span, div.note h5 > span,
figure.example > figcaption > span {
text-transform: uppercase;
}
div.issue h3, div.issue h4, div.issue h5 {
color:var(--issueheading-text);
}
div.note h3, div.note h4, div.note h5 {
color:var(--noteheading-text);
}
figure.example figcaption {
color:var(--exampleheading-text);
}
main figure {
text-align:left;
}
figure[id] {
position:relative;
padding:0.5em;
}
figure[id] figcaption {
font-style:normal;
font-size:1em;
}
figure.example figcaption span + span {
text-transform:initial;
}
.copyright + hr {
border-style: solid;
}
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;
}
#acknowledgements ul { padding: 0; margin:0; }
#acknowledgements li { display:inline; }
#acknowledgements li:after { content: ", "; }
#acknowledgements li:last-child:after { content: ""; }
dd .contributed {
user-select: none;
}
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: "";
}
aside section > .toc,
aside section > .toc ol {
margin-left: revert;
}
aside section > .toc li li {
margin-left: 1em;
font-size: revert;
}
table {
border-collapse:collapse;
}
table + table {
margin-top:2em;
}
caption {
text-align:left;
padding:0 0.25em 0.25em;
margin-bottom: 1em;
font-size: 1em;
font-style: revert;
font-weight: bold;
border-bottom: 1px solid;
}
caption, tbody, tfoot {
border-bottom:2pt solid #ccc;
}
thead,
thead th[colspan] {
border-bottom:1pt solid #ccc;
}
[rowspan] { vertical-align: bottom; }
tbody [rowspan] { vertical-align: middle; }
tbody th[scope="rowgroup"] {
border-bottom:3pt double #ccc;
}
tr {
border-bottom:1pt solid #ccc;
}
th, td {
padding:0.25em;
font-size:0.923em;
word-wrap:normal;
}
table ul,
table ol,
table li,
table p,
table dd {
margin:0;
text-align:left;
}
table ul,
table ol {
padding-left:1em;
}
tfoot td > * + * {
margin-top:1em;
}
tfoot dd:after { content: "\A"; white-space:pre; }
tfoot dt, tfoot dd { display:inline; }
tfoot dd { margin-left: 0.5em; }
tfoot dd + dt { margin-top:0; }
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):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=changelog]) 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=changelog]) 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=changelog]) 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=changelog]):not([id=exit-criteria]):not([id^=table-of-]):not([id^=list-of-]) > h2:before {
content:counter(section) ".\00a0";
}
section:not([id$=references]):not([id^=changelog]):not([id=exit-criteria]):not([id^=table-of-]):not([id^=list-of-]) > h3:before {
content:counter(section) "." counter(sub-section) "\00a0";
}
section > h4:before {
content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";
}
article section.appendix {
counter-increment:appendix;
counter-reset:sub-appendix;
}
article section[class~=appendix]:not([id=abstract]):not([id=sotd]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]) section {
counter-increment:sub-appendix;
counter-reset:sub-sub-appendix;
}
section.appendix > h2:before {
content:counter(appendix, upper-alpha) ".\00a0";
}
section.appendix section > h3:before {
content:counter(appendix, upper-alpha) "." counter(sub-appendix) "\00a0";
}
.self-link {
display: inline-block;
margin-right:0.25em;
user-select: none;
font-family: monospace;
font-style:normal;
font-weight:bold;
outline:none;
text-align:left;
text-decoration:underline;
border:0;
background-color:transparent;
line-height: 1;
vertical-align: initial;
}
figure[id] figcaption {
margin-left:1em;
}
figure[id] .self-link {
position:absolute;
top:1em;
left:0.5em;
}
.self-link:after {
content:"#";
font-size: initial;
}
aside > .self-link:after {
content:"|";
}
dl > .self-link:after {
content:"☝";
}
nav > .self-link:after {
content:"☛";
}
p > .self-link:after {
content:"¶";
}
section > .self-link:after {
content:"§";
}
figure > .self-link:after {
content:"❦";
}
table > .self-link:after {
content:"𝄜";
}
[rel~="spec:requirement"] .self-link:after {
content:"◎";
}
[rel~="spec:advisement"] .self-link:after {
content:"✪";
}
h2,h3,h4,h5,h6 {
display:inline-block;
margin-block:0;
margin-bottom:0.5rem;
}
</style>
    <link href="https://www.w3.org/StyleSheets/TR/2021/cg-draft" media="all" rel="stylesheet" title="CG-DRAFT" />
    <link href="https://www.w3.org/StyleSheets/TR/2021/dark.css" media="(prefers-color-scheme: dark)" rel="stylesheet" />
  </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/ 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/">
    <main>
      <article about="" typeof="schema:Article">
        <div class="head">
          <h1 property="schema:name">Solid Notifications Protocol</h1>

          <p id="w3c-state"><a href="https://www.w3.org/standards/types/#reports" rel="rdf:type">Draft Community Group Report</a>, <time datetime="2024-05-12T00:00:00Z">12 May 2024</time></p>

          <details open="">
            <summary>More details about this document</summary>

            <dl id="document-identifier">
              <dt>This version</dt>
              <dd><a href="https://solidproject.org/TR/2024/notifications-protocol-20240512" rel="owl:sameAs mem:memento">https://solidproject.org/TR/2022/notifications-protocol-20240512</a></dd>
            </dl>

            <dl id="document-latest-published-version">
              <dt>Latest published version</dt>
              <dd><a href="https://solidproject.org/TR/notifications-protocol" rel="rel:latest-version">https://solidproject.org/TR/notifications-protocol</a></dd>
            </dl>

            <dl id="document-previous-version">
              <dt>Previous version</dt>
              <dd><a href="https://solidproject.org/TR/2022/notifications-protocol-20221231" rel="rel:predecessor-version">https://solidproject.org/TR/2022/notifications-protocol-20221231</a></dd>
            </dl>
            <dl id="document-editors-draft">
              <dt>Editor’s draft</dt>
              <dd><a href="https://solid.github.io/notifications/protocol" rel="rdfs:seeAlso">https://solid.github.io/notifications/protocol</a></dd>
            </dl>

            <dl id="document-history">
              <dt>History</dt>
              <dd><a href="https://github.com/solid/notifications/commits/main/protocol.html">Commit history</a></dd>
            </dl>

            <dl id="document-editors">
              <dt>Editors</dt>
              <dd data-editor-id="46140" id="Sarven-Capadisli"><span about="" rel="schema:creator schema:editor"><span about="https://csarven.ca/#i" typeof="schema:Person"><a href="https://csarven.ca/" rel="schema:url"><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>

            <dl id="document-authors">
              <dt>Authors</dt>
              <dd id="Aaron-Coburn"><span about="" rel="schema:author"><span about="https://people.apache.org/~acoburn/#i" typeof="schema:Person"><a href="https://people.apache.org/~acoburn/" rel="schema:url"><span about="https://people.apache.org/~acoburn/#i" property="schema:name"><span property="schema:givenName">Aaron</span> <span property="schema:familyName">Coburn</span></span></a></span></span></dd>
              <dd><a about="" href="https://csarven.ca/" rel="schema:author" resource="https://csarven.ca/#i">Sarven Capadisli</a></dd>
              <dd id="elf-Pavlik"><span about="" rel="schema:author"><span about="https://elf-pavlik.hackers4peace.net" typeof="schema:Person"><a href="https://hackers4peace.net/elf-pavlik" rel="schema:url"><span about="https://elf-pavlik.hackers4peace.net" property="schema:name">elf Pavlik</span></a></span></span></dd>
              <dd id="Rahul-Gupta"><span about="" rel="schema:author"><span about="https://cxres.pages.dev/profile#i" typeof="schema:Person"><a href="https://cxres.pages.dev/" rel="schema:url"><span about="https://cxres.pages.dev/profile#i" property="schema:name"><span property="schema:givenName">Rahul</span> <span property="schema:familyName">Gupta</span></span></a></span></span></dd>
            </dl>

            <dl id="document-created">
              <dt>Created</dt>
              <dd><time content="2022-05-09T00:00:00Z" datatype="xsd:dateTime" datetime="2022-05-09T00:00:00Z" property="schema:dateCreated">2022-05-09</time></dd>
            </dl>

            <dl id="document-published">
              <dt>Published</dt>
              <dd><time content="2022-05-09T00:00:00Z" datatype="xsd:dateTime" datetime="2022-05-09T00:00:00Z" property="schema:datePublished">2022-05-09</time></dd>
            </dl>

            <dl id="document-modified">
              <dt>Modified</dt>
              <dd><time content="2024-05-12T00:00:00Z" datatype="xsd:dateTime" datetime="2024-05-12T00:00:00Z" property="schema:dateModified">2024-05-12</time></dd>
            </dl>

            <dl id="document-feedback">
              <dt>Feedback</dt>
              <dd><a href="https://github.com/solid/notifications" rel="doap:repository">GitHub solid/notifications</a> (<a href="https://github.com/solid/notifications/pulls">pull requests</a>, <a href="https://github.com/solid/notifications/issues/new">new issue</a>, <a href="https://github.com/solid/notifications/issues" rel="doap:bug-database">open 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-type">
              <dt>Document Type</dt>
              <dd><a href="http://usefulinc.com/ns/doap#Specification" rel="rdf:type">Specification</a></dd>
            </dl>

            <dl id="document-version">
              <dt>Version</dt>
              <dd><span lang="" property="schema:version" xml:lang="">0.3.0</span></dd>
            </dl>

            <dl id="document-in-reply-to">
              <dt>In Reply To</dt>
              <dd><a href="https://solidproject.org/about" rel="as:inReplyTo">About Solid</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://solidproject.org/TR/notifications-protocol#document-policy-offer" rel="odrl:uid">https://solidproject.org/TR/notifications-protocol#document-policy-offer</a></dd>
                  <dt>Target</dt>
                  <dd><a href="https://solidproject.org/TR/notifications-protocol" rel="odrl:target">https://solidproject.org/TR/notifications-protocol</a></dd>
                  <dt>Permission</dt>
                  <dd>
                    <dl id="document-permission" rel="odrl:permission" resource="#document-permission" typeof="odrl:Permission">
                      <dt>Assigner</dt>
                      <dd><a href="https://www.w3.org/groups/cg/solid/" rel="odrl:assigner">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" rel="dcterms:rights" resource="#document-rights"><span property="dcterms:description"><a href="https://www.w3.org/policies/#copyright">Copyright</a> © 2021–2024 the Contributors to Solid Protocol, Version 0.3.0, published by the <a about="" href="https://www.w3.org/groups/cg/solid/" rel="schema:publisher"><span property="schema:name">Solid Community Group</span></a> under the <a about="" href="https://www.w3.org/community/about/agreements/cla/" rel="schema:license">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.</span></p>

          <hr title="Separator for header" />
        </div>

        <div datatype="rdf:HTML" id="content" property="schema:description">
          <section id="abstract"><a class="self-link" href="#abstract"></a>
            <h2>Abstract</h2>
            <div datatype="rdf:HTML" property="schema:abstract">
              <p>This specification defines a Linked Data-based protocol for sending notification to client application upon updates to resources in the Solid ecosystem while respecting resource-based access controls and privacy.</p>
            </div>
          </section>

          <section id="sotd" inlist="" rel="schema:hasPart" resource="#sotd"><a class="self-link" href="#sotd"></a>
            <h2 property="schema:name">Status of This Document</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>This report was published by the <a href="https://www.w3.org/groups/cg/solid/">Solid Community Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="https://www.w3.org/community/">W3C Community and Business Groups</a>.</p>
            </div>
          </section>

          <nav id="toc">
            <h2>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"><bdi class="secno">1.</bdi> <span>Introduction</span></a>
                  <ol>
                    <li class="tocline"><a href="#overview"><bdi class="secno">1.1</bdi> <span>Overview</span></a></li>
                    <li class="tocline"><a href="#namespaces"><bdi class="secno">1.2</bdi> <span>Namespaces</span></a></li>
                    <li class="tocline"><a href="#conformance"><bdi class="secno">1.3</bdi> <span>Conformance</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#protocol"><bdi class="secno">2.</bdi> <span>Protocol</span></a>
                  <ol>
                    <li class="tocline">
                      <a class="tocxref" href="#discovery"><bdi class="secno">2.1</bdi> <span>Discovery</span></a>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#subscription"><bdi class="secno">2.2</bdi> <span>Subscription</span></a>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#notification-channel"><bdi class="secno">2.3</bdi> <span>Notification Channel</span></a>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#notification-message"><bdi class="secno">2.4</bdi> <span>Notification Message</span></a>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#data-model"><bdi class="secno">3.</bdi> <span>Data Model</span></a>
                  <ol>
                    <li class="tocline">
                      <a class="tocxref" href="#description-resource-data-model"><bdi class="secno">3.1</bdi> <span>Description Resource</span></a>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#subscription-service-data-model"><bdi class="secno">3.2</bdi> <span>Subscription Service</span></a>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#notification-channel-data-model"><bdi class="secno">3.3</bdi> <span>Notification Channel</span></a>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#notification-message-data-model"><bdi class="secno">3.4</bdi> <span>Notification Message</span></a>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#considerations"><bdi class="secno">4.</bdi> <span>Considerations</span></a>
                  <ol>
                    <li><a href="#security-considerations"><bdi class="secno">4.1</bdi> <span>Security Considerations</span></a></li>
                    <li><a href="#privacy-considerations"><bdi class="secno">4.2</bdi> <span>Privacy Considerations</span></a></li>
                    <li><a href="#security-privacy-review"><bdi class="secno">4.3</bdi> <span>Security and Privacy Review</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#changelog"><bdi class="secno">A.</bdi> <span>Changelog</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#acknowledgements"><bdi class="secno">B.</bdi> <span>Acknowledgements</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#references"><bdi class="secno">C.</bdi> <span>References</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#normative-references"><bdi class="secno">C.1</bdi> <span>Normative References</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#informative-references"><bdi class="secno">C.2</bdi> <span>Informative References</span></a></li>
                  </ol>
                </li>
              </ol>
            </div>
          </nav>

          <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"><a class="self-link" href="#introduction"></a>
            <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"><a class="self-link" href="#motivation"></a><span datatype="rdf:HTML" property="schema:description">The Solid Notification Protocol defines an extensible, HTTP-based framework by which client applications can receive notifications for HTTP resource changes.</span></p>

              <p>A goal of the protocol defined by this specification is to enable interaction patterns both for cases where an HTTP client maintains an open connection to receive notifications as well as for cases where an HTTP client makes a request for notifications and then disconnects.</p>
              <p>This specification is for:</p>

              <ul about="" rel="schema:audience">
                <li><a href="http://data.europa.eu/esco/occupation/a7c1d23d-aeca-4bee-9a08-5993ed98b135">Server developers</a> that want 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 want to implement a client to listen for updates to particular resources.</li>
              </ul>

              <p>In addition to this specification, readers might find the Use Cases and Requirements for Notifications Protocol [<cite><a class="bibref" href="#bib-notifications-ucr">NOTIFICATIONS-UCR</a></cite>] document useful.</p>

              <section id="overview" inlist="" rel="schema:hasPart" resource="#overview"><a class="self-link" href="#overview"></a>
                <h3 property="schema:name">Overview</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p>The Solid Notification protocol defines a mechanism for client applications to discover notification services available for any given resource.</p>

                  <p>The following diagram shows the high-level interactions involved in discovering Notification Channels and Subscription Services.</p>

                  <figure id="solid-notifications-flow-discovery" rel="schema:hasPart" resource="#solid-notifications-flow-discovery-subscription">
                    <figcaption property="schema:name">Solid Notifications Flow Discovery</figcaption><a class="self-link" href="#solid-notifications-flow-discovery"></a>

                    <img rel="schema:image" src="2024/notifications-flow-discovery.20240512.svg" width="800" />
                  </figure>

                  <p>A Subscription Service allows Subscription Clients to request a customised Notification Channel.</p>

                  <p>The following diagram shows the high-level interactions involved in establishing a customised Notification Channel.</p>

                  <figure id="solid-notifications-flow-subscription" rel="schema:hasPart" resource="#solid-notifications-flow-discovery-subscription">
                    <figcaption property="schema:name">Solid Notifications Flow Subscription</figcaption><a class="self-link" href="#solid-notifications-flow-subscription"></a>

                    <img rel="schema:image" src="2024/notifications-flow-subscription.20240512.svg" width="800" />
                  </figure>

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

                  <figure id="solid-notifications-flow-receivefrom" rel="schema:hasPart" resource="#solid-notifications-flow-receivefrom">
                    <figcaption property="schema:name">Solid Notifications Flow Receive From, where the receiver establishes connection to sender.</figcaption><a class="self-link" href="#solid-notifications-flow-receivefrom"></a>

                    <img rel="schema:image" src="2024/notifications-flow-receivefrom.20240512.svg" width="800" />
                  </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">
                    <figcaption property="schema:name">Solid Notifications Flow Send To, where the sender delivers notifications to receiver.</figcaption><a class="self-link" href="#solid-notifications-flow-sendto"></a>

                    <img rel="schema:image" src="2024/notifications-flow-sendto.20240512.svg" width="800" />
                  </figure>
                </div>
              </section>

              <section id="namespaces" inlist="" rel="schema:hasPart" resource="#namespaces" typeof="skos:Collection"><a class="self-link" href="#namespaces"></a>
                <h3 property="schema:name skos:prefLabel">Namespaces</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <table>
                    <caption>Prefixes and Namespaces</caption>
                    <thead>
                      <tr>
                        <th>Prefix</th>
                        <th>Namespace</th>
                        <th>Description</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr rel="skos:member" resource="http://www.w3.org/ns/solid/notifications#" typeof="owl:Ontology">
                        <td><code>notify</code></td>
                        <td>http://www.w3.org/ns/solid/notifications#</td>
                        <td property="skos:prefLabel">Solid Notifications</td>
                      </tr>
                    </tbody>
                  </table>
                </div>
              </section>

              <section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance"><a class="self-link" href="#conformance"></a>
                <h3 property="schema:name">Conformance</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>This section describes the <span about="" rel="spec:conformance" resource="#conformance">conformance model of the Solid Notifications Protocol</span>.</p>

                  <section id="normative-informative-content" inlist="" rel="schema:hasPart" resource="#normative-informative-content"><a class="self-link" href="#normative-informative-content"></a>
                    <h4 property="schema:name">Normative and Informative Content</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p id="normative-informative-sections"><a class="self-link" href="#normative-informative-sections"></a>All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>

                      <p id="requirement-levels"><a class="self-link" href="#requirement-levels"></a>The key words “<span rel="dcterms:subject" resource="spec:MUST">MUST</span>”, “<span rel="dcterms:subject" resource="spec:MUSTNOT">MUST NOT</span>”, “<span rel="dcterms:subject" resource="spec:SHOULD">SHOULD</span>”, and “<span rel="dcterms:subject" resource="spec:MAY">MAY</span>” are to be interpreted as described in <a href="https://www.rfc-editor.org/info/bcp14">BCP 14</a> [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>] [<cite><a class="bibref" href="#bib-rfc8174">RFC8174</a></cite>] when, and only when, they appear in all capitals, as shown here.</p>

                      <p id="advisement-levels"><a class="self-link" href="#advisement-levels"></a>The key words “<span rel="dcterms:subject" resource="spec:StronglyEncouraged">strongly encouraged</span>”, “<span rel="dcterms:subject" resource="spec:StronglyDiscouraged">strongly discouraged</span>”, “<span rel="dcterms:subject" resource="spec:Encouraged">encouraged</span>", “<span rel="dcterms:subject" resource="spec:Discouraged">discouraged</span>", “<span rel="dcterms:subject" resource="spec:Can">can</span>", “<span rel="dcterms:subject" resource="spec:Cannot">cannot</span>”, “<span rel="dcterms:subject" resource="spec:Could">could</span>”, “<span rel="dcterms:subject" resource="spec:CouldNot">could not</span>”, “<span rel="dcterms:subject" resource="spec:Might">might</span>”, and “<span rel="dcterms:subject" resource="spec:MightNot">might not</span>” are used for non-normative content.</p>
                    </div>
                  </section>

                  <section id="specification-category" inlist="" rel="schema:hasPart" resource="#specification-category" typeof="skos:ConceptScheme"><a class="self-link" href="#specification-category"></a>
                    <h4 property="schema:name skos:prefLabel">Specification Category</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p property="skos:definition">The <span about="" rel="spec:specificationCategory" resource="#specification-category">Solid Notifications Protocol</span> identifies the following <cite><a href="https://www.w3.org/TR/spec-variability/#spec-cat" rel="dcterms:subject" resource="spec:SpecificationCategory">Specification Category</a></cite> to distinguish the types of conformance: <span rel="skos:hasTopConcept" resource="spec:API">API</span>, <span rel="skos:hasTopConcept" resource="spec:NotationSyntax">notation/syntax</span>, <span rel="skos:hasTopConcept" resource="spec:SetOfEvents">set of events</span>, <span rel="skos:hasTopConcept" resource="spec:Protocol">protocol</span>.</p>
                    </div>
                  </section>

                  <section id="classes-of-products" inlist="" rel="schema:hasPart" resource="#classes-of-products" typeof="skos:ConceptScheme"><a class="self-link" href="#classes-of-products"></a>
                    <h4 property="schema:name skos:prefLabel">Classes of Products</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p property="skos:definition">The <span about="" rel="spec:classesOfProducts" resource="#classes-of-products">Solid Notifications Protocol</span> identifies the following <cite><a href="https://www.w3.org/TR/qaframe-spec/#cop-def" rel="dcterms:subject" resource="spec:ClassesOfProducts">Classes of Products</a></cite> for conforming implementations. These products are referenced throughout this specification.</p>

                      <dl rel="skos:hasTopConcept">
                        <dt about="#ResourceServer" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="ResourceServer"><a class="self-link" href="#ResourceServer"></a>Resource Server</dfn></dt>
                        <dd about="#ResourceServer" property="skos:definition">A <em>resource server</em> builds on an HTTP <cite>server</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>] and [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>] by defining media types, HTTP header fields, and the behaviour of resources, as identified by link relations.</dd>
                        <dt about="#DiscoveryClient" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="DiscoveryClient"><a class="self-link" href="#DiscoveryClient"></a>Discovery Client</dfn></dt>
                        <dd about="#DiscoveryClient" property="skos:definition">A <em>Discovery Client</em> that builds on HTTP <cite>client</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>], [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>], and [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] by defining behaviour in terms of fetching across the platform.</dd>
                        <dt about="#SubscriptionClient" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="SubscriptionClient"><a class="self-link" href="#SubscriptionClient"></a>Subscription Client</dfn></dt>
                        <dd about="#SubscriptionClient" property="skos:definition">A <em>Subscription Client</em> that builds on HTTP <cite>client</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>], [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>], and [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] by defining behaviour in terms of fetching across the platform.</dd>
                        <dt about="#SubscriptionServer" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="SubscriptionServer"><a class="self-link" href="#SubscriptionServer"></a>Subscription Server</dfn></dt>
                        <dd about="#SubscriptionServer" property="skos:definition" rel="skos:broadMatch" resource="spec:ProducerOfInstructions">A <em>Subscription Server</em> that builds on HTTP <cite>server</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>] and [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>].</dd>
                        <dt about="#NotificationSender" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="NotificationSender"><a class="self-link" href="#NotificationSender"></a>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"><a class="self-link" href="#NotificationReceiver"></a>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>
                       </dl>
                    </div>
                  </section>

                  <section id="interoperability" inlist="" rel="schema:hasPart" resource="#interoperability" typeof="skos:ConceptScheme"><a class="self-link" href="#interoperability"></a>
                    <h4 property="schema:name skos:prefLabel">Interoperability</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p property="skos:definition">Interoperability occurs between <a href="#discovery-client-resource-server-interoperability" rel="skos:hasTopConcept">Discovery Client–Resource Server</a>, <a href="#subscription-client-subscription-server-interoperability" rel="skos:hasTopConcept">Subscription Client–Subscription Server</a>, or <a href="#notification-sender-notification-receiver-interoperability" rel="skos:hasTopConcept">Notification Sender–Notification Receiver</a>, as defined by the <a href="" rel="foaf:page">Solid Notifications Protocol</a>.</p>

                      <dl>
                        <dt about="#discovery-client-resource-server-interoperability" property="skos:prefLabel" typeof="skos:Concept"><dfn id="discovery-client-resource-server-interoperability"><a class="self-link" href="#discovery-client-resource-server-interoperability"></a>Discovery Client–Resource Server interoperability</dfn></dt>
                        <dd about="#discovery-client-resource-server-interoperability" property="skos:definition">Interoperability of implementations for <a href="#SubscriptionClient" rel="rdfs:seeAlso">Discovery Clients</a> and <a href="#ResourceServer" rel="rdfs:seeAlso">Resource Servers</a> is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to the Solid Notifications Protocol.</dd>
                        <dt about="#subscription-client-subscription-server-interoperability" property="skos:prefLabel" typeof="skos:Concept"><dfn id="subscription-client-subscription-server-interoperability"><a class="self-link" href="#subscription-client-subscription-server-interoperability"></a>Subscription Client–Subscription Server interoperability</dfn></dt>
                        <dd about="#subscription-client-subscription-server-interoperability" property="skos:definition">Interoperability of implementations for <a href="#SubscriptionClient" rel="rdfs:seeAlso">Subscription Clients</a> and <a href="#SubscriptionServer" rel="rdfs:seeAlso">Subscription Servers</a> is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to the Solid Notifications Protocol.</dd>
                        <dt about="#notification-sender-notification-receiver-interoperability" property="skos:prefLabel" typeof="skos:Concept"><dfn id="notification-sender-notification-receiver-interoperability"><a class="self-link" href="#notification-sender-notification-receiver-interoperability"></a>Notification Sender–Notification Receiver interoperability</dfn></dt>
                        <dd about="#notification-sender-notification-receiver-interoperability" property="skos:definition">Interoperability of implementations for <a href="#NotificationSender" rel="rdfs:seeAlso">Notification Sender</a> and <a href="#NotificationReceiver" rel="rdfs:seeAlso">Notification Receiver</a> is tested by evaluating an implementation’s ability to produce and consume content that adheres to the <a href="#notification-message-data-model" rel="rdfs:seeAlso">notification message data model</a> and conforms to a particular <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a>.</dd>
                      </dl>
                    </div>
                  </section>
                </div>
              </section>
            </div>
          </section>

          <section id="protocol" inlist="" rel="schema:hasPart" resource="#protocol"><a class="self-link" href="#protocol"></a>
            <h2 property="schema:name">Protocol</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>The Solid Notifications Protocol specifies a mechanism for discovery of notification capabilities on resources, customisation of notification channels through subscriptions, capabilities of notification channels, and methods for establishing a connection to a notification channel.</p>

              <p>A Resource Server may provide notifications over a notification channel that might be of one of many <a href="#notification-channel-types">notification channel types</a> that build upon existing web protocols.
              Individual <a href="#notification-channel-types">notification channel types</a> may augment the discovery and subscription requirements of the notification protocol.</p>

              <p id="json-ld-format"><a class="self-link" href="#json-ld-format"></a>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"><a class="self-link" href="#authentication-authorization"></a>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>

              <section id="discovery" inlist="" rel="schema:hasPart" resource="#discovery"><a class="self-link" href="#discovery"></a>
                <h3 property="schema:name">Discovery</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p about="#topic-resource" property="skos:definition" typeof="skos:Concept">The starting point for discovery is the resource which the notification is about, hereafter referred as the <strong><dfn id="topic-resource" property="skos:prefLabel"><a class="self-link" href="#topic-resource"></a>topic resource</dfn></strong>. Choosing the most appropriate topic resource from which to begin discovery is at the discretion of the <a href="#DiscoveryClient">Discovery Client</a>, since notifications may be available for any resource for authorized access subjects.</p>

                  <p><a href="#ResourceServer">Resource Servers</a> enable <a href="#DiscoveryClient">Discovery Clients</a> to discover <a href="#description-resource">description resources</a> that are associated with a topic resource.</p>

                  <p about="#description-resource" property="skos:definition" typeof="skos:Concept">A <strong><dfn id="description-resource" property="skos:prefLabel"><a class="self-link" href="#description-resource"></a>description resource</dfn></strong> is an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] that includes information about the capabilities and features of a <cite><a href="#subscription-service-data-model" rel="rdfs:seeAlso">subscription service</a></cite> or <cite><a href="#notification-channel-data-model" rel="rdfs:seeAlso">notification channel</a></cite>.</p>

                  <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>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 public read resource.</li>
                  </ul>

                  <p>Description resources can be discovered as follows:</p>

                  <p about="" id="resource-server-link-resource-description-resource" rel="spec:requirement" resource="#resource-server-link-resource-description-resource"><a class="self-link" href="#resource-server-link-resource-description-resource"></a><span property="spec:statement"><a href="#ResourceServer" rel="spec:requirementSubject">Resource Servers</a> that want to enable <a href="#DiscoveryClient">Discovery Clients</a> to discover subscription services and notification channels available for a given resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise the associated resources describing the <a href="#subscription-service">subscription services</a> and <a href="#notification-channel">notification channels</a> by responding to an HTTP request including a <code>Link</code> header with the <code>rel</code> value of <code>describedby</code> [<cite><a class="bibref" href="#bib-powder-dr">POWDER-DR</a></cite>] and the <a href="#description-resource">description resource</a> as link target [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></p>

                  <p about="" id="resource-server-link-storage-description-resource" rel="spec:requirement" resource="#resource-server-link-storage-description-resource"><a class="self-link" href="#resource-server-link-storage-description-resource"></a><span property="spec:statement"><a href="#ResourceServer" rel="spec:requirementSubject">Resource Servers</a> that want to enable <a href="#DiscoveryClient">Discovery Clients</a> to discover subscription services and notification channels available to a <a href="https://solidproject.org/TR/protocol#storage">storage</a> in which a given <a href="https://solidproject.org/TR/protocol#resource">resource</a> is in <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise the associated resources describing the <a href="#subscription-service">subscription services</a> and <a href="#notification-channel">notification channels</a> by responding to an HTTP request including a <code>Link</code> header with the <code>rel</code> value of <code>http://www.w3.org/ns/solid/terms#storageDescription</code> [<cite><a class="bibref" href="#bib-solid-protocol">SOLID-PROTOCOL</a></cite>] and the <a href="#description-resource">description resource</a> as link target [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></p>

                  <p about="" id="resource-server-description-resource-accept" rel="spec:requirement" resource="#resource-server-description-resource-accept"><a class="self-link" href="#resource-server-description-resource-accept"></a><span property="spec:statement"><a href="#ResourceServer" rel="spec:requirementSubject">Resource Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept requests targeting the <a href="#description-resource">description resource</a> when the value of the <code>Accept</code> header indicates a preferred representation in <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>].</span></p>

                  <p about="" id="resource-server-description-resource-response" rel="spec:requirement" resource="#resource-server-description-resource-response"><a class="self-link" href="#resource-server-description-resource-response"></a><span property="spec:statement"><a href="#ResourceServer" rel="spec:requirementSubject">Resource Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <a href="#description-resource-data-model" rel="rdfs:seeAlso">Description Resource Data Model</a> in the <a href="#description-resource">description resource</a> response content.</span></p>

                  <figure class="example listing" id="description-resource-request-response-jsonld" rel="schema:hasPart" resource="#description-resource-request-response-jsonld">
                    <figcaption property="schema:name"><span>Example</span>: <span>Discovery of description resource.</span></figcaption><a class="self-link" href="#description-resource-request-response-jsonld"></a>

                    <pre property="schema:description"><code>HEAD https://example.org/guinan/profile</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Link: &lt;https://example.org/guinan/profile.description&gt;; rel="describedby"</code>
<code></code>
<code>GET https://example.org/guinan/profile.description</code>
<code>Accept: application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json</code></pre>
                  </figure>
                </div>
              </section>

              <section id="subscription" inlist="" rel="schema:hasPart" resource="#subscription"><a class="self-link" href="#subscription"></a>
                <h3 property="schema:name">Subscription</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The subscriptions mechanism enables <a href="#SubscriptionClient">Subscription Clients</a> to request notifications for changes on a particular resources using a customised notification channel.</p>

                  <p about="#subscription-service" property="skos:definition" typeof="skos:Concept">A <strong><dfn id="subscription-service" property="skos:prefLabel"><a class="self-link" href="#subscription-service"></a>subscription service</dfn></strong> is an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] described with the <a href="#subscription-service-data-model" rel="rdfs:seeAlso">Subscription Service Data Model</a> that can be used by <a href="#SubscriptionClient">Subscription Clients</a> to discover available <a href="#notification-features">features</a> and customize the details of a subscription request.</p>

                  <p about="#subscription-request" property="skos:definition" typeof="skos:Concept">A <strong><dfn id="subscription-request" property="skos:prefLabel"><a class="self-link" href="#subscription-request"></a>subscription request</dfn></strong> is an HTTP request that targets a <a href="#subscription-service">subscription service</a> by a <a href="#SubscriptionClient">Subscription Client</a> requesting to receive notifications about one or more <a href="#topic-resource">topic resources</a>. The content of the subscription request describes the desired <a href="#notification-channel">notification channel</a>.</p>

                  <p about="#subscription-response" property="skos:definition" typeof="skos:Concept">A <strong><dfn id="subscription-response" property="skos:prefLabel"><a class="self-link" href="#subscription-response"></a>subscription response</dfn></strong> is an HTTP response to a <a href="#subscription-request">subscription request</a> by a <a href="#SubscriptionServer">Subscription Server</a>. The content of the subscription response describes the created <a href="#notification-channel">notification channel</a>.</p>

                  <p about="" id="subscription-client-subscription-request" rel="spec:requirement" resource="#subscription-client-subscription-request"><a class="self-link" href="#subscription-client-subscription-request"></a><span property="spec:statement"><a href="#SubscriptionClient" rel="spec:requirementSubject">Subscription Clients</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <a href="#notification-channel-data-model" rel="rdfs:seeAlso">Notification Channel Data Model</a>, and in addition conform to a particular <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a> in the <a href="#subscription-request">subscription request</a> content.</span></p>

                  <p about="" id="subscription-server-subscription-request-methods" rel="spec:requirement" resource="#subscription-server-subscription-request-methods"><a class="self-link" href="#subscription-server-subscription-request-methods"></a><span property="spec:statement"><a href="#SubscriptionServer" rel="spec:requirementSubject">Subscription Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> support the <code>GET</code>, <code>HEAD</code>, <code>OPTIONS</code>, and <code>POST</code> methods [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>] on the <a href="#subscription-service">subscription service</a>.</span></p>

                  <p about="" id="subscription-server-subscription-request-accept" rel="spec:requirement" resource="#subscription-server-subscription-request-accept"><a class="self-link" href="#subscription-server-subscription-request-accept"></a><span property="spec:statement"><a href="#SubscriptionServer" rel="spec:requirementSubject">Subscription Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept requests on the <a href="#subscription-service">subscription service</a> when the value of the <code>Accept</code> header indicates a preferred representation in <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>].</span></p>

                  <p about="" id="subscription-server-subscription-request-content-type" rel="spec:requirement" resource="#subscription-server-subscription-request-content-type"><a class="self-link" href="#subscription-server-subscription-request-content-type"></a><span property="spec:statement"><a href="#SubscriptionServer" rel="spec:requirementSubject">Subscription Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept requests on the <a href="#subscription-service">subscription service</a> when the value of the <code>Content-Type</code> header indicates the content's media type in <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>].</span></p>

                  <p about="" id="subscription-server-subscription-request-profile-unrecognised" rel="spec:requirement" resource="#subscription-server-subscription-request-profile-unrecognised"><a class="self-link" href="#subscription-server-subscription-request-profile-unrecognised"></a><span property="spec:statement"><a href="#SubscriptionServer" rel="spec:requirementSubject">Subscription Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>415</code> status code for HTTP requests with unsupported values in the <code>profile</code> parameter.</span></p>

                  <p about="" id="subscription-server-subscription-request-unprocessable-entity" rel="spec:requirement" resource="#subscription-server-subscription-request-unprocessable-entity"><a class="self-link" href="#subscription-server-subscription-request-unprocessable-entity"></a><span property="spec:statement"><a href="#SubscriptionServer" rel="spec:requirementSubject">Subscription Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>422</code> status code [<cite><a class="bibref" href="#bib-rfc4918">RFC4918</a></cite>] when unable to process the contained instructions, including unrecognised JSON-LD context in representation data.</span></p>

                  <p about="" id="subscription-server-subscription-response" rel="spec:requirement" resource="#subscription-server-subscription-response"><a class="self-link" href="#subscription-server-subscription-response"></a><span property="spec:statement"><a href="#SubscriptionServer" rel="spec:requirementSubject">Subscription Servers</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <a href="#notification-channel-data-model" rel="rdfs:seeAlso">Notification Channel Data Model</a>, and in addition conform to a particular <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a> in the <a href="#subscription-response">subscription response</a> content.</span></p>

                  <figure class="example listing" id="subscription-service-request-response-jsonld" rel="schema:hasPart" resource="#subscription-service-request-response-jsonld">
                    <figcaption property="schema:name"><span>Example</span>: <span>Subscription request and response.</span></figcaption><a class="self-link" href="#subscription-service-request-response-jsonld"></a>

                    <pre property="schema:description"><code>GET https://websocket.example/subscription</code>
<code>Accept: application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json</code>
<code></code>
<code>POST https://websocket.example/subscription</code>
<code>Accept: application/ld+json</code>
<code>Content-Type: application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json</code></pre>
                  </figure>
                </div>
              </section>

              <section id="notification-channel" inlist="" rel="schema:hasPart" resource="#notification-channel"><a class="self-link" href="#notification-channel"></a>
                <h3 property="schema:name">Notification Channel</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p about="#notification-channel" property="skos:definition" typeof="skos:Concept">A <strong><dfn property="skos:prefLabel">notification channel</dfn></strong> is a resource whose properties describe the immediately available notification interface with a specific <a href="#notification-channel-types">notification channel type</a> and established <a href="#notification-features">features</a> following the <a href="#notification-channel-data-model" rel="rdfs:seeAlso">Notification Channel Data Model</a>.</p>

                  <p about="" id="notification-sender-notification-message-data-model" rel="spec:requirement" resource="#notification-sender-notification-message-data-model"><a class="self-link" href="#notification-sender-notification-message-data-model"></a><span property="spec:statement"><a href="#NotificationSender" rel="spec:requirementSubject">Notification Sender</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be able to produce message content using the <a href="#notification-message-data-model" rel="rdfs:seeAlso">Notification Message Data Model</a>, in addition to conforming to a particular <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a>.</span></p>

                  <p about="" id="notification-receiver-notification-message-data-model" rel="spec:requirement" resource="#notification-receiver-notification-message-data-model"><a class="self-link" href="#notification-receiver-notification-message-data-model"></a><span property="spec:statement"><a href="#NotificationReceiver" rel="spec:requirementSubject">Notification Receiver</a> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be able to process message content using the <a href="#notification-message-data-model" rel="rdfs:seeAlso">Notification Message Data Model</a>, in addition to conforming to a particular <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a>.</span></p>

                  <section id="notification-channel-types" inlist="" rel="schema:hasPart" resource="#notification-channel-types"><a class="self-link" href="#notification-channel-types"></a>
                    <h4 property="schema:name">Notification Channel Types</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>A notification channel type is a specific communication protocol that governs how classes of products can establish a connection to send and receive messages. A notification channel type is identified by a IRI used to both <a href="#discovery">discover</a> and establish the <a href="#notification-channel">notification channels</a>. A notification channel type can also require additional data formats or extend the core data models.</p>

                      <div class="note" id="notification-channel-type-registry" inlist="" rel="schema:hasPart" resource="#notification-channel-type-registry"><a class="self-link" href="#notification-channel-type-registry"></a>
                        <h5 property="schema:name"><span>Note</span>: Notification Channel Type Registry</h5>
                        <div datatype="rdf:HTML" property="schema:description">
                          <p>Notification channel types are defined and published independently of this document. In order to help with the discovery of notification channel types that can be used with this specification, it is encouraged to register them in the <cite><a href="https://solidproject.org/TR/">Solid Technical Reports</a></cite> [<cite><a class="bibref" href="bib-solid-technical-reports">SOLID-TECHNICAL-REPORTS</a></cite>] for maximum global interoperability. New notification channel types, along with changes to existing entries, can be requested by following the registry definition in Solid Technical Reports.</p>

                          <p>When defining IRIs for use with a notification channel type, it is considered best practice to publish the vocabulary and the JSON-LD context as publicly accessible documents.</p>

                          <p>Extensions incorporate additional features beyond what is defined in this specification. Extensions are strongly encouraged to not contradict nor cause the non-conformance of functionality defined in this specification.</p>
                        </div>
                      </div>
                    </div>
                  </section>

                  <section id="notification-features" inlist="" rel="schema:hasPart" resource="#notification-features" typeof="skos:Collection"><a class="self-link" href="#notification-features"></a>
                    <h4 property="schema:name skos:prefLabel">Features</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p property="skos:definition">Features describe custom properties of a notification channel. Description Resources may advertise a list of features that the <a href="#SubscriptionServer">Subscription Server</a> can modify. <a href="#SubscriptionClient">Subscription Clients</a> can modify these features to customise the details of a requested notification channel. Subscription clients can discover available features in a <a href="#subscription-service">subscription service</a>.</p>

                      <p>Some features are specific to a particular notification channel type while others may be used across all types. These shared features are listed as an initial baseline, though not all notification channel types are required to implement these. Individual notification channel types may define type-specific features. The list of common, shared features is not intended to be exhaustive.</p>

                      <dl>
                        <dt id="notify-startAt" rel="dcterms:subject skos:member" resource="http://www.w3.org/ns/solid/notifications#startAt"><a class="self-link" href="#notify-startAt"></a>startAt</dt>
                        <dd>The proposed or actual starting date and time of a notification channel with value represented in the <code>xsd:dateTime</code> datatype.</dd>
                        <dt id="notify-endAt" rel="dcterms:subject skos:member" resource="http://www.w3.org/ns/solid/notifications#endAt"><a class="self-link" href="#notify-endAt"></a>endAt</dt>
                        <dd>The proposed or actual ending date and time of a notification channel with value represented in the <code>xsd:dateTime</code> datatype.</dd>
                        <dt id="notify-state" rel="dcterms:subject skos:member" resource="http://www.w3.org/ns/solid/notifications#state"><a class="self-link" href="#notify-state"></a>state</dt>
                        <dd>The last known state of a topic resource with value represented in the <code>xsd:string</code> datatype.</dd>
                        <dt id="notify-rate" rel="dcterms:subject skos:member" resource="http://www.w3.org/ns/solid/notifications#rate"><a class="self-link" href="#notify-rate"></a>rate</dt>
                        <dd>The minimum amount of time to elapse between notifications sent to receiver with value represented in the <code>xsd:duration</code> datatype.</dd>
                        <dt id="notify-accept" rel="dcterms:subject skos:member" resource="http://www.w3.org/ns/solid/notifications#accept"><a class="self-link" href="#notify-accept"></a>accept</dt>
                        <dd>The media types that are acceptable by the recipient of a notification with value corresponding to the HTTP <code>Accept</code> header value [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</dd>
                      </dl>
                    </div>
                  </section>
                </div>
              </section>

              <section id="notification-message" inlist="" rel="schema:hasPart" resource="#notification-message"><a class="self-link" href="#notification-message"></a>
                <h3 property="schema:name">Notification Message</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>A <a href="#NotificationSender">Notification Sender</a> is triggered by a process to deliver notifications about one or more <a href="#topic-resource">topic resources</a> to a <a href="#NotificationReceiver">Notification Receiver</a>.</p>

                  <p><a href="#NotificationSender">Notification Senders</a> can augment the <a href="https://www.w3.org/TR/json-ld11/#the-context">JSON-LD Context</a> definition and extend the content of notifications. See for <a href="https://www.w3.org/TR/activitystreams-core/#example-using-multiple-vocabularies">example using multiple vocabularies</a>.</p>

                  <p><a href="#NotificationReceiver">Notification Receivers</a> are encouraged to be aware that anything can be included in the notification message (depending on restrictions in place by the receiver, which are not defined by this specification but may be by a <a href="#notification-channel-types">notification channel type</a>), so when it comes to making use of notification data, receivers may want to take precautions when ascertaining the veracity of the contents.</p>
                </div>
              </section>
            </div>
          </section>

          <section id="data-model" inlist="" rel="schema:hasPart" resource="#data-model"><a class="self-link" href="#data-model"></a>
            <h2 property="schema:name">Data Model</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>This section specifies the data models for <a href="#description-resource-data-model">description resource</a>, <a href="#subscription-service-data-model">subscription service</a>, <a href="#notification-channel-data-model">notification channel</a>, and <a href="#notification-message-data-model">notification message</a>.</p>

              <section id="description-resource-data-model" inlist="" rel="schema:hasPart" resource="#description-resource-data-model"><a class="self-link" href="#description-resource-data-model"></a>
                <h3 content="Description Resource Data Model" property="schema:name">Description Resource</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The <a href="#description-resource">description resource</a> has the following properties:</p>

                  <ul>
                    <li id="notify-resource-id"><a class="self-link" href="#notify-resource-id"></a>One <code>id</code> property to identify the description resource.</li>
                    <li id="notify-subscription"><a class="self-link" href="#notify-subscription"></a>Zero, one, or many <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#subscription">subscription</code> properties to identify the available <a href="#subscription-service">subscription services</a>.</li>
                    <li id="notify-channel"><a class="self-link" href="#notify-channel"></a>Zero, one, or many <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#channel">channel</code> properties to identify the available <a href="#notification-channel">notification channels</a>.</li>
                  </ul>

                  <figure class="example listing" id="description-resource-jsonld" rel="schema:hasPart" resource="#description-resource-jsonld">
                    <figcaption property="schema:name"><span>Example</span>: Representation of a description resource.</figcaption><a class="self-link" href="#description-resource-jsonld"></a>

                    <pre datatype="rdf:JSON" property="schema:description"><code>{</code>
<code>  "@context": [</code>
<code>    "https://www.w3.org/ns/solid/notifications-context/v1"</code>
<code>  ],</code>
<code>  "id": "https://example.org/guinan/profile",</code>
<code>  "subscription": [{</code>
<code>    "id": "https://websocket.example/subscription",</code>
<code>    "channelType": "WebSocketChannel2023",</code>
<code>    "feature": ["endAt", "rate", "state"]</code>
<code>  }],</code>
<code>  "channel": [{</code>
<code>    "id": "https://channel.example/guinan/profile",</code>
<code>    "type": "WebSocketChannel2023",</code>
<code>    "topic": "https://example.org/guinan/profile",</code>
<code>    "receiveFrom": "wss://websocket.example/guinan/profile",</code>
<code>    "rate": "PT1M"</code>
<code>  }]</code>
<code>}</code></pre>
                  </figure>
                </div>
              </section>

              <section id="subscription-service-data-model" inlist="" rel="schema:hasPart" resource="#subscription-service-data-model"><a class="self-link" href="#subscription-service-data-model"></a>
                <h3 content="Subscription Service Data Model" property="schema:name">Subscription Service</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The <a href="#subscription-service">subscription service</a> has the following properties:</p>

                  <ul>
                    <li id="notify-subscription-id"><a class="self-link" href="#notify-subscription-id"></a>One <code>id</code> property to identify the subscription service.</li>
                    <li id="notify-channelType"><a class="self-link" href="#notify-channelType"></a>One <code>channelType</code> property to state the <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a>.</li>
                    <li id="notify-feature"><a class="self-link" href="#notify-feature"></a>Zero, one, or many <code>feature</code> properties to state the supported <a href="#notification-features" rel="rdfs:seeAlso">features</a>.</li>
                  </ul>

                  <figure class="example listing" id="subscription-service-jsonld" rel="schema:hasPart" resource="#subscription-service-jsonld">
                    <figcaption property="schema:name"><span>Example</span>: Representation of a subscription service.</figcaption><a class="self-link" href="#subscription-service-jsonld"></a>

                    <pre datatype="rdf:JSON" property="schema:description"><code>{</code>
<code>  "@context": [</code>
<code>    "https://www.w3.org/ns/solid/notifications-context/v1"</code>
<code>  ],</code>
<code>  "id": "https://websocket.example/subscription",</code>
<code>  "channelType": "WebSocketChannel2023",</code>
<code>  "feature": ["endAt", "rate", "state"]</code>
<code>}</code></pre>
                  </figure>
                </div>
              </section>

              <section id="notification-channel-data-model" inlist="" rel="schema:hasPart" resource="#notification-channel-data-model"><a class="self-link" href="#notification-channel-data-model"></a>
                <h3 content="Notification Channel Data Model" property="schema:name">Notification Channel</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The <a href="#notification-channel">notification channel</a> has the following properties:</p>

                  <ul>
                    <li id="notify-channel-id"><a class="self-link" href="#notify-channel-id"></a>One <code>id</code> property to identify the notification channel.</li>
                    <li id="notify-channel-type"><a class="self-link" href="#notify-channel-type"></a>One <code>type</code> property to state the <a href="#notification-channel-types" rel="rdfs:seeAlso">notification channel type</a>.</li>
                    <li id="notify-topic"><a class="self-link" href="#notify-topic"></a>At least one <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#topic">topic</code> property to identify the resource that the notifications are about.</li>
                    <li id="notify-feature-types"><a class="self-link" href="#notify-feature-types"></a>Zero, one, or many properties stating a particular <a href="#notification-features" rel="rdfs:seeAlso">feature</a>.</li>
                  </ul>

                  <p>Where a <a href="#NotificationReceiver">Notification Receiver</a> establishes the connection, the <a href="#notification-channel">notification channel</a> has the following additional property:</p>

                  <ul>
                    <li id="notify-receiveFrom"><a class="self-link" href="#notify-receiveFrom"></a>One <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#receiveFrom">receiveFrom</code> property to identify the resource on the <a href="#NotificationSender">Notification Sender</a> that can be used to establish a connection to receive notifications.</li>
                  </ul>

                  <p>Where a <a href="#NotificationSender">Notification Sender</a> pushes notifications, the <a href="#notification-channel">notification channel</a> in the <a href="#subscription-request">subscription request</a> has the following additional property:</p>

                  <ul>
                    <li id="notify-sendTo"><a class="self-link" href="#notify-sendTo"></a>Zero or one <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#sendTo">sendTo</code> property to identify the resource where the <a href="#NotificationReciever">Notification Receiver</a> can accept notifications.</li>
                  </ul>

                  <p>Where a <a href="#NotificationSender">Notification Sender</a> pushes notifications, the <a href="#notification-channel">notification channel</a> in the <a href="#subscription-response">subscription response</a> has the following additional properties:</p>

                  <ul>
                    <li id="notify-sender"><a class="self-link" href="#notify-sender"></a>Zero or one <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#sender">sender</code> property to identify the <a href="#NotificationSender">Notification Sender</a></li>
                  </ul>

                  <figure class="example listing" id="notification-channel-jsonld" rel="schema:hasPart" resource="#notification-channel-jsonld">
                    <figcaption property="schema:name"><span>Example</span>: <span>Representation of a notification channel.</span></figcaption><a class="self-link" href="#notification-channel-jsonld"></a>

                    <pre datatype="rdf:JSON" property="schema:description"><code>{</code>
<code>  "@context": [</code>
<code>    "https://www.w3.org/ns/solid/notifications-context/v1"</code>
<code>  ],</code>
<code>  "id": "https://channel.example/ac748712",</code>
<code>  "type": "WebSocketChannel2023",</code>
<code>  "topic": "https://example.org/guinan/profile",</code>
<code>  "receiveFrom": "wss://websocket.example/d4cf3f19",</code>
<code>  "startAt": "2023-01-01T07:00:00.000Z",</code>
<code>  "endAt": "2023-01-01T09:00:00.000Z",</code>
<code>  "rate": "PT5M",</code>
<code>  "state": "e75-TFJH"</code>
<code>}</code></pre>
                  </figure>
                </div>
              </section>

              <section id="notification-message-data-model" inlist="" rel="schema:hasPart" resource="#notification-message-data-model"><a class="self-link" href="#notification-message-data-model"></a>
                <h3 content="Notification Message Data Model" property="schema:name">Notification Message</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The core notification data is expressed with the <cite><a href="https://www.w3.org/TR/activitystreams-vocabulary/">Activity Streams</a></cite> [<cite><a class="bibref" href="#bib-activitystreams-vocabulary">ACTIVITYSTREAMS-VOCABULARY</a></cite>] and <cite><a href="http://www.w3.org/ns/solid/notifications">Solid Notifications</a></cite> vocabularies.</p>

                  <p>A notification has the following properties:</p>

                  <ul>
                    <li id="message-id"><a class="self-link" href="#message-id"></a>One <code rel="dcterms:subject" resource="https://www.w3.org/TR/activitystreams-vocabulary/#dfn-id">id</code> property to identify the notification.</li>
                    <li id="message-type"><a class="self-link" href="#message-type"></a>At least one <code rel="dcterms:subject" resource="https://www.w3.org/ns/activitystreams#Activity">type</code> property indicating a specific type of activity (<cite><a href="https://www.w3.org/TR/activitystreams-vocabulary/#activity-types" rel="rdfs:seeAlso">Activity Types</a></cite>).</li>
                    <li id="message-object"><a class="self-link" href="#message-object"></a>One <code rel="dcterms:subject" resource="https://www.w3.org/ns/activitystreams#object">object</code> property to identify the (<cite><a href="#topic-resource">topic</a></cite>) resource that the notification is about.</li>
                    <li id="message-published"><a class="self-link" href="#message-published"></a>One <code rel="dcterms:subject" resource="https://www.w3.org/ns/activitystreams#published">published</code> property to indicate the date and time of the notification.</li>
                    <li id="message-target"><a class="self-link" href="#message-target"></a>Zero, one, or many <code rel="dcterms:subject" resource="https://www.w3.org/ns/activitystreams#target">target</code> properties to identify the resource to which the activity is directed.</li>
                    <li id="message-state"><a class="self-link" href="#message-state"></a>Zero or one <code rel="dcterms:subject" resource="http://www.w3.org/ns/solid/notifications#state">state</code> property to indicate the last known state of the resource.</li>
                  </ul>

                  <figure class="example listing" id="notification-update" rel="schema:hasPart" resource="#notification-update">
                    <figcaption property="schema:name"><span>Example</span>: <span>An update activity</span></figcaption><a class="self-link" href="#notification-update"></a>

                    <pre datatype="rdf:JSON" property="schema:description"><code>{</code>
<code>  "@context": [</code>
<code>    "https://www.w3.org/ns/activitystreams",</code>
<code>    "https://www.w3.org/ns/solid/notifications-context/v1"</code>
<code>  ],</code>
<code>  "id": "urn:uuid:fc8b5af4-bd7e-4fd1-a649-afcbd0e1c083",</code>
<code>  "type": "Update",</code>
<code>  "object": "https://example.org/guinan/profile",</code>
<code>  "state": "128f-MtYev",</code>
<code>  "published": "2021-08-05T01:01:49.550Z"</code>
<code>}</code></pre>
                  </figure>

                  <figure class="example listing" id="notification-add" rel="schema:hasPart" resource="#notification-add">
                    <figcaption property="schema:name"><span>Example</span>: <span>An add activity</span></figcaption><a class="self-link" href="#notification-add"></a>

                    <pre  datatype="rdf:JSON" property="schema:description"><code>{</code>
<code>  "@context": [</code>
<code>    "https://www.w3.org/ns/activitystreams",</code>
<code>    "https://www.w3.org/ns/solid/notifications-context/v1"</code>
<code>  ],</code>
<code>  "id": "urn:uuid:a4da6738-6be0-11ed-90bd-1be4ba6b6b33",</code>
<code>  "type": "Add",</code>
<code>  "object": "https://example.org/guinan/photos/image",</code>
<code>  "target": "https://example.org/guinan/photos/",</code>
<code>  "published": "2022-11-24T11:55:31.483Z"</code>
<code>}</code></pre>
                  </figure>
                </div>
              </section>
            </div>
          </section>

          <section id="considerations" inlist="" rel="schema:hasPart" resource="#considerations" typeof="spec:Considerations"><a class="self-link" href="#considerations"></a>
            <h2 property="schema:name">Considerations</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>This section details security and privacy considerations.</p>

              <p>Some of the normative references with this specification point to documents with a <em>Living Standard</em> or <em>Draft</em> status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have implications.</p>

              <section id="security-considerations" inlist="" rel="schema:hasPart" resource="#security-considerations" typeof="spec:SecurityConsiderations"><a class="self-link" href="#security-considerations"></a>
                <h3 property="schema:name">Security Considerations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p id="consider-exposing-information"><a class="self-link" href="#consider-exposing-information"></a>Subscription Servers and Notification Senders are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature. Subscription Clients are strongly discouraged from exposing information beyond the minimum amount necessary to subscribe to updates about particular resources.</p>

                  <p id="consider-subscription-service-trust"><a class="self-link" href="#consider-subscription-service-trust"></a>Subscription Clients are discouraged from sending subscription requests to untrusted subscription services, including localhost or any other loopback IP address, in order to avoid making arbitrary requests.</p>
                </div>
              </section>

              <section id="privacy-considerations" inlist="" rel="schema:hasPart" resource="#privacy-considerations" typeof="spec:PrivacyConsiderations"><a class="self-link" href="#privacy-considerations"></a>
                <h3 property="schema:name">Privacy Considerations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>
                </div>
              </section>

              <section id="security-privacy-review" inlist="" rel="schema:hasPart" resource="#security-privacy-review" typeof="spec:SelfReviewQuestionnaireSecurityPrivacy"><a class="self-link" href="#security-privacy-review"></a>
                <h3 property="schema:name">Security and Privacy Review</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p>These questions provide an overview of security and privacy considerations for this specification as guided by [<cite><a class="bibref" href="#bib-security-privacy-questionnaire">SECURITY-PRIVACY-QUESTIONNAIRE</a></cite>].</p>

                  <dl rel="schema:hasPart">
                    <dt about="#security-privacy-review-purpose" id="security-privacy-review-purpose"><a class="self-link" href="#security-privacy-review-purpose"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#purpose" rel="cito:repliesTo">What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?</a></dt>
                    <dd about="#security-privacy-review-purpose" datatype="rdf:HTML" property="schema:description">There are no known security impacts of the features in this specification.</dd>

                    <dt about="#security-privacy-review-minimum-data" id="security-privacy-review-minimum-data"><a class="self-link" href="#security-privacy-review-minimum-data"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#minimum-data" rel="cito:repliesTo">Do features in your specification expose the minimum amount of information necessary to enable their intended uses?</a></dt>
                    <dd about="#security-privacy-review-minimum-data" datatype="rdf:HTML" property="schema:description">Yes.</dd>

                    <dt about="#security-privacy-review-personal-data" id="security-privacy-review-personal-data"><a class="self-link" href="#security-privacy-review-personal-data"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#personal-data" rel="cito:repliesTo">How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?</a></dt>
                    <dd about="#security-privacy-review-personal-data" datatype="rdf:HTML" property="schema:description">Access to <cite><a href="#subscription-service" rel="cito:discusses">subscription service</a></cite> and <cite><a href="#notification-message-data-model" rel="cito:discusses">notification message</a></cite> are only granted to authorized access subjects. The <cite><a href="#subscription-request" rel="cito:discusses">subscription request</a></cite>, <cite><a href="#subscription-response" rel="cito:discusses">subscription response</a></cite>, and notification message content can contain any data (including that which identifies or refers to agents that control the <cite> <a href="#SubscriptionClient" rel="cito:discusses">Subscription Client</a></cite> and <cite><a href="#NotificationSender" rel="cito:discusses">Notification Sender</a></cite>.) <cite><a href="https://w3ctag.github.io/design-principles/#consent" rel="cito:obtainsBackgroundFrom">Meaningful consent</a></cite> to any personal data that Subscription Clients include about agents associated with themselves or <cite><a href="#topic-resource">topic resources</a></cite> of interest are extended to the <cite><a href="#NotificationReceiver" rel="cito:discusses">Notification Receiver</a></cite>. Subscription Clients, <cite> <a href="#SubscriptionServer" rel="cito:discusses">Subscription Server</a></cite>, and <cite><a href="#NotificationSender" rel="cito:discusses">Notification Senders</a></cite> are discouraged from exposing information beyond the amount necessary to enable or use a feature.</dd>

                    <dt about="#security-privacy-review-sensitive-data" id="security-privacy-review-sensitive-data"><a class="self-link" href="#security-privacy-review-sensitive-data"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#sensitive-data" rel="cito:repliesTo">How do the features in your specification deal with sensitive information?</a></dt>
                    <dd about="#security-privacy-review-sensitive-data" datatype="rdf:HTML" property="schema:description">The features do not require sensitive information to obtained or exposed.</dd>

                    <dt about="#security-privacy-review-persistent-origin-specific-state" id="security-privacy-review-persistent-origin-specific-state"><a class="self-link" href="#security-privacy-review-persistent-origin-specific-state"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#persistent-origin-specific-state" rel="cito:repliesTo">Do the features in your specification introduce new state for an origin that persists across browsing sessions?</a></dt>
                    <dd about="#security-privacy-review-persistent-origin-specific-state" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-underlying-platform-data" id="security-privacy-review-underlying-platform-data"><a class="self-link" href="#security-privacy-review-underlying-platform-data"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#underlying-platform-data" rel="cito:repliesTo">Do the features in your specification expose information about the underlying platform to origins?</a></dt>
                    <dd about="#security-privacy-review-underlying-platform-data" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-send-to-platform" id="security-privacy-review-send-to-platform"><a class="self-link" href="#security-privacy-review-send-to-platform"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#send-to-platform" rel="cito:repliesTo">Does this specification allow an origin to send data to the underlying platform?</a></dt>
                    <dd about="#security-privacy-review-send-to-platform" datatype="rdf:HTML" property="schema:description">No. <cite><a href="#description-resource" rel="cito:discusses">Description resources</a></cite> and <cite><a href="#subscription-service" rel="cito:discusses">subscription services</a></cite> are described within the framework of HTTP as RDF documents <cite><a href="#json-ld-format" rel="cito:discusses">represented with the JSON-LD syntax</a></cite>. <cite><a href="#subscription-server" rel="cito:discusses">Subscription Servers</a></cite> and <cite><a href="#NotificationReceiver" rel="cito:discusses">Notification Receivers</a></cite> might be able to redirect to other resources, (e.g., the <code>https:</code> URLs to <code>file:</code>, <code>data:</code>, or <code>blob:</code> URLs), but no such behaviour is defined by this specification.</dd>

                    <dt about="#security-privacy-review-sensor-data" id="security-privacy-review-sensor-data"><a class="self-link" href="#security-privacy-review-sensor-data"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#sensor-data" rel="cito:repliesTo">Do features in this specification allow an origin access to sensors on a user’s device</a></dt>
                    <dd about="#security-privacy-review-sensor-data" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-other-data" id="security-privacy-review-other-data"><a class="self-link" href="#security-privacy-review-other-data"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#other-data" rel="cito:repliesTo">What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.</a></dt>
                    <dd about="#security-privacy-review-other-data" datatype="rdf:HTML" property="schema:description">No detail about another origin’s state is exposed. As the association between a resource and its description resource is at the discretion of the resource server, they can be on different <cite><a href="https://datatracker.ietf.org/doc/html/rfc6454#section-2.3" rel="cito:citesAsAuthority">origins</a></cite> [<cite><a class="bibref" href="#bib-RFC6454">RFC6454</a></cite>]. Similarly, the origins of subscription service and the notification channel might also be different. When subscription servers, servers hosting the notification channel, and servers allowing connections to receive notifications participate in the <cite><a href="https://fetch.spec.whatwg.org/#cors-protocol" rel="cito:citesAsAuthority">CORS protocol</a></cite> [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>], HTTP requests from different origins may be allowed. This feature does not add any new attack surface above and beyond normal <cite><a href="https://fetch.spec.whatwg.org/#cors-request" rel="cito:citesAsAuthority">CORS requests</a></cite>, so no extra mitigation is deemed necessary.</dd>

                    <dt about="#security-privacy-review-string-to-script" id="security-privacy-review-string-to-script"><a class="self-link" href="#security-privacy-review-string-to-script"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#string-to-script" rel="cito:repliesTo">Do features in this specification enable new script execution/loading mechanisms?</a></dt>
                    <dd about="#security-privacy-review-string-to-script" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-remote-device" id="security-privacy-review-remote-device"><a class="self-link" href="#security-privacy-review-remote-device"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#remote-device" rel="cito:repliesTo">Do features in this specification allow an origin to access other devices?</a></dt>
                    <dd about="#security-privacy-review-remote-device" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-native-ui" id="security-privacy-review-native-ui"><a class="self-link" href="#security-privacy-review-native-ui"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#native-ui" rel="cito:repliesTo">Do features in this specification allow an origin some measure of control over a user agent’s native UI?</a></dt>
                    <dd about="#security-privacy-review-native-ui" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-temporary-id" id="security-privacy-review-temporary-id"><a class="self-link" href="#security-privacy-review-temporary-id"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#temporary-id" rel="cito:repliesTo">What temporary identifiers do the features in this specification create or expose to the web?</a></dt>
                    <dd about="#security-privacy-review-temporary-id" datatype="rdf:HTML" property="schema:description">The <cite><a href="#subscription-response" rel="cito:discusses">subscription response</a></cite> content can contain a capability URL to protect the notification channel which is only exposed to authorized <cite><a href="#SubscriptionClient" rel="cito:discusses">Subscription Clients</a></cite>.</dd>

                    <dt about="#security-privacy-review-first-third-party" id="security-privacy-review-first-third-party"><a class="self-link" href="#security-privacy-review-first-third-party"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#first-third-party" rel="cito:repliesTo">How does this specification distinguish between behaviour in first-party and third-party contexts?</a></dt>
                    <dd about="#security-privacy-review-first-third-party" datatype="rdf:HTML" property="schema:description">Not Applicable.</dd>

                    <dt about="#security-privacy-review-private-browsing" id="security-privacy-review-private-browsing"><a class="self-link" href="#security-privacy-review-private-browsing"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#private-browsing" rel="cito:repliesTo">How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?</a></dt>
                    <dd about="#security-privacy-review-private-browsing" datatype="rdf:HTML" property="schema:description">No different than in the <q cite="https://www.w3.org/TR/security-privacy-questionnaire/#private-browsing">browser’s 'normal' state</q>.</dd>

                    <dt about="#security-privacy-review-considerations" id="security-privacy-review-considerations"><a class="self-link" href="#security-privacy-review-considerations"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#considerations" rel="cito:repliesTo">Does this specification have both "Security Considerations" and "Privacy Considerations" sections?</a></dt>
                    <dd about="#security-privacy-review-considerations" datatype="rdf:HTML" property="schema:description">Yes, in <cite><a href="#security-considerations" rel="rdfs:seeAlso">Security Considerations</a></cite> and <cite><a href="#privacy-considerations" rel="rdfs:seeAlso">Privacy Considerations</a></cite>.</dd>

                    <dt about="#security-privacy-review-relaxed-sop" id="security-privacy-review-relaxed-sop"><a class="self-link" href="#security-privacy-review-relaxed-sop"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#relaxed-sop" rel="cito:repliesTo">Do features in your specification enable origins to downgrade default security protections?</a></dt>
                    <dd about="#security-privacy-review-relaxed-sop" datatype="rdf:HTML" property="schema:description">No.</dd>

                    <dt about="#security-privacy-review-non-fully-active" id="security-privacy-review-non-fully-active"><a class="self-link" href="#security-privacy-review-non-fully-active"></a><a href="https://www.w3.org/TR/security-privacy-questionnaire/#non-fully-active" rel="cito:repliesTo">How does your feature handle non-"fully active" documents?</a></dt>
                    <dd about="#security-privacy-review-non-fully-active" datatype="rdf:HTML" property="schema:description">Not Applicable.</dd>
                  </dl>
                </div>
              </section>
            </div>
          </section>

          <section class="appendix" id="changelog" inlist="" rel="schema:hasPart" resource="#changelog" typeof="spec:Changelog"><a class="self-link" href="#changelog"></a>
            <h2 property="schema:name">Changelog</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><em>This section is non-normative.</em></p>

              <p>This document is based on <a href="https://solidproject.org/TR/2022/notifications-protocol-20221231">Solid Notifications Protocol, Version 0.2.0</a>. A <a href="https://github.com/solid/notifications/issues?q=milestone%3A%220.3%22+is%3Aclosed">list of issues addressed</a>, a <a href="https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fsolidproject.org%2FTR%2F2022%2Fnotifications-protocol-20221231&amp;doc2=https%3A%2F%2Fsolidproject.org%2FTR%2F2024%2Fnotifications-protocol-20240512">diff from Solid Notifications Protocol, Version 0.2.0 to this latest version</a>, as well as a <a href="https://github.com/solid/notifications/commits/main/protocol.html">detailed log of changes</a> are available.</p>

              <p>The following summary of <em>editorial</em>, <em>substantive</em>, and <em>registry</em> <span about="" rel="spec:changelog" resource="#changelog">changes</span> are classified using the <cite>W3C Process Document</cite> <cite><a href="https://www.w3.org/policies/process/#correction-classes">Classes of Changes</a></cite> [<cite><a class="bibref" href="#bib-w3c-process">W3C-PROCESS</a></cite>]:</p>

              <a class="self-link" href="#changes-since-notifications-protocol-20221231"></a><table id="changes-since-notifications-protocol-20221231">
                <caption>Changes since <a href="https://solidproject.org/TR/2022/notifications-protocol-20221231">Solid Notifications Protocol, Version 0.2.0</a></caption>
                <thead>
                  <tr>
                    <th>Change Class</th>
                    <th>Subject</th>
                    <th>Description</th>
                  </tr>
                </thead>
                <tbody about="#changelog" rel="spec:change">
                  <tr about="#fab8a00e-e633-4947-90ba-df6f0e4ecc7d" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-1" rel="spec:changeClass">1</a></td>
                    <td><a href="" rel="spec:changeSubject">Document</a></td>
                    <td property="spec:statement">Amend broken links, style sheets, or invalid markup.</td>
                  </tr>
                  <tr about="#d7f80478-0b63-4eee-a61c-59e8e659542e" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-2" rel="spec:changeClass">2</a></td>
                    <td><a href="" rel="spec:changeSubject">Document</a></td>
                    <td property="spec:statement">Amend language and document details.</td>
                  </tr>
                  <tr about="#b17c2adb-8946-42ba-8e92-2beb8557459a" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
                    <td><a href="#DiscoveryClient" rel="spec:changeSubject">#DiscoveryClient</a></td>
                    <td property="spec:statement">Add <a href="#DiscoveryClient">DiscoveryClient</a> as a new <a href="#classes-of-products">product class</a>.</td>
                  </tr>
                  <tr about="#bc9d1ee1-dcb7-403c-abbd-35ee1c732189" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-3" rel="spec:changeClass">3</a></td>
                    <td><a href="#discovery-client-resource-server-interoperability" rel="spec:changeSubject">#discovery-client-resource-server-interoperability</a></td>
                    <td property="spec:statement">Replace <em>Subscription Client–Resource Server interoperability</em> with <a href="#discovery-client-resource-server-interoperability">Discovery Client–Resource Server interoperability</a>.</td>
                  </tr>
                  <tr about="#a5a91f3d-856c-43dd-a34a-1ec32e835063" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-3" rel="spec:changeClass">3</a></td>
                    <td><a href="#discovery" rel="spec:changeSubject">#discovery</a></td>
                    <td property="spec:statement">Update <a href="#discovery">discovery</a> description.</td>
                  </tr>
                  <tr about="#af3070d4-80fd-4da7-bb5d-9bab9f8b5980" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-3" rel="spec:changeClass">3</a></td>
                    <td><a href="#resource-server-link-resource-description-resource" rel="spec:changeSubject">#resource-server-link-resource-description-resource</a></td>
                    <td property="spec:statement">Change intended consumer from <a href="#SubscriptionClient">SubscriptionClient</a> to <a href="#DiscoveryClient">DiscoveryClient</a> in <a href="#resource-server-link-resource-description-resource" rel="spec:changeSubject">#resource-server-link-resource-description-resource</a>.</td>
                  </tr>
                  <tr about="#eacdeb0f-75d9-4466-a190-306a55e4c2b6" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-3" rel="spec:changeClass">3</a></td>
                    <td><a href="#resource-server-link-storage-description-resource" rel="spec:changeSubject">#resource-server-link-storage-description-resource</a></td>
                    <td property="spec:statement">Change intended consumer from <a href="#SubscriptionClient">SubscriptionClient</a> to <a href="#DiscoveryClient">DiscoveryClient</a> in <a href="#resource-server-link-storage-description-resource" rel="spec:changeSubject">#resource-server-link-storage-description-resource</a>.</td>
                  </tr>
                  <tr about="#b9334c45-1f8e-4af1-a9bb-2ca26eb3a78b" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
                    <td><a href="#resource-server-description-resource-response" rel="spec:changeSubject">#resource-server-description-resource-response</a></td>
                    <td property="spec:statement">Add <a href="#resource-server-description-resource-response">#resource-server-description-resource-response</a> to require <a href="#ResourceServer">ResourceServer</a> response content of the <a href="#description-resource">description resource</a> uses the <a href="#description-resource-data-model">Description Resource Data Model</a>.</td>
                  </tr>
                  <tr about="#c927530a-fbf3-45f9-840f-a8f3cc887ccf" typeof="spec:Change">
                    <td><a href="https://www.w3.org/policies/process/#class-3" rel="spec:changeClass">3</a></td>
                    <td><a href="#json-ld-format" rel="spec:changeSubject">#json-ld-format</a></td>
                    <td property="spec:statement">Change <a href="#json-ld-format">JSON-LD context and profile URI</a> to <code>https://www.w3.org/ns/solid/notifications-context/v1</code>.</td>
                  </tr>
                </tbody>
                <tfoot>
                  <tr>
                    <td colspan="3">
                      <dl class="change-classes">
                        <dt>1</dt><dd><a href="https://www.w3.org/policies/process/#class-1">No changes to text content</a></dd>
                        <dt>2</dt><dd><a href="https://www.w3.org/policies/process/#class-2">Corrections that do not affect conformance</a></dd>
                        <dt>3</dt><dd><a href="https://www.w3.org/policies/process/#class-3">Corrections that do not add new features</a></dd>
                        <dt>4</dt><dd><a href="https://www.w3.org/policies/process/#class-4">New features</a></dd>
                        <dt>5</dt><dd><a href="https://www.w3.org/policies/process/#class-5">Changes to the contents of a registry table</a></dd>
                      </dl>
                    </td>
                  </tr>
                </tfoot>
              </table>

              <p id="changes-previous"><a class="self-link" href="#changes-previous"></a>Changes since earlier versions of the Solid Notifications Protocol are detailed in the <a href="https://solidproject.org/TR/2022/notifications-protocol-20221231#change-log">changes section of the previous version</a> of the Solid Notifications Protocol.</p>
            </div>
          </section>

          <section class="appendix" id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements"><a class="self-link" href="#acknowledgements"></a>
            <h2 property="schema:name">Acknowledgements</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>The Community Group gratefully acknowledges the work that led to the creation of this specification, and extends sincere appreciation to those individuals that worked on technologies and specifications that deeply influenced our work.</p>

              <p>The Community Group would like to thank the following individuals for their useful comments, both large and small, that have led to changes to this specification over the years:</p>

              <ul>
                <li>Aaron Coburn</li>
                <li>Ángel Araya</li>
                <li>Christoph Braun</li>
                <li>Dmitri Zagidulin</li>
                <li>elf Palvlik</li>
                <li>Graham Klyne</li>
                <li>Hadrian Zbarcea</li>
                <li>Henry Story</li>
                <li>Jackson Morgan</li>
                <li>Jamie Fiedler</li>
                <li>Jarlath Holleran</li>
                <li>Joachim Van Herwegen</li>
                <li>Justin Bingham</li>
                <li>Kevin Howard</li>
                <li>Kjetil Kjernsmo</li>
                <li>Michiel de Jong</li>
                <li>Pete Edwards</li>
                <li>Rahul Gupta</li>
                <li>Ruben Verborgh</li>
                <li>Sarven Capadisli</li>
                <li>Ted Thibodeau Jr</li>
                <li>Tim Berners-Lee</li>
                <li>Wout Slabbinck</li>
                <li>Wouter Termont</li>
                <li><span lang="te" xml:lang="te">దామోదర</span></li>
              </ul>
            </div>
          </section>

          <section class="appendix" id="references" inlist="" rel="schema:hasPart" resource="#references"><a class="self-link" href="#references"></a>
            <h2 property="schema:name">References</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="normative-references" inlist="" rel="schema:hasPart" resource="#normative-references"><a class="self-link" href="#normative-references"></a>
                <h3 property="schema:name">Normative References</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <dl class="bibliography" resource="">
                    <dt id="bib-activitystreams-vocabulary">[ACTIVITYSTREAMS-VOCABULARY]</dt>
                    <dd><cite><a href="https://www.w3.org/TR/activitystreams-vocabulary/" rel="cito:citesAsAuthority">Activity Streams</a></cite>. James Snell; Evan Prodromou.  W3C. 23 May 2017. W3C Recommendation. URL: <a href="https://www.w3.org/TR/activitystreams-vocabulary/">https://www.w3.org/TR/activitystreams-vocabulary/</a></dd>
                    <dt id="bib-json-ld11">[JSON-LD11]</dt>
                    <dd><cite><a href="https://www.w3.org/TR/json-ld11/" rel="cito:citesAsAuthority">JSON-LD 1.1</a></cite>. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley.  W3C. 16 July 2020. W3C Recommendation. URL: <a href="https://www.w3.org/TR/json-ld11/">https://www.w3.org/TR/json-ld11/</a></dd>
                    <dt id="bib-powder-dr">[POWDER-DR]</dt>
                    <dd><cite><a href="https://www.w3.org/TR/powder-dr/" rel="cito:citesAsAuthority">Protocol for Web Description Resources (POWDER): Description Resources</a></cite>. Phil Archer; Kevin Smith; Andrea Perego.  W3C. 1 September 2009. W3C Recommendation. URL: <a href="https://www.w3.org/TR/powder-dr/">https://www.w3.org/TR/powder-dr/</a></dd>
                    <dt id="bib-rdf11-concepts">[RDF11-CONCEPTS]</dt>
                    <dd><cite><a href="https://www.w3.org/TR/rdf11-concepts/" rel="cito:citesAsAuthority">RDF 1.1 Concepts and Abstract Syntax</a></cite>. Richard Cyganiak; David Wood; Markus Lanthaler.  W3C. 25 February 2014. W3C Recommendation. URL: <a href="https://www.w3.org/TR/rdf11-concepts/">https://www.w3.org/TR/rdf11-concepts/</a></dd>
                    <dt id="bib-rfc2119">[RFC2119]</dt>
                    <dd><cite><a href="https://datatracker.ietf.org/doc/html/rfc2119" rel="cito:citesAsAuthority">Key words for use in RFCs to Indicate Requirement Levels</a></cite>. S. Bradner.  IETF. March 1997. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a></dd>
                    <dt id="bib-rfc3986">[RFC3986]</dt>
                    <dd><cite><a href="https://datatracker.ietf.org/doc/html/rfc3986" rel="cito:citesAsAuthority">Uniform Resource Identifier (URI): Generic Syntax</a></cite>. T. Berners-Lee; R. Fielding; L. Masinter.  IETF. January 2005. Internet Standard. URL: <a href="https://datatracker.ietf.org/doc/html/rfc3986">https://datatracker.ietf.org/doc/html/rfc3986</a></dd>
                    <dt id="bib-rfc4918">[RFC4918]</dt>
                    <dd><cite><a href="https://datatracker.ietf.org/doc/html/rfc4918" rel="cito:citesAsAuthority">HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</a></cite>. L. Dusseault, Ed.  IETF. June 2007. Proposed Standard. URL: <a href="https://datatracker.ietf.org/doc/html/rfc4918">https://datatracker.ietf.org/doc/html/rfc4918</a></dd>
                    <dt id="bib-rfc8174">[RFC8174]</dt>
                    <dd><cite><a href="https://datatracker.ietf.org/doc/html/rfc8174" rel="cito:citesAsAuthority">Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a></cite>. B. Leiba.  IETF. May 2017. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc8174">https://datatracker.ietf.org/doc/html/rfc8174</a></dd>
                    <dt id="bib-rfc8288">[RFC8288]</dt>
                    <dd><cite><a href="https://httpwg.org/specs/rfc8288.html" rel="cito:citesAsAuthority">Web Linking</a></cite>. M. Nottingham.  IETF. October 2017. Proposed Standard. URL: <a href="https://httpwg.org/specs/rfc8288.html">https://httpwg.org/specs/rfc8288.html</a></dd>
                    <dt id="bib-rfc9110">[RFC9110]</dt>
                    <dd><cite><a href="https://www.rfc-editor.org/rfc/rfc9110" rel="cito:citesAsAuthority">HTTP Semantics</a></cite>. R. Fielding, M. Nottingham, J. Reschke, Eds.  IETF. June 2022. Internet Standard. URL: <a href="https://www.rfc-editor.org/rfc/rfc9110">https://www.rfc-editor.org/rfc/rfc9110</a></dd>
                    <dt id="bib-rfc9112">[RFC9112]</dt>
                    <dd><cite><a href="https://www.rfc-editor.org/rfc/rfc9112" rel="cito:citesAsAuthority">HTTP/1.1</a></cite>. R. Fielding, M. Nottingham, J. Reschke, Eds.  IETF. June 2022. Internet Standard. URL: <a href="https://www.rfc-editor.org/rfc/rfc9112">https://www.rfc-editor.org/rfc/rfc9112</a></dd>
                    <dt id="bib-solid-protocol">[SOLID-PROTOCOL]</dt>
                    <dd><cite><a href="https://solidproject.org/TR/protocol" rel="cito:citesAsAuthority" typeof="doap:Specification">Solid Protocol</a></cite>. Sarven Capadisli; Tim Berners-Lee; Kjetil Kjernsmo.  W3C Solid Community Group. Draft Community Group Report, Version 0.11.0. URL: <a href="https://solidproject.org/TR/protocol">https://solidproject.org/TR/protocol</a></dd>
                    <dt id="bib-xmlschema11-2">[XMLSCHEMA11-2]</dt>
                    <dd><cite><a href="https://www.w3.org/TR/xmlschema11-2/" rel="cito:citesAsAuthority">W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</a></cite>. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al.  W3C. 5 April 2012. W3C Recommendation. URL: <a href="https://www.w3.org/TR/xmlschema11-2/">https://www.w3.org/TR/xmlschema11-2/</a></dd>
                  </dl>
                </div>
              </section>

              <section id="informative-references" inlist="" rel="schema:hasPart" resource="#informative-references"><a class="self-link" href="#informative-references"></a>
                <h3 property="schema:name">Informative References</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <dl class="bibliography" resource="">
                    <dt id="bib-solid-technical-reports">[SOLID-TECHNICAL-REPORTS]</dt>
                    <dd><cite><a href="https://solidproject.org/TR/" rel="cito:citesAsRelated">Solid Technical Reports</a></cite>. Sarven Capadisli.  W3C Solid Community Group. 03 June 2024. Living Document. URL: <a href="https://solidproject.org/TR/">https://solidproject.org/TR/</a></dd>
                    <dt id="bib-notifications-ucr">[NOTIFICATIONS-UCR]</dt>
                    <dd><cite><a href="https://solid.github.io/notifications-panel/notifications-ucr" rel="cito:citesAsRelated">Solid Notifications Use Cases and Requirements</a></cite>. Sarven Capadisli.  W3C Solid Community Group. 28 November 2022. W3C Editor’s Draft. URL: <a href="https://solid.github.io/notifications-panel/notifications-ucr">https://solid.github.io/notifications-panel/notifications-ucr</a></dd>
                    <dt id="bib-security-privacy-questionnaire">[SECURITY-PRIVACY-QUESTIONNAIRE]</dt>
                    <dd><cite><a href="https://www.w3.org/TR/security-privacy-questionnaire/" rel="cito:citesAsPotentialSolution">Self-Review Questionnaire: Security and Privacy</a></cite>. Theresa O'Connor; Peter Snyder.  W3C. 16 December 2021. W3C Group Note. URL: <a href="https://www.w3.org/TR/security-privacy-questionnaire/">https://www.w3.org/TR/security-privacy-questionnaire/</a></dd>
                    <dt id="bib-w3c-process">[W3C-PROCESS]</dt>
                    <dd><cite><a href="https://www.w3.org/policies/process/" rel="cito:citesAsPotentialSolution">W3C Process Document</a></cite>. Elika J. Etemad / fantasai; Florian Rivoal.  W3C Process Community Group. 12 June 2023. URL: <a href="https://www.w3.org/policies/process/">https://www.w3.org/policies/process/</a></dd>
                  </dl>
                </div>
              </section>
            </div>
          </section>
        </div>
      </article>
    </main>

    <p role="navigation" id="back-to-top"><a href="#toc"><abbr title="Back to top">↑</abbr></a></p>

    <script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script>
  </body>
</html>