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
|
<pre>Network Working Group J. Hautakorpi
Request for Comments: 5318 G. Camarillo
Category: Informational Ericsson
December 2008
<span class="h1">The Session Initiation Protocol (SIP)</span>
<span class="h1">P-Refused-URI-List Private-Header (P-Header)</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/</a>
<a href="http://trustee.ietf.org/license-info">license-info</a>) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies the Session Initiation Protocol (SIP)
P-Refused-URI-List Private-Header (P-Header). This P-Header is used
in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC)
system. It enables URI-list servers to refuse the handling of
incoming URI lists that have embedded URI lists. This P-Header also
makes it possible for the URI-list server to inform the client about
the embedded URI list that caused the rejection and the individual
URIs that form such a URI list.
<span class="grey">Hautakorpi & Camarillo Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
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-2">2</a>
<a href="#section-3">3</a>. Usage Scenario ..................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Overview of Operation ...........................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Syntax of P-Refused-URI-List Header Field .......................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Response Generation .............................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. Message Sequence Example ........................................<a href="#page-7">7</a>
<a href="#section-8">8</a>. Applicability ...................................................<a href="#page-9">9</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-11">11</a>
<a href="#section-11">11</a>. Acknowledgements ..............................................<a href="#page-11">11</a>
<a href="#section-12">12</a>. References ....................................................<a href="#page-11">11</a>
<a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-11">11</a>
<a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Open Mobile Alliance (OMA) has specified the Push to talk over
Cellular (PoC) service, which uses the Session Initiation Protocol
(SIP) [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>] and Uniform Resource Identifier (URI)-list services [<a href="#ref-5" title=""Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services"">5</a>]
(more information about OMA PoC can be found at [<a href="#ref-8" title=""OMA PoC System Description: Draft Version 2.0"">8</a>]).
OMA PoC needs a mechanism for servers to refuse the handling of
incoming URI lists when these have embedded URI lists. Such a
mechanism is intended to be used to establish a particular type of
PoC session called an ad-hoc PoC group session.
The remainder of this document is organized as follows. <a href="#section-3">Section 3</a>
describes the scenario where the mechanism will be used. <a href="#section-4">Section 4</a>
provides an overview of the mechanism, which includes a new P-Header
called P-Refused-URI-List. <a href="#section-5">Section 5</a> defines the syntax of this new
P-Header. <a href="#section-6">Section 6</a> specifies how to use the P-Header. <a href="#section-7">Section 7</a>
provides a usage example. <a href="#section-8">Section 8</a> describes the applicability of
the P-Header. Security considerations are discussed in <a href="#section-9">Section 9</a>
and, finally, the IANA considerations are stated in <a href="#section-10">Section 10</a>.
<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="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="grey">Hautakorpi & Camarillo Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Usage Scenario</span>
An ad-hoc PoC group session is a type of multi-party PoC session.
The originator of a particular ad-hoc PoC group session chooses in an
ad-hoc manner (e.g., selecting from an address book) the set of
desired participants. In order to establish the ad-hoc PoC group
session, the originator sends an INVITE request with a URI list that
contains the URIs of those participants.
The PoC network, following the procedures defined in [<a href="#ref-6" title=""Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)"">6</a>], receives
such an INVITE request and generates an individual INVITE request
towards each of the URIs in the URI list.
In previous versions of the OMA PoC service, the originator of an
ad-hoc PoC group session was only allowed to populate the initial URI
list with URIs identifying individual PoC users. Later versions of
the service allow the originator to also include URI lists whose
entries represent URI lists. That is, the initial URI list contains
entries that are URI lists themselves. The expected service behavior
then is that the members of the embedded URI lists are invited to
join the ad-hoc PoC group session.
Figure 1 illustrates the desired behavior. The originator (not
shown) places the URI list friends@example.org, along with the URI
alice@example.com, in the initial URI list. The PoC network resolves
friends@example.org into its members, bob@example.org and
carol@example.net, and sends INVITE requests to all the recipients.
<span class="grey">Hautakorpi & Camarillo Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
2. INVITE
+------------------>
| alice@example.com
|
|
+-------------+
| |
1. INVITE | | 3. INVITE
------------------>| PoC Network |---------------->
alice@example.com | | bob@example.org
friends@example.org | |
+-------------+
|
|
|
| 4. INVITE
+------------------>
carol@example.net
Figure 1: PoC Expected Behavior
The PoC network in Figure 1 consists of PoC servers, which are SIP
entities that can behave as proxies or B2BUAs (Back-to-Back User
Agents). There are two types of logical PoC servers: controlling and
participating.
In an ad-hoc PoC group session, there is always exactly one
controlling PoC server. The controlling PoC server of an ad-hoc PoC
group session resolves an incoming URI list and sends INVITEs to the
members of the list. The controlling PoC server also functions as
the focus of the session. Every participant in an ad-hoc PoC group
has an associated participating PoC server, which resides in the home
domain of the participant.
Figure 2 shows how the PoC servers of the PoC network behave in the
scenario shown in Figure 1. An originating PoC user agent sends an
INVITE request (1) with a URI list to its participating PoC server.
The participating PoC server of the originator receives the INVITE
request, assumes the role of controlling PoC server for the ad-hoc
PoC group session, and sends an INVITE request to each of the URIs in
the URI list.
<span class="grey">Hautakorpi & Camarillo Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
+-------------+
2. INVITE | Particip. |
+------------------>| PoC server |->
| alice@example.com | example.com |
| +-------------+
|
+-------------+ 3. INVITE +-------------+
| |-------------------->| |
1. INVITE | Controlling | friends@example.org | Particip. |
---------------->| PoC server | | PoC server |->
alice@example.com | | 4. 403 Forbidden | example.org |
friends@example.org| |<--------------------| |
+-------------+ bob@example.org +-------------+
| | carol@example.net ^
| | |
| | 5. INVITE |
| +--------------------------------+
| bob@example.org
|
| +------------+
| 6. INVITE | Particip. |
+------------------>| PoC server |->
carol@example.net | example.net|
+------------+
Figure 2: PoC Network Behavior
The first URI of the list, alice@example.com, identifies a single
user. The second URI of the URI list, friends@example.org,
identifies a URI list. In PoC terminology, friends@example.com
identifies a pre-arranged PoC group. The PoC server at example.org,
which knows the membership of friends@example.com, cannot send INVITE
requests to the members of friends@example.org because that PoC
server does not act as a controlling PoC server for the ad-hoc PoC
group session being established. Instead, it informs the controlling
PoC server that friends@example.org is a list whose members are
bob@example.org and carol@example.net. Upon receiving this
information, the controlling PoC server generates INVITE requests
towards bob@example.org and carol@example.net.
Although not shown in the above example, the participating PoC server
(example.org) can include -- based on policy, presence of the
members, etc. -- just a partial list of URIs of the URI list.
Furthermore, a URI that the participating PoC server returns can be a
URI list.
<span class="grey">Hautakorpi & Camarillo Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
At present, there is not a mechanism for a participating PoC server
to inform a controlling PoC server that a URI identifies a list and
the members of that list, nor is there a mechanism to indicate the
URIs contained in the list. This document defines such a mechanism:
the P-Refused-URI-List P-Header.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Overview of Operation</span>
When a URI-list server receives an INVITE request with a URI list
containing entries that are URI lists themselves, and the server
cannot handle the request, it returns a 403 (Forbidden) response with
a P-Refused-URI-List P-Header, as shown in Figure 3. The P-Refused-
URI-List P-Header contains the members of the URI list or lists that
caused the rejection of the request. This way, the client can send
requests directly to those member URIs.
+---------+ INVITE request +----------+
| |------------------------------>| |
| | [URI list in a URI list] | URI-list |
| Client | | server |
| | 403 Forbidden | |
| |<------------------------------| |
| | [Content of refused URI list] | |
+---------+ +----------+
Figure 3: Operational Overview
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Syntax of P-Refused-URI-List Header Field</span>
The following is the augmented Backus-Naur Form (BNF) [<a href="#ref-4" title=""Augmented BNF for Syntax Specifications: ABNF"">4</a>] syntax of
the P-Refused-URI-List P-Header:
P-Refused-URI-List = "P-Refused-URI-List" HCOLON
uri-list-entry
*(COMMA uri-list-entry)
uri-list-entry = ( name-addr / addr-spec )
*( SEMI refused-param )
refused-param = members-param / generic-param
members-param = "members" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT
The members P-Header parameter MUST contain a cid-url, which is
defined in <a href="./rfc2392">RFC 2392</a> [<a href="#ref-2" title=""Content-ID and Message-ID Uniform Resource Locators"">2</a>].
The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are
defined in [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>].
<span class="grey">Hautakorpi & Camarillo Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Response Generation</span>
A 403 (Forbidden) response can contain more than one P-Refused-URI-
List entries. The P-Refused-URI-List header field MUST NOT be used
with any other response. The P-Refused-URI-List P-Header contains
one or more URIs, which were present in the URI list in the incoming
request and could not be handled by the server. Additionally, the
P-Refused-URI-List can optionally carry some or all of the members of
the URI lists identified by those URIs.
The 403 (Forbidden) response MAY contain body parts which contain URI
lists. Those body parts can be referenced by the P-Refused-URI-List
entries through their Content-IDs [<a href="#ref-2" title=""Content-ID and Message-ID Uniform Resource Locators"">2</a>]. If there is a Content-ID
defined in the P-Refused-URI-List, one of the body parts MUST have an
equivalent Content-ID. The format of a URI list is service specific.
This kind of message structure enables clients to determine which URI
relates to which URI list, if the URI-list server is willing to
disclose that information. Furthermore, the information enclosed in
the URI lists enable clients to take further actions to remedy the
rejection situation (e.g., send individual requests to the members of
the URI list).
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Message Sequence Example</span>
In the following message sequence example, a controlling PoC server
sends an INVITE request to a participating PoC server. The
participating PoC server rejects the request with a 403 (Forbidden)
response. The 403 response has a P-Refused-URI-List P-Header that
carries the members of the rejected URI lists that the participating
PoC server determines to disclose to this controlling PoC server in
the body of the message.
Controlling PoC server Participating PoC server
example.com example.net
| |
| INVITE |
|-------------------------------->|
| |
| 403 Forbidden |
|<--------------------------------|
| |
Figure 4: Message Sequence Example
The INVITE request shown in Figure 4 is as follows (Via header fields
are not shown for simplicity):
<span class="grey">Hautakorpi & Camarillo Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
INVITE sip:poc-service@example.net SIP/2.0
Max-Forwards: 70
From: PoC service <sip:poc-service@example.com>;tag=4fxaed73sl
To: PoC service <sip:poc-service@example.net>
Call-ID: 7xTn9vxNit65XU7p4@example.com
CSeq: 1 INVITE
Contact: <sip:poc-service@poc-as.example.com>
Require: recipient-list-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 538
--boundary1
Content-Type: application/sdp
(SDP not shown)
--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">
<list>
<entry uri="sip:bob@example.net"/>
<entry uri="sip:friends-list@example.net"/>
<entry uri="sip:colleagues-list@example.net"/>
</list>
</resource-lists>
--boundary1--
The URIs sip:friends-list@example.net and
sip:colleagues-list@example.net in the example above are actually
references to URI lists (i.e., pre-arranged PoC groups). In the
following response, the URI lists are in the XML resource list format
[<a href="#ref-7" title=""Extensible Markup Language (XML) Formats for Representing Resource Lists"">7</a>].
The content of the 403 (Forbidden) response in Figure 4 is as follows
(Via header fields are not shown for simplicity):
SIP/2.0 403 Forbidden
From: PoC service <sip:poc-service@example.com>;tag=4fxaed73sl
To: PoC service <sip:poc-service@example.net>;tag=814254
Call-ID: 7xTn9vxNit65XU7p4@example.com
CSeq: 1 INVITE
P-Refused-URI-List: sip:friends-list@example.net;
members=<cid:an3bt8jf03@example.net>
P-Refused-URI-List: sip:colleagues-list@example.net;
<span class="grey">Hautakorpi & Camarillo Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
members=<cid:bn35n8jf04@example.net>
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 745
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-ID: <an3bt8jf03@example.net>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:bill@example.org"/>
<entry uri="sip:randy@example.com"/>
<entry uri="sip:eddy@example.com"/>
</list>
</resource-lists>
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-ID: <bn35n8jf04@example.net>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:joe@example.org"/>
<entry uri="sip:carol@example.com"/>
</list>
</resource-lists>
--boundary1--
Using the message body of the 403 (Forbidden) response above, the
controlling PoC server can determine the members of
sip:friend-list@example.net and sip:colleagues-list@example.net that
the participating PoC server determines to disclose to this
controlling PoC server. Furthermore, the controlling PoC server can
deduce that the participating PoC server has not sent any outgoing
requests, per regular URI-list server procedures.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Applicability</span>
The P-Refused-URI-List header field is intended to be used in OMA PoC
networks. This header field is used between PoC servers and carries
information about those URI lists that were rejected by the server
receiving the request.
<span class="grey">Hautakorpi & Camarillo Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
The OMA PoC services is designed so that, in a given session, only
one PoC server can resolve incoming URI lists and send INVITEs to
members of these lists. This restriction is not present on services
developed to be used on the public Internet. Therefore, the
P-Refused-URI-List P-Header does not seem to have general
applicability outside the OMA PoC service.
Additionally, the use of the P-Refused-URI-List P-Header requires
special trust relationships between servers that do not typically
exist on the public Internet.
It is important to note that the P-Refused-URI-List is optional and
does not change the basic behavior of a SIP URI-list service. The
P-Refused-URI-List only provides clients with additional information
about the refusal of the request.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
It is assumed that the network elements handling the P-Refused-URI-
List P-Header are trusted. Also, attackers are not supposed to have
access to the protocol messages between those elements. This is
because the P-Refused-URI-List is intended to be used in the OMA PoC
environment, which is implemented in the operators' core network; for
more on OMA PoC security assumptions, see [<a href="#ref-9" title=""Push to talk over Cellular (PoC) - Architecture: Draft Version 2.0"">9</a>]. Traffic protection
between network elements is achieved by using IP Security (IPsec) and
sometimes by physically protecting the network.
However, implementors and administrators should be aware of two
special security considerations related to the use of P-Refused-URI-
List:
Eavesdropping: 403 (Forbidden) responses may contain information
about the members of a given URI list. Eavesdroppers can acquire
this information if the 403 (Forbidden) responses are not
encrypted. Therefore, it is RECOMMENDED that either hop-by-hop or
end-to-end encryption (e.g., using TLS or S/MIME, respectively) is
used.
Disclosing information: A rogue entity may be able to acquire
information about the members of a given URI list if the URI-list
server sends information about those URI lists to unauthorized
users. Therefore, it is RECOMMENDED that a URI-list server
discloses the content of that URI-list only to authorized clients.
<span class="grey">Hautakorpi & Camarillo Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
The IANA has made two additions to the Session Initiation Protocol
(SIP) Parameters registry. The following header field has been added
to the Header Fields sub-registry.
Header Name compact Reference
----------------- ------- ---------
P-Refused-URI-List [<a href="./rfc5318">RFC5318</a>]
The following header field parameter has been added to the Header
Field Parameters and Parameter Values sub-registry.
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
P-Refused-URI-List members No [<a href="./rfc5318">RFC5318</a>]
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgements</span>
Authors would like to thank Tom Hiller who did a thorough, dedicated
review for this document.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-1">1</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-2">2</a>] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", <a href="./rfc2392">RFC 2392</a>, August 1998.
[<a id="ref-3">3</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-4">4</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-5">5</a>] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-List
Services", <a href="./rfc5363">RFC 5363</a>, October 2008.
[<a id="ref-6">6</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.
<span class="grey">Hautakorpi & Camarillo Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5318">RFC 5318</a> The P-Refused-URI-List P-Header December 2008</span>
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-7">7</a>] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", <a href="./rfc4826">RFC 4826</a>, May 2007.
[<a id="ref-8">8</a>] Open Mobile Alliance, "OMA PoC System Description: Draft Version
2.0", April 2007.
[<a id="ref-9">9</a>] Open Mobile Alliance, "Push to talk over Cellular (PoC) -
Architecture: Draft Version 2.0", April 2007.
Authors' Addresses
Jani Hautakorpi
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Hautakorpi & Camarillo Informational [Page 12]
</pre>
|
