Internet Engineering Task Force (IETF) D. Petrie
Request for Comments: 6080 SIPez LLC
Category: Standards Track S. Channabasappa, Ed.
ISSN: 2070-1721 CableLabs
March 2011
A Framework for Session Initiation Protocol User Agent Profile Delivery
セッション開始プロトコルユーザエージェントプロファイル配信のためのフレームワーク
Abstract
抽象
This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope.
この文書では、SIP展開でセッション開始プロトコル（SIP）ユーザエージェント（UAS）の設定を可能にするフレームワークを指定します。フレームワークは、ユーザーエージェントが自動的に、最小限または全くないユーザーと管理者の介入で、機能する必要があること、プロファイルデータを配信するための手段を提供します。フレームワークは、SIPユーザエージェントは、ソース、要求プロファイルを発見し、修正プロファイルに関連する通知を受信する方法について説明します。このフレームワークの一部として、新しいSIPイベントパッケージは、プロファイルの変更の通知のために定義されています。フレームワークは、相互運用性を確保するために、最小限のデータ検索オプションを提供します。フレームワークは、その範囲内のプロファイルデータの指定が含まれていません。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6080.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6080で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Profile Delivery Stages . . . . . . . . . . . . . . . . . 9
3.5. Supported Device Types . . . . . . . . . . . . . . . . . . 10
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 10
4.2. Devices Supporting Multiple Users from Different
Service Providers . . . . . . . . . . . . . . . . . . . . 12
5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 14
5.1. Profile Delivery Stages . . . . . . . . . . . . . . . . . 14
5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 22
5.3. Additional Considerations . . . . . . . . . . . . . . . . 24
5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 33
6. Event Package Definition . . . . . . . . . . . . . . . . . . . 33
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 33
6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 33
6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 36
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 37
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 37
6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 37
6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 38
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 38
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 39
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 39
6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 39
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Example 1: Device Requesting Profile . . . . . . . . . . . 39
7.2. Example 2: Device Obtaining Change Notification . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 46
8.2. Registry of SIP Configuration Profile Types . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47
9.1. Local-Network Profile . . . . . . . . . . . . . . . . . . 48
9.2. Device Profile . . . . . . . . . . . . . . . . . . . . . . 49
9.3. User Profile . . . . . . . . . . . . . . . . . . . . . . . 50
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Normative References . . . . . . . . . . . . . . . . . . . 52
11.2. Informative References . . . . . . . . . . . . . . . . . . 53
SIP user agents require configuration data to function properly. Examples include information specific to local networks, devices, and users. A configuration data set specific to an entity is termed a profile. For example, device profile contains the configuration data related to a device. The process of providing devices with one or more profiles is termed "profile delivery". Ideally, this profile delivery process should be automatic and require minimal or no user intervention.
SIPユーザエージェントは、適切に機能するためにコンフィギュレーション・データを必要とします。例としては、ローカルネットワーク、デバイス、およびユーザーに固有の情報が含まれています。エンティティに特定の設定の構成データは、プロファイルと呼ばれます。例えば、デバイスプロファイルは、デバイスに関連するコンフィギュレーションデータを含みます。 1つ以上のプロファイルを持つデバイスを提供するプロセスは、「プロファイルの配信」と呼ばれます。理想的には、このプロファイルの配信プロセスは自動的に行われ、最小限、あるいはまったくユーザーの介入を必要とすべきです。
Many deployments of SIP user agents require dynamic configuration and cannot rely on pre-configuration. This framework provides a standard means of providing dynamic configuration that simplifies deployments containing SIP user agents from multiple vendors. This framework also addresses change notifications when profiles change. However, the framework does not define the content or format of the profile, leaving that to future standardization activities.
SIPユーザエージェントの多くの配備は動的な構成を必要とし、事前の設定に依存することはできません。このフレームワークは、複数のベンダーからのSIPユーザエージェントを含む展開を簡素化する動的な構成を提供する標準的な手段を提供します。プロファイルが変更されたときに、このフレームワークは、変更通知に対応しています。しかし、フレームワークは、将来の標準化活動にそれを残して、プロフィールの内容や形式を定義していません。
This document is organized as follows. The normative requirements are contained in Section 5 (framework operations) and Section 6 (the event package definition). The rest of the document provides introductory and supporting explanations. Section 3 provides a high-level overview of the abstract components, profiles, and the profile delivery stages. Section 4 provides some motivating use cases. Section 7 follows with illustrative examples of the framework in use.
次のようにこの文書は、組織化されています。規範的な要件は、第5節（フレームワークの操作）と第6節（イベントパッケージ定義）に含まれています。文書の残りの部分は、導入とサポートの説明を提供します。セクション3は、抽象コンポーネント、プロファイル、プロファイル配信段の高レベルの概要を提供します。第4節では、いくつかの動機ユースケースを提供します。セクション7は、使用中のフレームワークの例示的な実施例で続きます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document also reuses the SIP terminology defined in [RFC3261] and [RFC3265], and it specifies the usage of the following terms.
また、このドキュメントは[RFC3261]及び[RFC3265]で定義されたSIPの用語を再利用し、それは以下の用語の使用法を指定します。
Device: software or hardware entity containing one or more SIP user agents. It may also contain applications such as a DHCP client.
デバイス：ソフトウェア、または1つのまたは複数のSIPユーザエージェントを含むハードウェアエンティティ。また、DHCPクライアントのようなアプリケーションが含まれていてもよいです。
Device Provider: the entity responsible for managing a given device.
デバイスプロバイダ：特定のデバイスの管理を担当するエンティティ。
Local Network Provider: the entity that controls the local network to which a given device is connected.
ローカルネットワークプロバイダ：特定のデバイスが接続されているローカルネットワークを制御するエンティティ。
SIP Service Provider: the entity providing SIP services to users. This can refer to private or public enterprises.
SIPサービスプロバイダ：ユーザーにSIPサービスを提供するエンティティ。これは、民間や公営企業を参照することができます。
Profile: configuration data set specific to an entity (e.g., user, device, local network, or other).
プロファイル：構成データは、エンティティ（例えば、ユーザ、デバイス、ローカルネットワーク、またはその他の）に特異的なセット。
Profile Type: a particular category of profile data (e.g., user, device, local network, or other).
プロファイルタイプ：プロファイルデータの特定のカテゴリ（例えば、ユーザ、デバイス、ローカルネットワーク、または他の）。
Profile Delivery Server (PDS): the source of a profile, it is the logical collection of the Profile Notification Component (PNC) and the Profile Content Component (PCC).
プロファイル配信サーバ（PDS）：プロファイルのソース、それはプロファイル通知コンポーネント（PNC）とプロファイルのコンテンツコンポーネント（PCC）の論理的なコレクションです。
Profile Notification Component (PNC): the logical component of a Profile Delivery Server that is responsible for enrolling devices and providing profile notifications.
プロフィール通知コンポーネント（PNC）：デバイスを登録し、プロファイルの通知を提供する責任があるプロファイル配信サーバの論理コンポーネント。
Profile Content Component (PCC): the logical component of a Profile Delivery Server that is responsible for storing, providing access to, and accepting profile content.
プロフィールコンテンツ・コンポーネント（PCC）：、保存へのアクセスを提供し、プロファイルのコンテンツを受け入れる責任あるプロファイル配信サーバの論理コンポーネント。
Profile Delivery Stages: the processes that lead a device to obtain profile data, and any subsequent changes, are collectively called profile delivery stages.
プロファイル配信段階：プロファイルデータを取得するためにデバイスを導く工程、及びその後の変更は、まとめてプロファイル配信ステージと呼ばれます。
Bootstrapping: Bootstrapping is the process by which a new (or factory reset) device, with no configuration or minimal "factory" pre-configuration, enrolls with the PDS. The device may use a temporary identity and credentials to authenticate itself to enroll and receive profiles, which may provide more permanent identities and credentials for future enrollments.
ブートストラップ：ブートストラップなしの構成または最小限の「工場」事前構成された新しい（または工場出荷時の状態にリセット）デバイスは、PDSを用いて登録するプロセスです。デバイスは、将来の就学のために、より恒久的なアイデンティティと資格情報を提供することができるプロファイルを登録し、受け取るために自分自身を認証するために、一時的なアイデンティティと資格情報を使用することができます。
This section provides an overview of the configuration framework. It presents the reference model, the motivation, the profile delivery stages, and a mapping of the concepts to specific use cases. It is meant to serve as a reference section for the document, rather than providing a specific logical flow of material, and it may be necessary to revisit these sections for a complete appreciation of the framework.
このセクションでは、コンフィギュレーション・フレームワークの概要を提供します。これは、具体的な使用例を参照モデル、モチベーション、プロファイル配信段階、および概念のマッピングを示しています。むしろ、材料の特定の論理フローを提供するよりも、文書のための基準部として機能するように意図され、そしてフレームワークの完全な理解のためにこれらのセクションを再検討する必要があるかもしれません。
The SIP UA Profile Delivery Framework uses a combination of SIP event messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file retrieval protocols, such as HTTP [RFC2616], to discover, monitor, and retrieve configuration profiles. The framework defines three types of profiles (local-network, device, and user) in order to separate aspects of the configuration that may be independently managed by different administrative domains. The initial SUBSCRIBE message for each profile allows the UA to describe itself (both its implementation and the identity requesting the profile), while requesting access to a profile by type, without prior knowledge of the profile name or location. Discovery mechanisms are specified to help the UA form the Subscription URI (the Request-URI for the SIP SUBSCRIBE). The SIP User Agent Server (UAS) handling these subscriptions is the Profile Delivery Server (PDS). When the PDS accepts a subscription, it sends a NOTIFY to the device. The initial NOTIFY from the PDS for each profile may contain profile data or a reference to the location of the profile, to be retrieved using HTTP or similar file retrieval protocols. By maintaining a subscription to each profile, the UA will receive additional NOTIFY messages if the profile is later changed. These may contain a new profile, a reference to a new profile, or a description of profile changes, depending on the Content-Type [RFC3261] in use by the subscription. The framework describes the mechanisms for obtaining three different profile types, but does not describe the data model they utilize (the data model is out of scope for this specification).
、発見モニター、および構成プロファイルを取得するために、そのようなHTTP [RFC2616]などの従来のファイル検索プロトコル（[RFC3265] SUBSCRIBE及びNOTIFY）SIP UAプロファイル配信フレームワークは、SIPイベント・メッセージの組合せを使用します。フレームワークは、独立して、異なる管理ドメインによって管理することができる構成の側面を分離するために3つのプロファイルの種類（ローカルネットワーク、デバイス、およびユーザ）を定義します。最初のタイプによって、プロファイルへのアクセスを要求しながら、各プロファイルに対するメッセージは、プロファイル名や場所の予備知識なしに、UAは（その実装およびプロファイルを要求するアイデンティティの両方）自体を記述することを可能にするSUBSCRIBE。発見メカニズムは、サブスクリプションURI（SIP SUBSCRIBEためのRequest-URI）を形成するUAを助けるために指定されています。これらのサブスクリプションを扱うSIPユーザエージェントサーバ（UAS）は、プロファイル配信サーバ（PDS）です。 PDSは、サブスクリプションを受け入れる場合は、デバイスにNOTIFYを送信します。各プロファイルは、HTTP又は同様のファイル検索プロトコルを使用して取得するプロファイルデータまたはプロファイルの場所への参照を含むことができるため、初期には、PDSからNOTIFY。プロファイルが後で変更された場合には、各プロファイルにサブスクリプションを維持することで、UAは、追加のNOTIFYメッセージを受信します。これらは、サブスクリプションによって使用中のContent-Type [RFC3261]に応じて、新しいプロファイル、新しいプロファイルへの参照、またはプロファイルの変更の記述を含んでいてもよいです。フレームワークは、3つの異なるプロファイル・タイプを取得するためのメカニズムを説明し、それらが利用するデータモデルを記述していない（データ・モデルは、本明細書の範囲外です）。
The design of the framework was the result of a careful analysis to identify the configuration needs of a wide range of SIP deployments. As such, the reference model provides for a great deal of flexibility, while breaking down the interactions to their basic forms, which can be reused in many different scenarios.
フレームワークの設計は、SIP展開の広い範囲の設定のニーズを識別するための慎重な分析の結果でした。このように多くの異なるシナリオで再利用することができ、それらの基本的な形態に相互作用を破壊しながら、参照モデルは、大きな柔軟性を提供します。
The reference model for the framework defines the interactions between the Profile Delivery Server (PDS) and the device. The device needs the profile data to function effectively in the network. The PDS is responsible for responding to device requests and providing the profile data. The reference model is illustrated in Figure 1.
フレームワークのための参照モデルは、プロファイル配信サーバ（PDS）とデバイスとの間の相互作用を規定します。デバイスは、プロファイルデータは、ネットワーク内で効果的に機能する必要があります。 PDSは、デバイスの要求に応答し、プロファイルデータを提供する責任があります。参照モデルは、図1に示されています。
+-------------------------+
+--------+ | Profile Delivery Server |
| Device |<==========================>| +---+ +---+ |
+--------+ | |PNC| |PCC| |
| +---+ +---+ |
+-------------------------+
PNC = Profile Notification Component
PCC = Profile Content Component
Figure 1: Framework Reference Model
図1：Frameworkリファレンスモデル
The PDS is subdivided into two logical components:
PDSは、二つの論理コンポーネントに細分化されています。
o Profile Notification Component (PNC), responsible for enrolling devices for profiles and providing profile change notifications.
プロファイルのデバイスを登録し、プロファイル変更通知を提供する責任Oプロファイル通知コンポーネント（PNC）、。
o Profile Content Component (PCC), responsible for storing, providing access to, and accepting modifications related to profile content.
O、記憶へのアクセスを提供し、プロファイルコンテンツに関連する変更を受け入れるための責任コンテンツ・コンポーネント（PCC）を、プロファイル。
The motivation for the framework can be demonstrated by applying the reference model presented in Section 3.1 to two scenarios that are representative of the two ends of a spectrum of potential SIP deployments.
フレームワークのための動機付けは、潜在的なSIP展開のスペクトルの両端の代表である2つのシナリオをセクション3.1に提示参照モデルを適用することによって実証することができます。
In the simplest deployment scenario, a device connects through a network that is controlled by a single provider who provides the local network, manages the devices, and offers services to the users. The provider propagates profile data to the device that contains all the necessary information to obtain services in the network (including information related to the local network and the users). This is illustrated in Figure 2. An example is a simple enterprise network that supports SIP-based devices.
最も単純な展開シナリオでは、デバイスは、ローカルネットワークを提供する単一のプロバイダによって制御されているネットワークを介して接続デバイスを管理し、ユーザにサービスを提供しています。プロバイダは、（ローカルネットワークとユーザに関連する情報を含む）ネットワークにおいてサービスを取得するために必要なすべての情報を含むデバイスにプロファイルデータを伝播します。これは例では、SIPベースのデバイスをサポートする単純な企業ネットワークである図2に示されています。
--------------
/ Local Network, \
| Device & Service |
\ Provider /
----------------
|
|
--------
| Device |
--------
|
|
----
|User|
----
Figure 2: Simple Deployment Model
図2：単純な展開モデル
In more complex deployments, devices connect via a local network that is not controlled by the SIP service provider, such as devices that connect via available public WiFi hot spots. In such cases, local network providers may wish to provide local network information such as bandwidth constraints to the devices.
より複雑な展開では、デバイスは、利用可能な公衆無線LANホットスポットを介して接続するデバイスとして、SIPサービスプロバイダによって制御されていないローカルネットワークを介して接続します。このような場合には、ローカルネットワークプロバイダは、そのようなデバイスへの帯域幅の制約として、ローカルネットワーク情報を提供することを望むかもしれません。
Devices may also be controlled by device providers that are independent of the SIP service provider who provides user services, such as kiosks that allow users to access services from remote locations. In such cases, the profile data may have to be obtained from different profile sources: local network provider, device provider, and SIP service provider. This is indicated in Figure 3.
デバイスはまた、ユーザが遠隔地からのサービスにアクセスすることを可能にするキオスクとしてユーザサービスを提供するSIPサービスプロバイダから独立しているデバイスプロバイダによって制御することができます。ローカルネットワークプロバイダ、デバイスプロバイダ、及びSIPサービスプロバイダ：このような場合、プロファイルデータは異なるプロファイルソースから取得されなければなりません。これは、図3に示されています。
--------
/ SIP \
| Service | -> Provides 'user' profile
| Provider | data (e.g., services
\ / configuration)
-------- --------
| / \
| | Device | -> Provides 'device' profile
| | Provider | data (e.g., device specifics)
| \ /
| ---------
| /
| / -------
| / / Local \
| / | Network |
| | | Provider | -> Provides 'local-network' profile
| | \ / data (e.g., bandwidth)
| | -------
| | /
| | /
| | |
===================
( Local Network )
===================
|
|
--------
| Device | -> Needs the 'local-network'
-------- and 'device' profile
/ \
/ \
------ ------
|User A| |User B| -> Users need 'user' profiles
------ ------
Figure 3: Complex Deployment Model
図3：複雑な展開モデル
In either case, Providers need to deliver to the device, profile data that is required to participate in their network. Examples of profile data include the list of codecs that can be used and the SIP proxies to which to connect for services. Pre-configuration of such information is one option if the device is always served by the same set of Providers. In all other cases, the profile delivery needs to be automated and consistent across Providers. Given the presence of a number of large deployments where pre-configuration is neither desired nor optimal, there is a need for a common configuration framework such as the one described in this document.
いずれの場合も、プロバイダは、そのネットワークに参加するために必要とされるデバイス、プロファイルデータを提供する必要があります。プロファイルデータの例としては、サービスのための接続先使用することができコーデックおよびSIPプロキシのリストが含まれています。このような情報の事前設定は、デバイスが常にプロバイダの同じセットで提供される場合は、1つの選択肢です。他のすべての例では、プロファイルの配信を自動化し、プロバイダ間で一貫する必要があります。事前設定は、所望でも最適でもない大規模な展開の数の存在を考えると、このような本文書に記載されたものと共通の構成フレームワークが必要とされています。
Further, the former deployment model can be accomplished by the device obtaining profile data from a single provider. However, the latter deployment model requires the device to obtain profile data from different providers. To address either deployment or any variation in between, one needs to allow for profile delivery via one or more Providers. The framework accomplishes this by specifying multiple profile types and a set of profile delivery stages to obtain them. These are introduced in the subsections to follow.
さらに、前者の展開モデルは、単一のプロバイダからのプロファイルデータを取得する装置によって達成することができます。しかし、後者の展開モデルは、異なるプロバイダからプロファイルデータを取得するためにデバイスを必要とします。展開またはその間の任意のバリエーションのいずれかに対処するために、1つは、1つの以上のプロバイダを経由して、プロファイルの配信を可能にする必要があります。フレームワークは、それらを得るために、複数のプロファイルタイプとプロファイル配信ステージのセットを指定することによって、これを達成します。これらは、フォローするのサブセクションで導入されています。
The framework handles the presence of potentially different Providers by allowing for multiple profile types. Clients request each profile separately, and obtain them from the same, or different, Providers. A deployment can also choose to pre-configure the device to request only a subset of the specified profile types. The framework specifies three basic profile types, as follows:
フレームワークは、複数のプロファイルタイプを可能にすることによって、潜在的に異なるプロバイダの存在を扱います。クライアントは、個別に各プロファイルを要求し、そして、同じ、または異なるプロバイダからそれらを得ます。展開はまた、指定されたプロファイルタイプのサブセットのみを要求するために、デバイスを事前に設定することを選択することができます。次のようなフレームワークは、三つの基本的なプロファイルの種類を指定します。
Local Network Profile: contains configuration data related to the local network to which a device is directly connected, provided by the local network provider.
ローカルネットワークプロファイルは、ローカルネットワークプロバイダによって提供されるデバイスが直接接続されるローカルネットワークに関連するコンフィギュレーションデータを含みます。
Device Profile: contains configuration data related to a specific device, provided by the device provider.
デバイスプロファイル：デバイス・プロバイダによって提供される特定のデバイスに関連するコンフィギュレーションデータを含んでいます。
User Profile: contains configuration data related to a specific User, as required to reflect that user's preferences and the particular services to which it is subscribed. It is provided by the SIP service provider.
ユーザープロファイルは：そのユーザーの好みとそれが購読している特定のサービスを反映するために、必要に応じて、特定のユーザーに関連する構成データが含まれています。これは、SIPサービスプロバイダが提供されます。
Additional profile types may also be specified by future work within the IETF. The data models associated with each profile type are out of scope for this document.
追加のプロファイルタイプはまた、IETF内の今後の作業で指定することができます。各プロファイル・タイプに関連付けられたデータ・モデルは、この文書の範囲外です。
The framework specified in this document requires a device to explicitly request profiles. It also requires one or more PDSs, which provide the profile data. The processes that lead a device to obtain profile data, and any subsequent changes, can be explained in three stages, termed the profile delivery stages.
この文書で指定されたフレームワークでは、明示的にプロファイルを要求するデバイスが必要です。また、プロファイルデータを提供する1つのまたは複数のPDSが必要です。プロファイルデータ、及び任意のその後の変更を取得するためにデバイスを導くプロセスは、3つの段階で説明したプロファイル配信ステージと呼ぶことができます。
Profile Enrollment: the process by which a device requests, and if successful, enrolls with a PDS capable of providing a profile. A successful enrollment is indicated by a notification containing the profile information (contents or content indirection information). Depending on the request, this could also result in a subscription to notification of profile changes.
プロフィール登録：によってデバイスリクエストプロセス、及び成功した場合、プロファイルを提供することができるPDSで登録します。成功した登録は、プロファイル情報（コンテンツ又はコンテンツ間接情報）を含む通知で示されています。リクエストに応じて、これはまた、プロファイルの変更の通知にサブスクリプションにつながる可能性があります。
Profile Content Retrieval: the process by which a device retrieves profile contents, if the profile enrollment resulted in content indirection information.
プロファイル登録がコンテンツ間接情報が得られた場合、デバイスは、プロファイルの内容を取得するプロセス：コンテンツ検索プロフィール。
Profile Change Notification: the process by which a device is notified of any changes to an enrolled profile. This may provide the device with modified profile data or content indirection information.
プロフィール変更通知：デバイスが登録プロファイルへの変更が通知されるプロセス。これは、変更されたプロファイルデータまたはコンテンツ間接情報と装置を提供することができます。
The examples in this framework tend to associate devices with entities that are accessible to end-users. However, this is not necessarily the only type of device that can utilize the specified framework. Devices can be entities such as SIP Phones or soft clients, with or without user interfaces (that allow for device configuration), entities in the network that do not directly communicate with any users (e.g., gateways, media servers, etc.) or network infrastructure elements (e.g., SIP servers). The framework is extensible for use with such device types. However, it is to be noted that some of these other device types (e.g., network elements) may also be configurable using other mechanisms. The use of this framework in conjunction with other mechanisms (specified outside of this document), is out of scope.
このフレームワークの例では、エンドユーザーにアクセス可能なエンティティとデバイスを関連付けする傾向があります。しかし、これは必ずしも指定されたフレームワークを利用することができる装置の唯一のタイプではありません。デバイスは、（デバイス構成を可能に）ユーザーインターフェースの有無にかかわらず、このようなSIP電話機またはソフトクライアントなどのエンティティ、直接任意のユーザー（例えば、ゲートウェイ、メディアサーバーなど）やネットワークと通信していないネットワーク内のエンティティすることができインフラストラクチャ要素（例えば、SIPサーバ）。フレームワークは、デバイス・タイプで使用するための拡張可能です。しかし、これらの他のデバイスタイプ（例えば、ネットワーク要素）の一部が、他のメカニズムを使用して構成してもよいことに留意すべきです。 （この文書の外に指定された）他の機構と組み合わせて、このフレームワークを使用すると、範囲外です。
This section provides a small, non-comprehensive set of representative use cases to further illustrate how this framework can be utilized in SIP deployments. The first use case is simplistic in nature, whereas the second is relatively complex. The use cases illustrate the effectiveness of the framework in either scenario.
このセクションでは、さらに、このフレームワークは、SIP展開で利用することができる方法を説明するための代表的な使用ケースの小さな、非包括的なセットを提供します。第二は、比較的複雑であるのに対し、第一のユースケースは、本質的に単純です。ユースケースは、いずれかのシナリオでは、フレームワークの有効性を示しています。
For security considerations, please refer to Sections 5 and 9.
セキュリティ上の考慮事項については、セクション5および9を参照してください。
Description: Consider a deployment scenario (e.g., a small private enterprise) where a participating device implements this framework and is configured, using previously obtained profile data, to request only the device profile. Assume that the device operates in the same network as the PDS (i.e., there is no NAT) and it obtains its IP configuration using DHCP. Typical communication between the device and the PDS will traverse one or more SIP proxies, but is not required, and is omitted in this illustration.
説明：参加デバイスは、このフレームワークを実装し、唯一のデバイスプロファイルを要求するために、以前に得られたプロファイルデータを用いて、構成されている展開シナリオ（例えば、小さな民間企業）を考えます。デバイスは、PDSと同じネットワークで動作すると仮定する（すなわち、全くNATが存在しない）、それはDHCPを使用してIP設定を取得します。デバイスとPDSの間の典型的な通信は、一つ以上のSIPプロキシを横断するが、必要ではなく、この図では省略されています。
Figure 4 illustrates the sequence of events that includes device start-up and a successful profile enrollment for the device profile that results in device profile data. It then illustrates how a change in the profile data is delivered via Profile Change Notification.
図4は、デバイス起動し、デバイスプロファイルデータをもたらすデバイスプロファイルの成功プロファイル登録を含むイベントのシーケンスを示しています。その後、プロファイルデータの変化はプロフィール変更通知を介して配信される方法を示しています。
+----------------------+
+--------+ | Provider's Network |
| Device | | |
| | | |
+--------+ | DHCP PDS |
+----------------------+
| | |
(A) |<============== DHCP =============>| |
| |
| |
| |
(B) |<=========== Profile Enrollment ============>|
| | Profile data
| | is modified
| |
(C) |<============ Profile Change ================|
| Notification |
| |
| |
Figure 4: Use Case 1
図4：ユースケース1
The following is an explanation of the interactions in Figure 4.
以下は、図4の相互作用について説明します。
(A) Upon initialization, the device obtains IP configuration parameters such as an IP address using DHCP.
初期化時に（A）は、装置は、DHCPを使用してIPアドレスとしてIP構成パラメータを取得します。
(B) The device requests profile enrollment for the device profile. Successful enrollment provides it with a notification containing the device profile data.
（B）デバイスは、デバイスプロファイルのプロファイル登録を要求します。成功した登録は、デバイス・プロファイル・データを含む通知でそれを提供します。
(C) Due to a modification of the device profile, a profile change notification is sent across to the device, along with the modified profile.
（C）によりデバイスプロファイルの修飾に、プロファイル変更通知は、変更したプロファイルとともに、デバイスに渡って送信されます。
Description: Consider a single device that allows multiple users to obtain services from different SIP service providers, e.g., a kiosk at an airport.
説明：複数のユーザーが異なるSIPサービスプロバイダからサービスを取得することを可能にする単一のデバイス、例えば、空港でキオスクを考えてみましょう。
The following assumptions apply:
以下の仮定が適用されます。
o Provider A is the device and local network provider for the device, and the SIP service provider for user A; Provider B is the SIP service provider for user B.
OプロバイダAは、デバイスとデバイスのローカルネットワークプロバイダ、およびユーザAのSIPサービスプロバイダです。プロバイダBは、ユーザBのSIPサービスプロバイダであります
o Profile enrollment always results in content indirection information requiring profile content retrieval.
Oプロファイル登録が常にプロファイルコンテンツ検索を要求するコンテンツ間接情報をもたらします。
o Communication between the device and the PDSs is facilitated via one or more SIP proxies (only one is shown in the illustration).
OデバイスとのPDSとの間の通信は、（一方のみが図に示されている）は、1つまたは複数のSIPプロキシを介して促進されます。
Figure 5 illustrates the use case and highlights the communications relevant to the framework specified in this document.
図5は、ユースケースを示し、この文書で指定されたフレームワークに関連する通信を強調する。
User User
A B +----------------------+ +----------------------+
+--------+ | Provider | | Provider |
| Device | | A | | B |
| | | | | |
+--------+ | DHCP PROXY PDS | | PROXY PDS |
+----------------------+ +----------------------+
| | | | | |
(A) |<====DHCP====>| | | | |
| | | | |
| | | | |
| Profile Enrollment | | | |
(B) |<local-network profile>|<====>| | |
|
| <<Profile content retrieval>>
|
|
| Profile Enrollment | | | |
(C) |<== device profile ==> |<====>| | |
|
| <<Profile content retrieval>>
|
.
.
.
| Profile Enrollment | | | |
(D) |<= user profile (A) => |<====>| | |
| | | | |
|
| <<Profile content retrieval>>
.
[[User A obtains services]]
.
.
.
|
| Profile Enrollment | |
(E) |<=========== user profile (B) ==========>|<=========>|
| | |
| <<Profile content retrieval>>
|
[[User B obtains services]]
[[ユーザーB]は、サービスを取得します]
Figure 5: Use Case 2
図5：ユースケース2
The following is an explanation of the interactions in Figure 5.
以下、図5における相互作用について説明します。
(A) Upon initialization, the device obtains IP configuration parameters using DHCP. This also provides the local domain information to help with local-network profile enrollment.
初期化時に（A）は、デバイスがDHCPを使用してIP構成パラメータを取得します。これは、ローカル・ネットワークプロファイルの登録を支援するローカルドメインの情報を提供します。
(B) The device requests profile enrollment for the local network profile. It receives an enrollment notification containing content indirection information from Provider A's PDS. The device retrieves the profile (this contains useful information such as firewall port restrictions and available bandwidth).
（B）デバイスがローカルネットワークプロファイルのプロファイル登録を要求します。これは、プロバイダAのPDSからコンテンツ間接情報を含む登録通知を受け取ります。デバイスプロファイル（これは、ファイアウォールポート制限および利用可能な帯域幅などの有用な情報が含まれている）を取得します。
(C) The device then requests profile enrollment for the device profile. It receives an enrollment notification resulting in device profile content retrieval. The device initializes the user interface for services.
（C）デバイスは、デバイスプロファイルのプロファイル登録を要求します。これは、デバイスプロファイル、コンテンツ検索で得られた登録通知を受信します。デバイスは、サービスのためのユーザーインターフェイスを初期化します。
(D) User A with a pre-existing service relationship with Provider A attempts communication via the user interface. The device uses the user supplied information (including any credential information) and requests profile enrollment for user A's profile. Successful enrollment and profile content retrieval results in services for user A.
プロバイダAと既存のサービス関係を有する（D）ユーザAは、ユーザインタフェースを介して通信を試みます。デバイスは、（任意の資格情報を含む）ユーザ供給された情報を使用して、ユーザAのプロファイルのプロファイル登録を要求します。ユーザAのためのサービスで成功した登録とプロフィールコンテンツ検索結果
(E) At a different point in time, user B with a service relationship with Provider B attempts communication via the user interface. It enrolls and retrieves user B's profile and this results in services for user B.
（E）は、時間的に異なる時点で、プロバイダBとのサービス関係を有するユーザBは、ユーザインターフェースを介して通信を試みます。これは、登録して、ユーザBのプロファイルを取得し、これは、ユーザBのためのサービスになり
The discovery mechanisms for profile enrollment described by the framework, or the profile data themselves, can result in outbound proxies that support devices behind NATs, using procedures specified in [RFC5626].
フレームワークによって記載プロファイル登録のための検出メカニズム、またはプロファイルデータ自体は、[RFC5626]で指定された手順を使用して、NATの背後にあるデバイスをサポートするアウトバウンドプロキシをもたらすことができます。
This section specifies the profile delivery framework. It provides the requirements for the three profile delivery stages introduced in Section 3.4 and presents the associated security requirements. It also presents considerations such as back-off and retry mechanisms.
このセクションでは、プロファイル配信フレームワークを指定します。これは、3.4節で紹介し3つのプロファイルの配信ステージのための要件を提供し、関連するセキュリティ要件を提示します。また、このようなバックオフなどの考慮事項を提示し、メカニズムを再試行してください。
The three profile delivery stages -- enrollment, content retrieval, and change notification -- apply separately to each profile type specified for use with this framework. The following subsections provide the requirements associated with each stage.
3つのプロファイル送達段階 - 加入、コンテンツ検索、および変更通知 - このフレームワークで使用するために指定された各プロファイルタイプに別々に適用します。以下のサブセクションでは、各ステージに関連付けられている要件を提供します。
Profile enrollment is the process by means of which a device requests, and receives, profile data. Each profile type specified in this document requires an independent enrollment request. However, a particular PDS can support enrollment for one or more profile types.
プロファイル登録は、デバイス要求によって処理され、そして、プロファイルデータを受信します。この文書で指定された各プロファイルのタイプは、独立した登録要求を必要とします。しかし、特定のPDSは、1つまたは複数のプロファイルタイプに対して登録をサポートすることができます。
PDSs and devices MUST implement all of the three profile types. A device that has not been configured otherwise SHOULD try to obtain all the three profile types, in the order specified by this framework. The exceptions are bootstrapping when it SHOULD request the device profile type (see Section 5.3.1) or when it has been explicitly configured with a different order via mechanisms such as previously retrieved profile data or pre-configuration or manual configuration.
PDSおよびデバイスは3つのプロファイルタイプをすべて実装しなければなりません。それ以外の場合は設定されていないデバイスは、このフレームワークによって指定された順序で、すべての3つのプロファイルのタイプを取得しようとする必要があります。それはデバイスプロファイルタイプ（セクション5.3.1を参照）を要求する必要があるとき、またはそれが明示的にそのような以前に取得したプロファイルデータまたは事前設定または手動設定などのメカニズムを介して、異なる順序で構成されているときに例外がブートストラップされます。
Profile enrollment consists of the following operations, in the specified order.
プロフィール登録は指定された順序で、以下の操作で構成されています。
Enrollment request transmission
登録要求送信
Profile enrollment is initiated when the device transmits a SIP SUBSCRIBE request [RFC3265] for the 'ua-profile' event package, specified in Section 6. The profile being requested is indicated using the 'profile-type' parameter. The device MUST transmit the SIP SUBSCRIBE message via configured outbound proxies for the destination domain, or in accordance with RFC 3263 [RFC3263].
デバイスは、要求されたプロファイルは、「プロファイル・タイプ」パラメータを使用して示されているセクション6で指定された「UAプロファイル」イベントパッケージのSIP SUBSCRIBEリクエスト[RFC3265]を、送信するときに、プロファイル登録が開始されます。デバイスは、SIP宛先ドメインの、又はRFC 3263 [RFC3263]に従って構成されたアウトバウンドプロキシを介しSUBSCRIBEメッセージを送信しなければなりません。
The device needs certain data to create an enrollment request, form a Request-URI, and authenticate to the network. This includes the profile provider's domain name and device or user identities and credentials. Such data can be "configured" during device manufacturing, by the user, or via profile data enrollment (see Section 5.3.1). The data can also be "discovered" using the procedures specified by this framework. The "discovered" data can be retained across device resets (but not across factory resets) and such data is referred to as "cached". Thus, data can be configured, discovered, or cached. The following requirements apply.
デバイスは、登録要求を作成するのRequest-URIを形成し、ネットワークへの認証に特定のデータを必要とします。これは、プロファイルプロバイダのドメイン名とデバイスまたはユーザーIDと認証情報が含まれています。そのようなデータは、ユーザによって、またはプロファイルデータの登録を介して、デバイスの製造中に「構成」させることができる（セクション5.3.1参照）。データはまた、このフレームワークによって指定された手順を使用して「発見」することができます。 「発見」のデータは、デバイスリセットしても保持（ただし、工場出荷時のリセットにわたる）と、そのようなデータは、「キャッシュされた」と呼ぶことにすることができます。このように、データは、構成された発見、またはキャッシュすることができます。以下の要件が適用されます。
* If the device is configured with a specific domain name (for the local network provider or device provider), it MUST NOT attempt "discovery" of the domain name. This is the case when the device is pre-configured (e.g., via a user interface) to be managed by specific entities.
*デバイスは（ローカルネットワークプロバイダや機器プロバイダーのために）特定のドメイン名で構成されている場合、それは、ドメイン名の「発見」を試みてはいけません。これは、デバイスが事前に設定（例えば、ユーザインタフェースを介して）特定のエンティティによって管理する場合です。
* The device MUST only use data associated with the provider's domain in an enrollment request. As an example, when the device is requesting a local-network profile in the domain 'example.net', it cannot present a user Address of Record (AoR) associated with the local domain 'example.com'.
*デバイスは登録要求にプロバイダのドメインに関連付けられたデータを使用しなければなりません。デバイスがドメイン「example.net」内ローカルネットワークプロファイルを要求している場合、一例としては、ローカルドメイン「example.com」に関連付けられたレコード（AOR）のユーザアドレスを提示することができません。
* The device SHOULD adhere to the following order of data usage: configured, cached, and discovered. An exception is when the device is explicitly configured to use a different order.
*デバイスは、データ使用の次の順序を遵守する必要があります構成され、キャッシュされた、と発見しました。デバイスは、明示的に別の順序を使用するように設定されている場合は例外です。
Upon failure to obtain the profile using any methods specified in this framework, the device MAY provide a user interface to allow for user intervention. This can result in temporary, one-time data to bootstrap the device. Such temporary data is not considered to be "configured" and SHOULD NOT be cached across resets. The configuration obtained using such data MAY provide the configuration data required for the device to continue functioning normally.
この枠組みの中で指定された任意の方法を使用してプロファイルを得るために失敗したときに、デバイスは、ユーザの介入を可能にするユーザインタフェースを提供してもよいです。これは、デバイスをブートストラップするために一時的に、1回のデータになります。このような一時的なデータは、「構成された」ことをしてリセットしてもキャッシュされるべきではないと見なされていません。そのようなデータを用いて得られた構成が正常に機能し続けるために装置に必要な構成データを提供することができます。
Devices attempting enrollment MUST comply with the SIP-specific event notification specified in [RFC3265], the event package requirements specified in Section 6.2, and the security requirements specified in Section 5.2.
登録をしようとするデバイスは、[RFC3265]で指定されたSIP固有のイベント通知、6.2節で指定されたイベントパッケージの要件、および5.2節で指定されたセキュリティ要件を遵守しなければなりません。
Enrollment request admittance
登録要求アドミタンス
A PDS or a SIP proxy will receive a transmitted enrollment request. If a SIP infrastructure element receives the request, it will relay it to the authoritative proxy for the domain indicated in the Request-URI (the same way it would handle any other SUBSCRIBE message). The authoritative proxy is required to examine the request (e.g., event package) and transmit it to a PDS capable of addressing the profile enrollment request.
PDSまたはSIPプロキシは、送信、登録要求を受信します。 SIPインフラストラクチャ要素が要求を受信した場合、それは、Request-URI（それは他のSUBSCRIBEメッセージを処理するのと同じ方法）で示さドメインの権威プロキシにそれを中継します。権限のプロキシは、要求（例えば、イベントパッケージ）を調べ、プロファイル登録要求に対処することのできるPDSに送信する必要があります。
A PDS receiving the enrollment request SHOULD respond to the request, or proxy it to a PDS that can respond. An exception to responding or proxying the request is when a policy prevents response (e.g., recognition of a denial-of-service (DoS) attack, an invalid device, etc.). The PDS then verifies the identity presented in the request and performs any necessary authentication. Once authentication is successful, the PDS MUST either admit or reject the enrollment request, based on applicable authorization policies. A PDS admitting the enrollment request indicates it via a 2xx-class response, as specified in [RFC3265].
登録要求を受信したPDSは、要求に応答する、または応答することができPDSへのプロキシそれをすべきです。ポリシーが応答を阻止するときの応答または要求をプロキシの例外である（例えば、サービス拒否（DoS）攻撃、無効なデバイスなどの認識）。 PDSは、要求に提示アイデンティティを検証し、必要な認証を行います。認証が成功すると、PDSは、適用可能な認可ポリシーに基づいて、登録要求を認めるか拒否する必要があります。登録要求を認めるPDSは、[RFC3265]で指定されるように、2XXクラスの応答を介してそれを示します。
Refer to Sections 6.6 and 5.2 for more information on subscription request handling and security requirements, respectively.
それぞれ、サブスクリプション要求の処理及びセキュリティ要件の詳細については、セクション6.6と5.2を参照してください。
Enrollment request acceptance
登録要求受付
A PDS that admits the enrollment request verifies applicable policies, identifies the requested profile data and prepares a SIP NOTIFY message to the device. Such a notification can either contain the profile data or contain content indirection information that results in the device performing profile content retrieval. The PDS then transmits the prepared SIP notification. When the device successfully receives and accepts the SIP notification, profile enrollment is complete.
登録要求は、適用可能なポリシーを検証認めPDSは、要求されたプロファイルデータを識別し、SIPデバイスにNOTIFYメッセージを準備します。そのような通知は、プロファイルデータを含むまたはプロファイルコンテンツ検索を実行する装置になるコンテンツ間接情報を含むことができます。 PDSは、次に準備SIP通知を送信します。デバイスが正常にSIP通知を受信して、受け入れると、プロフィール登録が完了しています。
When it receives the SIP NOTIFY message, indicating successful profile enrollment, the device SHOULD make the new profile effective within the specified time frame, as described in Section 6.2. The exception is when the profile data is delivered via content indirection, and the device cannot obtain the profile data within the specified time frame.
それはSIPが成功プロファイル登録を示す、NOTIFYメッセージを受信した場合、セクション6.2で説明したように、デバイスは、指定された時間枠内で新規プロファイルを有効にするべきです。プロファイルデータは、コンテンツ間接介して送達され、デバイスが指定された時間枠内にプロファイルデータを取得できない場合は例外です。
Once profile enrollment is successful, the PDS MUST consider the device enrolled for the specific profile, for the duration of the subscription.
プロフィールの登録が成功すると、PDSは、サブスクリプションの期間中、特定のプロファイルに登録し、デバイスを考慮する必要があります。
A successful profile enrollment leads to an initial SIP notification, and may result in subsequent change notifications. Each of these notifications can either contain profile data or content indirection information. If it contains content indirection information, the device is required to retrieve the profile data using the specified content retrieval protocols. This process is termed "profile content retrieval". For information regarding the use of the SIP NOTIFY message body, please refer to Section 6.5.
成功したプロファイルの登録は、最初のSIP通知につながり、その後の変更通知をもたらすことができます。これらの通知はそれぞれ、いずれかのプロファイルデータやコンテンツ間接情報を含めることができます。それは、コンテンツ間接情報が含まれている場合は、デバイスが指定されたコンテンツ検索プロトコルを使用してプロファイルデータを取得するために必要とされます。このプロセスは、「プロファイルコンテンツ検索」と呼ばれています。 SIPを使用すると、メッセージ本文をNOTIFYに関する情報については、6.5節を参照してください。
Devices and PDSs implementing this framework MUST implement two content retrieval protocols: HTTP and HTTPS, as specified in [RFC2616] and [RFC2818], respectively. Future enhancements or usage of this framework may specify additional or alternative content retrieval protocols. For security requirements and considerations, please refer to Section 5.2.
それぞれ、[RFC2616]で指定されるように、HTTPおよびHTTPS及び[RFC2818]：このフレームワークを実装する装置とのPDSは、2つのコンテンツ検索プロトコルを実装しなければなりません。将来の拡張またはこのフレームワークの使用は、追加または代替コンテンツ検索プロトコルを指定することができます。セキュリティ要件および考慮事項については、5.2節を参照してください。
Profile data can change over time. Changes can be initiated by various entities (e.g., via the device, back-office components, and end-user web interfaces) and for various reasons (e.g., change in user preferences and modifications to services). Profiles may also be shared by multiple devices simultaneously. When a profile is changed, the PDS MUST inform all the devices currently enrolled for the specific profile. This process of informing a device of any changes to the profile that it is currently enrolled for is termed change notification.
プロフィールデータは、時間の経過とともに変化することができます。変更は、（デバイス、バックオフィスコンポーネント、およびエンドユーザーのウェブインターフェースを介して、例えば）、及び様々な理由のために様々なエンティティによって開始することができる（例えば、ユーザの好みやサービスへの変更で変化します）。プロファイルはまた、同時に複数のデバイスで共有することができます。プロファイルが変更された場合、PDSは、現在、特定のプロファイルに登録したすべてのデバイスに通知する必要があります。それは現在のために登録されたプロファイルへの変更のデバイスに通知するこのプロセスは、変更通知と呼ばれています。
The PDS provides change notification using a SIP notification (the SIP NOTIFY message, as specified in [RFC3265]). The SIP notification may provide the changes, a revised profile, or content indirection, which contains a pointer to the revised data. When a device successfully receives a profile change notification for an enrolled profile, it MUST act upon the changes prior to the expiration of the 'effective-by' parameter.
PDSは、SIP通知（[RFC3265]で指定されるように、SIPは、NOTIFYメッセージ）を用いて変更通知を提供します。 SIP通知は、改訂されたデータへのポインタを含む変更、改訂されたプロファイル、またはコンテンツ・インダイレクションを、提供することができます。デバイスが正常に登録されたプロファイルのプロファイルの変更通知を受信した場合、それは効果的なバイ 'パラメータの満了前に変更時に行動しなければなりません。
For NOTIFY content, please refer to Section 6.5.
NOTIFY内容については、6.5節を参照してください。
The requirements for the contents of the SIP SUBSCRIBE used to request profile enrollment are described in this section. The data required can be configured, cached, or discovered -- depending on the profile type. If the data is not configured, the device MUST use relevant cached data or proceed with data discovery. This section describes the requirements for creating a SIP SUBSCRIBE for enrollment, the caching requirements and how data can be discovered.
SIPのコンテンツの要件は、このセクションで説明されているプロファイルの登録を要求するために使用SUBSCRIBE。必要なデータは、構成されたキャッシュされた、または発見することができます - プロファイルの種類によって異なります。データが設定されていない場合、デバイスは、関連するキャッシュされたデータを使用したり、データの発見を続行しなければなりません。このセクションでは、SIPは、登録、キャッシュの要件とどのようにデータを発見することができますのためのSUBSCRIBE作成するための要件について説明します。
To create a Subscription URI to request the local-network profile, a device needs the local network domain name, the device identifier, and optionally a user AoR with associated credentials (if one is configured). Since the device can be potentially initialized in a different local network each time, it SHOULD NOT cache the local network domain, the SIP Subscription URI or the local-network profile data across resets. An exception to this is when the device can confirm that it is reinitialized in the same network (using means outside the scope of this document). Thus, in most cases, the device needs to discover the local network domain name. The device discovers this by establishing IP connectivity in the local network (such as via DHCP or pre-configured IP information). Once established, the device MUST attempt to use the local network domain obtained via pre-configuration, if available. If it is not pre-configured, it MUST employ dynamic discovery using DHCPv4 ([RFC2132], Domain Name option) or DHCPv6 ([RFC4704]). Once the local network domain is obtained, the device creates the SIP SUBSCRIBE for enrollment as described below.
（一方が設定されている場合）、ローカル・ネットワーク・プロファイルを要求するサブスクリプションURIを作成するために、デバイスは、ローカルネットワークドメイン名、デバイス識別子、および関連する資格情報を使用して必要に応じてユーザのAoRを必要とします。デバイスは、潜在的に異なるローカルネットワーク内の各時間を初期化することができるので、リセットしても、ローカルネットワークドメイン、SIPサブスクリプションURIまたはローカル・ネットワーク・プロファイル・データをキャッシュすべきではありません。この例外は、デバイスが（この文書の範囲外の手段を使用して）それが同じネットワークに再初期化されていることを確認できた場合です。したがって、ほとんどの場合、デバイスは、ローカルネットワークのドメイン名を発見する必要があります。デバイスは、（DHCPまたは事前設定されたIP情報を介して）ローカル・ネットワーク内のIP接続を確立することにより、これを発見します。設立後は、デバイスが利用可能な場合は、事前設定を経て得られたローカルネットワークドメインを使用しようとしなければなりません。それは事前に設定されていない場合、それはDHCPv4の（[RFC2132]、ドメイン名オプション）またはDHCPv6の（[RFC4704]）を使用して動的検出を使用しなければなりません。ローカル・ネットワーク・ドメインが得られると、装置は、以下に説明するようにSIPを登録するためのSUBSCRIBE作成します。
o The device MUST NOT populate the user part of the Request-URI. The device MUST set the host portion of the Request-URI to the dot-separated concatenation of "_sipuaconfig" and the local network domain (see example below).
Oデバイスは、Request-URIのユーザ部を投入してはなりません。デバイスが「_sipuaconfig」とローカルネットワークドメインのドットで区切られた連結へのRequest-URIのホスト部分を設定しなければならない（以下の例を参照）。
o If the device has been configured with a user AoR for the local network domain (verified as explained in Section 5.2) the device MUST use it to populate the From field, unless configured not to (due to privacy concerns, for example). Otherwise, the device MUST set the From field to a value of "anonymous@anonymous.invalid".
デバイスがローカルネットワークドメインのユーザーのAoRで構成されている場合、デバイスは、フィールドから移入するためにそれを使用しなければならない（例えば、原因プライバシーの問題に）ないように設定されていない限り、O、（5.2節で説明したように検証）。そうでない場合、デバイスは、フィールドから「anonymous@anonymous.invalid」の値に設定しなければなりません。
o The device MUST include the +sip.instance parameter within the Contact header, as specified in [RFC5626]. The device MUST ensure that the value of this parameter is the same as that included in any subsequent profile enrollment request.
デバイスO [RFC5626]で指定されるように、Contactヘッダ内の+ sip.instanceパラメータを含まなければなりません。デバイスは、このパラメータの値は、後続のプロファイル登録要求に含まれたものと同じであることを確認しなければなりません。
For example, if the device requested and received the local domain name via DHCP to be: airport.example.net, then the local-network profile SUBSCRIBE Request-URI would look like:
デバイスは要求されたとするDHCPを介してローカルドメイン名を受け取った場合、例えば：airport.example.net、ローカル・ネットワーク・プロファイルは、Request-URIは次のようになりSUBSCRIBE：
sip:_sipuaconfig.airport.example.net
SIP：_sipuaconfig.airport.example.net
The local-network profile SUBSCRIBE Request-URI does not have a user part so that the URI is distinct between the "local" and "device" URIs when the domain is the same for the two. This provides a means of routing to the appropriate PDS in domains where there are distinct servers.
ローカルネットワークプロファイルは、ドメインが2について同じである場合、URIは「ローカル」と「デバイス」のURIとの間の区別されるようにリクエストURIは、ユーザ部分を持たないSUBSCRIBE。これは、別個のサーバが存在するドメイン内の適切なPDSにルーティングする手段を提供します。
The From field is populated with the user AoR, if available. This allows the local network provider to propagate user-specific profile data, if available. The "+sip.instance" parameter within the Contact header is set to the device identifier or specifically, the SIP UA instance. Even though every device may get the same (or similar) local-network profile, the uniqueness of the "+sip.instance" parameter provides an important capability. Having unique instance ID fields allows the management of the local network to track devices present in the network and consequently also manage resources such as bandwidth allocation.
利用可能な場合、フィールドから、ユーザーのAoRが移入されます。これは、利用可能な場合には、ユーザー固有のプロファイルデータを伝播するローカルネットワークプロバイダを可能にします。 Contactヘッダ内の「+ sip.instance」パラメータは、デバイス識別子、または具体的には、SIP UAのインスタンスに設定されています。すべてのデバイスが同じ（または類似の）ローカル・ネットワークプロファイルを得ることができたとしても、「+ sip.instance」パラメータの一意性は、重要な機能を提供します。一意のインスタンスIDフィールドを有するローカルネットワークの管理は、ネットワークに存在するデバイスを追跡し、その結果、このような帯域割り当てなどのリソースを管理することを可能にします。
Once associated with a device, the device provider is not expected to change frequently. Thus, the device is allowed to, and SHOULD, cache the Subscription URI for the device profile upon successful enrollment. Exceptions include cases where the device identifier has changed (e.g., new network card), device provider information has changed (e.g., user initiated change), or the device cannot obtain its profile using the Subscription URI. Thus, when available, the device MUST use a cached Subscription URI. If no cached URI is available then it needs to create a Subscription URI. To create a Subscription URI, the device needs a device identity and the device provider's domain name. Unless already configured, the device needs to discover the necessary information and form the Subscription URI. In such cases, the following requirements apply for creating a Subscription URI for requesting the device profile:
デバイスに関連付けられていると、デバイスプロバイダが頻繁に変更することが予想されていません。このように、デバイスがに許可され、そして、成功した入学時にデバイスプロファイル用のサブスクリプションのURIをキャッシュすべきです。例外は、デバイス識別子（例えば、新しいネットワークカード）変更された、デバイスプロバイダ情報（例えば、ユーザが開始変化）変化している、またはデバイスがサブスクリプションURIを使用してプロファイルを得ることができない場合が挙げられます。このように、利用可能な場合、デバイスは、キャッシュされたサブスクリプションのURIを使用しなければなりません。キャッシュされたURIが使用できない場合、それはサブスクリプションのURIを作成する必要があります。サブスクリプションのURIを作成するには、デバイスはデバイスIDとデバイスプロバイダのドメイン名を必要とします。すでに設定されていない限り、デバイスは、必要な情報を発見し、サブスクリプションのURIを形成する必要があります。このような場合には、次の要件は、デバイスプロファイルを要求するためのサブスクリプションのURIを作成するために適用されます。
o The device MUST populate the user part of the Request-URI with the device identifier. The device MUST set the host portion of the Request-URI to the domain name of the device provider. The device identifier format is explained in detail later in this section.
Oデバイスは、デバイス識別子とのRequest-URIのユーザ部分に移入しなければなりません。デバイスは、デバイスプロバイダのドメイン名へのRequest-URIのホスト部分を設定しなければなりません。デバイス識別子のフォーマットは、この節の後半で詳細に説明します。
o The device MUST set the From field to a value of anonymous@<device provider's domain>.
Oデバイスは匿名@ <デバイスプロバイダのドメイン>の値にFromフィールドを設定しなければなりません。
o The device MUST include the "+sip.instance" parameter within the Contact header, as specified in [RFC5626]. The device MUST use the same value as the one presented while requesting the local-network profile.
[RFC5626]で指定されるようにOデバイスは、コンタクトヘッダ内の「+ sip.instance」パラメータを含まなければなりません。デバイスは、ローカルネットワークプロファイルを要求しながら、提示された1つとして同じ値を使用しなければなりません。
Note that the discovered AoR for the Request-URI can be overridden by a special, provisioned, AoR that is unique to the device. In such cases, the provisioned AoR is used to form the Request-URI and to populate the From field.
要求URIのための発見のAoRは、デバイスに固有の特別な、プロビジョニング、のAoRによって上書きされることに注意してください。このような場合、プロビジョニングのAoRは、Request-URIを形成し、フィールドから移入するために使用されます。
If the device is not configured with an AoR, and needs a domain name to populate the Request-URI and the From field, it can either use a configured domain name, if available, or discover it. The options to discover are described below. The device MUST use the results of each successful discovery process for one enrollment attempt, in the order specified below.
デバイスがのAoRで構成され、リクエスト-URIおよびFromフィールドを移入するためにドメイン名を必要とされていない場合は、それが利用可能な場合、設定されたドメイン名を使用するか、またはそれを発見することができます。発見するためのオプションを以下に記載されています。デバイスは、以下の指定された順序で、1回の入学の試行に成功するたびに発見プロセスの結果を使用しなければなりません。
o Option 1: Devices that support DHCP MUST attempt to obtain the domain name of the outbound proxy during the DHCP process, using the DHCP option for SIP servers defined in [RFC3361] or [RFC3319] (for IPv4 and IPv6, respectively).
Oオプション1：DHCPをサポートするデバイスは、[RFC3361]または[RFC3319]で定義されたSIPサーバのDHCPオプション（IPv4とIPv6のそれぞれ）を使用して、DHCPプロセス中アウトバウンドプロキシのドメイン名を取得しようとしなければなりません。
o Option 2: Devices that support DHCP MUST attempt to obtain the local IP network domain during the DHCP process (refer to [RFC2132] and [RFC4704]).
Oオプション2：DHCPをサポートしているデバイスは、DHCPプロセス中にローカルIPネットワークドメインを取得しようとしなければならない（[RFC2132]及び[RFC4704]参照）。
o Option 3: Devices MUST use the local network domain name (configured or discovered to retrieve the local-network profile), prefixing it with the label "_sipuaconfig".
Oオプション3：デバイスは、ラベル「_sipuaconfig」とそれを前に置く、ローカルネットワークドメイン名（設定またはローカル・ネットワークプロファイルを取得するために発見された）を使用する必要があります。
If the device needs to create a Subscription URI and needs to use its device identifier, it MUST use the UUID-based (Universally Unique Identifier) URN representation as specified in [RFC4122]. The following requirements apply:
デバイスは、サブスクリプションURIを作成する必要があり、そのデバイス識別子を使用する必要がある場合は、[RFC4122]で指定されるように、それはUUIDベース（汎用一意識別子）URN表現を使用しなければなりません。次の要件が適用されます。
o When the device has a non-alterable Media Access Control (MAC) address, it SHOULD use the version 1 UUID representation with the timestamp and clock sequence bits set to a value of '0'. This will allow for easy recognition, and uniqueness of MAC-address-based UUIDs. An exception is the case where the device supports independent device configuration for more than one SIP UA. An example would be multiple SIP UAs on the same platform.
デバイスが非可変メディアアクセス制御（MAC）アドレスを有する場合、O、それが「0」の値に設定されたタイムスタンプとクロックシーケンスビットとバージョン1つのUUID表現を使用すべきです。これは容易に認識し、MACアドレスベースのUUIDの一意性を可能にします。例外は、デバイスが複数のSIP UAのための独立した装置の構成をサポートする場合です。例では、同じプラットフォーム上で複数のSIPのUAだろう。
o If the device cannot use a non-alterable device identifier, it SHOULD use an alternative non-alterable device identifier. For example, the International Mobile Equipment Identity (IMEI) for mobile devices.
デバイスが非可変デバイス識別子を使用できない場合、O、それは代替の非変更可能なデバイス識別子を使用すべきです。例えば、モバイルデバイスのための国際移動体装置識別番号（IMEI）。
o If the device cannot use a non-alterable MAC address, it MUST use the same approach as defining a user agent instance ID in [RFC5626].
デバイスが非可変MACアドレスを使用できない場合、O、それは[RFC5626]にユーザエージェントインスタンスIDを定義するのと同じ方法を使用しなければなりません。
o Note: when the URN is used as the user part of the Request-URI, it MUST be URL escaped since the colon (":") is not a legal character in the user part of an addr-spec ([RFC4122]), and must be escaped.
O注：URNは、リクエストURIのユーザーの一部として使用される場合、それはコロン（「：」）があるためURLはエスケープする必要のaddr-specのユーザ部分に法的文字はない（[RFC4122]） 、およびエスケープする必要があります。
For example, the instance ID:
urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com
would be escaped to look as follows in a URI: sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@ example.com
SIP：URIに次のように見えるようにエスケープされるだろう壷％3auuid％3af81d4fae-7ced-11D0-a765-00a0c91e6bf6 @ example.com
The ABNF ([RFC5234]) for the UUID representation is provided in [RFC4122].
UUIDの表現のためのABNFは、（[RFC5234]）[RFC4122]に提供されます。
To create a Subscription URI to request the user profile on behalf of a user, the device needs to know the user's AoR. This can be statically or dynamically configured on the device (e.g., user input, or propagated as part of the device profile). Similar to device profiles, the content and propagation of user profiles may differ, based on deployment scenarios (i.e., users belonging to the same domain may -- or may not -- be provided the same profile). To create a Subscription URI, the following rules apply: o The device MUST set the Request-URI to the user AoR.
ユーザーの代わりにユーザープロファイルを要求するサブスクリプションのURIを作成するには、デバイスは、ユーザののAoRを知っている必要があります。これは、静的または動的デバイス（例えば、ユーザ入力、またはデバイスプロファイルの一部として伝播）で構成することができます。デバイスプロファイルと同様に、ユーザプロファイルの内容と伝播が展開シナリオに基づいて、異なっていてもよい（すなわち、同一のドメインに属するユーザができる - またはしないかもしれない - 同じプロファイルを提供すること）。サブスクリプションのURIを作成するには、以下のルールが適用されます。デバイスがユーザのAoRに要求-URIを設定しなければなりませんoを。
o The device MUST populate the From field with the user AoR.
Oデバイスは、ユーザのAoRとフィールドから移入しなければなりません。
An authoritative SIP proxy for a SIP provider's network that receives a profile enrollment request for the user profile type will route based on the Event Header field values, thus allowing a subscription to the user's AoR to be routed to the appropriate PDS.
したがって、ユーザーののAoRへのサブスクリプションは、適切なPDSにルーティングすることができ、イベントヘッダーフィールドの値に基づいて、ユーザプロファイルタイプの意志ルートのプロファイル登録要求を受けたSIPプロバイダーのネットワークに対して権限のSIPプロキシ。
Profile data can contain sensitive information that needs to be secured, such as identities and credentials. Security involves authentication, data integrity and data confidentiality. Authentication is the process by which you verify that an entity is who it claims to be, such as a user AoR presented during profile enrollment. Message integrity provides the assurance that the message contents transmitted between two entities, such as between the PDS and the device, has not been modified during transit. Privacy ensures that the message contents have not been subjected to monitoring by unwanted elements during transit. Authentication and data integrity are required to ensure that the profile contents were received by a valid entity, from a valid source, and without any modifications during transit. For profiles that contain sensitive data, data confidentiality is also required.
プロファイルデータは、IDや資格情報として、確保する必要がある機密情報を含むことができます。セキュリティ、認証、データの整合性とデータの機密性を必要とします。認証を使用すると、エンティティが、そのようなのAoRは、プロファイル登録時に提示されるユーザとして、それがあることを主張する人であることを確認するプロセスです。メッセージの完全性は、PDSとデバイスとの間のような2つのエンティティ間で送信されるメッセージの内容は、輸送中に変更されていないことの保証を提供します。プライバシー、メッセージの内容が転送中に不要な要素によりモニタリングに供されていないことを保証します。認証およびデータの整合性は、プロファイルの内容が有効なソースから、及び輸送中の任意の変更を加えることなく、有効なエンティティによって受信されたことを保証するために必要とされます。機密データが含まれているプロファイルの場合、データの機密性も必要です。
For an overview of potential security threats, refer to Section 9. For information on how the device can be configured with identities and credentials, refer to Section 5.3.1. The following subsections provide the security requirements associated with each profile delivery stage, and applies to each of profile types specified by this framework.
潜在的なセキュリティ上の脅威の概要については、デバイスは、5.3.1項を参照して、アイデンティティと資格情報を使用して設定することができます方法については、セクション9を参照してください。以下のサブセクションでは、各プロファイルの受け渡しステージに関連付けられたセキュリティ要件を提供し、このフレームワークによって指定されたプロファイルタイプのそれぞれに適用されます。
Profile enrollment may result in sensitive profile data. In such cases, the PDS MUST authenticate the device, except during the bootstrapping scenario when the device does not have existing credentials (see Section 5.3.1 for more information on bootstrapping). Additionally, the device MUST authenticate the PDS to ensure that it is obtaining sensitive profile data from a valid PDS.
プロフィール登録は敏感なプロファイルデータをもたらすことができます。このような場合には、PDSは、デバイスが、既存の資格情報を（ブートストラップの詳細については、5.3.1項を参照）を持っていない場合、ブートストラップのシナリオの間を除いて、デバイスを認証しなければなりません。さらに、デバイスは、それが有効なPDSから機密プロファイルデータを取得していることを確認するためにPDSを認証しなければなりません。
To authenticate a device that has been configured with identities and credentials, as specified in Section 5.3.1, and support profiles containing sensitive profile data (refer to Section 5.3.3), devices and PDSs MUST support digest authentication (over Transport Layer Security (TLS)) as specified in [RFC3261]. Future enhancements may
5.3.1項で指定されるように、アイデンティティと資格情報を使用して構成されているデバイス、および機密プロファイルデータを含むサポートプロファイル（セクション5.3.3参照）、デバイスを認証するとのPDSは、（トランスポート層セキュリティ上（ダイジェスト認証をサポートしなければなりません[RFC3261]で指定されるようにTLS））。将来の機能拡張してもよいです
provide other authentication methods such as authentication using X.509 certificates. For the device to authenticate the PDS, the device MUST mutually authenticate with the PDS during digest authentication (device challenges the PDS, which responds with the Authorization header). Transmission of sensitive profile data also requires data integrity. This can be accomplished by configuring the device with, or by ensuring that the discovery process during profile enrollment provides, a Session Initiation Protocol Secure (SIPS) URI resulting in TLS establishment ([RFC5246]). TLS also prevents offline dictionary attacks when digest authentication is used. Thus, in the absence of TLS, the device MUST NOT respond to any authentication challenges. It is to be noted that the digest credentials used for obtaining profile data via this framework may, or may not, be the same as those used for SIP registration (see Section 5.3.1). In addition, while [RFC3261] considers MD5 to be a reasonable choice to compute the hash, and this may have been true when [RFC3261] was published, implementers are recommended to use stronger alternatives such as SHA-256. Refer to [FIPS-180-3] and [RFC4634] for more information about SHA-256.
このようX.509証明書を使用して認証など他の認証方法を提供します。 PDSを認証するデバイスのために、デバイスは、互いに（デバイスがAuthorizationヘッダで応答PDSを、挑戦）ダイジェスト認証中PDSで認証しなければなりません。敏感なプロファイルデータの送信は、データの整合性が必要です。これは、でデバイスを構成することによって達成することができる、またはプロファイルの登録時の発見プロセスが提供することを保証することにより、セッション・イニシエーション・プロトコルは、TLSの確立をもたらす（SIPS）URI（[RFC5246]）を固定します。ダイジェスト認証を使用する場合、TLSは、オフライン辞書攻撃を防ぐことができます。このように、TLSのない状態で、デバイスは、任意の認証チャレンジに応じてはいけません。それは、あるいはないかもしれないが、SIP登録（セクション5.3.1を参照）のために使用されるものと同じであってもよく、このフレームワークを介してプロファイルデータを取得するために使用される資格情報をダイジェストことに留意すべきです。 [RFC3261]はMD5のハッシュを計算するために合理的な選択であることを考慮し、[RFC3261]が発表されたとき、これは本当だったかもしれないがまた、実装者は、SHA-256などの強力な代替手段を使用することをお勧めします。 SHA-256の詳細については、[FIPS-180-3]と[RFC4634]を参照。
When the PDS challenges a profile enrollment request, and it fails, the PDS MAY refuse enrollment or provide profile data without the user-specific information (e.g., to bootstrap a device as indicated in Section 5.3.1). If the device challenges, but fails to authenticate the PDS, it MUST reject the initial notification and retry the profile enrollment process. If the device is configured with, or discovers, a SIPS URI but TLS establishment fails because the next-hop SIP entity does not support TLS, the device SHOULD attempt other resolved next-hop SIP entities. When the device establishes TLS with the next-hop entity, the device MUST use the procedures specified in [RFC2818], Section 3.1, for authentication, unless it does not have any configured information (e.g., certification authority (CA) certificate) to perform authentication (like prior to bootstrapping). The 'Server Identity' for authentication is always the domain of the next-hop SIP entity. If the device attempts validation, and it fails, it MUST reject the initial notification and retry profile enrollment. In the absence of a SIPS URI for the device and a mechanism for mutual authentication, the PDS MUST NOT present any sensitive profile data in the initial notification, except when the device is being bootstrapped. It MAY still use content indirection to transmit sensitive profile data.
PDSは、プロファイル登録要求に挑戦し、それが失敗した場合、PDSは登録を拒否またはユーザ固有の情報（セクション5.3.1に示すように、例えば、デバイスをブートストラップする）ことなく、プロファイルデータを提供することができます。デバイス上の課題が、が、PDSの認証に失敗した場合、それは最初の通知を拒否し、プロファイルの登録プロセスを再試行しなければなりません。デバイスはで構成され、または発見された場合は、SIPS URIが、TLS確立は失敗し、ネクストホップSIPエンティティはTLSをサポートしていないため、デバイスは、他の解決ネクストホップSIPエンティティを試みるべきです。デバイスは、ネクストホップエンティティとTLSを確立すると、それは、任意の構成情報を持っていない場合を除き、デバイスは、認証のために、[RFC2818]、セクション3.1で指定された手順を使用しなければなりません（例えば、証明機関（CA）証明書）を実行します認証（ブートストラップ前のように）。認証のための「サーバーIDは、」常にネクストホップSIPエンティティのドメインです。デバイスは、検証を試み、それが失敗した場合は、最初の通知を拒否し、プロファイル登録を再試行しなければなりません。デバイスと相互認証のためのメカニズムのためのSIPS URIの非存在下で、PDSは、デバイスがブートストラップされている場合を除いて、最初の通知に機密プロファイルデータを提示してはいけません。それはまだ敏感なプロファイルデータを送信するために、コンテンツ間接を使用するかもしれません。
When a device is being provided with bootstrapping profile data within the notification, and it contains sensitive information, the SIP Identity header SHOULD be used, as specified in [RFC4474]. This helps with devices that MAY be pre-configured with certificates to validate bootstrapping sources (e.g., list of allowed domain certificates, or a list of root CA certificates using Public Key
デバイスは、通知内のブートストラップ・プロファイル・データが提供され、それは機密情報が含まれている場合、[RFC4474]で指定されるように、SIP Identityヘッダを使用すべきです。これは、ブートストラップソースを検証するための証明書（例えば、許可されたドメインの証明書のリスト、または公開鍵を使用して、ルートCA証明書のリストで事前に構成されているデバイスに役立ちます
Infrastructure (PKI)). When the SIP Identity header is used, the PDS MUST set the host portion of the AoR in the From header to the Provider's domain (the user portion is a entity-specific identifier). If the device is capable of validating the SIP Identity, and it fails, it MUST reject bootstrapping profile data.
インフラストラクチャ（PKI））。 SIP Identityヘッダを使用する場合、PDSは、プロバイダのドメインにヘッダからのAoRのホスト部分を設定しなければなりません（ユーザ部分は、エンティティ固有の識別子です）。デバイスは、SIPアイデンティティを検証することができ、それが失敗した場合は、ブートストラップ・プロファイル・データを拒絶しなければなりません。
Initial or change notifications following a successful enrollment can provide a device with the requested profile data or use content indirection to direct it to a PCC that can provide the profile data. This document specifies HTTP and HTTPS as content retrieval protocols.
成功の登録を以下の初期または変更通知が要求されたプロファイルデータをデバイスに提供したり、プロファイルデータを提供することができますPCCにそれを指示するコンテンツ間接を使用することができます。この文書では、コンテンツ検索プロトコルとしてHTTPとHTTPSを指定します。
If the profile is provided via content indirection and contains sensitive profile data, then the PDS MUST use a HTTPS URI for content indirection. PCCs and devices MUST NOT use HTTP for sensitive profile data, except for bootstrapping a device via the device profile. A device MUST authenticate the PCC as specified in [RFC2818], Section 3.1. A device that is being provided with profile data that contains sensitive data MUST be authenticated using digest authentication as specified in [RFC2617], with the exception of a device that is being bootstrapped for the first time via the device profile. The resulting TLS channel also provides data integrity and data confidentiality.
プロファイルは、コンテンツ間接を介して提供し、機密プロファイルデータが含まれている場合、PDSは、コンテンツ間接のためのHTTPS URIを使用しなければなりません。 PCCとデバイスはデバイスプロファイルを介してデバイスをブートストラップを除き、機密プロファイルデータのためにHTTPを使用してはなりません。 [RFC2818]で指定されるように、デバイスは、セクション3.1をPCCを認証する必要があります。機密データを含むプロファイルデータを備えているデバイスは、デバイスプロファイルを介して最初にブートストラップされているデバイスを除いて、[RFC2617]で指定されるようにダイジェスト認証を使用して認証されなければなりません。その結果TLSチャネルはまた、データの整合性と機密性を提供します。
If the device requested enrollment via a SIP subscription with a non-zero 'Expires' parameter, it can also result in change notifications for the duration of the subscription. For change notifications containing sensitive profile data, this framework RECOMMENDS the use of the SIP Identity header as specified in [RFC4474]. When the SIP Identity header is used, the PDS MUST set the host portion of the AoR in the From header to the Provider's domain (the user portion is a entity-specific identifier). This provides header and body integrity as well. However, for sensitive profile data requiring data confidentiality , if the contact URI to which the NOTIFY request is to be sent is not SIPS, the PDS MUST use content indirection. Additionally, the PDS MUST also use content indirection for notifications containing sensitive profile data, when the profile enrollment was not authenticated.
デバイスは、パラメータを「有効期限」非ゼロのSIPサブスクリプションを経由して登録を要求した場合、それはまた、サブスクリプションの期間変更通知をもたらす可能性があります。感受性プロファイルデータを含む変更通知のために、このフレームワークは[RFC4474]で指定されるようにSIP Identityヘッダの使用を推奨しています。 SIP Identityヘッダを使用する場合、PDSは、プロバイダのドメインにヘッダからのAoRのホスト部分を設定しなければなりません（ユーザ部分は、エンティティ固有の識別子です）。これは、同様に、ヘッダとボディ完全性を提供します。敏感なプロファイルデータは、データの機密性を要求するためのコンタクトURI要求を通知するれる場合は、送信されるべきであることはSIPSない、PDS、コンテンツ間接参照を使用しなければなりません。また、PDSは、プロファイルの登録が認証されていなかった敏感なプロファイルデータを含む通知の内容間接を、使用しなければなりません。
This section provides additional considerations, such as details on how a device obtains identities and credentials, back-off and retry methods, guidelines on profile data, and additional profile types.
このセクションでは、このようなデバイスは、アイデンティティと資格情報、バックオフを取得し、メソッドを再試行してください方法の詳細は、プロファイルデータ上のガイドライン、および追加のプロファイルの種類などの追加の考慮事項を、提供します。
When requesting a profile, the profile delivery server will likely require the device to provide an identity (i.e., a user AoR) and associated credentials for authentication. During this process (e.g., digest authentication), the PDS is also required to present its knowledge of the credentials to ensure mutual authentication (see Section 5.2.1). For mutual authentication with the PDS, the device needs to be provided with the necessary identities and credentials (e.g., username/password, certificates). This is done via bootstrapping. For a discussion around the security considerations related to bootstrapping, please see Section 9.2.
プロファイルを要求するとき、プロファイル配信サーバは、おそらく同一（すなわち、ユーザAOR）と認証のための関連する資格情報を提供する装置を必要とします。このプロセスの間（例えば、ダイジェスト認証）、PDSはまた、（セクション5.2.1を参照）、相互認証を保証するために、資格情報の知識を提示する必要があります。 PDSとの相互認証のために、デバイスは、必要なアイデンティティと資格情報（例えば、ユーザ名/パスワード、証明書）を設ける必要があります。これは、ブートストラップを介して行われます。ブートストラップに関連するセキュリティ上の考慮事項の周りの議論については、9.2節を参照してください。
Bootstrapping a device with the required identities and credentials can be accomplished in one of the following ways:
次のいずれかの方法で行うことができる必要アイデンティティと資格情報を使用してデバイスをブートストラップ：
Pre-configuration The device may be pre-configured with identities and associated credentials, such as a user AoR and digest password.
事前設定デバイスは、アイデンティティと、ユーザのAoRなどの関連資格情報と予め設定されたパスワードを消化することができます。
Out-of-band methods A device or Provider may provide hardware- or software-based credentials such as Subscriber Identity Module (SIM) cards or Universal Serial Bus (USB) drives.
アウトオブバンド方法は、デバイスまたはプロバイダは、加入者識別モジュール（SIM）カードまたはユニバーサルシリアルバス（USB）ドライブなどのハードウェアまたはソフトウェアベースの資格情報を提供することができます。
End-user interface The end-user may be provided with the necessary identities and credentials. The end-user can then configure the device (using a user interface), or present when required (e.g., IM login screen).
エンドユーザは、エンドユーザが必要なアイデンティティと資格情報を提供することができるインタフェース。 （例えば、IMログイン画面）必要な場合、エンドユーザは、次いで、（ユーザインターフェイスを使用して）デバイスを設定する、または存在することができます。
Using this framework When a device is initialized, even if it has no pre-configured information, it can request the local-network and device profiles. For purposes of bootstrapping, this framework recommends that the device profile provide one of the following to bootstrap the device:
デバイスは、それが事前に設定情報を持っていない場合であっても、初期化され、このフレームワークを使用して、ローカルネットワークおよびデバイスプロファイルを要求することができます。ブートストラップの目的のために、このフレームワークは、デバイスプロファイルは、デバイスをブートストラップするために、次のいずれかを提供することをお勧めします。
* Profile data that allows the end-user to communicate with the device provider or SIP service provider using non-SIP methods. For example, the profile data can direct the end-user to a web portal to obtain a subscription. Upon obtaining a successful subscription, the end-user or the device can be provided with the necessary identities and credentials.
*エンドユーザが非SIPメソッドを使用して、デバイスプロバイダまたはSIPサービスプロバイダと通信することを可能にするプロファイルデータ。例えば、プロファイルデータは、サブスクリプションを取得するためのWebポータルにエンドユーザーに指示することができます。成功したサブスクリプションを取得すると、エンドユーザまたはデバイスは、必要なIDおよび資格情報を提供することができます。
* Content indirection information to a PCC that can provide identities and credentials. As an example, consider a device that has an X.509 certificate that can be authenticated by the PCC. In such a case, the PCC can use HTTPS to provide identities and associated credentials.
*アイデンティティと資格情報を提供することができますPCCのコンテンツ間接情報。一例として、PCCによって認証することができるX.509証明書を有するデバイスを考えます。このような場合に、PCCは、アイデンティティと関連する認証情報を提供するために、HTTPSを使用することができます。
* Profile data containing identities and credentials that can be used to bootstrap the device (see Section 5.3.3 for profile data recommendations). This can be used in cases where the device is initialized for the first time, or after a factory reset. This can be considered only in cases where the device is initialized in the Provider's network, for obvious security reasons.
デバイスをブートストラップするために使用することができアイデンティティと資格情報を含む*プロファイル・データ（プロファイルデータの推奨事項については、セクション5.3.3を参照してください）。これは、デバイスが最初に初期化される場合に、または工場出荷時の状態にリセットした後に使用することができます。これが唯一のデバイスは、明らかなセキュリティ上の理由から、プロバイダーのネットワークに初期化される場合に考慮することができます。
For interoperability purposes, this framework requires PDSs and devices to support the last option (above), which is to use this framework. Specifically, the option of providing identities and credentials via the profile data MUST be supported.
相互運用性のために、このフレームワークは、このフレームワークを使用することで、最後のオプションを（上記）、サポートするためのPDSとデバイスを必要とします。具体的には、プロファイルデータを経由してのアイデンティティと資格情報を提供するオプションをサポートしなければなりません。
Additionally, AoRs are typically known by PDSs that serve the domain indicated by the AoR. Thus, devices can only present the configured AoRs in the respective domains. An exception is the use of federated identities. This allows a device to use a user's AoR in multiple domains. Further even within the same domain, the device's domain proxy and the PDS may be in two different realms, and as such may be associated with different credentials for digest authentication. In such cases, multiple credentials may be configured, and associated with the realms in which they are to be used. This framework specifies only digest authentication for profile enrollment and the device is not expected to contain any other credentials. For profile retrieval using content indirection, the device will need to support additional credentials such as X.509 certificates (for TLS). Future enhancements can specify additional credential types for profile enrollment and retrieval.
また、のAORは、典型的には、のAoRで示すドメインを提供するPDSで知られています。したがって、デバイスは、それぞれのドメイン内のAOR構成を提示することができます。例外は、フェデレーションIDの使用です。これは、デバイスが複数のドメインでユーザーののAoRを使用することができます。さらにでも同じドメイン内に、デバイスのドメインプロキシとPDSは、二つの異なるレルムであってもよく、そのようにダイジェスト認証のため異なる証明書に関連付けられてもよいです。このような場合には、複数の資格情報を構成することができる、及びそれらが使用されるべきレルムに関連付けられました。このフレームワークは、プロファイルの登録とデバイスが他の認証情報を含むことが期待されていないためにダイジェスト認証を指定します。コンテンツ間接参照を使用してプロファイルの検索のため、装置は、（TLS用）X.509証明書などの追加の資格情報をサポートする必要があります。将来の機能拡張は、プロファイルの登録と検索のために追加のクレデンシャルタイプを指定することができます。
A state diagram representing a device requesting any specific profile defined by this framework is shown in Figure 6.
このフレームワークによって定義された特定のプロファイルを要求しているデバイスを表す状態図が図6に示されています。
+------------+
| Initialize |
+-----+------+
|
|
V
+-------------+
| Prepare |
+--------->| Enrollment |<------------------+
| | Request | |
| +------+------+ |
+------+------+ | |
| Failure | Enroll. Req. prepared |
+-->| Handling & | /Send Req |
| | Delay | | |
| +-------------+ V |
| ^ ^ +-------------+ |
| | | | Await | |
| | +--------+ Enrollment | |
| | Timeout, | acceptance | |
| | non-2xx/- +------+------+ |
| | | |
| Timeout 200 OK/- Enrollment
| /Terminate | Timeout/-
| Enrollment V |
| | +--------------+ |
| | | Enrollment | |
| +------------+ accepted | |
Retries Exceeded |(await NOTIFY)| |
/Retry Enrollment +---+------+---+ |
| | | |
| | | |
| NOTIFY w. Content Ind| | NOTIFY w. Profile |
| /Retrieve Profile | | /Accept Profile |
| +------------+ +------------+ |
| | | |
| V V |
| +------------+ +------------+ |
+-----+ Retrieving | Retrieved | Enrollment +---+
,->| Profile +--/Apply Profile-->| Successful |
/ | | |(monitoring)|<--.
Timeout +--+---------+ +--+----+----+ :
/Retry ; ^ | : ;
`------' | NOTIFY w. Cont.Ind | `-------'
+---/Retrieve Profile-----+ NOTIFY w. Profile
/Apply Profile
Figure 6: Device State Diagram
図6：デバイス状態図
As a reminder:
リマインダとして：
o The timeout for SIP messages is specified by [RFC3261]. In the cases where this is not specified such as the timeout to wait for the initial notification during profile enrollment, it is left to device implementations or future protocol enhancements.
O SIPメッセージのタイムアウトは[RFC3261]で指定されています。これは、そのようなプロファイル登録時に最初の通知を待つタイムアウトとして指定されていない場合には、デバイスの実装または将来のプロトコルの拡張に委ねられます。
o The timeout for profile retrieval using content indirection will be as specified by profile retrieval protocols employed. If none exists, it is left to device implementations.
O含有量インダイレクションを使用してプロファイルを検索するためのタイムアウトは使用プロファイル検索プロトコルによって指定されるように。が存在しない場合は、デバイスの実装に任されています。
In addition, since profile enrollment is a process unique to this framework, the device MUST follow the enrollment attempt along with exponential back-off and retry mechanisms as indicated in Figure 7.
また、プロファイル登録が、このフレームワークに固有の処理であるため、デバイスは、指数バックオフと共に、登録の試みに従わなければならなくて、図7に示されるように機構を再試行します。
Function for Profile Enrollment ()
プロファイル登録のための機能（）
Init Function: Iteration i=0
init関数：反復I = 0
Loop 1: Attempt
ループ1：試み
Loop 2: For each SIP Subscription URI
ループ2：各SIP URIのサブスクリプションのために
Loop 3: For each next-hop SIP entity
ループ3：各次ホップSIPエンティティの
- Prepare and transmit Enrollment Request
- 準備し、登録要求を送信します
- Await Enrollment Acceptance and initial NOTIFY
- 待っ入学受け入れ、初期には、NOTIFY
+ If the profile enrollment is successful = Exit this function()
プロフィールの登録が成功した場合は+ =）（この機能を終了します
+ If profile enrollment fails due to an explicit failure or a timeout as specified in [RFC3261] = Continue with the next-hop SIP entity (Loop 3)
+ [RFC3261]で指定されたプロファイル登録が原因明示的な故障またはタイムアウトに失敗した場合=ネクストホップSIPエンティティ（ループ3）に進み
End Loop: Loop 3
エンドループ：ループ3
End Loop: Loop 2
エンドループ：ループ2
(Note: If you are here, profile enrollment did not succeed)
（注意：あなたがここにいる場合は、プロフィール登録が成功しませんでした）
+ Is any valid cached profile data available? = If yes, use it and continue with Loop 1
+任意の有効なキャッシュされたプロファイルデータはありますか？ =はい、それを使用し、ループ1を続行した場合
+ If the enrollment request is for a non-mandatory profile = Start profile enrollment for the next profile, if applicable
登録要求は、非必須プロファイルのためであれば該当する場合は+ =、次のプロファイルのプロファイル登録を開始します
- Delay for 2^i*(64*T1); -- this is exponential back-off
- ディレイ2のために^私は（64 * T1）*; - これは、指数バックオフであります
- increment i;
- 私をインクリメントします。
- If i>8, reset i=8;
- i>は8、Iをリセットした場合= 8;
End loop: Loop 1
エンドループ：ループ1
End Function()
エンド機能（）
Figure 7: Profile Enrollment Attempt (Pseudo-Code)
図7：プロファイル登録の試み（擬似コード）
The pseudo-code above (Figure 7) allows for cached profiles to be used. However, any cached local-network profile MUST NOT be used unless the device can ensure that it is in the same local network that provided the cached data. This framework does not provide any procedures for local network recognition. Any cached device and user profiles MUST only be used in domains with which they are associated. For example, a cached device profile is used only when the associated domain matches the current device provider's domain. If a PDS wants to invalidate a profile it may do so by transmitting a NOTIFY with an 'empty profile', i.e., profile instance without any included data (if supported by the profile data model; not to be confused with an empty NOTIFY), or via an explicit profile data element that invalidates the data. A device receiving such a NOTIFY MUST discard the applicable profile (i.e., it cannot even store it in the cache). Additionally, if a factory reset is available and performed on a device, it MUST reset the device to its initial state prior to any configuration. Specifically, the device MUST set the device back to the state when it was originally distributed.
（図7）は、上記の擬似コードは、使用されるキャッシュされたプロファイルを可能にします。ただし、キャッシュされたローカル・ネットワークプロファイルは、それがキャッシュされたデータを提供し、同じローカルネットワークにあることを確認することができる装置がない限り使用してはいけません。このフレームワークは、ローカルネットワークの認識のためのいずれかの手順を提供しません。キャッシュされたデバイスとユーザプロファイルは、それらが関連付けられているドメインで使用されなければなりません。たとえば、キャッシュされたデバイスプロファイルが関連付けられているドメインが現在のデバイスプロバイダのドメインと一致した場合にのみ使用されます。 PDSは、それが空のプロファイル」でNOTIFY送信することによってそれを行うことができるプロファイルを無効にしたい場合（プロファイルデータモデルでサポートされている場合、NOTIFYは空と混同しないように）、すなわち、どのなしのプロファイルのインスタンスは、データが含まれ、またはデータを無効に明示的なプロファイルデータ要素を経由して。そのようなNOTIFY受信装置が適用可能なプロファイル（すなわち、それもキャッシュに格納することができない）、捨てなければなりません。ファクトリリセットが利用可能であり、デバイス上で実行される場合に加えて、それは、任意の構成の前に初期状態にデバイスをリセットする必要があります。それは元々、分散されたとき、具体的に、デバイスは、バック状態にデバイスを設定しなければなりません。
The order of profile enrollment is important. For the profiles specified in this framework, the device MUST enroll in the following default order: local network, device, and user. The pseudo-code presented earlier (Figure 7) differentiates between 'mandatory' and 'non-mandatory' profiles. This distinction is left to profile data definitions.
プロファイル登録の順序は重要です。ローカルネットワーク、デバイス、およびユーザー：この枠組みの中で指定されたプロファイルの場合、デバイスは、次のデフォルトの順に加入しなければなりません。先に提示した擬似コード（図7）は、「必須」と「非必須」プロファイルを区別する。この区別は、データ定義をプロファイルする残っています。
It is to be noted that this framework does not allow the devices to inform the PDSs of profile retrieval errors such as invalid data. Follow-on standardization activities are expected to address this feature.
これは、このフレームワークは、デバイスは無効なデータとして、プロファイル取得エラーののPDSを通知することができないことに注意すべきです。後続の標準化活動は、この機能に対応することが期待されています。
This framework does not specify the contents for any profile type. Follow-on standardization activities are expected to address profile contents. However, the framework provides the following requirements and recommendations for profile data definitions:
このフレームワークは、任意のプロファイルタイプの内容を指定しません。後続の標準化活動は、プロファイルの内容に対処することが期待されています。しかし、フレームワークは、プロファイルデータの定義については、以下の要件および推奨事項を提供します。
o The device profile type SHOULD specify parameters to configure the identities and credentials for use in scenarios such as bootstrapping (see Section 5.3.1) and run-time modifications to identities and credentials. This framework recommends the device profile provide the identities and credentials due to a couple of reasons. The local-network profile may not always be available, and even if present, may not be controlled by the device provider who controls device configuration to provide services. Further, the device may not have any users configured prior to being bootstrapped, resulting in an absence of user profile requests.
Oデバイスプロファイルタイプは、ブートストラップなどのシナリオで使用するための識別情報と認証情報を設定するためのパラメータを指定する必要があります（セクション5.3.1を参照）、実行時の変更を識別し、信任状に。このフレームワークは、デバイスプロファイルが原因の理由のカップルにアイデンティティと資格情報を提供するお勧めします。ローカル・ネットワークプロファイルは、常に利用可能ではないかもしれない、とさえ存在する場合、サービスを提供するために、デバイス構成を制御するデバイスプロバイダによって制御されない場合があります。さらに、デバイスは、ユーザプロファイル要求の不在下で得られた、ブートストラップされる前に構成された任意のユーザーを有していなくてもよいです。
However, this framework does not prevent other profile types from providing identities and credentials to meet deployment needs. For example, the user profile can contain identities and credentials for communicating with specific applications.
しかし、このフレームワークは、展開のニーズを満たすためにアイデンティティと資格情報を提供するから、他のプロファイルの種類を防ぐことはできません。例えば、ユーザプロファイルは、特定のアプリケーションと通信するためのIDと認証情報を含めることができます。
o Each profile MUST clearly identify if it may contain any sensitive data. Such profiles MUST also identify the data elements that are considered sensitive, i.e., data that cannot be disclosed to unauthorized parties. As an example, a device profile definition may identify itself as containing sensitive data and indicate data such as device credentials to be sensitive.
それは機密データが含まれている可能性がある場合、O各プロファイルは、明確に特定しなければなりません。そのようなプロファイルはまた、権限のない者に開示することができない、すなわち、データを感受性であると考えられるデータ要素を識別しなければなりません。一例として、デバイスプロファイル定義は、機密データを含むものとして自分自身を識別し、そのようなデバイス認証情報などのデータが機密であることを示すことができます。
o When the device receives multiple profiles, the contents of each profile type SHOULD only contain data relevant to the entity it represents. As an example, consider a device that obtains all the defined profiles. Information pertaining to the local network is contained in the 'local-network' profile and not the 'user' profile. This does not preclude relevant data about a different entity from being included in a profile type, e.g., the 'device' profile type may contain information about the users allowed to access services via the device. A profile may also contain starting information to obtain subsequent profiles.
デバイスが複数のプロファイルを受信すると、O、各プロファイルタイプの内容は、それが表すエンティティに関連するデータを含むべきです。例として、すべての定義されたプロファイルを取得し、デバイスを考えます。ローカルネットワークに関連する情報は、「ローカルネットワークのプロファイルではなく「ユーザーのプロファイルに含まれています。これは、例えば、「デバイス」プロファイルタイプが装置を介してサービスにアクセスすることを許可されたユーザーに関する情報を含んでいてもよい、プロファイル・タイプに含まれる異なるエンティティに関する関連データを排除するものではありません。プロファイルはまた、後続のプロファイルを取得するために起動情報を含むことができます。
o Data overlap SHOULD be avoided across profile types, unless necessary. If data overlap is present, prioritization of the data is left to data definitions. As an example, the device profile may contain the list of codecs to be used by the device and the user profile (for a user on the device) may contain the codecs preferred by the user. Thus, the same data (usable codecs) is present in two profiles. However, the data definitions may indicate that, to function effectively, any codec chosen for communication needs to be present in both the profiles.
必要でない限り、Oデータの重複は、プロファイルタイプで避けるべきです。データの重複が存在する場合、データの優先順位付けは、データ定義に残されます。一例として、デバイスプロファイルは、デバイスが使用するコーデックのリストを含んでいてもよく、（デバイス上のユーザの）ユーザプロファイルは、ユーザの好みのコーデックを含んでいてもよいです。したがって、同じデータ（使用可能なコーデック）は、2つのプロファイルに存在します。しかし、データの定義が有効に機能するために、それを示すことができる、通信のために選択された任意のコーデックは、プロファイルの両方に存在する必要があります。
The framework specified in this document does not address profile data representation, storage, or retrieval protocols. It assumes that the PDS has a PCC based on existing or other Profile Data Frameworks.
この文書で指定されたフレームワークは、プロファイルデータ表現、保管、または検索プロトコルに対処していません。これは、PDSは、既存または他のプロファイル・データ・フレームワークに基づいてPCCを持っていることを前提としています。
While this framework does not impose specific constraints on any such framework, it does allow for the propagation of profile content to the PDS (specifically the PCC). Thus, Profile Data Frameworks or retrieval frameworks used in conjunction with this framework MAY consider techniques for propagating incremental, atomic changes to the PDS. One means for propagating changes to a PDS is XML Configuration Access Protocol (XCAP) ([RFC4825]).
このフレームワークは、任意のそのようなフレームワークに特定の制約を課していないが、それはPDS（具体PCC）のプロファイルコンテンツの伝播を可能にするん。従って、このフレームワークに関連して使用されるプロファイルデータフレームワーク又は検索フレームワークは、PDSに増分、アトミック変更を伝播するための技術を考慮することができます。一つは、PDSに変更を伝播するための手段とXMLコンフィギュレーションアクセスプロトコル（XCAP）（[RFC4825]）です。
This document specifies three profile types: local-network, device, and user. However, there may be use cases for additional profile types. e.g., profile types for application specific profile data or to provide enterprise-specific policies. Definition of such additional profile types is not prohibited, but considered out of scope for this document. Such profile definitions MUST specify the order of retrieval with respect to all the other profiles such as the local-network, device, and user profile types defined in this document.
ローカル・ネットワーク、デバイス、およびユーザー：この文書では、3種類のプロファイルを指定します。しかし、追加のプロファイルタイプのためのユースケースがあるかもしれません。例えば、アプリケーション固有プロファイルデータのプロファイルタイプまたは企業固有のポリシーを提供することを目的とします。このような追加のプロファイルタイプの定義は禁止されますが、この文書の範囲外と見なされていません。そのようなプロファイル定義は、この文書で定義されたローカルネットワーク、デバイス、およびユーザ・プロファイル・タイプのような他のすべてのプロファイルに対して検索の順序を指定しなければなりません。
The framework defined in this document was designed to address various deployment considerations, some of which are highlighted below.
この文書で定義されたフレームワークは、以下の強調表示されているそのうちのいくつかは、さまざまな展開の考慮事項に対処するために設計されました。
Provider relationships:
プロバイダとの関係：
o The local network provider and the SIP service provider can often be different entities, with no administrative or business relationship with each other.
OローカルネットワークプロバイダおよびSIPサービスプロバイダは、多くの場合、互いに無行政やビジネス関係と異なる構成要素にすることができます。
o There may be multiple SIP service providers involved, one for each service to which a user subscribes (telephony service, instant messaging, etc.); this framework does not specify explicit behavior in such a scenario, but it does not prohibit its usage either.
O、ユーザーが加入（電話サービス、インスタントメッセージング、等）に、各サービスに対して1つの関与する複数のSIPサービスプロバイダが存在してもよいです。このフレームワークは、このようなシナリオでは、明示的な動作を指定しませんが、それはどちらか、その使用を禁止するものではありません。
o Each user accessing services via the same device may subscribe to different sets of services, from different service providers.
O同じデバイスを介してサービスにアクセスする各ユーザーは、異なるサービスプロバイダから、サービスの異なるセットに加入することができます。
User-device relationship:
ユーザーデバイスの関係：
o The relationship between devices and users can be many-to-many (e.g., a particular device may allow for many users to obtain subscription services through it, and individual users may have access to multiple devices).
Oデバイスとユーザとの間の関係は、多対多の（多くのユーザーがそれを介してサブスクリプション・サービスを取得するなど、特定のデバイスが可能に、かつ個々のユーザが複数のデバイスへのアクセスを有していてもよい）とすることができます。
o Each user may have different preferences for use of services, and presentation of those services in the device user interface.
O各ユーザーは、デバイスのユーザーインターフェイスでサービスの利用、およびそれらのサービスの提供のために異なる嗜好を持っていることがあります。
o Each user may have different personal information applicable to use of the device, either as related to particular services, or independent of them.
Oの各ユーザは、いずれかとして特定のサービスに関連する、またはそれらの独立した装置の使用に適用可能な別の個人情報を有していてもよいです。
PDSs that support devices behind NATs, and devices that can be behind NATs can use procedures specified in [RFC5626]. The Outbound proxies can be configured or discovered. Clients that support such behavior MUST include the 'outbound' option-tag in a Supported header field value, and add the "ob" parameter, as specified in [RFC5626], within the SIP SUBSCRIBE for profile enrollment.
NATの背後にあることができるNATの背後にあるデバイスをサポートするのPDS、およびデバイスは、[RFC5626]で指定された手順を使用することができます。アウトバウンドプロキシが設定されるか、または発見することができます。このような現象は、サポートされているヘッダフィールド値に「送信」オプションタグを含み、そして「OB」パラメータを追加しなければならないサポートするクライアントは、[RFC5626]で指定されるように、SIP内のプロファイル登録のためのSUBSCRIBE。
The framework specified in this document proposes and specifies a new SIP event package, as allowed by [RFC3265]. The purpose is to allow for devices to subscribe to specific profile types with PDSs and for the PDSs to notify the devices with the profile data or content indirection information.
[RFC3265]で許可されているとして、この文書で指定されたフレームワークは、新しいSIPイベントパッケージを提案して指定します。目的は、デバイスプロファイルデータまたはコンテンツ間接情報をデバイスに通知するためのPDSのPDSを有するとのための特定のプロファイル・タイプにサブスクライブすることを可能にすることです。
The requirements specified in [RFC3265] apply to this package. The following subsections specify the event package description and the associated requirements. The framework requirements are defined in Section 5.
[RFC3265]で指定された要件は、このパッケージに適用されます。以下のサブセクションでは、イベントパッケージの説明と関連する要件を指定します。フレームワークの要件は、第5節で定義されています。
The name of this package is "ua-profile". This value appears in the Event header field present in SUBSCRIBE and NOTIFY requests for this package, as defined in [RFC3265].
このパッケージの名前は「UA-プロファイル」です。この値は[RFC3265]で定義されるように、このパッケージのSUBSCRIBE及びNOTIFYリクエスト中に存在するイベントヘッダフィールドに現れます。
This package defines the following new parameters for the event header:
このパッケージには、イベントヘッダーのため、次の新しいパラメータを定義します。
"profile-type", "vendor", "model", "version", and "effective-by"
「プロファイル・タイプ」、「ベンダー」、「モデル」、「バージョン」、および「有効バイ」
The following rules apply:
次の規則が適用されます。
o All the new parameters, with the exception of the "effective-by" parameter, MUST only be used in SUBSCRIBE requests and ignored if they appear in NOTIFY requests.
Oすべての新しいパラメータは、「効果的なバイ」パラメータを除いて、唯一のSUBSCRIBEリクエストで使用されると、彼らはNOTIFY要求で表示された場合に無視しなければなりません。
o The "effective-by" parameter is for use in NOTIFY requests only and MUST be ignored if it appears in SUBSCRIBE requests.
「効果的なバイ」パラメータoをすることだけNOTIFYリクエストをし、それがSUBSCRIBEリクエストに表示された場合は無視されなければならないで使用するためのものです。
The semantics of these new parameters are specified in the following subsections.
これらの新しいパラメータの意味は以下のサブセクションで指定されています。
The "profile-type" parameter is used to indicate the token name of the profile type the user agent wishes to obtain and to be notified of subsequent changes. This document defines three logical types of profiles and their token names. They are as follows:
「プロファイル・タイプ」パラメータは、ユーザエージェントを取得し、その後の変更を通知することを希望するプロファイル・タイプのトークンの名前を示すために使用されます。この文書では、3つのプロファイルの論理型とそのトークン名を定義します。それらは次の通りです：
local-network: specifying the "local-network" type profile indicates the desire for profile data, and potentially, profile change notifications specific to the local network.
ローカル・ネットワーク：「ローカルネットワーク」タイプのプロファイルを指定するプロファイルデータのための欲求を示しており、潜在的に、ローカルネットワークに特定のプロファイルの変更通知。
device: specifying the "device" type profile(s) indicates the desire for the profile data, and potentially, profile change notification that is specific to the device or user agent.
デバイス：「デバイス」型プロファイル（複数可）を指定するプロファイルデータのための欲求を示し、そして潜在的に、デバイスまたはユーザエージェントに固有のプロファイル変更通知。
user: specifying the "user" type profile indicates the desire for the profile data, and potentially, profile change notification specific to the user.
ユーザ：「ユーザー」タイプのプロファイルを指定するには、潜在的に、プロファイルデータのための欲求、及び、ユーザに固有のプロファイル変更通知を示しています。
The profile type is identified in the Event header parameter: "profile-type". A separate SUBSCRIBE dialog is used for each profile type. Thus, the subscription dialog on which a NOTIFY arrives implies which profile's data is contained in, or referred to, by the NOTIFY message body. The Accept header of the SUBSCRIBE request MUST include the MIME types for all profile content types for which the subscribing user agent wishes to retrieve profiles, or receive change notifications.
「プロファイル・タイプ」：プロファイルタイプは、イベント・ヘッダパラメータで識別されます。別SUBSCRIBEダイアログは、各プロファイルタイプのために使用されます。このように、NOTIFYれているサブスクリプション]ダイアログボックスが到着した意味プロファイルのデータはに含まれている、またはNOTIFYメッセージのボディにより、参照されます。 SUBSCRIBE要求のAcceptヘッダーは、サブスクライブユーザエージェントプロファイルを取得する、または変更通知を受信することを希望するすべてのプロファイルのコンテンツタイプのMIMEタイプを含まなければなりません。
In the following syntax definition using ABNF, EQUAL and token are defined in [RFC3261]. It is to be noted that additional profile types may be defined in subsequent documents.
ABNF、EQUALとトークンを使用して、次の構文定義に[RFC3261]で定義されています。これは、追加のプロファイルタイプが、その後のドキュメントで定義されることに留意すべきです。
Profile-type = "profile-type" EQUAL profile-value profile-value = profile-types / token profile-types = "device" / "user" / "local-network"
プロファイル・タイプ=「プロファイル型」EQUALプロファイル値プロファイル値=プロファイルタイプ/トークン・プロファイル・タイプ=「デバイス」/「ユーザ」/「ローカルネットワーク」
The "device", "user", or "local-network" token in the profile-type parameter may represent a class or set of profile properties. Follow-on standards defining specific profile contents may find it desirable to define additional tokens for the profile-type parameter. Also, additional content types may be defined along with the profile formats that can be used in the Accept header of the SUBSCRIBE to filter or indicate what data sets of the profile are desired.
プロファイルタイプパラメータの「デバイス」、「ユーザ」、または「ローカルネットワーク」トークンは、プロファイルプロパティのクラスまたはセットを表すことができます。特定のプロファイルの内容を定義するフォローの基準は、それが望ましいプロファイル型パラメータの追加のトークンを定義することをお薦めします。また、追加コンテンツタイプがフィルタリングまたはプロファイルのセットが望まれるどのようなデータを示すために、SUBSCRIBEのAcceptヘッダーに使用することができるプロファイルフォーマットとともに定義することができます。
The "vendor", "model", and "version" parameter values are tokens specified by the implementer of the user agent. These parameters MUST be provided in the SUBSCRIBE request for all profile types. The implementer SHOULD use their DNS domain name (e.g., example.com) as the value of the "vendor" parameter so that it is known to be unique, unless there is a good reason not to. Examples of exceptions include: if the vendor does not have an assigned DNS domain name, if they are using a different vendor's implementation, etc. These parameters are useful to the PDS to affect the profiles provided. In some scenarios, it is desirable to provide different profiles based upon these parameters. For example, feature property X in a profile may work differently on two versions of the same user agent. This gives the PDS the ability to compensate for or take advantage of the differences. In the following ABNF defining the syntax, EQUAL and quoted-string are defined in [RFC3261].
「ベンダー」、「モデル」、および「バージョン」パラメータ値はユーザエージェントの実装によって指定されたトークンです。これらのパラメータは、すべてのプロファイル・タイプのためのSUBSCRIBEリクエストに提供しなければなりません。ないように十分な理由がない限り、ユニークであることが知られているように、実装者は、「ベンダー」パラメータの値として、そのDNSドメイン名（たとえば、example.com）を使用してください。例外としては、例えば、ベンダーが割り当てられたDNSドメイン名を持っていない場合、彼らは提供のプロファイルに影響を与えるためにこれらのパラメータは、PDSに役立つなど、異なるベンダーの実装を使用している場合。いくつかのシナリオでは、これらのパラメータに基づいて異なるプロファイルを提供することが望ましいです。たとえば、プロファイル内の機能特性Xは、同一のユーザエージェントの2つのバージョンで異なる動作をすることができます。これは、PDSに補うかの違いを利用することができます。次のABNF構文を定義する際に、EQUALと引用文字列は、[RFC3261]で定義されています。
Vendor = "vendor" EQUAL quoted-string Model = "model" EQUAL quoted-string Version = "version" EQUAL quoted-string
ベンダー=「ベンダー」EQUAL引用符で囲まれた文字列のモデル=「モデル」EQUAL引用符で囲まれた文字列のバージョン=「バージョン」EQUAL引用符で囲まれた文字列
The "effective-by" parameter in the Event header of the NOTIFY request specifies the maximum number of seconds before the user agent MUST attempt to make the new profile effective. The "effective-by" parameter MAY be provided in the NOTIFY request for any of the profile types. A value of 0 (zero) indicates that the subscribing user agent MUST attempt to make the profiles effective immediately (despite possible service interruptions). This gives the PDS the power to control when the profile is effective. This may be important to resolve an emergency problem or disable a user agent immediately. If it is absent, the device SHOULD attempt to make the profile data effective at the earliest possible opportunity that does not disrupt any services being offered. The "effective-by" parameter is ignored in all messages other than the NOTIFY request. In the following ABNF, EQUAL and DIGIT are defined in [RFC3261].
ユーザエージェントは、新しいプロファイルを有効にしようとしなければならない前に、「効果的なバイ」NOTIFYリクエストのEventヘッダーでパラメータが最大秒数を指定します。 「効果的なバイ」パラメータは、プロファイルタイプのいずれかのためNOTIFYリクエストで提供されてもよいです。 0（ゼロ）の値は、サブスクライブユーザエージェントが（可能なサービスの中断にもかかわらず）、すぐにプロファイルを有効にしようとしなければならないことを示しています。これは、PDSにプロファイルが有効であるときを制御する力を与えます。これは緊急の問題を解決するか、すぐにユーザーエージェントを無効にすることが重要です。それが存在しない場合は、デバイスが提供されているすべてのサービスを妨害しないできるだけ早い機会にプロファイルデータを有効にしようとすべきです。 「効果的なバイ」パラメータがNOTIFYリクエスト以外のすべてのメッセージでは無視されます。以下のABNFでは、EQUALとDIGITは[RFC3261]で定義されています。
Effective-By = "effective-by" EQUAL 1*DIGIT
効果的なバイ=「効果的なバイ」EQUAL 1 * DIGIT
The following are example Event headers that may occur in SUBSCRIBE requests. These examples are not intended to be complete SUBSCRIBE requests.
中に発生する可能性がありますされている次の例のイベントのヘッダーには、SUBSCRIBE要求。これらの例は、SUBSCRIBE要求を完了することを意図したものではありません。
Event: ua-profile;profile-type=device; vendor="vendor.example.com";model="Z100";version="1.2.3"
イベント：UAプロファイル、プロファイル・タイプ=デバイス。ベンダー= "vendor.example.com";モデル= "Z100";バージョン= "1.2.3"
Event: ua-profile;profile-type=user; vendor="premier.example.com";model="trs8000";version="5.5"
イベント：UA-プロファイル; =ユーザータイプをプロファイリング。ベンダー= "premier.example.com";モデル= "trs8000";バージョン= "5.5"
The following are example Event headers that may occur in NOTIFY requests. These example headers are not intended to be complete SUBSCRIBE requests.
中に発生する可能性がありますされている次の例のイベントのヘッダーはNOTIFYリクエストを。これらの例ヘッダはSUBSCRIBEリクエスト完全であることを意図していません。
Event: ua-profile;effective-by=0
イベント：UA-プロファイル;効果的なバイ= 0
Event: ua-profile;effective-by=3600
イベント：UA-プロファイル;効果的なバイ= 3600
The following table shows the use of Event header parameters in SUBSCRIBE requests for the three profile types:
次の表は、三のプロファイルタイプに対するSUBSCRIBE要求のイベントヘッダパラメータの使用を示します。
profile-type || device | user | local-network
=============================================
vendor || m | m | m
model || m | m | m
version || m | m | m
effective-by || | |
m - MUST be provided s - SHOULD be provided o - OPTIONAL to be provided
Mは - S提供しなければなりません - OPTIONAL提供する - Oが提供されるべきです
Non-specified means that the parameter has no meaning and should be ignored.
非指定されたパラメータは意味を持たず、無視されなければならないことを意味しています。
The following table shows the use of Event header parameters in NOTIFY requests for the three profile types:
以下の表は、3種類のプロファイルの要求をNOTIFYのイベントヘッダパラメータの使用を示します。
profile-type || device | user | local-network
=============================================
vendor || | |
model || | |
version || | |
effective-by || o | o | o
This package defines no use of the SUBSCRIBE request body. If present, it SHOULD be ignored. Exceptions include future enhancements to the framework that may specify a use for the SUBSCRIBE request body.
このパッケージは、SUBSCRIBEリクエストのボディのない使用を定義しません。存在する場合、それは無視されるべきです。例外は、SUBSCRIBEリクエストのボディのための使用を指定することができるフレームワークへの将来の拡張を含みます。
The duration of a subscription is specific to SIP deployments, and no specific recommendation is made by this event package. If absent, a value of 86400 seconds (24 hours; 1 day) is RECOMMENDED since the presence (or absence) of a device subscription is not time critical to the regular functioning of the PDS.
サブスクリプションの期間は、SIPの展開に固有のものであり、具体的な勧告は、このイベントパッケージによって行われません。存在しない場合は、86400秒（24時間、1日）の値は、デバイスサブスクリプションの存在（または不在）がPDSの定期的な機能に重要な時間ではないので、推奨されています。
It is to be noted that a one-time fetch of a profile, without ongoing subscription, can be accomplished by setting the 'Expires' parameter to a value of Zero, as specified in [RFC3265].
これは[RFC3265]で指定されたワンタイムは、進行中のサブスクリプションなしで、ゼロの値に「有効期限」パラメータを設定することによって達成することができ、プロファイルのフェッチことに留意すべきです。
The framework specifying the event package allows for the NOTIFY body to contain the profile data, or a pointer to the profile data using content indirection. For profile data delivered via content indirection, i.e., a pointer to a PCC, then the Content-ID MIME header, as described in [RFC4483], MUST be used for each profile document URI. At a minimum, the "http:" [RFC2616] and "https:" [RFC2818] URI schemes MUST be supported; other URI schemes MAY be supported based on the Profile Data Frameworks (examples include FTP [RFC0959], Lightweight Directory Access Protocol (LDAP) [RFC4510], and XCAP [RFC4825] ).
イベントパッケージを特定のフレームワークは、プロファイルデータを格納するNOTIFY体、またはコンテンツインダイレクションを使用してプロファイルデータへのポインタを可能にします。コンテンツ・インダイレクションを介して送達プロファイルデータのために、すなわち、その後PCCへのポインタは、Content-ID MIMEヘッダは、[RFC4483]に記載されているように、各プロファイル文書URIを使用しなければなりません。最低でも、 "HTTP：" [RFC2616]及び "HTTPS：" [RFC2818] URIスキームがサポートしなければなりません。他のURIスキームは、プロファイルデータフレームワークに基づいてサポートされるかもしれ（例はFTP [RFC0959]、ライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4510]、およびXCAP [RFC4825]を含みます）。
A non-empty NOTIFY body MUST include a MIME type specified in the Accept header of the SUBSCRIBE. Further, if the Accept header of the SUBSCRIBE included the MIME type message/external-body (indicating support for content indirection) then the PDS MAY use content indirection in the NOTIFY body for providing the profiles.
非空体は、SUBSCRIBEのAcceptヘッダで指定されたMIMEタイプを含まなければなりませんNOTIFY。さらに、SUBSCRIBEを次にPDSプロファイルを提供するためのNOTIFY体内にコンテンツ間接参照を使用するかもしれ（コンテンツ間接のサポートを示す）MIMEタイプメッセージ/外部のボディが含まのヘッダを受け入れた場合。
A successful SUBSCRIBE request results in a NOTIFY with either profile contents or a pointer to it (via content indirection). The SUBSCRIBE SHOULD be either authenticated or transmitted over an integrity protected SIP communications channel. Exceptions include cases where the identity of the Subscriber is unknown and the Notifier is configured to accept such requests.
成功したプロファイルの内容または（コンテンツ間接介して）それへのポインタのいずれかとNOTIFYにリクエスト結果をSUBSCRIBE。認証済みまたは完全性保護されたSIP通信チャネルを介して送信されるべきであるいずれかSUBSCRIBE。例外は、加入者の身元は不明であり、通知は、そのような要求を受け入れるように構成された例があります。
The Notifier MAY also authenticate SUBSCRIBE messages even if the NOTIFY is expected to only contain a pointer to profile data. Securing data sent via content indirection is covered in Section 9.
Notifierはまた、NOTIFY場合でも、SUBSCRIBEメッセージ認証を行ってもよいデータだけをプロファイルするポインタを含むことが期待されます。コンテンツ間接を介して送信されたデータをセキュアにすることは、セクション9で覆われています。
If the profile type indicated in the "profile-type" Event header parameter is unavailable or the Notifier is configured not to provide it, the Notifier SHOULD return a 404 response to the SUBSCRIBE request. If the specific user or device is unknown, the Notifier MAY accept the subscription, or else it may reject the subscription (with a 403 response).
「プロファイル型」イベント・ヘッダ・パラメータに示されているプロファイル・タイプが利用できない場合、または通知がそれを提供しないように構成されている場合、通知は、SUBSCRIBE要求に対して404応答を返すべきです。特定のユーザーまたはデバイスが不明な場合は、Notifierは、サブスクリプションを受け入れるか、あるいはそうでなければ（403応答で）サブスクリプションを拒否することができます。
As specified in [RFC3265], the Notifier MUST always send a NOTIFY request upon accepting a subscription. If the device or user is unknown and the Notifier chooses to accept the subscription, the Notifier MAY either respond with profile data (e.g., default profile data) or provide no profile information (i.e., empty NOTIFY).
[RFC3265]で指定されているように、Notifierは常にサブスクリプションを受け付けるNOTIFYリクエストを送らなければなりません。デバイス又はユーザが未知であると通知は、サブスクリプションを受け入れることを選択した場合、通知は、プロファイルデータ（例えば、デフォルトのプロファイルデータ）又は提供ないプロファイル情報（すなわち、空のNOTIFY）で応答することができるいずれか。
If the identity indicated in the SUBSCRIBE request (From header) is a known identity and the requested profile information is available (i.e., as specified in the "profile-type" parameter of the Event header), the Notifier SHOULD send a NOTIFY with profile data. Profile data MAY be sent as profile contents or via content indirection (if the content indirection MIME type was included in the Accept header). The Notifier MUST NOT use any scheme that was not indicated in the "schemes" Contact header field.
（Fromヘッダ）SUBSCRIBE要求に示さアイデンティティが既知のアイデンティティであり、要求されたプロファイル情報が利用可能である場合（すなわち、イベント・ヘッダの「プロファイル・タイプ」パラメータで指定されるように）、通知プロファイルとNOTIFY送りますデータ。プロファイルデータは、プロファイルの内容として、またはコンテンツ間接を介して送信することができる（コンテンツ間接MIMEタイプはAcceptヘッダーに含まれていた場合）。 Notifierは、「スキーム」Contactヘッダーフィールドで示されていなかった任意のスキームを使用してはなりません。
The Notifier MAY specify when the new profiles must be made effective by the Subscriber by specifying a maximum time in seconds (zero or more) in the "effective-by" Event header parameter.
新しいプロファイルは、「効果的なバイ」イベントヘッダパラメータに秒（ゼロ以上）で最大時間を指定することによって、加入者が有効化されなければならないときに通知を指定するかもしれません。
If the SUBSCRIBE was received over an integrity protected SIP communications channel, the Notifier SHOULD send the NOTIFY over the same channel.
SUBSCRIBEが完全性保護されたSIPの通信チャネルを介して受信された場合、Notifierは同じチャネルを介してNOTIFYを送るべきです。
A Subscriber to this event package MUST adhere to the NOTIFY request processing behavior specified in [RFC3265]. If the Notifier indicated an effective time (using the "effective-by" Event header parameter), the Subscriber SHOULD attempt to make the profiles effective within the specified time. Exceptions include deployments that prohibit such behavior in certain cases (e.g., emergency sessions are in progress). When profile data cannot be applied within the recommended time frame and this affects device behavior, any actions to be taken SHOULD be defined by the profile data definitions. By default, the Subscriber is RECOMMENDED to make the profiles effective as soon as possible.
このイベントパッケージへの加入者は、[RFC3265]で指定されたNOTIFYリクエスト処理動作に従わなければなりません。通知は、（「有効バイ」イベント・ヘッダ・パラメータを使用して）効果的な時間を示している場合、加入者は、指定された時間内にプロファイルを有効にすることを試みるべきです。例外は、特定の場合（例えば、緊急セッションが進行中である）このような行動を禁止導入を含みます。プロファイルデータは、推奨される時間枠内で適用することができず、これは、デバイスの動作に影響を与える場合に、取るべき任意のアクションは、プロファイルデータ定義によって定義されるべきです。デフォルトでは、加入者はできるだけ早くプロファイルを有効にすることをお勧めします。
When accepting content indirection, the Subscriber MUST always support "http:" or "https:" and be prepared to accept NOTIFY messages with those URI schemes. If the Subscriber wishes to support alternative URI schemes they MUST each be indicated in the "schemes" Contact header field parameter as defined in [RFC4483]. The
「HTTPS：」または：コンテンツ間接を受け付けた場合、加入者は、常に「HTTP」をサポートしなければならないし、それらのURIスキームとNOTIFYメッセージを受け入れるために準備します。加入者が別のURIスキームをサポートしたい場合、[RFC4483]で定義されるように、それらはそれぞれ「スキーム」Contactヘッダフィールドパラメータに示されなければなりません。ザ・
Subscriber MUST also be prepared to receive a NOTIFY request with no body. The subscriber MUST NOT reject the NOTIFY request with no body. The subscription dialog MUST NOT be terminated by a empty NOTIFY, i.e., with no body.
また、加入者は、本文なしでNOTIFYリクエストを受け取るために準備しなければなりません。加入者はいないボディとNOTIFYリクエストを拒否してはなりません。サブスクリプションダイアログは本文なしで、すなわち、NOTIFY空で終了してはなりません。
This event package allows the creation of only one dialog as a result of an initial SUBSCRIBE request as described in Section 4.4.9 of [RFC3265]. It does not support the creation of multiple subscriptions using forked SUBSCRIBE requests.
このイベントパッケージは、[RFC3265]のセクション4.4.9で説明したように、最初のSUBSCRIBEリクエストの結果としてのみ1つのダイアログを作成することができます。それはフォークがSUBSCRIBEリクエスト使用して複数のサブスクリプションの作成をサポートしていません。
The rate of notifications for the profiles in this framework is deployment specific, but expected to be infrequent. Hence, the event package specification does not specify a throttling or minimum period between NOTIFY requests.
この枠組みの中でのプロファイルの通知の割合は、展開固有のものですが、まれであることを期待していました。したがって、イベントパッケージ仕様は、NOTIFY要求の間に絞り又は最小期間を指定していません。
State agents are not applicable to this event package.
状態エージェントは、このイベントパッケージには適用されません。
This section provides examples along with sample SIP message bodies relevant to this framework. Both the examples are derived from the use case illustrated in Section 4.1, specifically the request for the device profile. The examples are informative only.
このセクションでは、このフレームワークに関連するサンプルSIPメッセージ本文と一緒に実施例を提供します。両方の例はセクション4.1に示されているユースケース、デバイスプロファイルの具体的要求に由来します。例は、単なる参考です。
This example illustrates the detailed message flows between the device and the SIP service provider's network for requesting and retrieving the profile (the flow uses the device profile as an example).
この例では、（流れは一例として、デバイスプロファイルを使用）プロファイルを要求し、取得するための装置及びSIPサービスプロバイダのネットワークとの間を流れる詳細なメッセージを示します。
The following are assumed for this example:
以下は、この例では想定されています。
o Device is assumed to have established local network connectivity; NAT and firewall considerations are assumed to have been addressed by the SIP service provider.
Oデバイスは、ローカルネットワーク接続を確立していると仮定されます。 NATやファイアウォールの考慮事項は、SIPサービスプロバイダによって対処されていると想定されています。
o Examples are snapshots only and do not illustrate all the interactions between the device and the service provider's network (and none between the entities in the SIP service provider's network).
Oの例としては、スナップショットであり、デバイスとサービスプロバイダのネットワーク（及びSIPサービスプロバイダのネットワーク内のエンティティ間なし）との間のすべての相互作用を示していません。
o All SIP communication with the SIP service provider happens via a SIP proxy.
O SIPサービスプロバイダを持つすべてのSIP通信は、SIPプロキシを経由して行われます。
o HTTP over TLS is assumed to be the Content Retrieval method used (any suitable alternative can be used as well).
O HTTP TLS上に使用されるコンテンツ検索方法（任意の適切な代替も同様に使用することができる）であると仮定されます。
The flow diagram and an explanation of the messages follow.
フロー図とメッセージの説明が続きます。
+----------------------+
+--------+ | SIP Service Provider |
| Device | | |
|(SIP UA)| | SIP PDS HTTP |
+--------+ | PROXY Server |
| |
+----------------------+
| | | |
| | | |
| SUBSCRIBE | | |
(SReq)|--------device profile--------->| | |
| |------>| |
| |200 OK | |
| 200 OK |<------| |
(SRes)|<-------------------------------| | |
| | | |
| | NOTIFY| |
| NOTIFY (Content Indirection)|<------| |
(NTFY)|<-------------------------------| | |
| 200 OK | | |
(NRes)|------------------------------->|200 OK | |
| |------>| |
| |
| |
| |
|<<<<<<<<<<<<< TLS establishment >>>>>>>>>>>>>|
| |
| HTTP Request |
(XReq)|---------------------------------------------->|
| |
| HTTP Response |
(XRes)|<----------------------------------------------|
| |
(SReq) the device transmits a request for the 'device' profile using the SIP SUBSCRIBE utilizing the event package specified in this framework.
（SREQ）デバイスは、SIPを使用して「デバイス」プロファイルは、この枠組みの中で指定されたイベントパッケージを利用するSUBSCRIBE要求を送信します。
* Note: Some of the header fields (e.g., SUBSCRIBE, Event, Via) are continued on a separate line due to format constraints of this document.
*注：ヘッダフィールドの一部（例えば、SUBSCRIBE、イベント、ビアは）によるこの文書の形式の制約に別の行に継続されます。
SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@example.com SIP/2.0
Event: ua-profile;profile-type=device;vendor="vendor.example.net";
model="Z100";version="1.2.3"
From: anonymous@example.com;tag=1234
To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
Call-ID: 3573853342923422@192.0.2.44
CSeq: 2131 SUBSCRIBE
Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@192.168.1.44
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-123456789AB0>"
;schemes="http,https"
Via: SIP/2.0/TCP 192.0.2.41;
branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
Accept: message/external-body, application/x-z100-device-profile
Content-Length: 0
(SRes) the SUBSCRIBE request is received by a SIP proxy in the service provider's network, which transmits it to the PDS. The PDS accepts the response and responds with a 200 OK.
（SRES）SUBSCRIBEリクエストがPDSに送信するサービスプロバイダのネットワーク内のSIPプロキシによって受信されます。 PDSは、応答を受け取り、200 OKで応答します。
* Note: The device and the SIP proxy may have established a secure communications channel (e.g., TLS).
*注：デバイスとSIPプロキシは、安全な通信チャネル（例えば、TLS）を確立してもよいです。
(NTFY) subsequently, the PDS transmits a SIP NOTIFY message indicating the profile location.
（NTFY）続いて、PDSは、SIPプロファイルの場所を示すNOTIFYメッセージを送信します。
* Note: Some of the fields (e.g., content-type) are continued on a separate line due to format constraints of this document.
*注：フィールドの一部（例えば、コンテンツ・タイプ）によるこの文書の形式の制約に別の行に継続されます。
NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@192.168.1.44 SIP/2.0
Event: ua-profile;effective-by=3600
From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
;tag=abca
To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
;tag=1234
Call-ID: 3573853342923422@192.0.2.44
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0
MIME-Version: 1.0
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 01 Jan 2010 09:00:00 UTC";
URL="http://example.com/z100-000000000000.html";
size=9999;
hash=10AB568E91245681AC1B
Content-Type: application/x-z100-device-profile Content-ID: <39EHF78SA@example.com> . . .
コンテンツタイプ：アプリケーション/ X-Z100-デバイスプロファイルのContent-ID：<39EHF78SA@example.com>。 。 。
(NRes) Device accepts the NOTIFY message and responds with a 200 OK.
（NRES）デバイスは、NOTIFYメッセージを受け取り、200 OKで応答します。
(XReq) once the necessary secure communications channel is established, the device sends an HTTP request to the HTTP server indicated in the NOTIFY.
必要な安全な通信チャネルが確立されると（XREQ）、デバイスは、NOTIFYに示されるHTTPサーバにHTTPリクエストを送信します。
(XRes) the HTTP server responds to the request via a HTTP response containing the profile contents.
（XRES）HTTPサーバは、プロファイルの内容を含むHTTP応答を介して要求に応答します。
The following example illustrates the case where a user (X) is simultaneously accessing services via two different devices (e.g., multimedia entities on a PC and PDA) and has access to a user interface that allows for changes to the user profile.
次の例では、ユーザ（X）は、同時に2つの異なるデバイス（例えば、PCやPDA上でマルチメディアエンティティ）を介してサービスにアクセスしている場合を示しており、ユーザプロファイルへの変更を可能にするユーザインターフェースへのアクセスを有しています。
The following are assumed for this example:
以下は、この例では想定されています。
o The devices (A & B) obtain the necessary profiles from the same SIP service provider.
Oデバイス（A＆B）は、同一のSIPサービスプロバイダから必要なプロファイルを得ます。
o The SIP service provider also provides a user interface that allows the user to change preferences that impact the user profile.
O SIPサービスプロバイダは、ユーザがユーザ・プロファイルに影響を与える設定を変更することを可能にするユーザインタフェースを提供します。
The flow diagram and an explanation of the messages follow.
フロー図とメッセージの説明が続きます。
o Note: The example only shows retrieval of user X's profile, but it may request and retrieve other profiles (e.g., local-network, device).
O注：例では、ユーザXのプロファイルの検索を示しているが、他のプロファイル（例えば、ローカルネットワーク、デバイス）を要求し、検索することができます。
----- -----
|User |_________| UI* | * = User Interface
| X | | |
----- -----
/ \
/ \
/ \ +----------------------+
+--------+ +--------+ | SIP Service Provider |
| Device | | Device | | |
| A | | B | | SIP PDS HTTP |
+--------+ +--------+ | PROXY Server |
+----------------------+
| | | |
| | | |
(A-EX)|<=Enrolls for User X's profile=>|<=====>| |
| | | |
| |
(A-RX)|<===Retrieves User X's profile================>|
| |
| | | | |
| | Enrolls for | | |
| (B-EX)|<== User X's ==>|<=====>| |
| | profile | | |
| | | | |
| | |
| (B-RX)|<= Retrieves User X's profile=>|
| |
| | |
| (HPut)|---------------------->|
| | |
| (HRes)|<----------------------|
| |
| | | |
| | NOTIFY| |
| NOTIFY |<------| |
(A-NT)|<-------------------------------| | |
| 200 OK | | |
(A-RS)|------------------------------->|200 OK | |
| |------>| |
| |
| | | NOTIFY| |
| | NOTIFY |<------| |
| (B-NT)|<---------------| | |
| | 200 OK | | |
| (B-RS)|--------------->|200 OK | |
| | |------>| |
| |
| |
(A-RX)|<===Retrieves User X's profile================>|
| |
| | |
| | |
| (B-RX)|<= Retrieves User X's profile=>|
| | |
(A-EX) Device A discovers, enrolls, and obtains notification related to user X's profile.
（A-EX）デバイスAは、発見登録し、そしてユーザXのプロファイルに関連する通知を取得します。
(A-RX) Device A retrieves user X's profile.
（A-RX）デバイスAは、ユーザXのプロファイルを取得します。
(B-EX) Device B discovers, enrolls, and obtains notification related to user X's profile.
（B-EX）デバイスBは、発見登録し、そしてユーザXのプロファイルに関連する通知を取得します。
(B-RX) Device B retrieves user X's profile.
（B-RX）デバイスBは、ユーザXのプロファイルを取得します。
(HPut) Changes affected by the user via the user interface are uploaded to the HTTP server.
ユーザインタフェースを介してユーザーが影響を受けた（HPut）の変更は、HTTPサーバにアップロードされています。
* Note: The Unique Identifier (UI) itself can act as a
device and subscribe to user X's profile. This is not
the case in the example shown.
(HRes) Changes are accepted by the HTTP server.
（HREを）変更は、HTTPサーバによって受け入れられています。
(A-NT) PDS transmits a NOTIFY message to device A indicating the changed profile. A sample message is shown below:
（A-NT）PDSは、変更されたプロファイルを示すデバイスAへのNOTIFYメッセージを送信します。サンプルメッセージは以下に示します。
* Note: Some of the fields (e.g., Via) are continued on a
separate line due to format constraints of this document.
NOTIFY sip:userX@192.0.2.44 SIP/2.0
Event: ua-profile;effective-by=3600
From: sip:userX@sip.example.net;tag=abcd
To: sip:userX@sip.example.net.net;tag=1234
Call-ID: 3573853342923422@192.0.2.44
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1
MIME-Version: 1.0
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 01 Jan 2010 09:00:00 UTC";
URL="http://www.example.com/user-x-profile.html";
size=9999;
hash=123456789AAABBBCCCDD
.
.
.
(A-RS) Device A accepts the NOTIFY and sends a 200 OK.
（A-RS）デバイスAは、NOTIFY受け取り、200 OKを送信します。
(B-NT) PDS transmits a NOTIFY message to device B indicating the changed profile. A sample message is shown below:
（B-NT）PDSは、変更されたプロファイルを示す装置BにNOTIFYメッセージを送信します。サンプルメッセージは以下に示します。
* Note: Some of the fields (e.g., Via) are continued on a
separate line due to format constraints of this document.
NOTIFY sip:userX@192.0.2.43 SIP/2.0
Event: ua-profile;effective-by=3600
From: sip:userX@sip.example.net;tag=abce
To: sip:userX@sip.example.net.net;tag=1234
Call-ID: 3573853342923422@192.0.2.43
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2
MIME-Version: 1.0
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 01 Jan 2010 09:00:00 UTC";
URL="http://www.example.com/user-x-profile.html";
size=9999;
hash=123456789AAABBBCCCDD
.
.
.
(B-RS) Device B accepts the NOTIFY and sends a 200 OK.
（B-RS）デバイスB NOTIFY受け取り、200 OKを送信します。
(A-RX) Device A retrieves the updated profile pertaining to user X.
（A-RX）は、デバイスAは、ユーザXに関連する更新されたプロファイルを取得します
(B-RX) Device B retrieves the updated profile pertaining to user X.
（B-RX）デバイスBは、ユーザXに関連する更新されたプロファイルを取得します
IANA has registered a SIP event package, event header parameters, and SIP configuration profile types as outlined in the following subsections.
以下のサブセクションで概説されるようにIANAは、SIPイベントパッケージ、イベント・ヘッダ・パラメータ、及びSIP構成プロファイル・タイプを登録しました。
This specification registers a new event package as defined in [RFC3265]. The registration is as follows:
この仕様は、[RFC3265]で定義された新しいイベントパッケージを登録します。次のように登録があります：
Package Name: ua-profile
パッケージ名：UA-プロフィール
Package or Template-Package: This is a package
パッケージまたはテンプレート・パッケージ：これはパッケージです
Published Document: RFC 6080
公開されたドキュメント：RFC 6080
Persons to Contact: Daniel Petrie <dan.ietf@SIPez.com>, Sumanth Channabasappa <sumanth@cablelabs.com>
問い合わせする者：ダニエル・ペトリー<dan.ietf@SIPez.com>、スーマンスChannabasappa <sumanth@cablelabs.com>
New event header parameters: profile-type, vendor, model, version, effective-by (The profile-type parameter has predefined values. The new event header parameters do not.)
新しいイベント・ヘッダ・パラメータ：プロファイル型、ベンダー、モデル、バージョン、有効なバイ（。。プロファイル-typeパラメータに値が事前定義された新しいイベント・ヘッダ・パラメータがありません）
The following table illustrates the additions to the IANA SIP "Header Field Parameters and Parameter Values" registry:
次の表は、IANA SIP「ヘッダーフィールドパラメータとパラメータ値」レジストリへの追加を示しています。
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- ---------- ---------
Event profile-type Yes [RFC6080]
Event vendor No [RFC6080]
Event model No [RFC6080]
Event version No [RFC6080]
Event effective-by No [RFC6080]
IANA has registered new SIP configuration profile types at http://www.iana.org in the "SIP Configuration Profile Types" registry.
IANAは、「SIP構成プロファイルタイプ」レジストリにhttp://www.iana.orgで新しいSIP構成プロファイルの種類を登録しています。
The registration procedures are "Specification Required", as explained in "Guidelines for Writing an IANA Considerations Section in RFCs" ([RFC5226]).
「RFCでIANA問題部に書くためのガイドライン」（[RFC5226]）で説明したように登録手続きは、「仕様が必要」です。
Registrations with the IANA MUST include the profile type, and a published document that describes its purpose and usage.
IANAでの登録は、プロファイルタイプ、およびその目的と使用方法を説明する公開されたドキュメントを含まなければなりません。
As this document specifies three SIP configuration profile types, the initial IANA registration contains the information shown in the table below.
この文書三のSIP構成プロファイルのタイプを指定するように、初期のIANA登録は、以下の表に示す情報を含みます。
Profile Type Reference
-------------- ---------
local-network [RFC6080]
device [RFC6080]
user [RFC6080]
The framework specified in this document specifies profile delivery stages, an event package, and three profile types to enable profile delivery. The profile delivery stages are enrollment, content retrieval, and change notification. The event package helps with enrollment and change notifications. Each profile type allows for profile retrieval from a PDS belonging to a specific provider.
この文書で指定されたフレームワークは、プロファイルの配信を可能にするために、プロファイルの配信ステージ、イベントパッケージ、および3つのプロファイルのタイプを指定します。プロファイル配信段階は、登録、コンテンツ検索、および変更通知です。イベントパッケージは、登録と変更の通知に役立ちます。各プロファイル・タイプは、特定のプロバイダに属するPDSからプロファイル検索を可能にします。
Enrollment allows a device to request, and if successful, enroll with a PDS to obtain profile data. To transmit the request the device relies on configured, cached, or discovered data. Such data includes provider domain names, identities, and credentials. The device either uses configured outbound proxies or discovers the next-hop entity using [RFC3263] that can result in a SIP proxy or the PDS. It then transmits the request. A SIP proxy receiving the request uses the Request-URI and event header contents to route it to a PDS (via other SIP proxies, if required).
登録は、デバイスが要求することができ、そして成功した場合、プロファイルデータを取得するPDSに登録します。デバイスが設定され、キャッシュされた、または検出されたデータに依存して要求を送信します。このようなデータは、プロバイダのドメイン名、アイデンティティ、および資格情報を含んでいます。装置を構成アウトバウンドプロキシを使用するか、またはSIPプロキシまたはPDSをもたらすことができる[RFC3263]を使用してネクストホップエンティティを発見のいずれか。その後、要求を送信します。 （必要であれば、他のSIPプロキシを介して）要求を受信したSIPプロキシは、PDSにルーティングをするための要求-URIとイベントヘッダーの内容を使用します。
When a PDS receives the enrollment request, it can either challenge any contained identity or admit the enrollment. Authorization rules then decide if the enrollment gets accepted. If accepted, the PDS sends an initial notification that contains either the profile data, or content indirection information. The profile data can contain generic profile data (common across multiple devices) or information specific to an entity (such as the device or a user). If specific to an entity, it may contain sensitive information such as credentials. Disclosure of sensitive data can lead to threats such as impersonation attacks (establishing rogue sessions), theft of service (if services are obtainable), and zombie attacks. It is important for the device to ensure the authenticity of the PNC and the PCC since impersonation of the SIP service provider can lead to DoS and man-in-the-middle (MITM) attacks.
PDSは、登録要求を受信すると、それはどんな含まれているアイデンティティに挑戦したり登録を認めることができます。登録が受け付けられます場合は、承認ルールは、決定します。受け入れた場合、PDSは、プロファイルデータ、またはコンテンツ間接情報のいずれかが含まれている最初の通知を送信します。プロファイルデータは、（例えば、デバイスまたはユーザなどの）エンティティに固有の一般的なプロファイル（複数のデバイス間で共通）データまたは情報を含むことができます。エンティティに固有の場合は、そのような資格情報などの機密情報が含まれていてもよいです。機密データの開示は、このようななりすまし攻撃（不正なセッションを確立する）、サービスの窃盗（サービスが得られる場合）、およびゾンビ攻撃などの脅威につながることができます。 SIPサービスプロバイダの偽装がDoS攻撃とのman-in-the-middle（MITM）攻撃につながることができますので、デバイスがPNCとPCCの信頼性を確保することが重要です。
Profile content retrieval allows a device to retrieve profile data via content indirection from a PCC. This communication is accomplished using one of many profile delivery protocols or frameworks, such as HTTP or HTTPS as specified in this document. However, since the profile data returned is subject to the same considerations as that sent via profile notification, similar threats exist. For example, DoS attacks (rogue devices bombard the PCC with requests for a specific profile) and attempts to modify erroneous data onto the PCC (since the location and format may be known). Thus, for the delivery of any sensitive profile data, authentication of the entity requesting profile data is required. It is also important for the requesting entity to authenticate the profile source via content indirection and ensure that the sensitive profile data is protected via data integrity. For sensitive data that should not be disclosed to unauthorized parties, data confidentiality is also required.
PCCからコンテンツ間接介してプロファイルデータを取得する装置をコンテンツ検索を可能にするプロフィール。この通信は、この文書で指定されたようなHTTPやHTTPSなどの多くのプロファイル配信プロトコルまたはフレームワークのいずれかを使用して達成されます。しかし、返されたプロファイルデータは、プロファイル通知を介して送信されるものと同じ考察の対象であるため、同様の脅威が存在します。たとえば、DoS攻撃とPCC（場所およびフォーマットを知ることができるので）上に誤ったデータを修正する試み（不正なデバイスが特定のプロファイルに対する要求でPCCを衝撃）。したがって、機密プロファイルデータの配信のために、プロファイルデータを要求しているエンティティの認証が必要です。要求エンティティは、コンテンツ間接経由プロファイルソースを認証し、機密プロファイルデータは、データの整合性によって保護されていることを確認することも重要です。権限のない第三者に開示するべきではない機密データの場合、データの機密性も必要です。
The following subsections highlight the security considerations that are specific to each profile type.
以下のサブセクションでは、各プロファイルのタイプに固有のセキュリティ上の配慮を強調表示します。
A local network may or may not (e.g., home router) support local-network profiles as specified in this framework. Even if supported, the PDS may only be configured with a generic local-network profile that is provided to every device that requests the local-network profile. Such a PDS may not implement any authentication requirements or TLS.
このフレームワークで指定されているローカルネットワークがまたはではない（例えば、ホームルータ）ローカル・ネットワーク・プロファイルをサポートすることができます。サポートされていても、PDSは、ローカル・ネットワークプロファイルを要求したすべてのデバイスに提供される一般的なローカル・ネットワークプロファイルを構成することができます。このようなPDSは、任意の認証要件やTLSを実装しない場合があります。
Alternatively, certain deployments may require the entities -- device and the PDS -- to authenticate each other prior to successful profile enrollment. Such networks may pre-configure user identities to the devices and allow user-specific local-network profiles. In such networks, the PDS will support digest authentication, and the devices are configured with user identities and credentials as specified in Section 5.3.1. If sensitive profile data is being transmitted, the user identity is a SIPS URI that results in TLS with the next-hop (which is authenticated), and digest authentication is used by the PDS and the device.
前成功したプロファイルの登録に互いを認証するために - デバイスとPDS - また、特定の展開は、エンティティが必要な場合があります。このようなネットワークは、デバイスへのユーザーIDを事前に設定し、ユーザー固有のローカル・ネットワークプロファイルを可能にすることができます。このようなネットワークでは、PDSは、ダイジェスト認証をサポートします、そして、セクション5.3.1に指定されているデバイスは、ユーザーIDと資格情報を使用して構成されています。敏感なプロファイルデータが送信されている場合、ユーザIDが（認証された）次のホップでTLSをもたらすSIPS URIであり、PDSデバイスによって使用されるダイジェスト認証。
This framework supports both use cases and any variations in between. However, devices obtaining local-network profiles from an unauthenticated PDS are cautioned against potential MITM or PDS impersonation attacks. This framework requires that a device reject sensitive data, such as credentials, from unauthenticated local-network sources. It also prohibits devices from responding to authentication challenges in the absence of TLS on all hops as a result of using a SIPS URI. Responding to unauthenticated challenges allows for dictionary attacks that can reveal weak passwords. The only exception to accepting such sensitive data without authentication of the PDS is in the case of bootstrapping (see Section 5.3.1). In the case of bootstrapping, the methods employed need to be aware of potential security threats such as impersonation.
このフレームワークは、ユースケースとの間における任意の変化の両方をサポートしています。ただし、認証されていないPDSからローカル・ネットワークプロファイルを取得するデバイスは、潜在的なMITMまたはPDSのなりすまし攻撃を警告しています。このフレームワークは、デバイスが認証されていないローカル・ネットワーク・ソースからそのような資格情報などの機密データを、拒絶することを必要とします。また、SIPS URIを使用した結果として、すべてのホップでTLSの不在下での挑戦を認証するために応答するデバイスを禁止しています。認証されていない課題への対応は、弱いパスワードを明らかにすることができ、辞書攻撃が可能になります。 PDSの認証なしでそのような機密データを受け入れる唯一の例外は、ブートストラップの場合には（セクション5.3.1を参照）。ブートストラップの場合において、使用方法は、なりすましなどの潜在的なセキュリティ上の脅威を認識する必要があります。
SIP Identity is useful for the device to validate notifications in the absence of a secure channel such as TLS when a SIPS URI is used. In such cases, the device can validate the SIP Identity header to verify the source of the profile notification, and the source of the profile data when content indirection is not used. However, the presence of the header does not guarantee the validity of the data. It verifies the source and confirms data integrity, but the data obtained from an undesired source may still be invalid, e.g., invalid outbound proxy information, resulting in DoS. Thus, devices requesting the local-network profile from unknown networks need to be prepared to discard information that prevent retrieval of other, required, profiles.
SIPアイデンティティは、SIPS URIを使用するTLSなどのセキュアチャネルが存在しない場合に通知を検証するデバイスのために有用です。このような場合、デバイスは、コンテンツ間接参照を使用しない場合、プロファイル通知のソース、およびプロファイルデータのソースを検証するためにSIP Identityヘッダを検証することができます。しかし、ヘッダの存在は、データの妥当性を保証するものではありません。これは、ソースを検証し、データの整合性を確認するが、望ましくないソースから得られたデータは依然としてDOSで得られた、無効、例えば、無効アウトバウンドプロキシ情報であってもよいです。したがって、未知のネットワークからローカルネットワークプロファイルを要求するデバイスは、他の、必要な、プロファイルの検索を防止情報を破棄するように調製する必要があります。
Device profiles deal with device-specific configuration. They may be provided to unknown devices that are attempting to obtaining profiles for purposes such as trials, self-subscription (not to be confused with [RFC3265]), and emergency services [PHONEBCP].
デバイスプロファイルは、デバイス固有の設定を扱います。彼らは、このような試験では、自己のサブスクリプション（[RFC3265]と混同しないように）、および緊急サービスなどの目的[PHONEBCP]のプロファイルを取得しようとしている不明なデバイスに提供することができます。
This framework allows the device profile to be used for bootstrapping a device. Such bootstrapping profile data may contain enough information to connect to a Provider. For example, it may enable the device to communicate with a device provider, allowing for trial or self-subscription services via visual or audio interfaces (e.g., interactive voice response), or customer service representatives. The profile data may also allow the device a choice of device providers and allow the end-user to choose one. The profile data may also contain identities and credentials (temporary or long-term) that can be used to obtain further profile data from the network. This framework recommends the use of the SIP Identity header by the PDS. However, to be able to validate the SIP Identity header, the device needs to be pre-configured with the knowledge of allowable domains or certificates for validation (e.g., using PKI). If not, the device can still guarantee header and body integrity if the profile data contains the domain certificate (but the data can still be invalid or malicious). In such cases, devices supporting user interfaces may obtain confirmation from the user trying to bootstrap the device (confirming header and body integrity). However, when the SIP Identity header is not present, or the device is not capable of validating it, the bootstrapping data is unauthenticated and obtained without any integrity protection. Such bootstrapping data, however, may contain only temporary credentials (SIPS URI and digest credentials) that can be used to reconnect to the network to ensure data integrity and data confidentiality prior to obtaining long-term credentials. It is to be noted that such devices are at the mercy of the network they request the device profile from. If they are initialized in a rogue network, or get hijacked by a rogue PDS, the end-user may be left without desired device operation or, worse, unwanted operation. To mitigate such factors the device provider may communicate temporary credentials (e.g., passwords that can be entered via an interface) or permanent credentials (e.g., a USB device) to the end-user for connectivity. If such methods are used, those credentials MUST be quickly replaced by large-entropy credentials, to minimize the impact of dictionary attacks. Future enhancements to this framework may specify device capabilities that allow for authentication without any provider-specific configuration (e.g., X.509 certificates using PKI can allow for authentication by any provider with access to the CA certificate). Alternatively, the device may be pre-configured with credentials for use with content indirection mechanisms. In such circumstances a PDS can use secure content indirection mechanism, such as HTTPS, to provide the bootstrapping data.
このフレームワークは、デバイスプロファイルは、デバイスをブートストラップするために使用されることを可能にします。このようなブートストラッププロファイルデータは、プロバイダに接続するために十分な情報が含まれていてもよいです。例えば、それは、視覚又はオーディオインターフェース（例えば、対話型音声応答）、または顧客サービス担当者を介して、試験または自己のサブスクリプションサービスを可能にする、デバイス・プロバイダと通信するデバイスを可能にすることができます。プロファイルデータは、デバイスにデバイス・プロバイダーの選択が可能となり、エンドユーザーがいずれかを選択できるようにしてもよいです。プロファイルデータは、ネットワークからのさらなるプロファイルデータを得るために使用することができるIDおよび資格情報（一時的又は長期）を含んでいてもよいです。このフレームワークは、PDSによってSIP Identityヘッダを使用することをお勧めします。しかしながら、SIP Identityヘッダを検証することができるように、デバイス（例えば、PKIを使用して）検証のための許容ドメインまたは証明書の知識を事前に設定する必要があります。そうでない場合、プロファイルデータは、ドメイン証明書が含まれている場合、デバイスは、まだヘッダとボディの整合性を保証することができます（ただし、データはまだ無効または悪意のあるすることができます）。このような場合には、ユーザインタフェースをサポートするデバイスは、デバイス（確認ヘッダとボディの整合性）をブートストラップしようとするユーザからの確認を得ることができます。 SIP Identityヘッダが存在しない、またはデバイスがそれを検証することができない場合しかし、ブートストラップデータは、認証されていない任意の完全性保護なしで得られます。このようなブートストラップデータは、しかし、前に長期の資格を取得するデータの整合性とデータの機密性を確保するために、ネットワークに再接続するために使用することができる唯一の一時的な資格情報（URIをSIPSと資格情報をダイジェスト）を含むことができます。それは、そのようなデバイスは、彼らがからデバイスプロファイルを要求するネットワークのなすがままにされていることに留意すべきです。それらは不正なネットワークに初期化され、又は不正PDSによって乗っ取られた場合は、エンドユーザは、所望のデバイスの動作や、悪化、不要な操作をすることなく放置されてもよいです。このような要因を緩和するために、デバイスプロバイダが一時的身分証明を通信することができる（例えば、インタフェースを介して入力できるパスワード）または接続のエンドユーザへの永続的身分証明（例えば、USBデバイス）。そのような方法が使用されている場合は、それらの資格情報がすぐに辞書攻撃の影響を最小限に抑えるために、大エントロピーの資格情報に置き換えなければなりません。このフレームワークの将来の拡張は任意のプロバイダ固有の構成（例えば、PKIを使用して、X.509証明書は、CA証明書へのアクセスを有する任意のプロバイダによって認証を可能にすることができる）ことなく認証を可能にする装置機能を指定することができます。あるいは、デバイスは、コンテンツ間接メカニズムと共に使用するための資格情報を使用して事前に構成されてもよいです。このような状況にPDSは、ブートストラップデータを提供するために、HTTPSのような安全なコンテンツ間接メカニズムを使用することができます。
Once a device is associated with a device provider the device profile is vital to device operation. This is because the device profile can contain important operational information such as users that are to be allowed access (white-list or black-list), user credentials (if required) and other sensitive information. Thus, it is necessary to ensure that any device profile containing sensitive information is obtained via an authenticated source, with integrity protection, and delivered to an authenticated device. For sensitive information such as credentials, data confidentiality is also required. The framework requires that devices obtain sensitive information only from authenticated entities except while it is being bootstrapped. In cases where data confidentiality needs to be mandated for notifications, the device provider can configure the device with a SIPS URI, to be used as the Subscription URI, during profile enrollment. The framework also requires a PDS presenting sensitive profile data to use digest authentication. This ensures that the data is delivered to an authenticated entity. Authentication of profile retrieval via content indirection for sensitive profiles is via HTTPS utilizing HTTP digest.
デバイスは、デバイスプロバイダに関連したらデバイスプロファイルは、デバイス動作に不可欠です。デバイスプロファイルは、アクセス（ホワイトリストまたはブラックリスト）を許可されるユーザ、ユーザ認証情報（必要な場合）、およびその他の機密情報などの重要な動作情報を含むことができるからです。これにより、機密情報を含む任意のデバイスプロファイルは、完全性保護と、認証されたソースを介して取得し、認証されたデバイスに配信されることを保証する必要があります。などの資格情報などの機密情報については、データの機密性も必要です。フレームワークは、デバイスは、それがブートストラップされている間を除き、認証されたエンティティからのみ機密情報を入手する必要があります。データの機密性を通知するために義務付けする必要な場合には、デバイス・プロバイダは、SIPS URIでデバイスを設定することができ、プロファイルの登録時に、サブスクリプションのURIとして使用されるように。フレームワークは、ダイジェスト認証を使用するように敏感なプロファイルデータを提示するPDSが必要です。これは、データが認証されたエンティティに配信されることを保証します。感受性プロファイルのコンテンツ間接介しプロファイル検索の認証はHTTPダイジェストを利用したHTTPSを介して行われます。
Devices can only request user profiles for users that are known by a SIP service provider. PDSs are required to reject user profile enrollment requests for any users that are unknown in the network.
デバイスはSIPサービスプロバイダによって知られているユーザのユーザプロファイルを要求することができます。 PDSのは、ネットワーク内の未知の任意のユーザーのユーザープロファイル登録要求を拒否するように要求されています。
For known user AoRs that are allowed to retrieve profiles, the security considerations are similar to that of the device profile (except for bootstrapping).
プロファイルを取得するために許可されている既知のユーザーのAORの場合は、セキュリティ上の考慮事項は、（ブートストラップを除く）デバイスプロファイルのものと同様です。
The author appreciates all those who contributed and commented on the many iterations of this document. Detailed comments were provided by the following individuals: Jonathan Rosenberg, Henning Schulzrinne, Cullen Jennings, Rohan Mahy, Rich Schaaf, Volker Hilt, Adam Roach, Hisham Khartabil, Henry Sinnreich, Martin Dolly, John Elwell, Elliot Eichen, Robert Liao, Dale Worley, Francois Audet, Roni Even, Jason Fischl, Josh Littlefield, and Nhut Nguyen.
著者は貢献し、この文書の多くの繰り返しにコメントしたすべての人を高く評価しています。ジョナサン・ローゼンバーグ、ヘニングSchulzrinneと、カレン・ジェニングス、ロハンマーイ、リッチシャーフ、フォルカー柄、アダムローチ、ヒシャムKhartabil、ヘンリーSinnreich、マーティン・ドリー、ジョンエルウェル、エリオットEichen、ロバート遼、デールウォーリー：詳細なコメントは、以下の個人によって提供されました、フランソワAudet、ロニでも、ジェイソンFischl、ジョシュ・リトルフィールド、およびNhutグエン。
The final revisions of this document were a product of design team discussions. The editor wishes to extend special appreciation to the following design team members for their numerous reviews and specific contributions to various sections: Josh Littlefield (Overview, Section 6), Peter Blatherwick (Section 6), Cullen Jennings (Security), Sam Ganesan (Section 6), and Mary Barnes (layout, Section 6).
このドキュメントの最後の改訂は、設計チームの議論の産物でした。ジョシュ・リトル（概要、第6節）、ピーター・Blatherwick（第6節）、カレン・ジェニングス（セキュリティ）、サム・ガネサン（節：エディタは、彼らの数々のレビューや様々なセクションへの具体的な貢献のために、以下の設計チームのメンバーに特別な感謝を拡張したいです6）、およびメアリー・バーンズ（レイアウト、セクション6）。
The following design team members are thanked for numerous reviews and general contributions: Martin Dolly, Jason Fischl, Alvin Jiang, and Francois Audet.
マーティン・ドリー、ジェイソンFischl、アルビン江、そしてフランソワAudet：以下の設計チームのメンバーは、多くのレビューや一般拠出金のために感謝しています。
The following SIPPING WG members are thanked for numerous reviews, comments and recommendations: John Elwell, Donald Lukacs, Roni Even, David Robbins, Shida Schubert, and Eugene Nechamkin. The editor would also like to extend a special thanks to the comments and recommendations provided by the SIPPING WG, specifically Keith Drage (restructuring proposal) and John Elwell (numerous reviews and recommendations).
ジョンエルウェル、ドナルド・ルカーチ、ロニでも、デビッド・ロビンス、志田シューベルト、およびユージンNechamkin：以下SIPPING WGのメンバーは、多くのレビュー、コメントおよび推奨事項については感謝しています。エディタはSIPPING WG、特にキース糖剤（リストラ案）とジョン・エルウェル（数多くのレビューと勧告）により提供されるコメントや勧告に特別な感謝を拡張したいと思います。
Additionally, appreciation is also due to Peter Koch for expert DNS advice.
また、感謝の専門家のDNSのアドバイスのためにも、ピーター・コッホによるものです。
Finally, sincere appreciation is extended to the chairs (Mary Barnes and Gonzalo Camarillo); the past/current Area Directors (Cullen Jennings, Jon Peterson, and Robert Sparks) for facilitating discussions, reviews, and contributions; and, the expert reviewers from the IESG (Peter McCann, Catherine Meadows).
最後に、心からの感謝は、椅子（メアリー・バーンズとゴンサロ・カマリロ）に拡張されます。ディスカッション、レビュー、および貢献を促進するための過去/現在のエリアディレクター（カレン・ジェニングス、ジョンピーターソン、ロバート・スパークス）。そして、IESGからの専門家の査読（ピーター・マッキャン、キャサリン・メドウズ）。
[FIPS-180-3] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]国立標準技術研究所（NIST）、 "セキュアハッシュ規格（SHS）"、FIPS PUB 180-3の、2008年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319] Schulzrinneと、H.、およびB.フォルツ、RFC 3319、2003年7月 "セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション"。
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[RFC3361] Schulzrinneと、H.、 "動的ホスト構成プロトコル（DHCP-用-IPv4）のセッション開始プロトコル（SIP）サーバーのオプション"、RFC 3361、2002年8月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]リーチ、P.、Mealling、M.、およびR. Salzの、 "汎用一意識別子（UUID）URN名前空間"、RFC 4122、2005年7月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]バーガー、E.、 "セッション開始プロトコル（SIP）におけるコンテンツの間接化の仕組みメッセージ"、RFC 4483、2006年5月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704]フォルツ、B.、 "IPv6の動的ホスト構成プロトコル（DHCPv6）クライアント完全修飾ドメイン名（FQDN）オプション"、RFC 4704、2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[PHONEBCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, October 2010.
[PHONEBCP]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、2010年10月の作業。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"、RFC 4510、2006年6月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]イーストレイク、D.とT.ハンセンは、RFC 4634、2006年7月、 "米国は、ハッシュアルゴリズム（SHAとHMAC-SHA）を固定します"。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
Authors' Addresses
著者のアドレス
Daniel Petrie SIPez LLC 246A Park Ave Arlington, MA 02476 USA
ダニエル・ペトリーSIPez LLC 246Aパークアベニューアーリントン、MA 02476 USA
EMail: dan.ietf@SIPez.com URI: http://www.SIPez.com/
電子メール：dan.ietf@SIPez.com URI：http://www.SIPez.com/
Sumanth Channabasappa (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA
スーマンスChannabasappa（エディタ）CableLabsの858コールクリークサークルルイビル、CO 80027 USA
EMail: sumanth@cablelabs.com URI: http://www.cablelabs.com/
電子メール：sumanth@cablelabs.com URI：http://www.cablelabs.com/