RFC2657 日本語訳
2657 LDAPv2 Client vs. the Index Mesh. R. Hedberg. August 1999. (Format: TXT=19251 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hedberg Request for Comment: 2657 Catalogix Category: Experimental August 1999
コメントを求めるワーキンググループR.ヘドバーグの要求をネットワークでつないでください: 2657年のCatalogixカテゴリ: 実験的な1999年8月
LDAPv2 Client vs. the Index Mesh
LDAPv2クライアント対インデックスメッシュ
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
LDAPv2 clients as implemented according to RFC 1777 [1] have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol [2], heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this.
RFC1777[1]によると、実行されるLDAPv2クライアントは紹介のときに分かりません。 そのようなクライアントとIndex Meshの間の統合は、Common Indexingプロトコル[2]によって定義されるように大いに紹介によって、したがって、特別な方法で扱われる必要があります。 このドキュメントはこれをする1つの可能な方法を定義します。
1. Background
1. バックグラウンド
During the development of the Common Indexing Protocol (CIP), one of the underlying assumptions was that the interaction between clients and the Index Mesh Servers [1] would heavily depend on the passing of referrals. Protocols like LDAPv2 [2] that lack this functionality need to compensate for it by some means. The way chosen in this memo is to add more intelligence into the client. There are two reasons behind this decision. First, this is not a major enhancement that is needed and secondly, that the intelligence when dealing with the Index Mesh, with or the knowledge about referrals, eventually has to go into the client.
Common Indexingプロトコル(CIP)の開発の間、基本的な仮定の1つはクライアントとIndex Mesh Servers[1]との相互作用が大いに紹介の通過であることによるだろうということでした。 この機能性を欠いているLDAPv2[2]のようなプロトコルは、どうでもそれを補う必要があります。 このメモで選ばれた道は、より多くの知性をクライアントに加えることです。 この決定の後ろに2つの理由があります。 最初に、これ、Index Meshに対処するとき、必要であるa主要な増進と第二にそれが知性でない、または、紹介に関する知識、結局、クライアントに入るために持っています。
2. The clients view of the Index Mesh
2. Index Meshのクライアント視点
If a LDAPv2 client is going to be able to interact with the Index Mesh, the Mesh has to appear as something that is understandable to the client. Basically, this consists of representing the index servers and their contained indexes in a defined directory information tree (DIT) [3,4] structure and a set of object classes and attribute types that have been proven to be useful in this context.
LDAPv2クライアントがIndex Meshと対話できるなら、Meshはクライアントにとって、何か理解できるものとして現れなければなりません。 基本的に、これは(DIT)[3、4]が構造化する定義されたディレクトリ情報木とこのような関係においては役に立つと立証された物のクラスと属性タイプのセットでインデックスサーバとそれらの含まれたインデックスを表すのから成ります。
Hedberg Experimental [Page 1] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[1ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
2.1 The CIP Object Classes
2.1 CIP物のクラス
Object class descriptions are written according to the BNF defined in [5].
[5]で定義されたBNFによると、物のクラス記述は書かれています。
2.1.1 cIPIndex
2.1.1 cIPIndex
The cIPIndex objectClass, if present in a entry, allows it to hold one indexvalue and information connected to this value.
エントリーに存在しているなら、cIPIndex objectClassはそれを1indexvalueと情報がこの値に接続されるままにさせます。
( 1.2.752.17.3.9
NAME 'cIPIndex'
SUP 'top'
STRUCTURAL
MUST ( extendedDSI $ idx )
MAY ( indexOCAT )
)
(1.2.752.17.3.9NAME'cIPIndex'SUP'先端'STRUCTURAL MUST(extendedDSI$idx)5月(indexOCAT))
2.1.2 cIPDataSet
2.1.2 cIPDataSet
The cIPDataSet objectClass, if present in a entry, allows it to hold information concerning one DataSet.
エントリーに存在しているなら、cIPDataSet objectClassはそれに1DataSetに関して情報を保持させます。
( 1.2.752.17.3.10
NAME 'cIPDataSet'
SUP 'top'
STRUCTURAL
MUST ( dSI $ searchBase )
MAY ( indexOCAT $ description $ indexType $
accessPoint $ protocolVersion $ polledBy $
updateIntervall $ securityOption $
supplierURI $ consumerURI $ baseURI $
attributeNamespace $ consistencyBase
)
)
(1.2.752.17.3.10NAME'cIPDataSet'SUP'先端'STRUCTURAL MUST(dSI$searchBase)5月(indexOCAT$記述$indexType$accessPoint$protocolVersion$polledBy$updateIntervall$securityOption$supplierURI$consumerURI$baseURI$attributeNamespace$consistencyBase))
2.2 The CIP attributeTypes
2.2 CIP attributeTypes
The attributes idx, indexOCAT, extendedDSI, description, cIPIndexType, baseURI, dSI are used by a client accessing the index server. The other attributes (accesspoint, protocolVersion, polledBy, updateIntervall, consumerURI, supplierURI and securityOption, attributeNamespace, consistencyBase) are all for usage in server to server interactions.
属性idx、indexOCAT、extendedDSI、記述、cIPIndexType、baseURI、dSIはインデックスサーバにアクセスするクライアントによって使用されます。他の属性(accesspointとprotocolVersionとpolledByとupdateIntervallとconsumerURIとsupplierURIとsecurityOption、attributeNamespace、consistencyBase)はサーバ相互作用へのすべてサーバの用法のためのものです。
Hedberg Experimental [Page 2] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[2ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
2.2.1 idx
2.2.1 idx
The index value, normally used as part of the RDN.
通常、RDNの一部として使用されるインデックス値。
( 1.2.752.17.1.20
NAME 'idx'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
SINGLE-VALUE
)
(1.2の平等のcaseIgnoreIA5Matchの構文のIA5Stringのただ一つの.752.17.1.20名前'idx'価値)
2.2.2 dSI
2.2.2 dSI
DataSet Identifier, a unique identifier for one particular set of information. This should be an OID, but stored in a stringformat.
DataSet Identifier、1つの特定の情報のためのユニークな識別子。 これは、OIDにもかかわらず、stringformatに格納されているべきです。
( 1.2.752.17.1.21
NAME 'dSI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.21名の'dSI'平等caseIgnoreIA5Match構文IA5String)
2.2.3 indexOCAT
2.2.3 indexOCAT
Describes the type of data that is stored in this entry, by using objectcClasses and attributeTypes. The information is stored as a objectClass name followed by a space and then an attributeType name. A typical example when dealing with whitepages information would be "person cn".
このエントリーにobjectcClassesとattributeTypesを使用することによって格納されるデータのタイプについて説明します。 objectClass名がスペースと次に、attributeType名で従ったので、情報は格納されます。 whitepages情報に対処するとき、典型的な例は「人のcn」でしょう。
( 1.2.752.17.1.28
NAME 'indexOCAT'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.28名の'indexOCAT'平等caseIgnoreIA5Match構文IA5String)
2.2.5 supplierURI
2.2.5 supplierURI
A URI describing which protocols, hostnames and ports should be used by an indexserver to interact with servers carrying indexinformation representing this dataSet.
どのプロトコル、ホスト名、およびポートについて説明するURIは、このdataSetを表すindexinformationを運ぶサーバと対話するのにindexserverによって使用されるはずです。
( 1.2.752.17.1.22
NAME 'supplierURI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.22名の'supplierURI'平等caseIgnoreIA5Match構文IA5String)
Hedberg Experimental [Page 3] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[3ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
2.2.6 baseURI
2.2.6 baseURI
The attribute value for this attribute is a LDAP URI. One can envisage other URI syntaxes, if the client knows about more access protocols besides LDAP, and the interaction between the client and the server can not use referrals for some reason.
この属性のための属性値はLDAP URIです。 人は他のURI構文を考えることができます、クライアントがLDAP以外により多くのアクセス・プロトコルに関して知って、クライアントとサーバとの相互作用がある理由で紹介を使用できないなら。
( 1.2.752.17.1.26
NAME 'baseURI'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.26名の'baseURI'平等caseExactIA5Match構文IA5String)
2.2.7 protocolVersion
2.2.7 protocolVersion
At present, the Common Indexing Protocol version should be 3.
現在のところ、Common Indexingプロトコルバージョンは3であるべきです。
( 1.2.752.17.1.27
NAME 'protocolVersion'
EQUALITY numericStringMatch
SYNTAX numericString
)
(1.2.752.17.1.27名の'protocolVersion'平等numericStringMatch構文numericString)
2.2.8 cIPIndexType
2.2.8 cIPIndexType
The type of index Object that is used to pass around index information.
回すのにおいて使用されたインデックスObjectのタイプは情報に索引をつけます。
( 1.2.752.17.1.29
NAME 'cIPIndexType'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.29名の'cIPIndexType'平等caseIgnoreIA5Match構文IA5String)
2.2.10 polledBy
2.2.10 polledBy
The Distinguished Name of Index servers that polls data from this indexserver.
このindexserverからのデータに投票するIndexサーバのDistinguished Name。
( 1.2.752.17.1.30
NAME 'polledBy'
EQUALITY distinguishedNameMatch
SYNTAX DN
)
(1.2.752.17.1.30名の'polledBy'平等distinguishedNameMatch構文DN)
Hedberg Experimental [Page 4] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[4ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
2.2.11 updateIntervall
2.2.11 updateIntervall
The maximum duration in seconds between the generation of two updates by the supplier server.
供給者サーバによる2つのアップデートの世代の間の秒の最大の持続時間。
( 1.2.752.17.1.31
Name 'updateIntervall'
EQUALITY numericStringMatch
SYNTAX numericString
SINGLE-VALUE
)
(1.2の平等のnumericStringMatchの構文のnumericStringのただ一つの.752.17.1.31名前'updateIntervall'価値)
2.2.12 securityOption
2.2.12 securityOption
Whether and how the supplier server should sign and encrypt the update before sending it to the consumer server.
消費者サーバにそれを送る前に、供給者サーバは、どのようにアップデートにコード化してサインして、コード化するべきであるか。
( 1.2.752.17.1.32
NAME 'securityOption'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
SINGLE-VALUE
)
(1.2の平等のcaseIgnoreIA5Matchの構文のIA5Stringのただ一つの.752.17.1.32名前'securityOption'価値)
2.2.13 extendedDSI
2.2.13 extendedDSI
DataSet Identifier possibly followed by a space and a taglist, the later as specified by [6].
DataSet Identifierはことによるとスペースとtaglist、指定されるとしての[6]による後で続きました。
( 1.2.752.17.1.33
NAME 'extendedDSI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.33名の'extendedDSI'平等caseIgnoreIA5Match構文IA5String)
2.2.14 consumerURI
2.2.14 consumerURI
A URI describing which means a server can accept indexinformation. An example being a mailto URI for MIME email based index transport.
どれがサーバを意味するかを説明するURIはindexinformationを受け入れることができます。 MIMEメールのためのmailto URIである例はインデックス輸送を基礎づけました。
( 1.2.752.17.1.34
NAME 'consumerURI'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.34名の'consumerURI'平等caseExactIA5Match構文IA5String)
Hedberg Experimental [Page 5] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[5ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
2.2.15 attributeNamespace
2.2.15 attributeNamespace
Any consumer supplier pair has to agree on what attribute that should be used and also possibly the meaning of the attributenames. The value of this attribute should, for example, be a URI pointing to a document wherein the agreement is described.
どんな消費者供給者組もそれがどんな属性で使用されるべきであるか、そして、ことによるともattributenamesの意味に同意しなければなりません。 例えば、この属性の値は協定が説明されるドキュメントを示すURIであるべきです。
( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY
caseExactIA5Match SYNTAX IA5String
)
(1.2.752.17.1.35名の'attributeNamespace'平等caseExactIA5Match構文IA5String)
2.2.16 consistencyBase
2.2.16 consistencyBase
This attribute is specifically used by consumer supplier pairs that use the tagged index object [6].
この属性はタグ付けをされたインデックス物[6]を使用する消費者供給者組によって明確に使用されます。
( 1.2.752.17.1.36
NAME 'consistencyBase'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
(1.2.752.17.1.36名の'consistencyBase'平等caseExactIA5Match構文IA5String)
3. The interaction between a client and the Index Mesh
3. クライアントとIndex Meshとの相互作用
A client interaction with the Index Mesh consists of a couple of rather well defined actions. The first being to find a suitable index to start with, then to transverse the Index Mesh and finally to query the servers holding the original data. Note when reading this text that what is discussed here is the client's perception of the DIT, how it is in fact implemented is not discussed.
Index Meshとのクライアント相互作用は2、3のかなりよく定義された動作から成ります。 1番目がまず第一に適当なインデックスを見つけることであり、Index Meshと最終的に質問への横向きへのその時はオリジナルのデータを保持するサーバです。 議論するものがここにある本稿にクライアントのDITの認知を読み込んで、いつそれがどう事実上実行されるかについて議論しないかに注意してください。
3.1 Finding a Index Mesh
3.1 インデックスがメッシュであることがわかること。
This approach depends on the fact that every index server partaking in an Index Mesh is represented in the DIT by a entry of the type cIPDataSet, and has a distinguished name (DN) which most significant relative distinguished name (RDN) has the attributetype dSI. Therefore, finding a suitable indexserver to start the search from is a matter of searching the DIT at a suitable place for objects with the objectClass cIPIndexObject. Every found entry can then be evaluated by looking at the description value as well as the indexOCAT value. The description string should be a human readable and understandable text that describes what the index server is indexing. An example of such a string could be, "This index covers all employees at Swedish Universities and University Colleges that has an email account". The indexOCAT attribute supplies information about which kind of entries and which attributes within these entries that the index information has emanated from. For example, if the
このアプローチはIndex Meshに参加するあらゆるインデックスサーバがDITにタイプcIPDataSetのエントリーで表されて、それの最も重要な相対的な分類名にはattributetype dSIがある(RDN)分類名(DN)を持っているという事実に依存します。 したがって、適当なindexserverを検索を始める見つけるのは、物のためにobjectClass cIPIndexObjectと共に適当な場所をDITを捜す問題です。 そして、indexOCAT値と同様に記述値を見ることによって、あらゆる備え付けることのエントリーを評価できます。 記述ストリングはインデックスサーバが索引をつけていることについて説明する人間の読み込み可能で理解できるテキストであるべきです。 そのようなストリングに関する例は「このインデックスはメールがそれで説明するスウェーデンの大学と大学大学に全社員を覆っている」ということであるかもしれません。 indexOCAT属性はインデックス情報が発したこれらのエントリーの中でエントリーのどの種類とどの属性に関して情報を提供するか。 例えば
Hedberg Experimental [Page 6] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[6ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
indexOCAT attribute value is "person cn", one can deduce that this is an index over persons and not over roles, and that it is the attribute commonName that is indexed.
indexOCAT属性値は「人のcn」、ものが、役割の上で推論するのではなく、人々の上でこれがインデックスであると推論できて、それが索引をつけられる属性commonNameであるということです。
3.2 Searching the mesh
3.2 メッシュを捜すこと。
Each index server has its information represented in the DIT as a very flat tree. In fact, it is only one level deep.
それぞれのインデックスサーバで、非常に平坦な木としてDITに情報を表します。 事実上、それは深く1つのレベルにすぎません。
0 Indexservers cIPDataSet
/|\
/ | \
/ | \
0 0
cIPDataSet entries cIPIndex entries
one for each DataSet one for each index value
that this server has that this indexserver
gathered indexes from. has.
0 Indexservers cIPDataSet/|\ / | \ / | それぞれのための各DataSet1のための0 0cIPDataSetエントリーcIPIndexエントリー1つはこのサーバではこれほどそんなによりindexserverな集まっているインデックスが来ている値に索引をつけます。\. 持っています。
A search then consists of a set of searches. The first being the search for the index entries that contains an indexvalue that matches what the user is looking for, and the second a search based on the DSI information in the extendedDSI attribute values returned from the first search. In the case of the the cIPIndexType being tagged- index, the taglists should be compared to find which DSI it might be useful to pose further queries to.
そして、検索は1セットの検索から成ります。 まず最初に、インデックスエントリーの検索であり、それはユーザが探しているものに合っているindexvalueを含んでいます、そして、検索がextendedDSI属性値におけるDSI情報に基礎づけた2番目は最初の検索から戻りました。 タグ付けをされたインデックスであるcIPIndexTypeの場合では、taglistsは、さらなる質問を引き起こすのがどのDSIの役に立つかもしれないかわかるために比較されるべきです。
When doing these types of searches, the client should be aware of the fact that the index values disregarding their origin (attributeTypes) always are stored in the index server as values of the idx attribute.
これらのタイプの検索をするクライアントインデックスがそれらの起源を無視しながら評価する事実を知るべきであるとき、(attributeTypes)はidx属性の値としてインデックスサーバにいつも格納されます。
The object of the second search is to get information on the different DataSet involved, and should normally be performed as a read. Since the DataSet information probably will remain quite stable over time, this information lends itself very well to caching. If at this stage there is more than one DataSet involved, the User interface might use the description value to aid the user in choosing which one to proceed with. The content of the searchBase value of the DataSet tells the client whether it represents another index server (the most significant part of the dn is a dSI attribute) or if it is a end server.
2番目の検索の目的が異なったDataSetの情報をかかわらせることであり、aが読んだように通常、実行されるはずです。 DataSet情報が時間がたつにつれてたぶんかなり安定した状態を保つので、この情報はそれ自体をキャッシュに非常によく与えます。 DataSetが伴った1つ以上が現在のところあれば、Userインタフェースは、どれを続けるかを選ぶ際にユーザを支援するのに記述値を使用するかもしれません。 DataSetのsearchBase価値の内容は、別のインデックスサーバを表すかどうかかそれとも(dnの最もかなりの部分はdSI属性です)、それがエンドサーバであるかどうかクライアントに言います。
Hedberg Experimental [Page 7] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[7ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
3.3 Querying the end server
3.3 エンドサーバについて質問すること。
When finally reaching the end server/servers that probably has the sought for information, the information in the indexOCAT attribute can be used to produce an appropriate filter. If a search for "Rol*" in an index having an indexOCAT attribute value of "person cn" returns an idx entry with the idx value of "Roland", then an appropriate filter to use might be "&(|(cn=* roland *)(cn=roland *)(cn=* roland))(objectclass=person)". A complete example of a search process is given in Appendix A.
最終的にエンドサーバ/サーバに達するとき、それには、探すことが情報のためにたぶんあって、適切なフィルタを生産するのにindexOCAT属性における情報は使用できます。 「「」 インデックス有における、「人のcn」のindexOCAT属性値が「ローランド」のidx値があるidxエントリーを返すRol*、次に、使用するのが適切であるフィルタはそうです」と(| (cn=*roland*)(cn=roland*)(cn=*roland))(objectclassは人と等しい)の検索であるなら。」 検索の過程の完全な例はAppendix Aで出されます。
4. Security Considerations
4. セキュリティ問題
Since this memo deals with client behavior, it does not add anything that either enhances or diminishes the security features that exists in LDAPv2.
このメモがクライアントの振舞いに対処するので、それはLDAPv2に存在するセキュリティ機能を高めるか、または減少させる何も加えません。
5. Internationalization
5. 国際化
As with security, this memo neither enhances or diminishes the handling of internationalization in LDAPv2.
セキュリティのように、このメモは、LDAPv2での国際化の取り扱いを機能アップもしませんし、減少もさせません。
6. References
6. 参照
[1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[1]YeongとW.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[2] Allen, J. and M. Mealling "The Architecture of the Common
Indexing Protocol (CIP)", RFC 2651, August 1999.
[2] 1999年8月に「一般的なインデックスプロトコル(CIP)の構造」、RFC2651を荒びきにするアレン、J.、およびM.。
[3] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[3] ディレクトリ: 概念の、そして、モデルの、そして、サービスの概観。 CCITT推薦X.500、1988。
[4] Information Processing Systems -- Open Systems Interconnection --
The Directory: Overview of Concepts, Models and Service. ISO/IEC
JTC 1/SC21; International Standard 9594-1, 1988.
[4] 情報処理システム--オープン・システム・インターコネクション--ディレクトリ: 概念の、そして、モデルの、そして、サービスの概観。 ISO/IEC JTC1/SC21。 国際規格9594-1、1988。
[5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[6] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
Index Object for use in the Common Indexing Protocol", RFC 2654,
August 1999.
[6] ヘドバーグとR.とグリーンブラットとB.とモウツとR.とM.ウォール、「Common Indexingプロトコルにおける使用のためのTagged Index Object」、RFC2654、1999年8月。
Hedberg Experimental [Page 8] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[8ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
7. Author's Address
7. 作者のアドレス
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo, Norway
ローランドヘドバーグCatalogix Dalsveien53 0387オスロ(ノルウェー)
Phone: +47 23 08 29 96 EMail: roland@catalogix.ac.se
以下に電話をしてください。 +47 23 08 29 96はメールされます: roland@catalogix.ac.se
Hedberg Experimental [Page 9] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[9ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
Appendix A - Sample Session
付録A--サンプルセッション
Below is a sample of a session between a LDAPv2 client and an index server mesh as specified in this memo.
以下に、このメモによるLDAPv2クライアントと指定されるとしてのインデックスサーバメッシュとのセッションのサンプルがあります。
The original question of the session is to find the email address of a person by the name, "Roland Hedberg", who is working at "Umea University" in Sweden.
セッションの独創的な問題は名前、スウェーデンで「ウメオ大学」で働いている「ローランド・ヘドバーグ」で人のEメールアドレスを見つけることです。
Step 1.
1を踏んでください。
A singlelevel search with the baseaddress "c=SE" and the filter "(objectclass=cipDataset)" was issued.
baseaddress"c=SE"と「(objectclass=cipDataset)」というフィルタによるsinglelevel検索は発行されました。
The following results were received:
以下の結果を受け取りました:
DN: dSI=1.2.752.17.5.0,c=SE dsi= 1.2.752.17.5.0 description= "index over employees with emailaddresses within Swedish higher education" indexOCAT= "cn person" cIPIndexType= "x-tagged-index-1" ; searchBase= "dsi=1.2.752.17.5.0,c=SE" protocolVersion = 3
DN: 1.2.752.17.5.0.0、c=SE dsi=記述=が「スウェーデンの高等教育の中で従業員の上でemailaddressesで索引をつける」という1.2.752.17.5indexOCAT=「cn人」dSI=cIPIndexTypeは「xはインデックスに何1インチもタグ付けをしたこと」と等しいです。 searchBaseが等しい、「dsiが等しい、1.2 .752 .17 .5 .0、c=SE、」 protocolVersion=3
DN: dSI=1.2.752.23.1.3,c=SE dsi= 1.2.752.23.1.3 description= "index over Swedish lawyers" indexOCAT= "cn person" cIPIndexType= "x-tagged-index-1" ; searchBase= "dsi=1.2.752.23.1.3,c=SE" protocolVersion = 3
DN: 1.2.752.23.1.3.3、c=SE dsi=記述=が「スウェーデン人の弁護士の上で索引をつける」という1.2.752.23.1indexOCAT=「cn人」dSI=cIPIndexTypeは「xはインデックスに何1インチもタグ付けをしたこと」と等しいです。 searchBaseが等しい、「dsiが等しい、1.2 .752 .23 .1 .3、c=SE、」 protocolVersion=3
Step 2.
2を踏んでください。
Since the first index seemed to cover the interesting population, a single level search with the baseaddress "dsi=1.2.752.17.5.0,c=SE" and the filter "(|(idx=roland)(idx=hedberg))" was issued.
dsiは1.2と等しいです。以来最初のインデックスがbaseaddressでおもしろい人口、ただ一つの平らな検索をカバーするように思えた、「.752 .17 .5 .0 」 「(| (idx=roland)(idx=hedberg))」というフィルタが支給されたc=SE。
The following results were received:
以下の結果を受け取りました:
DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE idx= Roland extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024 extendedDSI= 1.2.752.17.5.14 35,78,150,200 extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040 extendedDSI= 1.2.752.17.5.17 17
DN: idxはローランドと等しく、dSIは.0、1.2.752.17.5c=SE idx=ローランドと等しいです。extendedDSIが1.2.752.17.5.10 1,473,612,879と等しく、1024extendedDSIが1.2.752.17.5.14 35と等しく、7815万200extendedDSIが1.2.752.17.5.16 187、2031と等しい、3167、5284、6034-6040extendedDSIは1.2.752.17.5.17 17と等しいです。
Hedberg Experimental [Page 10] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[10ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE idx= Hedberg extendedDSI= 1.2.752.17.5.8 24,548-552,1066 extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350 extendedDSI= 1.2.752.17.5.14 84,112,143,200 extendedDSI= 1.2.752.17.5.15 1890-1912 extendedDSI= 1.2.752.17.5.17 44
DN: idx=ヘドバーグ、dSI=1.2.752.17、.5、ヘドバーグ.0、c=SE idx=extendedDSIは1.2.752.17.5.8 24,548-552と等しく、1066extendedDSIは1.2.752.17.5.10 473,512,636,777と等しく、1350extendedDSIは1.2.752.17.5.14 84,112,143,200 extendedDSI=1.2.752.17.5.15 1890-1912extendedDSI=1.2.752.17.5.17 44と等しいです。
A comparison between the two sets of extendedDSIs shows that two datasets 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named "Roland" and "Hedberg". Therefore, the next step would be to see what the datasets represent. A comparison like this should normally not be left to the user.
そして、extendedDSIsの2セットでの比較がその2つのデータセット1.2.752を示している、.17、.5、.10、1.2 .752 .17 .5 .14 「ローランド」と「ヘドバーグ」という人々を含みます。 したがって、次のステップはデータセットが表すものを見るだろうことです。 通常、このような比較はユーザに任せるはずがありません。
Step. 3
踏んでください。 3
Two baselevel searches, one for "dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and the other for "dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter "(objectclass=cipdataset)" were issued.
2つの基準面検索、1、「dsi=1.2.752.17、.5、.10、dsi=1.2.752、.17、.5、.0、」 もう片方のc=SE、「dsi=1.2.752.17、.5、.14、dsi=1.2.752、.17、.5、.0、c=SE、」 フィルタで、「(objectclass=cipdataset)」は発行されました。
The following results were received:
以下の結果を受け取りました:
DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE dsi= 1.2.752.17.5.10 description= "Employees at Umea University,Sweden" indexOCAT= "person cn" searchBase= "o=Umea Universitet,c=SE"
DN: dSI=1.2.752.17、.5、.10、dSI=1.2.752.17、.5.0、1.2.752.17.5.10c=SE dsi=記述=「ウメオ大学のスウェーデンの従業員」indexOCAT=「人のcn」searchBase=「o=ウメオUniversitet、c=SE」
respectively
それぞれ
DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE dsi= 1.2.752.17.5.14 description= "Employees at Lund University,Sweden" indexOCAT= "person cn" searchBase= "o=Lunds Universitet,c=SE"
DN: dSI=1.2.752.17、.5、.14、1.2.752.17.5.0、1.2.752.17.5.14c=SE dsi=記述=「ランド大学のスウェーデンの従業員」indexOCAT=「人のcn」dSI=searchBase=、「o=Lunds Universitet、c=SE」
Step 4
ステップ4
Based on the descriptions for the two datasets, "1.2.752.17.5.10" was chosen as the best to proceed with. From the searchbase attribute value, it was clear that this was a base server. The query now has to be somewhat modified. One possibility would be to issue a query with the baseobject "o=Umea Universitet,c=SE" and the filter "(&(cn=Roland Hedberg)(objectclass=person))"
2つのデータセットのための記述に基づいて「1.2、.752、.17、0.1インチが続ける中で最も良いものとして選ばれた.5、」 searchbase属性値から、これがベースサーバであったのは明確でした。質問は現在、いくらか変更されていなければなりません。 1つの可能性は「oはウメオUniversitet、c=SEと等しく」て、「((cnはローランド・ヘドバーグと等しいです)(objectclass=人))」というフィルタをbaseobjectとの質問に支給するだろうことです。
Hedberg Experimental [Page 11] RFC 2657 LDAPv2 vs. Index Mesh August 1999
ヘドバーグ実験的な[11ページ]RFC2657LDAPv2対インデックスは1999年8月にかみ合います。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hedberg Experimental [Page 12]
ヘドバーグExperimentalです。[12ページ]
一覧
スポンサーリンク
