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）は、SIPプロトコルがこのドキュメントでは、SIPを定義するなど、インスタントメッセージを送信するために、別の参加者間での半二重メディアセッションを確立するために使用されるプッシュツートークセルラーオーバー（POC）サービスを定義していますイベントパッケージは、PoCサービスに必要な追加機能の出版、サブスクリプション、および通知をサポートします。このSIPイベントパッケージは、PoCサービスに適用可能であり、一般的なインターネットには適用できない場合があります。
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
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).
SIPのPoC端末がプッシュツートークする（例えば、VoIP電話、プレゼンスサービス、メッセージングサービス、等）を加えて、種々のSIPベースの通信サービスをサポートすることができます。ユーザーは、時間ではまだ一つ以上の他の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アーキテクチャは、会議フォーカス[12]、RTPトランスレータ、またはポリシーサーバーとしての役割を実行することができるネットワーク内のSIPサーバを利用します。呼び出し側に早期または未確認の指標を提供し、呼び出し側が起動できるようにするために、メディアパケットのバッファリングを行うためにSIPネットワークサーバで構成されて話をする指示と共に、発信者の提供の遅延を最小限に抑えることが可能な最適化と呼ばれる前に話しますPoC端末が応答しました。この最適化は唯一と呼ばれるPoC端末は、現在のPoCセッションを受け入れている時に適切であり、その応答モードは、自動応答に設定されています。この最適化はそのためと呼ばれるPoC端末の現在のISBとAMの設定の知識を持っているネットワークのSIPサーバーが必要です。
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は、サーバーが単一の帯域幅制限された無線ベアラを使用して複数のセッション間でメディアシグナリングおよびフロア制御を多重化するために、B2BUAとして機能する必要が同時に複数のPoCセッションをサポートしている場合。必要とされていない同時に複数の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 PoC端末とSIPネットワークサーバとの間のISB、AM、IPAB、およびSSSの設定の通信を可能にするために、追加のSIP機能を提案しています。
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イベントパブリケーションエージェント（EPA）は、いくつかの特定のセッションの試みに影響を与える可能性があり、その特定のEPAのユーザの設定を公開することを可能にするSIPイベントパッケージを定義します。これは、加入者がこの情報を収集し、セッションがそのユーザーにしようとした場合、ユーザーのニーズに予想するために、このイベントパッケージにイベントステートコンポジを購読することができます。 PoCサービスのアーキテクチャを提供するために設計されています：ここで定義されたSIPイベントパッケージは、一般的なインターネットには適用されないと考えられています。特に、およびRFC 3903によって定義されたコンテキストに[8]、PoC端末がイベント公開エージェント（EPA）として動作し、ネットワークサーバは、イベント状態として動作させるためにOMAの意図であります
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）。 1台の端末で行われたこの状態の変化はすべて異なる端子間または特定のユーザーのためのネットワーク・サーバに同期して保持されるようにする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.
この文書では、EPAは、ESCへのISB、AM、IPAB、およびSSSの設定を伝達することを可能にするPoC-設定文書を定義します。 EPAは、PoC-設定文書がでPUBLISHリクエストを送信します[8]。 PoC-設定文書が含まれている設定は、その特定のEPAで表示表します。 ESCは、異なる経済連携協定で同じユーザのためのPoC-設定文書を収集する組成ポリシーを適用し、通知を提供することができます。通知は、ESCは、競合を解決できるかどうかに応じて、設定の合成されたビューまたはEPAあたりの設定のリストを含めることができます。加入者は、RFC 3265で指定された手順に従って、この文書で変更の通知を受信することができる[5]。このメモの目的は、[6] RFC 3427に示された手順に従うことと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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
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と一緒に使用されることを意図し、任意のイベントパッケージは、この方法が問題部を含むことを有するPUBLISH。また、このセクションでは、PUBLISHリクエストで使用するすべてのイベントパッケージのための情報を埋めます。
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）は、POC-設定イベントパッケージの変更のイベントステートコンポジ（ESC）を通知するためにPUBLISHリクエストを使用します。変更が生じたときに通知として機能し、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]、この値はSUBSCRIBE及びNOTIFYリクエスト中に存在するイベントヘッダフィールドに現れます。 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]、SUBSCRIBEリクエストは、本体を含むことができます。体の目的は、その種類によって異なります。 POC-設定イベントパッケージへのサブスクリプションは、通常、体は含まれません。
The Request-URI of the SUBSCRIBE request identifies the user about whose poc-settings the subscriber wants to be informed.
SUBSCRIBEリクエストのRequest-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秒です。 ExpiresヘッダーフィールドにRFC 3265に従って、[5]、加入者は、別の有効期限を指定するかもしれません。
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ヘッダーフィールドはSUBSCRIBEリクエストから省略された場合には、この本体は、SUBSCRIBEリクエストのAcceptヘッダーフィールドにリストされた形式、またはパッケージ固有のデフォルトフォーマットです。
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は異なる経済連携協定で、ユーザーのためのPoC-設定文書を集めています。 ESCは、組成物のポリシーを適用し、異なるのEPA全体のすべてのこれらの設定の一般的な観点でのPoC-設定文書を構成します。場合ESCは、二つの異なるのEPAによって提供矛盾した情報に、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-の設定」イベントパッケージのすべての加入者とノーティファイアはSUBSCRIBEリクエストは、Acceptヘッダーフィールドを含むかもしれ6章に記載された「アプリケーション/ POC-設定+ xmlの」データ・フォーマットをサポートしなければなりません。このようなヘッダフィールドが存在しない場合、それは（イベントヘッダフィールドが「POC-設定」の値が含まれていることを仮定して）「+ XMLアプリケーション/ POC-設定」のデフォルト値を有しています。 Acceptヘッダーフィールドが存在する場合、それは「+ XMLアプリケーション/ POC-設定」を含まなければならないとする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.
認証されると、通知は、許可決定を行います。認証は、ユーザによって提供されていない限り、通知は、サブスクリプションを受け入れてはいけません。認可が提供される手段は、この文書の範囲外です。認可は、おそらく、Webページで指定したアクセスリストによって事前に提供されている可能性があります。認可は、標準化されたアクセス制御リスト、ドキュメントのいくつかの種類をアップロードする手段により提供された可能性があります。
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メッセージのフォーマットと構造を詳しく説明します。ただし、パッケージは中性または偽の状態情報を生成する方法を、リソースの状態を計算する方法を、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.
通知はいつでもNOTIFYを送信することができます。典型的には、それが1を送信するときに、ユーザーが変更のPOC-設定段階。 NOTIFYリクエストは、PoC-設定文書を含むボディを含むかもしれません。 NOTIFYれる時間は、特定の加入者のために送られ、その通知内ボディの内容は、サブスクリプションを管理する許可ポリシーによって指定されたルールの対象となっています。しかし、一般的に変更が発生したため、これらのPoC関連サービスの表示が含まれていますNOTIFY。
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.
最終的な許可が判定された場合、保留中のサブスクリプションの場合には、NOTIFY送信することができます。認可判定の結果が成功した場合は、NOTIFYを送ってくださいと、ユーザーののPoC設定の現在の状態と完全のPoC-設定文書を含むべきです。サブスクリプションが拒否された場合、NOTIFYが送られるかもしれません。 RFC 3265に記載されているように[5]、Subscription-Stateヘッダフィールドは、サブスクリプションの状態を示しています。
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.
NOTIFYのボディはない受け入れヘッダフィールド場合、最新SUBSCRIBEリクエスト、またはタイプを使用して「アプリケーション/ POC-設定+ XML」のAcceptヘッダーフィールドにリストされたタイプのいずれかを使用して送信されなければならない存在でした。
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-設定イベント状態を学びます。通知は一切公表が行われなかったため、ユーザのためのNOTIFYリクエストを生成することが可能です。その場合、のPoC - 設定文書は、任意の<エンティティ>要素（<エンティティ>要素の詳細については、セクション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]。 SUBSCRIBEリクエストのFromフィールドで識別される暗号化は、加入者の鍵を使用して行うことができます。同様に、通知の整合性は、加入者にとって重要です。このように、通知の内容は、[9] S / MIMEを使用して、認証とメッセージ整合性を提供してもよいです。 NOTIFYがPOC-設定ユーザによって表されるユーザのキーへのアクセス権を持っていない可能性が通知、によって生成されるので、しばしばザがNOTIFY第三者によって署名されます。 NOTIFYリクエストは、ユーザーのドメインに対する権限によって署名されなければなりません。言い換えれば、そのSIP URI一口であるユーザーのために：user@example.com、NOTIFYのある署名は、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]コヒーレントリソース状態を形成するのに必要なロジックを含むNOTIFYリクエストを受信すると、加入者続く工程を説明するために、イベント・パッケージにそれを残します。
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.
本明細書では、各要求がないのPoC-設定文書、または特定のユーザーのための1つまたは複数のPoCに関する設定を表す文書のいずれかを含まないNOTIFY。ダイアログ内で、最高CSeqヘッダーフィールド値を持つNOTIFYリクエストでのPoC - 設定文書は、現在のものです。何の文書は、そのNOTIFYに存在しない場合は、次の最高のCSeq値を持つNOTIFYでのPoC-設定文書の存在が使用されています。
RFC 3265 [5] requires each package to describe handling of forked SUBSCRIBE requests.
RFC 3265 [5] SUBSCRIBEフォーク要求の処理を記述するために各パッケージが必要です。
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.
この仕様は、最初のSUBSCRIBEリクエストを発する結果として構築される単一の対話を可能にします。これは、単一の加入者は、特定のユーザーに特定のサブスクリプションの通知を生成していることを保証します。この結果は、ユーザーがアクティブな複数の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-設定通知者は、5秒に1回以上の割合で、単一のユーザーのための通知を生成するべきではありません。
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-設定文書を含むPUBLISHリクエストを送信します。これらの設定は、彼女がログインしている時に、端末の独立ユーザーに適用されている。言い換えれば、のPoC端末で行われた変更は、ユーザーがログインしているすべてのPoC端末に影響する設定します。ことをお勧めし、ユーザが状態剤とコヒーレント状態のビューを維持するために、独自のPoC-設定文書に加入ログインしている各端末。
An example of a PoC-setting document is provided in Section 6.2.
PoC-設定文書の例は、セクション6.2で提供されています。
RFC 3265 [5] allows packages to use URIs to retrieve large state documents.
RFC 3265 [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]でPUBLISHリクエストを期待コンテンツタイプを定義するイベントパッケージが必要です。
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).
このイベントパッケージでは、PUBLISHリクエストのボディは、PoC-設定文書を（セクション6を参照）が含まれています。これのPoC-設定文書には、EPAでのユーザーののPoC関連の設定について説明します。 EPAは、PoC-設定文書で自分の情報を含むべきです。すなわち、（<エンティティ>要素の詳細については、セクション6.1を参照）要求を発行するの体内の単一の<エンティティ>要素が存在すべきです。
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.
この仕様は、PUBLISH応じて身体にセマンティクスを関連付けません。
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.
このイベントパッケージは、異なる経済連携協定は、特定のユーザーのためのPoC設定を公開することができます。各EPAは、<実体>要素にグループ化された独自の設定を公開しています。 EPAは、レコードの指定されたアドレスのグローバル一意識別子を提供します。これはESCは、経済連携協定を区別し、どちらかの状態解消競合を構成するか、それに貢献し、すべての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.
このイベントパッケージは、それぞれ、<IPAB-設定>、<AM-設定>、所与のEPAのために、要素<ISB-設定>によって識別される4つのセグメントを定義し、<SSS-設定>。それらのそれぞれは、EPAの異なる状態を指します。
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]。この仕様は、PoC-設定文書を識別するためのXML名前空間を使用しています。この仕様によって定義された要素の名前空間URIは、名前空間識別子「OMA」を使用してURN [2]です。このURNは以下のとおりです。
urn:oma:params:xml:ns:poc:poc-settings
URN：OMA：のparams：XML：NS：少し：ビットの設定
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タイプ「アプリケーション/ POC-設定+ 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-設定>で始まります。これは、ゼロ以上の<エンティティ>要素、EPAを表すレコードの指定されたアドレスのグローバル一意識別子を含む「ID」属性を含む各から成ります。 <エンティティ>要素は、EPAを表し、それは一意に「ID」属性によって識別されます。 EPAは、PoC-設定文書内の単一の<entity>要素を含むべきです。 ESCは、ESCは、異なるソースからの不適合出版による競合を解決することができない、典型的場合、のPoC-設定文書におけるいくつかの<エンティティ>要素を含むことができます。
A valid PoC-settings document can include zero <entity> elements if the ESC provides a notification for which no publication has occurred.
ESCはない刊行物が発生しなかったの通知を提供する場合、有効なのPoC - 設定文書はゼロ<エンティティ>要素を含むことができます。
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.
<エンティティ>要素は、拡張のために異なる名前空間から他の要素及び属性を含むかもしれません。未知の名前空間からの要素や属性を無視しなければなりません。
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.
<エンティティ>要素は、0または1 <ISB-設定>要素、0または1 <AM-設定>要素、0または1 <IPAB-設定>、および0または1 <SSS-設定>要素で構成されています。異なる名前空間から他の要素と属性は、拡張性の目的のために存在していてもよく、未知の名前空間からの要素や属性を無視しなければなりません。
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-設定>要素はブール「アクティブ」属性を含む単一の<着信セッション禁止>要素が含まれています。 「アクティブ」属性は、この設定のため、ユーザーの好みに応じて、着信セッションは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-設定>要素は、その値が「自動」または「手動」のいずれかに設定することができます。<解答モード>要素が含まれています。異なる名前空間から他の要素と属性は、拡張性の目的のために存在していてもよく、未知の名前空間からの要素や属性を無視しなければなりません。
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要求を受信したようなサーバは、1人以上の受信者に宛て。目的の受信者は、セッションの試みで、「手動」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-設定>要素はブール「アクティブ」属性を含む単一の<着信個人アラート - 禁じる>要素が含まれています。 「アクティブ」属性は、この設定のため、ユーザーの好みに応じて、入ってくる個人的な警告メッセージが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-設定>要素はブール「アクティブ」属性を含む単一の<同時セッション・サポート>要素が含まれています。 「アクティブ」属性は、SIP UAが同時に複数のPoCセッションを処理する意思があるかどうかを示します。 「アクティブ」属性は「偽」または「0」に設定されている場合、SIP UAがPoCセッションに従事し、かつSIP UAは、SIP PoCセッションのために第二の着信要求を受信したとき、次に、UAは、招待を拒否します。 「アクティブ」属性が「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:
本明細書に記載の実施態様は、PoC-設定文書の制約を定義する次のXMLスキーマに準拠する必要があります。
<?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" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：OMA：のparams：XML：NS：POC：POC-設定" のxmlns = "壷：OMA：のparams：XML ：NS：POC：POC-の設定」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<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：インポート名前空間= "http://www.w3.org/XML/1998/namespace" のschemaLocation = "http://www.w3.org/2001/xml.xsd" /> <XS：注釈> < XS：ドキュメントのXML：LANG =「EN」>無ければ着信セッションをサポートするXMLスキーマ定義は、モードは、着信個人アラートがバーリング回答、およびプッシュツートークオーバーセルラー（PoC）サービスでの同時セッションをサポート。 </ XS：ドキュメンテーション> </ XS：注釈>
<xs:element name="poc-settings" type="poc-settingsType"/>
<のX：要素名=「短期の設定」タイプ=「短期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の名前= "POC-settingsType"> <XS：配列> <XS：要素名= "エンティティ" タイプ= "entityType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：任意の名前空間=」 ##他の」のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ 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の名前= "entityType"> <XS：シーケンス> <XS：要素名= "ISB-設定" タイプ= "isbSettingType" のminOccurs = "0" /> <XS：要素名= "AM-設定" タイプ= "amSettingType" のminOccurs = "0" /> <XS：要素名= "IPAB-設定" タイプ= "ipabSettingType" のminOccurs = "0" /> <XS：要素名= "SSS-設定" タイプ= "sssSettingType" minOccurs = "0" /> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" />
</xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType>
</ XS：シーケンス> <XS：属性名= "ID" タイプ= "XS：文字列" 使用= "必須" /> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ 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の名前= "isbSettingType"> <XS：配列> <XS：要素名= "着信セッション禁止"> <XS：complexTypeの> <XS：属性名= "アクティブ" タイプ= "XS：ブール"使用= "必須" /> </ XS：complexTypeの> </ XS：要素> <XS：任意の名前空間= "##あらゆる" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS ：シーケンス> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ 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の名前= "amSettingType"> <XS：配列> <XS：要素名= "モードに答える"> <XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "自動" /> <XS：列挙値= "マニュアル" /> </ XS：制限> </ XS：単純> </ XS：要素> <XS：任意の名前空間= "##いずれか" のprocessContents = "緩いです" minOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ 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の名前= "ipabSettingType"> <XS：シーケンス> <XS：要素名= "着信パーソナルアラート禁じる"> <XS：complexTypeの> <XS：属性名= "アクティブ" タイプ= "XS：ブール」使用= "必須" /> </ XS：complexTypeの> </ XS：要素> <XS：任意の名前空間= "##あらゆる" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> < / XS：シーケンス> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ 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の名前= "sssSettingType"> <XS：シーケンス> <XS：要素名= "同時セッションサポート"> <XS：complexTypeの> <XS：属性名= "アクティブ" タイプ= "XS：ブール"使用= "必須" /> </ XS：complexTypeの> </ XS：要素> <XS：任意の名前空間= "##あらゆる" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS ：シーケンス> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：complexTypeの>
</xs:schema>
</ XS：スキーマ>
The following is an example of a PoC-settings document:
以下は、PoC-設定文書の例です。
<?xml version="1.0" encoding="UTF-8"?>
<？xml version = "1.0" エンコード= "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-設定のxmlns = "URN：OMA：paramsは：XML：NS：POC：POC-設定"> <エンティティID = "do39s8zksn2d98x"> <ISB-設定> <アクティブ着信セッション禁止= "TRUE" /> </ ISB-設定> <AM-設定> <答えるモード>自動</解答モード> </ AM-設定> <IPAB-設定> <着信個人アラート - 除けアクティブ= "偽" /> < / IPAB-設定> <SSS-設定> <同時セッションサポートアクティブ= "真" /> </ SSS-設定> </エンティティ> </ POC-設定>
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におけるセキュリティの考慮事項（セクション14）[8]この文書に適用されます。具体的には、「POC-設定」イベントパッケージに含まれる設定は、SIP要求を発行する生成されたユーザに適用可能です。そのため、SIPは「POC-設定」イベントパッケージを含む要求を発行する受信サーバーは、前イベント公開を許可するユーザを認証すべきである（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セッションを受信し、攻撃SIP UAにハング状態のままに偽のPoCセッションを作成することにより、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リクエストのボディを保護しない場合は、のman-in-the-middle攻撃や悪意のある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.
作者は彼らのコメントのためにイルッカ・ウエストマン、アンドリュー・アレン、Chinmay Padhye、ゴンサロ・カマリロ、ポールKyzivat、ハリスZisimopoulos、ジョエルM.ハルパーン、とラス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
連絡先となる担当者：ミゲルA.ガルシア・マーティン、miguel.an.garcia@nokia.com
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of MIME media type application/ poc-settings+xml
件名：MIMEメディアタイプapplication / POC-設定の登録+ xmlの
MIME media type name: application
MIMEメディアタイプ名：application
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.
エンコードの考慮事項：使用される文字エンコーディングに応じて、8ビット文字を採用することができるXMLを使用しています。 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
追加情報：オープン・モバイル・アライアンスはhttp://www.openmobilealliance.orgでプッシュツートークOMAのWebサイトでは携帯電話の仕様を超えるを出版
Person & email address to contact for further information: Miguel A. Garcia-Martin, miguel.an.garcia@nokia.com
人と詳細のために連絡する電子メールアドレス：ミゲルA.ガルシア・マーティン、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.
その他の情報：このメディアタイプは、アプリケーション/ XMLのRFC 3023の特殊化である[3]、及び考察の多くは、アプリケーション/ POC - 設定+ xmlのためにそこに適用します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2]堀、R.、 "URN構文"、RFC 2141、1997年5月を。
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[3]村田、M.、サンローラン、S.、およびD.コーン、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、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]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（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]ニエミ、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.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[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]パオリ、J.、Sperberg-マックィーン、C.、ブレイ、T.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第二版）"、W3C FirstEdition 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]キャマリロ、G.、およびA.ローチ、 "セッション開始プロトコル（SIP）の要件とフレームワークのURI（Uniform Resource Identifier） - リストサービス"、進歩、2005年4月に働いています。
[12] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, January 2006.
[12]ローゼンバーグ、J.、RFC 4353、2006年1月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
Author's Address
著者のアドレス
Miguel A. Garcia-Martin Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland
ミゲルA.ガルシア・マーチンノキアNOKIA GROUPのP.O.Box 407、FIN 00045フィンランド
EMail: miguel.an.garcia@nokia.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。