[要約] RFC 4354は、Push-to-Talk over Cellular（PoC）サービスのサポートのためのセッション開始プロトコル（SIP）イベントパッケージとデータ形式に関するものです。このRFCの目的は、異なる設定でのPoCサービスのサポートを可能にするための標準化と指針を提供することです。
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）イベントパッケージとデータフォーマットは、Cellular（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).
Copyright（c）The Internet Society（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.
Open Mobile Alliance（OMA）は、SIPがさまざまな参加者間でハーフダプレックスメディアセッションを確立するために使用されるプロトコル、インスタントメッセージなどを送信するために使用されるプロトコルであるCellular（POC）サービスを介してプッシュツートークを定義しています。このドキュメントはSIPを定義します。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.
Open Mobile Alliance（OMA）（http://www.openmobilealliance.org）は現在、Cellular（POC）サービスを推進することを指定しています。このサービスにより、SIPユーザーエージェント（POCターミナル）が1つ以上の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端子は、これらの動作モードの両方または1つのみをサポートする場合があります。ユーザーは、現在の状況と好みに基づいて頻繁に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ベースの通信サービスをサポートできます。ユーザーは、他の1つまたは複数の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端末は、着信するインスタントアラートを受け入れないように設定できます。これは、インスタントパーソナルアラートVarring（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セッションを同時に処理するためのサポートを提供する場合がありますが、他の端子は時間の1つのPOCセッションのみを処理できます。または、端末が複数のPOCセッションを同時に処理できたとしても、ユーザーは一度に1つのPOCセッションを1つだけ持ちたい場合があります。複数の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ネットワークサーバーで構成され、メディアパケットのバッファリングを実行するために、発信者に早期または未確認の適応症を提供し、呼び出し元の前に発信者が話し始めることができますPOCターミナルが答えました。この最適化は、呼び出されたPOC端末が現在POCセッションを受け入れており、その回答モードが自動回答に設定されている場合にのみ適切です。したがって、この最適化では、ネットワークSIPサーバーが現在のISBと呼び出されたPOC端子の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 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 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.
SIPイベント出版エージェント（EPA）が特定のEPAでユーザーの設定を公開できるSIPイベントパッケージを定義します。これにより、サブスクライバーはこのイベントパッケージにイベント状態コンポジタを購読することができ、この情報を収集し、セッションがそのユーザーに試行されたときにユーザーのニーズを予測できます。ここで定義されているSIPイベントパッケージは、一般的なインターネットには適用されないと考えられています。POCサービスのアーキテクチャを提供するように設計されています。特に、RFC 3903 [8]で定義されているコンテキストでは、POCターミナルをイベント出版エージェント（EPA）として動作させることはOMAの意図であり、ネットワークサーバーはイベント状態コンポジット（ESC）として動作します。POCターミナルとネットワークサーバーがユーザーのPOC関連設定にも購読する可能性があるため、1つの端末で作成されたこの状態の変更は、特定のユーザーのすべての異なる端末またはネットワークサーバーで同期して保持されます。
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がISB、AM、IPAB、およびSSS設定をESCに伝えることができるPOCセッティングドキュメントを定義します。EPAは、公開リクエスト[8]でPoc-Settingsドキュメントを送信します。Poc-Settingsドキュメントには、その特定のEPAでの設定ビューを表します。ESCは、異なるEPAで同じユーザーのPOCセッティングドキュメントを収集し、構成ポリシーを適用し、通知を提供できます。通知には、ESCが競合を解決できるかどうかに応じて、設定の構成ビューまたはEPAあたりの設定のリストを含めることができます。サブスクライバーは、RFC 3265 [5]で指定された手順に従って、このドキュメントの変更の通知を受信できます。このメモの目的は、RFC 3427 [6]に示されている手順に従い、IANAと新しいPoc-Settingsイベントパッケージを登録することです。
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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、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のオープンモバイルアライアンスのWebページにあります。
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-Settings」イベントパッケージを定義します。イベントの発行エージェント（EPA）は、公開リクエストを使用して、POC-Settingsイベントパッケージの変更をイベント状態コンポジター（ESC）に通知します。Notifierとして行動すると、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-Settings」です。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-Settings」は、追加のパラメーターを定義しません。
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-Settingsイベントパッケージへのサブスクリプションには、通常はボディが含まれません。
The Request-URI of the SUBSCRIBE request identifies the user about whose poc-settings the subscriber wants to be informed.
サブスクライブリクエストのリクエスト-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]によると、サブスクライバーは、ヘッダーフィールドの有効期限が切れることを指定する場合があります。
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メッセージには、購読されたリソースの状態を説明するボディが含まれます。この本体は、サブスクライブリクエストの承認ヘッダーフィールドにリストされている形式、またはサブスクライブリクエストから承認ヘッダーフィールドが省略された場合のパッケージ固有のデフォルト形式です。
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セッティングドキュメントを収集しました。ESCは構成ポリシーを適用し、異なるEPAにわたるこれらすべての設定の共通のビューを持つPOCセッティングドキュメントを構成します。2つの異なる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-Settings」イベントパッケージのすべてのサブスクライバーと通知者は、セクション6で説明した「アプリケーション/POCセティングXML」データ形式をサポートする必要があります。購読要求には、受け入れヘッダーフィールドが含まれる場合があります。そのようなヘッダーフィールドが存在しない場合、「アプリケーション/POCセティングXML」のデフォルト値があります（イベントヘッダーフィールドに「POC-Settings」の値が含まれていると仮定します）。受け入れヘッダーフィールドが存在する場合、「Application/POC-Settings 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-Settingsドキュメントの内容には、プライバシー情報を明らかにする可能性のある機密情報を含めることができます。したがって、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.
認証されると、Notifierは許可決定を下します。通知者は、ユーザーによって承認が提供されていない限り、サブスクリプションを受け入れてはなりません。許可が提供される手段は、このドキュメントの範囲外です。おそらく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]は、通知メッセージのフォーマットと構造を詳述しています。ただし、パッケージは、いつ通知を送信するか、リソースの状態をどのように計算するか、ニュートラルまたは偽の状態情報を生成する方法、および状態情報が完全か部分的かどうかに関する詳細な情報を提供することが義務付けられています。このセクションでは、Poc-Settingsイベントパッケージの詳細について説明します。
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セッティングステージが変更されたときに1つを送信します。Notifyリクエストには、POCセッティングドキュメントを含むボディが含まれている場合があります。Notifyが特定のサブスクライバーに送信される時間と、その通知内の身体の内容は、サブスクリプションを支配する承認ポリシーによって指定された規則の対象となります。ただし、通常、Notifyには、変更が発生した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.
Notifyの本文は、最新のサブスクライブリクエストのAccept Headerフィールドにリストされているタイプの1つを使用して、または受け入れヘッダーフィールドが存在しない場合は「アプリケーション/POCセティング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-Settings Event Stateを学習します。Notifierが、出版物が行われていないユーザーの通知要求を生成する可能性があります。その場合、POC-Settingsドキュメントには<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]を使用して認証とメッセージの整合性を提供する場合があります。Notifyは、Poc-Settingsユーザーが表すユーザーのキーにアクセスできないNotifierによって生成されるため、多くの場合、Notifyはサードパーティによって署名されます。Notifyリクエストは、ユーザーのドメインに関する当局によって署名される必要があります。言い換えれば、SIP URIがsip：user@example.comであるユーザーの場合、Notifyの署名者は、たとえば.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セッティングドキュメントがないか、特定のユーザーの1つ以上のPOC関連設定を表すドキュメントが含まれています。ダイアログ内では、CSEQヘッダー値が最も高いNotifyリクエストのPOCセッティングドキュメントは現在のものです。そのNotifyにドキュメントが存在しない場合、次に最高のCSEQ値を持つNotifyに存在する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.
この仕様では、初期サブスクライブリクエストを放出した結果として、単一のダイアログのみを構築できます。これにより、特定のユーザーへの特定のサブスクリプションの通知を生成している1人のサブスクライバーのみが保証されます。この結果、ユーザーは複数の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-Settings Notifiersは、5秒ごとに1回以上のレートで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-Settingsドキュメントの公開は、ユーザーにリンクされています。ただし、ユーザーは異なるPOC端子で同時にログインする場合があります。ユーザーが端末からPOC設定を変更すると、POCセッティングドキュメントを含む公開リクエストが送信されます。これらの設定は、ログインしている端末とは独立してユーザーに適用できます。つまり、端末で行われたPOC設定の変更は、ユーザーがログに記録されているすべてのPOC端子に影響します。ユーザーがログインしている各端末は、州のエージェントとの一貫した状態ビューを維持するために、独自のpoc-settingsドキュメントに登録することをお勧めします。
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-Settingsドキュメントはかなり小さいです。このイベントパッケージは、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セッティングドキュメントに独自の情報を含める必要があります。つまり、公開要求の本文に単一の<Entity>要素があるはずです（<Entity>要素の詳細な説明については、セクション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.
この仕様は、パブリッシュレスポンスでセマンティクスを身体に関連付けるものではありません。
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]は、状態文書内のセグメントを定義します。各セグメントは、公開されているイベント状態で潜在的に多く識別可能なセクションの1つとして定義されます。
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-settings>、<am-settings>、<ipab-settings>、<sss-settings>、<ssss-settings>によって識別される4つのセグメントを定義します。それらのそれぞれは、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-Settingsの出版物については、料金制限の推奨事項はありません。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-settingsはXMLドキュメント[10]であり、適切に形成されている必要があり、有効である必要があります。poc-settingsドキュメントはXML 1.0に基づいている必要があり、UTF-8 [7]を使用してエンコードする必要があります。この仕様では、POCセッティングドキュメントを識別するためにXML名空間を使用します。この仕様で定義された要素の名前空間URIは、名前空間識別子「OMA」を使用してurn [2]です。このurnは次のとおりです。
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-settingsドキュメントは、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-settingsドキュメントは、ルート要素タグ<poc-settings>で始まります。これは、EPAを表す特定のレコードアドレスのグローバルに一意の識別子を含む「ID」属性を含むゼロまたはそれ以上の要素で構成されています。<Entity>要素はEPAを表し、「ID」属性によって一意に識別されます。EPAは、POCセッティングドキュメントに単一の<Entity>要素を含める必要があります。ESCには、通常、ESCが異なるソースからの矛盾した出版により競合を解決できない場合、POCセティングドキュメントにいくつかの<Entity>要素が含まれる場合があります。
A valid PoC-settings document can include zero <entity> elements if the ESC provides a notification for which no publication has occurred.
有効なPOCセティングドキュメントには、ESCが出版物が発生していない通知を提供する場合、ゼロ<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 from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
<Entity>要素は、ゼロまたは1つの<isb-settings>要素、ゼロまたは1つの<am-settings>要素、ゼロまたは1つの<ipab-settings>、およびゼロまたは1 <sss-settings>要素で構成されています。拡張性の目的のために、異なる名前空間からの他の要素と属性が存在する場合があります。不明な名前空間からの要素または属性は無視する必要があります。
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>要素には、ブール値の「アクティブ」属性を含む単一の<coming-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-settings>要素には、<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]などのサーバーは、1人以上の受信者にアドレス指定されたSIPリクエストを受信します。意図した受信者が<Answer-Mode>を「マニュアル」に設定した場合、URI-Listサーバーはセッションの試行に進みます。彼女がそれを「自動」に設定すると、URI-Listサーバーは、意図した受信者に連絡する前に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-settings>要素には、ブールの「アクティブ」属性を含む単一の<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.
<ssss-settings>要素には、ブールの「アクティブ」属性を含む単一の<同時セッションサポート>要素が含まれています。「アクティブ」属性は、SIP UAが複数のPOCセッションを同時に処理する意思があるかどうかを示します。「アクティブ」属性が「false」または「0」に設定されている場合、SIP UAがPOCセッションに従事し、SIP UAがSIP POCセッションの2番目の着信要求を受け取る場合、UAは招待を拒否します。「アクティブ」属性が「True」または「1」に設定されている場合、SIP UAがPOCセッションに従事し、SIP UAがSIP POCセッションの2番目の着信要求を受け取る場合、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">
<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: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: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="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="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>
The following is an example of a PoC-settings document:
以下は、POCセッティングドキュメントの例です。
<?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>
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-Settings」イベントパッケージは、SIPパブリックリクエストで輸送されることを意図しています。したがって、RFC 3903 [8]のセキュリティ上の考慮事項（セクション14）がこのドキュメントに適用されます。特に、「Poc-Settings」イベントパッケージに含まれる設定は、SIPパブリッシュリクエストを生成したユーザーに適用できます。したがって、「Poc-Settings」イベントパッケージを含む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-Settingsドキュメントの不正な受信者は、出版社の端末が自動回答モードでPOCセッションに回答するように設定されていることを知ることができ、UASが自動的に再生される不適切なメディアを含む悪意のあるセッションを作成することができます。または、攻撃者は、ターミナルが同時にPOCセッションを受け取ることをいとわないことを知ることができ、その後、攻撃されたSIP UAにHung Statesを残す偽の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でも説明します。NotifierがNotify Requestsのボディを暗号化しない場合、盗聴者はSIPユーザーエージェントのステータスを学習し、それを使用して悪意のあるPOCセッションを作成できます。通知者が誠実さがnotifyリクエストの機関を保護しない場合、中間の攻撃者または悪意のあるSIPプロキシは、Poc-Settingsイベントパッケージ通知の内容を変更できます。これは害を引き起こすことはありませんが、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: Package Name: poc-settings
この仕様は、RFC 3265 [5]で定義されている登録手順に基づいて、イベントパッケージを登録します。以下は、そのような登録に必要な情報です：パッケージ名：poc-settings
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-settings xml
Required parameters: (none)
必要なパラメーター：（なし）
Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8 [7].
オプションのパラメーター：charset;囲まれた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.
このメディアタイプを使用するアプリケーション：Open Mobile Alliance（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 Person & email address to contact for further information: Miguel A. Garcia-Martin, miguel.an.garcia@nokia.com
追加情報：Open Mobile Allianceは、http://www.openmobilealliance.orgの人と電子メールアドレスのOMA Webサイトの携帯電話の仕様に対するプッシュツートークを公開しています。.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.
著者/変更コントローラー：Open Mobile Alliance（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats、R。、「urn構文」、RFC 2141、1997年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 Media Types」、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：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach、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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC 3427、12月2002年。
[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。、「Secure/Multipurpose Internet Mail拡張機能（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（第2版）」、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] 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
ミゲルA.ガルシアマルティンノキアP.O.Box 407 Nokia Group、Fin 00045 Finland
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。