RFC2377 日本語訳
2377 Naming Plan for Internet Directory-Enabled Applications. A.Grimstad, R. Huber, S. Sataluri, M. Wahl. September 1998. (Format: TXT=38274 bytes) (Updated by RFC4519) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.グリムスターの要求をネットワークでつないでください: 2377年のR.ヒューバーカテゴリ: 角度株式会社1998年9月に重要な情報のAT&TのS.SataluriルーセントテクノロジーズのM.ウォール
Naming Plan for Internet Directory-Enabled Applications
ディレクトリで可能にされたアプリケーションとインターネットのためのプランを命名します。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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アプローチを使用することにおけるものによって行きあたられた問題を克服することによって、インターネットホワイトページService(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アプローチの応用はこれまで、インターネットにおけるディレクトリで可能にされたアプリケーションの広い展開への障害であると判明しました。 必要な登録インフラストラクチャは、実在しないか主に無視されています。 存在するインフラストラクチャは、使用するために厄介であり、反生産的の結果を生む傾向があります。 ディレクトリサーバのマネージャとオペレータにとって、命名に使用される属性は、ユーザにとって紛らわしくて、融通がききません。
Grimstad, et. al. Informational [Page 1] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[1ページ]のRFC2377
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])に説明された考えを利用します。 そして、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は頂上、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
dc=法人のdc=頂上、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つの属性がどう使用されているかを抑制しません。
Grimstad, et. al. Informational [Page 2] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[2ページ]のRFC2377
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つのアプローチは特にディレクトリのための新しい識別子を作成するとき、RDNとして識別子の既存の店とcn属性を再利用するとき、RDNとしてuid属性を使うことです。 人のオブジェクトの便利な既存の識別体系はRFC822メールボックス識別子です。 識別子のこの店を使う人のためのRDNが例えばあるように
uid=John.Smith@acme.com
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
uidは John.Smith@acme.com と等しく、dcは頂上と等しく、dc=com uidは Mary.Jones@acme.com と等しく、dc=法人であり、dcは頂上と等しく、dc=com uidは J.Smith@worldnet.att.net と等しく、dc=法的であることで、dcは頂上と等しく、dc=com cnは読書Room、dc=物理学、国家のdc=研究室、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ディレクトリ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に基づくインターネットホワイトページServiceの成長を制限するいくつかの方法で貢献しています。
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共同体で名前を構成する従来の方法は有益な(すなわち、公式に標準化されなかった)別館BとしてX.521に記録されます。 ユーザの相対的な分類名(RDN)は一般名(cn)属性から成ります。 中、これによる意味される、何、ユーザの特定の社会--そのユーザの名前であることが通例に理解されています。 ユーザの分類名はある一般的なオブジェクトの名前の組み合わせです、組織や地理的なユニットのように、一般名で。 このスタイルの名前工事に関する2つの主な問題があります。
Grimstad, et. al. Informational [Page 3] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[3ページ]のRFC2377
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として一般名属性を使用できません。 同じディレクトリ情報Tree(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.
北米のディレクトリForum(NADF、現在の北大西洋ディレクトリForumにもかかわらず、それでも、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.」と共に「頂上Inc.」Moreoverのように終わります、米国の場合では、民間命名インフラストラクチャは全国的に作動しません、したがって、それが提供する組織名がディレクトリをブラウズしている間、それらを見つけるのを難しくする州と地方のDITノードの下で位置しなければなりません。 NADFはalgorithmicallyにDITの、より便利な場所にエントリーか別名のプレースメントを許容するマルチ属性RDNsを引き出す方法を提案しますが、これらの派生している名前は、厄介であって、不人気です。 例えば、Nadirが「天底はInc.をネットワークでつなぐこと」という名でニュージャージーの民間命名インフラストラクチャで登録される組織であるなら、その時、Itsの民間分類名(DN)があるでしょう。
o="Nadir Networks, Inc.", st=New Jersey, c=US
o=「天底はInc.をネットワークでつなぐ」、第=c=ニュージャージー(米国)
Grimstad, et. al. Informational [Page 4] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[4ページ]のRFC2377
while its derived name which is unambiguous under c=US directly is
c=米国の下で明白な派生している名前は直接そうですが
o="Nadir Networks, Inc." + st=New Jersey, c=US
o=「天底はInc.をネットワークでつなぐ」という+、第=c=ニュージャージー(米国)
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つに組織を登録することへの関心は最小限でした。 最終的に、多国籍の組織は国際的な登録局の不足によってだめにされます。
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.
ディレクトリ命名プランは何らかの文脈(名前空間)の中で明白な(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セットの属性値です。 一般的な場合では、本当の世界オブジェクトとディレクトリオブジェクトとの協会は、ディレクトリで可能にされたアプリケーションで作られていて、多くへの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
そのような弱連結システムの名前は明白に1個の本当の世界オブジェクトを特定するべきです。 しかしながら、本当の世界オブジェクトは弱連結システムの異なった(例えば、独自に管理される)サーバで異なって表されるかもしれません(すなわち、異なった属性にもかかわらず、同じDNを持っている異なったディレクトリオブジェクトで)。 プランは、このありそうなシナリオに打ち勝つために名前を作成するのを試みません。 すなわち、それは、すべてのディレクトリオブジェクトのためにただ一つの名前空間を生産するのを試みません。 (この問題はさらに詳細に考えられます。
Grimstad, et. al. Informational [Page 5] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[5ページ]のRFC2377
in Section 5.1.)
セクション5.1で。)
c) readily usable by LDAP clients and servers
LDAPクライアントとサーバで容易に使用可能なc)
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.
私たちは、ディレクトリで可能にされたアプリケーションのユーザインタフェースが、DNsにユーザをさらすのを避けると予想しますが、彼らからユーザを完全に隔離できるのはありそうもないです。 この理由で、命名プランは名前構造における身近な情報の使用を可能にするべきです。 ユーザはその人の自身の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.
私たちは3人の属性タイプ、domainComponent(dc)、userID(uid)、およびcommonName(cn)を使用することでどうDNsを組み立てることができるかを説明します。 それらはそれぞれ順番に説明されます。
4.1 Domain Component (dc)
4.1 ドメインコンポーネント(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
この命名プランに従って、ディレクトリを配布したがっている組織は以下の通り続くでしょう。 登録されたドメイン名"acme.com"を持っていて、組織、例えば、「頂上Inc.」を考えてください。 それはそうするでしょう。
Grimstad, et. al. Informational [Page 6] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[6ページ]のRFC2377
construct the DN
DNを組み立ててください。
dc=acme, dc=com
dcは頂上、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の部下はオブジェクトが組織に話したディレクトリになるでしょう。 組織の組織的なユニットや場所などの区画分譲地を命名するのにドメインコンポーネント属性を使用できます。 例えば、頂上は、名前を構成するのにドメイン名"corporate.acme.com"と"richmond.acme.com"を使用するかもしれません。
dc=corporate, dc=acme, dc=com
dc=richmond, dc=acme, dc=com
dc=法人のdc=頂上、dc=com dc=richmond、dc=頂上、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と場所オブジェクトを命名するのに必要であるディレクトリ図式は以下でセクション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を使用することで組織の組織的なユニットや場所などの区画分譲地にRDNsを割り当てることができるだろうというメモ
ou=corporate, dc=acme, dc=com
l=richmond, dc=acme, dc=com.
ouは法人のdc=頂上と等しく、dc=com lはrichmondと等しく、dcは頂上、dc=comと等しいです。
Use of the dc attribute for the RDN of directory objects of class "domain" is also possible [1].
また、dc属性のクラス「ドメイン」のディレクトリオブジェクトのRDNの使用は可能な[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 俗称(cn)
The commonName (cn) attribute is defined and registered in X.500 [3][11].
commonName(cn)属性は、X.500[3][11]に定義されて、示されます。
Grimstad, et. al. Informational [Page 7] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[7ページ]のRFC2377
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 Usageに関する例
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.
実際には、RDNが人のオブジェクトが私たちであったので他のオブジェクトに名前とcnの既存の登録を利用できたので、私たちはuidを使用しました。
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メールボックス識別子が特に便利なソースであることがわかりました。 人にいくつかのEメールアドレスがあると、1つはユーザ登録名の目的のために選択されるでしょう。 私たちは、ユーザのためにこれを「顕著な」Eメールアドレスか「顕著な」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:
例えば、Eメールアドレス J.Smith@acme.com を区別した組織Acmeに合併されたユーザがいれば、uid属性は以下の通りになるでしょう。
uid=J.Smith@acme.com
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のドメインコンポーネント属性はその人の顕著なEメールアドレスのドメイン名から構成されるでしょう。 すなわち、ユーザuid= J.Smith@acme.com に関しては、ドメインコンポーネント属性は通常、以下の通りでしょう。
dc=acme, dc=com
dcは頂上、dc=comと等しいです。
The full LDAP DN for this user would then be:
そしてこのユーザのための完全なLDAP DNは以下の通りでしょう。
uid=J.Smith@acme.com, dc=acme, dc=com
uidは J.Smith@acme.com と等しく、dcは頂上、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識別子を持っているディレクトリ管理者は以下の要素を考えるべきです:
Grimstad, et. al. Informational [Page 8] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[8ページ]のRFC2377
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
js@acme.com
may well be preferable to one such as:
たぶん以下のように1より望ましいでしょう。
js@blaster.third-floor.acme.com.
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
js@acme.com
may well be preferable to one such as:
たぶん以下のように1より望ましいでしょう。
J.Smith@acme.com
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が有効なメールボックスであると仮定するのは、悪い仮定でしょう。 メール属性の値はいつもチェックされるべきです。
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.
BUT NEED NOT、RFC822識別子のドメイン名の要素がそうするかもしれないと強調するのが重要であり、DNのドメインの部品と同じにしてください。 これは、ドメインコンポーネントがアクセスが必要性が機械的にユーザのEメールアドレスに反映されないという要件を構造化するコントロールか他のディレクトリであるとサポートするために自由度を提供することを意味します。 まさしくユーザのEメールアドレスを変えさせるどんな条件のもとでもアクセス制御構造の変更などの新しいシステム要件を容易にしたいと思いません。 また、注意されて、ドメインコンポーネントがRFC822識別子に合うのが必要ではありませんが、私たちがするのが連結されたドメインコンポーネントが登録されたドメイン名を形成するのを必要として、それがいるということであるべきです、DNSに表されるもの。 これはディレクトリ階層構造で自動的に名前闘争を避けます。
Grimstad, et. al. Informational [Page 9] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[9ページ]のRFC2377
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.スミスが、特別な許容がdc=頂上、LDAP DITのdc=com部分の情報に承諾される必要であると仮定してください。 彼らの名前構造のそばで特別なユーザを組織化するのがグループ(DNsの任意の収集)を通して一般に簡単であるので、私たちはこのためにサブドメインを使用します。 特別な許容がMISの組織的なユニットのユーザによって必要とされたと仮定してください。 正常なDNS手順によると、既に存在していないなら、"mis.acme.com"というサブドメインは確立されます。 構造という名前をもっているユーザの特別な許容は承諾されるでしょう:
uid=*, dc=mis, dc=acme, dc=com
uidが*、dc=と等しい、誤、dc=頂上、dc=com
The DN of J.Smith in this case will be:
この場合、J.スミスのDNは以下の通りになるでしょう。
uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
uidが J.Smith@acme.com 、dc=と等しい、誤、dc=頂上、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.スミスのためのDNは以下の通りであるかもしれません。
uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
uidが J.Smith@worldnet.att.net 、dc=と等しい、誤、dc=頂上、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のドメイン名部分が合っているどんなREQUIREにもディレクトリ分類名のdcの部品をしていない間、私たちは、可能であるところでこれをすることを提案します。 最小限では、DNとuidの最も重要な断片であるなら、ユーザのEメールアドレス、連絡するのが適切であるディレクトリシステムが、ユーザの情報が大いに高められるのがわかると発見することに関する知識に基づいた同じくらい(すなわち、「dcは頂上と等しいです、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 、分集団がフォーム local@worldnet.att.net のISPとしたがって、メールボックスからのメールボックスを持っているということであるということでない状況を表します。
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つのレベルで現れるでしょう。
Grimstad, et. al. Informational [Page 10] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[10ページ]のRFC2377
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名前空間を共有する1セットのサーバ)の中に接続されるでしょう。 島をつなげる接着剤は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 URL、これらの2つのレベルのカップリングが鋭くそうしないかもしれない1つか以上が実際には区別されたのでLDAP紹介が言い表されるので。
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と共にディレクトリオブジェクトを独自に管理したかもしれない可能性を隠すためにDNsを生産するのを試みません。
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]に開発された伝統的なディレクトリ図式は、拡張子がここで開発される命名プランと共に使用されるのを必要とします。 拡大は既存の図式要素をできるだけ再利用する以下の試みについて説明しました。 拡大が必要であるディレクトリオブジェクトは以下の通りです。 葉の組織、組織的なユニット、および様々なクラスは反対します。 私たちは組織、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].
可能な範囲内で既存の構造的なオブジェクトのクラスを使用し続けるために、私たちは、2の新しい補助のオブジェクトのクラス、dcObject、およびuidObjectからの追加情報でこれらのクラスに基づくエントリーを補うよう提案します。 それらは、[14]のセクション4の記法を使用することで指定されます。
The auxiliary object class dcObject is defined in "Using Domains in LDAP Distinguished Names" [1].
補助のオブジェクトのクラスdcObjectは「LDAP分類名にドメインを使用します」[1]で定義されます。
Grimstad, et. al. Informational [Page 11] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[11ページ]のRFC2377
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.1NAME uidObject SUP先端AUXILIARY MUST uid)
5.2.1 Organization Schema
5.2.1 組織図式
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を加えることによって、可能にされます。
5.2.2 Organizational Unit Schema
5.2.2 組織的なユニット図式
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オブジェクト(DITで組織かorganizationalUnitオブジェクトのどちらかに下位である)のRDNを組み立てるのに使われます。 これは、組織的なユニットのobjectClass属性に補助のクラスdcObjectを加えることによって、可能にされます。
5.2.3 Person Schema
5.2.3 人の図式
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は各クラスで許されています。 一貫性において、このオブジェクトクラス属性値でアプリケーションフィルタリングを補助するために人のエントリーobjectClass属性にuidObjectを加えることができました。 他のクラスのRDNがuid属性で組み立てられているorganizationalPersonなどの人のオブジェクトの使用は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属性の使用を必要としていない間、それが人のクラスから得られたどんなクラスでも必要な属性であり、まだかなり重要であると強調されるべきです。 それはユーザエントリーは興味があるのが検索によってわかるのを可能にすることにおける重要な役割をプレーするでしょう。
5.2.4 Certification Authority Schema
5.2.4 認証局図式
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
証明権威(カリフォルニア)オブジェクトのクラスは補助のクラスです、それが本質的にはorganizationalRole、組織、organizationalUnitまたは人などの基底クラスへの1セットの追加属性であることを意味して。 ベースの構造的なクラスがinetOrgPerson、uidの使用であるケースにおける、カリフォルニアのRDNを構造物の結果と考えてください。
Grimstad, et. al. Informational [Page 12] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[12ページ]のRFC2377
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.
補助のクラスuidObjectが、uid属性が使用されるのを可能にするのが必要でしょう。 organizationalUnitか組織がカリフォルニアへの基底クラスである場合では、補助のクラスdcObjectの使用は、カリフォルニアの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(または、それから得られたクラス)のエントリーで。 時々、クラスapplicationEntityは使用されています。 どちらの場合ではも、サーバかサーバ・アプリケーションオブジェクトのRDNを組み立てるのにたぶんuid属性を使うべきではありません。 標準の図式はそのようなRDNsに属性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サーバ証明書のためのDNsの構造と彼らのストレージにディレクトリでこの命名プランを使用したがっていると仮定してください。 SSLを通して接続するクライアントにとって、サーバの証明書の対象の分野(すなわち、対象のDN)のcn属性の値にサーバのドメイン名(例えばサーバに連絡するのに使用されるURLからの)をたとえるのは通例です。 この理由で、サーバのドメイン名に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はホストと等しく、dcは頂上と等しく、dc=comは組み立てられます。 ただ説明された既存の習慣に従うために、サーバの対象DNはSSLサーバ証明書がcn=host.acme.comと、dc=ホストと、dc=頂上と、dc=comとサーバの証明書であるべきであるので、ディレクトリエントリにこの名前で保存されるべきです。 このエントリーは補助のクラスのようにその構造的なオブジェクトのクラスと強い認証ユーザとしてアプリケーション・プロセスかアプリケーション実体を使用するべきです。
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.)
構造的なオブジェクトのクラスの組織、organizationalUnit、場所、およびorganizationalPersonがdc属性の包含を可能にしないのでこれらのクラスのインスタンスにdcObject[1]などの補助のオブジェクトのクラスを使用しなければならないことに注意してください。)
Grimstad, et. al. Informational [Page 13] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[13ページ]のRFC2377
5.2.6.1 Name Form for Domain Objects
5.2.6.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木のiso.org.dod.internet.directory.NameForm枝の下にこのグループにおけるOIDsがある、(1.3 .6 .1 .1 .2)。
( 1.3.6.1.1.2.1
NAME domainNameForm
OC domain
MUST dc )
(.6.1.1.2.1NAME domainNameForm OCドメインがdcしなければならない1.3)
The domainNameForm name form indicates that objects of structural object class domain have their RDN constructed from a value of the attribute dc.
形成というdomainNameForm名は、構造的なオブジェクトクラスドメインのオブジェクトで属性dcの値からそれらのRDNを組み立てるのを示します。
5.2.6.2 Name Form for Organization Objects
5.2.6.2 組織オブジェクトのための名前フォーム
( 1.3.6.1.1.2.2
NAME dcOrganizationNameForm
OC organization
MUST dc )
(.6.1.1.2.2NAME dcOrganizationNameForm OC組織がdcしなければならない1.3)
The dcOrganizationNameForm name form indicates that objects of structural object class organization have their RDN constructed from a value of the attribute dc.
形成というdcOrganizationNameForm名は、構造的なオブジェクトクラス組織の目的で属性dcの値からそれらのRDNを組み立てるのを示します。
5.2.6.3 Name Form for Organizational Unit Objects
5.2.6.3 組織的なユニットオブジェクトのための名前フォーム
( 1.3.6.1.1.2.3
NAME dcOrganizationalUnitNameForm
OC organizationalUnit
MUST dc )
(1.3、.6、.1、.1、.3NAME dcOrganizationalUnitNameForm OC organizationalUnitがdcしなければならない.2)
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 場所オブジェクトのための名前フォーム
( 1.3.6.1.1.2.4
NAME dcLocalityNameForm
OC locality
MUST dc )
(.6.1.1.2.4NAME dcLocalityNameForm OC場所がdcしなければならない1.3)
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を組み立てるのを示します。
Grimstad, et. al. Informational [Page 14] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[14ページ]のRFC2377
5.2.6.5 Name Form for Organizational Person Objects
5.2.6.5 組織的な人のオブジェクトのための名前フォーム
( 1.3.6.1.1.2.5
NAME uidOrganizationalPersonNameForm
OC organizationalPerson
MUST uid )
(1.3、.6、.1、.1、.5NAME uidOrganizationalPersonNameForm OC organizationalPersonがuidしなければならない.2)
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.
このプランは多くの有意義な論議の間に現れました、特にデヴィッドChadwick、ジョン・デール、ジョーGajewski、マーク・ジャクソン、ライアン・モウツ、トム・スペンサー、およびクリス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.
[1]Kille、S.、ウォール、M.、グリムスター、A.、ヒューバー、R.、およびS.Sataluri、「LDAP分類名にドメインを使用します」、RFC2247(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] バーカー、P.、S.Kille、および「コサインとインターネットX.500図式」、RFC1274、11月1991日
[4] The North American Directory Forum, "A Naming Scheme for
c=US", RFC 1255, September 1991.
[4] 北米のディレクトリフォーラム、「cの命名体系は米国と等しい」RFC1255、1991年9月。
[5] The North American Directory Forum, "NADF Standing Documents:
A Brief Overview", RFC 1417, February 1993.
[5] 北米のディレクトリフォーラム、「NADF地位は以下を記録します」。 「簡潔な概要」、RFC1417、1993年2月。
[6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.
[6]YeongとW.とハウズ、T.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[7] ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
Grimstad, et. al. Informational [Page 15] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[15ページ]のRFC2377
[8] Kille, S., "A String Representation of Distinguished Names",
RFC 1779, March 1995.
[8]Kille、S.、「分類名のストリング表現」、RFC1779、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] ウォール、M.、Kille、S.、およびT.ハウズ、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。
[10] Wahl, M., "A Summary of the Pilot X.500 Schema for use
in LDAPv3", Work in Progress.
[10] ウォール、M.、「使用のためのLDAPv3"のPilot X.500 Schema、ProgressのWorkのSummary。」
[11] Wahl, M., "A Summary of the X.500 User Schema for use with
LDAPv3", RFC 2256, December 1997.
[11] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500 User SchemaのSummary。」
[12] Howes, T., and M. Wahl, "Referrals and Knowledge References
in LDAP Directories", Work in Progress.
[12] ハウズ、T.、およびM.ウォール、「LDAPディレクトリにおける紹介と知識参照」は進行中で働いています。
[13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
1997年12月の[13] ハウズ、T.とM.スミス、「LDAP URL形式」RFC2255。
[14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[14] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[15] Smith, M., "Definition of the inetOrgPerson Object Class",
Work in Progress.
[15] スミス、M.、「inetOrgPersonオブジェクトのクラスの定義」、処理中の作業。
Grimstad, et. al. Informational [Page 16] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[16ページ]のRFC2377
12. Authors' Addresses
12. 作者のアドレス
Al Grimstad AT&T Room 1C-429, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
アルグリムスターAT&T Room1C429、101Crawfordsコーナー道路Holmdel、ニュージャージー07733-3030米国
EMail: alg@att.com
メール: alg@att.com
Rick Huber AT&T Room 1B-433, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
リックヒューバーAT&T余地の1B-433、101Crawfordsが道路Holmdel、ニュージャージー07733-3030米国を追い詰めます。
EMail: rvh@att.com
メール: rvh@att.com
Sri Sataluri Lucent Technologies Room 4D-335, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
様のSataluriルーセントテクノロジーズ部屋4D-335、101Crawfordsが道路Holmdel、ニュージャージー07733-3030米国を追い詰めます。
EMail: srs@lucent.com
メール: srs@lucent.com
Mark Wahl Critical Angle Inc. 4815 W Braker Lane #502-385 Austin, TX 78759 USA
マークウォール臨界角株式会社4815W Braker Laneテキサス78759#502-385オースチン(米国)
EMail: M.Wahl@critical-angle.com
メール: M.Wahl@critical-angle.com
Grimstad, et. al. Informational [Page 17] RFC 2377 A Directory Naming Plan September 1998
etグリムスター、アル。 プラン1998年9月を命名する1ディレクトリあたり情報[17ページ]のRFC2377
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 18]
etグリムスター、アル。 情報[18ページ]
一覧
スポンサーリンク
