RFC3944 日本語訳
3944 H.350 Directory Services. T. Johnson, S. Okubo, S. Campos. December 2004. (Format: TXT=61160 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループT.ペニス要求をネットワークでつないでください: 3944 ノースカロライナカテゴリのU.: 情報のS.のオークボ早稲田大学S.カンポITU-T2004年12月
H.350 Directory Services
H.350ディレクトリサービス
Status of this Memo
この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).
Copyright(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.
国際Telecommunications Union Standardization Sector(ITU-T)はマルチメディア会議プロトコルを支持してディレクトリ・サービス・アーキテクチャを指定するRecommendationsの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のRecommendations H.350とH.350.4の全体の標準のテキストを含んでいます。 残っているセクションはITU-Tバージョンに含まれているのではなく、このドキュメントだけに含まれています。
Johnson, et al. Informational [Page 1] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[1ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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
1. 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 コンベンションは本書では.4 4を使用しました。 H.350. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1。 目標. . . . . . . . . . . . . . . . . . 6 4.1.2を設計してください。 図式. . . . . . . . . . . . . . 7 4.2commURIObject定義を広げています。 . . . . . . . . . . . . . . . 10 4.2.1commURIObject。 . . . . . . . . . . . . . . . . . 10 4.2.2commURI。 . . . . . . . . . . . . . . . . . . . . 10 4.3. CommObject定義. . . . . . . . . . . . . . . . . 11 4.3.1commObject. . . . . . . . . . . . . . . . . . . 11 4.3.2commUniqueId. . . . . . . . . . . . . . . . . . 11 4.3.3commOwner。 . . . . . . . . . . . . . . . . . . . 12 4.3.4commPrivate。 . . . . . . . . . . . . . . . . . . 13 4.4. CommObject LDIFファイル. . . . . . . . . . . . . . . . . 13 4.4.1。 commURIObject. . . . . . . . . . . . . 13 4.4.2のためのLDIF。 commObjectのためのLDIF。 . . . . . . . . . . . . . . 15 4.5. H.350はインデックスプロフィールを付加します。 . . . . . . . . . . . . 17 5. H.350.4. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1。 図式. . . . . . . . . . . . . . 18 5.2を広げています。 オブジェクトクラス定義。 . . . . . . . . . . . . . . . 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はファイルします。 . . . . . . . . . . . . . . . . 23 5.4. H.350.4はA Indexingプロフィールを付加します。 . . . . . . . . . . . 26 6. 承認. . . . . . . . . . . . . . . . . . . . . . . 26 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 27 8。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. 引用規格。 . . . . . . . . . . . . . . . . . 28 8.2. 有益な参照。 . . . . . . . . . . . . . . . . 28 9. 他の仕様との関係。 . . . . . . . . . . . . 29 10. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 29 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 30
Johnson, et al. Informational [Page 2] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[2ページ]の3944時間.350のRFCディレクトリサービス2004年12月
1. Scope
1. 範囲
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.
国際Telecommunications Union Standardization Sector(ITU-T)はマルチメディア会議プロトコルを支持してディレクトリ・サービス・アーキテクチャを指定するRecommendationsの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シリーズでは、Recommendation H.350はベースアーキテクチャとオブジェクトのクラスを指定します、下位のRecommendationsは個々のプロトコルに特定の要素を指定しますが。 現在、Recommendationsは:
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、標準的でないプロトコルのための--一口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共同体へのこのドキュメントで利用可能にします。
2. Terminology
2. 用語
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 Proxyサーバです。すべて合図していないプロトコルが呼び出しサーバを使用することに注意してください。
* endpoint: a logical device that provides video and/or voice media
encoding/decoding, and signalling functions. Examples include:
* 終点: ビデオを提供する論理的なデバイス、そして/または、機能をコード化するか、解読して、または示す声のメディア。 例は:
Johnson, et al. Informational [Page 3] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[3ページ]の3944時間.350のRFCディレクトリサービス2004年12月
* 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.
* 企業ディレクトリ: 組織のユーザの情報の正準な収集。 通常、この情報は、全体を作成するためにさまざまな組織的なユニットから集められます。 例えば、人事部は名前とアドレスを提供するかもしれません、とTelecommunicationsは電話番号、TechnologyがEメールアドレスを提供するかもしれない情報などを前提とするかもしれません。 このアーキテクチャの目的のために、企業ディレクトリが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.
* ホワイトページ: エンドユーザが別のユーザのアドレスを調べることができるアプリケーション。 これは、ウェブベースである、またはある他のユーザーインタフェースを使用するかもしれません。
3. Conventions used in this document
3. 本書では使用されるコンベンション
Conventions in this document conform to ITU-T guidelines. In this Recommendation, the following conventions are used:
コンベンションは本書ではITU-Tガイドラインに従います。 このRecommendationでは、以下のコンベンションは使用されています:
"Shall" indicates a mandatory requirement.
"Shall"は義務的な要件を示します。
"Should" indicates a suggested but optional course of action.
"Should"は示されましたが、任意の行動を示します。
"May" indicates an optional course of action rather than a recommendation that something take place.
「5月」は何かが行われるという推薦よりむしろ任意の行動を示します。
References to clauses, sub clauses, annexes and appendices refer to those items within this Recommendation unless another specification is explicitly listed.
別の仕様が明らかにリストアップされない場合、節、潜水艦節、別館、および付録の参照はこのRecommendationの中のそれらの項目を示します。
4. H.350
4. H.350
The normative text of H.350 is reproduced in this section.
H.350の標準のテキストはこのセクションで複製されます。
4.1. Scope
4.1. 範囲
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
このRecommendationは、マルチメディア会議のためにLDAPを使用することでディレクトリ・サービス・アーキテクチャについて説明します。 標準化されたディレクトリサービスは終点、探せるホワイトページ、クリック可能なおよびダイヤルすることで人々の協会をサポートすることができます。 また、ディレクトリサービスは中で補助されることができます。
Johnson, et al. Informational [Page 4] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[4ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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図式について説明します。 それはビデオ、声の特有のディレクトリ、企業ディレクトリ、呼び出しサーバ、および終点の相互関係のために設計と実装問題について議論します。
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つのプロバイダーによって開発されたホワイトページサーチエンジンは2番目のプロバイダーによって生産されたIP電話にディレクトリ情報に役立つかもしれません、合図がしかし、3番目のプロバイダーによって作成された呼び出しサーバによって管理されている状態で。 それぞれのこれらの異種のシステムは同じ基本的なデータ送信端末にアクセスできます、各システムの別々の管理を調整する必要性を減少するか、または排除して。 ユーザへの重要な利益はこのデータの管理を既存の顧客管理ツールに組み入れることができるということです、アプリケーションの迅速でフレキシブルな拡大を考慮して。 本当に、多くの技術プロバイダーが既にそれらの製品にLDAPを組み入れますが、標準化された図式の利益なしでやむを得ずそうしました。 このRecommendationは、相互運用性と性能を向上させるためにそれらの表現を標準化するために取り組みを表します。
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はいくつかの会議プロトコルのために既に標準化されますが、ディレクトリにおける彼らの表現はそのように標準化されません。 このRecommendationは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
正しい設定がサービスプロバイダーと終点の両方にアクセスしやすい位置にサービスプロバイダーによって保存されるなら、終点構成の管理を改良できます。 LDAPは呼び出しサーバと終点の両方からアクセスできる便利な番地を提供します。 したがって、サポート終点構成にディレクトリを使用するのは可能です。(簡易型の操作とユーザに移動性をサポートするのに、構成は重要です)。 また、他の技術が終点構成(著しくSNMPの登録サーバアドレスを得るための完全な構成とSRV記録の使用)をサポートすることに注意してください。 したがって、H.350は正式の終点構成アーキテクチャとして見なされるのではなく、むしろそうすることができる1つのツールとして見なされるべきです。
Johnson, et al. Informational [Page 5] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[5ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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.
このタスクを助けてください。 特徴終点特有の構成として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と呼ばれるジェネリックオブジェクトのクラスを使用します。 補助のクラスはRecommendationsのH.350.xシリーズで説明されるようにH.323、H.235、またはH.320などの特定のプロトコルを表します。 1つ以上のプロトコルをサポートする終点を表すために複数の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はcommObjectに関連している個人かリソースを示すcommOwnerと呼ばれる指針を含んでいます。 このように、人々かリソースを終点に関連づけることができます。 企業ディレクトリで必要である唯一の変化が簡単なオブジェクトのクラスcommURIの追加です。 CommObjectデータは同じくらいか完全に別々のディレクトリに例示されて、その結果、実装における柔軟性を許容するかもしれません。
4.1.1. Design Goals
4.1.1. デザイン目標
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) 番号案内に電話をかけるのを(例えば、終点アドレス)見つけることができるオンライン探せる「ホワイトページ」を可能にしてください、ユーザの他の「伝統的な」ディレクトリ情報と共に、名前、アドレス、電話、メールなどのように。
Johnson, et al. Informational [Page 6] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[6ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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) 1ユーザあたりの終点の複数のインスタンスかリソースをサポートすることができてください。
6) represent endpoints that support more than one protocol, for
example, endpoints that are both H.320 and H.323;
6) 例えば、1つ以上のプロトコルが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) 正しい構成設定をサポートツールとして1終点あたり1個のベースにエンドユーザに記録するか、または自動的に終点に積み込むことができるように終点構成の十分な情報を保存してください。
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.
このRecommendationの範囲はプロトコル自体の中で定義されるように機能性の拡大をプロトコルに含めません。 特徴を加えるのが、Recommendationの意図ではありませんが、単に存在を表すのは属性について議定書の中で述べます。 本件への例外は機能性がcommPrivate属性などのディレクトリ自体によって含意される時です。
4.1.2. Extending the Schema
4.1.2. 図式を広げています。
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オブジェクトのクラスは特定の実装に必要に応じて広げられるかもしれません。 例えば、クラスは、支払い参照がコードであるとサポートするために広げられるかもしれません。 図式への拡大は、Recommendationの一部であることはみなされないで、またコンプライアンスを意味しません。
Johnson, et al. Informational [Page 7] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[7ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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 schemasを広げるのが、Recommendationsによってサポートされるより多くの情報を表すのに必要であるかもしれません。 ディレクトリの属性によって表される必要がある独占終点の機能性を実装する開発者にとって、これは重要であるかもしれません。 また、エンタープライズアプリケーションに、それも重要であるかもしれません。 例えば、'modelNumber'、および'accountNumber'は、Recommendationで定義されない属性に関する例ですが、実装されるなら、役に立つかもしれません。 このアーキテクチャに属性を追加するのはこのRecommendationとの互換性を壊さない方法で完了していなければなりません。
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.
図式デザインと拡大の十分な議論はこのRecommendationの範囲を超えています。 詳細に関してIETF RFC2252を見てください。 図式拡大へのこのRecommendationとの互換性を壊さない2つの基本的なアプローチは、サブクラスを通した拡大と補助のクラスの使用で拡大です。
4.1.2.1. Extension Through Subclass
4.1.2.1. サブクラスを通した拡大
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名前'BillingInfo'DESC'支払い参考情報'一口のcommObjectの構造的な5月(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
dn: commUniqueId=2000、ou=h323identity、dcは会社、dc=com objectclassと等しいです: 最高objectclass: commObject objectclass: h323Identity
Johnson, et al. Informational [Page 8] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[8ページ]の3944時間.350のRFCディレクトリサービス2004年12月
objectclass: BillingInfo commUniqueId: 2000 BillingAccount: 0023456 BillingManager: John Smith
objectclass: BillingInfo commUniqueId: 2000BillingAccount: 0023456BillingManager: ジョン・スミス
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に説明されるように
4.1.2.2. Extension Through The Use Of Auxiliary Classes
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'支払いReference情報'SUPの最高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.
上司がどう先端と補助物に構造的なaであるので変えられた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
dn: commUniqueId=2000、ou=h323identity、dcは会社、dc=com objectclassと等しいです: 最高objectclass: commObject objectclass: BillingInfo
Johnson, et al. Informational [Page 9] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[9ページ]の3944時間.350のRFCディレクトリサービス2004年12月
commUniqueId: 2000 BillingAccount: 0023456 BillingManager: John Smith
commUniqueId: 2000BillingAccount: 0023456BillingManager: ジョン・スミス
4.1.2.3. Object Identifiers
4.1.2.3. オブジェクト識別子
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.
属性のObject Identifier(OID)は通常、ドットによって切り離された整数の系列として書かれたユニークな数字の識別子です。 例えば、commUniqueIdのためのOIDはそうです。0.0 .8 .350 .1 .1 .2 .1 .1。 すべての属性に、OIDがなければなりません。 OIDsは、1つを持っているだれからも得ることができて、アークとしてそれの部分を代表として派遣しても構わないと思っています、重複を避けるためにアークに関する記録をつけて。 さらに、インターネットAssigned民数記Authority(IANA)は尋ねるどんな組織にもOIDsを配ります。
4.2. commURIObject Definition
4.2. commURIObject定義
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インスタンスは異なったサービスプロバイダーによって管理された終点を示すかもしれません。
4.2.1. commURIObject
4.2.1. commURIObject
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の.350の.1の.1の.1の.2.1NAME'commURIObject'DESC'URI属性タイプを含むオブジェクト'SUP最高な.8AUXILIARY MAY(commURI))
4.2.2. commURI
4.2.2. 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 attributetypes:、(0.0.8.350.1.1.1.1.1NAME'commURI'DESC'はcommUniqueIdの分類名へのポイントとURI形式をラベルした'EQUALITY caseExactMatch SYNTAX1.3.6.1.4.1.1466.115.121.1.15)アプリケーションユーティリティのクラスStandard
Johnson, et al. Informational [Page 10] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[10ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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を含む値のマルチDefinition Labelled URIの数。 このLDAP URLによって指定された検索フィルタはcommObjectのクラスのcommUniqueId属性の平等検索を指定するものとします。 ユーザの終点がはっきりしていないのがわかる許容値(制御されるなら)注意Used。 ラベルフィールドは終点の機能を表すのに使用されるかもしれません、ユーザーインタフェースディスプレイ目的のための'ホームIP電話'や'デスクトップビデオ'のように。 分野のラベル部分が'デスクトップビデオ'を示している下の例のように空間を含むかもしれないことに注意してください。 この属性が役に立つExample(LDIFは断片化する)commURIである意味論Exampleアプリケーション: 頂上、ldap://directory.acme.com/dc=dc=com?潜水艦?(commUniqueId=はたたきます)デスクトップビデオ
4.3. CommObject Definition
4.3. CommObject定義
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の補助のクラスを含むかもしれません。
4.3.1. commObject
4.3.1. commObject
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.1NAME'commObject'DESC'Communication属性を含むオブジェクト'SUP先端STRUCTURAL MUST commUniqueId5月の(commOwner$commPrivate))
4.3.2. commUniqueId
4.3.2. commUniqueId
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、'終点がユニークなIdであることを保持する'.1.1NAME'commUniqueId'DESC
Johnson, et al. Informational [Page 11] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[11ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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構文1.3.6.1.4、.1、.1466、.115、.121、.1、.26) ユーティリティが標準のNumberを分類するアプリケーションはマルチDefinitionを評価します。終点の固有のID。 許容値(制御されるなら) 注意ThisはこのオブジェクトのRDNです。 実際には、唯一無二の各終点あたり1commUniqueIdがいつもあるでしょう。 この属性は唯一commObjectディレクトリの終点を特定します。 それは、そのディレクトリの中でユニークでなければなりませんが、グローバルにユニークである必要はありません。 この属性に、企業ディレクトリとの関係が全くありません。 この属性が役に立つExample(LDIFは断片化する)commUniqueIdである意味論Exampleアプリケーション: ボブ
4.3.3. commOwner
4.3.3. commOwner
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)
OID: 0.0.8.350.1.1.2.1.2 attributetypes: 0.0.8.350.1.1.2.1.2 NAME'commOwner'DESC'が最初の所有者'EQUALITY caseExactMatch SYNTAX1.3.6.1に.4を指して戻すためにURIをラベルした、.1、.1466、.115、.121、.1、.15) 人に指して戻すマルチDefinition Labelled URI形式かリソースオブジェクトがこのエントリーに関連づけた値のアプリケーションユーティリティのクラスStandard Number。 許容値(制御されるなら) 所有者の逆のエントリーファインダーとしてUsedに注意します。 この属性はグループを示すかもしれません。 このURIがcnを示すことができますが、commObjectと企業ディレクトリの両方の向こう側に認証情報を縛るのが必要であるアプリケーションでは、commOwnerがcnよりむしろdnを示すのが、望ましいかもしれないことに注意してください、その結果、唯一、commObjectの所有者を特定します。 この属性が役に立つExampleである意味論Exampleアプリケーション(LDIF断片)
Johnson, et al. Informational [Page 12] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[12ページ]の3944時間.350のRFCディレクトリサービス2004年12月
commOwner: ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith) commOwner: uid=bob,ou=people,dc=acme,dc=com
commOwner: 頂上、ldap://directory.acme.com/dc=dc=com?潜水艦?(ボブのcn=%20smith)commOwner: uidはボブと等しく、ouは人々と等しく、dcは頂上、dc=comと等しいです。
4.3.4. commPrivate
4.3.4. commPrivate
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: (0.0.8.350.1.1.2.1.3NAME''SYNTAX1.3.6ではなくエントリーが世界に目に見えるかどうか決めるcommPrivate'DESC'.1、.4、.1、.1466、.115、.121、.1、.26) 値のマルチDefinition ToのアプリケーションユーティリティのクラスStandard Numberは終点(すなわち、電話帳に載っていない番号)にユーザによって使用されて、プライバシーオプションを示します。 This属性がブールと定義されるという許容値(制御されるなら)メモ。 この属性が複数のタイプのプライバシーを収容するように、このRecommendationの将来のバージョンは制御ボキャブラリーを開発するかもしれません。 この属性が役に立つExample(LDIFは断片化する)commPrivateである意味論Exampleアプリケーション: 本当
4.4. CommObject LDIF Files
4.4. CommObject LDIFファイル
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のための図式構成ファイルを含みます。
4.4.1. LDIF for commURIObject
4.4.1. commURIObjectのための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 URI [commURIObject]. # # #
# LDAPのディレクトリ##抽象的な##ThisドキュメントのRepresenting Communication ObjectsのためのコミュニケーションObject Schema##Schemaは、LDAPディレクトリ[LDAPv3]にCommunication#オブジェクトを表すために図式を定義します。 それは、コミュニケーションオブジェクトURI[commURIObject]を表すために図式要素#を定義します。 # # #
Johnson, et al. Informational [Page 13] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[13ページ]の3944時間.350のRFCディレクトリサービス2004年12月
# .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
#
# .1 = 次の属性がタイプするコミュニケーション関連する仕事#.1=objectclass#.1.1.3=.1=commURIObject#.1.1.1=属性#.1.1.2構文##Attribute Type Definitions##、は本書では定義されます: # # commURI dn: cnは図式changetypeと等しいです: #属性の定義を変える必要があるなら、#、を変更してください、#、次に、これがこのLDIFファイルを使用することでcommObject#objectclassを加えるのが、初めてなら最初に#、を削除して、ワンステップ#で再加えてください、と#外で論評するべきである、この意志#やり損ない以来のattributetypes変更を削除してください。 代わりに、あなた、ldapmodifyする、あなたが#、が以下を削除するのに慎重であるなら、aを、誤りの#、を続けて、次に、ただそのスイッチを使用するために切り換えさせます。 attributetypes attributetypes: (0.0.8.350.1.1.1.1.1名の'commURI') - # # 属性を再加えてください--##定義の変化があるといけないので、加えてください: attributetypes attributetypes: (commUniqueId'EQUALITY caseExactMatch SYNTAX1.3.6.1のものの分類名に.4を指す0.0の.1の.1の.1NAME'commURI'DESC'ラベルされたURI.8.350.1.1形式、.1、.1466、.115、.121、.1、.15) - # 次のオブジェクトが分類するオブジェクトClass Definitions##は本書では定義されます: # # commURIObject##commURIObject##Thisの補助のオブジェクトのクラスはURI属性タイプ#の代理をします。
Johnson, et al. Informational [Page 14] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[14ページ]の3944時間.350のRFCディレクトリサービス2004年12月
#
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
#
# 削除します: objectclasses objectclasses: (0.0.8.350.1.1.1.2.1名の'commURIObject') - 加えます: objectclasses objectclasses: (0.0の.350の.1の.1の.1の.2.1NAME'commURIObject'DESC'URI属性タイプを含むオブジェクト'SUP最高な.8AUXILIARY MAY(commURI)) - # # LDIF#の端
4.4.2. LDIF for commObject
4.4.2. commObjectのための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のディレクトリ##抽象的な##ThisドキュメントのRepresenting Communication ObjectsのためのコミュニケーションObject Schema##Schemaは、LDAPディレクトリ[LDAPv3]にCommunication#オブジェクトを表すために図式を定義します。 それは、コミュニケーションオブジェクト[commObject]を表すために図式要素#を定義します。 # # # .1 = 次の属性がタイプするコミュニケーション関連する仕事#.1.2=commObject#.1.2.1=属性#.1.2.2=objectclass#.1.2.3=構文###Attribute Type Definitions##、は本書では定義されます: # # commUniqueId#commOwner#commPrivate dn: cnは図式changetypeと等しいです: ##属性の定義を変える必要があるなら#、を変更してください、次に、最初に、ワンステップで削除して、再加えてください。
Johnson, et al. Informational [Page 15] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[15ページ]の3944時間.350のRFCディレクトリサービス2004年12月
#
# 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#objectclassを加えるのが、初めてなら#外でコメントするべきである、この意志#やり損ない以来のattributetypes変更を削除してください。 代わりに、あなた、ldapmodifyする、あなたが#、が以下を削除するのに慎重であるなら、aを、誤りの#、を続けて、次に、ただそのスイッチを使用するために切り換えさせます。 attributetypes attributetypes: (0.0.8.350.1.1.2.1.1名の'commUniqueId') attributetypes: (0.0.8.350.1.1.2.1.2名の'commOwner') attributetypes: (0.0.8.350.1.1.2.1.3名の'commPrivate') - # # 属性を再加えてください--##定義の変化があるといけないので、加えてください: attributetypes attributetypes: (0.0.8.350.1.1.2.1.1NAME'終点がユニークな'Id EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX1.3.6であることを保持するcommUniqueId'DESC'.1、.4、.1、.1466、.115、.121、.1、.26) attributetypes: (最初の所有者'EQUALITY caseExactMatch SYNTAX1.3.6.1に.4を指して戻す0.0の.1の.2の.1の.2NAME'commOwner'DESC'ラベルされた.8.350.1URI、.1、.1466、.115、.121、.1、.15) attributetypes: (0.0.8.350.1.1.2.1.3NAME''SYNTAX1.3.6ではなくエントリーが世界に目に見えるかどうか決めるcommPrivate'DESC'.1、.4、.1、.1466、.115、.121、.1、.26) - # 次のオブジェクトが分類するオブジェクトClass Definitions##は本書では定義されます: # # commObject##commObject##、は以下を削除します。 objectclasses objectclasses: (0.0.8.350.1.1.2.2.1名の'commObject') - 加えます: objectclasses objectclasses: (0.0.8.350.1.1.2.2.1名の'commObject'
Johnson, et al. Informational [Page 16] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[16ページ]の3944時間.350のRFCディレクトリサービス2004年12月
DESC 'object that contains the Communication attributes'
SUP top STRUCTURAL
MUST commUniqueId
MAY ( commOwner $ commPrivate )
)
-
#
# end of LDIF
#
DESC'Communication属性を含むオブジェクト'SUP先端STRUCTURAL MUST commUniqueId5月の(commOwner$commPrivate) - # # LDIF#の端
4.5. H.350 Annex A Indexing Profile
4.5. H.350はインデックスプロフィールを付加します。
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.
属性のインデックスは、実装比活性であり、必要なアプリケーションによります。 非索引をつけられた属性はいくつかのアプリケーションを使用不可能に表すことができるくらい長い検索時間をもたらすことができます。 ユーザと別名ルックアップは著しく、速いはずです。 Annex A Indexing Profileはディレクトリアプリケーションのディレクトリにおける使用のために最適化されるcommObjectディレクトリのためにインデックス構成について説明します。 このプロフィールの使用は任意です。
commURI: no recommendation
commURI: 推薦がありません。
commUniqueId: equality
commUniqueId: 平等
commOwner: presence
commOwner: 存在
commPrivate: presence
commPrivate: 存在
5. H.350.4
5. H.350.4
The normative text of H.350 is reproduced in this section.
H.350の標準のテキストはこのセクションで複製されます。
5.1. Scope
5.1. 範囲
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.
このRecommendationは、マルチメディア会議のためにSIPを使用することでLDAPディレクトリ・サービス・アーキテクチャについて説明します。 特に、それは、ネットワークでSIP Userエージェント(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
このRecommendationがITU-T Recで議論するようにCommObjectディレクトリアーキテクチャを補うことを意図します。 スタンドアロンのアーキテクチャとして使用されているためにH.350であって、意図していません。 このLDAP図式の実装はH.350 CommObjectアーキテクチャの使用と共にSIP Userエージェントと会議デバイスの統合を既存のエンタープライズディレクトリに容易にします、その結果、ユーザがクリック可能なダイヤルするのがSIPデバイスでサポートしたホワイトページルックアップとアクセスを実行するのを許容します。 この図式を実装するプライマリ理由はITU-Tに記載されたものを含んでいます。
Johnson, et al. Informational [Page 17] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[17ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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.
Rec。 H.350、(CommObjectクラス定義) それらのように、特にSIP UAsの使用に申し込んでください。そうすれば、ベンダーを容易にするために、作成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.
このRecommendationの範囲はアーキテクチャが既存企業ディレクトリとホワイトページに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.
このRecommendationの範囲は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は特にホワイトページディレクトリアプリケーションのために配される興味があるプライマリ属性です。
5.1.1. Extending the schema
5.1.1. 図式を広げています。
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。
5.2. Object class definitions
5.2. オブジェクトクラス定義
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 Userエージェント(UAs)の代理をします。 それを補助のクラスであり、commObjectのクラスから得ます。(それは、ITU-T Recで定義されます)。 H.350。
5.2.1. SIPIdentity
5.2.1. SIPIdentity
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 objectclasses: (0.0.8.350.1.1.6.2.1NAME'SIPIdentity'DESC'SIPIdentityオブジェクト'SUP先端AUXILIARY MAY(SIPIdentitySIPURI$SIPIdentityRegistrarAddress$SIPIdentityProxyAddress$SIPIdentityUserName$SIPIdentityPassword$SIPIdentityServiceLevel$userSMIMECertificate))
Johnson, et al. Informational [Page 18] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[18ページ]の3944時間.350のRFCディレクトリサービス2004年12月
5.2.2. SIPIdentitySIPURI
5.2.2. SIPIdentitySIPURI
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名前'SIPIdentitySIPURI'DESC'一口Uaの普遍的なリソースインディケータ'平等caseExactMatch SUBSTR caseExactSubstringsMatch構文1.3.6.1.4、.1、.1466、.115、.121、.1、.15) SIPのコミュニケーションリソースを特定するアプリケーションユーティリティのクラスの標準のNumberの値のマルチDefinition Uniform Resource Identifier。 通常、ユーザ名とホスト名を含んでいて、形式においてEメールアドレスとしばしば同様です。 許容値(制御されるなら)のURIがSIPを設けるかもしれないという注意ThisかSIPS(安全な)。 SIPSが設けられる場合、URIは、SIPと対照的にSIPSを使用しているのを反映しなければなりません。 以下のExamplesを見てください。 この属性がユーザのSIP(S) UAの最も現在のリストの役に立つOnline表現である意味論Exampleアプリケーション。 例のSIPIdentitySIPURI: 一口: alice@foo.com //SIP例のSIPIdentitySIPURI: 一口: alice@152.2.158.212 //SIP例のSIPIdentitySIPURI: 一口: bob@birmingham.edu //SIPS例
5.2.3. SIPIdentityRegistrarAddress
5.2.3. SIPIdentityRegistrarAddress
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: (.2NAME'SIPIdentityRegistrarAddress'DESCが'記録係の位置を指定する'という0.0.8.350.1.1.6.1EQUALITY caseIgnoreIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26) 特定のドメインのためにREGISTER要求と推進を位置のサーバに扱うサーバが属するドメインへの値のマルチDefinition AddressのアプリケーションユーティリティのクラスStandard Number。 許容値(制御されるなら)
Johnson, et al. Informational [Page 19] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[19ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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
RFC3261が、ユーザエージェントが記録されている住所を使用する構成かマルチキャストで彼らの記録係アドレスを発見できると述べるという注意Note。 構成で、最初のシナリオはRFC3261のための範囲のように注意されます。 この属性は最初のシナリオに使用されるかもしれません。 それは手動で、(という例えば、ウェブページ、それがユーザのものを表示するH.350.4と共に自動的に意識している優れた正しい記録係アドレスであるかもしれません。ユーザエージェント。 この属性が役に立つホワイトページである意味論Exampleアプリケーションであり、ウェブページ、それはユーザの正しい設定情報を表示します。 例(LDIFは断片化する)のSIPIdentityRegistrarAddress: 152.2.15.22 //IPアドレスの例のSIPIdentityRegistrarAddress: sipregistrar.unc.edu //FQDNの例
5.2.4. SIPIdentityProxyAddress
5.2.4. SIPIdentityProxyAddress
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: (.3NAME'SIPIdentityProxyAddress'DESCが'SIP Proxyの位置を指定する'という0.0.8.350.1.1.6.1EQUALITY caseIgnoreIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26) ドメインの中でSIPプロキシのドメイン位置を指定する値のマルチDefinition AddressのアプリケーションユーティリティのクラスStandard Number。 RFC3261はSIPプロキシの役割を定義します。 プロキシを使用するREQUIREDではありませんが、多くの場合、許容値(制御されるなら)注意SIP UserエージェントはREQUIREDであるだろうこと。 この属性が役に立つホワイトページである意味論Exampleアプリケーションであり、ウェブページ、それはユーザの正しい設定情報を表示します。 例(LDIFは断片化する)のSIPIdentityProxyAddress: 172.2.13.234 //IPアドレスの例のSIPIdentityProxyAddress: sipproxy.unc.edu //FQDNの例
Johnson, et al. Informational [Page 20] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[20ページ]の3944時間.350のRFCディレクトリサービス2004年12月
5.2.5. SIPIdentityAddress
5.2.5. SIPIdentityAddress
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: (0.0.8.350.1.1.6.1.4NAME'SIPIdentityAddress'DESC'IPのアドレスかUa'EQUALITY caseIgnoreIA5Match SYNTAX1.3.6.1のもののFQDN、.4、.1、.1466、.115、.121、.1、.26) IPが扱う値のマルチDefinition Specifiesのアプリケーションユーティリティのクラスの標準のNumberかUAに関する完全修飾ドメイン名。 Thisが結果と考える許容値(制御されるなら)注意はUAコミュニケーションへのUAがダイレクトであるアプリケーションの役に立つかもしれません、プロキシか記録係にかかわらないで。 この属性がユーザの適切なユーザエージェント設定情報を表示する役に立つAウェブページである例のアプリケーション。 例(LDIFは断片化する)のSIPIdentityAddress: 152.2.121.36 //IPアドレスの例のSIPIdentityAddress: ipPhone.foo.org // FQDNの例
5.2.6. SIPIdentityPassword
5.2.6. SIPIdentityPassword
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.5NAME'SIPIdentityPassword''ユーザエージェントSIPパスワード'EQUALITY octetStringMatch SYNTAX1.3.6.1.4のDESC.1.1466.115、.121、.1、.40) SIPユーザエージェントのパスワードの、そして、RFC2617で定義されるHTTPダイジェスト認証体系に、中古の値のマルチDefinitionのアプリケーションユーティリティのクラスStandard Number。 Because RFC2069(RFC2617によって時代遅れにされました)がHTTP Digestの基礎としてRFC2543で使用されたという許容値(制御されるなら)メモ、RFCが2617であるとサポートするどんなSIPサーバもRFC2069との後方の互換性を確実にしなければなりません。 このSIPIdentityUserNameはDigest Accessによって役に立つ目的のためにSIPIdentityPasswordと共に予約されます。
Johnson, et al. Informational [Page 21] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[21ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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
認証であって、Basic Authenticationメソッドがある使用のために意図していません。 LDAPは参照のためのユーザパスワードを保存する1つのメソッドを提供します。 パスワードがLDAPに保存されるなら、それはLDAPサーバを攻撃のための特に貴重な目標にします。 作成者は、警戒して、この属性へのアクセスのために適切なセキュリティが暗号化や、アクセスコントロールや、トランスポート層セキュリティなどの手順であると実装するよう奨励されます。 この属性が役に立つExample(LDIFは断片化する)SIPIdentityPasswordである意味論Exampleアプリケーション: 36zxJmCIB18dM0FVAj
5.2.7. SIPIdentityUserName
5.2.7. SIPIdentityUserName
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.3という.1.6NAME'SIPIdentityUserName'DESC'ユーザエージェントユーザ名'EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX.6、.1、.4、.1、.1466、.115、.121、.1、.15) SIPユーザエージェントのユーザ名の、そして、RFC2617で定義されるHTTPダイジェスト認証体系に、中古の値のマルチDefinitionのアプリケーションユーティリティのクラスStandard Number。 Because RFC2069(RFC2617によって時代遅れにされました)がHTTP Digest Authenticationの基礎としてRFC2543で使用されたという許容値(制御されるなら)メモ、RFC2617で定義されるようにHTTP Digest AuthenticationをサポートするどんなSIPサーバもRFC2069との後方の互換性を確実にしなければなりません。 このSIPIdentityUserNameはSIPIdentityPasswordと共にDigest Access Authenticationによって役に立つ目的のために予約されて、Basic Authenticationメソッドがある使用のために意図しません。 多くの場合、ユーザ名がSIP URIの user@proxy.domain 部分から分析されることに注意してください。 その場合、この属性に居住するのは必要でないかもしれません。 この属性が役に立つExample(LDIFは断片化する)SIPIdentityUserNameである意味論Exampleアプリケーション: nelkhour
Johnson, et al. Informational [Page 22] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[22ページ]の3944時間.350のRFCディレクトリサービス2004年12月
5.2.8. SIPIdentityServiceLevel
5.2.8. SIPIdentityServiceLevel
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.7NAME'SIPIdentityServiceLevel'DESC. EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX1.3に'ユーザが属すことができるサービスを定義するために'.6.1.4、.1、.1466、.115、.121、.1、.26) 値のマルチDefinition ThisのアプリケーションユーティリティのクラスStandard Numberはユーザが属すことができるサービスのレベルについて説明します。 属性がする許容値(制御されるなら)注意ThisはSIPで見つけられたデータ要素を表しません。 SIP自身は、区別が使用中のレベルであるとサポートしません。 代わりに、この属性は直接LDAPでのサービスレベル情報のストレージにメカニズムを提供します。 このマッピングで、ディレクトリのSIPIdentityServiceLevelインスタンスの値を変えないで、サービスプロバイダーは既存のLDAPディレクトリに順応できます。 この属性が役に立つExample(LDIFは断片化する)SIPIdentityServiceLevelである意味論Exampleアプリケーション: プレミアム
5.3. SIPIdentity LDIF Files
5.3. SIPIdentity LDIFファイル
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 Objectを表して、抽象的な##This RecommendationがSIPIdentity#を表すために図式を定義するので、SIPIdentity Object Schema##SchemaはLDAPディレクトリ[LDAPv3]で反対します。 それは、SIPIdentityオブジェクト[SIPIdentity]を表すために図式要素#を定義します。 # # .1 = コミュニケーションはSIPIdentity#.1.6.1の=属性#.1.6.2=仕事#.1.6=objectclassを関係づけました。
Johnson, et al. Informational [Page 23] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[23ページ]の3944時間.350のRFCディレクトリサービス2004年12月
# .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=構文####Attribute Type Definitions##、はこのRecommendationで定義されます: # # SIPIdentitySIPURI#SIPIdentityRegistrarAddress#SIPIdentityProxyAddress#SIPIdentityAddress#SIPIdentityPassword#SIPIdentityUserName#SIPIdentityServiceLevel dn: cnは図式changetypeと等しいです: #属性の定義を変える必要があるなら、#、を変更してください、#、次に、これがこのLDIFファイルを使用することでSIPIdentity#objectclassを加えるのが、初めてなら最初に#、を削除して、ワンステップ#で再加えてください、と#外で論評するべきである、この意志#やり損ない以来のattributetypes変更を削除してください。 代わりに、あなた、ldapmodifyする、あなたが#、が以下を削除するのに慎重であるなら、aを、誤りの#、を続けて、次に、ただそのスイッチを使用するために切り換えさせます。 attributetypes attributetypes: (0.0.8.350.1.1.6.1.1名の'SIPIdentitySIPURI') attributetypes: (0.0.8.350.1.1.6.1.2名前'SIPIdentityRegistrarAddress') attributetypes: (0.0.8.350.1.1.6.1.3名前'SIPIdentityProxyAddress') attributetypes: (0.0.8.350.1.1.6.1.4名前'SIPIdentityAddress') attributetypes: (0.0.8.350.1.1.6.1.5名の'SIPIdentityPassword') attributetypes: (0.0.8.350.1.1.6.1.6名の'SIPIdentityUserName') attributetypes: (0.0.8.350.1.1.6.1.7名の'SIPIdentityServiceLevel') - # # 属性を再加えてください--##定義の変化があるといけないので、加えてください: attributetypes attributetypes: (0.0.8.350.1.1.6.1.1名前'SIPIdentitySIPURI'DESC'一口Uaの普遍的なリソースインディケータ'平等caseExactMatch SUBSTR caseExactSubstringsMatch構文1.3.6.1.4、.1、.1466、.115、.121、.1、.15)
Johnson, et al. Informational [Page 24] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[24ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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: (.2NAME'SIPIdentityRegistrarAddress'DESCが'記録係の位置を指定する'という0.0.8.350.1.1.6.1EQUALITY caseIgnoreIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26) attributetypes: (.3NAME'SIPIdentityProxyAddress'DESCが'SIP Proxyの位置を指定する'という0.0.8.350.1.1.6.1EQUALITY caseIgnoreIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26) attributetypes: (0.0.8.350.1.1.6.1.4NAME'SIPIdentityAddress'DESC'UaのIPアドレス'EQUALITY caseIgnoreIA5Match SYNTAX1.3.6.1.4.1、.1466、.115、.121、.1、.26) attributetypes: (0.0.8.350.1.1.6.1.5NAME'SIPIdentityPassword''ユーザエージェントSIPパスワード'EQUALITY octetStringMatch SYNTAX1.3.6.1.4のDESC.1.1466.115、.121、.1、.40) attributetypes: (0.0.8.350.1.1.6. 1.3という.1.6NAME'SIPIdentityUserName'DESC'ユーザエージェントユーザ名'EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX.6、.1、.4、.1、.1466、.115、.121、.1、.15) attributetypes: (0.0.8.350.1.1.6.1.7NAME'SIPIdentityServiceLevel'DESC. EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX1.3に'ユーザが属すことができるサービスを定義するために'.6.1.4、.1、.1466、.115、.121、.1、.26) - # 次のオブジェクトが分類するオブジェクトClass Definitions##はこのRecommendationで定義されます: # # SIPIdentity##SIPIdentity##、は以下を削除します。 objectclasses objectclasses: (0.0.8.350.1.1.6.2.1名の'SIPIdentity') - 加えます: objectclasses objectclasses: (0.0.8.350.1.1.6.2.1名の'SIPIdentity'
Johnson, et al. Informational [Page 25] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[25ページ]の3944時間.350のRFCディレクトリサービス2004年12月
DESC 'SIPIdentity object'
SUP top AUXILIARY
MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $
SIPIdentityProxyAddress $ SIPIdentityAddress $
SIPIdentityPassword $ SIPIdentityUserName $
SIPIdentityServiceLevel $ userSMIMECertificate )
)
-
#
# end of LDIF
#
DESC'SIPIdentityオブジェクト'SUPはAUXILIARY MAY(SIPIdentitySIPURI$SIPIdentityRegistrarAddress$SIPIdentityProxyAddress$SIPIdentityAddress$SIPIdentityPassword$SIPIdentityUserName$SIPIdentityServiceLevel$userSMIMECertificate)を上回っています。 - # # LDIF#の端
5.4. H.350.4 Annex A Indexing profile
5.4. H.350.4別館A Indexingプロフィール
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.
属性のインデックスは、実装比活性であり、必要なアプリケーションによります。 非索引をつけられた属性はいくつかのアプリケーションを使用不可能に表すことができるくらい長い検索時間をもたらすことができます。 ユーザと別名ルックアップは著しく、速いはずです。 Annex A Indexing Profileはディレクトリアプリケーションのディレクトリにおける使用のために最適化される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: 平等
6. Acknowledgments
6. 承認
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の両方からの規格から手広く引き出されました、そして、アーキテクチャはすべての共同体に役立つことになっています。
Johnson, et al. Informational [Page 26] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[26ページ]の3944時間.350のRFCディレクトリサービス2004年12月
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.
この仕事はVideo Conferencing Middleware(VidMid-VC)ワーキンググループ、Internet2の共同努力(www.internet2.edu)、およびVideo Development Initiative(www.vide.net)から展開しました。 アーキテクチャは研究ネットワークの向こう側に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から交付金で一部後押しされていました。
7. Security Considerations
7. セキュリティ問題
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 Group16のコンセンサスがあります。
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属性はRFC2798(セクション2.8)でinetOrgPersonの一部と定義されます。 この属性でSIPユーザエージェントのX.509証明書を保存できます。 証明書が存在しているとき、RFC3261[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属性にアクセスコントロールをけしかけるとき、システム管理者が常識を使用するようにアドバイスされます。 例えば、パスワード属性は単に認証されたユーザがアクセスしやすいはずですが、アドレス属性は公的に利用可能であるかもしれません。
Johnson, et al. Informational [Page 27] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[27ページ]の3944時間.350のRFCディレクトリサービス2004年12月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[1] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。
[2] ITU-T Recommendation H.350, "Directory services architecture for
multimedia conferencing", 2003.
[2] ITU-T Recommendation H.350、「マルチメディア会議のためのディレクトリ・サービス・アーキテクチャ」、2003。
[3] ITU-T Recommendation H.350.4, "Directory services architecture
for SIP", 2003.
[3] ITU-T Recommendation 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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
RFC 2798, April 2000.
[7] スミス、M.、「inetOrgPerson LDAPオブジェクトのクラスの定義」、RFC2798、2000年4月。
8.2. Informative References
8.2. 有益な参照
[8] ITU-T Recommendation H.350.1, "Directory services architecture
for H.323", 2003.
[8] ITU-T Recommendation H.350.1、「H.323のためのディレクトリ・サービス・アーキテクチャ」、2003。
[9] ITU-T Recommendation H.350.2, "Directory services architecture
for H.235", 2003.
[9] ITU-T Recommendation H.350.2、「H.235のためのディレクトリ・サービス・アーキテクチャ」、2003。
[10] ITU-T Recommendation H.350.3, "Directory services architecture
for H.320", 2003.
[10] ITU-T Recommendation H.350.3、「H.320のためのディレクトリ・サービス・アーキテクチャ」、2003。
[11] ITU-T Recommendation H.350.5, "Directory services architecture
for Non-Standard Protocols", 2003.
[11] ITU-T Recommendation H.350.5、「Non標準のプロトコルのためのディレクトリ・サービス・アーキテクチャ」、2003。
[12] ITU-T Recommendation H.350.6, "Directory services architecture
for Call Forwarding and Preferences", 2004.
[12] ITU-T Recommendation H.350.6、「Call ForwardingとPreferencesのためのディレクトリ・サービス・アーキテクチャ」、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.
Johnson, et al. Informational [Page 28] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[28ページ]の3944時間.350のRFCディレクトリサービス2004年12月
[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: 1578700000, 1997.
9. Relationship to Other Specifications
9. 他の仕様との関係
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)自体の中の原文の変化のないITU-T刊行物[4]の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]は推薦図書です。
10. Authors' Addresses
10. 作者のアドレス
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
Q.4/16のITU-T SG16早稲田大学YRP Ichibankan、3-4Hikarinooka横須賀市、239-0847日本の栄のオークボ報告担当者
Phone: +81 46 847 5406 EMail: sokubo@waseda.jp
以下に電話をしてください。 +81 46 847 5406はメールされます: sokubo@waseda.jp
Simao Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Place des Nations Geneva CH1211 - Switzerland
シモン・Ferraz deカンポスネト参事官、ITU-T SG16国際電気通信連合Place des NationsジュネーブCH1211--スイス
Phone: +41-22-730-6805 EMail: simao.campos@itu.int
以下に電話をしてください。 +41-22-730-6805 メールしてください: simao.campos@itu.int
Johnson, et al. Informational [Page 29] RFC 3944 H.350 Directory Services December 2004
ジョンソン、他 情報[29ページ]の3944時間.350のRFCディレクトリサービス2004年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78と、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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Johnson, et al. Informational [Page 30]
ジョンソン、他 情報[30ページ]
一覧
スポンサーリンク
