[要約] RFC 2377は、インターネットディレクトリ対応アプリケーションの命名計画に関するものであり、その目的は、一貫性のある命名規則を提供し、ディレクトリサービスの効果的な運用を支援することです。
Network Working Group A. Grimstad
Request for Comments: 2377 R. Huber
Category: Informational AT&T
S. Sataluri
Lucent Technologies
M. Wahl
Critical Angle Inc.
September 1998
Naming Plan for Internet Directory-Enabled Applications
インターネットディレクトリ対応アプリケーションの命名計画
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach.
従来のX.500アプローチのネーミングへの適用は、これまで著者の経験では、ディレクトリ対応アプリケーションのインターネット上での幅広い展開に対する障害であることが証明されています。階層型ディレクトリ内のオブジェクトに名前を付けるために、最も人気があり成功しているインターネットの名前付けスキームの長所を活用する新しいディレクトリ名前付け計画を提案します。この計画は、X.500アプローチをネーミングに拡張することにより、従来のX.500アプローチを使用するユーザーが直面する問題を克服することにより、インターネットホワイトページサービス（IWPS）およびその他のディレクトリ対応アプリケーションの作成を容易にすることができると信じています。
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. The required registration infrastructure is either non-existent or largely ignored. The infrastructure that does exist is cumbersome to use and tends to produce counterproductive results. The attributes used for naming have been confusing for users and inflexible to managers and operators of directory servers.
従来のX.500アプローチのネーミングへの適用は、これまで著者の経験では、ディレクトリ対応アプリケーションのインターネット上での幅広い展開に対する障害であることが証明されています。必要な登録インフラストラクチャが存在しないか、ほとんど無視されています。存在するインフラストラクチャは使いにくく、逆効果の結果を生む傾向があります。ネーミングに使用される属性は、ユーザーを混乱させ、ディレクトリサーバーの管理者やオペレーターには柔軟性がありません。
This paper describes a directory naming plan for the construction of an Internet directory infrastructure to support directory-enabled applications that can serve as an alternative (or extension) to the conventional X.500 approach.
このペーパーでは、従来のX.500アプローチの代替（または拡張）として機能するディレクトリ対応アプリケーションをサポートするインターネットディレクトリインフラストラクチャを構築するためのディレクトリ命名計画について説明します。
The plan has the following two main features. First, it bases the root and upper portions of the name hierarchy on the existing infrastructure of names from the Domain Name System (DNS). This component of the plan makes use of the ideas described in the companion paper to this plan, "Using Domains in LDAP Distinguished Names" [1]. And second, it provides a number of options for the assignment of names to directory leaf objects such as person objects, including an option that allows the reuse of existing Internet identifiers for people.
この計画には、次の2つの主要な機能があります。 1つ目は、ドメインネームシステム（DNS）からの名前の既存のインフラストラクチャに基づいて、名前階層のルートと上部を構成します。計画のこのコンポーネントは、この計画の関連文書「LDAP識別名でのドメインの使用」[1]で説明されているアイデアを利用します。そして、2つ目は、人物オブジェクトなどのディレクトリリーフオブジェクトに名前を割り当てるための多くのオプションを提供します。これには、既存のインターネット識別子を人物に再利用できるオプションも含まれます。
Just as the conventional X.500 style of naming is not a formal standard, use of the naming plan described here is not obligatory for directory-enabled applications on the Internet. Other approaches are permissible. However, we believe widespread use of this plan will largely eliminate naming as a typically thorny issue when administrators set up an LDAP-based directory service. Further, we strongly encourage developers of directory-enabled products, especially LDAP clients and user interfaces, to assume that this naming plan will see widespread use and design their products accordingly.
従来のX.500スタイルの名前付けが正式な標準ではないのと同様に、ここで説明する名前付け計画の使用は、インターネット上のディレクトリ対応アプリケーションでは必須ではありません。他のアプローチも許容されます。ただし、この計画を広く使用すると、管理者がLDAPベースのディレクトリサービスを設定する際の、一般的に厄介な問題としてのネーミングが大幅に解消されると考えています。さらに、ディレクトリ対応製品、特にLDAPクライアントとユーザーインターフェースの開発者は、この命名計画が広範囲に使用され、それに応じて製品を設計すると想定することを強くお勧めします。
Here, in summary, is our proposal.
ここに要約すると、私たちの提案です。
The upper portions of the hierarchical directory tree should be constructed using the components of registered DNS names using the domain component attribute "dc". The directory name for the organization having the domain name "acme.com" will then be, e.g.,
階層ディレクトリツリーの上部は、ドメインコンポーネント属性「dc」を使用して登録済みDNS名のコンポーネントを使用して構築する必要があります。ドメイン名が「acme.com」の組織のディレクトリ名は、たとえば次のようになります。
dc=acme, dc=com
dc = acme、dc = com
Organizations can add additional directory structure, for example to support implementation of access control lists or partitioning of their directory information, by using registered subdomains of DNS names, e.g., the subdomain "corporate.acme.com" can be used as the basis for the directory name
組織は、追加のディレクトリ構造を追加できます。たとえば、DNS名の登録済みサブドメインを使用して、アクセス制御リストの実装やディレクトリ情報の分割をサポートできます。たとえば、サブドメイン「corporate.acme.com」をディレクトリ名
dc=corporate, dc=acme, dc=com
For naming directory leaf objects such as persons, groups, server applications and certification authorities in a hierarchical directory, we propose the use of either the "uid" (user identifier) or the "cn" (common name) attribute for the relative distinguished name. This plan does not constrain how these two attributes are used.
階層ディレクトリ内の個人、グループ、サーバーアプリケーション、証明機関などのディレクトリリーフオブジェクトに名前を付ける場合、相対識別名に「uid」（ユーザー識別子）または「cn」（共通名）属性の使用を提案します。この計画は、これら2つの属性の使用方法を制限しません。
One approach to their use, for example, is to employ the uid attribute as the RDN when reusing an existing store of identifiers and the cn attribute as the RDN when creating new identifiers specifically for the directory. A convenient existing identification scheme for person objects is the RFC822 mailbox identifier. So an RDN for person employing this store of identifiers would be, e.g.,
たとえば、それらの使用方法の1つは、識別子の既存のストアを再利用する場合はuid属性をRDNとして使用し、ディレクトリ専用の新しい識別子を作成する場合はcn属性をRDNとして使用することです。人物オブジェクトの便利な既存の識別スキームは、RFC822メールボックス識別子です。したがって、この識別子のストアを使用する人のRDNは、たとえば、次のようになります。
uid=John.Smith@acme.com
ういｄ＝じょｈん。Ｓみｔｈ＠あｃめ。こｍ
For leaf objects not conveniently identified with such a scheme, the "cn" attribute is used, e.g.,
そのようなスキームで都合よく識別されないリーフオブジェクトの場合、「cn」属性が使用されます。たとえば、
cn=Reading Room
cn =閲覧室
Directory distinguished names will thus have the following structure, e.g.,
したがって、ディレクトリ識別名は次のような構造になります。
uid=John.Smith@acme.com, dc=acme, dc=com
uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
cn=Reading Room, dc=physics, dc=national-lab, dc=edu
The X.500 Directory model [2] can be used to create a world-wide distributed directory. The Internet X.500 Directory Pilot has been operational for several years and has grown to a size of about 1.5 million entries of varying quality. The rate of growth of the pilot is far lower than the rate of growth of the Internet during the pilot period.
X.500ディレクトリモデル[2]を使用して、世界規模の分散ディレクトリを作成できます。 Internet X.500 Directory Pilotは数年間運用されており、さまざまな品質の約150万エントリのサイズに成長しています。パイロットの成長率は、パイロット期間中のインターネットの成長率よりもはるかに低くなっています。
There are a substantial number of contributing factors that have inhibited the growth of this pilot. The common X.500 approach to naming, while not the preponderant problem, has contributed in several ways to limit the growth of an Internet White Pages Service based on X.500.
このパイロットの成長を阻害している要因はかなりあります。一般的なX.500の命名方法は、圧倒的な問題ではありませんが、X.500に基づくインターネットホワイトページサービスの成長を制限するいくつかの方法で貢献しています。
The conventional way to construct names in the X.500 community is documented as an informative (i.e., not officially standardized) Annex B to X.521. The relative distinguished name (RDN) of a user consists of a common name (cn) attribute. This is meant to be what -- in the user's particular society -- is customarily understood to be the name of that user. The distinguished name of a user is the combination of the name of some general object, such as an organization or a geographical unit, with the common name. There are two main problems with this style of name construction.
X.500コミュニティで名前を作成する従来の方法は、X.521の参考資料（公式には標準化されていない）の付属文書Bとして文書化されています。ユーザーの相対識別名（RDN）は、共通名（cn）属性で構成されます。これは、ユーザーの特定の社会において、そのユーザーの名前であると慣習的に理解されていることを意味します。ユーザーの識別名は、組織や地理単位などの一般的なオブジェクトの名前と一般名の組み合わせです。この名前の構成スタイルには2つの主な問題があります。
First, the common name attribute, while seeming to be user-friendly, cannot be used generally as an RDN in practice. In any significant set of users to be named under the same Directory Information Tree (DIT) node there will be collisions on common name. There is no way to overcome this other than either by forcing uniqueness on common names, something they do not possess, or by using an additional attribute to prevent collisions. This additional attribute normally needs to be unique in a much larger context to have any practical value. The end result is a RDN that is very long and unpopular with users.
まず、共通名属性はユーザーフレンドリーであるように見えますが、実際には一般的にRDNとして使用できません。同じディレクトリ情報ツリー（DIT）ノードの下で名前が付けられる重要なユーザーのセットでは、共通名で競合が発生します。これを克服する方法は、一般的な名前（所有していないもの）を一意にするか、追加の属性を使用して衝突を防ぐことです。この追加の属性は、通常、実際的な値を持つために、はるかに大きなコンテキストで一意である必要があります。その結果、RDNが非常に長くなり、ユーザーに人気がなくなります。
Second, and more serious, X.500 has not been able to use any significant number of pre-existing names. Since X.500 naming models typically use organization names as part of the hierarchy [2, 3], organization names must be registered. As organization names are frequently tied to trademarks and are used in sales and promotions, registration can be a difficult and acrimonious process.
第2に、より深刻なことに、X.500は既存の名前を多数使用することができませんでした。 X.500ネーミングモデルは通常、組織名を階層の一部として使用するため[2、3]、組織名を登録する必要があります。組織名は商標に関連付けられることが多く、販売やプロモーションで使用されるため、登録は困難で面倒なプロセスになる可能性があります。
The North American Directory Forum (NADF, now the North Atlantic Directory Forum but still the NADF) proposed to avoid the problem of registration by using names that were already registered in the "civil naming infrastructure" [4][5]. Directory distinguished names would be based on an organization's legal name as recognized by some governmental agency (county clerk, state secretary of state, etc.) or other registering entity such as ANSI.
北米ディレクトリフォーラム（NADF、現在は北大西洋ディレクトリフォーラム、ただしNADF）は、「市民命名インフラストラクチャ」にすでに登録されている名前を使用して登録の問題を回避することを提案しました[4] [5]。ディレクトリ識別名は、いくつかの政府機関（郡書記官、州務長官など）またはANSIなどの他の登録エンティティによって認識される組織の正式名に基づいています。
This scheme has the significant advantage of keeping directory service providers out of disputes about the right to use a particular name, but it leads to rather obscure names. Among these obscurities, the legal name almost invariably takes a form that is less familiar and longer than what users typically associate with the organization. For example, in the US a large proportion of legal organization names end with the text ", Inc." as in "Acme, Inc." Moreover, in the case of the US, the civil naming infrastructure does not operate nationally, so the organization names it provides must be located under state and regional DIT nodes, making them difficult to find while browsing the directory. NADF proposes a way to algorithmically derive multi-attribute RDNs which would allow placement of entries or aliases in more convenient places in the DIT, but these derived names are cumbersome and unpopular. For example, suppose Nadir is an organization that is registered in New Jersey civil naming infrastructure under the name "Nadir Networks, Inc." Its civil distinguished name (DN) would then be
このスキームには、特定の名前を使用する権利について紛争からディレクトリサービスプロバイダーを保護するという大きな利点がありますが、かなりあいまいな名前につながります。これらのあいまいさの中で、法的な名前は、ほとんどの場合、ユーザーが組織に通常関連付けるものよりも馴染みがなく長い形式になります。たとえば、米国では、法的な組織名の大部分が「、Inc.」というテキストで終わります。 「Acme、Inc.」のようにさらに、米国の場合、Civilネーミングインフラストラクチャは全国的に運用されていないため、提供する組織名は州および地域のDITノードの下にある必要があり、ディレクトリを参照しているときに見つけにくくなっています。 NADFは、DITのより便利な場所にエントリまたはエイリアスを配置できるようにするマルチ属性RDNをアルゴリズムによって導出する方法を提案しますが、これらの派生名は扱いにくく、人気がありません。たとえば、Nadirが「Nadir Networks、Inc.」という名前でニュージャージーの市民ネーミングインフラストラクチャに登録されている組織であるとします。その市民識別名（DN）は
o="Nadir Networks, Inc.", st=New Jersey, c=US
while its derived name which is unambiguous under c=US directly is
一方、c = USのもとでは明白な派生名は
o="Nadir Networks, Inc." + st=New Jersey, c=US
More generally, the requirement for registration of organizations in X.500 naming has led to the establishment of national registration authorities whose function is mainly limited to assignment of X.500 organization names. Because of the very limited attraction of X.500, interest in registering an organization with one of these national authorities has been minimal. Finally, multi-national organizations are frustrated by a lack of an international registration authority.
より一般的には、X.500ネーミングでの組織の登録の要件により、主にX.500組織名の割り当てに機能が制限される国内登録機関が設立されました。 X.500の魅力は非常に限られているため、これらの国家当局の1つに組織を登録することへの関心はごくわずかです。最後に、多国籍組織は国際的な登録機関の欠如に苛立っています。
A directory naming plan must provide a guide for the construction of names (identifiers, labels) for directory objects that are unambiguous (identify only one directory object) within some context (namespace), at a minimum within one isolated directory server.
ディレクトリ命名計画は、少なくとも1つの隔離されたディレクトリサーバー内で、特定のコンテキスト（ネームスペース）内で明確な（1つのディレクトリオブジェクトのみを識別する）ディレクトリオブジェクトの名前（識別子、ラベル）を構築するためのガイドを提供する必要があります。
A directory object is simply a set of attribute values. The association between a real-world object and a directory object is made by directory-enabled applications and is, in the general case, one to many.
ディレクトリオブジェクトは、単に属性値のセットです。実世界のオブジェクトとディレクトリオブジェクトの関連付けは、ディレクトリ対応のアプリケーションによって行われ、一般的には1対多です。
The following additional naming characteristics are requirements that this naming plan seeks to satisfy:
以下の追加の命名特性は、この命名計画が満たそうとしている要件です。
a) hierarchical
a) 階層的
The Internet, consisting of a very large number of objects and management domains, requires hierarchical names. Such names permit delegation in the name assignment process and partitioning of directory information among directory servers.
非常に多数のオブジェクトと管理ドメインで構成されるインターネットには、階層名が必要です。このような名前により、名前割り当てプロセスでの委任と、ディレクトリサーバー間でのディレクトリ情報の分割が可能になります。
b) friendly to loose coupling of directory servers
b) ディレクトリサーバーの疎結合に対応
One purpose of this naming plan is to define a naming pattern that will facilitate one form or another of loose coupling of potentially autonomous directory servers into a larger system.
この命名計画の目的の1つは、自律型のディレクトリサーバーを大規模なシステムに疎結合する何らかの形式を容易にする命名パターンを定義することです。
A name in such a loosely-coupled system should unambiguously identify one real-world object. The real-world object may, however, be represented differently (i.e. by different directory objects having different attributes but the same DN) in different (e.g. independently managed) servers in the loosely-coupled system. The plan does not attempt to produce names to overcome this likely scenario. That is, it does not attempt to produce a single namespace for all directory objects. (This issue is considered in more detail in Section 5.1.)
このような疎結合システムでの名前は、1つの実世界のオブジェクトを明確に識別する必要があります。ただし、実世界のオブジェクトは、疎結合システムの異なる（たとえば、独立して管理される）サーバーでは異なる（つまり、属性は異なるがDNが同じである異なるディレクトリオブジェクトによって）異なって表される場合があります。この計画は、この可能性のあるシナリオを克服するために名前を生成しようとするものではありません。つまり、すべてのディレクトリオブジェクトに対して単一の名前空間を作成することはありません。 （この問題については、セクション5.1で詳しく説明します。）
c) readily usable by LDAP clients and servers
c) LDAPクライアントおよびサーバーですぐに使用可能
As of this writing, a substantial number of the Lightweight Directory Access Protocol (LDAP) [6][7] implementations are currently available or soon will be. The names specified by this naming plan should be readily usable by these implementations and applications based on them.
これを書いている時点で、相当数のライトウェイトディレクトリアクセスプロトコル（LDAP）[6] [7]実装が現在利用可能であるか、間もなく利用可能になります。この命名計画で指定された名前は、これらの実装とそれらに基づくアプリケーションですぐに使用できるはずです。
d) friendly to re-use of existing Internet name registries
d) 既存のインターネットネームレジストリを再利用しやすい
As described in Section 2 above, creation of new global name registries has been highly problematic. Therefore, a fundamental requirement this plan addresses is to enable the reuse of existing Internet name registries such as DNS names and RFC822 mailbox identifiers when constructing directory names.
上記のセクション2で説明したように、新しいグローバル名レジストリの作成には非常に問題があります。したがって、この計画が取り組む基本的な要件は、ディレクトリ名を構築するときに、DNS名やRFC822メールボックス識別子などの既存のインターネット名レジストリを再利用できるようにすることです。
e) minimally user-friendly
e) 最小限のユーザーフレンドリー
Although we expect that user interfaces of directory-enabled applications will avoid exposing users to DNs, it is unlikely that users can be totally insulated from them. For this reason, the naming plan should permit use of familiar information in name construction. Minimally, a user should be capable of recognizing the information encoded in his/her own DN. Names that are totally opaque to users cannot meet this requirement.
ディレクトリ対応アプリケーションのユーザーインターフェイスでは、ユーザーがDNにさらされるのを回避できると考えられますが、ユーザーがDNから完全に隔離される可能性はほとんどありません。このため、ネーミングプランでは、名前の作成に使い慣れた情報を使用できるようにする必要があります。最低限、ユーザーは自分のDNにエンコードされた情報を認識できる必要があります。ユーザーに対して完全に不透明な名前は、この要件を満たすことができません。
The paper assumes familiarity with the terminology and concepts behind the terms distinguished name (DN) and relative distinguished name (RDN) [2][8][9].
このペーパーは、識別名（DN）および相対識別名（RDN）という用語の背後にある用語と概念に精通していることを前提としています[2] [8] [9]。
We describe how DNs can be constructed using three attribute types, domainComponent (dc), userID (uid) and commonName (cn). They are each described in turn.
DNを、domainComponent（dc）、userID（uid）、commonName（cn）の3つの属性タイプを使用して構築する方法について説明します。それぞれ順番に説明します。
The domain component attribute is defined and registered in RFC1274 [3][10]. It is used in the construction of a DN from a domain name. Details of the construction algorithm is described in "Using Domains in LDAP Distinguished Names" [1].
ドメインコンポーネント属性は、RFC1274 [3] [10]で定義および登録されています。ドメイン名からのDNの構築に使用されます。構築アルゴリズムの詳細は、「LDAP識別名でのドメインの使用」[1]で説明されています。
An organization wishing to deploy a directory following this naming plan would proceed as follows. Consider an organization, for example "Acme, Inc.", having the registered domain name "acme.com". It would construct the DN
この命名計画に従ってディレクトリを展開したい組織は、次のように進めます。登録されたドメイン名「acme.com」を持つ組織、たとえば「Acme、Inc.」を考えてみます。 DNを構築します
dc=acme, dc=com
dc = acme、dc = com
from its domain name. It would then use this DN as the root of its subtree of directory information.
そのドメイン名から。次に、このDNをディレクトリ情報のサブツリーのルートとして使用します。
The DN itself can be used to identify a directory organization object that represents information about the organization. The directory schema required to enable this is described below in section 5.2.
DN自体を使用して、組織に関する情報を表すディレクトリ組織オブジェクトを識別できます。これを有効にするために必要なディレクトリスキーマについては、セクション5.2で説明します。
The subordinates of the DN will be directory objects related to the organization. The domain component attribute can be used to name subdivisions of the organization such as organizational units and localities. Acme, for example, might use the domain names "corporate.acme.com" and "richmond.acme.com" to construct the names
DNの下位は、組織に関連するディレクトリオブジェクトになります。ドメインコンポーネント属性を使用して、組織単位や地域など、組織の下位区分に名前を付けることができます。たとえば、Acmeは、ドメイン名「corporate.acme.com」と「richmond.acme.com」を使用して名前を作成します。
dc=corporate, dc=acme, dc=com
dc=richmond, dc=acme, dc=com
under which to place its directory objects. The directory schema required to name organizationalUnit and locality objects in this way is described below in section 5.2.
その下にディレクトリオブジェクトを配置します。この方法でorganizationalUnitおよびlocalityオブジェクトに名前を付けるために必要なディレクトリスキーマについては、セクション5.2で説明します。
Note that subdivisions of the organization such as organizational units and localities could also be assigned RDNs using the conventional X.500 naming attributes, e.g.
組織単位や地域などの組織の下位区分には、従来のX.500命名属性を使用してRDNを割り当てることもできます。
ou=corporate, dc=acme, dc=com l=richmond, dc=acme, dc=com.
ou =企業、dc = acme、dc = com l =リッチモンド、dc = acme、dc = com。
Use of the dc attribute for the RDN of directory objects of class "domain" is also possible [1].
「ドメイン」クラスのディレクトリオブジェクトのRDNにdc属性を使用することも可能です[1]。
The userid (uid) attribute is defined and registered in RFC1274 [3][10].
userid（uid）属性は、RFC1274 [3] [10]で定義および登録されています。
This attribute may be used to construct the RDN for directory objects subordinate to objects named according to the procedure described in Section 4.1. This plan does not constrain how this attribute is used.
この属性を使用して、セクション4.1で説明されている手順に従って名前が付けられたオブジェクトに従属するディレクトリオブジェクトのRDNを構築できます。このプランは、この属性の使用方法を制限しません。
The commonName (cn) attribute is defined and registered in X.500 [3][11].
commonName（cn）属性は、X.500 [3] [11]で定義および登録されています。
This attribute may be used to construct the RDN for directory objects subordinate to objects named according to the procedure described in Section 4.1. This plan does not constrain how this attribute is used.
この属性を使用して、セクション4.1で説明されている手順に従って名前が付けられたオブジェクトに従属するディレクトリオブジェクトのRDNを構築できます。このプランは、この属性の使用方法を制限しません。
Although this plan places no constraints on the use of the uid and cn attributes for name construction, we would like to offer some suggestions by way of examples.
この計画では、名前の構築にuid属性とcn属性の使用に制約を課していませんが、例としていくつかの提案を提供します。
In practice, we have used uid for the RDN for person objects were we could make use of an existing registry of names and cn for other objects.
実際には、personオブジェクトのRDNにuidを使用しましたが、他のオブジェクトには名前とcnの既存のレジストリを利用できました。
Examples of existing registries of identifiers for person objects are RFC822 mailbox identifiers, employee numbers and employee "handles". Aside from the convenience to administrators of re-use of an existing store of identifiers, if it is ever necessary to display to a user his/her DN, there is some hope that it will be recognizable when such identifiers are used.
人物オブジェクトの識別子の既存のレジストリの例は、RFC822メールボックス識別子、従業員番号、および従業員の「ハンドル」です。既存の識別子のストアを再利用することの管理者にとっての利便性に加えて、ユーザーに自分のDNを表示する必要がある場合、そのような識別子が使用されたときにそれが認識できることが期待されます。
We have found RFC822 mailbox identifiers a particularly convenient source for name construction. When a person has several e-mail addresses, one will be selected for the purpose of user identification. We call this the "distinguished" e-mail address or the "distinguished" RFC822 mailbox identifier for the user.
RFC822メールボックス識別子は、名前の構築に特に便利なソースであることがわかりました。個人が複数の電子メールアドレスを持っている場合、ユーザーを識別するために1つが選択されます。これを「識別された」電子メールアドレスまたはユーザーの「識別された」RFC822メールボックス識別子と呼びます。
For example, if there is a user affiliated with the organization Acme having distinguished e-mail address J.Smith@acme.com, the uid attribute will be:
たとえば、識別された電子メールアドレスJ.Smith@acme.comを持つ組織Acmeに関連するユーザーがいる場合、uid属性は次のようになります。
uid=J.Smith@acme.com
ういｄ＝Ｊ。Ｓみｔｈ＠あｃめ。こｍ
The domain component attributes of a user's DN will normally be constructed from the domain name of his/her distinguished e-mail address. That is, for the user uid=J.Smith@acme.com the domain component attributes would typically be:
ユーザーのDNのドメインコンポーネント属性は、通常、ユーザーの識別された電子メールアドレスのドメイン名から作成されます。つまり、ユーザーuid=J.Smith@acme.comの場合、ドメインコンポーネント属性は通常次のようになります。
dc=acme, dc=com
dc = acme、dc = com
The full LDAP DN for this user would then be:
このユーザーの完全なLDAP DNは次のようになります。
uid=J.Smith@acme.com, dc=acme, dc=com
Directory administrators having several RFC822 identifiers to choose from when constructing a DN for a user should consider the following factors:
ユーザーのDNを作成するときに選択するいくつかのRFC822識別子を持つディレクトリ管理者は、次の要素を考慮する必要があります。
o Machine-independent addresses are likely to be more stable, resulting in directory names that change less. Thus an identifier such as:
o マシンに依存しないアドレスはより安定している可能性が高く、その結果、ディレクトリ名の変更が少なくなります。したがって、次のような識別子：
js@acme.com
ｊｓ＠あｃめ。こｍ
may well be preferable to one such as:
次のようなものよりも好ましいかもしれません：
js@blaster.third-floor.acme.com.
ｊｓ＠ｂぁｓてｒ。てぃｒｄーｆぉおｒ。あｃめ。こｍ。
o Use of some form of "handle" for the "local" part that is distinct from a user's real name may result in fewer collisions and thereby lessen user pain and suffering. Thus the identifier:
o ユーザーの本名とは異なる「ローカル」部分に何らかの形式の「ハンドル」を使用すると、衝突が少なくなり、ユーザーの苦痛が軽減されます。したがって、識別子：
js@acme.com
ｊｓ＠あｃめ。こｍ
may well be preferable to one such as:
次のようなものよりも好ましいかもしれません：
J.Smith@acme.com
Ｊ。Ｓみｔｈ＠あｃめ。こｍ
Practical experience with use of the RFC822 mailbox identifier scheme described here has shown that there are situations where it is convenient to use such identifies for all users in a particular population, although a few users do not, in fact, possess working mailboxes. For example, an organization may have a existing unique identification scheme for all employees that is used as a alias to the employees' real mailboxes -- which may be quite heterogeneous in structure. The identification scheme works for all employees to identify unambiguously each employee; it only works as an e-mail alias for those employees having real mailboxes. For this reason it would be a bad assumption for directory-enabled applications to assume the uid to be a valid mailbox; the value(s) of the mail attribute should always be checked.
ここで説明するRFC822メールボックス識別子スキームの使用に関する実際の経験では、特定の母集団のすべてのユーザーに対してそのような識別情報を使用するのが便利な状況があることが示されています。たとえば、組織には、従業員の実際のメールボックスへのエイリアスとして使用されるすべての従業員用の既存の一意の識別スキームがある場合があります。識別スキームは、すべての従業員が各従業員を明確に識別するために機能します。実際のメールボックスを持つ従業員の電子メールエイリアスとしてのみ機能します。このため、ディレクトリ対応アプリケーションがuidを有効なメールボックスであると想定することは、不適切な想定です。 mail属性の値は常にチェックする必要があります。
It is important to emphasize that the elements of the domain name of an RFC822 identifier may, BUT NEED NOT, be the same as the domain components of the DN. This means that the domain components provide a degree of freedom to support access control or other directory structuring requirements that need not be mechanically reflected in the user's e-mail address. We do not want under any condition to force the user's e-mail address to change just to facilitate a new system requirement such as a modification in an access control structure. It should also be noted that while we do not require that the domain components match the RFC822 identifier, we DO require that the concatenated domain components form a registered domain name, that is, one that is represented in the DNS. This automatically avoids name conflicts in the directory hierarchy.
RFC822識別子のドメイン名の要素は、DNのドメインコンポーネントと同じであっても、必ずしも必要ではないことを強調することが重要です。つまり、ドメインコンポーネントは、ユーザーの電子メールアドレスに機械的に反映する必要のないアクセス制御やその他のディレクトリ構造化の要件をサポートするための自由度を提供します。アクセス制御構造の変更などの新しいシステム要件を容易にするために、いかなる状況でもユーザーの電子メールアドレスを強制的に変更することは望ましくありません。また、ドメインコンポーネントがRFC822識別子と一致する必要はありませんが、連結されたドメインコンポーネントが登録済みドメイン名、つまりDNSで表されるものを形成している必要があることにも注意してください。これにより、ディレクトリ階層での名前の競合が自動的に回避されます。
To provide an example of a DN which deviates from what might be considered the default structure, consider the following scenario.
デフォルトの構造と見なされるものから逸脱しているDNの例を提供するには、次のシナリオを検討してください。
Suppose that J.Smith needs to be granted special permissions to information in the dc=acme, dc=com part of the LDAP DIT. Since it will be, in general, easier to organize special users by their name structure than via groups (an arbitrary collection of DNs), we use subdomains for this purpose. Suppose the special permissions were required by users in the MIS organizational unit. A subdomain "mis.acme.com" is established, if it does not already exist, according to normal DNS procedures. The special permissions will be granted to users with the name structure:
J.Smithに、LDAP DITのdc = acme、dc = comの部分にある情報への特別なアクセス許可を付与する必要があるとします。一般に、グループ（DNの任意のコレクション）を使用するよりも名前の構造によって特別なユーザーを整理する方が簡単なので、この目的のためにサブドメインを使用します。 MIS組織単位のユーザーが特別な権限を要求したとします。通常のDNS手順に従って、サブドメイン「mis.acme.com」がまだ存在しない場合は、確立されます。特別な権限は、名前構造を持つユーザーに付与されます。
uid=*, dc=mis, dc=acme, dc=com
The DN of J.Smith in this case will be:
この場合のJ.SmithのDNは次のようになります。
uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
In principal, there is nothing to prevent the domain name elements of the RFC822 identifier from being completely different from the domain components of the DN. For instance, the DN for a J.Smith could be:
原則として、RFC822識別子のドメイン名要素がDNのドメインコンポーネントと完全に異なることを妨げるものは何もありません。たとえば、J.SmithのDNは次のようになります。
uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
While we do not REQUIRE that the domain name part of the uid match the dc components of the directory distinguished name, we suggest that this be done where possible. At a minimum, if the most significant pieces of the DN and the uid are the same (i.e., "dc=acme, dc=com" and "acme.com") the likelihood, based on a knowledge of a user's e-mail address, of discovering an appropriate directory system to contact to find information about the user is greatly enhanced.
uidのドメイン名部分がディレクトリ識別名のdcコンポーネントと一致する必要はありませんが、可能な場合はこれを行うことをお勧めします。少なくとも、DNとuidの最も重要な部分が同じ（つまり、「dc = acme、dc = com」、および「acme.com」）の場合、ユーザーの電子メールの知識に基づく可能性ユーザーに関する情報を見つけるために連絡する適切なディレクトリシステムを検出するアドレスが大幅に強化されました。
The example above represents a situation where this suggestion isn't possible because some of the users in a population have mailbox identifiers that differ from the pattern of the rest of the users, e.g., most mailboxes are of the form local@acme.com, but a subpopulation have mailboxes from an ISP and therefore mailboxes of the form local@worldnet.att.net.
上記の例は、母集団の一部のユーザーが他のユーザーのパターンとは異なるメールボックス識別子を持っているため、この提案が不可能な状況を表しています。たとえば、ほとんどのメールボックスはlocal@acme.comという形式です。しかし、サブポピュレーションにはISPからのメールボックスがあるため、local @ worldnet.att.netという形式のメールボックスがあります。
We envision the deployment of LDAP-based directory services on the Internet to take the form of loosely coupled LDAP servers. This coupling will occur at two levels.
緩やかに結合されたLDAPサーバーの形をとるために、インターネット上にLDAPベースのディレクトリサービスを配備することを想定しています。この結合は2つのレベルで発生します。
Firstly, LDAP servers will be loosely connected into islands (i.e. a set of servers sharing a single DN namespace). The glue connecting the islands will be LDAP referral [12] information configured into the LDAP servers. An LDAP search directed to any server in such an island can be answered, if the information is not available to that server, by an LDAP referral to another, more appropriate server within the same island.
まず、LDAPサーバーはアイランドに緩やかに接続されます（つまり、単一のDN名前空間を共有する一連のサーバー）。アイランドを接続する接着剤は、LDAPサーバーに構成されたLDAP参照[12]情報です。そのようなアイランド内の任意のサーバーに向けられたLDAP検索は、同じアイランド内の別のより適切なサーバーへのLDAP照会によって、そのサーバーで情報が利用できない場合に応答できます。
Secondly, various techniques will be used span LDAP islands. The concept that enables such techniques is the LDAP URL [13]. By combining a DNS host name and port (corresponding to one or more LDAP servers) with a DN, the LDAP URL provides unified high-level identification scheme (an LDAP URL namespace) for directory objects.
次に、LDAPアイランド全体でさまざまな手法が使用されます。このような手法を可能にする概念は、LDAP URL [13]です。 DNSホスト名とポート（1つ以上のLDAPサーバーに対応）とDNを組み合わせることにより、LDAP URLは、ディレクトリオブジェクトに統一された高レベルの識別スキーム（LDAP URL名前空間）を提供します。
Because an LDAP referral is expressed as one or more LDAP URL, these two levels of coupling may not sharply distinguished in practice.
LDAP参照は1つ以上のLDAP URLとして表現されるため、これら2つのレベルの結合は実際には明確に区別されない場合があります。
We do not envision the X.500 model of a single DIT (i.e. a single DN namespace) to be viable in an environment of competing service providers. This naming plan does not attempt to produce DNs to hide the possibility that a given real-world object may have independently managed directory objects with the same DN associated with it.
単一のDIT（つまり単一のDN名前空間）のX.500モデルが、競合するサービスプロバイダーの環境で実行可能であるとは想定していません。この命名計画では、DNを生成して、特定の実際のオブジェクトに、同じDNが関連付けられた独立して管理されているディレクトリオブジェクトがある可能性を隠そうとしません。
The traditional directory schema(s) developed for the X.500 standard and its application to the Internet [4] require extension to be used with the naming plan developed here. The extensions described below attempt to reuse existing schema elements as much as possible. The directory objects for which extensions are required are: organization, organizational unit, and various classes of leaf objects. We describe the schema modifications below for organization, organizationalUnit and selected leaf classes.
X.500標準用に開発された従来のディレクトリスキーマとそのインターネットへの適用[4]では、ここで開発された命名計画で使用する拡張が必要です。以下で説明する拡張機能は、既存のスキーマ要素を可能な限り再利用しようとします。拡張が必要なディレクトリオブジェクトは、組織、組織単位、およびリーフオブジェクトのさまざまなクラスです。以下に、組織、organizationalUnit、および選択したリーフクラスのスキーマ変更について説明します。
So as to continue to use existing structural object classes to the extent possible, we propose supplementing entries based on these classes with additional information from two new auxiliary object classes, dcObject and uidObject. They are specified using the notation in Section 4 of [14].
既存の構造オブジェクトクラスを可能な限り使用し続けるために、これらのクラスに基づくエントリを、dcObjectとuidObjectの2つの新しい補助オブジェクトクラスからの追加情報で補足することを提案します。それらは[14]のセクション4の表記法を使用して指定されます。
The auxiliary object class dcObject is defined in "Using Domains in LDAP Distinguished Names" [1].
補助オブジェクトクラスdcObjectは、「LDAP識別名でのドメインの使用」[1]で定義されています。
The auxiliary object class uidObject is defined as:
補助オブジェクトクラスuidObjectは次のように定義されます。
( 1.3.6.1.1.3.1 NAME uidObject SUP top AUXILIARY MUST uid )
（1.3.6.1.1.3.1名前uidObject SUP top AUXILIARY MUST uid）
The dc attribute is employed to construct the RDN of an organization object. This is enabled by adding the auxiliary class dcObject to the organization's objectClass attribute.
dc属性は、組織オブジェクトのRDNを構築するために使用されます。これは、組織のobjectClass属性に補助クラスdcObjectを追加することで有効になります。
The dc attribute is employed to construct the RDN of an organizationalUnit object (which is subordinate in the DIT to either an organization or an organizationalUnit object). This is enabled by adding the auxiliary class dcObject to the organizational unit's objectClass attribute.
dc属性は、organizationalUnitオブジェクトのRDNを構築するために使用されます（これは、DITで組織またはorganizationalUnitオブジェクトの下位にあります）。これは、組織単位のobjectClass属性に補助クラスdcObjectを追加することで有効になります。
No schema extensions are required for person objects if either the inetOrgPerson [15] (preferred) or the newPilotPerson object classes are used. The attribute uid is permissible in each class. For consistency, the uidObject could be added to person entry objectClass attributes to assist applications filtering on this object class attribute value. Use of other classes for person objects with RDN constructed with the uid attribute such as organizationalPerson requires the use of the uidObject class.
inetOrgPerson [15]（推奨）またはnewPilotPersonオブジェクトクラスのいずれかが使用されている場合、人物オブジェクトにスキーマ拡張は必要ありません。属性uidは、各クラスで許可されています。一貫性を保つために、uidObjectを人物エントリのobjectClass属性に追加して、アプリケーションがこのオブジェクトクラスの属性値をフィルタリングできるようにすることができます。 organizationalPersonなどのuid属性で構築されたRDNを持つ人物オブジェクトに他のクラスを使用するには、uidObjectクラスを使用する必要があります。
It has been traditional in X.500 and LDAP directory services to employ the common name (cn) attribute in naming. While this naming plan doesn't require use of the cn attribute in naming, it should be stressed that it is a required attribute in any class derived from the person class and is still quite important. It will play a significant role in enabling searches to find user entries of interest.
X.500およびLDAPディレクトリサービスでは、命名に共通名（cn）属性を使用するのが伝統的です。この命名計画では命名にcn属性を使用する必要はありませんが、personクラスから派生したすべてのクラスで必須の属性であり、依然として非常に重要であることを強調しておく必要があります。これは、関心のあるユーザーエントリを検索で検索できるようにする上で重要な役割を果たします。
The certification authority (CA) object class is an auxiliary class, meaning it is essentially a set of additional attributes for a base class such as organizationalRole, organization, organizationalUnit or person. Except in the case where the base structural class is inetOrgPerson, use of the uid attribute to construct the RDN of a CA will require the auxiliary class uidObject to permit the uid attribute to be used. In the cases where organizationalUnit or organization is the base class for a CA, use of the auxiliary class dcObject will permit the RDN of the CA to be a domain component.
証明機関（CA）オブジェクトクラスは補助クラスです。つまり、基本的には、organizationalRole、organization、organizationalUnit、personなどの基本クラスの追加属性のセットです。基本構造クラスがinetOrgPersonである場合を除いて、CAのRDNを構築するためにuid属性を使用するには、補助クラスuidObjectがuid属性の使用を許可する必要があります。 organizationalUnitまたはorganizationがCAの基本クラスである場合、補助クラスdcObjectを使用すると、CAのRDNをドメインコンポーネントにすることができます。
Servers and server applications are typically represented, for want of anything better, by entries of the object class applicationProcess (or a class derived from it). Sometimes the class applicationEntity is used. In either case, the uid attribute should probably not be employed to construct the RDN of a server or server application object. The standard schema uses the attribute cn for such RDNs.
サーバーとサーバーアプリケーションは、通常、オブジェクトクラスapplicationProcess（またはそれから派生したクラス）のエントリによって、より良いものを求めて表されます。場合によっては、applicationEntityクラスが使用されます。どちらの場合も、サーバーまたはサーバーアプリケーションオブジェクトのRDNを構築するために、おそらくuid属性を使用しないでください。標準スキーマは、そのようなRDNに属性cnを使用します。
Suppose one wants to use this naming plan both in the construction of DNs for SSL server certificates and for their storage in a directory. It is customary for clients connecting via SSL to compare the server's domain name (e.g. from the URL used to contact the server) with the value of the cn attribute in the subject field (i.e. subject's DN) of the server's certificate. For this reason, it is common practice to set the cn attribute to the server's domain name.
SSLサーバー証明書のDNの構築とディレクトリへの格納の両方でこの命名計画を使用したいとします。 SSLを介して接続するクライアントは、サーバーのドメイン名（サーバーへの接続に使用されるURLなど）とサーバーの証明書のサブジェクトフィールド（サブジェクトのDN）のcn属性の値を比較するのが慣例です。このため、cn属性をサーバーのドメイン名に設定するのが一般的です。
The naming and schema to handle this situation is best explained by an example. Consider the server "host.acme.com". Following the algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN dc=host, dc=acme, dc=com is constructed. To conform to the existing practices just described, the server's subject DN for the SSL server certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and the server's certificate should be stored in a directory entry with this name. This entry should use application process or application entity as its structural object class and strong authentication user as is auxiliary class.
この状況を処理するための命名とスキーマは、例で最もよく説明されています。サーバー「host.acme.com」について考えてみます。 「LDAP識別名でのドメインの使用」[1]のアルゴリズムに従って、DN dc = host、dc = acme、dc = comが構築されます。今説明した既存のプラクティスに準拠するには、SSLサーバー証明書のサーバーのサブジェクトDNがcn = host.acme.com、dc = host、dc = acme、dc = comであり、サーバーの証明書がディレクトリエントリに格納されている必要があります。この名前で。このエントリでは、アプリケーションオブジェクトまたはアプリケーションエンティティを構造オブジェクトクラスとして使用し、強力な認証ユーザーを補助クラスとして使用する必要があります。
For X.500 servers or LDAP servers following the X.500 model, our schema requires the definition of new name forms, structure rules, and DIT content rules. Structure rules and DIT content rules are locally defined, and do not involve a globally significant object identifier.
X.500モデルに準拠したX.500サーバーまたはLDAPサーバーの場合、スキーマには、新しい名前フォーム、構造ルール、およびDITコンテンツルールの定義が必要です。構造ルールとDITコンテンツルールはローカルで定義され、グローバルに重要なオブジェクト識別子を含みません。
The following name forms are defined using the syntax of section 6.22 of [14] for the convenience of those using such servers.
以下の名前の形式は、[14]のセクション6.22の構文を使用して定義され、そのようなサーバーを使用するユーザーの便宜を図っています。
Note that since the structural object classes organization, organizationalUnit, locality and organizationalPerson do not permit inclusion of the dc attribute, an auxiliary object class such as dcObject [1] must be used for instances of these classes.)
構造オブジェクトクラスorganization、organizationalUnit、locality、organizationalPersonではdc属性を含めることができないため、これらのクラスのインスタンスには、dcObject [1]などの補助オブジェクトクラスを使用する必要があります。
The OIDs in this group are under the iso.org.dod.internet.directory.NameForm branch of the OID tree (1.3.6.1.1.2).
このグループのOIDは、OIDツリー（1.3.6.1.1.2）のiso.org.dod.internet.directory.NameFormブランチの下にあります。
( 1.3.6.1.1.2.1 NAME domainNameForm OC domain MUST dc )
（1.3.6.1.1.2.1 NAME domainNameForm OCドメインはdcでなければならない）
The domainNameForm name form indicates that objects of structural object class domain have their RDN constructed from a value of the attribute dc.
domainNameForm名前フォームは、構造オブジェクトクラスdomainのオブジェクトが、属性dcの値から構築されたRDNを持っていることを示しています。
( 1.3.6.1.1.2.2 NAME dcOrganizationNameForm OC organization MUST dc )
（1.3.6.1.1.2.2 dcOrganizationNameForm OC組織の名前はdcでなければならない）
The dcOrganizationNameForm name form indicates that objects of structural object class organization have their RDN constructed from a value of the attribute dc.
dcOrganizationNameForm名前フォームは、構造オブジェクトクラス組織のオブジェクトのRDNが属性dcの値から構築されていることを示しています。
( 1.3.6.1.1.2.3 NAME dcOrganizationalUnitNameForm OC organizationalUnit MUST dc )
（1.3.6.1.1.2.3名前dcOrganizationalUnitNameForm OC organizationalUnitはdcでなければならない）
The dcOrganizationalUnitNameForm name form indicates that objects of structural object class organizationalUnit have their RDN constructed from a value of the attribute dc.
dcOrganizationalUnitNameForm名前フォームは、構造オブジェクトクラスorganizationalUnitのオブジェクトのRDNが属性dcの値から構築されていることを示しています。
( 1.3.6.1.1.2.4 NAME dcLocalityNameForm OC locality MUST dc )
（1.3.6.1.1.2.4 NAME dcLocalityNameForm OC localityはdcでなければならない）
The dcLocalityNameForm name form indicates that objects of structural object class locality have their RDN constructed from a value of the attribute dc.
dcLocalityNameForm名前フォームは、構造オブジェクトクラスのローカリティのオブジェクトが、属性dcの値から構築されたRDNを持っていることを示しています。
( 1.3.6.1.1.2.5 NAME uidOrganizationalPersonNameForm OC organizationalPerson MUST uid )
（1.3.6.1.1.2.5名前uidOrganizationalPersonNameForm OC organizationalPersonはuidでなければならない）
The uidOrganizationalPersonNameForm name form indicates that objects of structural object class organizationalPerson have their RDN constructed from a value of the attribute uid.
uidOrganizationalPersonNameForm名前フォームは、構造オブジェクトクラスorganizationalPersonのオブジェクトが、属性uidの値から構築されたRDNを持っていることを示しています。
Although access controls may be placed on portions of the DIT to deny browse access to unauthorized clients, it may be possible to infer directory names and DIT structure in such sensitive portions of the DIT from the results of DNS queries. Providing public visibility to some portions of the DIT may assist those make such inferences.
DITの一部にアクセス制御を配置して、許可されていないクライアントへの参照アクセスを拒否することもできますが、DNSクエリの結果から、DITのこのような機密部分のディレクトリ名とDIT構造を推測できる場合があります。 DITの一部に公開の可視性を提供することは、そのような推論を行うのに役立ちます。
This plan has emerged in the course of a number of fruitful discussions, especially with David Chadwick, John Dale, Joe Gajewski, Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
この計画は、特にデビッド・チャドウィック、ジョン・デイル、ジョー・ガジェウスキー、マーク・ジャクソン、ライアン・モーツ、トム・スペンサー、クリス・ツーとの多くの実りある議論の過程で浮上しました。
[1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, "Using Domains in LDAP Distinguished Names", RFC 2247, January 1998.
[1] Kille、S.、Wahl、M.、Grimstad、A.、Huber、R。、およびS. Sataluri、「Using Domains in LDAP Distinguished Names」、RFC 2247、1998年1月。
[2] X.500: The Directory -- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988.
[2] X.500：ディレクトリ-概念、モデル、およびサービスの概要、CCITT勧告X.500、1988年12月。
[3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991.
[3] Barker、P。、およびS. Kille、「COSINE and Internet X.500 Schema」、RFC 1274、1991年11月。
[4] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991.
[4] 北米ディレクトリフォーラム、「c = USの命名方式」、RFC 1255、1991年9月。
[5] The North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, February 1993.
[5] 北米ディレクトリフォーラム、「NADF Standing Documents：A Brief Overview」、RFC 1417、1993年2月。
[6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[6] Yeong、W.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol」、RFC 1777、1995年3月。
[7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[7] Wahl、M.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（v3）」、RFC 2251、1997年12月。
[8] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[8] Kille、S。、「識別名の文字列表現」、RFC 1779、1995年3月。
[9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[9] Wahl、M.、Kille、S。、およびT. Howes、「Lightweight Directory Access Protocol（v3）：UTF-8 String Representation of Distinguished Names」、RFC 2253、1997年12月。
[10] Wahl, M., "A Summary of the Pilot X.500 Schema for use in LDAPv3", Work in Progress.
[10] Wahl、M。、「LDAPv3で使用するパイロットX.500スキーマの概要」、進行中。
[11] Wahl, M., "A Summary of the X.500 User Schema for use with LDAPv3", RFC 2256, December 1997.
[11] Wahl、M。、「LDAPv3で使用するX.500ユーザースキーマの概要」、RFC 2256、1997年12月。
[12] Howes, T., and M. Wahl, "Referrals and Knowledge References in LDAP Directories", Work in Progress.
[12] Howes、T。、およびM. Wahl、「LDAPディレクトリ内の参照と知識参照」、進行中の作業。
[13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[13] ハウズ、T。、およびM.スミス、「LDAP URL形式」、RFC 2255、1997年12月。
[14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[14] Wahl、M.、Coulbeck、A.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（v3）：Attribute Syntax Definitions」、RFC 2252、1997年12月。
[15] Smith, M., "Definition of the inetOrgPerson Object Class", Work in Progress.
[15] Smith、M。、「inetOrgPersonオブジェクトクラスの定義」、作業中。
Al Grimstad AT&T Room 1C-429, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Al Nimstad AT＆T Room 1C-429、101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA
EMail: alg@att.com
Rick Huber AT&T Room 1B-433, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Rick Huber AT＆T Room 1B-433、101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA
EMail: rvh@att.com
Sri Sataluri Lucent Technologies Room 4D-335, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Sri Sataluri Lucent Technologies Room 4D-335、101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA
EMail: srs@lucent.com
Mark Wahl Critical Angle Inc. 4815 W Braker Lane #502-385 Austin, TX 78759 USA
Mark Wahl Critical Angle Inc. 4815 W Braker Lane＃502-385 Austin、TX 78759 USA
EMail: M.Wahl@critical-angle.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。