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. 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) や他のディレクトリ対応アプリケー ションを生成することを促進することを可能にします。 1.0 Executive Summary 1.0 要約 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つの中心的な特色を持ちます。最初に、名前のルート及び上位ポ ジションについてドメインネームシステム (DNS) から命名の既にある基 盤をベースにしています。計画のこの要素は、この計画の対になる文書 「LDAP 識別名においてドメインを用いる」[1] で記述されたアイデアを 使ったものです。次に、既にあるインターネット上の人間の識別子の再利 用を許可するというオプションも含め、人間オブジェクトといったディレ クトリの末端のオブジェクトに名前をつけるためのオプションの数々を提 供します。 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 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., この使用にあたっての一つのアプローチは、既存の識別子の貯蔵庫 (Store)を再利用するときに RDN として uid 属性を用い、ディレクトリ にとって特に新しい識別子を生成するときは RDN として cn 属性を用い るというものです。人間オブジェクトのために便利な既存の識別子スキー ムは 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 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 2.0 The Problem 2.0 問題点 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] は世界中に分散したディレクトリを作成 するために用いられます。インターネット X.500 ディレクトリパイロッ トは、何年もの間実際に運用されており、異なる質のおよそ 1500 万の エントリにまでサイズが膨らんでいます。パイロットの成長率はパイロッ ト期間中のインターネットの成長率よりも低いです。 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. このパイロットの成長を抑制することに貢献する要因は相当多くありま す。命名 (naming) についての共通の 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. 次はもっと深刻で、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 この企ては、ある特定の名前を使う権利についての議論からディレクトリ サービス提供業者が解放されるという重要な利点を持っていますが、これ はより不明瞭な名前へと導きます。これらの不明瞭さの中で、法的名称 は、ユーザーが通常その組織に関連させる名前よりも、長くて親しみにく い形式をほとんど常にとります。例えば、米国では、"Acme, Inc." とい うように、法的組織名のほとんどが ", Inc." で終わります。さらに、米 国の場合、市民命名基盤は国全体では機能しないので、それが提供する組 織名は州のもとで地域的 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 の関わる範囲が大変狭いため、これらの国立 登録機関の一つに組織を登録することへの興味は大変小さなものになって います。最終的に、多国籍企業は国際登録機関の欠如にいらいらを募らせ るでしょう。 3.0 Requirements 3.0 要求事項 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. ディレクトリ命名計画は、一つの孤立したディレクトリサーバーの中で最 低限の、あるコンテキスト（名前空間）の中で曖昧でない（ただ一つの ディレクトリオブジェクトを識別する）ディレクトリオブジェクトへの名 前（識別子、ラベル）を構築するためのガイドを提供しないといけませ ん。 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. ディレクトリオブジェクトは単純にいえば一連の属性値です。実世界のオ ブジェクトとディレクトオブジェクトの関連は、ディレクトリ対応アプリ ケーションによって作成され、一般的な場合では、一対多です。 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. この命名計画の目標の一つに、潜在的な自律ディレクトリサーバー群のゆ るやかな組み合わせをある大きなシステムへとまとめる一つの形式または その他の形式を促進する、命名パターンを定義することがあります。 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.) そのような緩やかに組み合わされたシステムの中の名前は、曖昧さなしに 一つの実世界オブジェクトを識別するべきです。実世界のオブジェクト は、しかし、緩やかに組み合わされたシステム中の、異なるサーバー（例 えば別々に管理されている）の中で、別に表現される（即ち、異なる属性 を持つが同じ 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 に エンコードされた情報を理解する能力があるようにすべきです。ユーザー にとって全く不明瞭な名前はこの要求を満たしません。 4.0 Name Construction 4.0 名前の構築 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. 私たちは domainComponent (dc), userID (uid) 及び commonName (cn) という3種類の属性型を用いてどのように DN を構築するかを記述しま す。 4.1 Domain Component (dc) 4.1 Domain Component (ドメイン要素) (dc) 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, Inc" であり、登録済みドメイン名 "acme.com" を持つとしましょ う。そのドメイン名から以下の DN を構築するでしょう。 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 の下位要素はこの組織に関係するディレクトリオブジェクトでしょ う。ドメイン要素 (domain component) 属性を、組織単位や地域といっ た組織の下位区分に名前を付けるために使うことが出来ます。<不正確>例えば、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. Use of the dc attribute for the RDN of directory objects of class "domain" is also possible [1]. クラス "domain" のディレクトリオブジェクトの RDN として dc 属性を 使用することも可能です。[1] 4.2 User ID (uid) 4.2 ユーザーID (uid) The userid (uid) attribute is defined and registered in RFC1274 [3][10]. ユーザーID (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 を構成するため に用いることが出来ます。この計画は、この属性がいかに使用されるかに ついて制約しません。 4.3 Common Name (cn) 4.3 Common Name (共通名) (cn) The commonName (cn) attribute is defined and registered in X.500 [3][11]. commonName (cn) 属性は X.500 [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 を構成するため に用いることが出来ます。この計画は、どの属性が以下に使用されるかに ついて制約しません。 4.4 Examples of uid and cn Usage 4.4 uid と cn の使用の例 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 メールボックス識別子が名前構築のためのとりわけ便利 な供給源であることに気づきました。ある人がいくつもの電子メールアド レスを持つときは、ユーザー識別の目的に用いる一つを選択します。私た ちはこれをそのユーザーのための「識別」電子メールアドレス、又は「識 別」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: 例えば、もし組織 Acme の系列化にあり、識別電子メールアドレス J.Smith@acme.com を持つあるユーザーがいたら、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 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@ame.com という形式であるのに、一部の人は ISP のメールボック スを持ちそれゆえメールボックスが local@worldnet.att.net という形式 をもつためにこの示唆が実現不可能であるという状況を表現します。 5.0 Naming Plan and Directories 5.0 命名計画とディレクトリ 5.1 Directory Services Considerations 5.1 ディレクトリサービスの考慮事項 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] です。DN に DNS ホスト名とポート（一つまたはそれ以上の LDAP サーバーに対 応）を組み合わせることで、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 参照は一つ以上の 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 を提供することを意図していません。 5.2 Directory Schema Implications of the Naming Plan 5.2 命名計画におけるディレクトリスキーマの関連 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] への応用は、ここで開発された命名計画を用いるために拡張 が必要です。以下に記述された拡張は、可能な限り既にあるスキーマ要素 を再利用することを意図しています。その拡張が必要とされるディレクト リオブジェクトは以下のとおりです: 組織 (organization), 組織単位 (organization unit), そして末端のオブジェクトの様々なクラス。私た ちは組織、組織単位、そして選ばれた末端のクラスのために以下のスキー マへの修正を記述します。 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]. 可能な拡張をするために既にある構造オブジェクトクラスを用いることを 継続するので、私たちは、2つの新しい補助クラス dcObject と uidObject からの付加情報を伴う、上記クラスがベースとなる補完エント リを提案します。 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 ) 5.2.1 Organization Schema 5.2.1 組織 (Organization) スキーマ 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 を構築するために用いられます。これ は organization のオブジェクトクラス属性に補助クラス dcObject を追 加することで可能になります。 5.2.2 Organizational Unit Schema 5.2.2 組織単位 (Organizational Unit) スキーマ 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 属性は（oraganizaion か organizationalUnit オブジェクトに対して DIT 中の下位となる） organizationalUnit オブジェクトの RDN を構築 するために用いられます。これは organizatinalUnit の objectClass 属 性に補助クラス dcObject を追加することで可能になります。 5.2.3 Person Schema 5.2.3 人間 (Person) スキーマ 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 クラスから派生したどのクラスでも必要な属 性であり、依然として非常に重要であることは強調されるべきです。興味 の対象であるユーザーエントリを検索して見出すことを可能にするにあた り重要な役割を果たすでしょう。 5.2.4 Certification Authority Schema 5.2.4 認証機関 (Certification Authority) スキーマ 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 属性を用いることは、uid 属性を用いること を許可するために補助クラス uidObject を要求するでしょう。 organizationalUnit または organization が CA のためのベースクラス であるという場合には、補助クラス dcObject を使用することでドメイン 要素を CA の RDN で用いることができます。 5.2.5 Server and Server Application Schema 5.2.5 サーバー及びサーバーアプリケーションスキーマ 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 のエントリによって表現されます。 時々クラス applicationEntry が用いられます。いずれの場合でも、uid 属性をサーバーまたはサーバーアプリケーションオブジェクトの RDN を 形成するために用いられることはおそらくするべきではありません。標準 スキーマはそのような 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 の形成及びそれ をディレクトリに格納するための両方で用いたいとしましょう。サーバー 証明書のサブジェクトフィールド（即ち、サブジェクトの DN）の cn 属 性の値とサーバーのドメイン名（例えば、サーバーに接続するために用い られる URL から取得）とを比較することが SSL 経由で接続しているクラ イアントにとっては通常です。この理由から、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 とすべきであり、この名前でディレクトリエ ントリに格納するべきです。このエントリはその構造クラスとしてアプリ ケーションプロセスまたはアプリケーション実体を、そして strong authentication user が補助クラスであるように使うべきです。 5.2.6 Name Forms 5.2.6 名前形式 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] といった補助オブジェクトクラスをこれらのクラスのインスタンスの ために用いなければなりません。 5.2.6.1 Name Form for Domain Objects 5.2.6.1 Domain オブジェクトのための名前形式 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 木の iso.org.dod.internet.directory.NameForm 枝の下になります。 ( 1.3.6.1.1.2.1 NAME domainNameForm OC domain MUST 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 を持つことを示します。 5.2.6.2 Name Form for Organization Objects 5.2.6.2 Organization オブジェクトのための名前形式 ( 1.3.6.1.1.2.2 NAME dcOrganizationNameForm OC organization MUST dc ) The dcOrganizationNameForm name form indicates that objects of structural object class organization have their RDN constructed from a value of the attribute dc. dcOrganizaionNameForm 名前形式は、構造オブジェクトクラス organization のオブジェクトが、属性 dc の値から形成されるその RDN を持つことを示します。 5.2.6.3 Name Form for Organizational Unit Objects 5.2.6.3 Organizational Unit オブジェクトのための名前形式 ( 1.3.6.1.1.2.3 NAME dcOrganizationalUnitNameForm OC organizationalUnit MUST 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 のオブジェクトが、属性 dc の値から形成されるそ の RDN を持つことを示します。 5.2.6.4 Name Form for Locality Objects 5.2.6.4 Locality オブジェクトのための名前形式 ( 1.3.6.1.1.2.4 NAME dcLocalityNameForm OC locality MUST 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 名前形式は、構造オブジェクトクラス locality の オブジェクトが、属性 dc の値から形成されるその RDN を持つことを示 します。 5.2.6.5 Name Form for Organizational Person Objects 5.2.6.5 Organizational Person オブジェクトのための名前形式 ( 1.3.6.1.1.2.5 NAME uidOrganizationalPersonNameForm OC organizationalPerson MUST 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 を持つことを示します。 6.0 Security Considerations 6.0 セキュリティ上の考慮事項 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 のある部分を一般から見えるようにすることは、 そのような推論をすることを援助するでしょう。 7.0 Acknowledgments 7.0 謝辞 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. この計画は、とりわけ David Chadwick, John Dale, Joe Gajewski, Mark Jackson, Ryan Moats, Tom Spencer そして Chris Tzu との実りの 多い議論の数々の流れの中から生まれました。 8.0 References 8.0 参考文献 [1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, "Using Domains in LDAP Distinguished Names", RFC 2247, January 1998. [2] X.500: The Directory -- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988. [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991. [4] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991. [5] The North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, February 1993. [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995. [7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [8] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995. [9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [10] Wahl, M., "A Summary of the Pilot X.500 Schema for use in LDAPv3", Work in Progress. [11] Wahl, M., "A Summary of the X.500 User Schema for use with LDAPv3", RFC 2256, December 1997. [12] Howes, T., and M. Wahl, "Referrals and Knowledge References in LDAP Directories", Work in Progress. [13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [15] Smith, M., "Definition of the inetOrgPerson Object Class", Work in Progress. 12. Authors' Addresses 12. 著者の連絡先 Al Grimstad 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 EMail: rvh@att.com 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 EMail: M.Wahl@critical-angle.com 13. Full Copyright Statement 13. 完全な著作権表記 Copyright (C) The Internet Society (1998). All Rights Reserved. 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. Grimstad, et. al. Informational [Page 1]