Network Working Group J. Hautakorpi
Request for Comments: 5318 G. Camarillo
Category: Informational Ericsson
December 2008
Network Working Group J. Hautakorpi
Request for Comments: 5318 G. Camarillo
Category: Informational Ericsson
December 2008
The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)
会话启动协议（SIP）P-Header-URI-List专用头（P-Header）
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.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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.
本文档指定了会话启动协议（SIP）P-Header-URI-List专用头（P-Header）。此P-Header用于开放移动联盟（OMA）的蜂窝式一键通（PoC）系统。它使URI列表服务器能够拒绝处理具有嵌入URI列表的传入URI列表。这个P头还使得URI列表服务器能够通知客户机导致拒绝的嵌入式URI列表以及形成这样一个URI列表的各个URI。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Usage Scenario ..................................................3
4. Overview of Operation ...........................................6
5. Syntax of P-Refused-URI-List Header Field .......................6
6. Response Generation .............................................7
7. Message Sequence Example ........................................7
8. Applicability ...................................................9
9. Security Considerations ........................................10
10. IANA Considerations ...........................................11
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................12
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Usage Scenario ..................................................3
4. Overview of Operation ...........................................6
5. Syntax of P-Refused-URI-List Header Field .......................6
6. Response Generation .............................................7
7. Message Sequence Example ........................................7
8. Applicability ...................................................9
9. Security Considerations ........................................10
10. IANA Considerations ...........................................11
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................12
The Open Mobile Alliance (OMA) has specified the Push to talk over Cellular (PoC) service, which uses the Session Initiation Protocol (SIP) [3] and Uniform Resource Identifier (URI)-list services [5] (more information about OMA PoC can be found at [8]).
开放移动联盟（OMA）已指定了蜂窝式一键通（PoC）服务，该服务使用会话发起协议（SIP）[3]和统一资源标识符（URI）-列表服务[5]（有关OMA PoC的更多信息，请参见[8]）。
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.
OMAPOC需要一种机制，当传入的URI列表具有嵌入的URI列表时，服务器可以拒绝处理这些列表。这种机制旨在用于建立称为特设PoC组会话的特定类型的PoC会话。
The remainder of this document is organized as follows. Section 3 describes the scenario where the mechanism will be used. Section 4 provides an overview of the mechanism, which includes a new P-Header called P-Refused-URI-List. Section 5 defines the syntax of this new P-Header. Section 6 specifies how to use the P-Header. Section 7 provides a usage example. Section 8 describes the applicability of the P-Header. Security considerations are discussed in Section 9 and, finally, the IANA considerations are stated in Section 10.
本文件的其余部分组织如下。第3节描述了将使用该机制的场景。第4节概述了该机制，其中包括一个名为P-reked-URI-List的新P头。第5节定义了这个新P-Header的语法。第6节规定了如何使用P标题。第7节提供了一个使用示例。第8节描述了P-Header的适用性。第9节讨论了安全注意事项，最后，第10节阐述了IANA注意事项。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
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.
特设PoC组会话是一种多方PoC会话。特定特设PoC组会话的发起人以特设方式（例如，从通讯簿中选择）选择所需参与者的集合。为了建立特设PoC组会话，发起者发送一个INVITE请求，其中包含这些参与者的URI列表。
The PoC network, following the procedures defined in [6], receives such an INVITE request and generates an individual INVITE request towards each of the URIs in the URI list.
PoC网络按照[6]中定义的过程接收此类INVITE请求，并针对URI列表中的每个URI生成单独的INVITE请求。
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.
在OMA PoC服务的早期版本中，仅允许临时PoC组会话的发起人使用标识单个PoC用户的URI填充初始URI列表。服务的更高版本允许发起者还包括URI列表，其条目表示URI列表。也就是说，初始URI列表包含的条目本身就是URI列表。然后，预期的服务行为是邀请嵌入URI列表的成员加入特设PoC组会话。
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.
图1说明了所需的行为。发起者（未显示）放置URI列表friends@example.org，以及URIalice@example.com，在初始URI列表中。PoC网络解决了friends@example.org加入其成员，bob@example.org和carol@example.net，并向所有收件人发送邀请请求。
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
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
图1:PoC预期行为
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.
图1中的PoC网络由PoC服务器组成，这些服务器是可以作为代理或B2BUA（背靠背用户代理）的SIP实体。有两种类型的逻辑PoC服务器：控制和参与。
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.
在特设PoC组会话中，始终只有一台控制PoC服务器。特设PoC组会话的控制PoC服务器解析传入URI列表，并向该列表的成员发送邀请。控制PoC服务器还充当会话的焦点。特设PoC组中的每个参与者都有一个关联的参与PoC服务器，该服务器位于参与者的主域中。
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.
图2显示了PoC网络的PoC服务器在图1所示场景中的行为。发起的PoC用户代理向其参与的PoC服务器发送带有URI列表的INVITE请求（1）。发起人的参与PoC服务器接收INVITE请求，承担控制特设PoC组会话的PoC服务器的角色，并向URI列表中的每个URI发送INVITE请求。
+-------------+
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|
+------------+
+-------------+
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
图2:PoC网络行为
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.
列表的第一个URI，alice@example.com，标识单个用户。URI列表的第二个URI，friends@example.org，标识URI列表。在PoC术语中，friends@example.com标识预先安排的PoC组。example.org上的PoC服务器，它知道friends@example.com，无法向的成员发送邀请请求friends@example.org因为该PoC服务器不充当正在建立的特设PoC组会话的控制PoC服务器。相反，它会通知控制PoC服务器friends@example.org是一个成员为的列表bob@example.org和carol@example.net. 收到此信息后，控制PoC服务器将生成针对的INVITE请求bob@example.org和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.
尽管在上面的示例中没有显示，但参与的PoC服务器（example.org）可以包括——基于策略、成员的存在等——URI列表中的部分URI列表。此外，参与PoC服务器返回的URI可以是URI列表。
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.
目前，没有用于参与PoC服务器通知控制PoC服务器URI标识列表和该列表的成员的机制，也没有用于指示列表中包含的URI的机制。本文档定义了这样一种机制：P-denked-URI-List P-Header。
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.
当一个URI列表服务器接收到一个INVITE请求，其中一个URI列表包含了URI列表本身的条目，并且该服务器无法处理该请求时，它返回一个403（禁止）响应，该响应带有一个P-denked-URI-list P-Header，如图3所示。P-denked-URI-List P-Header包含导致请求被拒绝的URI列表的成员。这样，客户端可以直接向这些成员URI发送请求。
+---------+ INVITE request +----------+
| |------------------------------>| |
| | [URI list in a URI list] | URI-list |
| Client | | server |
| | 403 Forbidden | |
| |<------------------------------| |
| | [Content of refused URI list] | |
+---------+ +----------+
+---------+ INVITE request +----------+
| |------------------------------>| |
| | [URI list in a URI list] | URI-list |
| Client | | server |
| | 403 Forbidden | |
| |<------------------------------| |
| | [Content of refused URI list] | |
+---------+ +----------+
Figure 3: Operational Overview
图3：操作概述
The following is the augmented Backus-Naur Form (BNF) [4] syntax of the P-Refused-URI-List P-Header:
以下是P-REQUENED-URI-List P-Header的增广Backus Naur Form（BNF）[4]语法：
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
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 RFC 2392 [2].
members P-Header参数必须包含在RFC 2392[2]中定义的cid url。
The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are defined in [3].
[3]中定义了HCOLON、SEMI、EQUAL、LDQUOT、RDQUOT和generic参数。
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.
403（禁止）响应可以包含多个P-REQUENED-URI-List条目。P-denked-URI-List头字段不得与任何其他响应一起使用。P-denked-URI-List P-Header包含一个或多个URI，这些URI出现在传入请求的URI列表中，服务器无法处理。此外，P-reked-URI-List可以选择性地携带由那些URI标识的URI列表的部分或全部成员。
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 [2]. 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.
403（禁止）响应可能包含包含URI列表的主体部分。这些身体部位可以通过其内容ID被P-URI-List条目引用[2]。如果P-URI-List中定义了内容ID，则其中一个主体部分必须具有等效的内容ID。URI列表的格式是特定于服务的。
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).
这种消息结构使客户端能够确定哪个URI与哪个URI列表相关，如果URI列表服务器愿意披露该信息。此外，URI列表中包含的信息使客户端能够采取进一步的措施来纠正拒绝情况（例如，向URI列表的成员发送单个请求）。
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.
在下面的消息序列示例中，控制PoC服务器向参与的PoC服务器发送INVITE请求。参与的PoC服务器以403（禁止）响应拒绝请求。403响应具有P-denked-URI-List P-Header，该P-denked-URI-List P-Header携带参与PoC服务器确定在消息主体中向该控制PoC服务器公开的被拒绝URI列表的成员。
Controlling PoC server Participating PoC server example.com example.net
控制PoC服务器参与PoC服务器example.com example.net
| |
| INVITE |
|-------------------------------->|
| |
| 403 Forbidden |
|<--------------------------------|
| |
| |
| INVITE |
|-------------------------------->|
| |
| 403 Forbidden |
|<--------------------------------|
| |
Figure 4: Message Sequence Example
图4：消息序列示例
The INVITE request shown in Figure 4 is as follows (Via header fields are not shown for simplicity):
图4所示的INVITE请求如下（为简单起见，未显示Via头字段）：
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
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
--boundary1
Content-Type: application/sdp
(SDP not shown)
（未显示SDP）
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1内容类型：应用程序/资源列表+xml内容处置：收件人列表
<?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--
<?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 [7].
URI sip：朋友-list@example.net及sip:同事-list@example.net在上面的示例中，实际上是对URI列表的引用（即，预先安排的PoC组）。在下面的响应中，URI列表采用XML资源列表格式[7]。
The content of the 403 (Forbidden) response in Figure 4 is as follows (Via header fields are not shown for simplicity):
图4中403（禁止）响应的内容如下（为简单起见，未显示Via头字段）：
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;
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;
members=<cid:bn35n8jf04@example.net>
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 745
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>
--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>
<?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>
--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--
<?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.
使用上面403（禁止）响应的消息体，控制PoC服务器可以确定sip:friend的成员-list@example.net及sip:同事-list@example.net参与的PoC服务器决定向该控制PoC服务器公开的消息。此外，根据常规URI列表服务器过程，控制PoC服务器可以推断参与的PoC服务器没有发送任何传出请求。
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.
P-reked-URI-List报头字段用于OMA PoC网络。此标头字段在PoC服务器之间使用，并携带有关接收请求的服务器拒绝的URI列表的信息。
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.
OMAPOC服务的设计使得在给定会话中，只有一台PoC服务器可以解析传入的URI列表并向这些列表的成员发送邀请。此限制不适用于为在公共互联网上使用而开发的服务。因此，P-denked-URI-List P-Header在OMA-PoC服务之外似乎没有普遍的适用性。
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.
此外，使用P-denked-URI-List P-Header需要在公共互联网上通常不存在的服务器之间建立特殊的信任关系。
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.
需要注意的是，P-denked-URI-List是可选的，不会改变SIP-URI列表服务的基本行为。P-denked-URI-List仅向客户端提供有关拒绝请求的附加信息。
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 [9]. Traffic protection between network elements is achieved by using IP Security (IPsec) and sometimes by physically protecting the network.
假设处理P-denked-URI-List P-Header的网元是可信的。此外，攻击者不应访问这些元素之间的协议消息。这是因为P-reked-URI-List旨在用于OMA PoC环境，该环境在运营商的核心网络中实现；有关OMA PoC安全性假设的更多信息，请参见[9]。网元之间的流量保护通过使用IP安全（IPsec）实现，有时通过物理保护网络实现。
However, implementors and administrators should be aware of two special security considerations related to the use of P-Refused-URI-List:
但是，实现者和管理员应该知道与使用P-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.
窃听：403（禁止）响应可能包含关于给定URI列表成员的信息。如果403（禁止）响应未加密，窃听者可以获取此信息。因此，建议使用逐跳或端到端加密（例如，分别使用TLS或S/MIME）。
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.
披露信息：如果URI列表服务器向未经授权的用户发送有关URI列表的信息，流氓实体可能能够获取有关给定URI列表成员的信息。因此，建议URI列表服务器仅向授权客户端公开该URI列表的内容。
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.
IANA在会话启动协议（SIP）参数注册表中添加了两个参数。以下标题字段已添加到标题字段子注册表。
Header Name compact Reference
----------------- ------- ---------
P-Refused-URI-List [RFC5318]
Header Name compact Reference
----------------- ------- ---------
P-Refused-URI-List [RFC5318]
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 [RFC5318]
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
P-Refused-URI-List members No [RFC5318]
Authors would like to thank Tom Hiller who did a thorough, dedicated review for this document.
作者要感谢Tom Hiller，他对本文件进行了全面、专门的审查。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[2] Levinson，E.，“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[5] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[5] Camarillo，G.和A.Roach，“会话启动协议（SIP）URI列表服务的框架和安全注意事项”，RFC 5363，2008年10月。
[6] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[6] Camarillo，G.和A.Johnston，“使用会话启动协议（SIP）中包含的请求列表建立会议”，RFC 5366，2008年10月。
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[7] Rosenberg，J.，“表示资源列表的可扩展标记语言（XML）格式”，RFC4826，2007年5月。
[8] Open Mobile Alliance, "OMA PoC System Description: Draft Version 2.0", April 2007.
[8] 开放移动联盟，“OMA PoC系统说明：2.0版草案”，2007年4月。
[9] Open Mobile Alliance, "Push to talk over Cellular (PoC) - Architecture: Draft Version 2.0", April 2007.
[9] 开放式移动联盟，“通过蜂窝网络进行按键通话（PoC）-架构：2.0版草案”，2007年4月。
Authors' Addresses
作者地址
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Jani.Hautakorpi@ericsson.com
EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com