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
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シリーズを作成しました。アーキテクチャの目標は、これらのサービスは、既存のアイデンティティ管理と企業ディレクトリを活用できるように、マルチメディア会議を「ディレクトリを有効にする」ことです。特定の目標は、すべてが同じデータストアにアクセスすることができ、複数のプロトコルをサポートし、複数のベンダーからのように複数のコールサーバ、ユーザーとそのマルチメディア会議システムの標準的なソースを維持するために、企業やサービスプロバイダを有効にすることです。
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コミュニティにこの文書を経由して利用できるようになります。この文書は、それぞれ、セクション4および5でITU-T勧告H.350およびH.350.4の全体の規範的なテキストを含みます。残りのセクションのみがこの文書ではなく、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シリーズを作成しました。アーキテクチャの目標は、これらのサービスは、既存のアイデンティティ管理と企業ディレクトリを活用できるように、マルチメディア会議を「ディレクトリを有効にする」ことです。特定の目標は、すべてが同じデータストアにアクセスすることができ、複数のプロトコルをサポートし、複数のベンダーからのように複数のコールサーバ、ユーザーとそのマルチメディア会議システムの標準的なソースを維持するために、企業やサービスプロバイダを有効にすることです。
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スキーマを標準化することにより、異なるシステムのベンダーの製品は、全体的なアプリケーション環境を作成するために一緒に展開することができます。例えば、1つのプロバイダによって開発されたホワイトページの検索エンジンは、さらに第3のプロバイダによって生成コールサーバによって管理されるシグナリングで、第二のプロバイダによって生成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が検索して位置するための標準化された方法をサポートしています。これは「クリッカブルダイヤル」をサポートするために必要なステップです。
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は、コールサーバとエンドポイントの両方によってアクセスすることができる便利な格納場所を提供します。したがって、単純化された操作とサポートユーザのモビリティのために重要であるエンドポイントの設定をサポートするためにディレクトリを使用することが可能です。他の技術は、エンドポイントの設定、登録サーバーのアドレスを取得するための完全な設定とSRVレコードのSNMPの顕著な使用をサポートしていることに注意してください。そのため、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.
アーキテクチャの二つの基本的なコンポーネントがあります。 commURIオブジェクトは、その唯一の目的commObjectに人やリソースをリンクすることであるクラスです。個々のディレクトリエントリにcommURI「ポインタ」を配置することにより、その個人は、特定の標的にcommObjectに関連付けられます。同様に、commObjectはcommObjectに関連付けられている個人またはリソースを指すcommOwnerと呼ばれるポインタを含んでいます。このように、人やリソースは、エンドポイントに関連付けることができます。企業ディレクトリに必要な唯一の変更は、単純なオブジェクトクラス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.
場合によっては、Recommendationsによってサポートされているよりも多くの情報を表現するために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 $ ) )
オブジェクトクラス（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勧告を使用しています。 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
DN：commUniqueId = 2000、OU = h323identity、DC =会社、dc = comのオブジェクトクラス：トップオブジェクトクラス：commObjectオブジェクトクラス：h323Identityオブジェクトクラス：BillingInfo commUniqueId：2000 BillingAccount：0023456 BillingManager：ジョン・スミス
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 $ ) )
（SUPトップ補助MAY（BillingAccount $ BillingManager $ '）参考情報課金' BillingInfo-OID NAME 'BillingInfo' DESC）をオブジェクトクラス
Note how the superior was changed from commObject to top and the object class changed from being a structural to auxiliary.
優れ先頭へcommObjectから変更し、オブジェクトクラスが補助する構造であることからどのように変化するかに注意してください。
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
DN：commUniqueId = 2000、OU = h323identity、DC =会社、dc = comのオブジェクトクラス：トップオブジェクトクラス：commObjectオブジェクトクラス：BillingInfo commUniqueId：2000 BillingAccount：0023456 BillingManager：ジョン・スミス
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は重複を避けるために、アークの記録を保ち、1を持っており、円弧としてそれの一部を委任するために喜んで誰からも入手することができます。さらに、インターネット割り当て番号機関（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インスタンスを関連付けるために、人やリソースオブジェクトに追加されます。その値は、ユーザーのH.323会議所とSIP IPフォンに、例えば、関連するcommObjectsを指す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オブジェクト・クラス：（SUPトップ補助MAY（commURI）0.0.8.350.1.1.1.2.1 NAME 'commURIObject' DESC 'URI属性タイプを含むオブジェクト'）
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 attributeTypes属性:( 0.0.8.350.1.1.1.1.1 NAME 'commURI' DESC平等CaseExactMatchの構文1.3.6.1.4.1 'commUniqueIdの識別名を指すように標識URIフォーマット' .1466.115.121.1.15）アプリケーションユーティリティクラススタンダード
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
値の数参照commObjectインスタンスを含むディレクトリを特定のLDAP URLを含むURI標識マルチ定義。このLDAP URLで指定された検索フィルタはcommObjectクラスのcommUniqueId属性の平等の検索を指定しなければなりません。許容値（制御の場合）、当該利用者のエンドポイントを見つけるために使用注意。ラベルフィールドは、このようなユーザインタフェース表示の目的のための「ホームIP電話」または「デスクトップビデオ」として、エンドポイントの機能を表現するために使用することができます。フィールドのラベル部分は、「デスクトップビデオ」を示す以下の例のようにスペースを含む場合があります。 LDAP：：？//directory.acme.com/dc=acme,dc=com ??サブ（commUniqueId =ボブ）デスクトップビデオこの属性が便利な例（LDIFフラグメント）commURIだろうれるセマンティクスサンプルアプリケーション
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ユーザエージェント、または他のプロトコルエンドポイント）とそのすべてのエイリアスを可能にします。すべてのディレクトリエントリはエントリの構造化オブジェクトクラスとして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オブジェクト・クラス：（0.0.8.350.1.1.2.2.1 NAME 'commObject' DESC SUPトップ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'
OID：0.0.8.350.1.1.2.1.1 attributeTypes属性：（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 ) 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
平等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）値マルチ定義のアプリケーションユーティリティクラスの標準的な数のエンドポイントの一意のID。許容値は、（制御された場合）これは、このオブジェクトのRDNであるノート。実際には、常に1とすべてのエンドポイントのための唯一のcommUniqueIdがあるでしょう。この属性は、一意commObjectディレクトリ内のエンドポイントを識別します。これは、そのディレクトリ内で一意でなければなりませんが、グローバルに一意である必要はありません。この属性は、エンタープライズ・ディレクトリに関係がありません。この属性は有用な例（LDIF断片）commUniqueIdされるであろうためセマンティクス例用途：ボブ
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 attributeTypes属性：0.0.8.350.1.1.2.1.2 NAME 'commOwner' DESC平等CaseExactMatchのSYNTAX '標識されたURIは、元の所有者を指すように' 1.3.6.1.4.1.1466.115.121.1 URIフォーマットはバックこのエントリに関連付けられた人物またはリソースオブジェクトを指すように標識された値がマルチ定義0.15）アプリケーションユーティリティクラス標準番号。許容値（制御された場合）、所有者（複数可）の逆エントリファインダとして使用注意。この属性は、グループを指すことがあります。このURIは、CNを指すことができることに留意されたいが、両方commObjectおよび企業ディレクトリを横断認証情報を結合することが所望される用途では、DNなくCNにcommOwner点は、このように一意の所有者を特定することが望ましいかもしれませんcommObject。 LDAP：？?? //directory.acme.com/dc=acme,dc=comサブ（CN =ボブ％20smith）commOwner：UID =ボブこの属性は有用な例（LDIF断片）commOwnerされるであろうためセマンティクス例アプリケーション、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 attributeTypes属性：SYNTAX 1.3.6.1.4.1.1466.115 'エントリは世界に見えているか否かを判断するには'（0.0.8.350.1.1.2.1.3 NAME 'commPrivate' DESC。 121.1.26、ユーザが使用する値マルチ定義の）アプリケーションユーティリティクラス標準番号及びすなわち、エンドポイントのプライバシーオプションを示し、非上場番号。許容値は、（制御されている場合）、この属性は、ブールのように定義される注意します。この勧告の今後のバージョンでは、プライバシーの複数のタイプに対応するために、この属性の統制語彙を開発することがあります。この属性が便利な例（LDIFフラグメント）commPrivateだろうれるセマンティクス用途例：真
This section contains a schema configuration file for commURIObject and commObject that can be used to configure an LDAP server to support these classes.
このセクションでは、これらのクラスをサポートするために、LDAPサーバを設定するために使用することができcommURIObjectとcommObjectのスキーマ設定ファイルが含まれています。
# 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ディレクトリの##抽象は##で通信オブジェクトを表すための＃通信対象のスキーマは##スキーマこの文書では、[LDAPv3の] LDAPディレクトリ内の通信＃オブジェクトを表すためのスキーマを定義します。これは、通信対象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 #
＃0.1 =コミュニケーション関連の仕事＃.1.1 = commURIObject＃.1.1.1 =属性＃.1.1.2 =オブジェクトクラス＃.1.1.3 =構文##属性タイプの定義##次の属性タイプは、この文書で定義されています。 ## commURIのDN：CN =スキーマ変更タイプ：あなたは属性の定義を変更する必要がある場合は##を変更し、＃最初削除し、これはあなたがcommObject＃オブジェクトクラスを追加している最初の時間であれば1つのステップは##で再度追加これは＃失敗しますので、このLDIFファイルを使用して、その後、削除attributeTypes属性の変更を＃をコメントアウトする必要があります。また、あなたのldapmodifyは、エラーの＃を継続するようにスイッチを持っている場合は、単にそのスイッチを使用する - あなたは＃削除は注意している場合：attributeTypes属性のattributeTypes属性：（0.0.8.350.1.1.1.1.1 NAME「commURI」） - ##再追加の属性を - 定義＃の変更があった場合には＃を追加します。attributeTypes属性のattributeTypes属性を：（0.0.8.350.1.1.1.1.1 NAME URIフォーマット標識「commURI」DESC」をcommUniqueIdの識別名を指すように「平等CaseExactMatchのSYNTAX 1.3.6.1.4.1.1466.115.121.1.15） - ＃のオブジェクトクラス定義##次のオブジェクト・クラスは、この文書で定義されています：## commURIObject ## commURIObject ##この補助オブジェクトクラスは、URI属性のタイプを表し＃
# 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 #
＃削除：オブジェクト・クラスオブジェクト・クラス：（0.0.8.350.1.1.1.2.1 NAME 'commURIObjectは'） - を追加：オブジェクトクラスオブジェクトクラス：URI属性タイプを含んでいる（0.0.8.350.1.1.1.2.1 NAME 'commURIObject' DESC「オブジェクト「SUPトップ補助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
LDAPディレクトリの##抽象は##で通信オブジェクトを表すための＃通信対象のスキーマは##スキーマこの文書では、[LDAPv3の] LDAPディレクトリ内の通信＃オブジェクトを表すためのスキーマを定義します。これは、通信対象[commObject]を表すためにスキーマ要素番号を定義します。 ### 0.1 =コミュニケーション関連の仕事は＃.1.2 = commObject＃.1.2.1 = ##以下の属性タイプがで定義されています。＃.1.2.2 =オブジェクトクラス＃.1.2.3 =構文###タイプアトリビュート定義の属性このドキュメント：## commUniqueId＃commOwner＃commPrivate DN：CN =スキーマ変更タイプは：あなたは属性の定義を変更する必要がある場合は、1つのステップで、＃は、最初の削除と再追加は##を変更します
# # 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'
これが初めてあなたは、このLDIFファイルを使用してオブジェクトクラスcommObject番号を追加しているがある場合、これは＃が失敗しますので、＃＃が、あなたは削除attributeTypes属性の変更を＃をコメントアウトする必要があります。また、あなたのldapmodifyは、エラーの＃を継続するようにスイッチを持っている場合は、単にそのスイッチを使用する - あなたは＃削除は注意している場合：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'） - の##の属性を再度追加 - の場合には、定義＃の変更がありました＃の追加：attributeTypes属性のattributeTypes属性：（0.0.8.350.1.1.2.1.1 NAME平等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 'エンドポイントのユニークなIdを保持するために' 'commUniqueId' DESC）attributeTypes属性を：（0.0平等CaseExactMatchのSYNTAX 1.3.6.1.4.1.1466.115.121.1.15 'URIは元の所有者を指すように標識された' .8.350.1.1.2.1.2 NAME 'commOwner' DESC）はattributeTypes属性：（0.0.8.350.1.1.2.1。 3 NAME SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）「エントリは世界に見えているか否かを判断するには」「commPrivate」DESC - ＃オブジェクトクラス定義##次のオブジェクト・クラッセオブジェクト・クラスオブジェクト・クラス：（0.0.8.350.1.1.2.2 - ## commObject ## commObject ##削除：：：オブジェクトクラスオブジェクトクラスを追加（0.0.8.350.1.1.2.2.1 NAME「commObject」）のは、この文書で定義されています。 1 NAME 'commObject'
DESC 'object that contains the Communication attributes' SUP top STRUCTURAL MUST commUniqueId MAY ( commOwner $ commPrivate ) ) - # # end of LDIF #
DESC 'コミュニケーションを含むオブジェクトは、属性' SUPトップ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.
属性のインデックス付けは、実装固有活性であり、所望の用途に依存します。非インデックスの属性が使用できないいくつかのアプリケーションをレンダリングするために十分に長い検索時間をもたらすことができます。特に、ユーザーとエイリアスルックアップが高速である必要があります。附属書インデックスプロファイルは、ディレクトリのアプリケーションのディレクトリでの使用に最適化されます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ユーザエージェント（UAS）を表し、ユーザとそれらのエンドポイントを関連付ける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
この勧告は、ITU-T勧告で説明したようにCommObjectディレクトリアーキテクチャを補足するものです。 H.350は、スタンドアローンのアーキテクチャとして使用するものではありません。一緒にH.350 CommObjectアーキテクチャを使用すると、このLDAPスキーマの実装は、このように、ユーザはSIPでサポートされている白いページの検索とアクセスクリック可能なダイヤルを実行することができ、既存のエンタープライズディレクトリにSIPユーザエージェントと会議デバイスの統合を容易デバイス。このスキーマを実装する主な理由は、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.
録音。 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勧告に列挙設計目標を達成するために必要な最小限のセットを表すものではありません。 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勧告の基礎を参照してください。スキーマ拡張の議論のための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ユーザエージェント（UAS）を表します。これは、補助クラスであり、ITU-T勧告で定義されている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オブジェクトのSUPトップ補助MAY（SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ SIPIdentityProxyAddress $ SIPIdentityUserName $ SIPIdentityPassword $ 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 attributeTypes属性：（0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' DESC平等CaseExactMatchのSUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115 'SIP UAのユニバーサルリソースインジケータ'。 SIPにおける通信リソースを識別する値の121.1.15）アプリケーションユーティリティクラス規格番号マルチ定義ユニフォームリソース識別子。通常、ユーザー名とホスト名が含まれており、電子メールアドレスへの形式で、多くの場合、類似しています。許容値（制御された場合）は、この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：一口：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)
OID：0.0.8.350.1.1.6.1.2 attributeTypes属性：（0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress' DESC平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 'レジストラの位置指定' をREGISTER要求を処理し、特定のドメインのためにロケーションサーバに転送サーバが属するドメインの）値のアプリケーションユーティリティクラス標準番号マルチ定義アドレス。許容値（制御されている場合）
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
メモは、RFC 3261には、ユーザエージェントはアドレス・オブ・レコード、またはマルチキャストで使用して、コンフィギュレーションによって彼らのレジストラのアドレスを発見することができますことを述べていることに注意してください。この属性は、最初のシナリオのために使用することができるRFC 3261のスコープのうち、第1のシナリオでは、コンフィギュレーションによって、留意されたいです。これは、手動で達成（例えば、ユーザーの正しいレジストラのアドレスを表示する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 attributeTypes属性：（0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress' DESC平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1 'SIPプロキシの場所を指定します'。 26）ドメイン内の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 attributeTypes属性：平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1（0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' DESC 'UAのIPアドレスまたはFQDN'。 26）の値のアプリケーションユーティリティクラスの標準的な数は、マルチ定義は、UAのIPアドレスまたは完全修飾ドメイン名を指定します。許容値は、（制御された場合）、この属性は、プロキシまたはレジストラを伴わないUA 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
OID：0.0.8.350.1.1.6.1.5 attributeTypes属性：（0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' DESC 1.3.6.1.4.1.1466.115.121.1.40平等octetStringMatch SYNTAX 'SIPパスワードユーザエージェント'） RFC 2617によって廃止されたRFC 2069が、使用したので2617許容値（制御された場合）ノートはRFCに定義されるようにHTTPのために使用される値マルチ定義のアプリケーションユーティリティクラス標準番号SIPユーザエージェントのパスワードは、認証方式をダイジェストRFC 2543でHTTPダイジェストの基礎は、RFC 2617をサポートしている任意のSIPサーバは、ダイジェストアクセスと使用のために予約されている、SIPIdentityPasswordと一緒に、RFC 2069このSIPIdentityUserNameとの下位互換性を確保しなければなりません
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
認証ではなく、基本認証方法に使用するためのもの。 LDAPは、参考のために、ユーザのパスワードを格納するための一つの方法を提供します。パスワードはLDAPに格納されている場合は、LDAPサーバー攻撃のために特に貴重なターゲットになります。実装者は注意を行使して、暗号化、アクセス制御、およびこの属性にアクセスするためのトランスポート層セキュリティなど、適切なセキュリティ手順を実装することが推奨されます。 36zxJmCIB18dM0FVAj：この属性は有用な例（LDIF断片）SIPIdentityPasswordされるであろうためセマンティクス例アプリケーション
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 attributeTypes属性： 'ユーザエージェントのユーザ名'（0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' DESC平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1 （制御された場合）RFC 2617の許容値で定義された値のマルチ定義認証スキームをHTTPダイジェストに使用されるSIPユーザエージェントのユーザ名を、の0.15）アプリケーションユーティリティクラス標準番号ノートためRFC 2617によって廃止されたRFC 2069、 、RFC 2543にHTTPダイジェスト認証のための基礎として使用し、HTTPダイジェスト認証をサポートしているSIPサーバがSIPIdentityPasswordと共に、RFC 2069このSIPIdentityUserNameとの下位互換性を確保する必要があり、RFC 2617で定義されるように、ダイジェストとの使用のために予約されていますアクセス認証、および基本認証方式で使用するためのものではありません。多くの場合、ユーザ名は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 attributeTypes属性： 'ユーザーが所属できるサービスを定義するには'（0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' DESC平等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch構文1.3.6.1.4.1 .1466.115.121.1.26）の値マルチ定義のアプリケーションユーティリティクラスの標準数はこれは、ユーザーが所属できるサービスのレベルを説明しています。許容値（制御された場合）は、この属性は、SIPで見つかったデータ要素を表していない注意します。 SIP自体は、サービスレベルの区別をサポートしていません。代わりに、この属性は、LDAPで直接サービス・レベルの情報を記憶するためのメカニズムを提供します。このマッピングは、サービスプロバイダーは、ディレクトリ内SIPIdentityServiceLevelインスタンスの値を変更せずに、既存のLDAPディレクトリに適応することができます。プレミアム：この属性が便利な例（LDIFフラグメント）SIPIdentityServiceLevelだろうれるセマンティクスサンプルアプリケーション
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
LDAPディレクトリは##抽象的なは##でSIPIdentityオブジェクトを表すため＃SIPIdentityオブジェクトスキーマは##スキーマこの勧告は、[のLDAPv3] LDAPディレクトリにSIPIdentity番号オブジェクトを表すためのスキーマを定義します。これはSIPIdentityオブジェクト[SIPIdentity]を表すためにスキーマ要素番号を定義します。 ## 0.1 =コミュニケーション関連の仕事＃.1.6 = SIPIdentity＃.1.6.1 =属性＃.1.6.2 =オブジェクトクラス
# .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 )
## SIPIdentitySIPURI＃SIPIdentityRegistrarAddress＃SIPIdentityProxyAddress＃SIPIdentityAddress＃SIPIdentityPassword＃SIPIdentityUserName＃SIPIdentityServiceLevelます。dn：CN =スキーマ変更タイプ：＃を変更＃.1.6.3 =構文### ###次の属性タイプは、この勧告で定義されているタイプの定義属性1ステップは##であなたは、属性の定義を変更する必要がある場合は＃、＃、最初の削除と再追加、これはあなたがこのLDIFファイルを使用してオブジェクトクラスSIPIdentity番号を追加する初めてである場合は、＃をコメントアウトする必要がありこれは＃が失敗しますので、attributeTypes属性の変更を削除します。また、あなたのldapmodifyは、エラーの＃を継続するようにスイッチを持っている場合は、単にそのスイッチを使用する - あなたは＃削除注意している場合：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'） - ＃ ＃属性を再度追加 - の場合には＃が追加定義＃の変化がある：attributeTypes属性のattributeTypes属性：EQUALITY CaseExactMatchのSUBSTR（0.0.8.350.1.1.6.1.1 NAME「SIPIdentitySIPURI」DESC「SIP UAのユニバーサルリソースインジケータ」 caseExactSubstringsMatch SYNTAX 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'
attributeTypes属性：（0.0.8.350.1.1.6.1.2 NAME 'SIPIdentityRegistrarAddress' DESCが等しい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平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 'SIPプロキシの場所を指定'）attributeTypes属性：（0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' DESC「IP UAのアドレス」平等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 'ユーザーエージェントSIPパスワード' 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平等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「ユーザーが属することができるサービスを定義するには「平等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26） - ＃オブジェクトクラス定義##次のオブジェクトクラスは、この勧告で定義されます。## SIPIdentity ## SIPIdentity ##削除：オブジェクトクラスオブジェクトクラス： （0.0.8.350.1.1.6.2.1 NAME 'SIPIdentityは'） - を追加：オブジェクト・クラスオブジェクト・クラス：（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 #
DESC "SIPIdentityオブジェクトのSUPトップ補助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
SIPアイデンティティのSIP URI：平等
SIPIdentityRegistrarAddress: no recommendation
SIPIdentityRegistrarAddress：なし推奨
SIPIdentityProxyAddress: no recommendation
SIPIdentityProxyAddress：なし推奨
SIPIdentityAddress: equality
SIPアイデンティティアドレス：平等
SIPIdentityUserName: equality
SIPアイデンティティユーザ名：平等
SIPIdentityPassword: no recommendation
SIPIdentityPassword、勧告なし
SIPIdentityServiceLevel: equality
SIPアイデンティティサービスレベル：平等
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.
ビデオ会議ミドルウェア（VidMid-VC）ワーキンググループ、インターネット2（www.internet2.edu）とビデオ開発イニシアティブ（www.vide.net）の共同の努力の外に開発したこの作品。国際研究ネットワーク全体のIPインフラストラクチャ上で動画や音声を提供する：（videnet.unc.eduのhttps //）学術テストベッドアーキテクチャはViDeNetで発見された展開の課題に対応して開発されました。
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研究グループ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付属資料Dは、それぞれHTTPダイジェストを）共有していることに留意すべきです。これらのアプローチは、コールサーバは、パスワードへのアクセス権を持っている必要があります。コールサーバまたは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で指定されるように、認証、完全性、および機密性を提供するために、S / MIMEで使用することができる[5]。
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]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（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]フランクス、J.、ハラム - ベイカーP.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.
[7]スミス、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]ハウズT.およびM.スミス、 "理解と展開LDAPディレクトリサービス"、新しいライダー出版、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]ハウズT.およびM.スミス、「ライトウェイトディレクトリアクセスプロトコルとLDAPプログラミングディレクトリ対応アプリケーション」、新しいライダー出版、ISBN：15.787億、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.
この仕様は、標準自体（セクション4）内のテキストを変更することなく、[4] ITU-T出版のRFCの出版物です。本節では唯一の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
タイラージョンソンエディタ、ノースカロライナ州チャペルヒル、NC 27599のH.350大学
Phone: +1.919.843.7004 EMail: Tyler_Johnson@unc.edu
電話：+1.919.843.7004電子メール：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
さかえ おくぼ らっぽｒてうｒ ふぉｒ Ｑ。４／１６、 いつーＴ ＳＧ１６ わせだ うにゔぇｒしｔｙ ＹＲＰ いちばんかん、 ３ー４ ひかりのおか よこすかーし、 ２３９ー０８４７ じゃぱん
Phone: +81 46 847 5406 EMail: sokubo@waseda.jp
電話：+81 46 847 5406 Eメール：sokubo@waseda.jp
Simao Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Place des Nations Geneva CH1211 - Switzerland
シモンFerrazのデ・カンポスネト参事官、ITU-T SG 16国際電気通信連合・プレイスデナシオンジュネーブCH1211 - スイス
Phone: +41-22-730-6805 EMail: simao.campos@itu.int
電話：+ 41-22-730-6805 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。