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
|
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 6914 jdrosen.net
Category: Informational April 2013
ISSN: 2070-1721
SIMPLE Made Simple: An Overview of the IETF Specifications
for Instant Messaging and Presence Using
the Session Initiation Protocol (SIP)
Abstract
The IETF has produced many specifications related to Presence and
Instant Messaging with the Session Initiation Protocol (SIP).
Collectively, these specifications are known as SIP for Instant
Messaging and Presence Leveraging Extensions (SIMPLE). This document
serves as a guide to the SIMPLE suite of specifications. It
categorizes the specifications, explains what each is for, and how
they relate to each other.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6914.
Rosenberg Informational [Page 1]
^L
RFC 6914 Simple Made Simple April 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Core Protocol Machinery . . . . . . . . . . . . . . . . . 4
2.2. Presence Documents . . . . . . . . . . . . . . . . . . . . 5
2.3. Privacy and Policy . . . . . . . . . . . . . . . . . . . . 6
2.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Federation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 8
3. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Page Mode . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Session Mode . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. IM Chat Rooms . . . . . . . . . . . . . . . . . . . . . . 11
3.4. IM Features . . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. Informative References . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The IETF has produced many specifications related to Presence and
Instant Messaging with the Session Initiation Protocol (SIP)
[RFC3261]. Collectively, these specifications are known as SIP for
Instant Messaging and Presence Leveraging Extensions (SIMPLE). These
specifications cover topics ranging from protocols for subscription
and publication to presence document formats to protocols for
managing privacy preferences. The large number of specifications can
make it hard to figure out exactly what SIMPLE is, what
specifications cover it, what functionality it provides, and how
these specifications relate to each other.
Rosenberg Informational [Page 2]
^L
RFC 6914 Simple Made Simple April 2013
This document serves to address these problems. It provides an
enumeration of the protocols that make up the SIMPLE suite of
specifications from IETF. It categorizes them into related areas of
functionality, briefly explains the purpose of each, and how the
specifications relate to each other. Each specification also
includes a letter that designates its category [RFC2026]. These
values are:
S: Standards Track
E: Experimental
B: Best Current Practice
I: Informational
2. Presence
SIMPLE provides for both presence and instant messaging (IM)
capabilities. Though both of these fit underneath the broad SIMPLE
umbrella, they are well separated from each other and are supported
by different sets of specifications. That is a key part of the
SIMPLE story; presence is much broader than just IM, and it enables
communications using voice and video along with IM.
The SIMPLE presence specifications can be broken up into:
o The core protocol machinery, which provides the actual SIP
extensions for subscriptions, notifications, and publications
o Presence documents, which are XML documents that provide for rich
presence and are carried by the core protocol machinery
o Privacy and policy, which are documents for expressing privacy
preferences about how those presence documents are to be shown (or
not shown) to other users
o Provisioning, which describes how users manage their privacy
policies, buddy lists, and other pieces of information required
for SIMPLE presence to work
o Optimizations, which are improvements in the core protocol
machinery that were defined to improve the performance of SIMPLE,
particularly on wireless links
Rosenberg Informational [Page 3]
^L
RFC 6914 Simple Made Simple April 2013
2.1. Core Protocol Machinery
RFC 6665, SIP-Specific Event Notification (S): [RFC6665] defines the
SUBSCRIBE and NOTIFY methods for SIP, forming the core of the SIP
event notification framework. To actually use the framework,
extensions need to be defined for specific event packages.
Presence is defined as an event package [RFC3856] within this
framework. Packages exist for other, non-presence related
functions, such as message waiting indicators and dialog state
changes.
RFC 3856, A Presence Event Package for the Session Initiation
Protocol (SIP) (S): [RFC3856] defines an event package for
indicating user presence through SIP. Through this package, a SIP
user agent (UA) can ask to be notified of the presence state of a
presentity (presence entity). The contents of the NOTIFY messages
in this package are presence documents discussed in Section 2.2.
RFC 4662, A Session Initiation Protocol (SIP) Event Notification
Extension for Resource Lists (S): [RFC4662] defines an extension
to [RFC3265] (which has now been obsoleted by RFC 6665) that
allows a client to subscribe to a list of resources using a single
subscription. The server, called a Resource List Server (RLS),
will "expand" the subscription and subscribe to each individual
member of the list. Its primary usage with presence is to allow
subscriptions to "buddy lists". Without RFC 4662, a UA would need
to subscribe to each presentity individually. With RFC 4662, they
can have a single subscription to all buddies. A user can manage
the entries in their buddy list using the provisioning mechanisms
in Section 2.4.
RFC 5367, Subscriptions to Request-Contained Resource Lists in the
Session Initiation Protocol (SIP) (S): [RFC5367] is very similar
to RFC 4662. It allows a client to subscribe to a list of
resources using a single subscription. However, with this
mechanism, the list is included within the body of the SUBSCRIBE
request. In RFC 4662, it is provisioned ahead of time on the
server.
RFC 3903, Session Initiation Protocol (SIP) Extension for Event State
Publication (S): [RFC3903] defines the PUBLISH method. With this
method, a UA can publish its current state for any event package,
including the presence event package. Once an agent publishes its
presence state, the presence server would send notifications of
this state change using RFC 3856.
Rosenberg Informational [Page 4]
^L
RFC 6914 Simple Made Simple April 2013
2.2. Presence Documents
Once a user has generated a subscription to presence using the core
protocol machinery, they will receive notifications (SIP NOTIFY
requests) that contain presence information. That presence
information is in the form of an XML presence document. Several
specifications have been defined to describe this document format,
focusing on rich, multimedia presence.
RFC 3863, Presence Information Data Format (PIDF) (S): [RFC3863]
defines the baseline XML format for a presence document. It
defines the concept of a tuple as representing a basic
communication modality and defines a simple status for it (open or
closed).
RFC 4479, A Data Model for Presence (S): [RFC4479] extends the basic
model in RFC 3863. It introduces the concepts of device and
person status and explains how these relate to each other. It
describes how presence documents are used to represent
communications systems states in a consistent fashion. More than
RFC 3863, it defines what a presence document is and what it
means.
RFC 4480, RPID: Rich Presence Extensions to the Presence Information
Data Format (PIDF) (S): [RFC4480] adds many more attributes to
the presence document schema, building upon the model in RFC 4479.
It allows for indications of activities, moods, places and place
types, icons, and indications of whether or not a user is idle.
RFC 4481, Timed Presence Extensions to the Presence Information Data
Format (PIDF) to Indicate Status Information for Past and Future
Time Intervals (S): [RFC4481] adds attributes to the presence
document schema, again building upon the model in RFC 4479. It
allows documents to indicate status for the future or the past.
For example, a user can indicate that they will be unavailable for
voice communications from 2 p.m. to 3 p.m. due to a meeting.
RFC 4482, CIPID: Contact Information for the Presence Information
Data Format (S): [RFC4482] adds attributes to the presence
document schema for contact information, such as a vCard, display
name, homepage, icon, or sound (such as the pronunciation of their
name).
RFC 5196, Session Initiation Protocol (SIP) User Agent Capability
Extension to Presence Information Data Format (PIDF) (S):
[RFC5196] adds even more attributes to the presence document
schema, this time to allow indication of capabilities for the user
Rosenberg Informational [Page 5]
^L
RFC 6914 Simple Made Simple April 2013
agent. For example, the extensions can indicate whether a UA
supports audio and video, what SIP methods it supports, and so on.
2.3. Privacy and Policy
The rich presence capabilities defined by the specifications in
Section 2.2 introduces a strong need for privacy preferences. Users
must be able to approve or deny subscriptions to their presence and
indicate what information such watchers can see. In SIMPLE, this is
accomplished through policy documents uploaded to the presence server
using the provisioning mechanisms in Section 2.4.
RFC 4745, Common Policy: A Document Format for Expressing Privacy
Preferences (S): [RFC4745] defines a general XML framework for
expressing privacy preferences for both geolocation information
and presence information. It introduces the concepts of
conditions, actions, and transformations that are applied to
privacy-sensitive data. The common policy framework provides
privacy safety, a property by which network error or version
incompatibilities can never cause more information to be revealed
to a watcher than the user would otherwise desire.
RFC 5025, Presence Authorization Rules (S): [RFC5025] uses the
framework of RFC 4745 to define a policy document format for
describing presence-privacy policies. Besides basic yes/no
approvals, this format allows a user to control what kind of
information a watcher is allowed to see.
RFC 3857, A Watcher Information Event Template-Package for the
Session Initiation Protocol (SIP) (S): [RFC3857], also known as
watcherinfo, provides a mechanism for a user agent to find out
what subscriptions are in place for a particular event package.
Though it was defined to be used for any event package, it has
particular applicability for presence. It is used to provide
reactive authorization. With reactive authorization, a user gets
alerted if someone tries to subscribe to their presence, so that
they may provide an authorization decision. Watcherinfo is used
to provide the alert that someone has subscribed to a user's
presence.
RFC 3858, An Extensible Markup Language (XML) Based Format for
Watcher Information (S): [RFC3858] is the companion to RFC 3857.
It specifies the XML format of watcherinfo that is carried in
notifications for the event template package in RFC 3857.
Rosenberg Informational [Page 6]
^L
RFC 6914 Simple Made Simple April 2013
2.4. Provisioning
Proper operation of a SIMPLE presence system requires that several
pieces of data are correctly managed by the users and provisioned
into the system. These include buddy lists (used by the resource
list subscription mechanism in RFC 4662) and privacy policies (such
as those described by the XML format in [RFC5025]).
In SIMPLE, management of this data is handled by the Extensible
Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825].
XCAP is used by the user agent to manipulate buddy lists, privacy
policy, and other data that is represented by XML documents stored on
a server.
RFC 4825, The Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) (S): [RFC4825] specifies XCAP, a usage of HTTP
that allows a user agent to manipulate the contents of XML
documents stored on a server. It can be used to manipulate any
kind of XML, and the protocol itself is independent of the
particular schema of the data it is modifying. XML schemas have
been defined for buddy lists, privacy policies, and offline
presence status, allowing all of those to be managed by a user
with XCAP.
RFC 5875, An Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) Diff Event Package (S): [RFC5875] defines an
extension to the SIP user agent configuration profile, allowing a
user agent to learn about changes in its documents on an XCAP
server. With this mechanism, there can be a change made by
someone else to a buddy list or privacy policy document, and a UA
will find out that a new version is available.
RFC 5874, An Extensible Markup Language (XML) Document Format for
Indicating a Change in XML Configuration Access Protocol (XCAP)
Resources (S): [RFC5874] defines an XML format for indicating
changes in XCAP documents. It makes use of an XML diff format
defined in [RFC5261]. It is used in conjunction with [RFC5875] to
alert a user agent of changes made by someone else to their
provisioned data.
RFC 4826, Extensible Markup Language (XML) Formats for Representing
Resource Lists (S): [RFC4826] defines two XML document formats
used to represent buddy lists. One is simply a list of users (or
more generally, resources), and the other defines a buddy list
whose membership is composed of a list of users or resources.
These lists can be manipulated by XCAP, allowing a user to add or
remove members from their buddy lists. The buddy list is also
Rosenberg Informational [Page 7]
^L
RFC 6914 Simple Made Simple April 2013
accessed by the resource list server specified in RFC 4662 for
processing resource list subscriptions.
RFC 4827, An Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) Usage for Manipulating Presence Document Contents
(S): [RFC4827] defines an XCAP usage that allows a user to store
an "offline" presence document. This is a presence status that is
used by a presence server when there are no presence documents
published for that user by any user agents currently running.
2.5. Federation
Federation refers to the interconnection of different presence and
instant messaging systems for the purposes of communications.
Federation can be between domains or within a domain. A document has
been developed that describes how presence and IM federation works.
RFC 5344, Presence and Instant Messaging Peering Use Cases (I):
[RFC5344] describes a basic set of presence and instant messaging
use cases for federating between providers.
2.6. Optimizations
When running over wireless links, presence can be a very expensive
service. Notifications often get sent when the change is not really
relevant to the watcher. Furthermore, when a notification is sent,
it contains the full presence state of the watcher, rather than just
an indication of what changed. Optimizations have been defined to
address both of these cases.
RFC 4660, Functional Description of Event Notification Filtering
(S): [RFC4660] defines a mechanism that allows a watcher to
include filters in its subscription. These filters limit the
cases in which notifications are sent. It is used in conjunction
with RFC 4661, which specifies the XML format of the filters
themselves. The mechanism, though targeted for presence, can be
applied to any SIP event package.
RFC 4661, An Extensible Markup Language (XML)-Based Format for Event
Notification Filtering (S): [RFC4661] defines an XML format used
with the event notification filtering mechanism defined in RFC
4660 [RFC4660].
RFC 5262, Presence Information Data Format (PIDF) Extension for
Partial Presence (S): [RFC5262] defines a new XML format for
representing changes in presence documents, called a partial PIDF
document. This format contains an XML patch operation [RFC5261]
that, when applied to the previous presence document, yields the
Rosenberg Informational [Page 8]
^L
RFC 6914 Simple Made Simple April 2013
new presence document. The partial PIDF document is included in
presence notifications when a watcher indicates that they support
the format.
RFC 5263, Session Initiation Protocol (SIP) Extension for Partial
Notification of Presence Information (S): [RFC5263] defines a
mechanism for receiving notifications that contain partial
presence documents.
RFC 5264, Publication of Partial Presence Information (S): [RFC5264]
defines a mechanism for publishing presence status using a partial
PIDF document.
RFC 5261, An Extensible Markup Language (XML) Patch Operations
Framework Utilizing XML Path Language (XPath) Selectors (S):
[RFC5261] defines an XML structure for representing changes in XML
documents. It is a form of "diff" but specifically for XML
documents. It is used by several of the optimization mechanisms
defined for SIMPLE.
RFC 5112, The Presence-Specific Static Dictionary for Signaling
Compression (Sigcomp) (S): [RFC5112] defines a dictionary for
usage with Signaling Compression (Sigcomp) [RFC3320] to improve
the compressibility of presence documents.
RFC 6446, Session Initiation Protocol (SIP) Event Notification
Extension for Notification Rate Control (S): [RFC6446] specifies
mechanisms for adjusting the rate of SIP event notifications.
These mechanisms can be applied in subscriptions to all SIP event
packages.
3. Instant Messaging
SIMPLE defines two modes of instant messaging. These are page mode
and session mode. In page mode, instant messages are sent by sending
a SIP request that contains the contents of the instant message. In
session mode, IM is viewed as another media type -- along with audio
and video -- and an INVITE request is used to set up a session that
includes IM as a media type. While page mode is more efficient for
one or two message conversations, session mode is more efficient for
longer conversations since the messages are not sent through the SIP
servers. Furthermore, by viewing IM as a media type, all of the
features available in SIP signaling -- third party call control,
forking, and so on, are available for IM.
Rosenberg Informational [Page 9]
^L
RFC 6914 Simple Made Simple April 2013
3.1. Page Mode
RFC 3428, Session Initiation Protocol (SIP) Extension for Instant
Messaging (S): [RFC3428] introduces the MESSAGE method, which can
be used to send an instant message through SIP signaling.
RFC 5365, Multiple-Recipient MESSAGE Requests in the Session
Initiation Protocol (SIP) (S): [RFC5365] defines a mechanism
whereby a client can send a single SIP MESSAGE to multiple
recipients. This is accomplished by including the list of
recipients as an object in the body and having a network server
send a copy to each recipient.
3.2. Session Mode
RFC 4975, The Message Session Relay Protocol (MSRP) (S): [RFC4975]
defines a small text-based protocol for exchanging arbitrarily
sized content of any kind between users. An MSRP session is set
up by exchanging certain information, such as an MSRP URI, within
SIP and Session Description Protocol (SDP) signaling.
RFC 3862, Common Presence and Instant Messaging (CPIM): Message
Format (S): [RFC3862] defines a wrapper around instant message
content providing metadata, such as the sender and recipient
identity. The CPIM format is carried in MSRP.
RFC 4976, Relay Extensions for the Message Sessions Relay Protocol
(MSRP) (S): [RFC4976] adds support for relays to MSRP. These
relay servers receive MSRP messages and send them towards the
destination. They provide support for firewall and NAT traversal
and allow for features such as recording and inspection to be
implemented.
RFC 6135, An Alternative Connection Model for the Message Session
Relay Protocol (MSRP) (S): [RFC6135] allows clients to negotiate
which endpoint in a session will establish the MSRP connection.
Without this specification, the client generating the SDP offer
would initiate the connection.
RFC 6714, Connection Establishment for Media Anchoring (CEMA) for the
Message Session Relay Protocol (MSRP) (S): [RFC6714] allows
middleboxes to anchor the MSRP connection, without the need for
middleboxes to modify the MSRP messages; thus, it also enables a
secure end-to-end MSRP communication in networks where such
middleboxes are deployed.
Rosenberg Informational [Page 10]
^L
RFC 6914 Simple Made Simple April 2013
3.3. IM Chat Rooms
In SIMPLE, IM multi-user chat (also known as chat-rooms) are provided
using regular SIP conferencing mechanisms. The framework for SIP
conferencing [RFC4353] and conference control [RFC5239] describe how
all SIP-based conferencing works; including joining and leaving,
persistent and temporary conferences, floor control and moderation,
and learning of conference membership, amongst other functions. All
that is necessary are extensions to provide features that are
specific to IM.
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
(Work in Progress): [SIMPCHAT] defines how MSRP is used to
provide support for nicknames and private chat within an IM
conference.
3.4. IM Features
Several specifications have been written to provide IM-specific
features for SIMPLE. These include "is-typing" indications, allowing
a user to know when their messaging peer is composing a response and
allowing a user to know when their IM has been received via delivery
notifications.
RFC 3994, Indication of Message Composition for Instant Messaging
(S): [RFC3994] defines an XML format that can be sent in instant
messages that indicates the status of message composition. This
provides the familiar "is-typing" indication in IM systems, but
also supports voice, video, and other message types.
RFC 5438, Instant Message Disposition Notification (IMDN) (S):
[RFC5438] provides delivery notifications of IM receipt. This
allows a user to know with certainty that a message has been
received.
4. Security Considerations
This specification is an overview of existing specifications and does
not introduce any security considerations on its own.
5. Acknowledgements
Thanks to Vijay Gurbani, Barry Leiba, Stephen Hanna, and Salvatore
Loreto for their review and comments.
Rosenberg Informational [Page 11]
^L
RFC 6914 Simple Made Simple April 2013
6. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema,
C., and D. Gurle, "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428,
December 2002.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-
Package for the Session Initiation Protocol (SIP)",
RFC 3857, August 2004.
[RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3994] Schulzrinne, H., "Indication of Message Composition for
Instant Messaging", RFC 3994, January 2005.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
Rosenberg Informational [Page 12]
^L
RFC 6914 Simple Made Simple April 2013
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", RFC 4480,
July 2006.
[RFC4481] Schulzrinne, H., "Timed Presence Extensions to the
Presence Information Data Format (PIDF) to Indicate
Status Information for Past and Future Time Intervals",
RFC 4481, July 2006.
[RFC4482] Schulzrinne, H., "CIPID: Contact Information for the
Presence Information Data Format", RFC 4482, July 2006.
[RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006.
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based
Format for Event Notification Filtering", RFC 4661,
September 2006.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension
for Resource Lists", RFC 4662, August 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745,
February 2007.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825,
May 2007.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Usage
for Manipulating Presence Document Contents", RFC 4827,
May 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
Rosenberg Informational [Page 13]
^L
RFC 6914 Simple Made Simple April 2013
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)",
RFC 4976, September 2007.
[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025,
December 2007.
[RFC5112] Garcia-Martin, M., "The Presence-Specific Static
Dictionary for Signaling Compression (Sigcomp)",
RFC 5112, January 2008.
[RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol
(SIP) User Agent Capability Extension to Presence
Information Data Format (PIDF)", RFC 5196,
September 2008.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008.
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML)
Patch Operations Framework Utilizing XML Path Language
(XPath) Selectors", RFC 5261, September 2008.
[RFC5262] Lonnfors, M., Leppanen, E., Khartabil, H., and J.
Urpalainen, "Presence Information Data Format (PIDF)
Extension for Partial Presence", RFC 5262,
September 2008.
[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
Khartabil, "Session Initiation Protocol (SIP) Extension
for Partial Notification of Presence Information",
RFC 5263, September 2008.
[RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
Partial Presence Information", RFC 5264, September 2008.
[RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and
Instant Messaging Peering Use Cases", RFC 5344,
October 2008.
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol
(SIP)", RFC 5365, October 2008.
[RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
Request-Contained Resource Lists in the Session
Initiation Protocol (SIP)", RFC 5367, October 2008.
Rosenberg Informational [Page 14]
^L
RFC 6914 Simple Made Simple April 2013
[RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition
Notification (IMDN)", RFC 5438, February 2009.
[RFC5874] Rosenberg, J. and J. Urpalainen, "An Extensible Markup
Language (XML) Document Format for Indicating a Change in
XML Configuration Access Protocol (XCAP) Resources",
RFC 5874, May 2010.
[RFC5875] Urpalainen, J. and D. Willis, "An Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Diff
Event Package", RFC 5875, May 2010.
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection
Model for the Message Session Relay Protocol (MSRP)",
RFC 6135, February 2011.
[RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Protocol (SIP) Event Notification Extension for
Notification Rate Control", RFC 6446, January 2012.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012.
[RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection
Establishment for Media Anchoring (CEMA) for the Message
Session Relay Protocol (MSRP)", RFC 6714, August 2012.
[SIMPCHAT] Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party
Chat Using the Message Session Relay Protocol (MSRP)",
Work in Progress, January 2013.
Author's Address
Jonathan Rosenberg
jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Rosenberg Informational [Page 15]
^L
|