Network Working Group M. Garcia-Martin
Request for Comments: 4354 Nokia
Category: Informational January 2006
Network Working Group M. Garcia-Martin
Request for Comments: 4354 Nokia
Category: Informational January 2006
A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service
一种会话启动协议（SIP）事件包和数据格式，用于各种设置，以支持蜂窝式按键通话（PoC）服务
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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet.
开放移动联盟（OMA）正在定义蜂窝式一键通（PoC）服务，其中SIP是用于在不同参与者之间建立半双工媒体会话、发送即时消息等的协议。本文档定义了SIP事件包，以支持发布、订阅、，以及PoC服务所需的附加功能的通知。此SIP事件包适用于PoC服务，可能不适用于通用Internet。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Applicability Statement .........................................5
4. Requirements ....................................................5
5. The "poc-settings" Event Package ................................6
5.1. Package Name ...............................................6
5.2. Event Package Parameters ...................................7
5.3. SUBSCRIBE Bodies ...........................................7
5.4. Subscription Duration ......................................7
5.5. NOTIFY Bodies ..............................................7
5.6. Notifier Processing of SUBSCRIBE Requests ..................8
5.6.1. Authentication ......................................8
5.6.2. Authorization .......................................8
5.7. Notifier Generation of NOTIFY Requests .....................8
5.8. Subscriber Processing of NOTIFY Requests ...................9
5.9. Handling of Forked Requests ...............................10
5.10. Rate of Notifications ....................................10
5.11. State Agents .............................................10
5.12. Examples .................................................10
5.13. Use of URIs to Retrieve State ............................10
5.14. PUBLISH Bodies ...........................................11
5.15. PUBLISH Response Bodies ..................................11
5.16. Multiple Sources for Event State .........................11
5.17. Event State Segmentation .................................11
5.18. Rate of Publication ......................................12
6. PoC-Settings Document ..........................................12
6.1. XML Schema ................................................14
6.2. Example ...................................................16
7. Security Considerations ........................................17
8. Acknowledgements ...............................................17
9. IANA Considerations ............................................17
9.1. Registration of the "poc-settings" Event Package ..........17
9.2. Registration of the "application/poc-settings+xml"
MIME type .................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Applicability Statement .........................................5
4. Requirements ....................................................5
5. The "poc-settings" Event Package ................................6
5.1. Package Name ...............................................6
5.2. Event Package Parameters ...................................7
5.3. SUBSCRIBE Bodies ...........................................7
5.4. Subscription Duration ......................................7
5.5. NOTIFY Bodies ..............................................7
5.6. Notifier Processing of SUBSCRIBE Requests ..................8
5.6.1. Authentication ......................................8
5.6.2. Authorization .......................................8
5.7. Notifier Generation of NOTIFY Requests .....................8
5.8. Subscriber Processing of NOTIFY Requests ...................9
5.9. Handling of Forked Requests ...............................10
5.10. Rate of Notifications ....................................10
5.11. State Agents .............................................10
5.12. Examples .................................................10
5.13. Use of URIs to Retrieve State ............................10
5.14. PUBLISH Bodies ...........................................11
5.15. PUBLISH Response Bodies ..................................11
5.16. Multiple Sources for Event State .........................11
5.17. Event State Segmentation .................................11
5.18. Rate of Publication ......................................12
6. PoC-Settings Document ..........................................12
6.1. XML Schema ................................................14
6.2. Example ...................................................16
7. Security Considerations ........................................17
8. Acknowledgements ...............................................17
9. IANA Considerations ............................................17
9.1. Registration of the "poc-settings" Event Package ..........17
9.2. Registration of the "application/poc-settings+xml"
MIME type .................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is currently specifying the Push-to-talk over Cellular (PoC) service. This service allows a SIP User Agent (PoC terminal) to establish a session to one or more SIP User Agents (UAs) simultaneously, usually initiated when the initiating user pushes a button.
开放移动联盟（OMA）(http://www.openmobilealliance.org)目前正在指定通过蜂窝网络（PoC）的按键通话服务。该服务允许SIP用户代理（PoC终端）同时建立与一个或多个SIP用户代理（UAs）的会话，通常在发起用户按下按钮时启动。
OMA has defined a collection of very stringent requirements in support of the PoC service. In order to provide the user with a satisfactory experience, the initial session establishment (from the time the user presses the button to the time they get an indication to speak) must be minimized.
OMA为支持PoC服务定义了一系列非常严格的要求。为了向用户提供令人满意的体验，必须最小化初始会话建立（从用户按下按钮到获得讲话指示的时间）。
The PoC terminal may support hardware capabilities such as a speakerphone and/or headset and software that provide the capability for the user to configure the PoC terminal to accept session initiations immediately and play out the media as soon as it is received without requiring the intervention of the called user. This mode of operation is known as Auto-Answer mode or automatic mode. The user may alternatively configure the PoC terminal to first alert the user and require the user to accept the session invitation manually before media is accepted. This mode of operation is known as Manual-Answer mode. The PoC terminal may support both or only one of these modes of operation. The user may change the Answer Mode (AM) configuration of the PoC terminal frequently based on their current circumstances and preference (perhaps because the user is busy or in a public area where she cannot use a speaker phone, etc.).
PoC终端可以支持诸如扬声器和/或耳机的硬件功能和软件，这些硬件功能为用户提供配置PoC终端以立即接受会话发起并在接收到媒体时立即播放媒体的能力，而无需被叫用户的干预。这种操作模式称为自动应答模式或自动模式。用户可替代地配置PoC终端以首先警告用户并要求用户在接受媒体之前手动接受会话邀请。这种操作模式称为手动应答模式。PoC终端可支持这两种或仅一种操作模式。用户可以基于其当前情况和偏好频繁地改变PoC终端的应答模式（AM）配置（可能是因为用户忙或者在公共区域中，她不能使用扬声器电话等）。
SIP PoC terminals can support various SIP-based communication services in addition to Push-to-talk (e.g., VoIP telephony, presence services, messaging services, etc.). The user may at times wish to disable the acceptance of Push-to-talk sessions whilst still remaining SIP registered for one or more other SIP-based services. When the PoC terminal is configured to not accept any incoming Push-to-talk sessions, this is known as Incoming Session Barring (ISB).
除了一键通（Push-to-talk）之外，SIP-PoC终端还可以支持各种基于SIP的通信服务（例如，VoIP电话、状态服务、消息服务等）。用户有时可能希望禁用按键通话会话的接受，同时仍然为一个或多个基于SIP的服务注册SIP。当PoC终端配置为不接受任何传入的按键通话会话时，这称为传入会话限制（ISB）。
A user may wish to contact another user who has a PoC terminal with Incoming Session Barring enabled. A user may send an Instant Personal Alert to another user to inform him that he wishes to engage him in a PoC Session. This Instant Personal Alert is received even when the destination PoC terminal has enabled Incoming Session Barring. If a user wishes to disable the acceptance of Instant Personal Alerts, he can configure his PoC terminal not accept any incoming Instant Personal Alerts. This is known as Instant Personal Alert Barring (IPAB).
用户可能希望联系具有启用了传入会话限制的PoC终端的另一用户。用户可以向另一用户发送即时个人警报，通知他希望让他参与PoC会话。即使目标PoC终端已启用传入会话限制，也会收到此即时个人警报。如果用户希望禁用接受即时个人警报，他可以将其PoC终端配置为不接受任何传入的即时个人警报。这称为即时个人警报限制（IPAB）。
Some PoC terminals may provide support for handling multiple PoC sessions simultaneously whereas other terminals are only able to handle one PoC session at time. Or, even if the terminal is able to handle multiple PoC sessions simultaneously, the user may desire to have just one single PoC session at a time. This indication of support for multiple PoC sessions simultaneously is known as Simultaneous PoC Sessions Support (SSS).
一些PoC终端可以提供同时处理多个PoC会话的支持，而其他终端一次只能处理一个PoC会话。或者，即使终端能够同时处理多个PoC会话，用户也可能希望一次只有一个PoC会话。这种同时支持多个PoC会话的指示称为同步PoC会话支持（SSS）。
The OMA PoC Architecture utilizes SIP servers within the network that may perform roles such as a conference focus [12], an RTP translator, or a policy server. A possible optimization to minimize the delay in providing the caller with an indication to speak consist of the SIP network server to perform buffering of media packets in order to provide an early or unconfirmed indication to the caller and allow the caller to start speaking before the called PoC terminal has answered. This optimization only is appropriate when the called PoC terminal is currently accepting PoC sessions and its Answer Mode is set to Auto-Answer. This optimization therefore requires the network SIP server to have knowledge of the current ISB and AM settings of the called PoC terminal.
OMA PoC体系结构利用网络中的SIP服务器，这些服务器可以执行会议焦点[12]、RTP转换器或策略服务器等角色。用于最小化向呼叫者提供讲话指示的延迟的可能优化包括SIP网络服务器，该SIP网络服务器执行媒体分组的缓冲，以便向呼叫者提供早期或未确认的指示，并允许呼叫者在被叫PoC终端应答之前开始讲话。仅当被叫PoC终端当前正在接受PoC会话且其应答模式设置为自动应答时，此优化才适用。因此，这种优化要求网络SIP服务器了解被调用PoC终端的当前ISB和AM设置。
Similarly, in order to avoid unnecessary transmission of Instant Personal Alerts across the radio interface, the network SIP server needs to have knowledge of the current IPAB setting at the terminal.
类似地，为了避免通过无线电接口不必要地传输即时个人警报，网络SIP服务器需要知道终端处的当前IPAB设置。
When the UA supports multiple PoC sessions simultaneously the server needs to act as a B2BUA in order to multiplex media and floor control signaling between multiple sessions using a single bandwidth limited radio bearer. When handling of multiple PoC sessions simultaneously is not needed the server can act as a SIP proxy. It is therefore advantageous for the server to be informed whether the UA currently intends to support multiple PoC sessions simultaneously.
当UA同时支持多个PoC会话时，服务器需要充当B2BUA，以便使用单个带宽有限的无线电承载在多个会话之间复用媒体和楼层控制信令。当不需要同时处理多个PoC会话时，服务器可以充当SIP代理。因此，告知服务器UA当前是否打算同时支持多个PoC会话是有利的。
This document proposes additional SIP capabilities to enable the communication of the ISB, AM, IPAB, and SSS settings between the SIP PoC terminal and the SIP network server.
本文档提出了额外的SIP功能，以实现SIP PoC终端和SIP网络服务器之间ISB、AM、IPAB和SSS设置的通信。
We define a SIP event package that allows a SIP Event Publication Agent (EPA) to publish the user's settings at that particular EPA which may impact some specific session attempts. This allows subscribers to subscribe to the Event State Compositor to this event package to gather this information, and anticipate to the user's needs when a session is attempted to that user. It is believed that the SIP event package defined here is not applicable to the general Internet: it has been designed to serve the architecture of the PoC service. In particular, and in the context defined by RFC 3903 [8], it is the intention of OMA to make PoC terminals behave as Event Publication Agents (EPA), and network servers behave as Event State
我们定义了一个SIP事件包，它允许SIP事件发布代理（EPA）在该特定EPA上发布用户的设置，这可能会影响某些特定的会话尝试。这允许订阅者订阅此事件包的事件状态合成器以收集此信息，并在尝试与该用户进行会话时预测用户的需要。人们认为，此处定义的SIP事件包不适用于通用Internet：它被设计为服务于PoC服务的体系结构。特别是，在RFC 3903[8]定义的上下文中，OMA的意图是使PoC终端充当事件发布代理（EPA），而网络服务器充当事件状态
Compositors (ESC). It is possible that PoC terminals and network servers may also subscribe to the user's PoC related settings, so that changes in this state made in one terminal are kept in synchronization across all different terminals or with the network server for a particular user.
排字器（ESC）。PoC终端和网络服务器也可能订阅用户的PoC相关设置，以便在一个终端中进行的该状态的更改在所有不同终端之间或与特定用户的网络服务器保持同步。
This document defines a PoC-settings document that allows an EPA to convey its ISB, AM, IPAB, and SSS settings to an ESC. The EPA sends a PoC-settings document in PUBLISH requests [8]. The PoC-settings document contain represents the settings view at that particular EPA. The ESC can collect PoC-settings document for the same user at different EPAs, apply a composition policy, and provide notifications. Notifications can contain a composed view of the settings or a list of settings per EPA, depending on whether the ESC is able to resolve conflicts. A subscriber can receive notifications of changes in this document according to the procedures specified in RFC 3265 [5]. The aim of this memo is to follow the procedure indicated in RFC 3427 [6] and to register a new poc-settings event package with IANA.
本文件定义了PoC设置文件，该文件允许EPA将其ISB、AM、IPAB和SSS设置传达给ESC。EPA在发布请求[8]中发送PoC设置文档。PoC设置文档包含表示该特定EPA的设置视图。ESC可以在不同EPA收集同一用户的PoC设置文档，应用合成策略，并提供通知。根据ESC是否能够解决冲突，通知可以包含设置的组合视图或每个EPA的设置列表。订阅者可以根据RFC 3265[5]中规定的程序接收本文档中的更改通知。本备忘录旨在遵循RFC 3427[6]中规定的程序，并向IANA注册新的poc设置事件包。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
The event package defined in this document is intended for use with network-based application servers that provide a Push-to-Talk over Cellular service.
本文档中定义的事件包旨在与基于网络的应用程序服务器一起使用，这些服务器通过蜂窝网络提供一键通服务。
A comprehensive description of all the requirements that affect the Push-to-Talk over Cellular service developed by the Open Mobile Alliance can be found in the Open Mobile Alliance web page at http://www.openmobilealliance.org.
有关影响开放移动联盟开发的移动电话一键通服务的所有要求的全面说明，请访问开放移动联盟的网页：http://www.openmobilealliance.org.
For the sake of simplicity, we briefly discuss here those requirements that affect the solution described in this document. These requirements can be summarized as follows:
为了简单起见，我们在此简要讨论影响本文档中描述的解决方案的那些需求。这些要求可概括如下：
1. There must be a mechanism that reduces the session setup time as much as possible. 2. In order to allow proper usage of scarce resources, there must be a mechanism that saves the air interface from being congested with unneeded or undesired traffic. 3. The mechanism should not involve the implementation of new protocols, unless strictly needed.
1. 必须有一种尽可能减少会话设置时间的机制。2.为了合理利用稀缺资源，必须有一种机制，避免空中接口因不必要或不希望的交通堵塞。3.除非严格需要，否则该机制不应涉及新协议的实施。
These requirements lead to a solution whereby the user can indicate to a network node his ability to accept or reject sessions or certain types of messages. Pushing these settings to a network node allows the network node to produce a faster response to the originator, perhaps even declining or filtering some SIP requests towards the destination. This approaches the goal of reducing the session setup time.
这些需求导致了一种解决方案，用户可以向网络节点指示其接受或拒绝会话或某些类型消息的能力。将这些设置推送到网络节点允许网络节点对发起者产生更快的响应，甚至可能拒绝或过滤一些指向目的地的SIP请求。这接近减少会话设置时间的目标。
RFC 3265 [5] defines a SIP extension for subscribing to remote nodes and receiving notifications of changes (events) in their states. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document qualifies as an event package. This section fills in the information required for all event packages by RFC 3265 [5].
RFC 3265[5]定义了一个SIP扩展，用于订阅远程节点并接收其状态更改（事件）的通知。它将这些事件的许多方面的定义留给具体的扩展，称为事件包。此文档符合事件包的条件。本节填写RFC 3265[5]要求的所有事件包的信息。
Additionally, RFC 3903 [8] defines an extension that allows SIP User Agents to publish event state. According to RFC 3903 [8], any event package intended to be used in conjunction with the SIP PUBLISH method has to include a considerations section. This section also fills the information for all event packages to be used with PUBLISH requests.
此外，RFC 3903[8]定义了一个扩展，允许SIP用户代理发布事件状态。根据RFC 3903[8]，与SIP发布方法结合使用的任何事件包都必须包含注意事项部分。本节还将填写与发布请求一起使用的所有事件包的信息。
We define a new "poc-settings" event package. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the poc-settings event package. Acting as a notifier, the ESC notifies subscribers to the user's poc-settings information when changes occur.
我们定义了一个新的“poc设置”事件包。事件发布代理（EPA）使用发布请求通知事件状态合成器（ESC）poc设置事件包中的更改。ESC作为通知程序，在发生更改时通知订阅者用户的poc设置信息。
The name of this package is "poc-settings". As specified in RFC 3265 [5], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903 [8], this value also appears in the Event header field present in PUBLISH requests.
此软件包的名称为“poc设置”。如RFC 3265[5]所述，此值出现在订阅和通知请求中的事件头字段中。如RFC 3903[8]中所述，此值也出现在发布请求中的事件标题字段中。
RFC 3265 [5] allows event packages to define additional parameters carried in the Event header field. This event package, "poc-settings", does not define additional parameters.
RFC 3265[5]允许事件包定义事件标题字段中携带的其他参数。此事件包“poc设置”不定义其他参数。
According to RFC 3265 [5], a SUBSCRIBE request can contain a body. The purpose of the body depends on its type. Subscriptions to the poc-settings event package will normally not contain bodies.
根据RFC 3265[5]，订阅请求可以包含一个主体。主体的用途取决于其类型。对poc设置事件包的订阅通常不包含正文。
The Request-URI of the SUBSCRIBE request identifies the user about whose poc-settings the subscriber wants to be informed.
SUBSCRIBE请求的请求URI标识订阅服务器希望通知其poc设置的用户。
The default expiration time for subscriptions within this package is 3600 seconds. As per RFC 3265 [5], the subscriber MAY specify an alternate expiration in the Expires header field.
此包中订阅的默认过期时间为3600秒。根据RFC 3265[5]，订阅者可以在Expires标头字段中指定替代到期。
As described in RFC 3265 [5], the NOTIFY message will contain bodies describing the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE request, or a package-specific default format if the Accept header field was omitted from the SUBSCRIBE request.
如RFC 3265[5]所述，NOTIFY消息将包含描述订阅资源状态的主体。此正文采用订阅请求的Accept header字段中列出的格式，或者如果订阅请求中省略了Accept header字段，则采用特定于包的默认格式。
In this event package, the body of the notification contains a PoC-settings document (see Section 6). The ESC has gathered PoC-settings documents for the user at different EPAs. The ESC applies a composition policy and composes a PoC-settings document with a common view of all these settings across different EPAs. In case the ESC is not able to resolve a conflict, due to contradictory information provided by two different EPAs, the ESC provides a PoC-settings document containing the settings at each terminal so that the subscriber can resolve the conflict.
在此事件包中，通知正文包含PoC设置文档（请参阅第6节）。ESC已为不同EPA的用户收集了PoC设置文档。电子稳定控制系统应用合成策略，并合成一个PoC设置文档，该文档包含不同EPA中所有这些设置的通用视图。如果由于两个不同EPA提供的信息相互矛盾，ESC无法解决冲突，ESC将提供一份PoC设置文档，其中包含每个终端的设置，以便订户能够解决冲突。
All subscribers and notifiers of the "poc-settings" event package MUST support the "application/poc-settings+xml" data format described in Section 6. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/poc-settings+xml" (assuming that the Event header field contains a value of "poc-settings"). If the Accept header field is present, it MUST include "application/poc-settings+xml" and MAY include any other types capable of representing user settings for PoC.
“poc设置”事件包的所有订阅者和通知者必须支持第6节中描述的“应用程序/poc设置+xml”数据格式。订阅请求可能包含接受标头字段。如果不存在此类头字段，则其默认值为“应用程序/poc设置+xml”（假设事件头字段包含“poc设置”的值）。如果存在Accept header字段，则它必须包括“应用程序/poc设置+xml”，并且可能包括能够表示poc用户设置的任何其他类型。
The contents of a PoC-settings document can contain sensitive information that can reveal some privacy information. Therefore, PoC-settings documents MUST only be sent to authorized subscribers. In order to determine if a subscription originates in an authorized user, the user MUST be authenticated as described in Section 5.6.1 and then he MUST be authorized to be a subscriber as described in Section 5.6.2.
PoC设置文档的内容可能包含敏感信息，这些信息可能会泄露一些隐私信息。因此，PoC设置文档只能发送给授权订户。为了确定订阅是否来源于授权用户，必须按照第5.6.1节的规定对该用户进行身份验证，然后按照第5.6.2节的规定授权该用户为订户。
Notifiers MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 [4] and other authentication extensions.
通知程序必须验证所有订阅请求。此身份验证可以使用RFC 3261[4]和其他身份验证扩展中定义的任何机制来完成。
Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading some kind of standardized access control list document.
一旦通过身份验证，通知程序将做出授权决定。除非用户提供了授权，否则通知程序不得接受订阅。提供授权的方式不在本文件范围内。授权可能通过访问列表提前提供，可能在网页中指定。授权可能通过上传某种标准化访问控制列表文件的方式提供。
RFC 3265 [5] details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the poc-settings event package.
RFC 3265[5]详细说明了NOTIFY消息的格式和结构。但是，软件包必须提供有关何时发送通知、如何计算资源状态、如何生成中立或虚假状态信息以及状态信息是完整的还是部分的详细信息。本节介绍poc设置事件包的详细信息。
A notifier MAY send a NOTIFY at any time. Typically, it will send one when the poc-settings stage of a user changes. The NOTIFY request MAY contain a body containing a PoC-settings document. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription. However, typically the NOTIFY will contain an indication of those PoC-related services for which a change has occurred.
通知者可以随时发送通知。通常，当用户的poc设置阶段更改时，它将发送一个。通知请求可能包含一个包含PoC设置文档的正文。为特定订阅者发送通知的时间以及该通知中正文的内容受管理订阅的授权策略指定的任何规则的约束。但是，通常，通知将包含已发生更改的那些PoC相关服务的指示。
In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
对于挂起的订阅，当确定最终授权时，可以发送通知。如果授权决定的结果是成功的，则应发送通知并包含
complete PoC-settings document with the current state of the user's PoC settings. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 [5], the Subscription-State header field indicates the state of the subscription.
使用用户PoC设置的当前状态填写PoC设置文档。如果订阅被拒绝，则可能会发送通知。如RFC 3265[5]所述，订阅状态标头字段指示订阅的状态。
The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/poc-settings+xml" if no Accept header field was present.
必须使用最新订阅请求中Accept header字段中列出的类型之一发送通知正文，或者如果不存在Accept header字段，则使用类型“application/poc settings+xml”。
Notifiers will typically act as Event State Compositors (ESC) and thus will learn the poc-settings event state via PUBLISH requests sent from the user's Event Publication Agent (EPA) when the user changes one of those settings. It is possible that the notifier generates a NOTIFY request for a user for which no publication has taken place. In that case, the PoC-settings document will not contain any <entity> element (see Section 6.1 for a detailed description of the <entity> element).
通知程序通常充当事件状态合成器（ESC），因此当用户更改其中一个设置时，将通过从用户的事件发布代理（EPA）发送的发布请求来了解poc设置事件状态。通知程序可能会为尚未发布的用户生成通知请求。在这种情况下，PoC设置文档将不包含任何<entity>元素（有关<entity>元素的详细说明，请参见第6.1节）。
For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME [9]. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME [9]. Since the NOTIFY is generated by the notifier, which may not have access to the key of the user represented by the poc-settings user, often the NOTIFY will be signed by a third party. The NOTIFY request SHOULD be signed by an authority over the domain of the user. In other words, for a user whose SIP URI is sip:user@example.com, the signator of the NOTIFY SHOULD be the authority for example.com.
出于隐私考虑，通常需要加密通知的内容。这可以通过使用S/MIME[9]实现。可以使用订阅请求的From字段中标识的订阅方密钥执行加密。类似地，通知的完整性对订阅者也很重要。因此，通知的内容可以使用S/MIME提供身份验证和消息完整性[9]。由于通知由通知程序生成，通知程序可能无法访问由poc设置用户表示的用户密钥，因此通知通常将由第三方签名。通知请求应由用户域上的权限签署。换句话说，对于SIP URI为SIP的用户：user@example.com，通知的签署人应为权威机构，例如：example.com。
RFC 3265 [5] leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state.
RFC 3265[5]让事件包来描述订阅者在收到通知请求后遵循的过程，包括形成一致资源状态所需的任何逻辑。
In this specification, each NOTIFY request contains either no PoC-settings document, or a document representing one or more PoC related settings for a given user. Within a dialog, the PoC-settings document in the NOTIFY request with the highest CSeq header field value is the current one. When no document is present in that NOTIFY, the PoC-settings document present in the NOTIFY with the next highest CSeq value is used.
在本规范中，每个NOTIFY请求要么不包含PoC设置文档，要么包含表示给定用户的一个或多个PoC相关设置的文档。在对话框中，通知请求中具有最高CSeq头字段值的PoC设置文档是当前文档。当该通知中没有文档时，将使用下一个最高CSeq值的通知中的PoC设置文档。
RFC 3265 [5] requires each package to describe handling of forked SUBSCRIBE requests.
RFC 3265[5]要求每个包描述分叉订阅请求的处理。
This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single subscriber is generating notifications for a particular subscription to a particular user. The result of this is that a user can have multiple SIP User Agents active, but these should be homogeneous, so that each can generate the same set of notifications for the user's poc-settings.
此规范仅允许在发出初始订阅请求后构造单个对话框。这保证只有一个订阅者为特定用户的特定订阅生成通知。这样做的结果是，用户可以有多个SIP用户代理处于活动状态，但这些代理应该是同质的，以便每个代理都可以为用户的poc设置生成相同的通知集。
RFC 3265 [5] requires each package to specify the maximum rate at which notifications can be sent.
RFC 3265[5]要求每个包指定可以发送通知的最大速率。
Poc-settings notifiers SHOULD NOT generate notifications for a single user at a rate of more than once every five seconds.
Poc设置通知程序不应以超过每五秒一次的速率为单个用户生成通知。
RFC 3265 [5] requires each package to consider the role of state agents in the package and, if they are used, to specify how authentication and authorization are done.
RFC 3265（5）要求每个包考虑包中的状态代理的作用，并且如果使用它们，则指定如何进行身份验证和授权。
This specification allows state agents to be located in the network. Publication of PoC-settings document is linked to a user. However, a user may be simultaneously logged in at different PoC terminals. If a user changes her PoC settings from a terminal, it will send a PUBLISH request containing a PoC-settings document. These settings are applicable to the user independently of the terminal at which she is logged in. In other words, PoC settings changes done in a terminal affect all the PoC terminals where the user is logged. It is RECOMMENDED that each of the terminals where the user is logged in subscribes to its own PoC-settings document in order to keep a coherent state view with the state agent.
此规范允许状态代理位于网络中。PoC设置文档的发布链接到用户。然而，用户可以在不同的PoC终端同时登录。如果用户从终端更改其PoC设置，它将发送包含PoC设置文档的发布请求。这些设置适用于用户，与用户登录的终端无关。换句话说，在终端中进行的PoC设置更改会影响用户登录的所有PoC终端。建议用户登录的每个终端订阅其自己的PoC设置文档，以便与状态代理保持一致的状态视图。
An example of a PoC-setting document is provided in Section 6.2.
第6.2节提供了PoC设置文件的示例。
RFC 3265 [5] allows packages to use URIs to retrieve large state documents.
RFC3265[5]允许包使用URI检索大型状态文档。
PoC-settings documents are fairly small. This event package does not provide a mechanism to use URIs to retrieve large state documents.
PoC设置文档相当小。此事件包不提供使用URI检索大型状态文档的机制。
RFC 3903 [8] requires event packages to define the content types expected in PUBLISH requests.
RFC 3903[8]要求事件包定义发布请求中预期的内容类型。
In this event package, the body of a PUBLISH request contains a PoC-settings document (see Section 6). This PoC-settings document describes the PoC-related settings of a user at an EPA. EPAs SHOULD include their own information in a PoC-settings document; i.e., there SHOULD be a single <entity> element in the body of the PUBLISH request (See Section 6.1 for a detailed description of the <entity> element).
在这个事件包中，发布请求的主体包含一个PoC设置文档（参见第6节）。本PoC设置文档描述了EPA用户的PoC相关设置。EPA应在PoC设置文件中包含自己的信息；i、 例如，发布请求正文中应该有一个<entity>元素（参见第6.1节了解<entity>元素的详细描述）。
All EPAs and ESCs MUST support the "application/poc-settings+xml" data format described in Section 6 and MAY support other formats.
所有EPA和ESC必须支持第6节中描述的“应用程序/poc设置+xml”数据格式，并且可能支持其他格式。
This specification does not associate semantics to a body in a PUBLISH response.
此规范不将语义与发布响应中的主体相关联。
RFC 3903 [8] requires event packages to specify whether multiple sources can contribute to the event state view at the ESC.
RFC 3903[8]要求事件包指定多个源是否可以对ESC的事件状态视图作出贡献。
This event package allows different EPAs to publish the PoC settings for a particular user. Each EPA publishes its own settings grouped in an <entity> element. The EPA provides a globally unique identifier for a given address of record. This allows the ESC to differentiate EPAs and either compose a state resolving conflicts or provide the union of the states of all the EPAs that contributed to it. The composition policy at the ESC is outside the scope of this document.
此事件包允许不同的EPA发布特定用户的PoC设置。每个EPA发布自己的设置，分组在<entity>元素中。EPA为给定的记录地址提供全局唯一标识符。这使得ESC能够区分EPA，或者组成一个解决冲突的州，或者提供促成冲突的所有EPA的州的联盟。ESC的组成政策不在本文件范围内。
RFC 3903 [8] defines segments within a state document. Each segment is defined as one of potentially many identifiable sections in the published event state.
RFC 3903[8]定义状态文档中的段。每个段定义为已发布事件状态中可能存在的多个可识别段之一。
This event package defines, for a given EPA, four segments identified by the elements <isb-settings>, <am-settings>, <ipab-settings>, and <sss-settings>, respectively. Each of them refers to different states of the EPA.
对于给定的EPA，此事件包分别定义了由元素<isb设置>、<am设置>、<ipab设置>和<sss设置>标识的四个段。每一个都是指美国环保署的不同州。
RFC 3903 [8] allows event packages to define their own rate of publication.
RFC 3903[8]允许事件包定义自己的发布速率。
There are no rate-limiting recommendations for poc-settings publication. Since changes in a PoC-settings document are typically triggered by interaction with a human user, there is not periodicity, nor a minimum or maximum rate of publication.
poc设置发布没有速率限制建议。由于PoC设置文档中的更改通常由与人类用户的交互触发，因此没有周期性，也没有最小或最大发布速率。
PoC-settings is an XML document [10] that MUST be well-formed and SHOULD be valid. PoC-settings documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [7]. This specification makes use of XML namespaces for identifying PoC-settings documents. The namespace URI for elements defined by this specification is a URN [2], using the namespace identifier 'oma'. This URN is:
PoC设置是一个XML文档[10]，必须格式正确且有效。PoC设置文档必须基于XML 1.0，并且必须使用UTF-8编码[7]。本规范使用XML名称空间来标识PoC设置文档。此规范定义的元素的名称空间URI是一个URN[2]，使用名称空间标识符“oma”。这个骨灰盒是：
urn:oma:params:xml:ns:poc:poc-settings
urn:oma:params:xml:ns:poc:poc-settings
PoC-settings documents are identified with the MIME type "application/poc-settings+xml" and are instances of the XML schema defined in Section 6.1.
PoC设置文档由MIME类型“application/PoC settings+xml”标识，是第6.1节中定义的xml模式的实例。
A PoC-settings document begins with the root element tag <poc-settings>. It consists of zero or more <entity> elements, each one including an 'id' attribute that contains a globally unique identifier for a given address of record that represents an EPA. An <entity> element represents an EPA, and it is uniquely identified by the 'id' attribute. EPAs SHOULD include a single <entity> element in a PoC-settings document. ESCs MAY include several <entity> elements in a PoC-settings document, typically when the ESC is unable to resolve conflicts due to incongruent publication from different sources.
PoC设置文档以根元素标记<PoC设置>开始。它由零个或多个<entity>元素组成，每个元素都包含一个“id”属性，该属性包含一个表示EPA的给定记录地址的全局唯一标识符。<entity>元素表示EPA，它由“id”属性唯一标识。EPA应在PoC设置文档中包含单个<entity>元素。ESC可能在PoC设置文档中包含多个<entity>元素，通常是当ESC由于来自不同来源的不一致发布而无法解决冲突时。
A valid PoC-settings document can include zero <entity> elements if the ESC provides a notification for which no publication has occurred.
如果ESC提供未发布的通知，则有效的PoC设置文档可以包含零<entity>元素。
The <entity> element MAY contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
出于可扩展性的目的，<entity>元素可能包含来自不同名称空间的其他元素和属性；必须忽略未知名称空间中的元素或属性。
The <entity> element consists of zero or one <isb-settings> elements,
zero or one <am-settings> elements, zero or one <ipab-settings>, and
zero or one <sss-settings> elements. Other elements and attributes
The <entity> element consists of zero or one <isb-settings> elements,
zero or one <am-settings> elements, zero or one <ipab-settings>, and
zero or one <sss-settings> elements. Other elements and attributes
from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
出于可扩展性的目的，可能存在来自不同名称空间的名称；必须忽略未知名称空间中的元素或属性。
An <isb-settings> element contains a single <incoming-session-barring> element that contains a boolean 'active' attribute. The 'active' attribute indicates whether incoming sessions are barred at the UA, depending on the user's preferences for this setting. Other elements and attributes from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
<isb settings>元素包含一个包含布尔“active”属性的<incoming session barring>元素。“活动”属性表示UA是否禁止传入会话，具体取决于用户对此设置的首选项。出于可扩展性的目的，可能存在来自不同名称空间的其他元素和属性；必须忽略未知名称空间中的元素或属性。
An <am-settings> element contains an <answer-mode> element, whose value can be set to either "automatic" or "manual". Other elements and attributes from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
<am设置>元素包含一个<answer mode>元素，其值可以设置为“自动”或“手动”。出于可扩展性的目的，可能存在来自不同名称空间的其他元素和属性；必须忽略未知名称空间中的元素或属性。
A server such as a URI-list server [11] receives a SIP request addressed to one or more recipients. If the intended recipient set the <answer-mode> to "manual", the URI-list server proceeds with the session attempt. If she set it to "automatic", the URI-list server generates a 200-class response prior to contacting the intended recipient.
诸如URI列表服务器[11]之类的服务器接收发往一个或多个接收者的SIP请求。如果目标收件人将<answer mode>设置为“manual”，URI列表服务器将继续会话尝试。如果她将其设置为“自动”，URI列表服务器将在联系预期收件人之前生成200类响应。
An <ipab-settings> element contains a single <incoming-personal-alert-barring> element that contains a boolean 'active' attribute. The 'active' attribute indicates whether incoming personal alert messages are barred at the UA, depending on the user's preferences for this setting. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
<ipab设置>元素包含一个包含布尔“活动”属性的<incoming personal alert barring>元素。“活动”属性表示UA是否禁止传入个人警报消息，具体取决于用户对此设置的偏好。出于可扩展性的目的，可能存在来自不同名称空间的其他元素；必须忽略未知名称空间中的元素或属性。
An <sss-settings> element contains a single <simultaneous-sessions-support> element that contains a boolean 'active' attribute. The 'active' attribute indicates whether the SIP UA is willing to handle more than one PoC session simultaneously. If the 'active' attribute is set to "false" or "0", then when the SIP UA is engaged in a PoC session, and the SIP UA receives an second incoming request for a SIP PoC session, the UA will decline the invitation. If the 'active' attribute is set to "true" or "1", then when the SIP UA is engaged in a PoC session, and the SIP UA receives an second incoming request for a SIP PoC session, the UA will possibly accept the invitation. Other elements and attributes from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
<sss settings>元素包含一个包含布尔“active”属性的<synchronous sessions support>元素。“active”属性表示SIP UA是否愿意同时处理多个PoC会话。如果“active”属性设置为“false”或“0”，则当SIP-UA参与PoC会话，并且SIP-UA接收到SIP-PoC会话的第二个传入请求时，UA将拒绝该邀请。如果“active”属性设置为“true”或“1”，则当SIP-UA参与PoC会话，并且SIP-UA接收到SIP-PoC会话的第二个传入请求时，UA可能会接受该邀请。出于可扩展性的目的，可能存在来自不同名称空间的其他元素和属性；必须忽略未知名称空间中的元素或属性。
Implementations according to this specification MUST comply to the following XML Schema, which defines the constraints of the PoC-settings document:
根据本规范的实现必须符合以下XML模式，该模式定义了PoC设置文档的约束：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oma:params:xml:ns:poc:poc-settings"
xmlns="urn:oma:params:xml:ns:poc:poc-settings"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oma:params:xml:ns:poc:poc-settings"
xmlns="urn:oma:params:xml:ns:poc:poc-settings"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition in support of the Incoming Session
Barring, Answer Mode, Incoming Personal Alert Barring,
and Simultaneous Sessions Support in the Push-to-talk
over Cellular (PoC) service.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition in support of the Incoming Session
Barring, Answer Mode, Incoming Personal Alert Barring,
and Simultaneous Sessions Support in the Push-to-talk
over Cellular (PoC) service.
</xs:documentation>
</xs:annotation>
<xs:element name="poc-settings" type="poc-settingsType"/>
<xs:element name="poc-settings" type="poc-settingsType"/>
<xs:complexType name="poc-settingsType">
<xs:sequence>
<xs:element name="entity" type="entityType"
minOccurs="0" maxOccurs="unbounded" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="poc-settingsType">
<xs:sequence>
<xs:element name="entity" type="entityType"
minOccurs="0" maxOccurs="unbounded" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="entityType">
<xs:sequence>
<xs:element name="isb-settings" type="isbSettingType"
minOccurs="0"/>
<xs:element name="am-settings" type="amSettingType"
minOccurs="0"/>
<xs:element name="ipab-settings" type="ipabSettingType"
minOccurs="0"/>
<xs:element name="sss-settings" type="sssSettingType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:complexType name="entityType">
<xs:sequence>
<xs:element name="isb-settings" type="isbSettingType"
minOccurs="0"/>
<xs:element name="am-settings" type="amSettingType"
minOccurs="0"/>
<xs:element name="ipab-settings" type="ipabSettingType"
minOccurs="0"/>
<xs:element name="sss-settings" type="sssSettingType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="isbSettingType">
<xs:sequence>
<xs:element name="incoming-session-barring">
<xs:complexType>
<xs:attribute name="active" type="xs:boolean"
use="required" />
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="isbSettingType">
<xs:sequence>
<xs:element name="incoming-session-barring">
<xs:complexType>
<xs:attribute name="active" type="xs:boolean"
use="required" />
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="amSettingType">
<xs:sequence>
<xs:element name="answer-mode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="automatic"/>
<xs:enumeration value="manual"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="amSettingType">
<xs:sequence>
<xs:element name="answer-mode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="automatic"/>
<xs:enumeration value="manual"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ipabSettingType">
<xs:sequence>
<xs:element name="incoming-personal-alert-barring">
<xs:complexType>
<xs:attribute name="active" type="xs:boolean"
use="required" />
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ipabSettingType">
<xs:sequence>
<xs:element name="incoming-personal-alert-barring">
<xs:complexType>
<xs:attribute name="active" type="xs:boolean"
use="required" />
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="sssSettingType">
<xs:sequence>
<xs:element name="simultaneous-sessions-support">
<xs:complexType>
<xs:attribute name="active" type="xs:boolean"
use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="sssSettingType">
<xs:sequence>
<xs:element name="simultaneous-sessions-support">
<xs:complexType>
<xs:attribute name="active" type="xs:boolean"
use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:schema>
</xs:schema>
The following is an example of a PoC-settings document:
以下是PoC设置文档的示例：
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<poc-settings xmlns="urn:oma:params:xml:ns:poc:poc-settings">
<entity id="do39s8zksn2d98x">
<isb-settings>
<incoming-session-barring active="true"/>
</isb-settings>
<am-settings>
<answer-mode>automatic</answer-mode>
</am-settings>
<ipab-settings>
<incoming-personal-alert-barring active="false"/>
</ipab-settings>
<sss-settings>
<simultaneous-sessions-support active="true"/>
</sss-settings>
</entity>
</poc-settings>
<poc-settings xmlns="urn:oma:params:xml:ns:poc:poc-settings">
<entity id="do39s8zksn2d98x">
<isb-settings>
<incoming-session-barring active="true"/>
</isb-settings>
<am-settings>
<answer-mode>automatic</answer-mode>
</am-settings>
<ipab-settings>
<incoming-personal-alert-barring active="false"/>
</ipab-settings>
<sss-settings>
<simultaneous-sessions-support active="true"/>
</sss-settings>
</entity>
</poc-settings>
The "poc-settings" event package defined by this document is meant to be transported with SIP PUBLISH requests. Therefore, the Security Considerations (Section 14) in RFC 3903 [8] apply to this document. In particular, the settings contained in the "poc-settings" event package are applicable to the user that generated the SIP PUBLISH request. Therefore, servers that receive SIP PUBLISH requests containing a "poc-settings" event package SHOULD authenticate the user prior to authorizing the event publication (as required by RFC 3903 [8]).
本文档定义的“poc设置”事件包将与SIP发布请求一起传输。因此，RFC 3903[8]中的安全注意事项（第14节）适用于本文件。具体而言，“poc设置”事件包中包含的设置适用于生成SIP发布请求的用户。因此，接收包含“poc设置”事件包的SIP发布请求的服务器应在授权事件发布之前对用户进行身份验证（按照RFC 3903[8]的要求）。
Authentication and authorization of subscriptions have been discussed in Section 5.6. Lack of authentication or authorization may provide poc-settings information to unauthorized parties, who can use that information for creating attacks. For example, an unauthorized recipient of a PoC-settings document can learn that the publisher's terminal is set to answer PoC sessions in automatic answer mode and then create a malicious session containing inappropriate media that the UAS will play automatically. Or the attacker can learn that the terminal is willing to receive simultaneous PoC sessions and then try to exhaust resources in the SIP UA by creating bogus PoC sessions that leave hung states in the attacked SIP UA.
第5.6节讨论了订阅的身份验证和授权。缺乏身份验证或授权可能会向未经授权的方提供poc设置信息，这些方可以使用该信息创建攻击。例如，PoC设置文档的未经授权的接收者可以了解到发布者的终端被设置为以自动应答模式应答PoC会话，然后创建包含UAS将自动播放的不适当媒体的恶意会话。或者，攻击者可以了解到终端愿意同时接收PoC会话，然后通过创建虚假的PoC会话，在受攻击的SIP UA中留下挂起状态，尝试耗尽SIP UA中的资源。
Integrity protection and confidentiality of notifications are also discussed in Section 5.7. If a notifier does not encrypt bodies of NOTIFY requests, an eavesdropper could learn the status of a SIP user agent and use it to create malicious PoC sessions. If the notifier does not integrity protect the bodies of NOTIFY requests, a man-in-the-middle attacker or malicious SIP proxy could modify the contents of the poc-settings event package notification. Although this does not cause harm, it can create annoyances (e.g., media clip due to lack of buffering) when PoC sessions are delivered to the user.
第5.7节还讨论了通知的完整性保护和保密性。如果通知程序不加密NOTIFY请求的主体，则窃听者可以了解SIP用户代理的状态，并使用它创建恶意PoC会话。如果通知程序没有完整性保护NOTIFY请求的主体，中间人攻击者或恶意SIP代理可以修改poc设置事件包通知的内容。虽然这不会造成伤害，但当PoC会话交付给用户时，它可能会造成麻烦（例如，由于缺少缓冲而产生的媒体剪辑）。
The author wants to thank Ilkka Westman, Andrew Allen, Chinmay Padhye, Gonzalo Camarillo, Paul Kyzivat, Haris Zisimopoulos, Joel M. Halpern, and Russ Housley for their comments.
作者要感谢Ilkka Westman、Andrew Allen、Chinmay Padhye、Gonzalo Camarillo、Paul Kyzivat、Haris Zisimopoulos、Joel M.Halpern和Russ Housley的评论。
This specification registers an event package, based on the registration procedures defined in RFC 3265 [5]. The following is the information required for such a registration:
本规范根据RFC 3265[5]中定义的注册过程注册事件包。以下是此类注册所需的信息：
Package Name: poc-settings
软件包名称：poc设置
Package or Template-Package: This is a package.
包或模板包：这是一个包。
Published Document: RFC 4354
已出版文件：RFC 4354
Person to Contact: Miguel A. Garcia-Martin, miguel.an.garcia@nokia.com
联系人：Miguel A.Garcia Martin，Miguel.an。garcia@nokia.com
To: ietf-types@iana.org
致：ietf-types@iana.org
Subject: Registration of MIME media type application/ poc-settings+xml
主题：注册MIME媒体类型应用程序/poc设置+xml
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: poc-settings+xml
MIME子类型名称：poc设置+xml
Required parameters: (none)
所需参数：（无）
Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8 [7].
可选参数：字符集；指示封闭XML的字符编码。默认值为UTF-8[7]。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [3], Section 3.2.
编码注意事项：使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 3023[3]，第3.2节。
Security considerations: This content type is designed to carry information about current PoC user settings, which in some cases may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information.
安全注意事项：此内容类型旨在承载有关当前PoC用户设置的信息，在某些情况下，这些信息可能被视为私人信息。应采取适当的预防措施来限制该信息的披露。
Interoperability considerations: This content type provides a common format for exchange of PoC settings information.
互操作性注意事项：此内容类型为PoC设置信息的交换提供了通用格式。
Published specification: RFC 4354 (this document).
已发布规范：RFC 4354（本文件）。
Applications which use this media type: Push-to-talk over Cellular systems in compliance with the Open Mobile Alliance (OMA) PoC specifications.
使用此媒体类型的应用程序：符合开放移动联盟（OMA）PoC规范的蜂窝式一键通系统。
Additional information: The Open Mobile Alliance publishes the Push-to-talk over Cellular specifications in the OMA web site at http://www.openmobilealliance.org
附加信息：开放式移动联盟在OMA网站上发布了移动电话一键通规范，网址为http://www.openmobilealliance.org
Person & email address to contact for further information: Miguel A. Garcia-Martin, miguel.an.garcia@nokia.com
联系人和电子邮件地址，以获取更多信息：Miguel A.Garcia Martin，Miguel.an。garcia@nokia.com
Intended usage: Limited use, restricted to PoC terminals and servers.
预期用途：有限用途，仅限于PoC终端和服务器。
Author/Change controller: Open Mobile Alliance (http://www.openmobilealliance.org), PoC working group.
作者/变更控制者：开放移动联盟(http://www.openmobilealliance.org)，PoC工作组。
Other information: This media type is a specialization of application/xml RFC 3023 [3], and many of the considerations described there also apply to application/poc-settings+xml.
其他信息：此媒体类型是application/xml RFC 3023[3]的一种专门化，其中描述的许多注意事项也适用于application/poc设置+xml。
[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] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[3] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[4] 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.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[6] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[6] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[8] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[8] Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[9] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[10] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000.
[10] Paoli，J.，Sperberg McQueen，C.，Bray，T.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C第一版REC-XML-20001006，2000年10月。
[11] Camarillo, G. and A. Roach, "Requirements and Framework for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Work in Progress, April 2005.
[11] Camarillo，G.和A.Roach，“会话启动协议（SIP）统一资源标识符（URI）-列表服务的要求和框架”，正在进行的工作，2005年4月。
[12] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, January 2006.
[12] Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年1月。
Author's Address
作者地址
Miguel A. Garcia-Martin Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland
芬兰芬兰芬兰诺基亚集团407号诺基亚邮政信箱，邮编：00045
EMail: miguel.an.garcia@nokia.com
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 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 BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。