specification/ED/protocol.html at f0f82ddd8cfcabac90bf1f60de92fadf4ed6675e · solid/specification · GitHub

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 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# 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 Protocol</h1>
          <p id="w3c-state">Editor’s Draft, <time datetime="2025-04-12T00:00:00Z">2025-04-12</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/ED/protocol" rel="owl:sameAs">https://solidproject.org/ED/protocol</a></dd>
            </dl>
            <dl id="document-latest-published-version">
              <dt>Latest published version</dt>
              <dd><a href="https://solidproject.org/TR/protocol" rel="rel:latest-version">https://solidproject.org/TR/protocol</a></dd>
            </dl>
            <dl id="document-previous-version">
              <dt>Previous version</dt>
              <dd><a href="https://solidproject.org/TR/2024/protocol-20240512" rel="rel:predecessor-version">https://solidproject.org/TR/2024/protocol-20240512</a></dd>
            </dl>
            <dl id="document-history">
              <dt>History</dt>
              <dd><a href="https://github.com/solid/specification/commits/main/ED/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 schema:author"><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> <span class="contributed">(v0.9, v0.10, v0.11)</span></dd>
              <dd data-editor-id="2017" id="Tim-Berners-Lee"><span about="" rel="schema:editor schema:author"><span about="https://www.w3.org/People/Berners-Lee/card#i" typeof="schema:Person"><a href="https://www.w3.org/People/Berners-Lee/" rel="schema:url"><span about="https://www.w3.org/People/Berners-Lee/card#i" property="schema:name"><span property="schema:givenName">Tim</span> <span property="schema:familyName">Berners-Lee</span></span></a></span></span> <span class="contributed">(v0.9, v0.10, v0.11)</span></dd>
              <dd data-editor-id="38800" id="Kjetil-Kjernsmo"><span about="" rel="schema:editor schema:author"><span about="https://www.kjetil.kjernsmo.net/foaf#me" typeof="schema:Person"><a href="https://kjetil.kjernsmo.net/" rel="schema:url"><span about="https://www.kjetil.kjernsmo.net/foaf#me" property="schema:name"><span property="schema:givenName">Kjetil</span> <span property="schema:familyName">Kjernsmo</span></span></a></span></span> <span class="contributed">(v0.9, v0.10, v0.11)</span></dd>
            </dl>
            <dl id="document-former-editors">
              <dt>Former editors</dt>
              <dd>Ruben Verborgh <span class="contributed">(v0.9, v0.10)</span></dd>
            </dl>
            <dl id="document-published">
              <dt>Published</dt>
              <dd><time content="2020-12-16T00:00:00Z" datatype="xsd:dateTime" datetime="2020-12-16T00:00:00Z" property="schema:datePublished">2020-12-16</time></dd>
            </dl>
            <dl id="document-modified">
              <dt>Modified</dt>
              <dd><time content="2025-04-12T00:00:00Z" datatype="xsd:dateTime" datetime="2025-04-12T00:00:00Z" property="schema:dateModified">2025-04-12</time></dd>
            </dl>
            <dl id="document-feedback">
              <dt>Feedback</dt>
              <dd><a href="https://github.com/solid/specification" rel="doap:repository">GitHub solid/specification</a> (<a href="https://github.com/solid/specification/pulls">pull requests</a>, <a href="https://github.com/solid/specification/issues/new">new issue</a>, <a href="https://github.com/solid/specification/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.12.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>
            </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/protocol#document-policy-offer" rel="odrl:uid">https://solidproject.org/TR/protocol#document-policy-offer</a></dd>
                  <dt>Target</dt>
                  <dd><a href="https://solidproject.org/TR/protocol" rel="odrl:target">https://solidproject.org/TR/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> © 2019–2024 the Contributors to Solid 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 document connects a set of specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way.</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"><bdi class="secno"></bdi> <span>Abstract</span></a></li>
                <li class="tocline"><a class="tocxref" href="#sotd"><bdi class="secno"></bdi> <span>Status of This Document</span></a></li>
                <li class="tocline">
                  <p><a class="tocxref" href="#introduction"><bdi class="secno">1.</bdi> <span>Introduction</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#terminology"><bdi class="secno">1.1</bdi> <span>Terminology</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">
                      <p><a class="tocxref" href="#conformance"><bdi class="secno">1.3</bdi> <span>Conformance</span></a></p>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#normative-informative-content"><bdi class="secno">1.3.1</bdi> <span>Normative and Informative Content</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#specification-category"><bdi class="secno">1.3.2</bdi> <span>Specification Category</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#classes-of-products"><bdi class="secno">1.3.3</bdi> <span>Classes of Products</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#interoperability"><bdi class="secno">1.3.4</bdi> <span>Interoperability</span></a></li>
                      </ol>
                    </li>
                    <li class="tocline">
                      <p><a class="tocxref" href="#relations"><bdi class="secno">1.4</bdi> <span>Relations</span></a></p>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#relationship-to-ldp"><bdi class="secno">1.4.1</bdi> <span>Relationship to LDP</span></a></li>
                      </ol>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#http"><bdi class="secno">2.</bdi> <span>Hypertext Transfer Protocol</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#http-server"><bdi class="secno">2.1</bdi> <span>HTTP Server</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#http-client"><bdi class="secno">2.2</bdi> <span>HTTP Client</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#uri"><bdi class="secno">3.</bdi> <span>Uniform Resource Identifier</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#uri-slash-semantics"><bdi class="secno">3.1</bdi> <span>URI Slash Semantics</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#uri-persistence"><bdi class="secno">3.2</bdi> <span>URI Persistence</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#resources"><bdi class="secno">4.</bdi> <span>Resources</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#storage-resource"><bdi class="secno">4.1</bdi> <span>Storage Resource</span></a></li>
                    <li class="tocline">
                      <p><a class="tocxref" href="#resource-containment"><bdi class="secno">4.2</bdi> <span>Resource Containment</span></a></p>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#contained-resource-metadata"><bdi class="secno">4.2.1</bdi> <span>Contained Resource Metadata</span></a></li>
                      </ol>
                    </li>
                    <li class="tocline">
                      <p><a class="tocxref" href="#auxiliary-resources"><bdi class="secno">4.3</bdi> <span>Auxiliary Resources</span></a></p>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#auxiliary-resources-web-access-control"><bdi class="secno">4.3.1</bdi> <span>Web Access Control</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#auxiliary-resources-description-resource"><bdi class="secno">4.3.2</bdi> <span>Description Resource</span></a></li>
                      </ol>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#reading-writing-resources"><bdi class="secno">5.</bdi> <span>Reading and Writing Resources</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#resource-type-heuristics"><bdi class="secno">5.1</bdi> <span>Resource Type Heuristics</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#reading-resources"><bdi class="secno">5.2</bdi> <span>Reading Resources</span></a></li>
                    <li class="tocline">
                      <p><a class="tocxref" href="#writing-resources"><bdi class="secno">5.3</bdi> <span>Writing Resources</span></a></p>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#n3-patch"><bdi class="secno">5.3.1</bdi> <span>Modifying Resources Using N3 Patches</span></a></li>
                      </ol>
                    </li>
                    <li class="tocline"><a class="tocxref" href="#deleting-resources"><bdi class="secno">5.4</bdi> <span>Deleting Resources</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#resource-representations"><bdi class="secno">5.5</bdi> <span>Resource Representations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#constraints-problem-details"><bdi class="secno">5.6</bdi> <span>Constraints and Problem Details</span></a></li>
                  </ol>
                </li>
                <li class="tocline"><a class="tocxref" href="#linked-data-notifications"><bdi class="secno">6.</bdi> <span>Linked Data Notifications</span></a></li>
                <li class="tocline">
                  <p><a class="tocxref" href="#live-update"><bdi class="secno">7.</bdi> <span>Live Update</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#notifications-protocol"><bdi class="secno">7.1</bdi> <span>Solid Notifications Protocol</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#cors"><bdi class="secno">8.</bdi> <span>Cross-Origin Resource Sharing</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#cors-server"><bdi class="secno">8.1</bdi> <span>CORS Server</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#identity"><bdi class="secno">9.</bdi> <span>Identity</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#webid"><bdi class="secno">9.1</bdi> <span>WebID</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#authentication"><bdi class="secno">10.</bdi> <span>Authentication</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#solid-oidc"><bdi class="secno">10.1</bdi> <span>Solid-OIDC</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#webid-tls"><bdi class="secno">10.2</bdi> <span>WebID-TLS</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#authorization"><bdi class="secno">11.</bdi> <span>Authorization</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#web-access-control"><bdi class="secno">11.1</bdi> <span>Web Access Control</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#access-control-policy"><bdi class="secno">11.2</bdi> <span>Access Control Policy</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#http-definitions"><bdi class="secno">12.</bdi> <span>HTTP Definitions</span></a></p>
                  <ol>
                    <li class="tocline">
                      <p><a class="tocxref" href="#http-headers"><bdi class="secno">12.1</bdi> <span>HTTP Headers</span></a></p>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#accept-put"><bdi class="secno">12.1.1</bdi> <span>The Accept-Put Response Header</span></a></li>
                      </ol>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <p><a class="tocxref" href="#considerations"><bdi class="secno">13.</bdi> <span>Considerations</span></a></p>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#security-considerations"><bdi class="secno">13.1</bdi> <span>Security Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#privacy-considerations"><bdi class="secno">13.2</bdi> <span>Privacy Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#accessibility-considerations"><bdi class="secno">13.3</bdi> <span>Accessibility Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#internationalization-considerations"><bdi class="secno">13.4</bdi> <span>Internationalization Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#security-privacy-review"><bdi class="secno">13.5</bdi> <span>Security and Privacy Review</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#societal-impact-review"><bdi class="secno">13.6</bdi> <span>Societal Impact 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">
                  <p><a class="tocxref" href="#references"><bdi class="secno">C.</bdi> <span>References</span></a></p>
                  <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 property="schema:name">Introduction</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><em>This section is non-normative.</em></p>
              <p>The aims of the Solid project are in line with those of the Web itself: empowerment towards <q cite="https://www.w3.org/TR/ethical-web-principles/">an equitable, informed and interconnected society</q>. Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.</p>
              <p>The Solid ecosystem encapsulates a set of specifications that are guided by the principles we have adopted and also the priority of our values. We acknowledge that every technical decision has ethical implications both for the end user (short-term) as well as society (long-term). To contribute towards a net positive social benefit, we use the <cite><a href="https://www.w3.org/TR/ethical-web-principles/" rel="cito:citesForInformation">Ethical Web Principles</a></cite> [<cite><a class="bibref" href="#bib-ethical-web-principles">ETHICAL-WEB-PRINCIPLES</a></cite>] to orient ourselves. The consensus on the technical designs are informed by common use cases, implementation experience, and use.</p>
              <p>An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting. In this environment, actors allocate identifiers for their content, shape and store data where they have access to, set access controls, and use preferred applications and services to achieve them.</p>
              <p>The general architectural principles of Solid specifications are borrowed from the <cite><a href="https://www.w3.org/TR/webarch/" rel="cito:citesForInformation">Architecture of the World Wide Web</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>]. The components as described in each specification may evolve independently – according to the principle of orthogonality in order to increase the flexibility and robustness of the Solid ecosystem. With that, the specifications are loosely coupled and indicate which features overlap with those governed by another specification. Extensibility as well as variability also are taken into account in each specification.</p>
              <p>The specifications in the ecosystem describe how Solid servers and clients can be interoperable by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, and query interfaces.</p>
              <p>The specifications are accompanied with supplemental documents, such as <em>Primers</em> and <em>Best Practices and Guidelines</em> to help implementers to form a well-rounded understanding of the Solid ecosystem as well as ways to improve their implementations.</p>
              <p>This specification is for:</p>
              <ul about="" rel="schema:audience">
                <li>Resource <a href="http://data.europa.eu/esco/occupation/a7c1d23d-aeca-4bee-9a08-5993ed98b135">server developers</a> that want to enable clients to send and retrieve information;</li>
                <li><a href="http://data.europa.eu/esco/occupation/c40a2919-48a9-40ea-b506-1f34f693496d">Application developers</a> that want to implement a client to perform operations on resources.</li>
              </ul>
              <section id="terminology" inlist="" rel="schema:hasPart" resource="#terminology" typeof="skos:ConceptScheme">
                <h3 property="schema:name skos:prefLabel">Terminology</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>
                  <p property="skos:definition">The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.</p>
                  <p><span rel="skos:hasTopConcept"><span resource="#storage"></span><span resource="#solid-app"></span><span resource="#uniform-resource-identifier"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></span><span resource="#resource-metadata"></span><span resource="#agent"></span><span resource="#owner"></span><span resource="#origin"></span><span resource="#read-operation"></span><span resource="#write-operation"></span><span resource="#append-operation"></span></span></p>
                  <dl>
                    <dt about="#storage" property="skos:prefLabel" typeof="skos:Concept"><dfn id="storage">storage</dfn></dt>
                    <dd about="#storage" property="skos:definition">A storage is a space of URIs that affords agents controlled access to resources.</dd>
                    <dt about="#solid-app" property="skos:prefLabel" typeof="skos:Concept"><dfn id="solid-app">Solid app</dfn></dt>
                    <dd about="#solid-app" property="skos:definition">A Solid app is an application that reads or writes data from one or more <a href="#storage">storages</a>.</dd>
                    <dt about="#uniform-resource-identifier" property="skos:prefLabel" typeof="skos:Concept"><dfn id="uniform-resource-identifier">URI</dfn></dt>
                    <dd about="#uniform-resource-identifier" property="skos:definition">A <dfn>Uniform Resource Identifier</dfn> (<abbr title="Uniform Resource Identifier">URI</abbr>) provides the means for identifying resources [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>].</dd>
                    <dt about="#resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource">resource</dfn></dt>
                    <dd about="#resource" property="skos:definition">A resource is the target of an HTTP request identified by a URI [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</dd>
                    <dt about="#container-resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="container-resource">container resource</dfn></dt>
                    <dd about="#container-resource" property="skos:definition">A container resource is a hierarchical collection of resources that contains other resources, including containers.</dd>
                    <dt about="#root-container" property="skos:prefLabel" typeof="skos:Concept"><dfn id="root-container">root container</dfn></dt>
                    <dd about="#root-container" property="skos:definition">A root container is a container resource that is at the highest level of the collection hierarchy.</dd>
                    <dt about="#resource-metadata" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource-metadata">resource metadata</dfn></dt>
                    <dd about="#resource-metadata" property="skos:definition">Resource metadata encompasses data about resources described by means of RDF statements [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</dd>
                    <dt about="#agent" property="skos:prefLabel" typeof="skos:Concept"><dfn id="agent">agent</dfn></dt>
                    <dd about="#agent" property="skos:definition">An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [<cite><a class="bibref" href="#bib-webid">WEBID</a></cite>].</dd>
                    <dt about="#owner" property="skos:prefLabel" typeof="skos:Concept"><dfn id="owner">owner</dfn></dt>
                    <dd about="#owner" property="skos:definition">An owner is a person or a social entity that is considered to have the rights and responsibilities of a storage. An owner is identified by a URI, and implicitly has control over all resources in a storage. An owner is first set at storage provisioning time and can be changed.</dd>
                    <dt about="#origin" property="skos:prefLabel" typeof="skos:Concept"><dfn id="origin">origin</dfn></dt>
                    <dd about="#origin" property="skos:definition">An origin indicates where an HTTP request originates from [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>].</dd>
                    <dt about="#read-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="read-operation">read operation</dfn></dt>
                    <dd about="#read-operation" property="skos:definition">A read operation entails that information about a resource’s existence or its description can be known. [<a href="https://github.com/solid/specification/issues/149#issue-568433265" rel="cito:citesAsSourceDocument">Source</a>]</dd>
                    <dt about="#write-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="write-operation">write operation</dfn></dt>
                    <dd about="#write-operation" property="skos:definition">A write operation entails that information about resources can be created or removed. [<a href="https://github.com/solid/specification/issues/126#issuecomment-569920473" rel="cito:citesAsSourceDocument">Source</a>]</dd>
                    <dt about="#append-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="append-operation">append operation</dfn></dt>
                    <dd about="#append-operation" property="skos:definition">An append operation entails that information can be added but not removed. [<a href="https://github.com/solid/specification/issues/118#issuecomment-569648485" rel="cito:citesAsSourceDocument">Source</a>]</dd>
                  </dl>
                </div>
              </section>
              <section id="namespaces" inlist="" rel="schema:hasPart" resource="#namespaces">
                <h3 property="schema:name">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>
                        <td><code>rdf</code></td>
                        <td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
                        <td>[<cite><a class="bibref" href="#bib-rdf-schema">rdf-schema</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><code>ldp</code></td>
                        <td>http://www.w3.org/ns/ldp#</td>
                        <td>[<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><code>solid</code></td>
                        <td>http://www.w3.org/ns/solid/terms#</td>
                        <td>Solid Terms</td>
                      </tr>
                      <tr>
                        <td><code>pim</code></td>
                        <td>http://www.w3.org/ns/pim/space#</td>
                        <td>Workspace Ontology</td>
                      </tr>
                      <tr>
                        <td><code>acl</code></td>
                        <td>http://www.w3.org/ns/auth/acl#</td>
                        <td>ACL Ontology</td>
                      </tr>
                      <tr>
                        <td><code>dcterms</code></td>
                        <td>http://purl.org/dc/terms/</td>
                        <td>[<cite><a class="bibref" href="#bib-dc-terms">DC-TERMS</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><code>stat</code></td>
                        <td>http://www.w3.org/ns/posix/stat</td>
                        <td>POSIX File Status</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 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" 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 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:ProcessorBehaviour">processor behaviour</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 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>
                      <p><span rel="skos:hasTopConcept"><span resource="#Server"></span><span resource="#Client"></span></span></p>
                      <dl>
                        <dt about="#Server" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="Server">Server</dfn></dt>
                        <dd about="#Server" property="skos:definition">A <a href="#http-server" rel="rdfs:seeAlso">server</a> 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>] by defining media types, HTTP header fields, and the behaviour of resources, as identified by link relations.</dd>
                        <dt about="#Client" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="Client">Client</dfn></dt>
                        <dd about="#Client" property="skos:definition">A <a href="#http-client" rel="rdfs:seeAlso">client</a> 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>
                      </dl>
                    </div>
                  </section>
                  <section id="interoperability" inlist="" rel="schema:hasPart" resource="#interoperability">
                    <h4 property="schema:name skos:prefLabel">Interoperability</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p id="interoperability-server-client">Interoperability of implementations for <a href="#Server" rel="rdfs:seeAlso">servers</a> and <a href="#Client" rel="rdfs:seeAlso">clients</a> is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.</p>
                    </div>
                  </section>
                </div>
              </section>
              <section id="relations" inlist="" rel="schema:hasPart" resource="#relations">
                <h3 property="schema:name">Relations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>
                  <section id="relationship-to-ldp" inlist="" rel="schema:hasPart" resource="#relationship-to-ldp">
                    <h4 property="schema:name">Relationship to LDP</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p><em>This section is non-normative.</em></p>
                      <p>The <a href="https://solidproject.org/TR/protocol" rel="cito:discusses">Solid Protocol</a> and the <a href="https://www.w3.org/TR/ldp/" rel="cito:discusses">Linked Data Platform</a> (<abbr title="Linked Data Platform">LDP</abbr>) [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] both use relative referencing of URIs [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>].</p>
                      <p>As HTTP clients assign a URI to a resource when using <code>PUT</code> and <code>PATCH</code>, relative references in representation content are deterministic in both the Solid Protocol and LDP.</p>
                      <p>LDP does not specify URI patterns for resources when using the <code>POST</code> method, e.g., <code>POST http://example.org/foo/</code> may result in creating a resource with URI <code>http://example.org/foo/bar</code>, <code>http://example.org/baz/qux/quxx</code>, <code>http://example.org/{uuid}</code> or something else. In Solid Protocol, the URI of a new resource resulting from, e.g., <code>POST http://example.org/foo/</code>, is in context of the request URI, and therefore <code>http://example.org/foo/bar</code> will be created, and it is not possible to construct the new URI besides under the direct hierarchy of <code>http://example.org/foo/</code>.</p>
                      <p>Solid Protocol's <a href="#Server">server</a> behaviour in that regard is compatible with LDP even if only <code>ldp:Container</code> is advertised in the HTTP <code>Link</code> header field of the request URI, i.e., <code>http://example.org/foo/</code> as the target URI of <code>POST</code>. Thus, it is possible to have a Solid Protocol server as a particular specialisation of LDP with respect to behaviours around <code>POST</code> to containers. Clients that are interoperable with LDP servers would also be interoperable with Solid Protocol servers with respect to relative referencing. Although LDP servers cannot guarantee the URI pattern resulting from <code>POST</code> requests, the fact that Solid Protocol servers can does not impact interoperability between Solid Protocol servers and LDP clients.</p>
                      <p>Solid Protocol <a href="#Client">clients</a> may not fully interoperate with LDP servers, e.g., it is possible for an LDP server implementation to assign URIs to new resources that are not compatible with Solid Protocol. An LDP server needs to also conform to Solid Protocol server requirements in order to participate in the Solid ecosystem.</p>
                    </div>
                  </section>
                </div>
              </section>
            </div>
          </section>
          <section id="http" inlist="" rel="schema:hasPart" resource="#http">
            <h2 property="schema:name">Hypertext Transfer Protocol</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>Solid <a href="#Server" rel="dcterms:subject">servers</a> and <a href="#Client" rel="dcterms:subject">clients</a> need to exchange data securely over the Internet, and they do so using the HTTP Web standard. This section describes in detail which parts of HTTP must be implemented by clients and servers.</p>
              <section id="http-server" inlist="" rel="schema:hasPart" resource="#http-server">
                <h3 property="schema:name">HTTP Server</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="server-http" rel="spec:requirement" resource="#server-http"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP Semantics</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span></span> <span about="" id="server-caching" rel="spec:requirement" resource="#server-caching"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> conform to <cite>HTTP Caching</cite> [<cite><a class="bibref" href="#bib-rfc9111">RFC9111</a></cite>].</span></span> <span about="" id="server-http-11" rel="spec:requirement" resource="#server-http-11"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1</cite> [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>].</span></span> <span about="" id="server-http-2" rel="spec:requirement" resource="#server-http-2"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> conform to <cite>HTTP/2</cite> [<cite><a class="bibref" href="#bib-rfc9113">RFC9113</a></cite>].</span></span></p>
                  <p><span about="" id="server-tls-https" rel="spec:requirement" resource="#server-tls-https"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> use TLS connections through the <code>https</code> URI scheme in order to secure the communication with clients.</span></span> <span about="" id="server-tls-https-redirect" rel="spec:requirement" resource="#server-tls-https-redirect"><span property="spec:statement">When both <code>http</code> and <code>https</code> URI schemes are supported, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> redirect all <code>http</code> URIs to their <code>https</code> counterparts using a response with a <code>301</code> status code and a <code>Location</code> header field.</span></span></p>
                  <p about="" id="server-unauthenticated" rel="spec:requirement" resource="#server-unauthenticated"><span property="spec:statement">When a client does not provide valid credentials when requesting a resource that requires it (see <a href="#webid">WebID</a>), <span rel="spec:requirementSubject" resource="#Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> send a response with a <code>401</code> status code (unless <code>404</code> is preferred for security reasons).</span></p>
                  <p about="" id="server-content-type-includes" rel="spec:requirement" resource="#server-content-type-includes"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> generate a <code>Content-Type</code> header field in a message that contains content.</span></p>
                  <p about="" id="server-content-type-missing" rel="spec:requirement" resource="#server-content-type-missing"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> reject <code>PUT</code>, <code>POST</code>, and <code>PATCH</code> requests that contain content but lack the <code>Content-Type</code> header field, with a status code of <code>400</code>.</span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/660#issue-2319265317" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-last-modified-includes" rel="spec:requirement" resource="#server-last-modified-includes"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> generate a <code>Last-Modified</code> header field in response to <code>GET</code> and <code>HEAD</code> requests.</span></p>
                </div>
              </section>
              <section id="http-client" inlist="" rel="schema:hasPart" resource="#http-client">
                <h3 property="schema:name">HTTP Client</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="client-http" rel="spec:requirement" resource="#client-http"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP Semantics</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span></span> <span about="" id="client-caching" rel="spec:requirement" resource="#client-caching"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP Caching</cite> [<cite><a class="bibref" href="#bib-rfc9111">RFC9111</a></cite>].</span></span> <span about="" id="client-http-11" rel="spec:requirement" resource="#client-http-11"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1</cite> [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>].</span></span> <span about="" id="client-http-2" rel="spec:requirement" resource="#client-http-2"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/2</cite> [<cite><a class="bibref" href="#bib-rfc9113">RFC9113</a></cite>].</span></span></p>
                  <p about="" id="client-authentication-different-credentials" rel="spec:requirement" resource="#client-authentication-different-credentials"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Client">client</span> receives a response with a <code>403</code> or <code>404</code> status code, the client <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> repeat the request with different credentials.</span></p>
                  <p about="" id="client-content-type-includes" rel="spec:requirement" resource="#client-content-type-includes"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <code>Content-Type</code> HTTP header field in <code>PUT</code>, <code>POST</code>, and <code>PATCH</code> requests that contain content [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/660#issue-2319265317" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
            </div>
          </section>
          <section id="uri" inlist="" rel="schema:hasPart" resource="#uri">
            <h2 property="schema:name">Uniform Resource Identifier</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <div class="note" id="storage-owner-uri-ownership" inlist="" rel="schema:hasPart" resource="#storage-owner-uri-ownership">
                <h3 property="schema:name"><span>Note</span>: Storage Owner and URI Ownership</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>This specification does not describe the relationship between a storage <q>owner</q> and Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#uri-ownership">URI ownership</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>].</p>
                </div>
              </div>
              <section id="uri-slash-semantics" inlist="" rel="schema:hasPart" resource="#uri-slash-semantics">
                <h3 property="schema:name">URI Slash Semantics</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p id="uri-slashes-hierarchical-identifier">The slash (<code>/</code>) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource. [<a href="https://github.com/solid/specification/issues/35#issuecomment-547949014" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p><span about="" id="server-uri-trailing-slash-distinct" rel="spec:requirement" resource="#server-uri-trailing-slash-distinct"><span property="spec:statement">If two URIs differ only in the trailing slash, and the <span rel="spec:requirementSubject" resource="#Server">server</span> has associated a resource with one of them, then the other URI <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> correspond to another resource.</span></span> <span about="" id="server-uri-redirect-differing" rel="spec:requirement" resource="#server-uri-redirect-differing"><span property="spec:statement">Instead, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> respond to requests for the latter URI with a 301 redirect to the former.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567482817" rel="cito:citesAsSourceDocument">Source</a>]. <span about="" id="server-authorization-redirect" rel="spec:requirement" resource="#server-authorization-redirect"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> authorize prior to this optional redirect.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567454889" rel="cito:citesAsSourceDocument">Source</a>].</p>
                </div>
              </section>
              <section id="uri-persistence" inlist="" rel="schema:hasPart" resource="#uri-persistence">
                <h3 property="schema:name">URI Persistence</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>
                  <p>Servers should not re-use URIs, regardless of the mechanism by which resources are created. Certain specific cases exist where URIs may be reinstated when it identifies the same resource, but only when consistent with Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#URI-persistence">URI persistence</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>]. [<a href="https://github.com/solid/specification/issues/46#issuecomment-589619372" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <div class="note" id="uri-reuse" inlist="" rel="schema:hasPart" resource="#uri-reuse">
                    <h4 property="schema:name"><span>Note</span>: URI Reuse</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="uri-reuse-disabling" rel="spec:advisement" resource="#uri-reuse-disabling"><span property="spec:statement">Servers that wish to disable URI re-use <span rel="spec:advisementLevel" resource="spec:Might">might</span> want to use the <code>410</code> status code.</span></p>
                    </div>
                  </div>
                </div>
              </section>
            </div>
          </section>
          <section id="resources" inlist="" rel="schema:hasPart" resource="#resources">
            <h2 property="schema:name">Resources</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="storage-resource" inlist="" rel="schema:hasPart" resource="#storage-resource">
                <h3 property="schema:name">Storage Resource</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p about="" id="server-storage" rel="spec:requirement" resource="#server-storage"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> provide one or more <a href="#storage">storages</a>. The storage resource (<code>pim:Storage</code>) is the root container for all of its contained resources (see <a href="#resource-containment">Resource Containment</a>).</span></p>
                  <p about="" id="server-storage-nonoverlapping" rel="spec:requirement" resource="#server-storage-nonoverlapping"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> supports multiple storages, the URIs <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be allocated to non-overlapping space.</span></p>
                  <p about="" id="server-link-storage" rel="spec:requirement" resource="#server-link-storage"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise the storage resource by including the HTTP <code>Link</code> header field with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code> when responding to storage’s request URI.</span></p>
                  <p about="" id="client-link-storage" rel="spec:requirement" resource="#client-link-storage">Clients can determine a resource is of type storage by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking for the <code>Link</code> header field with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</p>
                  <p about="" id="client-storage-disovery" rel="spec:requirement" resource="#client-storage-discovery">Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a <code>Link</code> header field with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</p>
                  <p about="" id="client-rdf-storage" rel="spec:requirement" resource="#client-rdf-storage">Clients can discover a storage by making an HTTP <code>GET</code> request on the target URL to retrieve an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/pim/space#storage</code>. The object of the relation is the storage (<code>pim:Storage</code>).</p>
                  <p>[<a href="https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/153#issuecomment-624630022" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-storage-description" rel="spec:requirement" resource="#server-storage-description"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include the <code>Link</code> header field with <code>rel="http://www.w3.org/ns/solid/terms#storageDescription"</code> targeting the URI of the storage description resource in the response of HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> requests targeting a resource in a storage.</span></p>
                  <p about="" id="server-storage-description-resource" rel="spec:requirement" resource="#server-storage-description-resource"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include <a href="#storage-description-statements" rel="rdfs:seeAlso">statements about the storage</a> as part of the storage description resource.</span></p>
                  <p about="#storage-description-statements" id="storage-description-statements" typeof="skos:Collection"><span property="skos:prefLabel">Storage description statements</span> include the properties:</p>
                  <dl about="#storage-description-statements" rel="skos:member">
                    <dt about="#storage-description-rdf-type" id="storage-description-rdf-type" property="skos:prefLabel" typeof="skos:Concept"><code>rdf:type</code></dt>
                    <dd about="#storage-description-rdf-type" property="skos:definition">A class whose URI is <code>http://www.w3.org/ns/pim/space#Storage</code>.</dd>
                  </dl>
                  <p>[<a href="https://github.com/solid/specification/issues/355" rel="cito:citesAsSourceDocument">Source</a>].</p>
                  <p about="" id="server-storage-track-owner" rel="spec:requirement" resource="#server-storage-track-owner"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> keep track of at least one <a href="#owner">owner</a> of a storage in an implementation defined way.</span></p>
                  <p about="" id="server-storage-link-owner" rel="spec:requirement" resource="#server-storage-link-owner"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> wants to advertise the owner of a storage, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include the <code>Link</code> header field with <code>rel="http://www.w3.org/ns/solid/terms#owner"</code> targeting the URI of the owner in the response of HTTP <code>HEAD</code> or <code>GET</code> requests targeting the root container.</span></p>
                  <p>[<a href="https://github.com/solid/specification/issues/67" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/132" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/153" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/197" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
              <section id="resource-containment" inlist="" rel="schema:hasPart" resource="#resource-containment">
                <h3 property="schema:name">Resource Containment</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.</p>
                  <p id="server-hierarchical-containment">There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy. [<a href="https://github.com/solid/specification/issues/98#issuecomment-547506617" rel="cito:citesAsSourceDocument">Source</a>]. It follows that all resources are discoverable from a container and that it is not possible to create orphan resources. [<a href="https://github.com/solid/specification/issues/97#issuecomment-547459396" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-basic-container" rel="spec:requirement" resource="#server-basic-container"><span property="spec:statement">The representation and behaviour of containers in Solid corresponds to LDP Basic Container and <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be supported by <span rel="spec:requirementSubject" resource="#Server">server</span>.</span> [<a href="https://github.com/solid/specification/issues/47#issuecomment-561675764" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p id="server-container-last-modified">Servers can determine the field value of the HTTP <code>Last-Modified</code> header field in response to <code>HEAD</code> and <code>GET</code> requests targeting a container based on changes to containment triples.</p>
                  <div class="note" id="container-last-modified-comparison" inlist="" rel="schema:hasPart" resource="#container-last-modified-comparison">
                    <h4 property="schema:name"><span>Note</span>: Container Last-Modified Comparison</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="container-last-modified-reliability" rel="spec:advisement" resource="#container-last-modified-reliability"><span property="spec:statement">The <code>Last-Modified</code> of a container will not change when other parts of the container changes. This is to avoid instant propagation of changes all the way to the root container. As <code>Last-Modified</code> <span rel="spec:advisementLevel" resource="spec:Cannot">cannot</span> be reliably used to check whether the container representation has changed in any way, relying on it for change detection is not meaningful. In future versions of this specification, this design may be revisited.</span></p>
                    </div>
                  </div>
                  <section id="contained-resource-metadata" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata">
                    <h4 property="schema:name">Contained Resource Metadata</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Container descriptions are not limited to containment triples. To further support client navigation and application interaction, servers can include <a href="#resource-metadata">resource metadata</a> about contained resources as part of the container description, as described below.</p>
                      <p about="" id="server-contained-resource-metadata" rel="spec:requirement" resource="#server-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> include <a href="#contained-resource-metadata-statements" rel="rdfs:seeAlso">resource metadata about contained resources</a> as part of the container description, unless that information is inapplicable to the server.</span></p>
                      <p about="#contained-resource-metadata-statements" id="contained-resource-metadata-statements" typeof="skos:Collection"><span property="skos:prefLabel">Contained resource metadata statements</span> include the properties:</p>
                      <dl about="#contained-resource-metadata-statements" rel="skos:member">
                        <dt about="#contained-resource-metadata-rdf-type" id="contained-resource-metadata-rdf-type" property="skos:prefLabel" typeof="skos:Concept"><code>rdf:type</code></dt>
                        <dd about="#contained-resource-metadata-rdf-type" property="skos:definition">A class whose URI is the expansion of the <em>URI Template</em> [<cite><a class="bibref" href="#bib-rfc6570">RFC6570</a></cite>] <code>http://www.w3.org/ns/iana/media-types/{+iana-media-type}#Resource</code>, where <code>iana-media-type</code> corresponds to a value from the IANA Media Types [<cite><a class="bibref" href="#bib-iana-media-types">IANA-MEDIA-TYPES</a></cite>].</dd>
                        <dt about="#contained-resource-metadata-stat-size" id="contained-resource-metadata-stat-size" property="skos:prefLabel" typeof="skos:Concept"><code>stat:size</code></dt>
                        <dd about="#contained-resource-metadata-stat-size" property="skos:definition">A non-negative integer giving the size of the resource in bytes.</dd>
                        <dt about="#contained-resource-metadata-dcterms-modified" id="contained-resource-metadata-dcterms-modified" property="skos:prefLabel" typeof="skos:Concept"><code>dcterms:modified</code></dt>
                        <dd about="#contained-resource-metadata-dcterms-modified" property="skos:definition">The date and time when the resource was last modified.</dd>
                        <dt about="#contained-resource-metadata-stat-mtime" id="contained-resource-metadata-stat-mtime" property="skos:prefLabel" typeof="skos:Concept"><code>stat:mtime</code></dt>
                        <dd about="#contained-resource-metadata-stat-mtime" property="skos:definition">The Unix time when the resource was last modified.</dd>
                      </dl>
                      <p id="dcterms-modified-corresponds-last-modified">The <code>dcterms:modified</code> value of a contained resource corresponds with the <code>Last-Modified</code> header field value of the contained resource. If one were to perform <code>HEAD</code> or <code>GET</code> requests on the URI of the contained resource at the time of the HTTP message’s generation, then a response with the <code>200</code> status code including the <code>Last-Modified</code> header field would indicate the same date and time.</p>
                      <div class="note" id="contained-resource-metadata-considerations" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata-considerations">
                        <h5 property="schema:name"><span>Note</span>: Contained Resource Metadata Considerations</h5>
                        <div datatype="rdf:HTML" property="schema:description">
                          <p about="" id="contained-resource-metadata-inapplicable" rel="spec:advisement" resource="#contained-resource-metadata-inapplicable"><span property="spec:statement">The generation of contained resource metadata <span rel="spec:advisementLevel" resource="spec:Might">might</span> be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.</span></p>
                        </div>
                      </div>
                      <p>Contained resource metadata is <a href="#server-protect-contained-resource-metadata" rel="cito:discusses">protected by the server</a>.</p>
                      <p>[<a href="https://github.com/solid/specification/issues/227" rel="cito:citesAsSourceDocument">Source</a>]
                      [<a href="https://github.com/solid/specification/issues/343" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/352" rel="cito:citesAsSourceDocument">Source</a>]</p>
                    </div>
                  </section>
                </div>
              </section>
              <section id="auxiliary-resources" inlist="" rel="schema:hasPart" resource="#auxiliary-resources">
                <h3 property="schema:name">Auxiliary Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Solid has the notion of <em>auxiliary resources</em> to provide supplementary information such as descriptive metadata, authorization conditions, data shape constraints, digital rights or provenance record about a given resource (hereafter referred as the <em>subject resource</em>), and affects how resources and others associated with it are processed, served or interpreted.</p>
                  <p about="" id="server-auxiliary-resources-management" rel="spec:requirement" resource="#server-auxiliary-resources-management"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> support auxiliary resources defined by this specification and manage the association between a subject resource and auxiliary resources.</span> When a subject resource is deleted its auxiliary resources are also deleted by the server (<a href="#server-delete-remove-auxiliary-resource">Server Deleting Auxiliary Resources</a>).</p>
                  <p id="auxiliary-resources-rdf-document">Auxiliary resources are represented as <em>RDF document</em>s [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>]. HTTP interactions on auxiliary resources are subject to the requirements as per <cite><a href="#reading-writing-resources">Reading and Writing Resources</a></cite>.</p>
                  <div class="note" id="self-describing-resources" inlist="" rel="schema:hasPart" resource="#self-describing-resources">
                    <h4 property="schema:name"><span>Note</span>: Self-describing Resources</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="self-describing-subject-resource" rel="spec:advisement" resource="#self-describing-subject-resource"><span property="spec:statement">Where applicable, to promote <a href="https://www.w3.org/2001/tag/doc/selfDescribingDocuments">self-describing resources</a>, implementations and authors are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to use the subject resource instead of the associated auxiliary resource.</span></p>
                    </div>
                  </div>
                  <div class="note" id="uri-origin" inlist="" rel="schema:hasPart" resource="#uri-origin">
                    <h4 property="schema:name"><span>Note</span>: URI Origin</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>The resource and the associated auxiliary resource can be on different origins [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>].</p>
                    </div>
                  </div>
                  <p>This specification defines the following types of auxiliary resources:</p>
                  <ul>
                    <li><a href="#auxiliary-resources-web-access-control">Web Access Control</a></li>
                    <li><a href="#auxiliary-resources-description-resource">Description Resource</a></li>
                  </ul>
                  <p about="" id="server-link-auxiliary-type" rel="spec:requirement" resource="#server-link-auxiliary-type"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise auxiliary resources associated with a subject resource by responding to <code>HEAD</code> and <code>GET</code> requests by including the HTTP <code>Link</code> header field with the <code>rel</code> parameter [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></p>
                  <p about="" id="client-link-auxiliary-type" rel="spec:requirement" resource="#client-link-auxiliary-type">Clients can discover auxiliary resources associated with a subject resource by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header field with the <code>rel</code> parameter [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</p>
                  <table>
                    <thead>
                      <tr>
                        <th>Auxiliary Type</th>
                        <th>Link Relation</th>
                        <th>Definitions</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr>
                        <td><a href="#auxiliary-resources-web-access-control">Web Access Control</a></td>
                        <td><code>acl</code></td>
                        <td>[<cite><a class="bibref" href="#bib-wac">WAC</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><a href="#auxiliary-resources-description-resource">Description Resource</a></td>
                        <td><code>describedby</code></td>
                        <td>[<cite><a class="bibref" href="#bib-powder-dr">POWDER-DR</a></cite>]</td>
                      </tr>
                    </tbody>
                  </table>
                  <section id="auxiliary-resources-web-access-control" inlist="" rel="schema:hasPart" resource="#auxiliary-resources-web-access-control">
                    <h4 property="schema:name">Web Access Control</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>An auxiliary resource of type <em>Web Access Control</em> provides access control description of a subject resource (<a href="#web-access-control">Web Access Control</a>).</p>
                    </div>
                  </section>
                  <section id="auxiliary-resources-description-resource" inlist="" rel="schema:hasPart" resource="#auxiliary-resources-description-resource">
                    <h4 property="schema:name">Description Resource</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>An auxiliary resource of type <em>Description Resource</em> provides a description of a subject resource.</p>
                      <p about="" id="server-description-resource-max" rel="spec:requirement" resource="#server-description-resource-max"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> directly associate more than one description resource to a subject resource.</span></p>
                      <p about="" id="server-description-resource-authorization" rel="spec:requirement" resource="#server-description-resource-authorization"><span property="spec:statement">When an HTTP request targets a description resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> apply the authorization rule that is used for the subject resource with which the description resource is associated.</span></p>
                      <p about="" id="client-link-describes" rel="spec:requirement" resource="#client-link-describes">Clients can discover resources that are described by description resources by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header field with a <code>rel</code> value of <code>describes</code> (inverse of the <code>describedby</code> relation) [<cite><a class="bibref" href="#bib-rfc6892">RFC6892</a></cite>].</p>
                    </div>
                  </section>
                </div>
              </section>
            </div>
          </section>
          <section id="reading-writing-resources" inlist="" rel="schema:hasPart" resource="#reading-writing-resources">
            <h2 property="schema:name">Reading and Writing Resources</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p about="" id="server-method-not-allowed" rel="spec:requirement" resource="#server-method-not-allowed"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>405</code> status code to requests using HTTP methods that are not supported by the target resource.</span> [<a href="https://github.com/solid/specification/issues/117" rel="cito:citesAsSourceDocument">Source</a>]</p>
              <section id="resource-type-heuristics" inlist="" rel="schema:hasPart" resource="#resource-type-heuristics">
                <h3 property="schema:name">Resource Type Heuristics</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>When creating new resources, servers can determine a target URI’s type by examining the URI path ending (<a href="#uri-slash-semantics">URI Slash Semantics</a>).</p>
                  <p about="" id="server-post-uri-assignment" rel="spec:requirement" resource="#server-post-uri-assignment"><span property="spec:statement">When a successful <code>POST</code> request creates a resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> assign a URI to that resource.</span></p>
                  <div class="note" id="uri-allocation" inlist="" rel="schema:hasPart" resource="#uri-allocation">
                    <h4 property="schema:name"><span>Note</span>: URI Allocation</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="uri-allocation-put-patch" rel="spec:advisement" resource="#uri-allocation-put-patch"><span property="spec:statement">Clients <span rel="spec:advisementLevel" resource="spec:Can">can</span> use <code>PUT</code> and <code>PATCH</code> requests to assign a URI to a resource.</span></p>
                      <p about="" id="uri-allocation-post" rel="spec:advisement" resource="#uri-allocation-post"><span property="spec:statement">Clients <span rel="spec:advisementLevel" resource="spec:Can">can</span> use <code>POST</code> requests to have the server assign a URI to a resource.</span></p>
                    </div>
                  </div>
                  <p>[<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/pull/263" rel="cito:citesAsSourceDocument">Source</a>].</p>
                </div>
              </section>
              <section id="reading-resources" inlist="" rel="schema:hasPart" resource="#reading-resources">
                <h3 property="schema:name">Reading Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p about="" id="server-safe-methods" rel="spec:requirement" resource="#server-safe-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> support the HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> methods [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>] for clients to read resources or to determine communication options.</span> [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-allow-methods" rel="spec:requirement" resource="#server-allow-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate the HTTP methods supported by the target resource by generating an <code>Allow</code> header field in successful responses.</span></p>
                  <p about="" id="server-accept-headers" rel="spec:requirement" resource="#server-accept-headers"><span property="spec:statement">When responding to authorized requests, <span rel="spec:requirementSubject" resource="#Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate supported media types in the HTTP <code>Accept-Patch</code> [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>], <code>Accept-Post</code> [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] and <code>Accept-Put</code> [<cite><a href="#accept-put">The Accept-Put Response Header</a></cite>] response header fields that correspond to acceptable HTTP methods listed in <code>Allow</code> header field value in response to HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> requests.</span></p>
                  <p>[<a href="https://github.com/solid/specification/issues/85#issuecomment-575386251" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/43" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/378" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
              <section id="writing-resources" inlist="" rel="schema:hasPart" resource="#writing-resources">
                <h3 property="schema:name">Writing Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Servers MUST support the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-put-patch-intermediate-containers" rel="spec:requirement" resource="#server-put-patch-intermediate-containers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of <code>PUT</code> and <code>PATCH</code> requests.</span> [<a href="https://github.com/solid/specification/issues/68#issuecomment-561690124" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p><span about="" id="server-post-container" rel="spec:requirement" resource="#server-post-container"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> allow creation of new resources by a <code>POST</code> request to a URI path ending with <code>/</code>.</span></span> <span about="" id="server-post-container-create-resource" rel="spec:requirement" resource="#server-post-container-create-resource"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create resources with URI paths ending with <code>/{id}</code> in container <code>/</code>.</span></span> [<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/190" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-post-target-not-found" rel="spec:requirement" resource="#server-post-target-not-found"><span property="spec:statement">When a <code>POST</code> method request targets a resource without an existing representation, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>404</code> status code.</span> [<a href="https://github.com/solid/specification/issues/108#issuecomment-549448159" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-put-patch-auxiliary-resource" rel="spec:requirement" resource="#server-put-patch-auxiliary-resource"><span property="spec:statement">When a <code>PUT</code> or <code>PATCH</code> request targets an auxiliary resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create or update it.</span> [<a href="https://github.com/solid/specification/issues/42#issuecomment-616688848" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p><span about="" id="server-protect-containment" rel="spec:requirement" resource="#server-protect-containment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>PUT</code> or <code>PATCH</code> on a container to update its containment triples; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/40#issuecomment-573358652" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-protect-contained-resource-metadata" rel="spec:requirement" resource="#server-protect-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>POST</code>, <code>PUT</code> and <code>PATCH</code> to update a container’s <a href="#contained-resource-metadata-statements">resource metadata statements</a>; if the server receives such a request, it MUST respond with a <code>409</code> status code.</span> [<a href="https://github.com/solid/specification/issues/227#issuecomment-919312592" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <div class="note" id="conditional-update" inlist="" rel="schema:hasPart" resource="#conditional-update">
                    <h4 property="schema:name"><span>Note</span>: Conditional Update</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="resource-update-integrity" rel="spec:advisement" resource="#resource-update-integrity"><span property="spec:statement">Clients are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to use the HTTP <code>If-None-Match</code> header field with a value of <code>"*"</code> to prevent an unsafe request method, e.g., <code>PUT</code>, <code>PATCH</code>, from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation.</span> [<a href="https://github.com/solid/specification/issues/108#issuecomment-567272797" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/40#issuecomment-566995240" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/292" rel="cito:citesAsSourceDocument">Source</a>]</p>
                    </div>
                  </div>
                  <p about="" id="server-etag" rel="spec:requirement" resource="#server-etag"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> use the HTTP <code>ETag</code> header field with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the <code>If-Match</code> header field in their requests.</span></p>
                </div>
                <section id="n3-patch" inlist="" rel="schema:hasPart" resource="#n3-patch">
                  <h4 property="schema:name">Modifying Resources Using N3 Patches</h4>
                  <div datatype="rdf:HTML" property="schema:description">
                    <p><span about="" id="server-patch-n3-accept" rel="spec:requirement" resource="#server-patch-n3-accept"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept a <code>PATCH</code> request with an <em>N3 Patch</em> body when the target of the request is an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</span></span> <span about="" id="server-patch-n3-advertise" rel="spec:requirement" resource="#server-patch-n3-advertise"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate support of N3 Patch by listing <code>text/n3</code> as a field value of the <code>Accept-Patch</code> header field [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>] of relevant responses.</span></span> [<a href="https://github.com/solid/specification/issues/125#issuecomment-959518598" rel="cito:citesAsSourceDocument">Source</a>]</p>
                    <p>An <em>N3 Patch</em> is a document in the <em>Notation3 (N3)</em> format [<cite><a class="bibref" href="#bib-notation3">N3</a></cite>], identified by the media type <code>text/n3</code>, conforming to the following constraints:</p>
                    <ul>
                      <li id="server-patch-n3-patches" rel="spec:requirement" resource="#server-patch-n3-patches"><span property="spec:statement">A patch document <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain one or more patch resources.</span></li>
                      <li id="server-patch-n3-patch-identifier" rel="spec:requirement" resource="#server-patch-n3-patch-identifier"><span property="spec:statement">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be identified by a URI or blank node, which we refer to as <code>?patch</code> in the remainder of this section.</span></li>
                      <li id="server-patch-n3-type" rel="spec:requirement" resource="#server-patch-n3-type">A patch resource <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> contain a triple [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] <code><span property="spec:statement">?patch rdf:type solid:Patch</span></code>.</li>
                      <li id="server-patch-n3-deletes" rel="spec:requirement" resource="#server-patch-n3-deletes"><span property="spec:statement">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain at most one triple of the form <code>?patch solid:deletes ?deletions</code>.</span></li>
                      <li id="server-patch-n3-inserts" rel="spec:requirement" resource="#server-patch-n3-inserts">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain at most one triple of the form <code>?patch solid:inserts ?insertions</code>.</li>
                      <li id="server-patch-n3-where" rel="spec:requirement" resource="#server-patch-n3-where"><span property="spec:statement">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain at most one triple of the form <code>?patch solid:where ?conditions</code>.</span></li>
                      <li id="server-patch-n3-formulae" rel="spec:requirement" resource="#server-patch-n3-formulae"><span property="spec:statement">When present, <code>?deletions</code>, <code>?insertions</code>, and <code>?conditions</code> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be non-nested <em>cited formulae</em> [<cite><a class="bibref" href="#bib-notation3">N3</a></cite>] consisting only of triples and/or triple patterns [<cite><a class="bibref" href="#bib-sparql11-query">SPARQL11-QUERY</a></cite>]. When not present, they are presumed to be the empty formula <code>{}</code>.</span></li>
                    </ul>
                    <p id="server-patch-n3-default" rel="schema:hasPart" resource="#server-patch-n3-default"><span property="schema:description">While other specifications might provide a structure and interpretation for a wider class of N3 Patch documents, the present specification only governs the application of N3 Patch documents that additionally adhere to the following constraints:</span></p>
                    <ul about="#server-patch-n3-default">
                      <li id="server-patch-n3-single" rel="spec:requirement" resource="#server-patch-n3-single"><span property="spec:statement">The patch document <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain exactly one patch resource, identified by one or more of the triple patterns described above, which all share the same <code>?patch</code> subject.</span></li>
                      <li id="server-patch-n3-simple-type" rel="spec:requirement" resource="#server-patch-n3-type">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain a triple <code><span property="spec:statement">?patch rdf:type solid:InsertDeletePatch</span></code>.</li>
                      <li id="server-patch-n3-variables" rel="spec:requirement" resource="#server-patch-n3-variables"><span property="spec:statement">The <code>?insertions</code> and <code>?deletions</code> formulae <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> contain variables that do not occur in the <code>?conditions</code> formula.</span></li>
                      <li id="server-patch-n3-blank-nodes" rel="spec:requirement" resource="#server-patch-n3-blank-nodes"><span property="spec:statement">The <code>?deletions</code> formula <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> contain blank nodes.</span></li>
                      <li id="server-patch-n3-blank-nodes-syntax" rel="spec:requirement" resource="#server-patch-n3-blank-nodes-syntax"><span property="spec:statement">The same blank node identifier <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> be used in both the <code>?insertions</code> and the <code>?conditions</code> formulae within the same patch resource, nor in either of these formulae and elsewhere in the patch document.</span></li>
                    </ul>
                    <p about="" id="server-patch-n3-invalid" rel="spec:requirement" resource="#server-patch-n3-invalid"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <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>] if a patch document does not satisfy all of the above constraints.</span></p>
                    <p><span about="" id="server-n3-patch-where" rel="spec:requirement" resource="#server-n3-patch-where"><span property="spec:statement">When <code>?conditions</code> is non-empty, <span rel="spec:requirementSubject" resource="#Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> treat the request as a <a href="#read-operation">Read operation</a>.</span></span> <span about="" id="server-n3-patch-insert" rel="spec:requirement" resource="#server-n3-patch-insert"><span property="spec:statement">When <code>?insertions</code> is non-empty, <span rel="spec:requirementSubject" resource="#Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> (also) treat the request as an <a href="#append-operation">Append operation</a>.</span></span> <span about="" id="server-n3-patch-delete" rel="spec:requirement" resource="#server-n3-patch-delete"><span property="spec:statement">When <code>?deletions</code> is non-empty, <span rel="spec:requirementSubject" resource="#Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> treat the request as a <a href="#read-operation">Read</a> and <a href="#write-operation">Write operation</a>.</span></span></p>
                    <p about="" id="server-patch-n3-semantics" rel="spec:requirement" resource="#server-patch-n3-semantics"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> process a patch resource against the target document as follows:</span></p>
                    <ol about="#server-patch-n3-semantics" class="algorithm">
                      <li>Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.</li>
                      <li>If <code>?conditions</code> is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.</li>
                      <li>If no such mapping exists, or if multiple mappings exist, the <span id="server-patch-n3-semantics-no-mapping" rel="spec:requirement" resource="#server-patch-n3-semantics-no-mapping"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid-contrib/query-panel/issues/3" rel="cito:citesAsSourceDocument">Source</a>]</li>
                      <li>The resulting variable mapping is propagated to the <code>?deletions</code> and <code>?insertions</code> formulae to obtain two sets of resulting triples.</li>
                      <li>If the set of triples resulting from <code>?deletions</code> is non-empty and the dataset does not contain <em>all</em> of these triples, the <span id="server-patch-n3-semantics-deletions-non-empty-all-triples" rel="spec:requirement" resource="#server-patch-n3-semantics-deletions-non-empty-all-triples"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid-archive/query-panel/issues/3" rel="cito:citesAsSourceDocument">Source</a>]</li>
                      <li>The triples resulting from <code>?deletions</code> are to be removed from the RDF dataset.</li>
                      <li>The triples resulting from <code>?insertions</code> are to be added to the RDF dataset, with each blank node from <code>?insertions</code> resulting in a newly created blank node.</li>
                      <li>The combination of deletions followed by insertions then forms the new resource state of the RDF document, and the server responds with the appropriate status code.</li>
                    </ol>
                  </div>
                  <figure class="example listing" id="n3-patch-example" rel="schema:hasPart" resource="#n3-patch-example" typeof="schema:SoftwareSourceCode">
                    <figcaption property="schema:name"><span>Example</span>: <span>Applying an <span rel="schema:programmingLanguage" resource="http://www.wikidata.org/entity/Q1424987">N3</span> patch</span></figcaption>
                    <pre property="schema:description"><code>@prefix solid: &lt;http://www.w3.org/ns/solid/terms#&gt;.</code>
<code>@prefix ex: &lt;http://www.example.org/terms#&gt;.</code>
<code></code>
<code>_:rename a solid:InsertDeletePatch;</code>
<code>  solid:where   { ?person ex:familyName "Garcia". };</code>
<code>  solid:inserts { ?person ex:givenName "Alex". };</code>
<code>  solid:deletes { ?person ex:givenName "Claudia". }.</code></pre>
                    <p>This N3 Patch instructs to rename <em>Claudia Garcia</em> into <em>Alex Garcia</em>, on the condition that no other Garcia family members are present in the target RDF document.</p>
                  </figure>
                </section>
              </section>
              <section id="deleting-resources" inlist="" rel="schema:hasPart" resource="#deleting-resources">
                <h3 property="schema:name">Deleting Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Servers MUST support the HTTP <code>DELETE</code> method [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p><span about="" id="server-delete-protect-root-container" rel="spec:requirement" resource="#server-delete-protect-root-container"><span property="spec:statement">When a <code>DELETE</code> request targets storage’s root container or its associated ACL resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>405</code> status code.</span></span> <span about="" id="server-disallow-delete" rel="spec:requirement" resource="#server-disallow-delete"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> exclude the <code>DELETE</code> method in the field value of the <code>Allow</code> header field, in response to requests to these resources [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/37#issuecomment-627281466" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-delete-remove-containment" rel="spec:requirement" resource="#server-delete-remove-containment"><span property="spec:statement">When a contained resource is deleted, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also remove the corresponding containment triple.</span> [<a href="https://www.w3.org/TR/ldp/#ldpc-del-contremovesconttriple" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-delete-remove-auxiliary-resource" rel="spec:requirement" resource="#server-delete-remove-auxiliary-resource"><span property="spec:statement">When a contained resource is deleted, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also delete the associated auxiliary resources (see the <a href="#auxiliary-resources">Auxiliary Resources</a> section).</span></p>
                  <p><span about="" id="server-delete-remove-empty-container" rel="spec:requirement" resource="#server-delete-remove-empty-container"><span property="spec:statement">When a <code>DELETE</code> request targets a container, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> delete the container if it contains no resources.</span></span> <span about="" id="server-delete-protect-nonempty-container" rel="spec:requirement" resource="#server-delete-protect-nonempty-container"><span property="spec:statement">If the container contains resources, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>409</code> status code and response body describing the error.</span></span> [<a href="https://github.com/solid/specification/pull/187/files/b7426e95a1613e08195a853a4d0a403b7030f494#r447130915" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p><em>This section is non-normative.</em></p>
                  <p about="" id="server-delete-side-effects" rel="spec:advisement" resource="#server-delete-side-effects"><span property="spec:statement">The server might perform additional actions, as described in the normative references like [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>]. For example, the server <span rel="spec:advisementLevel" resource="spec:Could">could</span> perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.</span></p>
                  <p id="server-delete-get">Subsequent <code>GET</code> requests to the deleted resource usually result in a <code>404</code> or <code>410</code> status code, although HTTP allows others. [<a href="https://github.com/solid/specification/issues/72" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/46" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
              <section id="resource-representations" inlist="" rel="schema:hasPart" resource="#resource-representations">
                <h3 property="schema:name">Resource Representations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p about="" id="server-representation-turtle-jsonld" rel="spec:requirement" resource="#server-representation-turtle-jsonld"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> creates an <em>RDF source</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] on HTTP <code>PUT</code>, <code>POST</code>, or <code>PATCH</code> requests, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> satisfy <code>GET</code> requests on this resource when the field value of the <code>Accept</code> header field requests a representation in <code>text/turtle</code> or <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-turtle">Turtle</a></cite>] [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>].</span> [<a href="https://github.com/solid/specification/issues/45" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/69" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/109" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/195" rel="cito:citesAsSourceDocument">Source</a>]</p>
                  <p about="" id="server-representation-write-redirect" rel="spec:requirement" resource="#server-representation-write-redirect"><span property="spec:statement">When a <code>PUT</code>, <code>POST</code>, <code>PATCH</code> or <code>DELETE</code> method request targets a representation URL that is different than the resource URL, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>307</code> or <code>308</code> status code and <code>Location</code> header field specifying the preferred URI reference.</span> [<a href="https://github.com/solid/specification/issues/109" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
              <section id="constraints-problem-details" inlist="" rel="schema:hasPart" resource="#constraints-problem-details">
                <h3 property="schema:name">Constraints and Problem Details</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>
                  <p about="" id="server-resource-constraints-advertisement" rel="spec:advisement" resource="#server-resource-constraints-advertisement"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to publish any constraints on clients’ ability to create or update resources by adding a <code>Link</code> header field with an appropriate context URI, a link relation of <code>http://www.w3.org/ns/ldp#constrainedBy</code>, and a target URI identifying a set of constraints [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>], to responses to requests that fail due to violation of those constraints. The same <code>Link</code> header field can be provided in other responses.</span></p>
                  <p about="" id="server-resource-constraints-uri" rel="spec:advisement" resource="#server-resource-constraints-uri"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to use the URIs of the constraints that are defined by specifications or other constraint URIs within its authority depending on the request's semantics on a target resource.</span></p>
                  <p about="" id="server-resource-constraints-rdf" rel="spec:advisement" resource="#server-resource-constraints-rdf"><span property="spec:statement">Constraints are intended to be protected and persistent resources and therefore cannot be modified by clients. To facilitate better client interactions, it is <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to express constraints in RDF.</span></p>
                  <p>[<a href="https://github.com/solid/specification/pull/185" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
            </div>
          </section>
          <section id="linked-data-notifications" inlist="" rel="schema:hasPart" resource="#linked-data-notifications">
            <h2 property="schema:name">Linked Data Notifications</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p about="" id="server-ldn" rel="spec:requirement" resource="#server-ldn"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</span></p>
              <p about="" id="client-ldn" rel="spec:requirement" resource="#client-ldn"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="#Client">client</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</span></p>
            </div>
          </section>
          <section id="live-update" inlist="" rel="schema:hasPart" resource="#live-update">
            <h2 property="schema:name">Live Update</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="notifications-protocol" inlist="" rel="schema:hasPart" resource="#notifications-protocol">
                <h3 property="schema:name">Solid Notifications Protocol</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Entities in a Solid ecosystem use the <cite><a href="https://solidproject.org/TR/notifications-protocol">Solid Notifications Protocol</a></cite> to communicate about changes affecting a resource.</p>
                  <p about="" id="server-notifications-protocol-resource-server" rel="spec:requirement" resource="#server-notifications-protocol-resource-server"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the <cite><a href="https://solidproject.org/TR/notifications-protocol">Solid Notifications Protocol</a></cite> [<cite><a class="bibref" href="#bib-solid-notifications-protocol">SOLID-NOTIFICATIONS-PROTOCOL</a></cite>] by implementing the <cite><a href="https://solidproject.org/TR/2024/notifications-protocol-20240512#ResourceServer" rel="rdfs:seeAlso">Resource Server</a></cite> to enable clients to discover subscription resources and notification channels available to a given resource or storage.</span></p>
                  <p about="" id="server-notifications-protocol-subscription-server" rel="spec:requirement" resource="#server-notifications-protocol-subscription-server"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the <cite><a href="https://solidproject.org/TR/notifications-protocol">Solid Notifications Protocol</a></cite> [<cite><a class="bibref" href="#bib-solid-notifications-protocol">SOLID-NOTIFICATIONS-PROTOCOL</a></cite>] by implementing the <cite><a href="https://solidproject.org/TR/2024/notifications-protocol-20240512#SubscriptionServer" rel="rdfs:seeAlso">Subscription Server</a></cite> to process and produce instructions for subscription requests.</span></p>
                  <p about="" id="server-notifications-protocol-notification-sender" rel="spec:requirement" resource="#server-notifications-protocol-notification-sender"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the <cite><a href="https://solidproject.org/TR/notifications-protocol">Solid Notifications Protocol</a></cite> [<cite><a class="bibref" href="#bib-solid-notifications-protocol">SOLID-NOTIFICATIONS-PROTOCOL</a></cite>] by implementing the <cite><a href="https://solidproject.org/TR/2024/notifications-protocol-20240512#NotificationSender" rel="rdfs:seeAlso">Notification Sender</a></cite> to produce and send messages to a <cite><a href="https://solidproject.org/TR/2024/notifications-protocol-20240512#NotificationSender" rel="rdfs:seeAlso">Notification Receiver</a></cite>.</span></p>
                  <p about="" id="server-notifications-protocol-notification-receiver" rel="spec:requirement" resource="#server-notifications-protocol-notification-receiver"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the <cite><a href="https://solidproject.org/TR/notifications-protocol">Solid Notifications Protocol</a></cite> [<cite><a class="bibref" href="#bib-solid-notifications-protocol">SOLID-NOTIFICATIONS-PROTOCOL</a></cite>] by implementing the <cite><a href="https://solidproject.org/TR/2024/notifications-protocol-20240512#NotificationReceiver" rel="rdfs:seeAlso">Notification Receiver</a></cite> to receive and process messages that conform to a notification channel type.</span></p>
                  <p><em>The following is non-normative.</em></p>
                  <p>The <cite>Solid WebSockets API</cite> (Unofficial Draft) [<cite><a class="bibref" href="#bib-solid-websockets-api">SOLID-WEBSOCKETS-API</a></cite>] has been the common notification protocol for many years. That draft does not include an authentication mechanism, and therefore this Protocol has transitioned to require the <a href="https://solidproject.org/TR/notifications-protocol">Solid Notifications Protocol</a>.</p>
                  <p>Existing client and server implementations should begin providing support for the new notification protocol while supporting backwards compatibility, as appropriate.</p>
                </div>
              </section>
            </div>
          </section>
          <section id="cors" inlist="" rel="schema:hasPart" resource="#cors">
            <h2 property="schema:name">Cross-Origin Resource Sharing</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><a href="#solid-app">Solid apps</a> typically access data from multiple sources. However, Web browsers by default prevent apps that run on one origin from accessing data on other origins. This cross-origin protection is a security mechanism that ensures malicious websites cannot simply read your profile or banking details from other websites. However, this reasonable default poses a problem even for benevolent Solid apps, which might have good reasons to access data from different places. For instance, a Solid app at <code>https://app.example/</code> would be prevented from accessing data on <code>https://guinan.example/</code> or <code>https://darmok.example/</code>, even when Guinan and Darmok have given the user of the app their permission to see some of their data.</p>