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
|
<pre>Network Working Group M. Garcia-Martin
Request for Comments: 5364 G. Camarillo
Category: Standards Track Ericsson
October 2008
<span class="h1">Extensible Markup Language (XML) Format Extension for Representing</span>
<span class="h1">Copy Control Attributes in Resource Lists</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
In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs). The sender sends a single SIP request to a server which
further distributes the request to the group. This SIP request
contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request. This URI list is
expressed as a resource list XML document. This specification
defines an XML extension to the XML resource list format that allows
the sender of the request to qualify a recipient with a copy control
level similar to the copy control level of existing email systems.
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 of Operation . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Extension to the Resource List Data Format . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-7">7</a>. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9.1">9.1</a>. Disposition Type Registration . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9.2">9.2</a>. XML Namespace Registration . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9.3">9.3</a>. XML Schema Registration . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-10">10</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-15">15</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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</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>] describes a generic framework for carrying Uniform
Resource Identifier (URI) lists in SIP [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] messages.
Specifically, the document provides a common framework for specific
implementations of URI-list services, such as conferences initiated
with INVITE requests [<a href="./rfc5366" title=""Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)"">RFC5366</a>] or Multiple-recipient MESSAGE requests
[<a href="./rfc5365" title=""Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)"">RFC5365</a>].
Common to all URI-list services is the presence of a SIP request that
contains a collection of resources, typically expressed as an XML
resource list [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>]. SIP requests carrying resource lists can
appear either in requests received by the URI-list server, indicating
the list of intended recipients, or in each of the requests that the
URI-list server sends to recipients, indicating the list of
recipients of the same SIP request.
Although the XML resource list [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] provides a powerful
mechanism for describing a list of resources, there is a need for a
copy control attribute to determine whether a resource is receiving a
SIP request as a primary recipient, a carbon copy, or a blind carbon
copy. This is similar to common email systems, where the sender can
categorize each recipient as a "to", "cc", or "bcc" recipient.
This document addresses this problem by providing an extension to the
XML resource list [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] that enables the sender to supply a copy
control attribute that labels each recipient as a "to", "cc", or
"bcc" recipient. This attribute indicates whether the recipient is
receiving a primary copy of the SIP request, a carbon copy, or a
blind carbon copy. Additionally, we provide the sender with the
capability of indicating in the URI list that one or more resources
should be anonymized, so that some recipients' URIs are not disclosed
to the other recipients. Instead, these URIs are replaced with
anonymous URIs.
The remainder of this document is organized as follows: <a href="#section-2">Section 2</a>
introduces the terminology used throughout this specification.
<a href="#section-3">Section 3</a> gives an overview of operation. <a href="#section-4">Section 4</a> formally defines
an extension to URI lists. The XML schema definition is provided in
<a href="#section-5">Section 5</a>. <a href="#section-6">Section 6</a> shows examples of the URI lists with the
extensions defined in this document. <a href="#section-7">Section 7</a> discusses the
implications of carrying URI lists in SIP messages.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
<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.
URI-list service: SIP application service that receives a SIP
request containing a URI list and sends a similar SIP request to
each URI in the list.
Intended recipient: The intended final recipient of the request to
be generated by URI-list service.
Copy control: An attribute assigned by the sender to a URI in an
XML resource list. Its purpose is to indicate to the recipient
whether he is getting a primary, carbon, or blind carbon copy of
the SIP request.
Recipient list or recipient XML resource list: An XML resource list
containing the list of intended recipients. The sender sets this
list in the SIP request he sends to the URI-list server.
Recipient-history list or recipient-history XML resource list: An
XML resource list containing the visible list of recipients (i.e.,
those non-anonymous non-bcc). The URI-list server creates this
list, based on the recipient list, and includes it in each of the
SIP requests it sends to each recipient.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview of Operation</span>
Figure 1 depicts a general overview of the operation of a URI-list
server. A SIP User Agent Client (UAC) issuer sends a SIP request
(F1) to a URI-list server containing a recipient list. The URI-list
server generates a SIP request to each recipient, according to the
specific SIP method. Each of these SIP requests contains a
recipient-history list that indicates the visible list of recipients
of the SIP request.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | |
| F2 2xx response | | | |
|<---------------- | F3 SIP request | | |
| | (recp-hist.list)| | |
| | --------------->| | |
| | F4 SIP request | | |
| | (recp-hist.list)| | |
| | -------------------------->| |
| | F5 SIP request | | |
| | (recp-hist.list)| | |
| | ------------------------------------->|
| | F6 200 OK | | |
| |<--------------- | | |
| | F7 200 OK | | |
| |<-------------------------- | |
| | F8 200 OK | | |
| |<------------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operation
The URI-list mechanism allows a sender to specify multiple targets
for a SIP request by including a recipient XML resource list
[<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] in the body of the SIP request. This recipient list
includes the target URIs of the SIP request (the actual procedures
are method specific and outside the scope of this document). Each
target URI may also be marked with a copy control attribute to
indicate the copy level in which the recipient is receiving the SIP
request. This is achieved by the sender qualifying each URI in the
URI list with a 'copyControl' attribute. The available values of the
'copyControl' attribute include "to", "cc", and "bcc" (analogous to
email). This is discussed in greater detail in <a href="#section-4">Section 4</a>. When the
URI-list server expands the request to each recipient, the URI-list
server includes a recipient-history XML resource list built upon the
recipient list received from the sender. The recipient-history XML
resource list replaces the recipient list in the SIP requests
generated by the URI-list server towards each recipient. The URI-
list server copies from the recipient list those targets that are
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
marked with the "to" and "cc" copy control level, and pastes them in
the recipient-history list. The URI-list server explicitly excludes
from the recipient-history list those URIs marked with a "bcc" copy
control, although it is able to preserve the address of a "bcc"
tagged URI when it matches the URI of the recipient of the SIP
request (this is described later in <a href="#section-4">Section 4</a>). When a recipient
receives the SIP request containing the recipient-history XML
resource list, he is able to determine which other visible recipients
are getting a copy of the SIP request, and whether they are marked
with the "to" or "cc" copy control level. Later, if needed, the
recipient can generate a reply to those visible recipients.
In addition to the 'copyControl' attribute for a URI in an XML
resource list, we define a second boolean attribute called
'anonymize'. The sender of a SIP request can mark a URI in a
recipient XML resource list with the 'anonymize' attribute to
indicate the URI-list server that the URI marked with that attribute
is to be replaced with an anonymous URI in the recipient-history XML
resource list. This provides knowledge to the recipients of a SIP
request of the number of additional visible recipients whose URIs
have not been disclosed.
There are cases when the sender marks several URIs with the
'anonymize' attribute. The URI-list server can group the anonymized
URIs in a single anonymized URI within its copy control level, and
provide a count of the number of anonymized URIs. To support this
scenario, we define a new 'count' attribute to a URI in the
recipient-history XML resource list. It is expected that the 'count'
attribute is only used with anonymous URIs, although syntactically it
is possible to add a 'count' attribute to any URI in any XML resource
list.
Initially, it may be thought that the 'anonymize' attribute overlaps
with the "bcc" value of the 'copyControl' attribute. However, there
are differences between them. If the sender qualifies a URI with a
'copyControl' attribute of "bcc" in the recipient XML resource list,
the URI-list server will typically remove that URI from the
recipient-history XML resource list (unless the URI-list server
decides to preserve a "bcc" marked URI when that URI is itself the
recipient of the SIP request). Recipients of the SIP request will
not notice that one or more extra "bcc" URIs also received the
request. However, if the sender qualifies a URI with the 'anonymize'
attribute in the recipient XML resource list, the URI-list server
will replace the URI with an anonymous one in the recipient-history
list. Recipients of the SIP request will notice that there have been
one or more additional recipients of the same request, but their URIs
are not disclosed.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Extension to the Resource List Data Format</span>
This document defines an extension to the XML resource list data
format [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>] that allows the sender to indicate a copy control
attribute that qualifies a recipient with a copy control level. We
define a new 'copyControl' attribute to the <entry> element of the
resource list document format [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>]. The 'copyControl' attribute
has similar semantics to the type of destination address in email
systems. It can take the values "to", "cc", and "bcc". A "to" value
of the 'copyControl' attribute indicates that the resource is
considered a primary recipient of the SIP request. A "cc" value
indicates that the resource receives a carbon copy of the SIP
request. A "bcc" value indicates that the resource receives a blind
carbon copy of the SIP request (i.e., this URI is not disclosed to
other recipients of the SIP request). The default 'copyControl'
value is "bcc". That is, the absence of a 'copyControl' attribute
MUST be treated as if the 'copyControl' was set to "bcc".
When creating a recipient-history list, URI-list servers use "bcc"
'copyControl' attributes to route SIP requests. In addition, URI-
list servers behave similarly to email systems [<a href="./rfc2822" title=""Internet Message Format"">RFC2822</a>] with respect
to the treatment of these URIs marked with a "bcc" copy control,
because they have two ways of treating "bcc" marked URIs. URI-list
servers MUST treat these "bcc" marked URIs in either of the following
two ways:
o URI-list servers MUST remove all URIs marked with a "bcc" copy
control in recipient-history lists. This mechanism allows URI-
list servers to send the same recipient-history list to each
recipient of the SIP request. However, recipients who are tagged
with "bcc" values are not explicitly informed about it.
o URI-list servers MUST preserve with a "bcc" copy control in the
recipient-history list the URI that identifies the recipient (if
any) and MUST remove the remaining URIs marked with a "bcc" copy
control. Consequently, each recipient receives a different
recipient-history list. However, recipients who have been marked
with a "bcc" copy control are explicitly informed about it.
Implementations that are able to receive recipient-history lists must
pay attention to the contents of the list. If the recipient's URI is
not included in the recipient-history list or if it is included but
tagged with a "bcc" copy control, then implementations SHOULD prevent
the user from replying to all the recipients of the SIP request.
This would allow the non-blind recipients to notice the existence of
blind recipients of the SIP request.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
A new 'anonymize' attribute can be included in a <entry> element of
the resource list document format [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>]. If set to a "true"
value, it provides an indication to the URI-list server for not
disclosing the URI itself in a URI list sent to the recipient, but
instead to anonymize the URI (i.e., making it bogus in the recipient-
history XML resource list). URI-list servers can use URIs tagged
with the 'anonymize' attribute for routing SIP requests, but MUST
convert them to the SIP URI "sip:anonymous@anonymous.invalid" in
recipient-history lists. The default value of the 'anonymize'
attribute is "false".
There are occasions where the URI-list server encounters the same URI
entry duplicated in a resource list, where duplicated URI entries are
tagged with the same or different values of the 'copyControl'
attribute. There are no reasonable usages that justify duplicated
URIs in resource lists; thus, this is considered an error. URI-list
servers should not send duplicated copies of the same SIP request to
the same intended recipient. In case the URI-list server encounters
the same URI entry duplicated in a resource list, it should send at
most a single copy of the request to that intended recipient. For
each set of duplicated URI entries, the URI-list server MUST select
the highest precedence value of the 'copyControl' attribute for the
same intended recipient. The order of precedence of the values of
the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI-
list server has selected a value for the 'copyControl' attribute of
an intended recipient, the URI-list server can continue processing
the request.
Processing of URIs tagged with a 'copyControl' attribute set to a
"bcc" value has higher precedence over the 'anonymize' attribute.
Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list
server MUST remove that URI from the recipient-history list, and the
'anonymize' attribute will be ignored. Therefore, the 'anonymize'
attribute is only useful for those URIs tagged with a 'copyControl'
of "to" or "cc".
A new 'count' attribute can be also included in an <entry> element of
the resource list document format [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>]. It provides the number
of equal URIs. Typically, recipient lists created by UACs will not
have equal (or duplicate) URI entries; thus, it is not expected to
contain URIs tagged with 'count' attributes. However, recipient-
history lists can contain duplicated anonymized URIs; therefore, it
is expected that recipient-history lists will contain 'count'
attributes. The default value of the 'count' attribute is "1".
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
The 'copyControl', 'anonymize', and 'count' attributes SHOULD be
included as modifiers of any of the child elements included in the
<list> element of a resource list (e.g., attribute of the <entry> or
<external> elements).
<a href="#section-5">Section 5</a> describes the format of the 'copyControl', 'anonymize', and
'count' attributes. Implementations according to this specification
MUST support this XML schema.
Implementations that receive recipient-history lists must pay
attention to the contents of the list. If the recipient's URI is not
included in recipient-history list or if it is included but tagged
with a "bcc" copy control, then they SHOULD prevent the user from
replying to all the recipients of the SIP request. This would allow
the non-blind recipients to notice the existence of blind recipients
in the original SIP request.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. XML Schema</span>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="copyControl">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
</xs:schema>
Figure 2: XML schema of the extension to the resource list format
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Examples</span>
This section shows two examples of URI lists that can be included in
SIP requests. The first example in Figure 3 shows a recipient list
that the UAC sends to the URI-list server. This corresponds to a
list that will be included in the flow F2 in Figure 1. The recipient
list contains a flat list according to the resource list data format
specified in <a href="./rfc4826">RFC 4826</a> [<a href="./rfc4826" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">RFC4826</a>]. Each resource indicates the copy
control of a resource with a 'copyControl' attribute. Some of the
resources are also marked with the 'anonymize' attribute. This
provides an indication to the URI-list service for not disclosing
their URIs in a recipient-history list. The last two <entry>
elements are marked with a 'copyControl' attribute of "bcc". This
provides an indication to the URI-list server for removing these URIs
in the recipient-history 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>
Figure 3: Recipient list sent from the UAC to the URI-list server
Upon receipt of the SIP request containing the recipient list of
Figure 3, the URI-list server creates a SIP request to each of the
URIs listed in the recipient list (so, in our example, it creates 7
SIP requests). The URI-list server processes the recipient list and
creates a recipient-history list that is included in each of the
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
outgoing SIP requests. The process is as follows: the URI-list
server creates a new recipient-history list, based on the recipient
list, but with changes. First, it copies all the URIs (<entry>
elements) marked with the "to" or "cc" 'copyControl' attributes,
which do not contain an 'anonymize' attribute (or when the
'anonymize' attribute is set to "false"). Then all the URIs marked
with a 'copyControl' attribute set to "to" and 'anonymize' attribute
set to "true" are replaced with the SIP anonymous URI
"sip:anonymous@anonymous.invalid". In this entry, the URI-list
server also adds the original value of the 'copyControl' attribute
("to" in our example), and it adds a 'count' attribute containing the
number of anonymous entries in this group ("2" in our example). Then
the URI-list server does the same operation to the URIs tagged with
the 'copyControl' attribute set to "cc" and 'anonymize' attribute set
to "true", adding also the 'count' attribute containing the number of
anonymous attributes in this group ("1" in the example). Last, the
URI-list server removes all URIs marked with the "bcc" 'copyControl'
attribute. The resulting recipient-history list is shown in
Figure 4.
<?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>
Figure 4: Recipient-history list sent from the URI-list server to
each recipient
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Carrying URI Lists in SIP</span>
A SIP UAC (User Agent Client) that composes a SIP request can include
a URI list with the extensions specified in this document to indicate
the list of intended recipients. On doing so, as 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>], the UAC adds a Content-Disposition [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] header
field set to the value 'recipient-list'. Typically UACs send these
'recipient-list' bodies to URI-list services (this corresponds to
flow F1 in Figure 1). A body whose Content-Disposition type is
'recipient-list' contains a URI list that includes the intended
recipients of the SIP request, something known throughout this
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
document as a recipient list. The <entry> element in the URI list
MAY also include a 'copyControl' and 'anonymize' attributes, as
specified in <a href="#section-4">Section 4</a>.
To be able to inform intended recipients of who else is receiving a
copy of the SIP request, we define a new mail disposition type to be
included in a Content-Disposition [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>] header field of a SIP
request. The value of this new disposition type is 'recipient-list-
history' and its purpose is to indicate a list of recipients that a
SIP request was sent to, something known throughout this document as
a recipient-history list. A body whose Content-Disposition type is
'recipient-list-history' contains a URI list with the visible
(including anonymized) recipients of the SIP request. The <entry>
element in the URI list MAY also include a 'copyControl' and 'count'
attributes, as specified in <a href="#section-4">Section 4</a>.
On sending a SIP request that contains a recipient-history list, if
the intended recipient does not support this specification, the SIP
request should not fail. In order to ensure successful receipt of
the SIP requests that include 'recipient-list-history' bodies, User
Agents (such as URI-list servers) that build SIP requests with the
Content-Disposition header field set to 'recipient-list-history'
SHOULD add a "handling" parameter [<a href="./rfc3204" title=""MIME media types for ISUP and QSIG Objects"">RFC3204</a>] set to "optional".
Otherwise, the SIP request could fail and never be received by the
intended recipient.
Even though "Message Body Handling in SIP" [<a href="#ref-SIP_BODY" title=""Message Body Handling in the Session Initiation Protocol (SIP)"">SIP_BODY</a>] mandates
support for multipart bodies, legacy recipients may not support them.
In such a case, if the request sent by the relay to the recipient
needs to contain another body (e.g., a MESSAGE request carrying a
message in its body), the relay will not be able to use this
extension because the recipient would not be able to process a
multipart body with the original body plus the 'recipient-list-
history' body.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</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 this specification 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.
User Agent Clients SHOULD NOT hand SIP requests containing URI-list
services to unauthenticated and untrusted parties. This is to avoid
man-in-the-middle attacks or acquiring URI lists for performing spam
attacks.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
URI lists may contain private information, such as SIP URIs. It is
therefore not desirable that these URI lists are known by third
parties. Eavesdroppers are able to watch URI lists contained in SIP
requests unless the SIP message is sent over a secured channel, by
using any of the available SIP mechanisms, such as Transport Layer
Security (TLS) [<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>], or unless the URI-list body itself is
encrypted with, e.g., S/MIME [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>]. Therefore, it is RECOMMENDED
that URI-list bodies are encrypted with S/MIME [<a href="./rfc3851" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"">RFC3851</a>] or that the
SIP request is encrypted with TLS [<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>] or any other suitable
encryption mechanism.
Note that this URI list does not indicate the actual participants in
the session. It indicates only the URIs invited and that might
accept the request. It does not assert that these parties actually
exist, that they are reachable at the given URI, or that they have
accepted the invitation. No inferences about billing should be made
from this information. It is subject to spoofing by loading the list
with falsified content.
Issuers of SIP request use the "bcc" copy control attribute described
in <a href="#section-4">Section 4</a> to facilitate sending SIP requests to recipients without
revealing the URIs of one or more of the other recipients.
Mishandling this use of "bcc" copy control has implications for
confidential information that might be revealed, which could
eventually lead to security problems through knowledge of even the
existence of a particular URI. For example, if using the first
method described in <a href="#section-4">Section 4</a>, where the "bcc" tagged URIs are
removed from the recipient-history list, blind recipients have no
explicit indication that they have been sent a blind copy of the SIP
request, except insofar as their URI does not appear in the
recipient-history list. Because of this, one of the blind URIs could
potentially send a reply to all of the shown recipients and
accidentally reveal that the message went to the blind recipient.
When the second method from <a href="#section-4">Section 4</a> is used, the blind recipient's
address appears in the recipient-history list of a separate copy of
the list. If the "bcc" tagged URI sent contains all of the "bcc"
tagged URIs, all of the "bcc" recipients will be seen by each "bcc"
recipient. Even if a separate message is sent to each "bcc"
recipient with only the individual's URI, implementations still need
to be careful to process replies to the message as per <a href="#section-4">Section 4</a> so
as not to accidentally reveal the blind recipient to other
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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA has made registrations according to the following subsections: a
new disposition type, a new XML namespace, and a new XML schema.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Disposition Type Registration</span>
<a href="#section-7">Section 7</a> defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value has been registered
in the IANA registry of Mail Content Disposition Values with the
following registration data:
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [<a href="./rfc5364">RFC5364</a>] |
| | URIs that indicates the | |
| | recipients of the request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. XML Namespace Registration</span>
This section registers a new XML namespace in the IANA XML registry,
as per the guidelines in <a href="./rfc3688">RFC 3688</a> [<a href="./rfc3688" title=""The IETF XML Registry"">RFC3688</a>].
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org),
Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"<a href="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd</a>">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title>
</head>
<body>
<h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1>
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
<h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
<a href="./rfc5364">RFC5364</a></a>.</p>
</body>
</html>
END
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. XML Schema Registration</span>
This section registers a new XML schema in the IANA XML registry per
the procedures in <a href="./rfc3688">RFC 3688</a> [<a href="./rfc3688" title=""The IETF XML Registry"">RFC3688</a>].
URI: urn:ietf:params:xml:schema:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org),
Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
The XML for this schema can be found as the sole content of
<a href="#section-5">Section 5</a>.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato,
Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris
Newman for reviewing this document and providing helpful comments.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.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-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-RFC3688">RFC3688</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
January 2004.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
[<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-RFC4346">RFC4346</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", <a href="./rfc4346">RFC 4346</a>, April 2006.
[<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="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC2822">RFC2822</a>] Resnick, P., "Internet Message Format", <a href="./rfc2822">RFC 2822</a>,
April 2001.
[<a id="ref-RFC5366">RFC5366</a>] Camarillo, G. and A. Johnston, "Conference Establishment
Using Request-Contained Lists in the Session Initiation
Protocol (SIP)", <a href="./rfc5366">RFC 5366</a>, October 2008.
[<a id="ref-RFC5365">RFC5365</a>] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol
(SIP)", <a href="./rfc5365">RFC 5365</a>, October 2008.
[<a id="ref-SIP_BODY">SIP_BODY</a>] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", Work in Progress,
August 2008.
<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="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists October 2008</span>
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 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5364">RFC 5364</a> Copy Control Attribute in Resource Lists 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 17]
</pre>
|
