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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Poderosa5で「インデックスが配列の境界外です。」と出る場合の対処法(CentOS8 Ubuntu)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る