[要約] RFC 6080は、セッション開始プロトコル（SIP）ユーザーエージェントプロファイルの配信のためのフレームワークを提供しています。このRFCの目的は、SIPユーザーエージェントの設定情報を効果的に配信するためのガイドラインを提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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に登録するプロセスです。デバイスは、一時的なIDと資格情報を使用して、登録および受信プロファイルを認証するために自らを使用して、将来の登録に対してより永続的なIDと資格情報を提供する場合があります。
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).
SIP UAプロファイル配信フレームワークは、SIPイベントメッセージ（購読と通知、[RFC3265]）と、HTTP [RFC2616]などの従来のファイル検索プロトコルの組み合わせを使用して、構成プロファイルを発見、監視、取得します。フレームワークは、異なる管理ドメインによって独立して管理できる構成の側面を分離するために、3種類のプロファイル（ローカルネットワーク、デバイス、およびユーザー）を定義します。各プロファイルの初期サブスクライブメッセージにより、UAはそれ自体を記述することができます（その実装とプロファイルを要求するIDの両方）、プロファイル名または場所の事前知識なしに、タイプごとにプロファイルへのアクセスを要求します。発見メカニズムは、UAがサブスクリプションURI（SIPサブスクライブのリクエスト-URI）を形成するのに役立つように指定されています。これらのサブスクリプションを処理するSIPユーザーエージェントサーバー（UAS）は、プロファイル配信サーバー（PDS）です。PDSがサブスクリプションを受け入れると、デバイスに通知を送信します。各プロファイルのPDSからの初期通知には、プロファイルデータまたはプロファイルの位置への参照が含まれ、HTTPまたは同様のファイル検索プロトコルを使用して取得できます。各プロファイルのサブスクリプションを維持することにより、UAはプロファイルが後で変更された場合、追加の通知メッセージを受信します。これらには、サブスクリプションで使用されているコンテンツタイプ[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
PNC =プロファイル通知コンポーネントPCC =プロファイルコンテンツコンポーネント
Figure 1: Framework Reference Model
図1：フレームワーク参照モデル
The PDS is subdivided into two logical components:
PDSは、2つの論理コンポーネントに分割されます。
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.
フレームワークの動機は、セクション3.1で提示された参照モデルを、潜在的なSIP展開のスペクトルの2つの端を代表する2つのシナリオに適用することで実証できます。
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.
最も単純な展開シナリオでは、ローカルネットワークを提供し、デバイスを管理し、ユーザーにサービスを提供する単一のプロバイダーによって制御されるネットワークを介してデバイスを接続します。プロバイダーは、ネットワーク内のサービスを取得するために必要なすべての情報を含むデバイス（ローカルネットワークおよびユーザーに関連する情報を含む）にプロファイルデータをプロファージングします。これを図2に示します。例は、SIPベースのデバイスをサポートするシンプルなエンタープライズネットワークです。
--------------
/ 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.
より複雑な展開では、デバイスは、利用可能な公開WiFiホットスポットを介して接続するデバイスなど、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.
デバイスは、ユーザーがリモートロケーションからサービスにアクセスできるKioskなど、ユーザーサービスを提供する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つ以上のプロバイダーを介してプロファイル配信を可能にする必要があります。フレームワークは、複数のプロファイルタイプとそれらを取得するためのプロファイル配信段階のセットを指定することにより、これを達成します。これらは、サブセクションで導入されています。
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:
このフレームワークは、複数のプロファイルタイプを許可することにより、潜在的に異なるプロバイダーの存在を処理します。クライアントは各プロファイルを個別にリクエストし、同じ、または異なるプロバイダーからそれらを取得します。展開は、指定されたプロファイルタイプのサブセットのみを要求するようにデバイスに事前構成することもできます。フレームワークは、次のように3つの基本的なプロファイルタイプを指定します。
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つ以上のPDSSが必要です。プロファイルデータとその後の変更を取得するためにデバイスを導くプロセスは、プロファイル配信段階と呼ばれる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の展開でどのように利用できるかをさらに説明するために、代表的なユースケースの小規模で非包括的なセットを提供します。最初のユースケースは本質的に単純化されていますが、2番目は比較的複雑です。ユースケースは、どちらのシナリオでもフレームワークの有効性を示しています。
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間の典型的な通信は、1つ以上の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 デバイスとPDSS間の通信は、1つ以上のSIPプロキシを介して促進されます（図には1つだけが表示されます）。
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.
（d）プロバイダーとの既存のサービス関係を持つユーザーA 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サブスクライブリクエスト[RFC3265]を送信するときに開始されます。要求されるプロファイルは、「プロファイルタイプ」パラメーターを使用して示されます。デバイスは、宛先ドメインの構成されたアウトバウンドプロキシを介して、またはRFC 3263 [RFC3263]に従って、SIPサブスクライブメッセージを送信する必要があります。
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.
デバイスは、登録要求を作成し、リクエスト-URIを形成し、ネットワークに認証するために特定のデータを必要とします。これには、プロファイルプロバイダーのドメイン名とデバイス、またはユーザーのアイデンティティと資格情報が含まれます。このようなデータは、デバイスの製造中、ユーザーによる、またはプロファイルデータの登録を介して「構成」できます（セクション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インフラストラクチャ要素が要求を受信した場合、リクエスト-URIに示されているドメインの権威あるプロキシに伝えます（他のサブスクライブメッセージを処理するのと同じ方法）。権威あるプロキシは、リクエスト（イベントパッケージなど）を調べ、プロファイル登録要求に対処できる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はリクエストで提示されたIDを検証し、必要な認証を実行します。認証が成功したら、PDSは、該当する許可ポリシーに基づいて、登録要求を認めたり拒否したりする必要があります。[RFC3265]で指定されているように、登録要求を認めるPDSは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通知メッセージをデバイスに準備します。このような通知には、プロファイルデータを含めるか、デバイスがプロファイルコンテンツの取得を実行するコンテンツの間接情報を含めることもできます。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通知メッセージを受信し、プロファイルの登録が成功したことを示した場合、デバイスは、セクション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通知メッセージ本文の使用に関する情報については、セクション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.
このフレームワークを実装するデバイスとPDSSは、それぞれ[RFC2616]と[RFC2818]で指定されているように、HTTPとHTTPSの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.
プロファイルデータは時間とともに変化する可能性があります。変更は、さまざまなエンティティ（デバイス、バックオフィスコンポーネント、エンドユーザーWebインターフェイスを介して）およびさまざまな理由（ユーザーの好みやサービスの変更の変更）によって開始できます。プロファイルは、複数のデバイスで同時に共有される場合があります。プロファイルが変更された場合、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通知メッセージ）を使用して変更通知を提供します。SIP通知は、変更されたデータへのポインターを含む変更、改訂されたプロファイル、またはコンテンツの間接を提供する場合があります。デバイスが登録プロファイルのプロファイル変更通知を正常に受信した場合、「効果的な」パラメーターの有効期限の前に変更に対応する必要があります。
For NOTIFY content, please refer to Section 6.5.
コンテンツの通知については、セクション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購読のコンテンツの要件について説明します。必要なデータは、プロファイルの種類に応じて、構成、キャッシュ、または検出できます。データが構成されていない場合、デバイスは関連するキャッシュデータを使用するか、データ発見を続行する必要があります。このセクションでは、登録のためのSIPサブスクライブの作成、キャッシュ要件、およびデータの検出方法について説明します。
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、またはリセット全体でローカルネットワークプロファイルデータをキャッシュしないでください。これの例外は、デバイスが同じネットワークで再活性化されていることを確認できる場合です（このドキュメントの範囲外の平均を使用）。したがって、ほとんどの場合、デバイスはローカルネットワークドメイン名を発見する必要があります。このデバイスは、ローカルネットワークでIP接続を確立することによりこれを発見します（DHCPまたは事前に構成されたIP情報など）。確立されたら、デバイスは、利用可能な場合は、事前構成によって取得されたローカルネットワークドメインを使用しようと試みる必要があります。事前に構成されていない場合は、DHCPV4（[RFC2132]、ドメイン名オプション）またはDHCPV6（[RFC4704]）を使用して動的発見を使用する必要があります。ローカルネットワークドメインが取得されると、デバイスは以下に説明するように登録用のSIPサブスクライブを作成します。
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のユーザー部分に入力してはなりません。デバイスは、リクエスト-URIのホスト部分を「_sipuaconfig」およびローカルネットワークドメインのドット分離された連結に設定する必要があります（以下の例を参照）。
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".
o デバイスがローカルネットワークドメイン用のユーザーAORで構成されている場合（セクション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]で指定されているように、デバイスには接触ヘッダー内に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である場合、ローカルネットワークプロファイルはリクエストリクエストを購読します。
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.
ローカルネットワークのプロファイルを購読するリクエスト-URIにはユーザーパーツがないため、ドメインが2つで同じである場合、URIが「ローカル」と「デバイス」URIの間で区別されます。これにより、異なるサーバーがあるドメイン内の適切な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.
From Fieldには、利用可能な場合はユーザーAORが入力されています。これにより、ローカルネットワークプロバイダーは、利用可能な場合はユーザー固有のプロファイルデータを伝播できます。コンタクトヘッダー内の「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 デバイスは、デバイス識別子を使用して、リクエスト-URIのユーザー部品に入力する必要があります。デバイスは、リクエスト-URIのホスト部分をデバイスプロバイダーのドメイン名に設定する必要があります。デバイス識別子形式については、このセクションの後半で詳しく説明します。
o The device MUST set the From field to a value of anonymous@<device provider's domain>.
o デバイスは、FROM FROMをAnonymous@<Device Provider's Domain>の値に設定する必要があります。
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.
o [RFC5626]で指定されているように、デバイスにはコンタクトヘッダー内に「sip.instance」パラメーターを含める必要があります。デバイスは、ローカルネットワークプロファイルを要求しているときに提示された値と同じ値を使用する必要があります。
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は、リクエスト-URIを形成し、FROMフィールドに入力するために使用されます。
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オプションを使用して、DHCPプロセス中にアウトバウンドプロキシのドメイン名を取得しようと試みる必要があります（それぞれIPv4およびIPv6の場合）。
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：デバイスは、ローカルネットワークドメイン名（設定または検出されたローカルネットワークプロファイルを取得するように設定または検出されます）を使用する必要があります。
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.
o デバイスに変更不可能なメディアアクセス制御（MAC）アドレスがある場合、タイムスタンプとクロックシーケンスビットを「0」に設定したバージョン1 UUID表現を使用する必要があります。これにより、Mac-AddressベースのUUIDの容易な認識と独自性が可能になります。例外は、デバイスが複数のSIP UAの独立したデバイス構成をサポートする場合です。例としては、同じプラットフォーム上の複数のSIP UASがあります。
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 デバイスが変更不可能なデバイス識別子を使用できない場合、代替の変更不可能なデバイス識別子を使用する必要があります。たとえば、モバイルデバイス用の国際的なモバイル機器ID（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].
o デバイスが変更不可能なMACアドレスを使用できない場合、[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のユーザー部分として使用される場合、コロン（ "："）がaddr-spec（[rfc4122]）のユーザー部分の法的文字ではないため、URLを逃れる必要があります。逃げなければなりません。
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
URI：SIP：urn％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を作成するには、次のルールが適用されます。Oデバイスは、リクエスト-URIをユーザーAORに設定する必要があります。
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.
ユーザープロファイルタイプのプロファイル登録要求を受信するSIPプロバイダーのネットワークの権威あるSIPプロキシは、イベントヘッダーフィールド値に基づいてルーティングし、ユーザーのAORにサブスクリプションを適切なPDSにルーティングできるようにします。
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.
プロファイルデータには、アイデンティティや資格情報など、保護する必要がある機密情報を含めることができます。セキュリティには、認証、データの整合性、データの機密性が含まれます。認証とは、プロファイルの登録中に提示されたユーザー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.
潜在的なセキュリティの脅威の概要については、セクション9を参照してください。デバイスをIDと資格情報で構成する方法については、セクション5.3.1を参照してください。次のサブセクションは、各プロファイル配信段階に関連付けられたセキュリティ要件を提供し、このフレームワークで指定された各プロファイルタイプに適用されます。
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 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.
セクション5.3.1で指定されているように、アイデンティティと資格情報で構成されたデバイスを認証するには、敏感なプロファイルデータを含むサポートプロファイル（セクション5.3.3を参照）をサポートするには、デバイスとPDSSが消化認証をサポートする必要があります（輸送層のセキュリティをサポートする必要があります。TLS））[RFC3261]で指定されています。将来の拡張機能は、X.509証明書を使用した認証など、他の認証方法を提供する場合があります。デバイスがPDSを認証するには、デバイスはダイジェスト認証中にPDSと相互に認証する必要があります（デバイスは、承認ヘッダーで応答するPDSに挑戦します）。機密性の高いプロファイルデータの送信には、データの整合性も必要です。これは、プロファイル登録中の発見プロセスがセッション開始プロトコルセキュア（SIPS）URIを提供することにより、TLSの確立をもたらす（[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で構成されている、または発見された場合、次のホップSIPエンティティがTLSをサポートしていないため、TLS確立が失敗します。デバイスが次のホップエンティティでTLSを確立する場合、デバイスは、設定された情報（例：認定機関（CA）証明書）がない限り、認証用に[RFC2818]、セクション3.1で指定された手順を使用する必要があります。認証（ブートストラップ前のように）。認証のための「サーバーID」は、常にNext-Hop 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 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.
[RFC4474]で指定されているように、デバイスに通知内でブートストラッププロファイルデータが提供され、機密情報が含まれている場合、SIP IDヘッダーを使用する必要があります。これは、ブートストラップソース（許可されたドメイン証明書のリスト、または公開キーインフラストラクチャ（PKI）を使用したルートCA証明書のリスト）を検証するために証明書で事前に構成される可能性のあるデバイスに役立ちます。SIP IDヘッダーを使用する場合、PDSはAORのホスト部分をHeaderにプロバイダーのドメインに設定する必要があります（ユーザー部分はエンティティ固有の識別子です）。デバイスが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を使用する必要があります。PCCSおよびデバイスは、デバイスプロファイルを介してデバイスをブートストラップすることを除き、機密性のプロファイルデータにHTTPを使用してはなりません。デバイスは、[RFC2818]で指定されているPCCをセクション3.1に認証する必要があります。機密データを含むプロファイルデータが提供されているデバイスは、[RFC2617]で指定されたDigest認証を使用して認証する必要があります。結果の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 IDヘッダーの使用を推奨します。SIP IDヘッダーを使用する場合、PDSはAORのホスト部分をHeaderにプロバイダーのドメインに設定する必要があります（ユーザー部分はエンティティ固有の識別子です）。これにより、ヘッダーと体の完全性も提供されます。ただし、データの機密性を必要とする機密性の高いプロファイルデータの場合、Notifyリクエストが送信される連絡先URIがSIPではない場合、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.
バンド外のメソッドデバイスまたはプロバイダーは、サブスクライバーIDモジュール（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ポータルに指示してサブスクリプションを取得できます。サブスクリプションを成功させると、エンドユーザーまたはデバイスに必要なアイデンティティと資格情報を提供できます。
* 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.
* IDと資格情報を提供できる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.
相互運用性のために、このフレームワークには、このフレームワークを使用する最後のオプション（上記）をサポートするためにPDSSとデバイスが必要です。具体的には、プロファイルデータを介してアイデンティティと資格情報を提供するオプションをサポートする必要があります。
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で示されるドメインに役立つPDSSによって知られています。したがって、デバイスは、それぞれのドメインで構成されたAORのみを表示できます。例外は、フェデレーションされたアイデンティティの使用です。これにより、デバイスは複数のドメインでユーザーのAORを使用できます。さらに、同じドメイン内でさえ、デバイスのドメインプロキシとPDSが2つの異なる領域にある可能性があるため、ダイジェスト認証の異なる資格情報に関連付けられている可能性があります。そのような場合、複数の資格情報が構成され、それらが使用される領域に関連付けられている場合があります。このフレームワークは、プロファイルの登録のためのダイジェスト認証のみを指定し、デバイスには他の資格情報が含まれることは期待されていません。コンテンツの間接を使用したプロファイル検索の場合、デバイスはX.509証明書（TLS）などの追加の資格情報をサポートする必要があります。将来の拡張機能は、プロファイルの登録と取得のための追加の資格情報タイプを指定することができます。
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
- 登録の受け入れと初期通知をお待ちしています
+ If the profile enrollment is successful = Exit this function()
+ プロファイルの登録が成功した場合=この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^i*（64*t1）の遅延; - これは指数関数的なバックオフです
- increment i;
- Increment I;
- If i>8, reset i=8;
- i> 8の場合、i = 8をリセットします。
End loop: Loop 1
エンドループ：ループ1
End Function()
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がプロファイルを無効にしたい場合、「空のプロファイル」、つまり含まれたデータなしのプロファイルインスタンス（プロファイルデータモデルでサポートされている場合、空の通知と混同しない場合）で通知を送信することにより、それを行うことができます。または、データを無効にする明示的なプロファイルデータ要素を介して。そのような通知を受信するデバイスは、該当するプロファイルを破棄する必要があります（つまり、キャッシュに保存することさえできません）。さらに、工場出荷時のリセットが利用可能で、デバイスで実行された場合、構成の前にデバイスを初期状態にリセットする必要があります。具体的には、デバイスが元々配布されたときにデバイスを状態に戻す必要があります。
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.
このフレームワークでは、デバイスが無効なデータなどのプロファイル検索エラーをPDSSに通知することを許可しないことに注意してください。フォローオン標準化アクティビティは、この機能に対処することが期待されています。
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.
ただし、このフレームワークでは、他のプロファイルタイプが展開ニーズを満たすためにアイデンティティや資格情報を提供することを妨げません。たとえば、ユーザープロファイルには、特定のアプリケーションと通信するためのアイデンティティと資格情報を含めることができます。
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の変更を伝播する1つの手段は、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 複数のSIPサービスプロバイダーが関与する場合があります。1つは、ユーザーがサブスクライブするサービス（テレフォニーサービス、インスタントメッセージングなど）をサブスクライブするものです。このフレームワークは、このようなシナリオで明示的な動作を指定するものではありませんが、その使用も禁止していません。
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の背後にあるデバイスをサポートするPDS、およびNATの背後にあるデバイスは、[RFC5626]で指定された手順を使用できます。アウトバウンドプロキシを構成または検出できます。そのような動作をサポートするクライアントは、サポートされているヘッダーフィールド値に「アウトバウンド」オプションタグを含め、[RFC5626]で指定されているように、プロファイル登録のSIPサブスクライブ内に「OB」パラメーターを追加する必要があります。
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イベントパッケージを提案および指定します。目的は、デバイスがPDSSを使用して特定のプロファイルタイプをサブスクライブし、PDSSがプロファイルデータまたはコンテンツの間接情報を使用してデバイスに通知できるようにすることです。
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-Profile」です。この値は、[RFC3265]で定義されているように、このパッケージのサブスクライブおよび通知に存在するイベントヘッダーフィールドに表示されます。
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 すべての新しいパラメーターは、「効果的な」パラメーターを除き、購読要求でのみ使用する必要があり、通知リクエストに表示される場合は無視する必要があります。
o The "effective-by" parameter is for use in NOTIFY requests only and MUST be ignored if it appears in SUBSCRIBE requests.
o 「効果的な」パラメーターは、通知要求のみで使用するためであり、購読要求に表示される場合は無視する必要があります。
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.
プロファイルタイプは、イベントヘッダーパラメーター「プロファイルタイプ」で識別されます。各プロファイルタイプに個別のサブスクライブダイアログが使用されます。したがって、通知が到着するサブスクリプションダイアログは、通知メッセージ本文によってどのプロファイルのデータが含まれているか、または参照されているかを意味します。サブスクライブリクエストの受け入れヘッダーには、サブスクライブユーザーエージェントがプロファイルの取得を希望するすべてのプロファイルコンテンツタイプの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を使用した次の構文定義では、[RFC3261]で等しいトークンとトークンが定義されています。追加のプロファイルタイプは、後続のドキュメントで定義される可能性があることに注意してください。
Profile-type = "profile-type" EQUAL profile-value
profile-value = profile-types / token
profile-types = "device" / "user" / "local-network"
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.
プロファイルタイプのパラメーターの「デバイス」、「ユーザー」、または「ローカルネットワーク」トークンは、プロファイルプロパティのクラスまたはセットを表す場合があります。特定のプロファイルコンテンツを定義するフォローオン標準では、プロファイルタイプのパラメーターの追加トークンを定義することが望ましい場合があります。また、追加のコンテンツタイプは、サブスクライブの受け入れヘッダーで使用できるプロファイル形式とともに定義することができます。
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].
「ベンダー」、「モデル」、および「バージョン」パラメーター値は、ユーザーエージェントの実装者によって指定されたトークンです。これらのパラメーターは、すべてのプロファイルタイプのサブスクライブリクエストで提供する必要があります。実装者は、DNSドメイン名（例：example.com）を「ベンダー」パラメーターの値として使用する必要があります。例外の例には、ベンダーに割り当てられたDNSドメイン名がない場合、別のベンダーの実装などを使用している場合、これらのパラメーターは、提供されるプロファイルに影響を与えるためにPDSに役立ちます。一部のシナリオでは、これらのパラメーターに基づいてさまざまなプロファイルを提供することが望ましいです。たとえば、プロファイルの機能プロパティXは、同じユーザーエージェントの2つのバージョンで異なる動作をする場合があります。これにより、PDSは違いを補償または活用する能力を提供します。構文を定義する以下のABNFでは、[RFC3261]で等しいと引用されたストリングが定義されています。
Vendor = "vendor" EQUAL quoted-string Model = "model" EQUAL quoted-string Version = "version" EQUAL quoted-string
vendor = "vendor" equal quoted-string model = "model" equal quoted-stringバージョン= "バージョン" equiooted-string
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リクエストのイベントヘッダーの「効果的な」パラメーターは、ユーザーエージェントが新しいプロファイルを効果的にしようとする必要がある最大秒数を指定します。「効果的な」パラメーターは、プロファイルタイプの任意のNotifyリクエストで提供される場合があります。0（ゼロ）の値は、サブスクライティングユーザーエージェントがプロファイルをすぐに有効にしようと試みなければならないことを示します（サービスの中断の可能性にもかかわらず）。これにより、プロファイルが効果的なときにPDSが制御する力が得られます。これは、緊急問題を解決したり、ユーザーエージェントをすぐに無効にしたりするために重要かもしれません。欠席している場合、デバイスは、提供されているサービスを混乱させない可能性のある機会にプロファイルデータを効果的にしようとする必要があります。「効果的な」パラメーターは、Notifyリクエスト以外のすべてのメッセージで無視されます。次のABNFでは、[RFC3261]で等しい桁と数字が定義されています。
Effective-By = "effective-by" EQUAL 1*DIGIT
effection by = "Effection-by"等しい1*桁
The following are example Event headers that may occur in SUBSCRIBE requests. These examples are not intended to be complete SUBSCRIBE requests.
以下は、購読要求で発生する可能性のあるイベントヘッダーの例です。これらの例は、完全な購読要求であることを意図したものではありません。
Event: ua-profile;profile-type=device;
vendor="vendor.example.com";model="Z100";version="1.2.3"
Event: ua-profile;profile-type=user;
vendor="premier.example.com";model="trs8000";version="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.
以下は、通知リクエストで発生する可能性のあるイベントヘッダーの例です。これらの例ヘッダーは、完全な購読要求であることを意図したものではありません。
Event: ua-profile;effective-by=0
Event: ua-profile;effective-by=3600
The following table shows the use of Event header parameters in SUBSCRIBE requests for the three profile types:
次の表は、3つのプロファイルタイプのサブスクライブリクエストでのイベントヘッダーパラメーターの使用を示しています。
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-提供する必要があります - 提供する必要があります - 提供するオプション
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つのプロファイルタイプの通知要求におけるイベントヘッダーパラメーターの使用を示しています。
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.
このパッケージは、購読要求本体の使用を定義していません。存在する場合は、無視する必要があります。例外には、購読要求本体の使用を指定する可能性のあるフレームワークの将来の強化が含まれます。
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展開に固有であり、このイベントパッケージによる具体的な推奨は行われません。不在の場合、デバイスのサブスクリプションの存在（または不在）がPDSの通常の機能に重要ではないため、86400秒（24時間; 1日）の値が推奨されます。
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]で指定されているように、「有効期限」パラメーターをゼロの値に設定することで、継続的なサブスクリプションなしで、プロファイルの1回限りのフェッチを実現できることに注意してください。
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へのポインターを介して配信されるプロファイルデータの場合、[RFC4483]に記載されているように、コンテンツID MIMEヘッダーは、各プロファイルドキュメント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.
空でない通知機関には、購読の受け入れヘッダーに指定されたMIMEタイプを含める必要があります。さらに、サブスクライブの受け入れヘッダーにMIMEタイプメッセージ/外部ボディ（コンテンツの間接のサポートを示す）が含まれている場合、PDSはプロファイルを提供するためにNotifyボディのコンテンツ間接を使用する場合があります。
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.
サブスクライブリクエストが成功すると、プロファイルの内容またはそれに対するポインターのいずれかの通知が発生します（コンテンツの間接を介して）。購読は、整合性保護されたSIP通信チャネルで認証されるか、送信する必要があります。例外には、サブスクライバーの身元が不明であり、通知者がそのような要求を受け入れるように構成されている場合が含まれます。
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.
通知者は、notifyがプロファイルデータへのポインターのみを含むと予想されている場合でも、サブスクライブメッセージを認証することもできます。コンテンツの間接を介して送信されたデータの保護されたデータは、セクション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).
「プロファイルタイプ」イベントヘッダーパラメーターに示されているプロファイルタイプが利用できない場合、または通知者がそれを提供しないように構成されている場合、notifierはサブスクライブリクエストに404応答を返す必要があります。特定のユーザーまたはデバイスが不明の場合、宛先はサブスクリプションを受け入れる場合があります。そうしないと、サブスクリプションを拒否する場合があります（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はプロファイルデータ（例：デフォルトのプロファイルデータ）で応答するか、プロファイル情報（つまり、空の通知）を提供できません。
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.
サブスクライブリクエスト（ヘッダーから）に示されているIDが既知のアイデンティティであり、要求されたプロファイル情報が利用可能である場合（つまり、イベントヘッダーの「プロファイルタイプ」パラメーターで指定されているように）。データ。プロファイルデータは、プロファイルの内容またはコンテンツの間接を介して送信される場合があります（コンテンツ間接MIMEタイプがAcceptヘッダーに含まれている場合）。Notifierは、「スキーム」コンタクトヘッダーフィールドに示されていないスキームを使用してはなりません。
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.
サブスクライブが整合性保護されたSIP通信チャネルを介して受信された場合、Notifierは同じチャネルで通知を送信する必要があります。
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]で指定された通知リクエスト処理動作を順守する必要があります。通知者が有効時間を示した場合（「効果的な」イベントヘッダーパラメーターを使用）、サブスクライバーは指定された時間内にプロファイルを有効にしようとします。例外には、特定の場合にそのような動作を禁止する展開が含まれます（たとえば、緊急セッションが進行中です）。推奨される時間枠内でプロファイルデータを適用できず、これがデバイスの動作に影響する場合、実行するアクションはプロファイルデータ定義によって定義する必要があります。デフォルトでは、サブスクライバーは、プロファイルをできるだけ早く効果的にするために推奨されます。
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 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.
コンテンツの間接を受け入れる場合、サブスクライバーは常に「http：」または「https：」をサポートし、それらのURIスキームで通知メッセージを受け入れる準備をしなければなりません。サブスクライバーが代替URIスキームをサポートしたい場合、[RFC4483]で定義されているように、「スキーム」に連絡するヘッダーフィールドパラメーターにそれぞれ示さなければなりません。サブスクライバーは、ボディのない通知要求を受信する準備もする必要があります。サブスクライバーは、本文なしで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で説明されているように、初期サブスクライブリクエストの結果として1つのダイアログのみを作成できます。Forked 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.
このフレームワークのプロファイルの通知率は展開固有ですが、まれになると予想されます。したがって、イベントパッケージの仕様では、通知リクエスト間のスロットリングまたは最小期間を指定しません。
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 TLSを超えるHTTPは、使用されるコンテンツ検索方法であると想定されています（適切な代替品も使用できます）。
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サブスクライブを使用して「デバイス」プロファイルのリクエストを送信します。
* 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 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）購読要求は、サービスプロバイダーのネットワークのSIPプロキシによって受信され、PDSに送信されます。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通知メッセージを送信します。
* 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> . . .
コンテンツタイプ：Application/x-z100-device-profile 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のプロファイルの取得のみを示していますが、他のプロファイル（Local-Network、Deviceなど）を要求して取得する場合があります。
----- -----
|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 a a a a a scood、登録、およびユーザーxのプロファイルに関連する通知を取得します。
(A-RX) Device A retrieves user X's profile.
（A-RX）デバイスユーザー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.
* 注：一意の識別子（UI）自体は、デバイスとして機能し、ユーザーXのプロファイルを購読できます。これは、示されている例ではそうではありません。
(HRes) Changes are accepted by the HTTP server.
（HRES）変更は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に通知メッセージを送信します。サンプルメッセージを以下に示します。
* Note: Some of the fields (e.g., Via) are continued on a separate line due to format constraints of this document.
* 注：このドキュメントのフォーマット制約により、一部のフィールド（たとえば、via）は別の行で継続されます。
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に通知メッセージを送信します。サンプルメッセージを以下に示します。
* Note: Some of the fields (e.g., Via) are continued on a separate line due to format constraints of this document.
* 注：このドキュメントのフォーマット制約により、一部のフィールド（たとえば、via）は別の行で継続されます。
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）デバイスユーザー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-Profile
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>
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.)
新しいイベントヘッダーパラメーター：プロファイルタイプ、ベンダー、モデル、バージョン、Effection-by（プロファイルタイプのパラメーターには定義値があります。新しいイベントヘッダーパラメーターはそうではありません。）
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]).
登録手順は、「RFCSで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.
このドキュメントは3つの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で登録してプロファイルデータを取得できます。リクエストを送信するために、デバイスは構成、キャッシュ、または発見されたデータに依存しています。このようなデータには、プロバイダードメイン名、アイデンティティ、および資格情報が含まれます。このデバイスは、構成されたアウトバウンドプロキシを使用するか、[RFC3263]を使用してNext-Hopエンティティを発見して、SIPプロキシまたはPDSをもたらす可能性があります。その後、リクエストを送信します。リクエストを受信するSIPプロキシでは、リクエスト-URIおよびイベントヘッダーコンテンツを使用してPDSにルーティングします（必要に応じて、他のSIPプロキシを介して）。
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が登録リクエストを受信すると、含まれるIDに挑戦するか、登録を認めることができます。承認規則は、登録が受け入れられるかどうかを決定します。受け入れられた場合、PDSは、プロファイルデータまたはコンテンツの間接情報のいずれかを含む初期通知を送信します。プロファイルデータには、一般的なプロファイルデータ（複数のデバイスで共通）またはエンティティに固有の情報（デバイスやユーザーなど）を含めることができます。エンティティに固有の場合、資格情報などの機密情報が含まれる場合があります。機密データの開示は、なりすまし攻撃（不正セッションの確立）、サービスの盗難（サービスが取得可能な場合）、ゾンビ攻撃などの脅威につながる可能性があります。SIPサービスプロバイダーのなりすましがDOSとMin-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攻撃（Rogueデバイスは特定のプロファイルのリクエストで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）が必要になる場合があります。このようなネットワークは、ユーザーのアイデンティティをデバイスに事前に構成し、ユーザー固有のローカルネットワークプロファイルを許可する場合があります。このようなネットワークでは、PDSは消化認証をサポートし、デバイスはセクション5.3.1で指定されているようにユーザーIDと資格情報で構成されます。機密性のプロファイルデータが送信されている場合、ユーザーIDはSIPS URIであり、次のホップ（認証）でTLSになり、Digest認証は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.
このフレームワークは、ユースケースとその間のバリエーションの両方をサポートします。ただし、認定されていないPDからローカルネットワークプロファイルを取得するデバイスは、潜在的な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 IDは、SIPS URIを使用したときにTLSなどの安全なチャネルがない場合に、デバイスが通知を検証するのに役立ちます。そのような場合、デバイスはSIP IDヘッダーを検証して、プロファイル通知のソースと、コンテンツの間接が使用されない場合のプロファイルデータのソースを確認できます。ただし、ヘッダーの存在は、データの有効性を保証するものではありません。ソースを検証し、データの整合性を確認しますが、望ましくないソースから取得したデータは、たとえば無効なアウトバウンドプロキシ情報、つまり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.
このフレームワークにより、デバイスプロファイルを使用すると、デバイスのブートストラップに使用できます。このようなブートストラッププロファイルデータには、プロバイダーに接続するのに十分な情報が含まれている場合があります。たとえば、デバイスがデバイスプロバイダーと通信し、視覚またはオーディオインターフェイス（インタラクティブな音声応答など）またはカスタマーサービスの代表者を介して試行または自己サブスクリプションサービスを可能にすることができます。プロファイルデータは、デバイスにデバイスプロバイダーの選択を許可し、エンドユーザーが1つを選択できるようにする場合があります。プロファイルデータには、ネットワークからさらなるプロファイルデータを取得するために使用できるアイデンティティと資格情報（一時的または長期的）が含まれる場合があります。このフレームワークは、PDSによるSIP IDヘッダーの使用を推奨しています。ただし、SIP IDヘッダーを検証できるようにするには、デバイスを検証用の許容ドメインまたは証明書の知識（PKIを使用するなど）で事前に構成する必要があります。そうでない場合、プロファイルデータにドメイン証明書が含まれている場合、デバイスはヘッダーとボディの完全性を保証できます（ただし、データはまだ無効または悪意があります）。そのような場合、ユーザーインターフェイスをサポートするデバイスは、デバイスをブートストラップしようとするユーザーからの確認を取得できます（ヘッダーと体の完全性を確認）。ただし、SIP IDヘッダーが存在しない場合、またはデバイスがそれを検証できない場合、ブートストラップデータは整合性保護なしに認識されず、取得されます。ただし、このようなブートストラップデータには、長期的な資格情報を取得する前にデータの整合性とデータの機密性を確保するためにネットワークに再接続するために使用できる一時的な資格情報（SIPS URIおよび消化資格情報）のみが含まれている場合があります。そのようなデバイスは、デバイスプロファイルを要求するネットワークに翻弄されていることに注意してください。不正なネットワークで初期化されている場合、または不正なPDSにハイジャックされた場合、エンドユーザーは、望ましいデバイス操作またはさらに悪いことに不要な操作なしに残される場合があります。このような要因を軽減するために、デバイスプロバイダーは、接続のためにエンドユーザーに、一時的な資格情報（インターフェイスを介して入力できるパスワード）または永続的な資格情報（USBデバイスなど）を通信する場合があります。そのような方法を使用する場合、これらの資格情報は、辞書攻撃の影響を最小限に抑えるために、大規模なエントロピー資格情報にすばやく置き換える必要があります。このフレームワークの将来の拡張により、プロバイダー固有の構成なしで認証を可能にするデバイス機能を指定できます（たとえば、PKIを使用したX.509証明書は、CA証明書にアクセスできるプロバイダーによる認証を可能にすることができます）。あるいは、デバイスは、コンテンツの間接メカニズムで使用するための資格情報で事前に構成されている場合があります。このような状況では、PDは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.
デバイスがデバイスプロバイダーに関連付けられると、デバイスプロファイルはデバイスの操作に不可欠です。これは、デバイスプロファイルに、アクセスを許可されるユーザー（ホワイトリストまたはブラックリスト）、ユーザー資格情報（必要に応じて）、その他の機密情報などの重要な運用情報を含めることができるためです。したがって、機密情報を含むデバイスプロファイルが、整合性保護を備えた認証されたソースを介して取得され、認証されたデバイスに配信されることを確認する必要があります。資格情報などの機密情報の場合、データの機密性も必要です。このフレームワークでは、デバイスがブートストラップされている場合を除き、認証されたエンティティからのみ機密情報を取得する必要があります。データの機密性を通知に義務付けられる必要がある場合、デバイスプロバイダーは、プロファイルの登録中に、サブスクリプションURIとして使用するSIPS URIでデバイスを構成できます。また、このフレームワークでは、Digest認証を使用するために機密性の高いプロファイルデータを提示するPDSも必要です。これにより、データが認証されたエンティティに配信されることが保証されます。機密プロファイルのコンテンツ間接を介したプロファイル検索の認証は、HTTPダイジェストを使用したHTTPを介して行われます。
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).
プロファイルを取得することが許可されている既知のユーザーAORSの場合、セキュリティ上の考慮事項は、デバイスプロファイル（ブートストラップを除く）の考慮事項に似ています。
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.
著者は、この文書の多くの反復について貢献し、コメントしたすべての人々に感謝しています。ジョナサン・ローゼンバーグ、ヘニング・シュルツリン、カレン・ジェニングス、ローハン・マヒー、リッチ・シャフ、ヴォルカー・ヒルト、アダム・ローチ、ヒシャム・ハルタビル、ヘンリー・シンライヒ、マーティン・ドーリー、ジョン・エルウェル、エリオット・アイヒエン、ロバート・リアオ、ダーバル・リアオ、ダール・ワーリー、Francois Audet、Roni Even、Jason Fischl、Josh Littlefield、Nhut Nguyen。
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）、ピーターブラザーウィック（セクション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.
以下の設計チームのメンバーは、マーティン・ドリー、ジェイソン・フィシュル、アルビン・ジャン、フランソワ・オーデットの多くのレビューと一般的な貢献に感謝しています。
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).
以下のすすりのWGメンバーは、ジョン・エルウェル、ドナルド・ルカックス、ロニ・イヴ・イヴビンズ、デビッド・ロビンズ、シダ・シューベルト、ユージン・ネカムキンの数々のレビュー、コメント、推奨事項に感謝しています。編集者はまた、Sipping WG、特にKeith Drage（再編の提案）とJohn Elwell（多数のレビューと推奨事項）によって提供されたコメントと推奨事項に特別な感謝を拡大したいと考えています。
Additionally, appreciation is also due to Peter Koch for expert DNS advice.
さらに、感謝は、専門家のDNSアドバイスに対するPeter Kochによるものでもあります。
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).
最後に、誠実な感謝は椅子に拡張されます（メアリー・バーンズとゴンザロ・カマリロ）。議論、レビュー、貢献を促進した過去/現在のエリアディレクター（Cullen Jennings、Jon Peterson、およびRobert Sparks）。そして、IESGの専門家レビュアー（Peter McCann、Catherine Meadows）。
[FIPS-180-3] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]国立標準技術研究所（NIST）、「Secure Hash Standard（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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. Volz、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPV6）オプション」、RFC 3319、2003年7月。
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[RFC3361] Schulzrinne、H。、「Dynamic Host Configuration Protocol（DHCP-For-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] Leach、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483] Burger、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] Volz、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] Crocker、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[PHONEBCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, October 2010.
[PhoneBCP] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の実践」、2010年10月の作業。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、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。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634] Eastlake、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and HMAC-SHA）」、RFC 4634、2006年7月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
Authors' Addresses
著者のアドレス
Daniel Petrie SIPez LLC 246A Park Ave Arlington, MA 02476 USA
ダニエル・ペトリー・シペスLLC 246Aパークアベニューアーリントン、マサチューセッツ州02476 USA
EMail: dan.ietf@SIPez.com
URI: http://www.SIPez.com/
Sumanth Channabasappa (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA
Sumanth Channabasappa（編集者）CableLabs 858 Coal Creek Circle Louisville、Co 80027 USA
EMail: sumanth@cablelabs.com
URI: http://www.cablelabs.com/