-
Notifications
You must be signed in to change notification settings - Fork 7
/
protocol.html
1186 lines (1023 loc) · 106 KB
/
protocol.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!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";
}
</style>
<link href="https://www.w3.org/StyleSheets/TR/2021/base.css" media="all" rel="stylesheet" title="W3C-Base" />
<link href="https://www.w3.org/StyleSheets/TR/2021/dark.css" media="(prefers-color-scheme: dark)" rel="stylesheet" />
<link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />
<script async="" src="https://dokie.li/scripts/dokieli.js"></script>
</head>
<body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ doap: http://usefulinc.com/ns/doap# deo: http://purl.org/spar/deo/ 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">Editor’s Draft, <time datetime="2024-06-03T00:00:00Z">2024-06-03</time></p>
<details open="">
<summary>More details about this document</summary>
<dl id="document-identifier">
<dt>This version</dt>
<dd><a href="https://solid.github.io/notifications/protocol" rel="owl:sameAs">https://solid.github.io/notifications/protocol</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-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="2021-10-21T00:00:00Z" datatype="xsd:dateTime" datetime="2021-10-21T00:00:00Z" property="schema:dateCreated">2021-10-21</time></dd>
</dl>
<dl id="document-published">
<dt>Published</dt>
<dd><time content="2021-10-22T00:00:00Z" datatype="xsd:dateTime" datetime="2021-10-22T00:00:00Z" property="schema:datePublished">2021-10-22</time></dd>
</dl>
<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2024-06-03T00:00:00Z" datatype="xsd:dateTime" datetime="2024-06-03T00:00:00Z" property="schema:dateModified">2024-06-03</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.4.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://solid.github.io/notifications/protocol#document-policy-offer" rel="odrl:uid">https://solid.github.io/notifications/protocol#document-policy-offer</a></dd>
<dt>Target</dt>
<dd><a href="https://solid.github.io/notifications/protocol" rel="odrl:target">https://solid.github.io/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 Notiications Protocol, Editor’s Draft, 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. All code snippets are in the public domain, <a about="" href="https://creativecommons.org/public-domain/cc0/" rel="schema:license">CC0</a>.</span></p>
<hr title="Separator for header" />
</div>
<div datatype="rdf:HTML" id="content" property="schema:description">
<section id="abstract">
<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">
<h2 property="schema:name">Status of This Document</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This report was not 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.</p>
<p>Publication as an Editor’s Draft does not imply endorsement by anyone. This document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. You are invited to contribute any feedback, comments, or questions you might have.</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 class="tocxref" href="#overview"><bdi class="secno">1.1</bdi> <span>Overview</span></a></li>
<li class="tocline"><a class="tocxref" href="#namespaces"><bdi class="secno">1.2</bdi> <span>Namespaces</span></a></li>
<li class="tocline"><a class="tocxref" 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">
<h2 about="#introduction" property="schema:name" typeof="deo:Introduction">Introduction</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p id="motivation" rel="schema:hasPart" resource="#motivation" typeof="deo:Motivation"><span datatype="rdf:HTML" property="schema:description">The 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">
<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>
<img rel="schema:image" src="notifications-flow-discovery.mmd.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>
<img rel="schema:image" src="notifications-flow-subscription.mmd.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>
<img rel="schema:image" src="notifications-flow-receivefrom.mmd.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>
<img rel="schema:image" src="notifications-flow-sendto.mmd.svg" width="800" />
</figure>
</div>
</section>
<section id="namespaces" inlist="" rel="schema:hasPart" resource="#namespaces" typeof="skos:Collection">
<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">
<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">
<h4 property="schema:name">Normative and Informative Content</h4>
<div datatype="rdf:HTML" property="schema:description">
<p id="normative-informative-sections">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">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">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 spec:specificationCategory" resource="#specification-category" typeof="skos:ConceptScheme">
<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">
<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">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">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">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">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">Notification Sender</dfn></dt>
<dd about="#NotificationSender" property="skos:definition" rel="skos:broadMatch" resource="spec:ProducerOfContent">A <em>Notification Sender</em> is the sender of a notification acting in conformance to the product class of a notification channel type.</dd>
<dt about="#NotificationReceiver" property="skos:prefLabel" rel="skos:broadMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="NotificationReceiver">Notification Receiver</dfn></dt>
<dd about="#NotificationReceiver" property="skos:definition" rel="skos:broadMatch" resource="spec:Consumer">A <em>Notification Receiver</em> is the recipient of a notification acting in conformance to the product class of a notification channel type.</dd>
</dl>
</div>
</section>
<section id="interoperability" inlist="" rel="schema:hasPart" resource="#interoperability" typeof="skos:ConceptScheme">
<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">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">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">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">
<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">This specification uses JSON-LD [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>] as the preferred data format, and <code>https://www.w3.org/ns/solid/notifications-context/v1</code> as a URI for the JSON-LD context and as a value of the <code>profile</code> parameter used for content negotiation.</p>
<p id="authentication-authorization">This specification does not require a specific authentication and authorization mechanism to be used with the Solid Notification Protocol. Implementations are encouraged to use existing approaches, such as those described in the Solid Protocol sections on <cite><a href="https://solidproject.org/TR/protocol#authentication" rel="cito:discusses">Authentication</a></cite> and <cite><a href="https://solidproject.org/TR/protocol#authorization" rel="cito:discusses">Authorization</a></cite> [<cite><a class="bibref" href="#bib-solid-protocol">SOLID-PROTOCOL</a></cite>].</p>
<section id="discovery" inlist="" rel="schema:hasPart" resource="#discovery">
<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">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">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"><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"><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"><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"><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>
<pre property="schema:description"><code>HEAD https://example.org/guinan/profile</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Link: <https://example.org/guinan/profile.description>; 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">
<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">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">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">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"><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"><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"><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"><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"><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"><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"><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>
<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">
<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"><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"><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">
<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">
<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">
<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">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">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">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">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">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">
<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">
<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">
<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">One <code>id</code> property to identify the description resource.</li>
<li id="notify-subscription">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">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>
<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">
<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">One <code>id</code> property to identify the subscription service.</li>
<li id="notify-channelType">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">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>
<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">
<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">One <code>id</code> property to identify the notification channel.</li>
<li id="notify-channel-type">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">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">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">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">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">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>
<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">
<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">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">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">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">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">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">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>
<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>
<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">
<h2 property="schema:name">Considerations</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This section details <span about="" rel="spec:consideration"><a href="#security-considerations">security</a> and <a href="#privacy-considerations">privacy</a> considerations</span>.</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">
<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">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">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">
<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">
<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 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 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 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 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 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 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 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 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>