-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathOStatus 1.0 Draft 2.html
846 lines (790 loc) · 36.8 KB
/
OStatus 1.0 Draft 2.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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OStatus 1.0 Draft 2</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OStatus 1.0 Draft 2">
<meta name="generator" content="xml2rfc v1.37pre1 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">E. Prodromou</td></tr>
<tr><td class="header"> </td><td class="header">B. Vibber</td></tr>
<tr><td class="header"> </td><td class="header">J. Walker</td></tr>
<tr><td class="header"> </td><td class="header">Z. Copley</td></tr>
<tr><td class="header"> </td><td class="header">StatusNet Inc</td></tr>
<tr><td class="header"> </td><td class="header">August 30, 2010</td></tr>
</table></td></tr></table>
<h1><br />OStatus 1.0 Draft 2</h1>
<h3>Abstract</h3>
<p>
OStatus lets people on different social networks follow each
other. It applies a group of related protocols (PubSubHubbub,
ActivityStreams, Salmon, Portable Contacts, and Webfinger) to
this problem in what we believe is a simple and obvious way.
</p>
<p>
OStatus is a minimal specification for distributed
status updates or microblogging. Many social applications can
be modelled with status updates, however. Practically any software
that generates RSS or Atom feeds could be OStatus-enabled.
Travel networks, event invitation systems, wikis, photo-sharing
systems, social news sites, social music sites, podcasting
servers, blogs, version control systems, and general purpose
social networks would all be candidates for OStatus use.
</p>
<p>
The authors recognize that most of this protocol suite was
intended to work together in a natural way. They claim no
originality or creativity in connecting their use. The authors
hope that the obviousness of some parts of this specification
are an argument in favor of its use.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
License<br />
<a href="#anchor2">2.</a>
Notation and Conventions<br />
<a href="#definitions">3.</a>
Definitions<br />
<a href="#anchor3">4.</a>
Requirements<br />
<a href="#anchor4">5.</a>
Out of scope<br />
<a href="#anchor5">6.</a>
Update representation<br />
<a href="#anchor6">7.</a>
User representation<br />
<a href="#anchor7">8.</a>
Feed representation<br />
<a href="#anchor8">9.</a>
Update publication<br />
<a href="#anchor9">10.</a>
User notification<br />
<a href="#anchor10">11.</a>
Discovery<br />
<a href="#anchor11">12.</a>
Usage scenarios<br />
<a href="#anchor12">12.1.</a>
Subscription from Subscriber server<br />
<a href="#anchor13">12.2.</a>
Subscription from Publisher server<br />
<a href="#rfc.references1">13.</a>
References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
License</h3>
<p>As of 30 August 2010, the following persons or entities have
made this Specification available under the Open Web Foundation
Agreement Version 0.9, which is available at
http://openwebfoundation.org/legal/agreement/
</p>
<ul class="text">
<li>StatusNet Inc.
</li>
</ul><p>
</p>
<p>You can review the signed copies of the Open Web
Foundation Agreement Version 0.9 for this Specification at
http://ostatus.org/owfa/, which may also include additional parties
to those listed above.
</p>
<p>Your use of this Specification may be subject to other third party
rights. THIS SPECIFICATION IS PROVIDED “AS IS.” The contributors
expressly disclaim any warranties (express, implied, or otherwise),
including implied warranties of merchantability, non-infringement,
fitness for a particular purpose, or title, related to the
Specification. The entire risk as to implementing or otherwise using
the Specification is assumed by the Specification implementer and
user. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST
PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH
RESPECT TO THIS SPECIFICATION OR ITS GOVERNING AGREEMENT, WHETHER
BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR
OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Notation and Conventions</h3>
<p>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>.
</p>
<p>
XML namespace prefixes used in this document:
</p>
<blockquote class="text"><dl>
<dt>atom:</dt>
<dd>http://www.w3.org/2005/Atom
</dd>
<dt>activity:</dt>
<dd>http://activitystrea.ms/spec/1.0/
</dd>
<dt>schema:</dt>
<dd>http://activitystrea.ms/spec/1.0/
</dd>
<dt>ostatus:</dt>
<dd>http://ostatus.org/schema/1.0/
</dd>
<dt>thr:</dt>
<dd>http://purl.org/syndication/thread/1.0
</dd>
</dl></blockquote><p>
</p>
<a name="definitions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Definitions</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>User:</dt>
<dd>
A person or organization, or a program that mimics a person
or organization ("bot").
</dd>
<dt>Group:</dt>
<dd>
A set of users.
</dd>
<dt>Update:</dt>
<dd>
Notification of a change in a user's status or an action
taken by a user. Updates can be automatically generated
by software or composed by the user.
</dd>
<dt>Feed:</dt>
<dd>
A list of related updates. For example, a feed may
consist of all updates by a user, all updates by
users that are members of a group, updates that
match a search query.
</dd>
<dt>Publisher:</dt>
<dd>
A user or group that makes their updates available for others.
</dd>
<dt>Subscriber:</dt>
<dd>
A user who receives updates from one or more publishers.
Also known as "follower".
</dd>
<dt>Follow:</dt>
<dd>
Receive updates from a publisher.
</dd>
<dt>publisher server:</dt>
<dd>
the Web-accessible server that the publisher uses to
make updates available.
</dd>
<dt>subscriber server:</dt>
<dd>
the Web-accessible server that the subscriber uses to
receive updates.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Requirements</h3>
<p>These are the parameters of the problem we wish to solve.
</p>
<p>
</p>
<ul class="text">
<li>An update may be represented with plain text in UTF-8 encoding.
</li>
<li>An update may be represented with HTML.
</li>
<li>An update may include one or more attached files.
</li>
<li>An update may be a response to another update.
</li>
<li>An update can be a forwarded or shared copy of another update. ("repeat",
"retweet").
</li>
<li>An update can be about a topic.
</li>
<li>An update can be directed to the attention of a particular recipient.
("mention").
</li>
<li>An update can be related to a location on Earth.
</li>
<li>Anyone can mark an update as a "favorite", or remove that mark.
</li>
<li>Users have a unique identity.
</li>
<li>Users have profile information like name, location,
nickname or username, bio, related URLs.
</li>
<li>Users can be represented with a image ("avatar").
</li>
<li>Subscriber can receive Publisher's updates very soon after
publication. ("Real time", "near real time") (Upshot: we want
push.)
</li>
<li>Publisher server can store a list of all Subscribers for a given
Publisher, including identities and profile data.
</li>
<li>Subscriber server can store a list of all Publishers for a given
Subscriber, including identities and profile data.
</li>
<li>Publisher server can store a list of all responses to an update
by a publisher.
</li>
<li>Publisher server can store a list of all forwarded copies of an update
by a publisher.
</li>
<li>Publisher server can store a list of all "favorites" of an update by
a Publisher.
</li>
<li>Servers can determine update context and metadata without
parsing the plain text according to a particular syntax.
</li>
<li>Subscribers can subscribe to a feed with multiple authors, such
as a group, a search feed, or a tag feed.
</li>
</ul><p>
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Out of scope</h3>
<p>The following common elements of microblogging and status update
systems are out of scope for OStatus.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>Microblogging syntax:</dt>
<dd>Microblogging servers use a number of
different idioms for adding metadata to an update. Notable examples
are hashtags (#hashtag) and @-replies (@username). We defer to
microsyntax.org for developing these idioms and encourage innovation.
Publisher and subscriber servers should be able to process received
updates without parsing the plain text content.
</dd>
<dt>Client API</dt>
<dd>Microblogging systems typically allow many forms of
communication between the publisher and the publisher server as well
as the subscriber and the subscriber server. Some examples: Web
interface, email, IM, SMS, and a Web API. By analogy with email,
OStatus is to client interfaces as SMTP is to IMAP or POP.
</dd>
<dt>Private messaging:</dt>
<dd>OStatus does
not directly address sending 1-to-1 private messages or private streams.
</dd>
<dt>Social graph:</dt>
<dd>OStatus does not specify
a static representation of the social graph nor a
protocol for retrieving that representation for a user.
We defer to FOAF or XFN where this is required.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
Update representation</h3>
<p>Updates are represented as <a class='info' href='#activitiesinatom'>Activities<span> (</span><span class='info'>Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.</span><span>)</span></a> [activitiesinatom]
in <a class='info' href='#RFC4287'>Atom<span> (</span><span class='info'>Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.</span><span>)</span></a> [RFC4287]. Typical updates would be represented in the <a class='info' href='#activityschema'>default Activity Schema<span> (</span><span class='info'>Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Base Schema (Draft),” March 2010.</span><span>)</span></a> [activityschema] with activity verb
"Post" and activity object type "Note",
"Status" or "Comment". Servers SHOULD
support these default types, and MAY support others.
</p>
<p>A spatial location for the update object should be encoded as <a class='info' href='#georss'>GeoRSS<span> (</span><span class='info'>, “GeoRSS-Simple,” .</span><span>)</span></a> [georss] element as part of the activity.
</p>
<p>Attachments to an update should be represented as
enclosures.
</p>
<p>If an update represents a notice made in reply to another,
this should be represented using the in-reply-to element from
<a class='info' href='#RFC4685'>[RFC4685]<span> (</span><span class='info'>Snell, J., “Atom Threading Extensions,” September 2006.</span><span>)</span></a>.
</p>
<p>Tag information should be represented as Atom categories.
</p>
<p>OStatus defines two custom extensions to Activity streams.
</p>
<blockquote class="text"><dl>
<dt>link[@rel=ostatus:attention]/@href</dt>
<dd>When an update
is directed to the attention of someone, or mentions
someone, this link stores that user's URI.
</dd>
<dt>link[@rel=ostatus:conversation]/@href</dt>
<dd>
When an update is part of a distributed conversation, this
is the URI of that conversation.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
User representation</h3>
<p>Users are identified by URIs.
</p>
<p>Users are represented as activity objects of the appropriate
object type. A typical user would have type "Person".
</p>
<p>In the absence of additional information, a default Atom or RSS feed
without additional Activity data will be represented as with activity
verb "Post" and activity object type
"Note", with the Atom author as the implied activity
actor. In this case, the author element MUST have a unique
identifier, that is, either the <email> or <uri<
elements must be present.
</p>
<p>Subscribers MUST search for the URI in the following order:
the Activity object's <id> element if available, else
the Atom author's <uri> element if available, else the
Atom author's <email> element treated as a Webfinger acct: URI.
Publishers MAY use a profile URL as the URI, but if so
MUST ensure that they are stable permalinks.
</p>
<p>Users SHOULD have a profile URL, which SHOULD be an HTTP
or HTTPS reference to an HTML page including discovery
information for the user's feed.
The profile URL SHOULD be represented as a
link[@rel=alternate,@type=text/html] in the Activity subject,
actor, or object item, otherwise the URI MAY be used if it is
an HTTP or HTTPS URL.
</p>
<p>To provide additional profile information, the author or
actor element can be extended with optional <a class='info' href='#poco'>Portable Contacts<span> (</span><span class='info'>Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008.</span><span>)</span></a> [poco]-structured data. Some
elements worth highlighting:
</p>
<blockquote class="text"><dl>
<dt>preferredUsername:</dt>
<dd>A login or username.
</dd>
<dt>displayName:</dt>
<dd>Full name. If present, it SHOULD be
identical to the author/name or actor/title value.
</dd>
<dt>note:</dt>
<dd>A free text description of the user.
</dd>
<dt>address/formatted:</dt>
<dd>A free text description of
the user's current location or usual location.
</dd>
<dt>urls[type=home]/value:</dt>
<dd>URL of a representative
page for the user. Note that this is distinct from
the link[@rel=alternate,@type=text/html] required for
activity actors.
</dd>
</dl></blockquote><p>
</p>
<p>Subscribers MAY use other sources of profile information such
as microformats on the profile page, but are not required to.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Feed representation</h3>
<p>Feeds are Activity feeds per <a class='info' href='#activitiesinatom'>[activitiesinatom]<span> (</span><span class='info'>Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.</span><span>)</span></a>.
</p>
<p>All feeds SHOULD have an activity:subject element.
User feeds SHOULD have a single activity:subject or atom:author.
Group feeds SHOULD have a single activity:subject
representing the group.
</p>
<p>All feeds MUST have a link[@rel=hub] to identify a PubSubHubbub
endpoint URL to establish update subscriptions.
</p>
<p>All feeds SHOULD have a link[@rel=salmon] to identify the Salmon
endpoint URL to receive replies and notifications.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
Update publication</h3>
<p>The publisher server uses <a class='info' href='#push'>PubSubHubbub<span> (</span><span class='info'>Fitzpatrick, B., Slatkin, B., and M. Atkins, “PubSubHubbub Core 0.3 -- Working Draft,” February 2010.</span><span>)</span></a> [push] to notify subscribers of new updates.
</p>
<p>If multiple subscribers using the same subscriber server
subscribe to the same publisher, the subscriber server SHOULD use
the one PubSubHubbub subscription for all of them.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.
User notification</h3>
<p>Servers use <a class='info' href='#salmon'>Salmon<span> (</span><span class='info'>Panzer, J., “The Salmon Protocol,” February 2010.</span><span>)</span></a> [salmon] to post
social events to users or groups. Servers MUST NOT assume that
updates that were modeled as activities in a PubSubHubbub-enabled
feed were received by the user.
</p>
<p>Note that sender and receiver of a notification MAY NOT
have a subscriber-publisher relationship.
</p>
<p>Important social events and related activities:
</p>
<blockquote class="text"><dl>
<dt>Attention:</dt>
<dd>When a user posts an update to the
attention of another user or a group, their server sends the update
to the salmon endpoint of that user or group. The update MUST have the
ostatus:attention link set to the URI of the receiving
user or group.
</dd>
<dt>Reply:</dt>
<dd>When a user posts an update in reply to
another update, their server SHOULD post it as a Salmon
entry to the author of the original update. The reply
MUST have the thr:in-reply-to element set to the URI of
the original notice. The reply MAY have the
ostatus:attention link set to the URI of the original
update's author.
</dd>
<dt>Subscribe:</dt>
<dd>When a subscriber starts
following a user, the subscription server sends a
schema:follow activity.
</dd>
<dt>Unsubscribe:</dt>
<dd>When a subscriber stops following
a user the subscription server sends an
ostatus:unfollow activity.
</dd>
<dt>Join:</dt>
<dd>When a subscriber starts
following a group, the subscriber server sends a
schema:follow activity.
</dd>
<dt>Leave:</dt>
<dd>When a subscriber stops following
a user the subscriber server sends an
ostatus:leave activity.
</dd>
<dt>Favorite:</dt>
<dd>When a user marks another user's
update as a favorite, their server sends an update with
verb schema:favorite.
</dd>
<dt>Unfavorite:</dt>
<dd>When a user has marked another
user's update as a favorite, and removes that mark,
their server sends an update with verb ostatus:unfavorite.
</dd>
<dt>Repeat:</dt>
<dd>When a user publishes a copy of an
update to their own feed, their server sends an update
with verb schema:share to the original verb.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.
Discovery</h3>
<p>Information necessary to establish a subscription or post a
notification can be determined from the feed for a user or
group. The profile data, salmon endpoint, and PubSubHubbub hub
are all encoded in the feed itself.
</p>
<p>There are three ways to discover the location of the feed.
</p>
<ol class="text">
<li>Direct input from the user.
</li>
<li>From
Link/Rel=http://schemas.google.com/g/2010#updates-from element
of a related XRD file for the user.
</li>
<li>From a link[@rel=alternate,@type=application/atom+xml]
element in the HTML of a profile page.
</li>
</ol><p>
</p>
<p>There are two ways to get a profile page URL.
</p>
<ol class="text">
<li>Direct input from a user.
</li>
<li>From
Link/Rel=http://webfinger.net/rel/profile-page
of a related XRD file for the user.
</li>
</ol><p>
</p>
<p>There are two ways to get a related XRD file for a user.
</p>
<ol class="text">
<li>Given an acct: URI like nickname@example.com, use
<a class='info' href='#Webfinger'>[Webfinger]<span> (</span><span class='info'>, “the WebFinger protocol,” .</span><span>)</span></a> to discover the user's XRD file.
</li>
<li>From a Link: HTTP header for the related profile page, use
<a class='info' href='#LRDD'>[LRDD]<span> (</span><span class='info'>Hammer-Lahav, E., “Link-based Resource Descriptor Discovery,” March 2010.</span><span>)</span></a>.
</li>
</ol><p>
</p>
<p>The user's XRD document MAY have an additional link template with Rel
equal to http://ostatus.org/schema/1.0/subscribe to
indicate the endpoint to use for initiating a subscription on
the user's subscription server. The template should take a
single argument, uri, for the account to subscribe to.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.
Usage scenarios</h3>
<p>These are some rough scripts for some important processes in this
system. They are non-normative.
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12.1"></a><h3>12.1.
Subscription from Subscriber server</h3>
<p>
</p>
<ol class="text">
<li>Subscriber notifies Subscriber server of a feed to which she
wants to subscribe (e.g., by providing a HTTP URL, a
Webfinger account, or choosing from a list of known feeds).
</li>
<li>The subscriber server discovers the URL of the feed.
</li>
<li>If the Subscriber server already has a subscription to this feed,
it skips to step 6.
</li>
<li>Subscriber server downloads the feed using HTTP.
</li>
<li>Subscriber server checks for a PubSubHubbub URL in the feed document. If
there's no PubSubHubbub URL, the server MAY end the subscription. Any other
subscription, e.g. one using polling, is out-of-band for
OStatus.
</li>
<li>Subscriber server subscribes to the feed using PubSubHubbub subscription
mechanism.
</li>
<li>Subscriber server checks the feed for a Salmon endpoint. If none
exists, the process is complete.
</li>
<li>Subscriber server uses Salmon to push a representation of the subscription to the Publisher
server.
</li>
</ol><p>
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12.2"></a><h3>12.2.
Subscription from Publisher server</h3>
<p>
</p>
<ol class="text">
<li>Subscriber provides a WebFinger account to the Publisher server
(say, in an HTML form).
</li>
<li>Publisher server uses WebFinger to discover the subscription
URITemplate for this user.
</li>
<li>Publisher server substitutes Publisher's feed URL into
URITemplate.
</li>
<li>Publisher server redirects user's browser to
substituted URL.
</li>
<li>Subscription continues from step 1 of previous case.
</li>
</ol><p>
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>13. References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="LRDD">[LRDD]</a></td>
<td class="author-text">Hammer-Lahav, E., “<a href="http://tools.ietf.org/html/draft-hammer-discovery-03">Link-based Resource Descriptor Discovery</a>,” March 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4287">[RFC4287]</a></td>
<td class="author-text"><a href="mailto:mnot@pobox.com">Nottingham, M., Ed.</a> and <a href="mailto:rfsayre@boswijck.com">R. Sayre, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc4287">The Atom Syndication Format</a>,” RFC 4287, December 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4287.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc4287.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc4287.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4685">[RFC4685]</a></td>
<td class="author-text">Snell, J., “<a href="http://tools.ietf.org/html/rfc4685">Atom Threading Extensions</a>,” RFC 4685, September 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4685.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="Webfinger">[Webfinger]</a></td>
<td class="author-text">“<a href="http://code.google.com/p/webfinger/wiki/WebFingerProtocol">the WebFinger protocol</a>.”</td></tr>
<tr><td class="author-text" valign="top"><a name="activitiesinatom">[activitiesinatom]</a></td>
<td class="author-text">Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “<a href="http://martin.atkins.me.uk/specs/activitystreams/atomactivity">Atom Activity Extensions (Draft)</a>,” March 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="activityschema">[activityschema]</a></td>
<td class="author-text">Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “<a href="http://martin.atkins.me.uk/specs/activitystreams/activityschema">Atom Activity Base Schema (Draft)</a>,” March 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="georss">[georss]</a></td>
<td class="author-text">“<a href="http://www.georss.org/simple">GeoRSS-Simple</a>.”</td></tr>
<tr><td class="author-text" valign="top"><a name="poco">[poco]</a></td>
<td class="author-text"><a href="mailto:joseph@plaxo.com">Smarr, J.</a>, “<a href="http://portablecontacts.net/draft-spec.html">Portable Contacts 1.0 Draft C</a>,” August 2008.</td></tr>
<tr><td class="author-text" valign="top"><a name="push">[push]</a></td>
<td class="author-text"><a href="mailto:brad@danga.com">Fitzpatrick, B.</a>, <a href="mailto:bslatkin@gmail.com">Slatkin, B.</a>, and <a href="mailto:mart@degeneration.co.uk">M. Atkins</a>, “<a href="http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html">PubSubHubbub Core 0.3 -- Working Draft</a>,” February 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="salmon">[salmon]</a></td>
<td class="author-text"><a href="mailto:jpanzer@google.com">Panzer, J.</a>, “<a href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html">The Salmon Protocol</a>,” February 2010.</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Evan Prodromou</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">StatusNet Inc</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:evan@status.net">evan@status.net</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://evan.status.net/">http://evan.status.net/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Brion Vibber</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">StatusNet Inc</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:brion@status.net">brion@status.net</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">James Walker</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">StatusNet Inc</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:james@status.net">james@status.net</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Zach Copley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">StatusNet Inc</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:zach@status.net">zach@status.net</a></td></tr>
</table>
</body></html>