RFC4354 日本語訳
4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular(PoC) Service. M. Garcia-Martin. January 2006. (Format: TXT=46847 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Garcia-Martin Request for Comments: 4354 Nokia Category: Informational January 2006
コメントを求めるワーキンググループM.ガルシア-マーチンの要求をネットワークでつないでください: 4354年のノキアカテゴリ: 情報の2006年1月
A Session Initiation Protocol (SIP) Event Package and Data Format
for Various Settings in Support
for the Push-to-Talk over Cellular (PoC) Service
セル(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)インターネット協会(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.
オープンのモバイルAlliance(OMA)はSIPがインスタントメッセージなどを送るためには異なった関係者の向こう側に半二重メディアセッションを証明するのに使用されるプロトコルであるところでCellular(PoC)サービスの上のPushから話を定義することです。 このドキュメントは、PoCサービスで必要である追加能力の公表、購読、および通知をサポートするためにSIPイベントパッケージを定義します。 このSIPイベントパッケージは、PoCサービスに適切であり、一般的なインターネットに適切でないかもしれません。
Garcia-Martin Informational [Page 1] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[1ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Applicability Statement .........................................5
4. Requirements ....................................................5
5. The "poc-settings" Event Package ................................6
5.1. Package Name ...............................................6
5.2. Event Package Parameters ...................................7
5.3. SUBSCRIBE Bodies ...........................................7
5.4. Subscription Duration ......................................7
5.5. NOTIFY Bodies ..............................................7
5.6. Notifier Processing of SUBSCRIBE Requests ..................8
5.6.1. Authentication ......................................8
5.6.2. Authorization .......................................8
5.7. Notifier Generation of NOTIFY Requests .....................8
5.8. Subscriber Processing of NOTIFY Requests ...................9
5.9. Handling of Forked Requests ...............................10
5.10. Rate of Notifications ....................................10
5.11. State Agents .............................................10
5.12. Examples .................................................10
5.13. Use of URIs to Retrieve State ............................10
5.14. PUBLISH Bodies ...........................................11
5.15. PUBLISH Response Bodies ..................................11
5.16. Multiple Sources for Event State .........................11
5.17. Event State Segmentation .................................11
5.18. Rate of Publication ......................................12
6. PoC-Settings Document ..........................................12
6.1. XML Schema ................................................14
6.2. Example ...................................................16
7. Security Considerations ........................................17
8. Acknowledgements ...............................................17
9. IANA Considerations ............................................17
9.1. Registration of the "poc-settings" Event Package ..........17
9.2. Registration of the "application/poc-settings+xml"
MIME type .................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
1. 序論…3 2. 用語…5 3. 適用性声明…5 4. 要件…5 5. 「poc-設定」イベントパッケージ…6 5.1. 名前をパッケージしてください…6 5.2. イベントパッケージパラメタ…7 5.3. ボディーを申し込んでください…7 5.4. 購読持続時間…7 5.5. ボディーに通知してください…7 5.6. より多くのNotifierに処理する、要求を申し込んでください…8 5.6.1. 認証…8 5.6.2. 承認…8 5.7. Notifier世代、要求に通知してください…8 5.8. 加入者、処理する、要求に通知してください…9 5.9. 股状の要求の取り扱い…10 5.10. 通知の速度…10 5.11. エージェントを述べてください…10 5.12. 例…10 5.13. 状態を検索するURIの使用…10 5.14. ボディーを発行してください…11 5.15. 応答本体を発行してください…11 5.16. イベント状態への複数のソース…11 5.17. イベント州の分割…11 5.18. 公表のレート…12 6. PoC-設定ドキュメント…12 6.1. XML図式…14 6.2. 例…16 7. セキュリティ問題…17 8. 承認…17 9. IANA問題…17 9.1. 「poc-設定」イベントパッケージの登録…17 9.2. 「アプリケーション/poc-設定+xml」MIMEの種類の登録…18 10. 参照…19 10.1. 標準の参照…19 10.2. 有益な参照…20
Garcia-Martin Informational [Page 2] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[2ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
1. Introduction
1. 序論
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.
オープンのモバイルAlliance(OMA)( http://www.openmobilealliance.org )は現在、Cellular(PoC)サービスの上のPushから話を指定しています。 このサービスは開始しているユーザがボタンを押すとき、同時に1人以上のSIP Userエージェント(UAs)にセッションを証明するためには(PoC端末)の、そして、通常、開始しているSIP Userエージェントを許容します。
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端末を構成する能力を提供して、呼ばれたユーザの介入を必要としないでそれを受け取るとすぐに、メディアを展開するスピーカーフォーン、そして/または、ヘッドホンやソフトウェアなどの能力であるとサポートするかもしれません。 この運転モードはAuto-アンサーモードか自動モードとして知られています。 あるいはまた、ユーザは、最初に、ユーザを警告して、ユーザが手動でメディアの前にセッション招待に応じるのが必要であるPoC端末が受け入れられるのを構成するかもしれません。 この運転モードはManual-アンサーモードとして知られています。 PoC端末は両方かこれらの運転モードの1つだけをサポートするかもしれません。 ユーザは頻繁に彼らの現在の事情と好みに基づくPoC端末のAnswer Mode(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端末はPushから話(例えば、VoIP電話、存在サービス、メッセージングサービスなど)に加えた様々なSIPベースの通信サービスをサポートすることができます。 まだ残っているSIPが他の1つ以上のSIPベースのサービスに登録していた間、ユーザは時には、Pushから話へのセッションの承認を無効にしたがっているかもしれません。 PoC端末が話へのどんな入って来るPushセッションにも受け入れないように構成されるとき、これはIncoming Session Barring(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).
Incoming Session Barringが有効にされている状態で、ユーザはPoC端末を持っている別のユーザに連絡したがっているかもしれません。 ユーザは、彼がPoC Sessionに彼に従事したがっていることを彼に知らせるためにInstantパーソナルAlertを別のユーザに送るかもしれません。 目的地PoC端末がIncoming Session Barringを有効にしたとき、このInstantパーソナルAlertを受け取りさえします。 ユーザがInstantパーソナルAlertsの承認を無効にしたいなら、彼は、彼のPoC端末が少しの入って来るInstantパーソナルAlertsも受け入れないのを構成できます。 これはInstantパーソナルAlert Barring(IPAB)として知られています。
Garcia-Martin Informational [Page 3] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[3ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
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セッションを過すことを望むかもしれません。 複数のPoCセッションのサポートのこのしるしは同時に、Simultaneous PoCセッションズSupport(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 Architectureは会議焦点[12]、RTP翻訳者、または方針サーバなどの役割を実行するかもしれないネットワークの中でSIPサーバを利用します。話すために指示を訪問者に提供する遅れを最小にする可能な最適化は、早いか未確認の指示を訪問者に提供して、呼ばれたPoC端末の前の話しが答えた始めに訪問者を許容するためにメディア向けの資料セットのバッファリングを実行するためにSIPネットワークサーバから成ります。 呼ばれたPoC端末が現在、PoCセッションを受け入れていて、Answer ModeがAuto-答えに用意ができているとき、この最適化だけが適切です。 したがって、この最適化は、ネットワーク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.
同様に、ラジオインタフェースの向こう側にInstantパーソナルAlertsの不要なトランスミッションを避けるために、ネットワーク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
私たちはSIP Event Publicationエージェント(EPA)がいくつかの特定のセッション試みに影響を与えるかもしれないその特定のEPAにおけるユーザの設定を発行できるSIPイベントパッケージを定義します。 セッションがそのユーザに試みられるとき、これはこの情報を集めるこのイベントパッケージへのEvent州Compositorに申し込んで、ユーザの必要なことに予期する加入者を許容します。 ここで定義されたSIPイベントパッケージが一般的なインターネットに適切でないと信じられています: それは、PoCサービスのアーキテクチャに役立つように設計されています。 特定、そして、およびRFC3903[8]によって定義された文脈では、それはOMAがPoC端末をEvent Publicationエージェント(EPA)として振る舞わせるという意志です、そして、ネットワークサーバはEvent州として振る舞います。
Garcia-Martin Informational [Page 4] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[4ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
Compositors (ESC). It is possible that PoC terminals and network servers may also subscribe to the user's PoC related settings, so that changes in this state made in one terminal are kept in synchronization across all different terminals or with the network server for a particular user.
植字工(ESC)。 また、PoC端末とネットワークサーバがユーザのPoCの関連する設定に加入するのは、可能です、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はPUBLISH要求[8]でPoC-設定ドキュメントを送ります。 ドキュメントが含むPoC-設定はその特定のEPAに設定視点を表します。 ESCは同じユーザのために異なったEPAにPoC-設定ドキュメントを集めて、構成方針を適用して、通知を提供できます。 通知は設定の落ち着いた視点か1EPAあたりの設定のリストを含むことができます、ESCが闘争を解決できるかどうかによって。 本書ではRFC3265[5]で指定された手順に応じて、加入者は変化の通知を受け取ることができます。 このメモの目的は、RFC3427[6]で示された手順に従って、新しいpoc-設定イベントパッケージをIANAに登録することです。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Applicability Statement
3. 適用性証明
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.
本書では定義されたイベントパッケージは使用のためにCellularサービスの上にPushから話を提供するネットワークベースのアプリケーション・サーバーで意図します。
4. Requirements
4. 要件
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 のオープンモバイルAllianceウェブページでオープンのモバイルAllianceによって開発されたCellularサービスの上でPushから話に影響するすべての要件の包括的な記述を見つけることができます。
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:
簡単にするために、私たちはここで簡潔に本書では説明されたソリューションに影響するそれらの要件について議論します。 以下の通りこれらの要件をまとめることができます:
Garcia-Martin Informational [Page 5] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[5ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
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要求を目的地に向かって断つか、またはフィルターにかけさえして。 これはセッション準備時間を短縮するという目標に近づきます。
5. The "poc-settings" Event Package
5. 「poc-設定」イベントパッケージ
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].
RFC3265[5]はそれらの州に遠隔ノードを購読して、変化の通知(イベント)を受け取るためのSIP拡張子を定義します。 それはこれらのイベントの多くの局面の定義をイベントパッケージとして知られている具体的な拡大に残します。 このドキュメントはイベントパッケージの資格を得ます。 このセクションはすべてのイベントパッケージのためにRFC3265[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.
さらに、RFC3903[8]はSIP Userエージェントがイベント状態を発行できる拡大を定義します。 RFC3903[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-設定」イベントパッケージを定義します。 イベントPublicationエージェント(EPA)はpoc-設定イベントパッケージにおける変化についてEvent州Compositor(ESC)に知らせるというPUBLISH要求を使用します。 notifierとして機能して、ESCは変化がいつ起こるかというユーザのpoc-設定情報に加入者に通知します。
5.1. Package Name
5.1. パッケージ名
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-設定」です。 この値がRFC3265[5]で指定されるようにEventヘッダー分野で存在しているように見える、登録、そして、NOTIFY要求。 また、RFC3903[8]で指定されるように、この値はPUBLISH要求の現在のEventヘッダーフィールドで見えます。
Garcia-Martin Informational [Page 6] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[6ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
5.2. Event Package Parameters
5.2. イベントパッケージパラメタ
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.
RFC3265[5]で、イベントパッケージはEventヘッダーフィールドで運ばれた追加パラメタを定義できます。 「poc-設定」というこのイベントパッケージは追加パラメタを定義しません。
5.3. SUBSCRIBE Bodies
5.3. ボディーを申し込んでください。
According to RFC 3265 [5], a SUBSCRIBE request can contain a body. The purpose of the body depends on its type. Subscriptions to the poc-settings event package will normally not contain bodies.
RFCによると、3265はボディーを含むことができます登録が、[5]、要求する。 ボディーの目的はタイプに頼っています。 通常、poc-設定イベントパッケージの購読はボディーを含まないでしょう。
The Request-URI of the SUBSCRIBE request identifies the user about whose poc-settings the subscriber wants to be informed.
Request-URI、登録、加入者がだれのpoc-設定が知識があるようになりたがっているかに関してユーザが特定するよう要求してください。
5.4. Subscription Duration
5.4. 購読持続時間
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秒です。 RFC3265[5]に従って、加入者はExpiresヘッダーフィールドにおける代替の満了を指定するかもしれません。
5.5. NOTIFY Bodies
5.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.
RFC3265[5]で説明されるように、NOTIFYメッセージは申し込まれたリソースの状態について説明するボディーを含むでしょう。 このボディーが形式がAcceptヘッダーフィールドで記載したコネである、登録、要求、またはデフォルトがヘッダーフィールドが省略された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はユーザのために異なったEPAにPoC設定ドキュメントを集めました。 ESCは異なったEPAの向こう側にこれらのすべての設定の共通認識で構成方針を適用して、PoC-設定ドキュメントを構成します。 相容れない情報への支払われるべきものは、2時までにESCが対立を解消できないといけないので、ESCが加入者が対立を解決できるように各端末に設定を保管しているPoC-設定ドキュメントを提供するのを異なったEPAを前提としました。
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-設定」イベントパッケージのすべての加入者とnotifiersはセクション6で説明された「アプリケーション/poc-設定+xml」データの形式をサポートしなければなりません。 登録、要求はそうするかもしれません。Acceptヘッダーフィールドを含んでください。 そのような何かヘッダーフィールドが存在していないなら、それには、「アプリケーション/poc-設定+xml」のデフォルト値があります(Eventヘッダーフィールドが「poc-設定」の値を含むと仮定して)。 Acceptヘッダーフィールドが存在しているなら、それは、「アプリケーション/poc-設定+xml」を含まなければならなくて、PoCのためにユーザー設定を表すことができるいかなる他のタイプも含むかもしれません。
Garcia-Martin Informational [Page 7] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[7ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
5.6. Notifier Processing of SUBSCRIBE Requests
5.6. より多くのNotifierに処理する、要求を申し込んでください。
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で説明されるように加入者であるのに彼に権限を与えなければなりません。
5.6.1. Authentication
5.6.1. 認証
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.
Notifiersはすべての購読要求を認証しなければなりません。 この認証はRFC3261[4]と他の認証拡大で定義されたメカニズムのどれかを使用し終わることができます。
5.6.2. Authorization
5.6.2. 承認
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は承認決定をします。 承認がユーザによって提供されていない場合、notifierは申し込みに応じてはいけません。 このドキュメントの範囲の外に承認がどれであるかによって提供された手段があります。 早めに、恐らくウェブページで指定されたアクセスリストを通して承認を提供したかもしれません。 アップロードある種の標準化されたアクセスコントロールリストドキュメントによって承認を提供したかもしれません。
5.7. Notifier Generation of NOTIFY Requests
5.7. Notifier世代、要求に通知してください。
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.
RFC3265[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.
notifierはいつでも、NOTIFYを送るかもしれません。 ユーザの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
未定の購読の場合では、確定授権が決定しているとき、NOTIFYを送ることができます。 承認決定の結果が成功、NOTIFY SHOULDであった、送られてください。そうすれば、SHOULDはaを含んでいます。
Garcia-Martin Informational [Page 8] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[8ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
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-設定ドキュメントを完成してください。 購読が拒絶されたa NOTIFY MAYであるなら、送ってください。 RFC3265[5]で説明されるように、Subscription-州のヘッダーフィールドは購読の状態を示します。
The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/poc-settings+xml" if no Accept header field was present.
ボディー、どんなAcceptヘッダーフィールドも存在していなかったならタイプの送られた使用ひとりが、最新のAcceptヘッダーフィールドで登録とタイプ「+ pocアプリケーション/設定xml」を要求するか、または使用することで記載したというNOTIFY MUSTでは、ことになってください。
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).
NotifiersはEvent州Compositors(ESC)として通常機能して、その結果、ユーザがそれらの設定の1つを変えるときユーザのEvent Publicationエージェント(EPA)から送られたPUBLISH要求でpoc-設定イベント状態を学ぶでしょう。 notifierが公表が全く行われていないユーザを求める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]を使用することでこれを達成できます。 From分野で特定されるように加入者のキーを使用することで暗号化を実行できる、登録、要求。 同様に、加入者には、通知の保全は重要です。 そういうものとして、S/MIME[9]を使用して、通知のコンテンツは認証とメッセージの保全を提供するかもしれません。 NOTIFYがnotifier(poc-設定ユーザによって代理をされたユーザのキーに近づく手段を持っていないかもしれない)によって生成されるので、しばしば、NOTIFYは第三者によって署名されるでしょう。 NOTIFYは、SHOULDがユーザのドメインの上の権威によって署名されるよう要求します。 言い換えれば、SIP URIが一口: user@example.com 、NOTIFY SHOULDのsignatorであるユーザにとっての、権威for example.comになってください。
5.8. Subscriber Processing of NOTIFY Requests
5.8. 加入者、処理する、要求に通知してください。
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.
RFC3265[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.
この仕様では、それぞれのNOTIFY要求はどんなPoC設定ドキュメントも与えられたユーザのために1つ以上のPoCの関連する設定を表さないドキュメントのどちらかも含んでいます。 対話の中では、最も高いCSeqヘッダーフィールド価値があるNOTIFY要求におけるPoC-設定ドキュメントは現在のものです。 どんなドキュメントもそのNOTIFYに存在していないとき、NOTIFYの次の最も高いCSeq値の現在のPoC-設定ドキュメントは使用されています。
Garcia-Martin Informational [Page 9] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[9ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
5.9. Handling of Forked Requests
5.9. 股状の要求の取り扱い
RFC 3265 [5] requires each package to describe handling of forked SUBSCRIBE requests.
[5]が、各パッケージが取り扱いについて説明するのを必要とするRFC3265が分岐した、登録、要求。
This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single subscriber is generating notifications for a particular subscription to a particular user. The result of this is that a user can have multiple SIP User Agents active, but these should be homogeneous, so that each can generate the same set of notifications for the user's poc-settings.
この仕様が、イニシャルを放つことの結果、ただ一つの対話が構成されるのを許容するだけである、登録、要求。 これは、独身の加入者だけが特定のユーザの特定の購読のための通知を生成しているのを保証します。 この結果はユーザが複数のSIP Userエージェントをアクティブにすることができますが、これらが均質であるべきであるということです、それぞれがユーザのpoc-設定のための同じセットの通知を生成することができるように。
5.10. Rate of Notifications
5.10. 通知の速度
RFC 3265 [5] requires each package to specify the maximum rate at which notifications can be sent.
RFC3265[5]は、通知を送ることができる最高率を指定するために各パッケージを必要とします。
Poc-settings notifiers SHOULD NOT generate notifications for a single user at a rate of more than once every five seconds.
Poc-設定notifiers SHOULDはシングルユーザーのために5秒あたりの一度以上のレートで通知を生成しません。
5.11. State Agents
5.11. 州のエージェント
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.
RFC3265[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-設定ドキュメントを購読するのは、RECOMMENDEDです。
5.12. Examples
5.12. 例
An example of a PoC-setting document is provided in Section 6.2.
PoCを設定しているドキュメントに関する例をセクション6.2に提供します。
5.13. Use of URIs to Retrieve State
5.13. 状態を検索するURIの使用
RFC 3265 [5] allows packages to use URIs to retrieve large state documents.
RFC3265[5]で、パッケージは、大きい州政府出版物を検索するのにURIを使用できます。
Garcia-Martin Informational [Page 10] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[10ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
PoC-settings documents are fairly small. This event package does not provide a mechanism to use URIs to retrieve large state documents.
PoC-設定ドキュメントはかなり小さいです。 このイベントパッケージは、大きい州政府出版物を検索するのにURIを使用するためにメカニズムを提供しません。
5.14. PUBLISH Bodies
5.14. ボディーを発行してください。
RFC 3903 [8] requires event packages to define the content types expected in PUBLISH requests.
RFC3903[8]は、PUBLISH要求で予想されたcontent typeを定義するためにイベントパッケージを必要とします。
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 SHOULDはPoC-設定ドキュメントにそれら自身の情報を含んでいます。 すなわち、そこ、SHOULD、PUBLISH要求のボディーのただ一つの<実体>要素(<実体>要素の詳述に関してセクション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とESCsはセクション6で説明された「アプリケーション/poc-設定+xml」データの形式をサポートしなければならなくて、他の形式をサポートするかもしれません。
5.15. PUBLISH Response Bodies
5.15. 応答本体を発行してください。
This specification does not associate semantics to a body in a PUBLISH response.
この仕様はPUBLISH応答で意味論をボディーに関連づけません。
5.16. Multiple Sources for Event State
5.16. イベント状態への複数のソース
RFC 3903 [8] requires event packages to specify whether multiple sources can contribute to the event state view at the ESC.
RFC3903[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は<実体>要素で分類されたそれ自身の設定を発行します。 EPAは与えられた記録されている住所のためのグローバルにユニークな識別子を提供します。 これで、ESCはEPAを差別化して、闘争を解決する州を構成するか、またはそれに貢献したすべてのEPA州の組合を提供します。 このドキュメントの範囲の外にESCの構成方針があります。
5.17. Event State Segmentation
5.17. イベント州の分割
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.
RFC3903[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-設定>によって特定された4つのセグメントを定義して、<による-設定の>、<のipab設定>、および<がsssされるということである、-、それぞれ設定>。 それぞれの彼らはEPAの異なった州について言及します。
Garcia-Martin Informational [Page 11] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[11ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
5.18. Rate of Publication
5.18. 公表のレート
RFC 3903 [8] allows event packages to define their own rate of publication.
RFC3903[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-設定ドキュメントにおける変化が人間のユーザとの相互作用によって通常引き起こされるので、周期性、および公表の最小の、または、最大のレートがありません。
6. PoC-Settings Document
6. 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]とSHOULDです。有効であってください。 PoC-設定ドキュメントをXML1.0に基礎づけなければならなくて、UTF-8[7]を使用して、コード化しなければなりません。 この仕様は、PoC-設定ドキュメントを特定するのにXML名前空間を利用します。 'oma'という名前空間識別子を使用して、この仕様で定義された要素のための名前空間URIはURN[2]です。 このURNは以下の通りです。
urn:oma:params:xml:ns:poc:poc-settings
つぼ:oma:params: xml:ナノ秒:poc: poc設定
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を代表する記録の与えられたアドレスのためのグローバルにユニークな識別子を含む'イド'属性を含むそれぞれ)から成ります。 <実体>要素はEPAを代表します、そして、それは'イド'属性によって唯一特定されます。 EPA SHOULDはPoC-設定ドキュメントにただ一つの<実体>要素を含んでいます。 ESCsはPoC-設定ドキュメントの数個の<実体>要素を含めるかもしれなくて、いつ通常、ESCであることができないかは合同でない公表のためさまざまな原因から決心と闘争します。
A valid PoC-settings document can include zero <entity> elements
if the ESC provides a notification for which no publication has
occurred.
ESCが公表が全く現れていない通知を提供するなら、有効なPoC-設定ドキュメントは<実体>要素を全く含むことができません。
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
<実体>要素がゼロから成るか、1つの<のisb設定>要素、ゼロまたはある<による-設定>要素かゼロかある<のipab設定>と、ゼロかある<がsssされるということである、-、設定>要素。 他の要素と属性
Garcia-Martin Informational [Page 12] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[12ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
異なるのから、名前空間は伸展性の目的のために存在しているかもしれません。 未知の名前空間からの要素か属性を無視しなければなりません。
An <isb-settings> element contains a single <incoming-session- barring> element that contains a boolean 'active' attribute. The 'active' attribute indicates whether incoming sessions are barred at the UA, depending on the user's preferences for this setting. Other elements and attributes from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
>要素が論理演算子の'アクティブな'属性を含むただ一つの<入って来るセッションを禁じる>要素に含む<isb-設定。 'アクティブな'属性は、この設定のためにユーザの好みによって、入って来るセッションが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.
<による-設定>要素が<アンサーモード>要素を含んでいるということです。(「自動である」か「手動」に要素の値を設定できます)。 異なった名前空間からの他の要素と属性は伸展性の目的のために存在しているかもしれません。 未知の名前空間からの要素か属性を無視しなければなりません。
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要求を受け取ります。 意図している受取人が「マニュアル」に<アンサーモード>を設定したなら、セッション試みがある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が、同時に1つ以上のPoCセッションを扱っても構わないと思っているかどうかを示します。 'アクティブな'属性が「誤っていること」に設定されると、「そして、一口UaがPoCセッションに従事して、一口Uaが一口PoCセッションを求める2番目の入って来る要求を受け取るとき、何0インチも、Uaは招待を断つでしょう」。 'アクティブな'属性が「本当に」設定されると、「そして、一口UaがPoCセッションに従事して、一口Uaが一口PoCセッションを求める2番目の入って来る要求を受け取るとき、何1インチも、Uaはことによると招待に応じるでしょう」。 異なった名前空間からの他の要素と属性は伸展性の目的のために存在しているかもしれません。 未知の名前空間からの要素か属性を無視しなければなりません。
Garcia-Martin Informational [Page 13] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[13ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
6.1. XML Schema
6.1. XML図式
Implementations according to this specification MUST comply to the following XML Schema, which defines the constraints of the PoC- settings document:
この仕様に従った実装は以下のXML Schemaに応じなければなりません:(XML SchemaはPoC設定ドキュメントの規制を定義します)。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oma:params:xml:ns:poc:poc-settings"
xmlns="urn:oma:params:xml:ns:poc:poc-settings"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><xs: 図式targetNamespace=「つぼ:oma:params: xml:ナノ秒:poc: poc設定」xmlnsは「つぼ:oma:params: xml:ナノ秒:poc: poc設定」xmlnsと等しいです: " http://www.w3.org/2001/XMLSchema "xs=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がxml: " http://www.w3.org/2001/xml.xsd "/><xs: 注釈><xs: ドキュメンテーションlang=と等しい、「アン「Cellular(PoC)サービスの上のPushから話におけるIncoming Session Barringを支持した>XML Schema Definition、Answer Mode、IncomingパーソナルAlert Barring、およびSimultaneousセッションズSupport。」 </xs: ドキュメンテーション></xs: 注釈>。
<xs:element name="poc-settings" type="poc-settingsType"/>
<xs: 要素名前=「poc-設定」は="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名=「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: 要素名=」をタイプする、午前、-、設定、」 タイプ="amSettingType"minOccursは「0インチ/>の<は以下をxsすること」と等しいです; 「「0インチ/>の<xs: 要素名前=「sss-設定」タイプ="sssSettingType"minOccurs=「0インチ/>の<xs: どんな名前空間=も」##他」の要素名前=「ipab-設定」タイプ="ipabSettingType"minOccurs=processContents=「手緩い」minOccurs=「0インチのmaxOccurs=」限りない」/>。
Garcia-Martin Informational [Page 14] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[14ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
「手緩い」/></xs: 「</xs: 系列><xs: 属性名前=「イド」タイプは「必要」/><使用=xs: 「xs: ストリング」anyAttribute名前空間=と等しく」##complexType」 いずれもprocessContents=>。
<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の名義の=「「><xs: complexType><はxsされます: 名前=を結果と考えてください」というisbSettingType「><xs: ><xs: 要素名=を配列してください」という入って来るセッションの禁じる能動態」タイプ=「xs: 論理演算子」/></xs:; 「手緩い」/></xs: 「complexType></xs: 要素><xs: どんな名前空間=も」##complexType」 どんな「手緩い」」 processContents=minOccurs=「0インチのmaxOccurs=」限りない」 」 /></xs: 系列><xs: anyAttribute名前空間=##いずれもprocessContentsも=>。
<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: 系列><xs: 要素名は」 アンサーモードと等しいです。<xs: complexTypeが=を命名する、「amSettingType、「「><xs: simpleType><xs: 制限ベース=「xs: 自動で「><xs: 列挙値=」を結んでください」という/><xs: 列挙値は「マニュアル」/></xsと等しいです」; 「手緩い」/></xs: 「制限></xs: simpleType></xs: 要素><xs: どんな名前空間=も」##complexType」 どんな「手緩い」」 processContents=minOccurs=「0インチのmaxOccurs=」限りない」 」 /></xs: 系列><xs: anyAttribute名前空間=##いずれもprocessContentsも=>。
<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の名義の=「「><xs: complexType><はxsされます: 名前=を結果と考えてください」というipabSettingType「><xs: ><xs: 要素名=を配列してください」という入って来る個人的な注意深い禁じる能動態」タイプ=「xs: 論理演算子」/></xs:; 「手緩い」/></xs: 「complexType></xs: 要素><xs: どんな名前空間=も」##complexType」 どんな「手緩い」」 processContents=minOccurs=「0インチのmaxOccurs=」限りない」 」 /></xs: 系列><xs: anyAttribute名前空間=##いずれもprocessContentsも=>。
Garcia-Martin Informational [Page 15] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[15ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
<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の名義の=「「><xs: complexType><はxsされます: 名前=を結果と考えてください」というsssSettingType「><xs: ><xs: 要素名=を配列してください」という同時のセッションサポート能動態」タイプ=「xs: 論理演算子」/></xs:; 「手緩い」/></xs: 「complexType></xs: 要素><xs: どんな名前空間=も」##complexType」 どんな「手緩い」」 processContents=minOccurs=「0インチのmaxOccurs=」限りない」 」 /></xs: 系列><xs: anyAttribute名前空間=##いずれもprocessContentsも=>。
</xs:schema>
</xs: 図式>。
6.2. Example
6.2. 例
The following is an example of a PoC-settings document:
↓これはPoC-設定ドキュメントに関する例です:
<?xml version="1.0" encoding="UTF-8"?>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>。
<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が等しい、「つぼ:oma:params: xml:ナノ秒:poc: poc設定、「><実体イド=、「do39s8zksn2d98x「>の<のisb設定><の入って来るセッションの禁じるアクティブな=」、本当に、」 />isb</設定><がそうである、-、設定>の<のアンサーモードの>の自動</アンサーモード>、」; </による-設定>ipab設定><の入って来る個人的な注意深い禁じアクティブな=<「偽」/>の>の<のsss設定><の同時のセッションサポートipab</設定能動態が></sss「本当」/設定></実体>poc</設定>と等しいということです。
Garcia-Martin Informational [Page 16] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[16ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
7. Security Considerations
7. セキュリティ問題
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 PUBLISH要求で輸送されることになっています。 したがって、RFC3903[8]のSecurity Considerations(セクション14)はこのドキュメントに適用します。 「poc-設定」イベントパッケージに含まれた設定はSIP PUBLISH要求を生成したユーザに特に、適切です。 したがって、「poc-設定」イベントを含んでいて、イベント公表を認可する前にパッケージSHOULDがユーザを認証するというSIP PUBLISH要求を受け取るサーバ、(必要に応じて、RFC3903[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で通知の保全保護と秘密性について議論します。 notifierがNOTIFY要求のボディーを暗号化しないなら、立ち聞きする者は、SIPユーザエージェントの状態を学んで、悪意があるPoCセッションを作成するのにそれを使用するかもしれません。 notifierがどんな保全もしないなら、NOTIFY要求のボディーを保護してください、中の男性、-、-、中央、攻撃者か悪意があるSIPプロキシがpoc-設定イベントパッケージ通知のコンテンツを変更できました。 これは害を引き起こしませんが、PoCセッションがユーザに提供されるとき、それはいらだち(例えばメディアはバッファリングの不足のため切り取られる)を引き起こすことができます。
8. Acknowledgements
8. 承認
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、アンドリュー・アレン、Chinmay Padhye、ゴンサロ・キャマリロ、ポールKyzivat、ハリスZisimopoulos、ジョエル・M.アルペルン、およびラスHousleyに感謝したがっています。
9. IANA Considerations
9. IANA問題
9.1. Registration of the "poc-settings" Event Package
9.1. 「poc-設定」イベントパッケージの登録
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:
この仕様はRFC3265[5]で定義された登録手順に基づいてイベントパッケージを登録します。 ↓これはそのような登録に必要である情報です:
Garcia-Martin Informational [Page 17] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[17ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
Package Name: poc-settings
名前をパッケージしてください: poc-設定
Package or Template-Package: This is a package.
パッケージかテンプレートパッケージ: これはパッケージです。
Published Document: RFC 4354
発行されたドキュメント: RFC4354
Person to Contact: Miguel A. Garcia-Martin, miguel.an.garcia@nokia.com
連絡する人: ミゲル・A.ガルシア-マーチン、 miguel.an.garcia@nokia.com
9.2. Registration of the "application/poc-settings+xml" MIME type
9.2. 「アプリケーション/poc-設定+xml」MIMEの種類の登録
To: ietf-types@iana.org
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ poc-settings+xml
Subject: MIMEメディアタイプアプリケーション/poc設定+xmlの登録
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: poc-settings+xml
MIME「副-タイプ」は以下を命名します。 poc-設定+xml
Required parameters: (none)
必要なパラメタ: (なにも)
Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8 [7].
任意のパラメタ: 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.
問題をコード化します: 文字符号化によるXML(8ビットのキャラクタを雇うことができる)が使用した用途。 RFC3023[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.
セキュリティ問題: このcontent typeは、いくつかの場合、個人情報であると考えられるかもしれない現在のPoCユーザー設定の情報を運ぶように設計されています。 適切な注意は、この情報の公開を制限するために採用されるべきです。
Interoperability considerations: This content type provides a common format for exchange of PoC settings information.
相互運用性問題: このcontent typeはPoC設定情報の交換のための一般的な形式を提供します。
Published specification: RFC 4354 (this document).
広められた仕様: RFC4354(このドキュメント)。
Applications which use this media type: Push-to-talk over Cellular systems in compliance with the Open Mobile Alliance (OMA) PoC specifications.
このメディアタイプを使用するアプリケーション: オープンのモバイルAlliance(OMA)PoC仕様に従ってCellularシステムの上で押して話してください。
Additional information: The Open Mobile Alliance publishes the Push-to-talk over Cellular specifications in the OMA web site at http://www.openmobilealliance.org
追加情報: オープンのモバイルAllianceは http://www.openmobilealliance.org のOMAウェブサイトのCellular仕様の上のPushから話を発行します。
Garcia-Martin Informational [Page 18] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[18ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
Person & email address to contact for further information: Miguel A. Garcia-Martin, miguel.an.garcia@nokia.com
詳細のために連絡する人とEメールアドレス: ミゲル・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.
コントローラを書くか、または変えてください: モバイル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 RFC3023[3]の専門化です、そして、また、そこで説明された問題の多くがアプリケーション/poc-設定+xmlに適用されます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[3] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[6] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[6] マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼンは「セッション開始プロトコル(一口)のためにプロセスを変えます」、BCP67、RFC3427、2002年12月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[7]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[8] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[8]Niemi、A.、「イベント州政府出版物のためのセッション開始プロトコル(一口)拡大」、RFC3903、2004年10月。
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[9]、RFC3851、2004年7月。
Garcia-Martin Informational [Page 19] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[19ページ]のRFC4354PoC設定イベントは2006年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.、T.、およびE.Maler、「拡張マークアップ言語(XML)1.0(第2版)」をSperberg-マックィーン、C.はいななかせます、W3C FirstEdition REC-xml-20001006、2000年10月。
10.2. Informative References
10.2. 有益な参照
[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] 「セッション開始プロトコル(一口)Uniform Resource Identifier(URI)のための要件とフレームワークはサービスを記載する」というキャマリロ、G.、およびA.ローチは進行中(2005年4月)で働いています。
[12] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, January 2006.
2006年1月の[12] ローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のためのフレームワーク」RFC4353。
Author's Address
作者のアドレス
Miguel A. Garcia-Martin Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland
ミゲルA.ガルシア-マーチンノキア私書箱407Nokia Group、FIN00045フィンランド
EMail: miguel.an.garcia@nokia.com
メール: miguel.an.garcia@nokia.com
Garcia-Martin Informational [Page 20] RFC 4354 PoC Settings Event Package January 2006
ガルシア-マーチンの情報[20ページ]のRFC4354PoC設定イベントは2006年1月をパッケージします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Garcia-Martin Informational [Page 21]
ガルシア-マーチンInformationalです。[21ページ]
一覧
スポンサーリンク
