-
Notifications
You must be signed in to change notification settings - Fork 14
/
index.html
1138 lines (1018 loc) · 105 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title>Linked Data Notifications</title>
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link href="https://dokie.li/media/css/basic.css" media="all" rel="stylesheet alternate" title="Basic" />
<link href="https://dokie.li/media/css/lncs.css" media="all" rel="stylesheet alternate" title="LNCS" />
<link href="https://dokie.li/media/css/acm.css" media="all" rel="stylesheet alternate" title="ACM" />
<link href="https://www.w3.org/StyleSheets/TR/2016/W3C-ED" media="all" rel="stylesheet" title="W3C-ED" />
<link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />
<style>
body {
counter-reset:section;
counter-reset:sub-section;
}
em.rfc2119 { color: #900; }
code { color: #c83500; }
pre code { color: #333; }
dfn { font-style:inherit; }
.do.fragment a { border-bottom:0; }
.do.fragment a:hover { background:none; border-bottom:0; }
section figure pre { margin:1em 0; display:block; }
cite .bibref { font-style: normal; }
.tabs nav ul li { margin:0; }
div.issue, div.note, div.warning {
clear: both;
margin: 1em 0;
padding: 1em 1.2em 0.5em;
position: relative;
}
div.issue h4, div.note h4 {
margin:0;
text-transform: uppercase;
font-weight:normal;
}
div.issue h4 {
color:#ae1e1e;
}
div.note h4 {
color:#22bb22;
}
figure .example-h {
margin-top:0;
text-align: left;
text-transform: uppercase;
color:#827017;
}
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"] {
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
-moz-border-right-colors: none;
-moz-border-top-colors: none;
background: #1a5e9a none repeat scroll 0 0;
border-color: #1a5e9a;
border-image: none;
border-radius: 0.4rem;
border-style: solid;
border-width: 0.65rem 0.7rem 0.6rem;
color: white;
display: block;
font-weight: bold;
}
main article > h1 {
font-size: 220%;
font-weight:bold;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id="exit-criteria"]) {
counter-increment:section;
counter-reset:sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$="references"]):not([id="exit-criteria"]) {
counter-increment:sub-section;
counter-reset:sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$="references"]):not([id="exit-criteria"]) section {
counter-increment:sub-sub-section;
counter-reset:sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$="references"]):not([id="exit-criteria"]) section section {
counter-increment:sub-sub-sub-section;
counter-reset:sub-sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id="exit-criteria"]):not([id^=table-of-]) > h2:before {
content:counter(section) ".\00a0\00a0\00a0\00a0";
}
section:not([id$="references"]):not([id^=change-log]):not([id="exit-criteria"]) > h3:before {
content:counter(section) "." counter(sub-section) "\00a0\00a0\00a0";
}
section > h4:before {
content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0\00a0\00a0";
}
aside.note.do blockquote dl.published,
aside.note.do blockquote dl.license,
aside.note.do blockquote dl.rights {
top:-2em;
left:4.5em;
}
#acknowledgements ul { padding: 0; margin:0 }
#acknowledgements li { display:inline; }
#acknowledgements li:after { content: ", "; }
#acknowledgements li:last-child:after { content: ""; }
</style>
<script src="https://dokie.li/scripts/dokieli.js"></script>
</head>
<body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ doap: http://usefulinc.com/ns/doap# deo: http://purl.org/spar/deo/ fabio: http://purl.org/spar/fabio/ as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# earl: http://www.w3.org/ns/earl#" typeof="schema:CreativeWork schema:Article sioc:Post prov:Entity as:Article doap:Specification">
<header>
<address>
<a class="logo" href="https://www.w3.org/"><img height="48" width="72" alt="W3C" src="https://www.w3.org/StyleSheets/TR/2016/logos/W3C"/></a>
</address>
</header>
<main>
<article about="" typeof="schema:Article doap:Specification">
<h1 property="schema:name">Linked Data Notifications</h1>
<dl id="document-identifier">
<dt>This version:</dt>
<dd><a href="https://linkedresearch.org/ldn/" rel="owl:sameAs doap:homepage">https://linkedresearch.org/ldn/</a></dd>
<dt>Latest published version:</dt>
<dd><a href="https://www.w3.org/TR/ldn/" rel="rdfs:seeAlso">https://www.w3.org/TR/ldn/</a></dd>
<dt>Previous version:</dt>
<dd><a href="https://www.w3.org/TR/2017/REC-ldn-20170502/">https://www.w3.org/TR/2017/REC-ldn-20170502/</a></dd>
</dl>
<div id="authors">
<dl id="author-name">
<dt>Editors</dt>
<dd id="Sarven-Capadisli" data-editor-id="46140"><span about="" rel="schema:creator schema:author"><span about="http://csarven.ca/#i" typeof="schema:Person"><a rel="schema:url" href="http://csarven.ca/"><span about="http://csarven.ca/#i" property="schema:name"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span></span>, <a about="http://csarven.ca/#i" href="http://uni-bonn.de/" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">University of Bonn</a>, <a about="http://csarven.ca/#i" href="mailto:[email protected]" rel="schema:email">[email protected]</a></dd>
<dd id="Amy-Guy" data-editor-id="69000"><span about="" rel="schema:creator schema:author"><span about="https://rhiaro.co.uk/#me" typeof="schema:Person"><a rel="schema:url" href="https://rhiaro.co.uk/"><span about="https://rhiaro.co.uk/#me" property="schema:name"><span property="schema:givenName">Amy</span> <span property="schema:familyName">Guy</span></span></a></span></span>, <a about="https://rhiaro.co.uk/#me" href="http://inf.ed.ac.uk/" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Edinburgh">University of Edinburgh</a>, <a about="https://rhiaro.co.uk/#me" href="mailto:[email protected]" rel="schema:email">[email protected]</a></dd>
</dl>
</div>
<dl id="document-inbox">
<dt>Notifications Inbox</dt>
<dd><a href="https://linkedresearch.org/inbox/linkedresearch.org/ldn/" rel="ldp:inbox">inbox/</a></dd>
</dl>
<dl id="document-annotation-service">
<dt>Annotation Service</dt>
<dd><a href="https://linkedresearch.org/annotation/linkedresearch.org/ldn/" rel="oa:annotationService">annotation/</a></dd>
</dl>
<dl id="document-published">
<dt>Published</dt>
<dd><time content="2016-06-14T00:00:00Z" datatype="xsd:dateTime" datetime="2016-06-14T00:00:00Z" property="schema:datePublished">2016-06-14</time></dd>
</dl>
<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2017-04-30T00:00:00Z" datatype="xsd:dateTime" datetime="2017-04-30T00:00:00Z" property="schema:dateModified">2017-04-30</time></dd>
</dl>
<dl id="document-repository">
<dt>Repository</dt>
<dd><a href="https://github.com/w3c/ldn" rel="doap:repository">GitHub</a></dd>
<dd><a href="https://github.com/w3c/ldn/issues" rel="doap:bug-database">Issues</a></dd>
</dl>
<dl id="document-implementation-reports">
<dt>Implementation reports</dt>
<dd><a href="https://linkedresearch.org/ldn/tests/summary" rel="rdfs:seeAlso">https://linkedresearch.org/ldn/tests/summary</a></dd>
</dl>
<dl id="document-test-suite">
<dt>Test suite</dt>
<dd><a href="https://linkedresearch.org/ldn/tests/" rel="rdfs:seeAlso">https://linkedresearch.org/ldn/tests/</a></dd>
</dl>
<dl>
<dt>In reply to</dt>
<dd><a href="https://www.w3.org/2013/socialweb/social-wg-charter" rel="as:inReplyTo">Social Web Working Group Charter</a></dd>
</dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2016 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>). <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a rel="license" href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
<div id="content">
<section id="abstract">
<h2>Abstract</h2>
<div datatype="rdf:HTML" property="schema:abstract">
<p>Linked Data Notifications is a protocol that describes how servers (receivers) can have messages pushed to them by applications (senders), as well as how other applications (consumers) may retrieve those messages. Any resource can advertise a receiving endpoint (Inbox) for the messages. Messages are expressed in RDF, and can contain any data.</p>
</div>
</section>
<section class="introductory" id="sotd" inlist="" rel="schema:hasPart" resource="#sotd">
<h2 property="schema:name">Status of This Document</h2>
<div property="schema:description" datatype="rdf:HTML">
<p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at https://www.w3.org/TR/.</em></p>
<p>This document was published by the <a href="https://www.w3.org/Social/WG">Social Web Working Group</a> as a Working Draft. This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:[email protected]">[email protected]</a> (<a href="mailto:[email protected]?subject=subscribe">subscribe</a>, <a href="https://lists.w3.org/Archives/Public/public-socialweb/">archives</a>). All comments are welcome.</p>
<p>Publication as a Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
<p>This document was produced by a group operating under the <a id="sotd_patent" property="w3p:patentRules" href="https://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>. <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="https://www.w3.org/2004/01/pp-impl/72531/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.</p>
<p>This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/2015/Process-20150901/">1 September 2015 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.</p>
</div>
</section>
<section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction">
<h2 about="#introduction" property="schema:name" typeof="deo:Introduction">Introduction</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>Data on the Web should not be locked in to particular systems or be only readable by the applications which created it. Users should be free to switch between applications and share data between them. Applications generate notifications about activities, interactions, and new information, which may be presented to the user or processed further.</p>
<p><dfn id="ldn">Linked Data Notifications (<abbr title="Linked Data Notifications">LDN</abbr>)</dfn> supports sharing and reuse of notifications <em>across</em> applications, regardless of how they were generated. This allows for more modular systems, which decouple data storage from the applications which display or otherwise make use of the data. The protocol is intended to allow senders, receivers and consumers of notifications, which are independently implemented and run on different technology stacks, to seamlessly work together, contributing to decentralisation of our interactions on the Web.</p>
<p>Instead of treating notifications as ephemeral or non-persistent entities, this specification enables the notion of a notification as an individual entity with its own URI. As such, notifications can be retrieved and reused. We support a range of different application domains, social and otherwise, thus the contents of notifications are left up to applications to define. Authentication and verification of notifications is encouraged, but the mechanism to do so is at the discretion of receivers and consumers, as needs differ according to types of notification and different application domains.</p>
<section id="social-web-working-group" inlist="" rel="schema:hasPart" resource="#social-web-working-group">
<h3 property="schema:name">Social Web Working Group</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><a href="#ldn"><abbr title="Linked Data Notifications">LDN</abbr></a> is one of several related specifications being produced by the Social Web Working Group. Implementers interested in alternative approaches and complimentary protocols should start by reading the overview document <a class="bibref" href="#bib-social-web-protocols">Social Web Protocols</a>. Specific subsections of Social Web Protocols are referenced throughout this specification to highlight points of extensibility or interoperability with other protocols.</p>
</div>
</section>
<section id="overview" inlist="" rel="schema:hasPart" resource="#overview">
<h3 property="schema:name">Overview</h3>
<div datatype="rdf:HTML" property="schema:description">
<figure id="figure-linked-data-notifications-overview" rel="schema:hasPart" resource="#figure-linked-data-notifications-overview">
<object data="linked-data-notifications-overview.svg" height="200" rel="schema:image" type="image/svg+xml" width="420"></object>
<figcaption property="schema:name">Overview of Linked Data Notifications</figcaption>
</figure>
<p>A sender is triggered, either by a human or an automatic process, to deliver a notification to a server. The notification is data intended for the attention of the receiver, for example: a personal message from a friend; a pingback link; a comment on a blog post; an invitation to collaborate; a calendar reminder; a scientific observation.</p>
<p>The sender chooses a target resource to send notifications to; the sender then discovers the location of the target’s <em>Inbox</em>, and sends the notification there. Any resource can advertise an Inbox. The receiver exposes the notification data (according to appropriate access control) for use by consumers.</p>
<p>Consumers discover the location of the Inbox in the same way as the sender, and may perform further processing on the notifications, combine it with some other data, or simply present it in a suitable human-readable way.</p>
</div>
</section>
<section id="summary" inlist="" rel="schema:hasPart" resource="#summary">
<h3 property="schema:name">Summary</h3>
<div datatype="rdf:HTML" property="schema:description">
<p id="summary-discovery">Senders and consumers <strong><a href="#discovery">discover</a></strong> a resource’s <em>Inbox</em> URL through a relation in the HTTP <code>Link</code> header or body of the resource.</p>
<p id="summary-sender">The <strong><a href="#sender">Sender</a></strong>:</p>
<ul about="#sender" property="skos:definition">
<li>Creates the body of the notification according to the needs of application.</li>
<li>Sends the notification to the Inbox URL by making a <code>POST</code> request, containing the body in JSON-LD or in another serialization acceptable by the server.</li>
</ul>
<p id="summary-receiver">The <strong><a href="#receiver">Receiver</a></strong>:</p>
<ul about="#receiver" property="skos:definition">
<li>Responds to <code>GET</code> requests made to the Inbox URL with a listing of the URLs of notifications that have previously been accepted.</li>
<li>Responds to <code>GET</code> requests made to the individual notification URLs with JSON-LD (or optionally other serializations).</li>
<li>Accepts <code>POST</code> requests at the Inbox URL to create notifications.</li>
<li>Optionally enforces constraints on notifications sent to the Inbox.</li>
</ul>
<p id="summary-consumer">The <strong><a href="#consumer">Consumer</a></strong>:</p>
<ul about="#consumer" property="skos:definition">
<li>Retrieves the contents of the Inbox URL with a <code>GET</code> request, and uses according to the needs of application.</li>
</ul>
</div>
</section>
<section id="relation-to-ldp" inlist="" rel="schema:hasPart" resource="#relation-to-ldp">
<h3 property="schema:name">Relation to Linked Data Platform</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><abbr title="Linked Data Notifications">LDN</abbr> is a specialized use of Linked Data Platform [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] for sending and consuming notifications. It is not dependent on a complete implementation of LDP, but an easy-to-implement subset. Having knowledge of LDP is not required to understand this specification, but those who do will find some concepts familiar. We describe the particular features necessary to make it easy to exchange notifications in a decentralised, interoperable way. An LDN Inbox is comparable to an LDP <code>BasicContainer</code>.</p>
</div>
</section>
</div>
</section>
<section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance">
<h2 property="schema:name">Conformance</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>The key words "<em class="rfc2119">MUST</em>", "<em class="rfc2119">MUST NOT</em>", "<em class="rfc2119">REQUIRED</em>", "<em class="rfc2119">SHALL</em>", "<em class="rfc2119">SHALL NOT</em>", "<em class="rfc2119">SHOULD</em>", "<em class="rfc2119">SHOULD NOT</em>", "<em class="rfc2119">RECOMMENDED</em>", "<em class="rfc2119">MAY</em>", and "<em class="rfc2119">OPTIONAL</em>" in this document are to be interpreted as described in [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>]. As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative.</p>
<section id="conformance-classes" inlist="" rel="schema:hasPart" resource="#conformance-classes">
<h3 property="schema:name">Conformance Classes</h3>
<div datatype="rdf:HTML" property="schema:description">
<p about="" rel="schema:hasPart"><span about="#ldn-implementations" datatype="rdf:HTML" id="ldn-implementations" property="skos:definition" typeof="skos:ConceptScheme"><span property="skos:prefLabel">LDN implementations</span> may be <em rel="skos:hasTopConcept" resource="#senders">senders</em>, <em rel="skos:hasTopConcept" resource="#receivers">receivers</em> or <em rel="skos:hasTopConcept" resource="#consumers">consumers</em>. The conformance criteria for each of these roles are described in their respective sections of this specification.</span></p>
<span about="" rel="schema:hasPart">
<span about="#data-structure-definition" typeof="qb:DataStructureDefinition">
<span rel="qb:component" resource="#component-dimension-subject" typeof="qb:ComponentSpecification"><span rel="qb:componentProperty qb:dimension" resource="earl:subject" typeof="qb:DimensionProperty"><span property="skos:prefLabel" content="Subject"></span></span></span>
<span rel="qb:component" resource="#component-dimension-test" typeof="qb:ComponentSpecification"><span rel="qb:componentProperty qb:dimension" resource="earl:test" typeof="qb:DimensionProperty"><span property="skos:prefLabel" content="Test"></span></span></span>
<span rel="qb:component" resource="#component-dimension-mode" typeof="qb:ComponentSpecification"><span rel="qb:componentProperty qb:dimension" resource="earl:mode" typeof="qb:DimensionProperty"><span property="skos:prefLabel" content="Mode"></span></span></span>
<span rel="qb:component" resource="#component-measure-result" typeof="qb:ComponentSpecification"><span rel="qb:componentProperty qb:measure" resource="earl:result" typeof="qb:MeasureProperty"><span property="skos:prefLabel" content="Result"></span></span></span>
</span>
</span>
</div>
<span about="" rel="schema:hasPart">
<span about="#ldn-tests-sender" property="skos:prefLabel" content="LDN Tests Sender" typeof="skos:ConceptScheme">
<span property="skos:hasTopConcept" resource="#test-sender-header-discovery"></span>
<span property="skos:hasTopConcept" resource="#test-sender-body-discovery"></span>
<span property="skos:hasTopConcept" resource="#test-sender-header-post-request"></span>
<span property="skos:hasTopConcept" resource="#test-sender-body-post-request"></span>
<span property="skos:hasTopConcept" resource="#test-sender-header-post-content-type-json-ld"></span>
<span property="skos:hasTopConcept" resource="#test-sender-body-post-content-type-json-ld"></span>
<span property="skos:hasTopConcept" resource="#test-sender-header-post-valid-json-ld"></span>
<span property="skos:hasTopConcept" resource="#test-sender-body-post-valid-json-ld"></span>
</span>
<span about="#ldn-tests-receiver" property="skos:prefLabel" content="LDN Tests Receiver" typeof="skos:ConceptScheme">
<span property="skos:hasTopConcept" resource="#test-receiver-get-response"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-get-ldp-contains"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-get-ldp-container"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-get-ldp-constrained-by"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-get-notifications-json-ld"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-get-notifications-limited"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-get-notifications-rdf-source"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-options-accept-post-contains-json-ld"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-options-accept-post"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-options-response"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-post-response"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-post-created"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-post-location"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-post-link-profile"></span>
<span property="skos:hasTopConcept" resource="#test-receiver-post-response-contraints-unmet"></span>
</span>
<span about="#ldn-tests-consumer" property="skos:prefLabel" content="LDN Tests Consumer" typeof="skos:ConceptScheme">
<span property="skos:hasTopConcept" resource="#test-consumer-header-discovery"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-body-discovery"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-listing-json-ld-compacted"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-listing-json-ld-expanded"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-notification-announce"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-notification-changelog"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-notification-citation"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-notification-assessing"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-notification-comment"></span>
<span property="skos:hasTopConcept" resource="#test-consumer-notification-rsvp"></span>
</span>
</span>
</section>
</div>
</section>
<section id="protocol" inlist="" rel="schema:hasPart" resource="#protocol">
<h2 property="schema:name">Protocol</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This section describes the discovery of the URL to which notifications are delivered or read from (the <em>Inbox</em>) and the delivery mechanism. Notification contents are described in <a href="#payload">Payload</a>.</p>
<section id="discovery" inlist="" rel="schema:hasPart" resource="#discovery">
<h3 property="schema:name">Discovery</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>An <em>Inbox</em>, the endpoint to which notifications are sent or from which they are consumed, can be discovered from any resource, for example a blog post, a user profile, a dataset, a video. The starting point for discovery is the resource which the notification is to or about: the <em>target</em>. Choosing the most appropriate target resource from which to begin discovery is at the discretion of the sender or consumer, since any resource (RDF or non-RDF) may have its own Inbox.</p>
<p>Senders and consumers do the following to discover the Inbox URL:</p>
<ul>
<li about="#test-sender-header-discovery" id="test-sender-header-discovery" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept"><span about="#test-consumer-header-discovery" id="test-consumer-header-discovery" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">make an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and use the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</span></li>
<li about="#test-sender-body-discovery" id="test-sender-body-discovery" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept"><span about="#test-consumer-body-discovery" id="test-consumer-body-discovery" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">make an HTTP <code>GET</code> request on the target URL to retrieve an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF 1.1</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/ldp#inbox</code>. The subject of that relation is target and the object is the Inbox.</span></li>
</ul>
<p>These may be carried out in either order, but if the first fails to result in an Inbox the second <em class="rfc2119">MUST</em> be tried. Senders and consumers <em class="rfc2119">SHOULD</em> omit the <code>Link</code> header discovery when specifically targeting URIs with fragment identifiers.</p>
<div class="note" id="note-fragments" rel="schema:hasPart" resource="#note-fragments">
<h4 property="schema:name">Note</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>If the target contains a fragment identifier, the fragment is not part of the request to the server. Senders and consumers should be aware that any Inbox found in the <code>Link</code> header will be for the resolved URL, <em>without</em> the fragment. See [<cite><a class="bibref" href="#bib-cooluris">Cool URIs for the Semantic Web</a> - Hash URIs</cite>].</p>
</div>
</div>
<p>A resource <em class="rfc2119">MUST</em> advertise only one Inbox. One Inbox <em class="rfc2119">MAY</em> be used by multiple resources, for example using the same Inbox for replies to all of my blog posts and shares of all of my photos.</p>
<figure class="listing example" id="discovery-head-example" rel="schema:hasPart" resource="#discovery-head-example">
<p class="example-h">Discovery example 1: Link header</p>
<pre about="#discovery-head-example" property="schema:description" typeof="fabio:Script"><code>HEAD /article HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Link: <http://example.org/inbox/>; rel="http://www.w3.org/ns/ldp#inbox"</code></pre>
<figcaption>Request and response when discovering an Inbox with a <code>HEAD</code> request, and receiving a <code>Link</code> header.</figcaption>
</figure>
<figure class="listing example" id="discovery-json-example-compact" rel="schema:hasPart" resource="#discovery-json-example-compact">
<p class="example-h">Discovery example 2: JSON-LD</p>
<pre about="#discovery-json-example-compact" property="schema:description" typeof="fabio:Script"><code>GET /profile HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json</code>
<code></code>
<code>{</code>
<code> "@context": "http://www.w3.org/ns/ldp",</code>
<code> "@id": "http://example.org/profile",</code>
<code> "inbox": "http://example.org/inbox/"</code>
<code>}</code></pre>
<figcaption>Discovering an Inbox with a <code>GET</code> request to retrieve JSON-LD. Response in JSON-LD compact form.</figcaption>
</figure>
<figure class="listing example" id="discovery-html-example-a" rel="schema:hasPart" resource="#discovery-html-example-a">
<p class="example-h">Discovery example 3: Visible HTML</p>
<pre about="#discovery-html-example-a" property="schema:description" typeof="fabio:Script"><code>GET /event HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: text/html, application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: text/html;charset=utf-8</code>
<code></code>
<code><p about="http://example.org/event" typeof="http://schema.org/Event" lang="en"></code>
<code> <a rel="http://www.w3.org/ns/ldp#inbox" href="/inbox/">RSVP</a> to event</code>
<code></p></code></pre>
<figcaption>Discovering an Inbox with a <code>GET</code> request to retrieve HTML. The Inbox link is visible to humans, and marked up with RDFa so the Inbox URL can be discovered by machines.</figcaption>
</figure>
<figure class="listing example" id="discovery-html-example-link" rel="schema:hasPart" resource="#discovery-html-example-link">
<p class="example-h">Discovery example 4: Invisible HTML</p>
<pre about="#discovery-html-example-link" property="schema:description" typeof="fabio:Script"><code>GET /article HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: text/html, application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: text/html;charset=utf-8</code>
<code></code>
<code><link href="/inbox/" rel="http://www.w3.org/ns/ldp#inbox" /></code></pre>
<figcaption>Discovering an Inbox with a <code>GET</code> request to retrieve HTML. An invisible Inbox expressed with a <code>link</code> element, marked up with RDFa for machine discovery.</figcaption>
</figure>
<figure class="listing example" id="discovery-html-example-section" rel="schema:hasPart" resource="#discovery-html-example-section">
<p class="example-h">Discovery example 5: Invisible HTML</p>
<pre about="#discovery-html-example-section" property="schema:description" typeof="fabio:Script"><code>GET /article HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: text/html, application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: text/html;charset=utf-8</code>
<code></code>
<code><section id="results" about="#results"</code>
<code> property="http://www.w3.org/ns/ldp#inbox" resource="/inbox/"></code>
<code></section></code></pre>
<figcaption>Discovering an Inbox with a <code>GET</code> request to retrieve HTML. An invisible Inbox expressed with the RDFa <code>property</code> attribute, so that a resource identified with a fragment URI may be the target.</figcaption>
</figure>
<figure class="listing example" id="discovery-turtle-example-webid" rel="schema:hasPart" resource="#discovery-turtle-example-webid">
<p class="example-h">Discovery example 6: Turtle</p>
<pre about="#discovery-turtle-example-webid" property="schema:description" typeof="fabio:Script"><code>GET / HTTP/1.1</code>
<code>Host: csarven.ca</code>
<code>Accept: text/turtle, application/ld+json</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: text/turtle;charset=utf-8</code>
<code></code>
<code><http://csarven.ca/#i></code>
<code> <http://www.w3.org/ns/ldp#inbox> <http://csarven.ca/inbox/> .</code></pre>
<figcaption>Discovering an Inbox with a <code>GET</code> request to retrieve Turtle.</figcaption>
</figure>
<p>Please see <a href="https://www.w3.org/TR/social-web-protocols/#targeting-and-discovery">Social Web Protocols</a> for recommendations on how to carry out discovery, particularly with consideration to servers which may be unaware of this protocol.</p>
</div>
</section>
<section id="sender" inlist="" rel="schema:hasPart" resource="#sender">
<h3 property="schema:name skos:prefLabel" rel="skos:topConceptOf" resource="#ldn-implementations">Sender</h3>
<div datatype="rdf:HTML" property="schema:description" resource="#sender" typeof="skos:Concept">
<p>Following <a href="#discovery">discovery</a>, <span about="#test-sender-header-post-request" id="test-sender-header-post-request" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept"><span about="#test-sender-body-post-request" id="test-sender-body-post-request" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept">senders who want to send notifications <em class="rfc2119">MUST</em> deliver them through a <code>POST</code> request to the Inbox URL</span></span>. Senders can expect a <code>201 Created</code> (with a <code>Location</code> Link header) or a <code>202 Accepted</code> in response to a successful request.</p>
<p>The sender <em class="rfc2119">MAY</em> use an <code>OPTIONS</code> request to determine the RDF content types accepted by the server, and serialize the notification in the request body according to the value of the <code>Accept-Post</code> header [<cite><a class="bibref" href="#bib-accept-post">Accept-Post</a></cite>] returned. Otherwise, <span about="#test-sender-header-post-content-type-json-ld" id="test-sender-header-post-content-type-json-ld" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept"><span about="#test-sender-body-post-content-type-json-ld" id="test-sender-body-content-type-json-ld" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept"><span about="#test-sender-header-post-valid-json-ld" id="test-sender-header-post-valid-json-ld" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept"><span about="#test-sender-body-post-valid-json-ld" id="test-sender-body-post-valid-json-ld" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-sender" typeof="skos:Concept">the body of the <code>POST</code> request <em class="rfc2119">MUST</em> contain the notification <a href="#payload">payload</a> in JSON-LD</span></span> with header <code>Content-Type: application/ld+json</code></span></span>. The <code>Content-Type</code> header <em class="rfc2119">MAY</em> include a <code>profile</code> URI [<cite><a class="bibref" href="#bib-rfc6906">RFC6906</a></cite>].</p>
<p>The sender <em class="rfc2119">MAY</em> include additional headers or content for the purposes of authentication or authorization e.g., <code>Authorization: Bearer XXX</code>.</p>
<p>If the sender has any services that listen on localhost that do not require authentication, it’s possible for a malicious script to run at the Inbox endpoint that could cause the sender to make an arbitrary <code>POST</code> request to itself. Senders <em class="rfc2119">SHOULD NOT</em> make <code>POST</code> requests to the Inbox that are localhost or a loopback IP address.</p>
<figure class="listing example" id="sending-notification-request" rel="schema:hasPart" resource="#sending-notification-request">
<p class="example-h">Sending example request</p>
<pre about="#sending-notification-request" property="schema:description" typeof="fabio:Script"><code>POST /inbox/ HTTP/1.1</code>
<code>Host: example.org</code>
<code>Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"</code>
<code>Content-Language: en</code>
<code></code>
<code>{</code>
<code> "@context": "https://www.w3.org/ns/activitystreams",</code>
<code> "@id": "",</code>
<code> "@type": "Announce",</code>
<code> "actor": "https://rhiaro.co.uk/#me",</code>
<code> "object": "http://example.net/note",</code>
<code> "target": "http://example.org/article",</code>
<code> "updated": "2016-06-28T19:56:20.114Z"</code>
<code>}</code></pre>
<figcaption property="schema:name">Example request to send to an Inbox.</figcaption>
</figure>
<figure class="listing example" id="sending-notification-response" rel="schema:hasPart" resource="#sending-notification-response">
<p class="example-h">Sending example response</p>
<pre about="#sending-notification-response" property="schema:description" typeof="fabio:Script"><code>HTTP/1.1 201 Created</code>
<code>Location: http://example.org/inbox/5c6ca040</code></pre>
<figcaption property="schema:name">Example response to a <code>POST</code> request on an Inbox.</figcaption>
</figure>
</div>
</section>
<section id="receiver" inlist="" rel="schema:hasPart" resource="#receiver">
<h3 property="schema:name skos:prefLabel" rel="skos:topConceptOf" resource="#ldn-implementations">Receiver</h3>
<div datatype="rdf:HTML" property="schema:description" resource="#receiver" typeof="skos:Concept">
<p><span about="#test-receiver-post-response" id="test-receiver-post-response" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept"><span about="#test-receiver-get-response" id="test-receiver-get-response" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Receivers <em class="rfc2119">MUST</em> support <code>GET</code> and <code>POST</code> requests on the Inbox URL.</span></span> <span about="#test-receiver-get-ldp-container" id="test-receiver-get-ldp-container" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">In LDP terms, an Inbox is a <em>Container</em>.</span></p>
<section id="receiving-notifications" inlist="" rel="schema:hasPart" resource="#receiving-notifications">
<h4 property="schema:name">Receiving notifications</h4>
<div datatype="rdf:HTML" property="schema:description">
<p about="#test-receiver-post-created" id="test-receiver-post-created" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept"><span about="#test-receiver-post-location" id="test-receiver-post-location" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Upon receipt of a <code>POST</code> request, if the notification resource was processed successfully, receivers <em class="rfc2119">MUST</em> respond with status code <code>201 Created</code> and the <code>Location</code> header set to the URL from which the notification data can be retrieved (see <a href="#consumer">Consumer</a>). If the request was queued to be processed asynchronously, the receiver <em class="rfc2119">MUST</em> respond with a status code of <code>202 Accepted</code> and include information about the status of the request in the body of the response.</span></p>
<p about="#test-receiver-post-response-contraints-unmet" id="test-receiver-post-response-contraints-unmet" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Receivers which enforce constraints on the notifications (see <a href="#constraints">Constraints</a>) <em class="rfc2119">SHOULD</em> fail to process the notification if the constraints are not met and return the appropriate <code>4xx</code> error code.</p>
<p about="#test-receiver-post-link-profile" id="test-receiver-post-link-profile" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Receivers <em class="rfc2119">MUST</em> accept notifications where the request body is JSON-LD, with the <code>Content-Type: application/ld+json</code>, which <em class="rfc2119">MAY</em> include a <code>profile</code> URI [<cite><a class="bibref" href="#bib-rfc6906">RFC6906</a></cite>].</p>
<p about="#test-receiver-options-response" id="test-receiver-options-response" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept"><span about="#test-receiver-options-accept-post" id="test-receiver-options-accept-post-accept-post" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept"><span about="#test-receiver-options-accept-post-contains-json-ld" id="test-receiver-options-accept-post-accept-post-contains-json-ld" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Receivers <em class="rfc2119">MAY</em> accept other RDF content types (e.g., <code>text/turtle</code>, <code>text/html</code>), and if so, <em class="rfc2119">SHOULD</em> advertise the content types they accept with an <code>Accept-Post</code> [<cite><a class="bibref" href="#bib-accept-post">Accept-Post</a></cite>] header in response to an <code>OPTIONS</code> request on the Inbox URL.</span></span></p>
<figure class="listing example" id="receiver-options-example" rel="schema:hasPart" resource="#receiver-options-example">
<p class="example-h">Receiver example 1: options response</p>
<pre about="#receiver-options-example" property="schema:description" typeof="fabio:Script"><code>OPTIONS /inbox/ HTTP/1.1</code>
<code>Host: example.org</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Allow: GET, HEAD, OPTIONS, POST</code>
<code>Accept-Post: application/ld+json, text/turtle</code></pre>
<figcaption property="schema:name">Receiver responding to an <code>OPTIONS</code> request with <code>Accept-Post</code>.</figcaption>
</figure>
<figure class="listing example" id="receiver-post-example" rel="schema:hasPart" resource="#receiver-post-example">
<p class="example-h">Receiver example 2: post response</p>
<pre about="#receiver-post-example" property="schema:description" typeof="fabio:Script">
<code>POST /inbox/ HTTP/1.1</code>
<code>Host: example.org</code>
<code>Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"</code>
<code>Content-Language: en</code>
<code></code>
<code>{</code>
<code> "@context": "https://www.w3.org/ns/activitystreams",</code>
<code> "@id": "",</code>
<code> "@type": "Announce",</code>
<code> "actor": "https://rhiaro.co.uk/#me",</code>
<code> "object": "http://example.net/note",</code>
<code> "target": "http://example.org/article",</code>
<code> "updated": "2016-06-28T19:56:20.114Z"</code>
<code>}</code>
<code></code>
<code>HTTP/1.1 201 Created</code>
<code>Location: http://example.org/inbox/92d72f00</code></pre>
<figcaption property="schema:name">Receiver responding to a <code>POST</code> request on the Inbox by creating a notification.</figcaption>
</figure>
</div>
</section>
<section id="receiving-inbox-contents" inlist="" rel="schema:hasPart" resource="#receiving-inbox-contents">
<h4 property="schema:name">Making Inbox contents available to consumers</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>A successful <code>GET</code> request on the Inbox <em class="rfc2119">MUST</em> return a <code>HTTP 200 OK</code> with the URIs of notifications, subject to the requester’s access (returning <code>4xx</code> error codes as applicable). <span about="#test-receiver-get-notifications-limited" id="test-receiver-get-notifications-limited" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Receivers <em class="rfc2119">MAY</em> list only URIs of notifications in the Inbox that the consumer is able to access.</span> <span about="#test-receiver-get-ldp-contains" id="test-receiver-get-ldp-contains" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">The Inbox URL <em class="rfc2119">MUST</em> use the <code>http://www.w3.org/ns/ldp#contains</code> predicate to refer to the notifications.</span></p>
<p>Each notification <em class="rfc2119">MUST</em> be an <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF source</a>. If non-RDF resources are returned, the consumer <em class="rfc2119">MAY</em> ignore them. A successful <code>GET</code> request on the notification URI <em class="rfc2119">MUST</em> return a <code>HTTP 200 OK</code> subject to the requester’s access (returning <code>4xx</code> error codes as applicable).</p>
<p><span about="#test-receiver-get-notifications-json-ld" id="test-receiver-get-notifications-json-ld" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">The JSON-LD content type <em class="rfc2119">MUST</em> be available for all resources, but clients may send <code>Accept</code> headers preferring other content types (<a href="#bib-rdfc7231">RFC7231</a> Section 3.4 - Content Negotiation).</span> <span about="#test-receiver-get-notifications-rdf-source" id="test-receiver-get-notifications-rdf-source" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">If the client sends no <code>Accept</code> header, the server may send the data in JSON-LD or any format which faithfully conveys the same information (e.g., Turtle).</span></p>
<p about="#test-receiver-get-ldp-constrained-by" id="test-receiver-get-ldp-constrained-by" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-receiver" typeof="skos:Concept">Any additional description about the Inbox itself <em class="rfc2119">MAY</em> also be returned (e.g., <a href="#constraints">Constraints</a>).</p>
<div class="note" id="note-paging" rel="schema:hasPart" resource="#note-paging">
<h4 property="schema:name">Note</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>This specification does not define a paging mechanism to serve the list of notifications in an Inbox. Implementations that wish to enable paging may want to use existing mechanisms to allow efficient retrievals e.g., <cite><a class="bibref" href="#bib-ldp-paging">Linked Data Platform Paging 1.0</a></cite>, <cite><a class="bibref" href="#bib-activitystreams-core">Activity Streams 2.0 Collection</a></cite>.</p>
</div>
</div>
<figure class="listing example" id="get-inbox-response" rel="schema:hasPart" resource="#get-inbox-response">
<p class="example-h">Receiver example 3: get response</p>
<pre about="#get-inbox-response" property="schema:description" typeof="fabio:Script"><code>GET /inbox/ HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: application/ld+json</code>
<code>Accept-Language: en-GB,en;q=0.8, en-US;q=0.6</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json</code>
<code>Content-Language: en</code>
<code></code>
<code>{</code>
<code> "@context": "http://www.w3.org/ns/ldp",</code>
<code> "@id": "http://example.org/inbox/",</code>
<code> "contains": [</code>
<code> "http://example.org/inbox/5c6ca040",</code>
<code> "http://example.org/inbox/92d72f00"</code>
<code> ]</code>
<code>}</code></pre>
<figcaption>Receiver responding to a <code>GET</code> request on the Inbox with a listing of notifications.</figcaption>
</figure>
</div>
</section>
<section id="sender-verification" inlist="" rel="schema:hasPart" resource="#sender-verification">
<h4 property="schema:name">Sender Verification</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Receivers <em class="rfc2119">SHOULD</em> verify the sender of the notification. For example:</p>
<ul>
<li>by having a whitelist of senders with write access to the Inbox</li>
<li>requiring authentication to enforce receiver’s knowledge of every sender</li>
<li>retrieving a copy of the notification from the sender’s domain to verify its origin</li>
<li>checking a digital signature which accompanies the notification</li>
</ul>
</div>
</section>
<section id="preventing-abuse" inlist="" rel="schema:hasPart" resource="#preventing-abuse">
<h4 property="schema:name">Preventing Abuse</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Receivers <em class="rfc2119">SHOULD</em> use <a href="#constraints">constraints</a> to filter unwarranted notifications from being created on the server and exposed by the Inbox.</p>
<p>Receivers could consider implementing access control on the Inbox URL to restrict writing to a whitelist of trusted senders.</p>
</div>
</section>
</div>
</section>
<section id="consumer" inlist="" rel="schema:hasPart" resource="#consumer">
<h3 property="schema:name skos:prefLabel" rel="skos:topConceptOf" resource="#ldn-implementations">Consumer</h3>
<div datatype="rdf:HTML" property="schema:description" resource="#consumer" typeof="skos:Concept">
<p>Consumers retrieve the URIs of notifications in an Inbox through making a <code>GET</code> request on the Inbox URL (to find this URL, see <a href="#discovery">discovery</a>).</p>
<p about="#test-consumer-listing-json-ld-compacted" id="test-consumer-listing-json-ld-compacted" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept"><span about="#test-consumer-listing-json-ld-expanded" id="test-consumer-listing-json-ld-expanded" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">The URIs of the notifications <em class="rfc2119">MUST</em> be discoverable through the <code>http://www.w3.org/ns/ldp#contains</code> predicate of the Inbox URL (see <a href="#get-inbox-response">example</a> for Inbox content).</span></p>
<p>When retrieving the Inbox or the individual notifications, the consumer <em class="rfc2119">SHOULD</em> explicitly set the <code>Accept</code> header to indicate preferred content types, including for JSON-LD. Fetching the individual notifications — if any, how many, or according to a particular criteria (e.g., content-length, timestamp) — is at the discretion of the consumer.</p>
<p>The consumer <em class="rfc2119">MAY</em> include additional headers or content for the purposes of authentication or authorization.</p>
<p>Consumers <em class="rfc2119">MAY</em> perform additional fetching or inferring of information from the payload (e.g., dereferencing resources referenced in the notification to fetch their contents) at their discretion. Consumers <em class="rfc2119">MAY</em> also want to check the notifications against any constraints as announced by an Inbox before further processing or use.</p>
<div class="note" id="note-request-uri-and-relative-id" rel="schema:hasPart" resource="#note-request-uri-and-body-and-relative-id">
<h4 property="schema:name">Note</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>The fetched URI for a notification <em>may</em> contain RDF statements with one or more subject IRIs <em>different</em> from the requested URI itself. Consumers should also not assume that the notification contains <em>any</em> triples with the requested URI as the subject. This is also pertinent when the body of the notification uses relative IRIs. Implementations may wish to treat notification URIs as graphs which contain the RDF from the notification payload.</p>
</div>
</div>
<div class="note" id="note-payload-verification" rel="schema:hasPart" resource="#note-payload-verification">
<h4 property="schema:name">Note</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Consumers should be aware that anything can be posted to an Inbox (depending on restrictions in place by the receiver, which are not defined by this protocol), so when it comes to making use of notification data consumers may want to take precautions when ascertaining the veracity of the contents.</p>
</div>
</div>
<figure class="listing example" id="notification-announce-annotation" rel="schema:hasPart" resource="#notification-announce-annotation">
<p class="example-h">Consumer example: getting a notification</p>
<pre about="#notification-announce-annotation" property="schema:description" typeof="fabio:Script"><code>GET /inbox/14a792f0 HTTP/1.1</code>
<code>Host: example.org</code>
<code>Accept: application/ld+json, text/turtle, application/xhtml+xml, text/html</code>
<code>Accept-Language: en-GB,en;q=0.8, en-US;q=0.6</code>
<code></code>
<code>HTTP/1.1 200 OK</code>
<code>Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"</code>
<code>Content-Language: en</code>
<code></code>
<code>{</code>
<code> "@context": [</code>
<code> "https://www.w3.org/ns/activitystreams",</code>
<code> { "@language": "en" }</code>
<code> ],</code>
<code> "@id": "http://example.org/inbox/14a792f0",</code>
<code> "@type": "Announce",</code>
<code> "actor": {</code>
<code> "@id": "http://csarven.ca/#i",</code>
<code> "name": "Sarven Capadisli"</code>
<code> },</code>
<code> "object": {</code>
<code> "@context": "http://www.w3.org/ns/anno.jsonld",</code>
<code> "@id": "http://example.net/note",</code>
<code> "@type": "Annotation",</code>
<code> "motivation": "http://www.w3.org/ns/oa#assessing",</code>
<code> "rights": "http://creativecommons.org/licenses/by/4.0/"</code>
<code> },</code>
<code> "target": "http://example.org/article",</code>
<code> "updated": {</code>
<code> "@type": "http://www.w3.org/2001/XMLSchema#dateTime",</code>
<code> "@value": "2016-06-28T19:56:20.114Z"</code>
<code> }</code>
<code>}</code></pre>
<figcaption><span about="#test-consumer-notification-assessing" id="test-consumer-notification-assessing" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">Result of a GET request on an individual notification discovered in an Inbox.</span></figcaption>
</figure>
</div>
</section>
</div>
</section>
<section id="payload" inlist="" rel="schema:hasPart" resource="#payload">
<h2 property="schema:name">Payload</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>The payload of the notification <em class="rfc2119">MUST</em> be JSON-LD unless another RDF syntax has been negotiated with the receiver. To allow for a wide variety of use cases, the actual vocabulary of the payload is deliberately not specified here.</p>
<section id="payload-examples" inlist="" rel="schema:hasPart" resource="#payload-examples">
<h3 property="schema:name">Payload Examples</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<figure class="listing example selected" id="notification-single-statement-json-ld" rel="schema:hasPart" resource="#notification-single-statement-json-ld">
<p class="example-h">Payload example 1</p>
<pre about="#notification-single-statement-turtle" property="schema:description" typeof="fabio:Script"><code>{</code>
<code> "@context": "http://schema.org/",</code>
<code> "@id": "http://example.net/note#foo",</code>
<code> "citation": { "@id": "http://example.org/article#results" }</code>
<code>}</code></pre>
<figcaption property="schema:name"><span about="#test-consumer-notification-citation" id="test-consumer-notification-citation" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">A citation described by a single statement, using the schema.org vocabulary.</span></figcaption>
</figure>
<figure class="listing example" id="notification-qualified-relation" rel="schema:hasPart" resource="#notification-qualified-relation">
<p class="example-h">Payload example 2</p>
<pre about="#notification-qualified-relation" property="schema:description" typeof="fabio:Script"><code>{</code>
<code> "@context": "https://www.w3.org/ns/activitystreams",</code>
<code> "@id": "",</code>
<code> "@type": "Announce",</code>
<code> "actor": "https://rhiaro.co.uk/#me",</code>
<code> "object": "http://example.net/note",</code>
<code> "target": "http://example.org/article",</code>
<code> "updated": "2016-06-28T19:56:20.114Z"</code>
<code>}</code></pre>
<figcaption property="schema:name"><span about="#test-consumer-notification-announce" id="test-consumer-notification-announce" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">An announcement of one resource to another, including a date and actor, described using the ActivityStreams 2.0 vocabulary.</span></figcaption>
</figure>
<figure class="listing example" id="notification-semantic-pingback" rel="schema:hasPart" resource="#notification-semantic-pingback">
<p class="example-h">Payload example 3</p>
<pre about="#notification-semantic-pingback" property="schema:description" typeof="fabio:Script"><code>{</code>
<code> "@context": { "pingback": "http://purl.org/net/pingback/" },</code>
<code> "@id": "",</code>
<code> "@type": "pingback:Item",</code>
<code> "pingback:source": { "@id": "http://example.net/note#foo" },</code>
<code> "pingback:target": { "@id": "http://example.org/article#results" }</code>
<code>}</code></pre>
<figcaption property="schema:name">A pingback notification described by the Semantic Pingback vocabulary.</figcaption>
</figure>
<figure class="listing example" id="notification-event-rsvp" rel="schema:hasPart" resource="#notification-event-rsvp">
<p class="example-h">Payload example 4</p>
<pre about="#notification-event-rsvp" property="schema:description" typeof="fabio:Script"><code>{</code>
<code> "@context": "http://schema.org/",</code>
<code> "@id": "",</code>
<code> "@type": "RsvpAction",</code>
<code> "event": { "@id": "http://example.org/event" },</code>
<code> "agent": { "@id": "https://rhiaro.co.uk/#me" }</code>
<code>}</code></pre>
<figcaption property="schema:name"><span about="#test-consumer-notification-rsvp" id="test-consumer-notification-rsvp" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">An event RSVP described by the schema.org vocabulary.</span></figcaption>
</figure>
<p>A notification may contain arbitrary information, including references to multiple resources with their own URIs, without necessarily referring to one particular external resource or origin for the data. The receiver is expected to return all triples that were initially sent when such a notification is requested by a consumer.</p>
<figure class="listing example" id="notification-any-data" rel="schema:hasPart" resource="#notification-any-data">
<p class="example-h">Payload example 5</p>
<pre about="#notification-any-data" property="schema:description" typeof="fabio:Script"><code>{</code>
<code> "@context": {</code>
<code> "@language": "en",</code>
<code> "sioc": "http://rdfs.org/sioc/ns#",</code>
<code> "foaf": "http://xmlns.com/foaf/0.1/"</code>
<code> },</code>
<code> "@id": "",</code>
<code> "@type": "sioc:Comment",</code>
<code> "sioc:reply_of": { "@id": "http://example.org/article" },</code>
<code> "sioc:created_at": {</code>
<code> "@type": "http://www.w3.org/2001/XMLSchema#dateTime",</code>
<code> "@value": "2015-12-23T16:44:21Z"</code>
<code> },</code>
<code> "sioc:content": "This is a great article!",</code>
<code> "sioc:has_creator": {</code>
<code> "@id": "http://example.org/profile",</code>
<code> "@type": "sioc:UserAccount",</code>
<code> "sioc:account_of": { "@id": "http://example.org/profile#alice" },</code>
<code> "sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },</code>
<code> "foaf:name": "Alice"</code>
<code> }</code>
<code>}</code></pre>
<figcaption property="schema:name"><span about="#test-consumer-notification-comment" id="test-consumer-notification-comment" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">A notification containing data about a comment and the user who created the comment, described by the Semantically Interlinked Online Communities (SIOC) and Friend-of-a-Friend (FOAF) vocabularies.</span></figcaption>
</figure>
<figure class="listing example" id="notification-provenance" rel="schema:hasPart" resource="#notification-provenance">
<p class="example-h">Payload example 6</p>
<pre about="#notification-provenance" property="schema:description" typeof="fabio:Script"><code>{</code>
<code> "@context": [{"prov": "http://www.w3.org/ns/prov#"}],</code>
<code> "@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",</code>
<code> "@type": "prov:Activity",</code>
<code> "http://www.w3.org/2000/01/rdf-schema#label": {</code>
<code> "@language": "en",</code>
<code> "@value": "Make it so"</code>
<code> },</code>
<code> "prov:endedAtTime": {</code>
<code> "@type": "http://www.w3.org/2001/XMLSchema#dateTime",</code>
<code> "@value": "2016-06-14T20:57:39.000Z"</code>
<code> },</code>
<code> "prov:generated": {</code>
<code> "@id": "http://example.org/entity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",</code>
<code> "@type": "prov:Entity",</code>
<code> "prov:specializationOf": { "@id": "http://example.org/entity/file" },</code>
<code> "prov:wasGeneratedBy": {</code>
<code> "@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7"</code>
<code> }</code>
<code> },</code>
<code> "prov:wasAssociatedWith": {</code>
<code> "@id": "http://csarven.ca/#i",</code>
<code> "@type": "prov:Agent",</code>
<code> "http://xmlns.com/foaf/0.1/name": {</code>
<code> "@language": "hy",</code>
<code> "@value": "Սարվէն Չափատիշլի"</code>
<code> }</code>
<code> }</code>
<code>}</code></pre>
<figcaption property="schema:name"><span about="#test-consumer-notification-changelog" id="test-consumer-notification-changelog" property="skos:definition" rel="skos:topConceptOf" resource="#ldn-tests-consumer" typeof="skos:Concept">A changelog entry described by the Provenance vocabulary.</span></figcaption>
</figure>
</div>
</section>
</div>
</section>
<section id="security-privacy-and-content-considerations" inlist="" rel="schema:hasPart" resource="#security-privacy-and-content-considerations">
<h2 property="schema:name">Security, Privacy and Content Considerations</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em> Normative requirements for security and privacy are called out in the section of the specification to which they are most applicable.</p>
<section id="constraints" inlist="" rel="schema:hasPart" resource="#constraints">
<h3 property="schema:name">Constraints</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Inbox URLs can announce their own constraints (e.g., <cite><a class="bibref" href="#bib-shacl">SHACL</a></cite>, <cite><a class="bibref" href="#bib-annotation-protocol">Web Annotation Protocol</a></cite>) via an HTTP <code>Link</code> header or body of the resource with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#constrainedBy</code>. Senders should comply with constraint specifications or the receiver may reject their notification and return an appropriate <code>4xx</code> error code.</p>
</div>
</section>
<section id="target-ownership" inlist="" rel="schema:hasPart" resource="#target-ownership">
<h3 property="schema:name">Target Ownership</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Publishers of the resources advertising an Inbox (target) should do so on a server they trust. Publishers must be aware that third-party access to headers or content could result in notifications being redirected.</p>
</div>
</section>
<section id="subscribing-to-notifications" inlist="" rel="schema:hasPart" resource="#subscribing-to-notifications">
<h3 property="schema:name">Subscribing to Notifications</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>This specification describes how consumers can read notifications from a receiver through <em>pull</em>, however consumers may want to ask to have incoming notifications or changes to Inbox’s contents pushed to them. Similarly, receivers may wish to make a request for notifications from a particular sender. This kind of subscription mechanism is left out of scope, but senders, receivers and consumers are not prohibited from making such an arrangement. Implementations that wish to enable subscribing may want to use existing mechanisms e.g., <cite><a class="bibref" href="#bib-activitypub">ActivityPub</a></cite>, <cite><a class="bibref" href="#bib-websub">WebSub</a></cite>, <cite><a class="bibref" href="#bib-rfc6455">The WebSocket Protocol</a></cite>, <cite><a class="bibref" href="#bib-webpush">HTTP Web Push</a></cite>.</p>
</div>
</section>
<section id="activity-streams-2-0-support" inlist="" rel="schema:hasPart" resource="#activity-streams-2-0-support">
<h3 property="schema:name">Activity Streams 2.0 Support</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Receiver implementations that wish to support <a href="https://www.w3.org/TR/activitystreams-core/">Activity Streams 2.0 Core</a> can see <a href="https://www.w3.org/TR/social-web-protocols/#inbox-interop">Social Web Protocols - Inbox Interop</a> for Content-Type and vocabulary equivalences.</p>
</div>
</section>
<section id="natural-language-content" inlist="" rel="schema:hasPart" resource="#natural-language-content">
<h3 property="schema:name">Natural Language Content</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Building an international base of users is important in a federated network. Some LDN interactions can return content with natural language text, such as HTML fragments, or summary fields. Providing multiple language representations of each item might not be feasible in all circumstances. Implementations are encouraged to provide means of discovering the available languages and/or negotiating the language returned, such as using the HTTP <code>Accept-Language</code> header to negotiate and select the most appropriate language representation to send for a given request.</p>
</div>
</section>
<section id="authenticated-inboxes" inlist="" rel="schema:hasPart" resource="#authenticated-inboxes">
<h3 property="schema:name">Authenticated Inboxes</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>If a receiver expects senders or consumers to authenticate, it should check the validity of their credentials before returning any other data, including other error codes. For example, the receiver should <em>not</em> first check for the existence of the inbox and return <code>404 Not Found</code> if the requester has not been verified.</p>
<p>Authentication involving token passing must be done over HTTPS.</p>
</div>
</section>
<section id="security-and-privacy-review" inlist="" rel="schema:hasPart" resource="#security-and-privacy-review">
<h3 property="schema:name">Security and Privacy Review</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>These questions provide an overview of security and privacy considerations for this specification as guided by <cite><a class="bibref" href="#bib-security-privacy-questionnaire-20151210">Self-Review Questionnaire: Security and Privacy</a></cite>.</p>
<dl>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#pii">Does this specification deal with personally-identifiable information?</a></dt><dd>Notification payloads may contain any data including that which identifies the sender or the receiver. Access to notification data is under the control of the receiver. In the case of sending sensitive information, the sender should be aware that the receiver may implement access control on the Inbox that allows for public reading of the contents.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#credentials">Does this specification deal with high-value data?</a></dt><dd>Same implications as personally-identifiable information in notification payload (as mentioned above).</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#persistent-origin-specific-state">Does this specification introduce new state for an origin that persists across browsing sessions?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#persistent-identifiers">Does this specification expose persistent, cross-origin state to the web?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#other-data">Does this specification expose any other data to an origin that it doesn’t currently have access to?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#string-to-script">Does this specification enable new script execution/loading mechanisms?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#location">Does this specification allow an origin access to a user’s location?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#sensors">Does this specification allow an origin access to sensors on a user’s device?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#local-device">Does this specification allow an origin access to aspects of a user’s local computing environment?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#remote-device">Does this specification allow an origin access to other devices?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#native-ui">Does this specification allow an origin some measure of control over a user agent’s native UI?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#temporary-id">Does this specification expose temporary identifiers to the web?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#first-third-party">Does this specification distinguish between behavior in first-party and third-party contexts?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#incognito">How should this specification work in the context of a user agent’s "incognito" mode?</a></dt><dd>Works in such a way that the website would not be able to determine that the user was in "incognito".</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#storage">Does this specification persist data to a user’s local device?</a></dt><dd>No.</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#considerations">Does this specification have a "Security Considerations" and "Privacy Considerations" section?</a></dt><dd>:)</dd>
<dt><a href="https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/#relaxed-sop">Does this specification allow downgrading default security characteristics?</a></dt><dd>No.</dd>
</dl>
</div>
</section>
</div>
</section>
<section class="appendix" id="exit-criteria" inlist="" rel="schema:hasPart" resource="#exit-criteria">
<h2 property="schema:name">Exit Criteria</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This specification advanced to Proposed Recommendation with at least two independent, interoperable implementations of each feature. Each feature was implemented by a different set of products. There was no requirement that all features needed to be implemented by a single product.</p>
<ul>
<li><strong>Independent</strong> implementations are developed by different parties and cannot share, reuse or derive form another qualifying implementation code which is directly pertinent to the implementation of this specification.</li>
<li><strong>Interoperability</strong> occurs between senders and receivers, or between consumers and receivers, when the sender/consumer makes a request to the receiver, and the receiver sends the expected response, as defined by this specification.</li>
<li>An <strong>implementation</strong> is an LDN sender, receiver or consumer which implements the corresponding conformance class of the specification.</li>
</ul>
<p id="features">For the purposes of evaluating exit criteria, each of the following was considered a feature:</p>
<ul>
<li>Advertising the Inbox of a given resource through the <code>Link</code> header.</li>
<li>Advertising the Inbox of a given resource through the body of the resource.</li>
<li>Sending a notification to the Inbox of a given target.</li>
<li>Receiving a notification and responding with the appropriate status code according to how it was processed and if it was accepted. Responding to <code>GET</code> requests on the Inbox with the Inbox listing, and responding to <code>GET</code> requests on the individual notifications with their representations.</li>
<li>Reading the Inbox listing of a given target.</li>
<li>Reading the individual notifications in the Inbox of a given target.</li>
</ul>
</div>
</section>
<section id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements">
<h2 about="#acknowledgements" property="schema:name" typeof="deo:Acknowledgements">Acknowledgements</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>We would like to thank and acknowledge the following people for their contributions to this specification:</p>
<ul about="" rel="schema:contributor">
<li about="https://orcid.org/0000-0002-3660-045X" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://www.amherst.edu/users/C/acoburn">Aaron Coburn</a></li>
<li about="#Addison-Phillips" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://www.w3.org/wiki/AddisonPhillips">Addison Phillips</a></li>
<li about="https://orcid.org/0000-0001-9083-7442" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://www.uebertext.org/">Adrian Pohl</a></li>
<li about="#Albert-Meroño-Peñuela" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://www.albertmeronyo.org/">Albert Meroño Peñuela</a></li>
<li about="#Alex-Kearney" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://alexkearney.com/">Alex Kearney</a></li>
<li about="https://deiu.me/profile#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://deiu.me/">Andrei Vlad Sambra</a></li>
<li about="https://akuckartz.databox.me/profile/card#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://akuckartz.databox.me/">Andreas Kuckartz</a></li>
<li about="http://bart.netage.nl/foaf#bvl" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://netage.cl/">Bart van Leeuwen</a></li>
<li about="#Benjamin-Goering" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://bengo.is/">Benjamin Goering</a></li>
<li about="http://[email protected]/#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://bigbluehat.com/">Benjamin Young</a></li>
<li about="#Bernadette-Hyland" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href=" https://w3id.org/people/bernhyland">Bernadette Hyland</a></li>
<li about="#Chris-Webber" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://dustycloud.org/">Chris Webber</a></li>
<li about="http://christian.amsuess.com/#CMA" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://christian.amsuess.com/">Christian M. Amsüss</a></li>
<li about="http://danbri.org/foaf.rdf#danbri" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://danbri.org/">Dan Brickley</a></li>
<li about="#Dmitri-Zagidulin" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://www.computingjoy.com/">Dmitri Zagidulin</a></li>
<li about="#Erik-Wilde" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://dret.net/netdret/">Erik Wilde</a></li>
<li about="http://ns.inria.fr/fabien.gandon#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://fabien.info/">Fabien Gandon</a></li>
<li about="#Felix-Sasaki" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://www.w3.org/People/fsasaki/">Felix Sasaki</a></li>
<li about="http://id.ninebynine.org/people/gk" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://ninebynine.org/">Graham Klyne</a></li>
<li about="http://bblfish.net/people/henry/card#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://bblfish.net/">Henry Story</a></li>
<li about="http://jeffreycwitt.com/#me " typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://jeffreycwitt.com/#me">Jeffrey Witt</a></li>
<li about="#John-Klensin" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://en.wikipedia.org/wiki/John_Klensin">John Klensin</a></li>
<li about="http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://kingsley.idehen.net/">Kingsley Idehen</a></li>
<li about="http://www.kjetil.kjernsmo.net/foaf#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://www.kjetil.kjernsmo.net/">Kjetil Kjernsmo</a></li>
<li about="https://melivincarvalho.com/#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://melivincarvalho.com/">Melvin Carvalho</a></li>
<li about="http://aksw.org/NatanaelArndt" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://natanael.arndt.xyz/">Natanael Arndt</a></li>
<li about="#Nick-Smith" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://www.thales-esecurity.com/">Nick Smith</a></li>
<li about="#Nicola-Greco" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://nicola.io/">Nicola Greco</a></li>
<li about="#Nuno-Freire" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://sites.google.com/site/nfreire/">Nuno Freire</a></li>
<li about="http://www.eurecom.fr/~troncy/troncyr-foaf.rdf#rt" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://www.eurecom.fr/~troncy/">Raphaël Troncy</a></li>
<li about="#Richard-Ishida" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://r12a.github.io/">Richard Ishida</a></li>
<li about="https://orcid.org/0000-0003-4441-6852" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://getty.edu/">Rob Sanderson</a></li>
<li about="#Sandro-Hawke" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://hawke.org/sandro/">Sandro Hawke</a></li>
<li about="http://soiland-reyes.com/stian/#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://soiland-reyes.com/stian/">Stian Soiland-Reyes</a></li>
<li about="https://www.w3.org/People/Berners-Lee/card#i" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="https://www.w3.org/People/Berners-Lee/">Tim Berners-Lee</a></li>
<li about="http://cuent.github.io/foaf.rdf#me" typeof="schema:Person"><a rel="schema:url" property="schema:name" xml:lang="" lang="" href="http://cuent.me/">Xavier Sumba</a></li>
</ul>
</div>
</section>
<section id="change-log" inlist="" rel="schema:hasPart" resource="#change-log">
<h2 property="schema:name">Change Log</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p><a about="https://www.w3.org/TR/2017/REC-ldn-20170502/" href="https://www.w3.org/TR/2017/REC-ldn-20170502/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2017/PR-ldn-20170321/">REC-ldn-20170502</a> ← <a about="https://www.w3.org/TR/2017/PR-ldn-20170321/" href="https://www.w3.org/TR/2017/PR-ldn-20170321/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2017/CR-ldn-20170223/">PR-ldn-20170321</a> ← <a about="https://www.w3.org/TR/2017/CR-ldn-20170223/" href="https://www.w3.org/TR/2017/CR-ldn-20170223/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2016/CR-ldn-20161101/">CR-ldn-20170223</a> ← <a about="https://www.w3.org/TR/2016/CR-ldn-20161101/" href="https://www.w3.org/TR/2016/CR-ldn-20161101/" rel="prov:wasRevisionOf" resource="hhttps://www.w3.org/TR/2016/WD-ldn-20161011/">CR-ldn-20161101</a> ← <a about="https://www.w3.org/TR/2016/WD-ldn-20161011/" href="https://www.w3.org/TR/2016/WD-ldn-20161011/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2016/WD-ldn-20160926/">WD-ldn-20161011</a> ← <a about="https://www.w3.org/TR/2016/WD-ldn-20160926/" href="https://www.w3.org/TR/2016/WD-ldn-20160926/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2016/WD-ldn-20160913/">WD-ldn-20160926</a> ← <a about="https://www.w3.org/TR/2016/WD-ldn-20160913/" href="https://www.w3.org/TR/2016/WD-ldn-20160913/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2016/WD-ldn-20160824/">WD-ldn-20160913</a> ← <a about="https://www.w3.org/TR/2016/WD-ldn-20160824/" href="https://www.w3.org/TR/2016/WD-ldn-20160824/" rel="prov:wasRevisionOf" resource="https://www.w3.org/TR/2016/WD-ldn-20160726/">WD-ldn-20160824</a> ← <a href="https://www.w3.org/TR/2016/WD-ldn-20160726/">WD-ldn-20160726</a></p>
<section id="change-log-Changes-from-21-March-2017-PR" inlist="" rel="schema:hasPart" resource="#change-log-Changes-from-21-March-2017-PR">
<h3 property="schema:name">Changes from 21 March 2017 PR to this version</h3>
<div datatype="rdf:HTML" property="schema:description">
<ul>
<li>Fix a syntax error in an example</li>
<li>Add 'in reply to' link to Social Web Group Charter</li>
<li>Add links to past versions of the spec</li>
<li>Update references</li>
</ul>
</div>
</section>
<section id="change-log-Changes-from-23-February-2017-CR" inlist="" rel="schema:hasPart" resource="#change-log-Changes-from-23-February-2017-CR">
<h3 property="schema:name">Changes from 23 February 2017 CR to 21 March 2017 PR</h3>
<div datatype="rdf:HTML" property="schema:description">
<ul>
<li>Update acknowledgements</li>
</ul>
</div>
</section>
<section id="change-log-Changes-from-1-November-2016-WD-to-this-version" inlist="" rel="schema:hasPart" resource="#change-log-Changes-from-01-November-2016-WD-to-this-version">
<h3 property="schema:name">Changes from 1 November 2016 CR to 23 February 2017 CR</h3>
<div datatype="rdf:HTML" property="schema:description">
<ul>
<li>Add Acknowledgements</li>
<li>Clarify the implied response codes for notifications and request URI in note</li>
<li>Update references</li>
</ul>
</div>
</section>
<section id="change-log-Changes-from-11-October-2016-WD" inlist="" rel="schema:hasPart" resource="#change-log-Changes-from-11-October-2016-WD">
<h3 property="schema:name">Changes from 11 October 2016 WD to 1 November 2016 CR</h3>
<div datatype="rdf:HTML" property="schema:description">