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
1001
1002
1003
1004
1005
|
<pre>Network Working Group M. Garcia-Martin
Request for Comments: 5365 G. Camarillo
Category: Standards Track Ericsson
October 2008
<span class="h1">Multiple-Recipient MESSAGE Requests in</span>
<span class="h1">the Session Initiation Protocol (SIP)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a mechanism that allows a SIP User Agent
Client (UAC) to send a SIP MESSAGE request to a set of destinations,
by using a SIP URI-list (Uniform Resource Identifier list) service.
The UAC sends a SIP MESSAGE request that includes the payload along
with the URI list to the MESSAGE URI-list service, which sends a
MESSAGE request including the payload to each of the URIs included in
the list.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. URI-List Document . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Option-Tag . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Procedures at the User Agent Client . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7">7</a>. Procedures at the MESSAGE URI-List Service . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7.1">7.1</a>. Determining the Intended Recipient . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7.2">7.2</a>. Creating an Outgoing MESSAGE Request . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7.3">7.3</a>. Composing Bodies in the Outgoing MESSAGE Request . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-11">11</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-12">12</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-13">13</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-13.1">13.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-13.2">13.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="./rfc3261">RFC 3261</a> (SIP) [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] is extended by <a href="./rfc3248">RFC 3248</a> [<a href="./rfc3428" title=""Session Initiation Protocol (SIP) Extension for Instant Messaging"">RFC3428</a>] to carry
instant messages in MESSAGE requests. SIP-based messaging, as
described in <a href="./rfc3428">RFC 3428</a> [<a href="./rfc3428" title=""Session Initiation Protocol (SIP) Extension for Instant Messaging"">RFC3428</a>], does not provide a mechanism to send
the same request to multiple recipients or replying to all recipients
of a SIP MESSAGE request. This memo addresses these functions.
A first requirement can be expressed as:
REQ-1: It must be possible for a user to send an instant message
request to an ad hoc group, where the identities of the recipients
are carried in the message itself.
One possibility to fulfill the above requirement is to establish a
session of instant messages with an instant messaging conference
server, and exchange the messages, for example, using MSRP (Message
Session Relay Protocol) [<a href="./rfc4975" title=""The Message Session Relay Protocol (MSRP)"">RFC4975</a>]. While this option seems to be
reasonable in many cases, in other situations the sending user just
wants to send a small pager-mode instant message to an ad hoc group
without the burden of setting up a session. This document focuses on
sending a pager-mode instant message to a number of intended
recipients.
To meet the requirement with a pager-mode instant message, we allow
SIP MESSAGE requests carry recipient-list bodies, i.e., URI lists in
body parts whose Content-Disposition (<a href="./rfc2183">RFC 2183</a>) [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] is
'recipient-list', as specified in <a href="./rfc5363">RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>]. A SIP MESSAGE
URI-list service, which is a specialized application service,
receives the request and sends a MESSAGE request including the
received payload to each of the URIs in the list. Each of these
MESSAGE requests contains a copy of the body included in the original
MESSAGE request.
A second requirement addresses the "Reply-To-All" functionality:
REQ-2: It MUST be possible for the recipient of a group instant
message to send a message to all other participants that received
the same group instant message (i.e., Reply-To-All).
To meet this requirement, we provide a mechanism whereby the MESSAGE
URI-list service also includes a URI list in body parts whose
Content-Disposition (<a href="./rfc2183">RFC 2183</a>) [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] is 'recipient-list-history',
as specified in <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. The 'recipient-list-history'
body is sent along with the instant message payload in each of the
instant messages sent to the recipients.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE
URI-list service needs to be configured with the SIP URI of the
service that provides the functionality. Discovering and
provisioning of this URI to the UAC is outside the scope of this
document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] and indicate requirement levels for compliant
implementations.
This document reuses the following terminology defined in <a href="./rfc3261">RFC 3261</a>
[<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]:
o Address-of-Record (AOR)
o User Agent (UA)
o User Agent Client (UAC)
o User Agent Server (UAS)
This document defines the following new terms:
MESSAGE URI-list service: A specialized URI-list service that
receives a MESSAGE request with a URI list and sends a similar
MESSAGE request to each URI in the list. In this context, similar
indicates that some SIP header fields can change, but the MESSAGE
URI-list service will not change the instant message payload.
MESSAGE URI-list services behave effectively as specialized B2BUAs
(Back-to-Back-User-Agents). A server providing MESSAGE URI-list
services can also offer URI-list services for other methods,
although this functionality is outside the scope of this document.
In this document, we only discuss MESSAGE URI-list services.
Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates
and addresses to a MESSAGE URI-list service. Besides the regular
instant message payload, an incoming MESSAGE request contains a
URI list.
Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI-
list service creates and addresses to a UAS (User Agent Server).
It contains the regular instant message payload.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
Intended recipient: The intended final recipient of the request to
be generated by MESSAGE URI-list service.
Reply-To-All: The ability of an intended recipient to receive a
MESSAGE request that includes the payload and the list of
recipients, and compose and send a MESSAGE request to the sender
and the rest of the recipients. The replying entity can use a
MESSAGE URI-list service if one is at its disposal or can create a
sequence of regular single-recipient MESSAGE requests to each SIP
AOR.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview</span>
A UAC creates a MESSAGE request that contains a multipart body
including a list of URIs (intended recipients) and an instant
message. The list of URIs is formatted according to the resource
list document format specified in <a href="./rfc4826">RFC 4826</a> [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] and extended
with the attributes defined in <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. The UAC sends
this MESSAGE request to the MESSAGE URI-list service. On reception
of this incoming MESSAGE request, the MESSAGE URI-list service
creates a MESSAGE request per intended recipient (listed in the URI
list) and copies the instant message payload to each of those
MESSAGES. The MESSAGE URI-list service also manipulates the XML
resource list according to the procedures indicated in <a href="./rfc5364">RFC 5364</a>
[<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>], and attaches the result to each of the MESSAGE requests,
along with the instant message payload. Then the MESSAGE URI-list
service sends each of the created outgoing MESSAGE request to the
respective receiver.
The MESSAGE URI-list mechanism allows a sender to specify multiple
targets for a MESSAGE request by including an XML resource list
document according to <a href="./rfc4826">RFC 4826</a> [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] in the body of the MESSAGE
request extended with the attributes defined in <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>].
This resource list, whose Content-Disposition (<a href="./rfc2183">RFC 2183</a>) [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] is
'recipient-list', as specified in <a href="./rfc5363">RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>], includes the
URIs of the targets. Each target URI may also be marked to indicate
in what role the URI-list service will place the target (e.g., "to",
"cc", or "bcc"), and whether the target URI is expected to be
anonymized or not, according to the procedures described in <a href="./rfc5364">RFC 5364</a>
[<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. When the MESSAGE URI-list server expands the MESSAGE
request to each recipient, it includes (along with the instant
message payload) a new URI list (based on the received one), whose
Content-Disposition (<a href="./rfc2183">RFC 2183</a>) [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] is 'recipient-list-history',
as specified in <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. This new URI list includes the
list of non-anonymous "to" and "cc" targets, allowing recipients both
to get knowledge of other recipients and to reply to them.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. URI-List Document</span>
As described in <a href="./rfc5363">RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>], specifications of individual URI-
list services, like the MESSAGE URI-list service described here, need
to specify a default format for 'recipient-list' bodies used within
the particular service.
The default format for 'recipient-list' bodies for MESSAGE URI-list
services is the resource list document specified in <a href="./rfc4826">RFC 4826</a>
[<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] extended with the copy control attributes [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. UACs
and MESSAGE URI-list services handling 'recipient-list' bodies MUST
support both of these formats and MAY support other formats.
As described in <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>], each URI can be tagged with a
'copyControl' attribute set to either "to", "cc", or "bcc",
indicating the role in which the recipient will get the MESSAGE
request. Additionally, URIs can be tagged with the 'anonymize'
attribute to prevent that the MESSAGE URI-list server discloses the
target URI in a URI list.
Additionally, <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>] defines a 'recipient-list-history'
body that contains the list of intended recipients. The default
format for 'recipient-list-history' bodies for MESSAGE URI-list
services is also the resource list document specified in <a href="./rfc4826">RFC 4826</a>
[<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] extended with the copy control attributes [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>].
MESSAGE URI-list services MUST support both of these formats; UASs
MAY support these formats. MESSAGE URI-list servers and UASs MAY
support other formats.
The resource list document specified in <a href="./rfc4826">RFC 4826</a> [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] provides a
number of features that are not needed by the MESSAGE URI-list
service defined in this document. The MESSAGE URI-list service needs
to transfer a simple flat list of URIs between a UAC and the MESSAGE
URI-list server and between the MESSAGE URI-list server and the UAS.
The service does not need hierarchical lists or the ability to
include entries by reference relative to the Extensible Configuration
Access Protocol (XCAP) [<a href="./rfc4825" title=""The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)"">RFC4825</a>] root URI. Therefore, the MESSAGE
URI-list service specified herein only uses flat resource lists
documents that do not contain relative references.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Option-Tag</span>
This document defines the 'recipient-list-message' option-tag for use
in the Require and Supported SIP header fields.
This option-tag is used to ensure that a server can process the
'recipient-list' body used in a MESSAGE request. It also provides
a mechanism to discover the capability of the server in responses
to OPTIONS requests.
<a href="#section-6">Section 6</a> provides normative procedures for the usage of this option
tag.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Procedures at the User Agent Client</span>
A UAC that wants to create a multiple-recipient MESSAGE request
creates a MESSAGE request that MUST be formatted according to <a href="./rfc3428">RFC</a>
<a href="./rfc3428">3428</a> <a href="./rfc3428#section-4">[RFC3428] Section 4</a>. The UAC populates the Request-URI with the
SIP or SIPS URI of the MESSAGE URI-list service. In addition to the
regular instant message body, the UAC adds a recipient-list body
whose Content-Disposition type is 'recipient-list', specified in <a href="./rfc5363">RFC</a>
<a href="./rfc5363">5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>]. This body contains a URI list with the recipients of
the MESSAGE. Target URIs in this body MAY also be tagged with the
'copyControl' and 'anonymize' attributes specified in <a href="./rfc5364">RFC 5364</a>
[<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. The UAC MUST also include the 'recipient-list-message'
option-tag, defined in <a href="#section-5">Section 5</a>, in a Require header field.
UACs generating MESSAGE requests that carry recipient-list bodies, as
described in previous sections, MUST include this option-tag in a
Require header field. UAs that are able to receive and process
MESSAGEs with a recipient-list body, as described in previous
sections, SHOULD include this option-tag in a Supported header field
when responding to OPTIONS requests.
Multiple-recipient MESSAGE requests contain a multipart body that
contains the body carrying the list and the actual instant message
payload. In some cases, the MESSAGE request can contain bodies other
than the text and the list bodies (e.g., when the request is
protected with S/MIME as per <a href="./rfc3851">RFC 3851</a> [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>]).
Typically, the MESSAGE URI-list service will copy all the significant
header fields in the outgoing MESSAGE request. However, there might
be cases where the SIP UA wants the MESSAGE URI-list service to add a
particular header field with a particular value, even if the header
field wasn't present in the MESSAGE request sent by the UAC. In this
case, the UAC MAY use the "?" mechanism described in <a href="./rfc3261#section-19.1.1">Section 19.1.1
of RFC 3261</a> [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] to encode extra information in any URI in the
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
list. However, the UAC MUST NOT use the special "body" hname (see
<a href="./rfc3261#section-19.1.1">Section 19.1.1 of RFC 3261</a> [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]) to encode a body, since the
body is present in the MESSAGE request itself.
The following is an example of a URI that uses the "?" mechanism:
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
The previous URI requests the MESSAGE URI-list service to add the
following header field to a MESSAGE request to be sent to
bob@example.com:
Accept-Contact: *;mobility="mobile"
The resource list document format specified in <a href="./rfc4826">RFC 4826</a> [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>]
provides features, such as hierarchical lists and the ability to
include entries by reference relative to the XCAP root URI. However,
these features are not needed by the multiple MESSAGE URI-list
service defined in this document. Therefore, when using the default
resource list document, UAs SHOULD use flat lists (i.e., no
hierarchical lists) and SHOULD NOT use <entry-ref> elements.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Procedures at the MESSAGE URI-List Service</span>
On reception of a MESSAGE request containing a URI list, the MESSAGE
URI-list service answers to the UAC with a 202 (Accepted) response.
Note that the status code in the response to the MESSAGE does not
provide any information about whether or not the MESSAGEs
generated by the URI-list service were successfully delivered to
the URIs in the list. That is, a 202 (Accepted) response means
that the MESSAGE URI-list service has received the MESSAGE and
that it will try to send a similar MESSAGE to the URIs in the
list. Designing a mechanism to inform a client about the delivery
status of an instant message is outside the scope of this
document.
Since the MESSAGE URI-list service does not use hierarchical lists
nor lists that include entries by reference to the XCAP root URI, a
MESSAGE URI-list server receiving a URI list with more information
than what has just been described MAY discard all the extra
information.
If a MESSAGE request contains a Request-URI containing a URI that
uses the "?" mechanism (see <a href="./rfc3261#section-19.1.1">Section 19.1.1 of RFC 3261</a> [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]) and
such URI contains the special "body" hname to include an additional
body, the MESSAGE URI-list server MAY discard the contents of the
"body" parameter.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Determining the Intended Recipient</span>
On reception of a MESSAGE request containing a URI list, a MESSAGE
URI-list service determines the list of intended recipients by
inspecting the URI list contained in the body.
<a href="./rfc5363#section-4.1">Section 4.1 of RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>] discusses cases when duplicated
URIs are found in a URI list. In order to avoid duplicated requests,
MESSAGE URI-list services MUST take those actions specified in <a href="./rfc5363">RFC</a>
<a href="./rfc5363">5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>] into account to avoid sending duplicated requests to
the same recipient.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Creating an Outgoing MESSAGE Request</span>
Since the MESSAGE URI-list service behaves as a UAC for outgoing
MESSAGE requests, for each of the intended recipients, the MESSAGE
URI-list service creates a new MESSAGE request according to the
procedures described in <a href="./rfc3428#section-4">Section 4 of RFC 3428</a> [<a href="./rfc3428" title=""Session Initiation Protocol (SIP) Extension for Instant Messaging"">RFC3428</a>].
Additionally, <a href="./rfc5363#section-5.3">Section 5.3 of RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>] provides additional
general guidance in creating outgoing requests. This document also
specifies the following procedures:
o A MESSAGE URI-list service MUST include a From header field whose
value is the same as the From header field included in the
incoming MESSAGE request, subject to the privacy requirements (see
<a href="./rfc3323">RFC 3323</a> [<a href="./rfc3323" title=""A Privacy Mechanism for the Session Initiation Protocol (SIP)"">RFC3323</a>] and <a href="./rfc3325">RFC 3325</a> [<a href="./rfc3325" title=""Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks"">RFC3325</a>]) expressed in the
incoming MESSAGE request.
Note that this does not apply to the "tag" parameter.
Failure to copy the From header field of the sender results in
unacceptable security and privacy failures. Note also that
this requirement does not intend to contradict requirements for
additional services running on the same physical node.
Specifically, a privacy service (see <a href="./rfc3323">RFC 3323</a> [<a href="./rfc3323" title=""A Privacy Mechanism for the Session Initiation Protocol (SIP)"">RFC3323</a>]) can be
co-located with the MESSAGE URI-list service, in which case,
the privacy service has precedence over the MESSAGE URI-list
service.
o A MESSAGE URI-list service SHOULD generate a new To header field
value set to the intended recipient's URI. According to the
procedures of <a href="./rfc3261">RFC 3261</a> <a href="./rfc3261#section-8.1.1.1">[RFC3261] Section 8.1.1.1</a>, this value is
also expected to be equal to the Request-URI of the outgoing
MESSAGE request.
The MESSAGE URI-list service behaves as a User Agent Client;
thus, the To header field should be populated with the
recipient's URI.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
o A MESSAGE URI-list service SHOULD create a new Call-ID header
field value.
A Call-ID header field might contain addressing information
that the sender wants to remain private. Since there is no
need to keep the same Call-ID on both sides of the MESSAGE URI-
list service, and since the MESSAGE URI-list service behaves as
a User Agent Client, it is recommended to create a new Call-ID
header field value according to the regular SIP procedures.
o If a P-Asserted-Identity header field was present in the incoming
MESSAGE request and the request was received from a trusted
source, as specified in <a href="./rfc3325">RFC 3325</a> [<a href="./rfc3325" title=""Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks"">RFC3325</a>], and the first hop of
the outgoing MESSAGE request is also trusted, a MESSAGE URI-list
service MUST include a P-Asserted-Identity header field in the
outgoing MESSAGE request with the same received value. However,
if the first hop of the outgoing MESSAGE request is not trusted
and the incoming MESSAGE request included a Privacy header field
with a value different than 'none', the MESSAGE URI-list service
MUST NOT include a P-Asserted-Identity header field in the
outgoing MESSAGE request.
o If a MESSAGE URI-list service is able to assert the identity of a
user (e.g., using HTTP Digest authentication scheme as per <a href="./rfc2617">RFC</a>
<a href="./rfc2617">2617</a> [<a href="./rfc2617" title=""HTTP Authentication: Basic and Digest Access Authentication"">RFC2617</a>], S/MIME as per <a href="./rfc3851">RFC 3851</a> [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>], etc.) and the
service implements a mechanism where it can map that
authentication scheme to a user's SIP or SIPS URI, and subject to
the privacy requirements expressed in the incoming MESSAGE request
(see <a href="./rfc3323">RFC 3323</a> [<a href="./rfc3323" title=""A Privacy Mechanism for the Session Initiation Protocol (SIP)"">RFC3323</a>]), the MESSAGE URI-list service MAY insert
a P-Asserted-Identity header with the value of the user's asserted
URI.
o If the incoming MESSAGE request contains an Authorization or
Proxy-Authorization header field whose realm is set to the MESSAGE
URI-list server's realm, then the MESSAGE URI-list service SHOULD
NOT copy it to the outgoing MESSAGE request; otherwise (i.e., if
the Authorization or Proxy-Authorization header field of incoming
MESSAGE request contains a different realm), the MESSAGE URI-list
service MUST copy the value to the respective header field of the
outgoing MESSAGE request.
o A MESSAGE URI-list service SHOULD create a separate count for the
CSeq header field [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] of the outgoing MESSAGE request.
o A MESSAGE URI-list service SHOULD initialize the value of the Max-
Forward header field of the outgoing MESSAGE request.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
o A MESSAGE URI-list service MUST include its own value in the Via
header field.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Composing Bodies in the Outgoing MESSAGE Request</span>
When creating the body of each of the outgoing MESSAGE requests, the
MESSAGE URI-list service keeps the relevant bodies of the incoming
MESSAGE request and copies them to the outgoing MESSAGE request. The
following guidelines constitute exceptions to the general body
handling:
o A MESSAGE request received at a MESSAGE URI-list service can
contain one or more security bodies (e.g., S/MIME, <a href="./rfc3851">RFC 3851</a>
[<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>]) encrypted with the public key of the MESSAGE URI-list
service. These bodies are deemed to be read by the URI-list
service rather than the recipient of the outgoing MESSAGE request
(which will not be able to decrypt them). Therefore, a MESSAGE
URI-list service MUST NOT copy any security body (such as an
S/MIME as per <a href="./rfc3851">RFC 3851</a> [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>] encrypted body) addressed to the
MESSAGE URI-list service to the outgoing MESSAGE request. This
includes bodies encrypted with the public key of the URI-list
service.
o The incoming MESSAGE request typically contains a recipient-list
body or reference, as indicated in <a href="./rfc5363">RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>] with the
actual list of recipients. If this URI list includes resources
tagged with the 'copyControl' attribute set to a value of "to" or
"cc", the URI-list service SHOULD include a URI list in each of
the outgoing MESSAGE requests. This list SHOULD be formatted
according to the resource list document format specified in <a href="./rfc4826">RFC</a>
<a href="./rfc4826">4826</a> [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] and the copyControl extension specified in <a href="./rfc5364">RFC 5364</a>
[<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>]. The MESSAGE URI-list service MUST follow the
procedures specified in <a href="./rfc5364">RFC 5364</a> [<a href="./rfc5364" title=""Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists"">RFC5364</a>] with respect to
handling of the 'anonymize', 'count', and 'copyControl'
attributes.
o If the MESSAGE URI-list service includes a URI list in an outgoing
MESSAGE request, it MUST include a Content-Disposition header
field as per <a href="./rfc2183">RFC 2183</a> [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] with the value set to 'recipient-
list-history' and a "handling" parameter as per <a href="./rfc3204">RFC 3204</a> [<a href="./rfc3204" title=""MIME media types for ISUP and QSIG Objects"">RFC3204</a>]
set to "optional".
o If a MESSAGE URI-list service includes a URI list in an outgoing
MESSAGE request, it SHOULD use S/MIME (<a href="./rfc3851">RFC 3851</a>) [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>] to
encrypt the URI list with the public key of the receiver.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
o The MESSAGE URI-list service SHOULD copy all the remaining message
bodies (e.g., text messages, images, etc.) of the incoming MESSAGE
request to the outgoing MESSAGE request.
o If there is only one body left, the MESSAGE URI-list service MUST
remove the multipart/mixed wrapper in the outgoing MESSAGE
request.
The rest of the MESSAGE request corresponding to a given URI in the
URI list MUST be created following the rules in <a href="#section-19.1.5">Section 19.1.5</a>,
"Forming Requests from a URI", of <a href="./rfc3261">RFC 3261</a> [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]. In particular,
<a href="./rfc3261#section-19.1.5">Section 19.1.5 of RFC 3261</a> [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] states:
"An implementation SHOULD treat the presence of any headers or
body parts in the URI as a desire to include them in the message,
and choose to honor the request on a per-component basis."
SIP allows to append a "method" parameter to a URI. Therefore, it is
legitimate that the 'uri' attribute of the <entry> element in the XML
resource list contains a "method" parameter. MESSAGE URI-list
services MUST generate only MESSAGE requests, regardless of the
"method" parameter that the URIs in the list indicate. Effectively,
MESSAGE URI-list services MUST ignore the "method" parameter in each
of the URIs present in the URI list.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Procedures at the UAS</span>
A UAS (in this specification, also known as intended recipient UAS)
that receives a MESSAGE request from the MESSAGE URI-list service
behaves as specified in <a href="./rfc3428">RFC 3428</a> <a href="./rfc3428#section-7">[RFC3428] Section 7</a>.
If the UAS supports this specification and the MESSAGE request
contains a body with a Content-Disposition header field as per <a href="./rfc2183">RFC</a>
<a href="./rfc2183">2183</a> [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] set to 'recipient-list-history', then the UAS will be
able to determine the SIP Address-of-Record (AOR) of the other
intended recipients of the MESSAGE request. This allows the user to
create a reply request (e.g., MESSAGE, INVITE) to the sender and the
rest of the recipients included in the URI list.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Examples</span>
Figure 1 shows an example of operation. A SIP UAC issuer sends a
MESSAGE request. The MESSAGE URI-list service answers with a 202
(Accepted) response and sends a MESSAGE request to each of the
intended recipients.
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 MESSAGE | | | |
| ---------------->| | | |
| F2 202 Accepted | | | |
|<---------------- | F3 MESSAGE | | |
| | ------------->| | |
| | F4 MESSAGE | | |
| | ------------------------>| |
| | F5 MESSAGE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operation
The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed
body that is composed of two bodies: a text/plain body containing the
instant message payload and an application/resource-lists+xml body
containing the list of recipients.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
MESSAGE sip:list-service.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: MESSAGE URI-list service <sip:list-service.example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE
Require: recipient-list-message
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
--boundary1
Content-Type: text/plain
Hello World!
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
--boundary1--
Figure 2: MESSAGE request received at the MESSAGE URI-list server
The MESSAGE requests F3, F4, and F5 are similar in nature. All those
MESSAGE requests contain a multipart/mixed body that is composed of
two other bodies: a text/plain body containing the instant message
payload and an application/resource-lists+xml containing the list of
recipients. Unlike the text/plain body, the application/
resource-lists+xml bodies of MESSAGE requests F3, F4, and F5 are not
equal to the application/resource-lists+xml body included in the
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
incoming MESSAGE request F1. This is because the URI-list service
has anonymized those URIs tagged with the 'anonymize' attribute and
has removed those URIs tagged with a "bcc" 'copyControl' attribute;
besides, the content disposition of these bodies is different.
Figure 3 shows an example of the MESSAGE request F3.
MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com
;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70
To: <sip:bill@example.com>
From: Alice <sip:alice@example.com>;tag=210342
Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
--boundary1
Content-Type: text/plain
Hello World!
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
--boundary1--
Figure 3: MESSAGE request sent by the MESSAGE URI-list server
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Security Considerations</span>
<a href="./rfc5363">RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>] discusses issues related to SIP URI-list services.
Implementations of MESSAGE URI-list services MUST follow the
security-related rules in <a href="./rfc5363">RFC 5363</a> [<a href="./rfc5363" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services"">RFC5363</a>]. These rules include
opt-in lists and mandatory authentication and authorization of
clients.
If the contents of the instant message needs to be kept private, the
User Agent Client SHOULD use S/MIME as per <a href="./rfc3851">RFC 3851</a> [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>] to
prevent a third party from viewing this information. In this case,
the user agent client SHOULD encrypt the instant message body with a
content encryption key. Then, for each receiver in the list, the UAC
SHOULD encrypt the content encryption key with the public key of the
receiver, and attach it to the MESSAGE request.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. IANA Considerations</span>
This document defines the SIP option tag 'recipient-list-message'
The following row has been added to the "Option Tags" section of the
SIP Parameter Registry:
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-message | The body contains a list of | [<a href="./rfc5365">RFC5365</a>] |
| | URIs that indicates the | |
| | recipients of the SIP | |
| | MESSAGE request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-message' Option-Tag
in SIP
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Acknowledgements</span>
Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben
Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean
Willis, and Keith Drage provided helpful comments.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. References</span>
<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2183">RFC2183</a>] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", <a href="./rfc2183">RFC 2183</a>, August 1997.
[<a id="ref-RFC2617">RFC2617</a>] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
<a href="./rfc2617">RFC 2617</a>, June 1999.
[<a id="ref-RFC3204">RFC3204</a>] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", <a href="./rfc3204">RFC 3204</a>, December 2001.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
[<a id="ref-RFC3323">RFC3323</a>] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", <a href="./rfc3323">RFC 3323</a>, November 2002.
[<a id="ref-RFC3325">RFC3325</a>] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", <a href="./rfc3325">RFC 3325</a>,
November 2002.
[<a id="ref-RFC3428">RFC3428</a>] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", <a href="./rfc3428">RFC 3428</a>, December 2002.
[<a id="ref-RFC3851">RFC3851</a>] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
<a href="./rfc3851">RFC 3851</a>, July 2004.
[<a id="ref-RFC4826">RFC4826</a>] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", <a href="./rfc4826">RFC 4826</a>, May 2007.
[<a id="ref-RFC5363">RFC5363</a>] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-
List Services", <a href="./rfc5363">RFC 5363</a>, October 2008.
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
[<a id="ref-RFC5364">RFC5364</a>] Garcia-Martin, M. and G. Camarillo, "Extensible Markup
Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists", <a href="./rfc5364">RFC 5364</a>,
October 2008.
<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>. Informative References</span>
[<a id="ref-RFC4825">RFC4825</a>] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", <a href="./rfc4825">RFC 4825</a>, May 2007.
[<a id="ref-RFC4975">RFC4975</a>] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", <a href="./rfc4975">RFC 4975</a>, September 2007.
Authors' Addresses
Miguel A. Garcia-Martin
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
EMail: miguel.a.garcia@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
<span class="grey">Garcia-Martin & Camarillo Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5365">RFC 5365</a> SIP Multiple-Recipient MESSAGE Requests October 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Garcia-Martin & Camarillo Standards Track [Page 18]
</pre>
|
