[要約] RFC 3944は、H.350ディレクトリサービスに関する標準仕様です。このRFCの目的は、VoIPネットワーク内のユーザー情報を効率的に管理し、検索するための統一的なディレクトリサービスを提供することです。
Network Working Group T. Johnson
Request for Comments: 3944 U. of North Carolina
Category: Informational S. Okubo
Waseda University
S. Campos
ITU-T
December 2004
H.350 Directory Services
H.350 ディレクトリ サービス
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネット コミュニティに情報を提供します。いかなる種類のインターネット標準も指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store.
国際電気通信連合標準化部門 (ITU-T) は、マルチメディア会議プロトコルをサポートするディレクトリ サービス アーキテクチャを指定する H.350 シリーズの勧告を作成しました。このアーキテクチャの目標は、マルチメディア会議を「ディレクトリ対応」にして、これらのサービスが既存の ID 管理とエンタープライズ ディレクトリを活用できるようにすることです。特定の目標は、企業またはサービス プロバイダーがユーザーとそのマルチメディア会議システムの正規のソースを維持できるようにして、複数のプロトコルをサポートする複数のベンダーの複数のコール サーバーがすべて同じデータ ストアにアクセスできるようにすることです。
Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version.
SIP は IETF 標準であるため、H.350 および H.350.4 のコンテンツは、このドキュメントを通じて IETF コミュニティに提供されます。この文書には、ITU-T 勧告 H.350 と H.350.4 のセクション 4 と 5 の規範テキスト全体が含まれています。残りのセクションは、この文書にのみ含まれており、ITU-T バージョンには含まれていません。
Table of Contents
目次
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions used in this document . . . . . . . . . . . . . . 4
4. H.350 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Design Goals . . . . . . . . . . . . . . . . . . 6
4.1.2. Extending the Schema . . . . . . . . . . . . . . 7
4.2. commURIObject Definition. . . . . . . . . . . . . . . . 10
4.2.1. commURIObject. . . . . . . . . . . . . . . . . . 10
4.2.2. commURI. . . . . . . . . . . . . . . . . . . . . 10
4.3. CommObject Definition . . . . . . . . . . . . . . . . . 11
4.3.1. commObject . . . . . . . . . . . . . . . . . . . 11
4.3.2. commUniqueId . . . . . . . . . . . . . . . . . . 11
4.3.3. commOwner. . . . . . . . . . . . . . . . . . . . 12
4.3.4. commPrivate. . . . . . . . . . . . . . . . . . . 13
4.4. CommObject LDIF Files . . . . . . . . . . . . . . . . . 13
4.4.1. LDIF for commURIObject . . . . . . . . . . . . . 13
4.4.2. LDIF for commObject. . . . . . . . . . . . . . . 15
4.5. H.350 Annex A Indexing Profile. . . . . . . . . . . . . 17
5. H.350.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Extending the schema . . . . . . . . . . . . . . 18
5.2. Object class definitions. . . . . . . . . . . . . . . . 18
5.2.1. SIPIdentity. . . . . . . . . . . . . . . . . . . 18
5.2.2. SIPIdentitySIPURI. . . . . . . . . . . . . . . . 19
5.2.3. SIPIdentityRegistrarAddress. . . . . . . . . . . 19
5.2.4. SIPIdentityProxyAddress. . . . . . . . . . . . . 20
5.2.5. SIPIdentityAddress . . . . . . . . . . . . . . . 21
5.2.6. SIPIdentityPassword. . . . . . . . . . . . . . . 21
5.2.7. SIPIdentityUserName. . . . . . . . . . . . . . . 22
5.2.8. SIPIdentityServiceLevel. . . . . . . . . . . . . 23
5.3. SIPIdentity LDIF Files. . . . . . . . . . . . . . . . . 23
5.4. H.350.4 Annex A Indexing profile. . . . . . . . . . . . 26
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References. . . . . . . . . . . . . . . . . . 28
8.2. Informative References. . . . . . . . . . . . . . . . . 28
9. Relationship to Other Specifications. . . . . . . . . . . . . 29
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 30
The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store.
国際電気通信連合標準化部門 (ITU-T) は、マルチメディア会議プロトコルをサポートするディレクトリ サービス アーキテクチャを指定する H.350 シリーズの勧告を作成しました。このアーキテクチャの目標は、マルチメディア会議を「ディレクトリ対応」にして、これらのサービスが既存の ID 管理とエンタープライズ ディレクトリを活用できるようにすることです。特定の目標は、企業またはサービス プロバイダーがユーザーとそのマルチメディア会議システムの正規のソースを維持できるようにして、複数のプロトコルをサポートする複数のベンダーの複数のコール サーバーがすべて同じデータ ストアにアクセスできるようにすることです。
H.350 architectures are not intended to change the operation of multimedia conferencing protocols in any way. Rather, they are meant to standardize the way the already defined protocol elements are stored in a directory, so that they can be accessed in a standardized manner.
H.350 アーキテクチャは、いかなる形でもマルチメディア会議プロトコルの動作を変更することを意図したものではありません。むしろ、すでに定義されているプロトコル要素をディレクトリに保存する方法を標準化し、標準化された方法でアクセスできるようにすることを目的としています。
In the H.350 series, Recommendation H.350 specifies the base architecture and object classes, while subordinate Recommendations specify elements that are specific to individual protocols. Currently, the Recommendations include:
H.350 シリーズでは、推奨 H.350 で基本アーキテクチャとオブジェクト クラスが指定され、下位の推奨で個々のプロトコルに固有の要素が指定されます。現在、推奨事項には次のものが含まれます。
H.350 - Directory Services Architecture for Multimedia Conferencing H.350.1 - Directory Services Architecture for H.323 H.350.2 - Directory Services Architecture for H.235 H.350.3 - Directory Services Architecture for H.320 H.350.4 - Directory Services Architecture for SIP H.350.5 - Directory Services Architecture for Non-Standard Protocols
H.350 - マルチメディア会議用のディレクトリ サービス アーキテクチャ H.350.1 - H.323 のディレクトリ サービス アーキテクチャ H.350.2 - H.235 のディレクトリ サービス アーキテクチャ H.350.3 - H.320 のディレクトリ サービス アーキテクチャ H.350.4 - ディレクトリ サービス アーキテクチャSIP H.350.5 用 - 非標準プロトコル用のディレクトリ サービス アーキテクチャ
Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community.
SIP は IETF 標準であるため、H.350 および H.350.4 のコンテンツは、このドキュメントを通じて IETF コミュニティに提供されます。
The following terms are used throughout the document:
この文書全体で次の用語が使用されます。
* call server: a protocol-specific signalling engine that routes video or voice calls on the network. In H.323 this entity is a gatekeeper. In SIP, this entity is a SIP Proxy Server. Note that not all signalling protocols use a call server.
* コール サーバー: ネットワーク上でビデオ コールまたは音声コールをルーティングするプロトコル固有のシグナリング エンジン。H.323 では、このエンティティはゲートキーパーです。SIP では、このエンティティは SIP プロキシ サーバーです。すべてのシグナリング プロトコルがコール サーバーを使用するわけではないことに注意してください。
* endpoint: a logical device that provides video and/or voice media encoding/decoding, and signalling functions. Examples include:
* エンドポイント: ビデオおよび/または音声メディアのエンコード/デコード、およびシグナリング機能を提供する論理デバイス。例としては次のものが挙げられます。
* a group teleconferencing appliance that is located in a conference room
* 会議室に設置されるグループテレビ会議アプライアンス
* an IP telephone.
* IP電話。
* a software program that takes video and voice from a camera and microphone and encodes it and applies signalling using a host computer.
* カメラとマイクからビデオと音声を取得し、それをエンコードし、ホスト コンピューターを使用して信号を適用するソフトウェア プログラム。
* enterprise directory: A canonical collection of information about users in an organization. Typically this information is collected from a variety of organizational units to create a whole. For example, Human Resources may provide name and address, Telecommunications may provide the telephone number, Information Technology may provide the email address, etc. For the purposes of this architecture, it is assumed that an enterprise directory is accessible via LDAP.
* エンタープライズ ディレクトリ: 組織内のユーザーに関する情報の正規のコレクション。通常、この情報はさまざまな組織単位から収集され、全体が作成されます。たとえば、人事部門は名前と住所を提供し、電気通信部門は電話番号を提供し、情報技術部門は電子メール アドレスを提供する場合があります。このアーキテクチャの目的上、エンタープライズ ディレクトリは LDAP 経由でアクセスできると想定されています。
* White Pages: An application that allows end users to look up the address of another user. This may be web-based or use some other user interface.
* ホワイト ページ: エンド ユーザーが別のユーザーのアドレスを検索できるようにするアプリケーション。これは Web ベースである場合もあれば、他のユーザー インターフェイスを使用している場合もあります。
Conventions in this document conform to ITU-T guidelines. In this Recommendation, the following conventions are used:
この文書の表記規則は ITU-T ガイドラインに準拠しています。この勧告では、次の規則が使用されます。
"Shall" indicates a mandatory requirement.
「するものとする」は必須要件を示します。
"Should" indicates a suggested but optional course of action.
「すべき」は、提案されているがオプションの行動方針を示します。
"May" indicates an optional course of action rather than a recommendation that something take place.
「かもしれない」は、何かが行われるという推奨ではなく、任意の行動方針を示します。
References to clauses, sub clauses, annexes and appendices refer to those items within this Recommendation unless another specification is explicitly listed.
別の仕様が明示的にリストされている場合を除き、条項、下位条項、付録および付録への参照は、この勧告内の項目を指します。
The normative text of H.350 is reproduced in this section.
このセクションでは、H.350 の規範テキストが再掲されます。
This Recommendation describes a directory services architecture for multimedia conferencing using LDAP. Standardized directory services can support association of persons with endpoints, searchable white pages, and clickable dialling. Directory services can also assist in the configuration of endpoints, and user authentication based on authoritative data sources. This document describes a standardized LDAP schema to represent endpoints on the network and associate those endpoints with users. It discusses design and implementation considerations for the inter-relation of video and voice-specific directories, enterprise directories, call servers and endpoints.
この勧告では、LDAP を使用したマルチメディア会議のためのディレクトリ サービス アーキテクチャについて説明します。標準化されたディレクトリ サービスは、個人とエンドポイントの関連付け、検索可能なホワイト ページ、およびクリック可能なダイヤルをサポートできます。ディレクトリ サービスは、エンドポイントの構成や、信頼できるデータ ソースに基づくユーザー認証にも役立ちます。このドキュメントでは、ネットワーク上のエンドポイントを表し、それらのエンドポイントをユーザーに関連付ける標準化された LDAP スキーマについて説明します。ビデオおよび音声固有のディレクトリ、エンタープライズ ディレクトリ、コール サーバー、およびエンドポイントの相互関係に関する設計と実装の考慮事項について説明します。
The use of a common, authoritative data source for call server, endpoint, user, authentication and white pages information is an important aspect of large scale multimedia conferencing environments. Without a common data source, service providers must create separate processes to manage each of these functions. By standardizing the LDAP schema used to represent the underlying data, products from different system vendors can be deployed together to create an overall application environment. For example, a white pages search engine developed by one provider could serve directory information to IP telephones produced by a second provider, with signalling managed by a call server produced by yet a third provider. Each of these disparate systems can access the same underlying data source, reducing or eliminating the need to coordinate separate management of each system. A significant benefit to the user is that the management of this data can be incorporated into existing customer management tools, allowing for quick and flexible scaling up of applications. Indeed, many technology providers have already incorporate LDAP into their products, but have been forced to do so without benefit of a standardized schema. This Recommendation represents an effort to standardize those representations to improve interoperability and performance.
コール サーバー、エンドポイント、ユーザー、認証、およびホワイト ページ情報に共通の信頼できるデータ ソースを使用することは、大規模なマルチメディア会議環境の重要な側面です。共通のデータ ソースがなければ、サービス プロバイダーはこれらの各機能を管理するための個別のプロセスを作成する必要があります。基礎となるデータを表すために使用される LDAP スキーマを標準化することにより、さまざまなシステム ベンダーの製品を一緒に導入して全体的なアプリケーション環境を作成できます。たとえば、あるプロバイダーが開発したホワイト ページ検索エンジンは、さらに 3 番目のプロバイダーが作成したコール サーバーが管理するシグナリングを使用して、2 番目のプロバイダーが作成した IP 電話にディレクトリ情報を提供できます。これらの異種システムはそれぞれ、基盤となる同じデータ ソースにアクセスできるため、各システムの個別の管理を調整する必要性が軽減または排除されます。ユーザーにとっての大きな利点は、このデータの管理を既存の顧客管理ツールに組み込むことができ、アプリケーションを迅速かつ柔軟にスケールアップできることです。実際、多くのテクノロジー プロバイダーはすでに LDAP を製品に組み込んでいますが、標準化されたスキーマの恩恵を受けずに組み込むことを余儀なくされています。この勧告は、相互運用性とパフォーマンスを向上させるためにこれらの表現を標準化する取り組みを表しています。
While URLs are already standardized for several conferencing protocols, their representation in a directory is not. This Recommendation supports a standardized way for URLs to be searched and located. This is a necessary step to support 'clickable dialling'.
URL はいくつかの会議プロトコル用にすでに標準化されていますが、ディレクトリ内での URL の表現は標準化されていません。この推奨事項は、URL を検索および特定するための標準化された方法をサポートします。これは、「クリック可能なダイヤル」をサポートするために必要な手順です。
Management of endpoint configurations can be improved if the correct settings are stored by the service provider in a location that is accessible to both service provider and endpoint. LDAP provides a convenient storage location that can be accessed by both call server and endpoint; thus it is possible to use the directory to support endpoint configuration, which is important for simplified operation and supporting user mobility. Note that other technologies also support endpoint configuration, notably the use of SNMP for complete configuration and SRV records for obtaining registration server addresses. Therefore, H.350 should be viewed not as an authoritative endpoint configuration architecture, but rather one tool that can assist with this task. Note that the use of H.350 has as a feature endpoint specific configuration, where it is desirable that each endpoint has a unique configuration.
サービス プロバイダーとエンドポイントの両方がアクセスできる場所にサービス プロバイダーによって正しい設定が保存されている場合、エンドポイント構成の管理を改善できます。LDAP は、コール サーバーとエンドポイントの両方からアクセスできる便利な保存場所を提供します。したがって、ディレクトリを使用してエンドポイント構成をサポートすることができます。これは、操作を簡素化し、ユーザーのモビリティをサポートするために重要です。他のテクノロジーもエンドポイント構成をサポートしていることに注意してください。特に、完全な構成のための SNMP の使用と、登録サーバーのアドレスを取得するための SRV レコードの使用がサポートされています。したがって、H.350 は、権威あるエンドポイント構成アーキテクチャとしてではなく、このタスクを支援できる 1 つのツールとして見なされるべきです。H.350 の使用にはエンドポイント固有の構成が機能として含まれており、各エンドポイントが固有の構成を持つことが望ましいことに注意してください。
This architecture uses a generic object class, called commObject, to represent attributes common to any video or voice protocol. Auxiliary classes represent specific protocols, such as H.323, H.235, or H.320, as described in the H.350.x series of Recommendations. Multiple H.350.x classes can be combined to represent endpoints that support more than one protocol. For example, endpoints that support H.323, H.235 and H.320 would include H.350, H.350.1, H.350.2, and H.350.3 in their LDAP representations. Further, each entry should contain commObject to serve as the entry's structural object class.
このアーキテクチャでは、commObject と呼ばれる汎用オブジェクト クラスを使用して、ビデオまたは音声プロトコルに共通の属性を表します。補助クラスは、H.350.x シリーズの推奨事項で説明されているように、H.323、H.235、または H.320 などの特定のプロトコルを表します。複数の H.350.x クラスを組み合わせて、複数のプロトコルをサポートするエンドポイントを表すことができます。たとえば、H.323、H.235、および H.320 をサポートするエンドポイントには、LDAP 表現に H.350、H.350.1、H.350.2、および H.350.3 が含まれます。さらに、各エントリには、エントリの構造オブジェクト クラスとして機能する commObject が含まれている必要があります。
There are two basic components in the architecture. The commURI object is a class whose only purpose is to link a person or resource to a commObject. By placing a commURI 'pointer' in an individual's directory entry, that individual becomes associated with the particular targeted commObject. Similarly, commObject contains a pointer, called commOwner, which points to the individual or resource that is associated with the commObject. In this way, people or resources can be associated with endpoints. The only change required in the enterprise directory is the addition of the simple object class commURI. CommObject data may be instantiated in the same or in entirely separate directories, thus allowing flexibility in implementation.
アーキテクチャには 2 つの基本コンポーネントがあります。commURI オブジェクトは、人またはリソースを commObject にリンクすることだけを目的とするクラスです。commURI の「ポインター」を個人のディレクトリ エントリに配置すると、その個人は特定の対象となる commObject に関連付けられます。同様に、commObject には commOwner と呼ばれるポインタが含まれており、このポインタは commObject に関連付けられた個人またはリソースを指します。このようにして、人やリソースをエンドポイントに関連付けることができます。エンタープライズ ディレクトリで必要な唯一の変更は、単純なオブジェクト クラス commURI の追加です。CommObject データは、同じディレクトリまたはまったく別のディレクトリでインスタンス化できるため、実装が柔軟になります。
Large-scale deployments of IP video and voice services have demonstrated the need for complementary directory services middleware. Service administrators need call servers that are aware of enterprise directories to avoid duplication of account management processes. Users need 'white pages' to locate other users with whom they wish to communicate. All of these processes should pull their information from canonical data sources in order to reduce redundant administrative processes and ensure information accuracy. The following design criteria are established for this architecture. The architecture will:
IP ビデオおよび音声サービスの大規模展開により、補完的なディレクトリ サービス ミドルウェアの必要性が実証されました。サービス管理者は、アカウント管理プロセスの重複を避けるために、エンタープライズ ディレクトリを認識するコール サーバーを必要とします。ユーザーは、通信したい他のユーザーを見つけるために「ホワイト ページ」を必要とします。冗長な管理プロセスを削減し、情報の正確性を確保するために、これらのプロセスはすべて、正規のデータ ソースから情報を取得する必要があります。このアーキテクチャでは次の設計基準が確立されています。アーキテクチャは次のことを行います。
1) enable endpoint information to be associated with people. Alternately it enables endpoint information to be associated with resources such as conference rooms or classrooms;
1) エンドポイント情報を人々に関連付けることができます。あるいは、エンドポイント情報を会議室や教室などのリソースに関連付けることもできます。
2) enable online searchable "white pages" where dialling information (e.g., endpoint addresses) can be found, along with other "traditional" directory information about a user, such as name, address, telephone, email, etc.;
2) 名前、住所、電話番号、電子メールなど、ユーザーに関する他の「従来の」ディレクトリ情報とともに、ダイヤル情報 (エンドポイント アドレスなど) を見つけることができるオンライン検索可能な「ホワイト ページ」を有効にします。
3) enable all endpoint information to be stored in a canonical data source (the Directory), rather than local to the call server, so that endpoints can be managed through manipulations of an enterprise directory, rather than by direct entry into the call server;
3) すべてのエンドポイント情報をコール サーバーのローカルではなく正規のデータ ソース (ディレクトリ) に保存できるようにすることで、コール サーバーに直接入力するのではなく、エンタープライズ ディレクトリの操作を通じてエンドポイントを管理できるようになります。
4) support the creation of very large-scale distributed directories. These include white pages "portals" that allow searching for users across multiple institutional directories. In this application, each enterprise directory registers itself with (or is unknowingly discovered by) a directory of directories that is capable of searching across multiple LDAP directories;
4) 非常に大規模な分散ディレクトリの作成をサポートします。これらには、複数の機関ディレクトリにわたるユーザーの検索を可能にするホワイト ページ「ポータル」が含まれます。このアプリケーションでは、各エンタープライズ ディレクトリは、複数の LDAP ディレクトリを検索できるディレクトリのディレクトリにそれ自体を登録します (または、知らず知らずのうちに検出されます)。
5) be able to support multiple instances of endpoints per user or resource;
5) ユーザーまたはリソースごとにエンドポイントの複数のインスタンスをサポートできる。
6) represent endpoints that support more than one protocol, for example, endpoints that are both H.320 and H.323;
6) 複数のプロトコルをサポートするエンドポイント (たとえば、H.320 と H.323 の両方のエンドポイント) を表します。
7) store enough information about endpoint configuration so that correct configuration settings can be documented to end users on a per-endpoint basis, as a support tool, or loaded automatically into the endpoint;
7) エンドポイント構成に関する十分な情報を保存して、正しい構成設定をサポート ツールとしてエンドポイントごとにエンド ユーザーに文書化したり、エンドポイントに自動的にロードしたりできるようにします。
8) be extendible as necessary to allow implementation-specific attributes to be included;
8) 実装固有の属性を含めることができるように、必要に応じて拡張可能であること。
9) be non-invasive to the enterprise directory, so that support for multimedia conferencing can be added in a modular fashion without significant changes to the enterprise directory.
9) エンタープライズ ディレクトリに対して非侵襲的であるため、エンタープライズ ディレクトリに大幅な変更を加えることなく、モジュール形式でマルチメディア会議のサポートを追加できます。
The scope of this Recommendation does not include extensions of functionality to protocols as defined within the protocols themselves. It is not the intent of the Recommendation to add features, but merely to represent existing protocol attributes. The exception to this case is when functionality is implied by the directory itself, such as the commPrivate attribute.
この勧告の範囲には、プロトコル自体の中で定義されているプロトコルへの機能の拡張は含まれません。この勧告の目的は機能を追加することではなく、単に既存のプロトコル属性を表すことです。この場合の例外は、commPrivate 属性など、ディレクトリ自体によって機能が暗黙的に指定されている場合です。
H.350 object classes may be extended as necessary for specific implementations. For example, a class may be extended to support billing reference codes. Extensions to the schema are not considered as part of the Recommendation and do not signify compliance.
H.350 オブジェクト クラスは、特定の実装の必要に応じて拡張できます。たとえば、クラスは、請求参照コードをサポートするように拡張できます。スキーマの拡張は推奨事項の一部とみなされず、準拠を示すものではありません。
In some cases it may be necessary to extend the H.350 schemas in order to represent more information than is supported by the Recommendations. This may be important for developers that implement proprietary endpoint functionality that needs to be represented by attributes in the directory. It may also be important for enterprise applications. For example 'modelNumber', and 'accountNumber' are examples of attributes that are not defined in the Recommendation but may be useful if implemented. Adding attributes to this architecture must be done in a way that does not break compatibility with this Recommendation.
場合によっては、推奨事項でサポートされている以上の情報を表現するために、H.350 スキーマを拡張する必要がある場合があります。これは、ディレクトリ内の属性で表す必要がある独自のエンドポイント機能を実装する開発者にとって重要になる可能性があります。エンタープライズ アプリケーションにとっても重要な場合があります。たとえば、「modelNumber」および「accountNumber」は、推奨事項では定義されていないが、実装されれば役立つ可能性がある属性の例です。このアーキテクチャに属性を追加する場合は、この推奨事項との互換性を損なわない方法で行う必要があります。
A full discussion of schema design and extension is beyond the scope of this Recommendation. See IETF RFC 2252 for details. Two basic approaches to schema extension that do not break compatibility with this Recommendation, are extension through subclass and extension through the use of auxiliary classes.
スキーマの設計と拡張についての詳しい説明は、この推奨事項の範囲を超えています。詳細については、IETF RFC 2252 を参照してください。この勧告との互換性を損なわないスキーマ拡張への 2 つの基本的なアプローチは、サブクラスによる拡張と補助クラスの使用による拡張です。
It is possible to create a subclass of an existing predefined object class in order to add new attributes to it. To create a subclass, a new object class must be defined, that is a subclass of the existing one, by indicating in the definition of the new class that the existing class is its superior. Once the subclass is created, new attributes can be defined within it.
既存の定義済みオブジェクト クラスのサブクラスを作成して、それに新しい属性を追加することができます。サブクラスを作成するには、新しいクラスの定義で既存のクラスが上位であることを示すことによって、既存のクラスのサブクラスである新しいオブジェクト クラスを定義する必要があります。サブクラスが作成されると、その中で新しい属性を定義できます。
The following example shows how the commObject class can be subclassed in order to add an attribute to represent a billing account and a billing manager.
次の例は、請求先アカウントと請求管理者を表す属性を追加するために commObject クラスをサブクラス化する方法を示しています。
objectclass ( BillingInfo-OID NAME 'BillingInfo' DESC 'Billing Reference Information' SUP commObject STRUCTURAL MAY ( BillingAccount $ BillingManager $ ) )
objectclass ( BillingInfo-OID NAME 'BillingInfo' DESC '請求参照情報' SUP commObject STRUCTURAL MAY ( BillingAccount $ BillingManager $ ) )
Note that BillingInfo-OID must be replaced by an actual OID. Also note that, whenever a structural class is extended, its subclass must also be structural.
BillingInfo-OID は実際の OID に置き換える必要があることに注意してください。また、構造クラスが拡張される場合は常に、そのサブクラスも構造クラスでなければならないことに注意してください。
The following sample entry shows the newly created attributes. This example also uses ITU-T Rec. H.350.1 for h323Identity.
次のサンプル エントリは、新しく作成された属性を示しています。この例でも ITU-T Rec を使用します。h323Identity の H.350.1。
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: h323Identity
objectclass: BillingInfo
commUniqueId: 2000
BillingAccount: 0023456
BillingManager: John Smith
Note that this example and approach demonstrate extension of the general commObject object class, and not any individual H.350.x classes. If it is desired to extend an H.350.x auxiliary class, then that should be accomplished through the definition of additional auxiliary classes that support the desired attributes, as described in section 4.1.2.2.
この例とアプローチは、個別の H.350.x クラスではなく、一般的な commObject オブジェクト クラスの拡張を示していることに注意してください。H.350.x 補助クラスを拡張したい場合は、セクション 4.1.2.2 で説明されているように、必要な属性をサポートする追加の補助クラスを定義することによって実現する必要があります。
It is possible to add attributes to an LDAP entry by defining an auxiliary class containing the new attributes and applying those attributes to instantiated values in the directory. The auxiliary class will not be subclassed from any existing object class. Note that it should have the special class top as its superior. The following example creates the same billing account and billing manager attributes as the previous example, but does so by defining them in their own auxiliary class.
新しい属性を含む補助クラスを定義し、それらの属性をディレクトリ内のインスタンス化された値に適用することにより、LDAP エントリに属性を追加できます。補助クラスは、既存のオブジェクト クラスからサブクラス化されません。なお、特級トップを上司とする必要がある。次の例では、前の例と同じ請求先アカウントおよび請求管理者の属性を作成しますが、これを独自の補助クラスで定義することによって実行します。
objectclass ( BillingInfo-OID NAME 'BillingInfo' DESC 'Billing Reference Information' SUP top AUXILIARY MAY ( BillingAccount $ BillingManager $ ) )
objectclass ( BillingInfo-OID NAME 'BillingInfo' DESC '請求参照情報' SUP top AUXILIARY MAY ( BillingAccount $ BillingManager $ ) )
Note how the superior was changed from commObject to top and the object class changed from being a structural to auxiliary.
上位クラスが commObject から top に変更され、オブジェクト クラスが構造クラスから補助クラスにどのように変更されたかに注目してください。
It is recommended that all attributes in the auxiliary class be optional rather than mandatory. In this way, the auxiliary object class itself can be associated with an entry regardless of whether any values for its attributes are present.
補助クラスのすべての属性は必須ではなくオプションにすることをお勧めします。このようにして、その属性の値が存在するかどうかに関係なく、補助オブジェクト クラス自体をエントリに関連付けることができます。
The following example shows a sample endpoint that utilizes the new auxiliary class and attributes. This example also uses H.350.1 for h323Identity.
次の例は、新しい補助クラスと属性を利用するサンプル エンドポイントを示しています。この例でも、h323Identity に H.350.1 を使用します。
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: BillingInfo
commUniqueId: 2000
BillingAccount: 0023456
BillingManager: John Smith
An attribute's Object Identifier (OID) is a unique numerical identifier usually written as a sequence of integers separated by dots. For example, the OID for the commUniqueId is 0.0.8.350.1.1.2.1.1. All attributes must have an OID. OIDs can be obtained from anyone who has one and is willing to delegate a portion of it as an arc, keeping a record of the arc to avoid duplication. Further, the Internet Assigned Numbers Authority (IANA) gives out OIDs to any organization that asks.
属性のオブジェクト識別子 (OID) は、通常、ドットで区切られた一連の整数として記述される一意の数値識別子です。たとえば、commUniqueId の OID は 0.0.8.350.1.1.2.1.1 です。すべての属性には OID が必要です。OID は、OID を持っていて、その一部をアークとして委任する意思のある人なら誰でも取得でき、重複を避けるためにアークの記録を保持します。さらに、Internet Assigned Numbers Authority (IANA) は、要求した組織に OID を配布します。
Auxiliary object class that contains the commURI attribute. This attribute is added to a person or resource object to associate one or more commObject instances with that object. Its values are LDAP URIs that point to the associated commObjects, for example, to a user's H.323 conferencing station and SIP IP phone. Note that multiple instances of commURI need not point to the same commObject directory. In fact, each commURI instance could point to an endpoint managed by a different service provider.
commURI 属性を含む補助オブジェクト クラス。この属性は、人物オブジェクトまたはリソース オブジェクトに追加され、1 つ以上の commObject インスタンスをそのオブジェクトに関連付けます。その値は、関連する commObject (たとえば、ユーザーの H.323 会議ステーションや SIP IP 電話) を指す LDAP URI です。commURI の複数のインスタンスが同じ commObject ディレクトリを指す必要はないことに注意してください。実際、各 commURI インスタンスは、異なるサービス プロバイダーによって管理されるエンドポイントを指すことができます。
OID: 0.0.8.350.1.1.1.2.1 objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' DESC 'object that contains the URI attribute type' SUP top AUXILIARY MAY ( commURI ) )
OID: 0.0.8.350.1.1.1.2.1 objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' DESC 'URI 属性タイプを含むオブジェクト' SUP top AUXILIARY MAY ( commURI ) )
OID: 0.0.8.350.1.1.1.1.1 attributetypes:( 0.0.8.350.1.1.1.1.1 NAME 'commURI' DESC 'Labeled URI format to point to the distinguished name of the commUniqueId' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Application utility class Standard
OID: 0.0.8.350.1.1.1.1.1 属性タイプ:( 0.0.8.350.1.1.1.1.1 NAME 'commURI' DESC 'commUniqueId の識別名を指すラベル付き URI 形式' 等価 caseExactMatch 構文 1.3.6.1.4.1.1466.115.121.1.15 ) アプリケーション ユーティリティ クラス Standard
Number of values multi Definition Labelled URI containing an LDAP URL identifying the directory containing the referenced commObject instance. The search filter specified by this LDAP URL shall specify an equality search of the commUniqueId attribute of the commObject class. Permissible values (if controlled) Notes Used to find the endpoint of the user in question. The label field may be used to represent the function of the endpoint, such as 'home IP phone' or 'desktop video' for user interface display purposes. Note that the label portion of the field may contain spaces as in the example below showing 'desktop video'. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) commURI: ldap://directory.acme.com/dc=acme,dc=com??sub?(commUniqueId=bob) desktop video
値の数 multi 定義 参照される commObject インスタンスを含むディレクトリを識別する LDAP URL を含むラベル付き URI。この LDAP URL で指定される検索フィルタは、commObject クラスの commUniqueId 属性の等価検索を指定します。許容値 (制御されている場合) 注 問題のユーザーのエンドポイントを検索するために使用されます。ラベル フィールドは、ユーザー インターフェイスの表示目的で、「ホーム IP 電話」や「デスクトップ ビデオ」などのエンドポイントの機能を表すために使用できます。「デスクトップビデオ」を示す以下の例のように、フィールドのラベル部分にはスペースが含まれる場合があることに注意してください。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) commURI: ldap://directory.acme.com/dc=acme,dc=com??sub?(commUniqueId=bob) デスクトップ ビデオ
Abstraction of video or voice over IP device. The commObject class permits an endpoint (H.323 endpoint or SIP user agent or other protocol endpoint) and all their aliases to be represented by a single entry in a directory. Note that every directory entry should contain commObject as the entry's structural object class. That entry may also contain H.350.x auxiliary classes.
ビデオまたはボイスオーバー IP デバイスの抽象化。commObject クラスを使用すると、エンドポイント (H.323 エンドポイント、SIP ユーザー エージェント、またはその他のプロトコル エンドポイント) とそのすべてのエイリアスをディレクトリ内の 1 つのエントリで表すことができます。すべてのディレクトリ エントリには、エントリの構造オブジェクト クラスとして commObject が含まれている必要があることに注意してください。このエントリには、H.350.x 補助クラスも含まれる場合があります。
OID: 0.0.8.350.1.1.2.2.1 objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' DESC 'object that contains the Communication attributes' SUP top STRUCTURAL MUST commUniqueId MAY ( commOwner $ commPrivate ) )
OID: 0.0.8.350.1.1.2.2.1 objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' DESC '通信属性を含むオブジェクト' SUP top STRUCTURAL MUST commUniqueId MAY ( commOwner $ commPrivate ) )
OID: 0.0.8.350.1.1.2.1.1 attributetypes: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' DESC 'To hold the endpoints unique Id' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Application utility class standard Number of values multi Definition The endpoint's unique ID. Permissible values (if controlled) Notes This is the RDN of this object. In practice, there will always be one and only one commUniqueId for every endpoint. This attribute uniquely identifies an endpoint in the commObject directory. It must be unique within that directory, but need not be unique globally. This attribute has no relationship to the enterprise directory. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) commUniqueId: bob
OID: 0.0.8.350.1.1.2.1.1 属性タイプ: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' DESC 'エンドポイントの一意の ID を保持するため' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.11 5.121.1.26 ) アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 エンドポイントの一意の ID。許容値 (制御されている場合) 注記 これは、このオブジェクトの RDN です。実際には、各エンドポイントに対して commUniqueId は常に 1 つだけ存在します。この属性は、commObject ディレクトリ内のエンドポイントを一意に識別します。このディレクトリ内では一意である必要がありますが、グローバルに一意である必要はありません。この属性はエンタープライズ ディレクトリとは関係がありません。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) commUniqueId: bob
OID: 0.0.8.350.1.1.2.1.2 attributetypes: 0.0.8.350.1.1.2.1.2 NAME 'commOwner' DESC 'Labeled URI to point back to the original owner' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Application utility class Standard Number of values multi Definition Labelled URI format to point back to the person or resource object associated with this entry. Permissible values (if controlled) Notes Used as a reverse entry finder of the owner(s). This attribute may point to groups. Note that this URI can point to a cn, but in applications where it is desired to bind authentication information across both the commObject and enterprise directories, it may be desirable that commOwner points to a dn rather than a cn, thus uniquely identifying the owner of the commObject. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) commOwner: ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith) commOwner: uid=bob,ou=people,dc=acme,dc=com
OID: 0.0.8.350.1.1.2.1.2 属性タイプ: 0.0.8.350.1.1.2.1.2 NAME 'commOwner' DESC '元の所有者を指すラベル付き URI' 等価 caseExactMatch 構文 1.3.6.1.4.1.1466.115.121.1.15 ) アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 このエントリに関連付けられた人物またはリソース オブジェクトを指すラベル付き URI 形式。許容値 (制御されている場合) 注記 所有者の逆入力ファインダーとして使用されます。この属性はグループを指す場合があります。この URI は cn を指すことができますが、commObject ディレクトリと enterprise ディレクトリの両方にわたって認証情報をバインドする必要があるアプリケーションでは、commOwner が cn ではなく dn を指すことが望ましい場合があることに注意してください。これにより、commOwner の所有者を一意に識別できます。通信オブジェクト。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) commOwner: ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith) commOwner: uid=bob、ou=人々、dc=acme、dc=com
OID: 0.0.8.350.1.1.2.1.3 attributetypes: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' DESC 'To decide whether the entry is visible to world or not' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Application utility class Standard Number of values multi Definition To be used by the user and indicate privacy options for an endpoint, i.e., unlisted number. Permissible values (if controlled) Notes This attribute is defined as Boolean. Future version of this Recommendation may develop a controlled vocabulary for this attribute to accommodate multiple types of privacy. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) commPrivate: true
OID: 0.0.8.350.1.1.2.1.3 属性タイプ: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' DESC 'エントリが世界に公開されるかどうかを決定する' SYNTAX 1.3.6.1.4.1.1466.115。121.1.26 ) アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 ユーザーによって使用され、エンドポイントのプライバシー オプション、つまりリストにない番号を示します。許容値 (制御されている場合) 注 この属性はブール値として定義されます。この勧告の将来のバージョンでは、複数のタイプのプライバシーに対応するために、この属性の制御された語彙が開発される可能性があります。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) commPrivate: true
This section contains a schema configuration file for commURIObject and commObject that can be used to configure an LDAP server to support these classes.
このセクションには、commURIObject および commObject のスキーマ構成ファイルが含まれており、これらのクラスをサポートするように LDAP サーバーを構成するために使用できます。
# Communication Object Schema # # Schema for Representing Communication Objects in an LDAP Directory # # Abstract # # This document defines the schema for representing Communication # objects in an LDAP directory [LDAPv3]. It defines schema elements # to represent a communication object URI [commURIObject]. # # #
# 通信オブジェクト スキーマ # # LDAP ディレクトリで通信オブジェクトを表現するためのスキーマ # # 要約 # # この文書は、LDAP ディレクトリ [LDAPv3] で # 通信オブジェクトを表現するためのスキーマを定義します。# 通信オブジェクト URI [commURIObject] を表すスキーマ要素を定義します。# # #
# .1 = Communication related work
# .1.1 = commURIObject
# .1.1.1 = attributes
# .1.1.2 = objectclass
# .1.1.3 = syntax
#
# Attribute Type Definitions
#
# The following attribute types are defined in this document:
#
# commURI
dn: cn=schema
changetype: modify
#
# if you need to change the definition of an attribute,
# then first delete and re-add in one step
#
# if this is the first time you are adding the commObject
# objectclass using this LDIF file, then you should comment
# out the delete attributetypes modification since this will
# fail. Alternatively, if your ldapmodify has a switch to continue
# on errors, then just use that switch -- if you're careful
#
delete: attributetypes
attributetypes: (0.0.8.350.1.1.1.1.1 NAME 'commURI' )
-
#
# re-add the attributes -- in case there is a change of definition
#
#
add: attributetypes
attributetypes: (0.0.8.350.1.1.1.1.1
NAME 'commURI'
DESC 'Labeled URI format to point to the distinguished name of
the commUniqueId'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
# Object Class Definitions
#
# The following object classes are defined in this document:
#
# commURIObject
#
# commURIObject
#
# This auxiliary object class represents a URI attribute type
#
# delete: objectclasses objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' ) - add: objectclasses objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' DESC 'object that contains the URI attribute type' SUP top AUXILIARY MAY ( commURI ) ) - # # end of LDIF #
# delete: objectclasses objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' ) - add: objectclasses objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' DESC ' URI 属性タイプを含むオブジェクト' SUP トップ AUXILIARY MAY ( commURI ) ) - # # LDIF の終わり #
# Communication Object Schema
#
# Schema for Representing Communication Objects in an LDAP Directory
#
# Abstract
#
# This document defines the schema for representing Communication
# objects in an LDAP directory [LDAPv3]. It defines schema elements
# to represent a communication object [commObject].
#
#
# .1 = Communication related work
# .1.2 = commObject
# .1.2.1 = attributes
# .1.2.2 = objectclass
# .1.2.3 = syntax
#
#
# Attribute Type Definitions
#
# The following attribute types are defined in this document:
#
# commUniqueId
# commOwner
# commPrivate
dn: cn=schema
changetype: modify
#
# if you need to change the definition of an attribute,
# then first delete and re-add in one step
# # if this is the first time you are adding the commObject # objectclass using this LDIF file, then you should comment # out the delete attributetypes modification since this will # fail. Alternatively, if your ldapmodify has a switch to continue # on errors, then just use that switch -- if you're careful # delete: attributetypes attributetypes: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' ) attributetypes: (0.0.8.350.1.1.2.1.2 NAME 'commOwner' ) attributetypes: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' ) - # # re-add the attributes -- in case there is a change of definition # # add: attributetypes attributetypes: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' DESC 'To hold the endpoints unique Id' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: (0.0.8.350.1.1.2.1.2 NAME 'commOwner' DESC 'Labeled URI to point back to the original owner' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetypes: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' DESC 'To decide whether the entry is visible to world or not' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - # Object Class Definitions # # The following object classes are defined in this document: # # commObject # # commObject # # delete: objectclasses objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' ) - add: objectclasses objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' DESC 'object that contains the Communication attributes' SUP top STRUCTURAL MUST commUniqueId MAY ( commOwner $ commPrivate ) ) - # # end of LDIF #
# # この LDIF ファイルを使用して commObject # オブジェクトクラスを追加するのが初めての場合は、 # 失敗するため、 # 属性タイプの削除の変更をコメントアウトする必要があります。あるいは、ldapmodify に続行スイッチがある場合は、 # エラー発生時にそのスイッチを使用してください -- 注意があれば # delete:attributetypesattributetypes:(0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' )attributes:(0.0.8.350.1.1.2.1.2 NAME 'commOwner' ) 属性タイプ: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' ) - # # 定義が変更された場合に備えて属性を再追加します ## add: 属性タイプ 属性タイプ: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' DESC 'エンドポイントの一意の ID を保持するには' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 属性タイプ: ( 0.0.8.350.1.1.2.1.2 NAME 'commOwner' DESC '元の所有者を指すラベル付き URI' 等価 caseExactMatch 構文 1.3.6.1.4.1.1466.115.121.1.15 ) 属性タイプ: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' DESC 'エントリが世界に公開されるかどうかを決定する' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - # オブジェクト クラスの定義 # # このドキュメントでは次のオブジェクト クラスが定義されます。# commObject # # commObject # # delete: objectclasses objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' ) - add: objectclasses objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' DESC 'objectこれには通信属性の SUP が含まれます。 top STRUCTURAL MUST commUniqueId MAY ( commOwner $ commPrivate ) ) - # # LDIF の終わり #
Indexing of attributes is an implementation-specific activity and depends upon the desired application. Non-indexed attributes can result in search times sufficiently long to render some applications unusable. Notably, user and alias lookup should be fast. The Annex A Indexing Profile describes an indexing configuration for commObject directories that will be optimized for use in directory of directories applications. Use of this profile is optional.
属性のインデックス作成は実装固有のアクティビティであり、目的のアプリケーションによって異なります。インデックス付けされていない属性により、一部のアプリケーションが使用できなくなるほど検索時間が長くなる可能性があります。特に、ユーザーとエイリアスの検索は高速である必要があります。付属書 A のインデックス作成プロファイルでは、ディレクトリ アプリケーションのディレクトリでの使用に最適化される commObject ディレクトリのインデックス作成構成について説明します。このプロファイルの使用はオプションです。
commURI: no recommendation
commURI: 推奨しません
commUniqueId: equality
commUniqueId: 等価性
commOwner: presence
commOwner: プレゼンス
commPrivate: presence
commPrivate: プレゼンス
The normative text of H.350 is reproduced in this section.
このセクションでは、H.350 の規範テキストが再掲されます。
This Recommendation describes an LDAP directory services architecture for multimedia conferencing using SIP. In particular, it defines an LDAP schema to represent SIP User Agents (UAs) on the network and associate those endpoints with users.
この勧告では、SIP を使用したマルチメディア会議のための LDAP ディレクトリ サービス アーキテクチャについて説明します。特に、ネットワーク上の SIP ユーザー エージェント (UA) を表し、それらのエンドポイントをユーザーに関連付ける LDAP スキーマを定義します。
This Recommendation is intended to supplement the CommObject directory architecture as discussed in ITU-T Rec. H.350, and not intended to be used as a stand-alone architecture. The implementation of this LDAP schema, together with the use of the H.350 CommObject architecture, facilitates the integration of SIP User Agents and conferencing devices into existing Enterprise Directories, thus allowing the user to perform white page lookups and access clickable dialling supported by SIP devices. The primary reasons for implementing this schema include those listed in ITU-T Rec. H.350 (the CommObject class definition) as they apply specifically to the use of SIP UAs, and to facilitate vendors making SIP services more readily available to their users.
この勧告は、ITU-T Rec. で議論されている CommObject ディレクトリ アーキテクチャを補足することを目的としています。H.350 であり、スタンドアロン アーキテクチャとして使用することは意図されていません。この LDAP スキーマの実装と H.350 CommObject アーキテクチャの使用により、SIP ユーザー エージェントと会議デバイスの既存のエンタープライズ ディレクトリへの統合が容易になり、ユーザーはホワイト ページの検索を実行し、SIP でサポートされているクリッカブル ダイヤルにアクセスできるようになります。デバイス。このスキーマを実装する主な理由には、ITU-T Rec. にリストされているものが含まれます。H.350 (CommObject クラス定義) は、特に SIP UA の使用に適用され、ベンダーがユーザーに SIP サービスをより簡単に利用できるようにするためのものです。
The scope of this Recommendation includes recommendations for the architecture to integrate endpoint information for endpoints using SIP into existing enterprise directories and white pages.
この推奨事項の範囲には、SIP を使用してエンドポイントのエンドポイント情報を既存のエンタープライズ ディレクトリおよびホワイト ページに統合するためのアーキテクチャに関する推奨事項が含まれます。
The scope of this Recommendation does not include normative methods for the use of the LDAP directory itself or the data it contains. The purpose of the schema is not to represent all possible data elements in the SIP protocol, but rather to represent the minimal set required to accomplish the design goals enumerated in ITU-T Rec. H.350.
この推奨事項の範囲には、LDAP ディレクトリ自体またはそこに含まれるデータの使用に関する規範的な方法は含まれません。スキーマの目的は、SIP プロトコルで考えられるすべてのデータ要素を表すことではなく、ITU-T Rec. に列挙されている設計目標を達成するために必要な最小限のセットを表すことです。H.350。
Note that SIP provides well-defined methods for discovering registrar addresses and locating users on the network. Some of the attributes defined here are intended for more trivial or manual implementations and may not be needed for all applications. For example, SIPIdentityRegistrarAddress and SIPIdentityAddress may not be needed for many applications, but are included here for completeness. Thus, SIPIdentitySIPURI is the primary attribute of interest that will be served out, especially for white page directory applications.
SIP は、レジストラ アドレスを検出し、ネットワーク上のユーザーを見つけるための明確に定義された方法を提供していることに注意してください。ここで定義されている属性の一部は、より簡単な実装または手動実装を目的としており、すべてのアプリケーションに必要なわけではありません。たとえば、SIPIdentityRegistrarAddress と SIPIdentityAddress は多くのアプリケーションでは必要ありませんが、完全を期すためにここに含めています。したがって、SIPIdentitySIPURI は、特にホワイト ページ ディレクトリ アプリケーションで提供される重要な属性です。
The SIPIdentity classes may be extended as necessary for specific implementations. See the base of ITU-T Rec. H.350 for a discussion on schema extension.
SIPIdentity クラスは、特定の実装の必要に応じて拡張できます。ITU-T Rec.のベースを参照してください。スキーマ拡張については H.350 を参照してください。
The SIPIdentity object class represents SIP User Agents (UAs). It is an auxiliary class and is derived from the commObject class, which is defined in the ITU-T Rec. H.350.
SIPIdentity オブジェクト クラスは、SIP ユーザー エージェント (UA) を表します。これは補助クラスであり、ITU-T Rec. で定義されている commObject クラスから派生しています。H.350。
OID: 0.0.8.350.1.1.6.2.1 objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' DESC 'SIPIdentity object' SUP top AUXILIARY MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ SIPIdentityProxyAddress $ SIPIdentityUserName $ SIPIdentityPassword $ SIPIdentityServiceLevel $ userSMIMECertificate ) )
OID: 0.0.8.350.1.1.6.2.1 オブジェクトクラス: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' DESC 'SIPIdentity object' SUP top AUXILIARY MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ SIPIdentityProxyAddress $ SIPIdentityUserName $ SIPIdentityパスワード $ SIPIdentityServiceLevel $ userSMIMECertificate))
OID: 0.0.8.350.1.1.6.1.1 attributetypes: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' DESC 'Universal Resource Indicator of the SIP UA' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Application utility class standard Number of values multi Definition Uniform Resource Identifier that identifies a communication resource in SIP. Usually contains a user name and a host name and is often similar in format to an email address. Permissible values (if controlled) Notes This URI may institute SIP or SIPS (secure). In the event that SIPS is instituted, the URI must reflect that it is using SIPS as opposed to SIP. See Examples below. Semantics Example applications for which this attribute would be useful Online representation of most current listing of a user's SIP(S) UA. Example SIPIdentitySIPURI: sip:alice@foo.com // SIP example SIPIdentitySIPURI: sip:alice@152.2.158.212 // SIP example SIPIdentitySIPURI: sips:bob@birmingham.edu // SIPS example
OID: 0.0.8.350.1.1.6.1.1 属性タイプ: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' DESC 'SIP UA のユニバーサル リソース インジケータ' 平等 caseExactMatch SUBSTR caseExactSubstringsMatch 構文 1.3.6.1.4.1.1466.115。121.1.15 ) アプリケーションユーティリティクラス標準 値の数 multi 定義 SIP における通信リソースを識別するユニフォームリソース識別子。通常はユーザー名とホスト名が含まれ、多くの場合電子メール アドレスに似た形式になります。許容値 (制御されている場合) 注意事項 この URI は SIP または SIPS (安全) を確立する場合があります。SIPS が確立された場合、URI は SIP ではなく SIPS を使用していることを反映する必要があります。以下の例を参照してください。セマンティクス この属性が役立つアプリケーションの例 ユーザーの SIP(S) UA の最新リストのオンライン表現。例 SIPIdentitySIPURI: sip:alice@foo.com // SIP の例 SIPIdentitySIPURI: sip:alice@152.2.158.212 // SIP の例 SIPIdentitySIPURI: sips:bob@birmingham.edu // SIPS の例
OID: 0.0.8.350.1.1.6.1.2 attributetypes: (0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress' DESC 'specifies the location of the registrar' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Application utility class Standard Number of values multi Definition Address for the domain to which the server that handles REGISTER requests and forwarding to the location server for a particular domain belongs. Permissible values (if controlled) Notes Note that RFC 3261 states that user agents can discover their registrar address by configuration, using the address-of-record, or by multicast. The first scenario, by configuration, is noted as out of scope for RFC 3261. This attribute may be used for the first scenario. It can be accomplished manually, (e.g., a web page that displays a user's correct registrar address) or automatically with an H.350.4 aware user agent. Semantics Example applications for which this attribute would be useful white pages, a web page that displays a user's correct configuration information. Example (LDIF fragment) SIPIdentityRegistrarAddress: 152.2.15.22 //IP address example SIPIdentityRegistrarAddress: sipregistrar.unc.edu //FQDN example
OID: 0.0.8.350.1.1.6.1.2 属性タイプ: (0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress' DESC 'レジストラの場所を指定します' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.2 6) アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 REGISTER リクエストを処理し、特定のドメインのロケーション サーバーへの転送を処理するサーバーが属するドメインのアドレス。許容値 (制御されている場合) 注記 RFC 3261 では、ユーザー エージェントが設定、レコードのアドレス、またはマルチキャストによってレジストラ アドレスを検出できると記載されていることに注意してください。最初のシナリオは、構成により、RFC 3261 の範囲外として示されています。この属性は、最初のシナリオに使用できます。これは手動で (たとえば、ユーザーの正しいレジストラ アドレスを表示する Web ページで) 実行することも、H.350.4 対応ユーザー エージェントを使用して自動的に実行することもできます。セマンティクス この属性が役立つサンプル アプリケーションは、ユーザーの正しい構成情報を表示する Web ページであるホワイト ページです。例 (LDIF フラグメント) SIPIdentityRegistrarAddress: 152.2.15.22 //IP アドレスの例 SIPIdentityRegistrarAddress: sipregistrar.unc.edu //FQDN の例
OID: 0.0.8.350.1.1.6.1.3 attributetypes: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress' DESC 'Specifies the location of the SIP Proxy' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Application utility class Standard Number of values multi Definition Address which specifies the domain location of SIP proxy within a domain. RFC 3261 defines the role of the SIP proxy. Permissible values (if controlled) Notes SIP User Agents are not REQUIRED to use a proxy, but will in many cases. Semantics Example applications for which this attribute would be useful white pages, a web page that displays a user's correct configuration information. Example (LDIF fragment) SIPIdentityProxyAddress: 172.2.13.234 //IP address example SIPIdentityProxyAddress: sipproxy.unc.edu //FQDN example
OID: 0.0.8.350.1.1.6.1.3 属性タイプ: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress' DESC 'SIP プロキシの場所を指定します' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 ドメイン内の SIP プロキシのドメインの場所を指定するアドレス。RFC 3261 では、SIP プロキシの役割が定義されています。許容値 (制御されている場合) 注 SIP ユーザー エージェントはプロキシを使用する必要はありませんが、多くの場合プロキシを使用する必要があります。セマンティクス この属性が役立つサンプル アプリケーションは、ユーザーの正しい構成情報を表示する Web ページであるホワイト ページです。例 (LDIF フラグメント) SIPIdentityProxyAddress: 172.2.13.234 //IP アドレスの例 SIPIdentityProxyAddress: sipproxy.unc.edu //FQDN の例
OID: 0.0.8.350.1.1.6.1.4 attributetypes: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' DESC 'IP address or FQDN of the UA' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Application utility class standard Number of values multi Definition Specifies the IP address or fully qualified domain name of the UA. Permissible values (if controlled) Notes This attribute may be useful for applications in which UA to UA communication is direct, not involving a proxy or registrar. Example applications for which this attribute would be useful A web page that displays a user's proper user agent configuration information. Example (LDIF fragment) SIPIdentityAddress: 152.2.121.36 // IP address example SIPIdentityAddress: ipPhone.foo.org // FQDN example
OID: 0.0.8.350.1.1.6.1.4 属性タイプ: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' DESC 'UA の IP アドレスまたは FQDN' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) アプリケーション ユーティリティ クラス standard 値の数 multi 定義 UA の IP アドレスまたは完全修飾ドメイン名を指定します。許容値 (制御されている場合) 注意事項 この属性は、プロキシやレジストラを介さずに UA 間の通信が直接行われるアプリケーションに役立つ場合があります。この属性が役立つアプリケーションの例 ユーザーの適切なユーザー エージェント構成情報を表示する Web ページ。例 (LDIF フラグメント) SIPIdentityAddress: 152.2.121.36 // IP アドレスの例 SIPIdentityAddress: ipPhone.foo.org // FQDN の例
OID: 0.0.8.350.1.1.6.1.5 attributetypes: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' DESC 'The user agent SIP password ' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) Application utility class Standard Number of values multi Definition The SIP user agent's password, used for the HTTP digest authentication scheme as defined in RFC 2617. Permissible values (if controlled) Notes Because RFC 2069, which was made obsolete by RFC 2617, was used as the basis for HTTP Digest in RFC 2543, any SIP servers supporting RFC 2617 must ensure backward compatibility with RFC 2069. This SIPIdentityUserName, together with SIPIdentityPassword, are reserved for the purpose of use with Digest Access Authentication, and not intended for use with Basic Authentication methods. LDAP provides one method to store user passwords for reference. If passwords are stored in LDAP it makes the LDAP server a particularly valuable target for attack. Implementors are encouraged to exercise caution and implement appropriate security procedures such as encryption, access control, and transport layer security for access to this attribute. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) SIPIdentityPassword: 36zxJmCIB18dM0FVAj
OID: 0.0.8.350.1.1.6.1.5 属性タイプ: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' DESC 'ユーザー エージェント SIP パスワード ' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 RFC 2617 で定義されている HTTP ダイジェスト認証スキームに使用される SIP ユーザー エージェントのパスワード。 許容値 (制御されている場合) 注意事項 RFC 2617 によって廃止された RFC 2069 が、RFC 2543 の HTTP ダイジェストの基礎であるため、RFC 2617 をサポートする SIP サーバーは、RFC 2069 との下位互換性を確保する必要があります。この SIPIdentityUserName は、SIPIdentityPassword とともに、ダイジェスト アクセス認証で使用する目的で予約されており、基本認証での使用を目的としていません。メソッド。LDAP は、参照用にユーザー パスワードを保存する 1 つの方法を提供します。パスワードが LDAP に保存されている場合、LDAP サーバーは特に貴重な攻撃対象になります。実装者は注意を払い、この属性にアクセスするための暗号化、アクセス制御、トランスポート層セキュリティなどの適切なセキュリティ手順を実装することが推奨されます。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) SIPIdentityPassword: 36zxJmCIB18dM0FVAj
OID: 0.0.8.350.1.1.6.1.6 attributetypes: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' DESC 'The user agent user name.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Application utility class Standard Number of values multi Definition The SIP user agent's user name, used for the HTTP digest authentication scheme as defined in RFC 2617. Permissible values (if controlled) Notes Because RFC 2069, which was made obsolete by RFC 2617, was used as the basis for HTTP Digest Authentication in RFC 2543, any SIP servers supporting HTTP Digest Authentication as defined in RFC 2617 must ensure backward compatibility with RFC 2069. This SIPIdentityUserName, together with SIPIdentityPassword, are reserved for the purpose of use with Digest Access Authentication, and not intended for use with Basic Authentication methods. Note that in many cases the user name will be parsed from the user@proxy.domain portion of the SIP URI. In that case it may not be necessary to populate this attribute. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) SIPIdentityUserName: nelkhour
OID: 0.0.8.350.1.1.6.1.6 属性タイプ: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' DESC 'ユーザー エージェント ユーザー名。' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121。 1.15 ) アプリケーション ユーティリティ クラス 標準 値の数 multi 定義 RFC 2617 で定義されている HTTP ダイジェスト認証スキームに使用される SIP ユーザー エージェントのユーザー名。 許容値 (制御されている場合) 注記 RFC 2069 は RFC 2617 によって廃止されたためは、RFC 2543 で HTTP ダイジェスト認証の基礎として使用されたため、RFC 2617 で定義されている HTTP ダイジェスト認証をサポートする SIP サーバーは、RFC 2069 との下位互換性を確保する必要があります。この SIPIdentityUserName は、SIPIdentityPassword とともに、ダイジェストで使用する目的で予約されています。アクセス認証。基本認証方法での使用を目的としていません。多くの場合、ユーザー名は SIP URI の user@proxy.domain 部分から解析されることに注意してください。その場合、この属性を設定する必要がない場合があります。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) SIPIdentityUserName: nelkhour
OID: 0.0.8.350.1.1.6.1.7 attributetypes: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' DESC 'To define services that a user can belong to.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Application utility class Standard Number of values multi Definition This describes the level of services a user can belong to. Permissible values (if controlled) Notes This attribute does not represent a data element found in SIP. SIP itself does not support distinctions in service levels. Instead, this attribute provides a mechanism for the storage of service level information directly in LDAP. This mapping allows service providers to adapt to an existing LDAP directory without changing the values of the SIPIdentityServiceLevel instances in the directory. Semantics Example applications for which this attribute would be useful Example (LDIF fragment) SIPIdentityServiceLevel: premium
OID: 0.0.8.350.1.1.6.1.7 属性タイプ: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' DESC 'ユーザーが所属できるサービスを定義します。' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) アプリケーション ユーティリティ クラス Standard 値の数 multi 定義 これは、ユーザーが属することができるサービスのレベルを記述します。許容値 (制御されている場合) 注 この属性は、SIP で見つかったデータ要素を表しません。SIP 自体はサービス レベルの区別をサポートしていません。代わりに、この属性は、サービス レベル情報を LDAP に直接保存するためのメカニズムを提供します。このマッピングにより、サービス プロバイダーは、ディレクトリ内の SIPIdentityServiceLevel インスタンスの値を変更せずに、既存の LDAP ディレクトリに適応できます。セマンティクス この属性が役立つアプリケーションの例 例 (LDIF フラグメント) SIPIdentityServiceLevel: premium
This clause contains a schema configuration file for SIPIdentity that can be used to configure an LDAP server to support this class.
この句には、このクラスをサポートするように LDAP サーバーを構成するために使用できる SIPIdentity のスキーマ構成ファイルが含まれています。
# SIPIdentity Object Schema
#
# Schema for representing SIPIdentity Object in an LDAP Directory
#
# Abstract
#
# This Recommendation defines the schema for representing
SIPIdentity
# object in an LDAP directory [LDAPv3]. It defines schema elements
# to represent an SIPIdentity object [SIPIdentity].
#
# .1 = Communication related work
# .1.6 = SIPIdentity
# .1.6.1 = attributes
# .1.6.2 = objectclass
# .1.6.3 = syntax # # # # Attribute Type Definitions # # The following attribute types are defined in this Recommendation: # # SIPIdentitySIPURI # SIPIdentityRegistrarAddress # SIPIdentityProxyAddress # SIPIdentityAddress # SIPIdentityPassword # SIPIdentityUserName # SIPIdentityServiceLevel dn: cn=schema changetype: modify # # if you need to change the definition of an attribute, # then first delete and re-add in one step # # if this is the first time you are adding the SIPIdentity # objectclass using this LDIF file, then you should comment # out the delete attributetypes modification since this will # fail. Alternatively, if your ldapmodify has a switch to continue # on errors, then just use that switch -- if you are careful # delete: attributetypes attributetypes: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' ) attributetypes: (0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress') attributetypes: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress') attributetypes: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' ) attributetypes: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' ) attributetypes: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' ) attributetypes: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel') - # # re-add the attributes -- in case there is a change of definition # # add: attributetypes attributetypes: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' DESC 'Universal Resource Indicator of the SIP UA' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# .1.6.3 = 構文 # # # # 属性タイプの定義 # # この推奨事項では、次の属性タイプが定義されています: # # SIPIdentitySIPURI # SIPIdentityRegistrarAddress # SIPIdentityProxyAddress # SIPIdentityAddress # SIPIdentityPassword # SIPIdentityUserName # SIPIdentityServiceLevel dn: cn=schemachangetype:modify ## 属性の定義を変更する必要がある場合は、 # まず削除して 1 つのステップで再追加します # # この LDIF ファイルを使用して SIPIdentity # オブジェクトクラスを追加するのが初めての場合は、 # をコメントアウトする必要があります# これは失敗するため、属性タイプの変更を削除します。あるいは、ldapmodify に続行スイッチがある場合は、 # エラー発生時にそのスイッチを使用してください -- 注意があれば # delete:attributetypesattributetypes:(0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' )attributetypes:(0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress') 属性タイプ: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress') 属性タイプ: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' ) 属性タイプ: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' ) 属性タイプ: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' ) 属性タイプ: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel') - ## 定義の変更があった場合に備えて、属性を再追加します。 # # add:attributetypesattributes:(0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' DESC 'SIP UA の Universal Resource Indicator' EQUALITY caseExactMatch SUBSTRcaseExactSubstringsMatch 構文 1.3.6.1.4.1.1466.115.121.1.15 )
attributetypes: (0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress' DESC 'specifies the location of the registrar' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress' DESC 'Specifies the location of the SIP Proxy' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' DESC 'IP address of the UA' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetypes: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' DESC 'The user agent SIP password ' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) attributetypes: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' DESC 'The user agent user name.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetypes: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' DESC 'To define services that a user can belong to.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - # Object Class Definitions # # The following object class is defined in this Recommendation: # # SIPIdentity # # SIPIdentity # # delete: objectclasses objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' ) - add: objectclasses objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' DESC 'SIPIdentity object' SUP top AUXILIARY MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ SIPIdentityProxyAddress $ SIPIdentityAddress $ SIPIdentityPassword $ SIPIdentityUserName $ SIPIdentityServiceLevel $ userSMIMECertificate ) ) - # # end of LDIF #
属性タイプ: (0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress' DESC 'レジストラの場所を指定します' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 属性タイプ: (0.0.8.350.1.1.6) .1.3 NAME 'SIPIdentityProxyAddress' DESC 'SIP プロキシの場所を指定します' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 属性タイプ: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' DESC 'IPUA のアドレス' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 属性タイプ: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' DESC 'ユーザー エージェント SIP パスワード ' EQUALITY octetStringMatch SYNTAX 1.3 .6.1.4.1.1466.115.121.1.40 ) 属性タイプ: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' DESC 'ユーザー エージェントのユーザー名。' 等価 caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 構文 1.3.6.1.4.1.1466.115.12 1.1.15) 属性タイプ: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' DESC 'ユーザーが所属できるサービスを定義します。' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - # オブジェクトクラス定義 # # この勧告では次のオブジェクト クラスが定義されています: # # SIPIdentity # # SIPIdentity # # delete: objectclasses objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' ) - add: objectclasses objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' DESC 'SIPIdentity オブジェクト' SUP top AUXILIARY MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ SIPIdentityProxyAddress $ SIPIdentityAddress $ SIPIdentityPassword $ SIPIdentityUserName $ SIPIdentityServiceLevel $ userSMIMECertificate ) ) - # # LDIF の終わり #
Indexing of attributes is an implementation-specific activity and depends upon the desired application. Non-indexed attributes can result in search times sufficiently long to render some applications unusable. Notably, user and alias lookup should be fast. The Annex A Indexing Profile describes an indexing configuration for SIPIdentity directories that will be optimized for use in directory of directories applications. Use of this profile is optional.
属性のインデックス作成は実装固有のアクティビティであり、目的のアプリケーションによって異なります。インデックス付けされていない属性により、一部のアプリケーションが使用できなくなるほど検索時間が長くなる可能性があります。特に、ユーザーとエイリアスの検索は高速である必要があります。付属書 A のインデックス作成プロファイルでは、ディレクトリ アプリケーションのディレクトリでの使用に最適化される SIPIdentity ディレクトリのインデックス作成構成について説明します。このプロファイルの使用はオプションです。
SIPIdentitySIPURI: equality
SIPIdentitySIPURI: 平等
SIPIdentityRegistrarAddress: no recommendation
SIPIdentityRegistrarAddress: 推奨事項なし
SIPIdentityProxyAddress: no recommendation
SIPIdentityProxyAddress: 推奨事項なし
SIPIdentityAddress: equality
SIPIdentityAddress: 等しい
SIPIdentityUserName: equality
SIPIdentityUserName: 等しい
SIPIdentityPassword: no recommendation
SIPIdentityPassword: 推奨なし
SIPIdentityServiceLevel: equality
SIPIdentityServiceLevel: 同等
We are grateful to numerous colleagues for reaching across multiple boundaries of standards bodies, research networks, academia and private industry in order to produce an architecture that works toward integrating multimedia conferencing deployments. In particular, standards from both IETF and ITU-T were drawn from extensively, and the architecture is meant to serve all communities.
マルチメディア会議導入の統合に向けて機能するアーキテクチャを作成するために、標準化団体、研究ネットワーク、学界、民間業界の複数の境界を越えて協力してくださった多くの同僚に感謝します。特に、IETF と ITU-T の両方の標準が広範に引用されており、アーキテクチャはすべてのコミュニティにサービスを提供することを目的としています。
This work developed out of the Video Conferencing Middleware (VidMid-VC) working group, a joint effort of Internet2 (www.internet2.edu) and the Video Development Initiative (www.vide.net). The architecture was developed in response to deployment challenges discovered in the ViDeNet (https//:videnet.unc.edu) academic test bed providing video and voice over IP infrastructure across research networks internationally.
この成果は、Internet2 (www.internet2.edu) と Video Development Initiative (www.vide.net) の共同作業であるビデオ会議ミドルウェア (VidMid-VC) ワーキング グループから発展しました。このアーキテクチャは、国際的な研究ネットワーク全体にビデオとボイスオーバー IP インフラストラクチャを提供する ViDeNet (https//:videnet.unc.edu) 学術テストベッドで発見された展開上の課題に対応して開発されました。
This work was supported in part by a grant from the United States National Science Foundation contract number ANI-0222710.
この研究は、米国国立科学財団契約番号 ANI-0222710 からの助成金によって部分的に支援されました。
This section is not present in the ITU-T standard, but gives information for the IETF community. Its content has the consensus of the ITU-T Study Group 16.
このセクションは ITU-T 標準には存在しませんが、IETF コミュニティ向けの情報を提供します。その内容は ITU-T Study Group 16 の合意を得ています。
H.350 does not alter the security architectures of any particular protocol. However, it does offer a standardized place to store authentication credentials where appropriate. It should be noted that both H.323 and SIP support shared secret authentication (H.235 Annex D and HTTP Digest, respectively). These approaches require that the call server have access to the password. Thus, if the call server or H.350 directory is compromised, passwords also may become compromised. These weaknesses may be due to weaknesses in the systems (H.350 directory or call servers) and their operation rather than in H.350 per se.
H.350 は、特定のプロトコルのセキュリティ アーキテクチャを変更しません。ただし、必要に応じて、認証資格情報を保存するための標準化された場所を提供します。H.323 と SIP はどちらも共有秘密認証 (それぞれ H.235 Annex D と HTTP Digest) をサポートしていることに注意してください。これらのアプローチでは、コール サーバーがパスワードにアクセスできる必要があります。したがって、コール サーバーまたは H.350 ディレクトリが侵害されると、パスワードも侵害される可能性があります。これらの弱点は、H.350 自体の弱点ではなく、システム (H.350 ディレクトリまたはコール サーバー) とその動作の弱点が原因である可能性があります。
The userSMIMECertificate attribute is defined in RFC 2798 (section 2.8) as a part of inetOrgPerson. The SIP user agent's X.509 certificate can be stored in this attribute. When the certificate is present, it can be employed with S/MIME to provide authentication, integrity, and confidentiality as specified in RFC 3261 [5].
userSMIMECertificate 属性は、inetOrgperson の一部として RFC 2798 (セクション 2.8) で定義されています。SIP ユーザー エージェントの X.509 証明書はこの属性に保存できます。証明書が存在する場合、RFC 3261 [5] で指定されているように、S/MIME とともに使用して認証、完全性、機密性を提供できます。
It is strongly encouraged that call servers and an H.350 directory mutually authenticate each other before sharing information. Further, it is strongly encouraged that communications between H.350 directories and call servers or endpoints happen over secure communication channels such as SSL or TLS.
情報を共有する前に、コール サーバーと H.350 ディレクトリが相互に認証することを強くお勧めします。さらに、H.350 ディレクトリとコール サーバーまたはエンドポイント間の通信は、SSL や TLS などの安全な通信チャネル経由で行うことが強く推奨されます。
Finally, access control lists on LDAP servers are a matter of policy and are not a part of the standard. System administrators are advised to use common sense when setting access control on H.350 attributes. For example, password attributes should only be accessible by the authenticated user, while address attributes might be publicly available.
最後に、LDAP サーバー上のアクセス制御リストはポリシーの問題であり、標準の一部ではありません。システム管理者は、常識に従って H.350 属性のアクセス制御を設定することをお勧めします。たとえば、パスワード属性は認証されたユーザーのみがアクセスできるようにする必要がありますが、アドレス属性は公的に利用できるようにする必要があります。
[1] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[1] Hodges, J. および R. Morgan、「軽量ディレクトリ アクセス プロトコル (v3): 技術仕様」、RFC 3377、2002 年 9 月。
[2] ITU-T Recommendation H.350, "Directory services architecture for multimedia conferencing", 2003.
[2] ITU-T 勧告 H.350、「マルチメディア会議のためのディレクトリ サービス アーキテクチャ」、2003 年。
[3] ITU-T Recommendation H.350.4, "Directory services architecture for SIP", 2003.
[3] ITU-T 勧告 H.350.4、「SIP のディレクトリ サービス アーキテクチャ」、2003 年。
[4] 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.
[4] Franks, J.、Hallam-Baker P.、Hostetler, J.、Lawrence, S.、Leach, P.、Luotonen, A.、および L. Stewart、「HTTP 認証: 基本およびダイジェスト アクセス認証」、RFC 2617、1999年6月。
[5] 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.
[5] Rosenberg, J.、Schulzrinne, H.、Camarillo, G.、Johnston, A.、Peterson, J.、Sparks, R.、Handley, M.、および E. Schooler、「SIP: セッション開始プロトコル」、RFC 3261、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Rosenberg, J. および H. Schulzrinne、「セッション開始プロトコル (SIP): SIP サーバーの検索」、RFC 3263、2002 年 6 月。
[7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.
[7] Smith, M.、「inetOrgperson LDAP オブジェクト クラスの定義」、RFC 2798、2000 年 4 月。
[8] ITU-T Recommendation H.350.1, "Directory services architecture for H.323", 2003.
[8] ITU-T 勧告 H.350.1、「H.323 のディレクトリ サービス アーキテクチャ」、2003 年。
[9] ITU-T Recommendation H.350.2, "Directory services architecture for H.235", 2003.
[9] ITU-T 勧告 H.350.2、「H.235 のディレクトリ サービス アーキテクチャ」、2003 年。
[10] ITU-T Recommendation H.350.3, "Directory services architecture for H.320", 2003.
[10] ITU-T 勧告 H.350.3、「H.320 のディレクトリ サービス アーキテクチャ」、2003 年。
[11] ITU-T Recommendation H.350.5, "Directory services architecture for Non-Standard Protocols", 2003.
[11] ITU-T 勧告 H.350.5、「非標準プロトコルのディレクトリ サービス アーキテクチャ」、2003 年。
[12] ITU-T Recommendation H.350.6, "Directory services architecture for Call Forwarding and Preferences", 2004.
[12] ITU-T 勧告 H.350.6、「通話転送と設定のためのディレクトリ サービス アーキテクチャ」、2004 年。
[13] Howes T. and M. Smith, "Understanding And Deploying LDAP Directory Services", New Riders Publishing, ISBN: 1578700701, 1999.
[13] Howes T. および M. Smith、『LDAP ディレクトリ サービスの理解と導入』、New Riders Publishing、ISBN: 1578700701、1999 年。
[14] Howes T. and M. Smith, "LDAP Programming Directory-Enabled Applications with Lightweight Directory Access Protocol", New Riders Publishing, ISBN: 1578700000, 1997.
[14] Howes T. および M. Smith、『Lightweight Directory Access Protocol を使用した LDAP プログラミング ディレクトリ対応アプリケーション』、New Riders Publishing、ISBN: 1578700000、1997。
This specification is an RFC publication of an ITU-T publication [4], without textual changes within the standard itself (Section 4). The present section appears in the RFC publication only. In order for this specification to be implemented properly, a number of standards pertaining to LDAP [1], [7], H.350 [2],[3], and SIP [4], [5], [6], [7], need to be implemented in whole or in part by the implementor.
この仕様は、ITU-T 出版物 [4] の RFC 出版物であり、規格自体 (セクション 4) 内のテキストの変更はありません。このセクションは、RFC 出版物にのみ掲載されています。この仕様を適切に実装するには、LDAP [1]、[7]、H.350 [2]、[3]、および SIP [4]、[5]、[6] に関連する多くの標準が必要です。[7] は、実装者によって全体または部分的に実装される必要があります。
For some background information on the ITU and IETF directory service protocols, reading [8], [9], [10], [11], and [12] is valuable, and [13] and [14] are recommended books.
ITU および IETF ディレクトリ サービス プロトコルの背景情報については、[8]、[9]、[10]、[11]、および [12] を読むことが価値があり、[13] と [14] は推奨書籍です。
Tyler Johnson Editor, H.350 University of North Carolina Chapel Hill, NC 27599
タイラー・ジョンソン編集者、H.350 ノースカロライナ大学チャペルヒル、NC 27599
Phone: +1.919.843.7004
EMail: Tyler_Johnson@unc.edu
Sakae Okubo Rapporteur for Q.4/16, ITU-T SG16 Waseda University YRP Ichibankan, 3-4 Hikarinooka Yokosuka-shi, 239-0847 Japan
Sakae Okubo Rapporteur for Q.4/16, ITU-T SG16 Waseda University YRP Ichibankan, 3-4 Hikarinooka Yokosuka-shi, 239-0847 Japan
Phone: +81 46 847 5406
EMail: sokubo@waseda.jp
Simao Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Place des Nations Geneva CH1211 - Switzerland
Simao Ferraz de Campos Neto カウンセラー、ITU-T SG 16 国際電気通信連合 ジュネーブ広場 CH1211 - スイス
Phone: +41-22-730-6805
EMail: simao.campos@itu.int
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 および www.rfc-editor.org に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。ISOC 文書の権利に関する ISOC の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。