Network Working Group R. Hedberg
Request for Comment: 2657 Catalogix
Category: Experimental August 1999
LDAPv2 Client vs. the Index Mesh
Status of this 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.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
RFC 1777に従って実装としてのLDAPv2クライアントは、[1]の紹介には何の概念がありません。一般的なインデックスプロトコル[2]で定義されているようなクライアントとインデックスメッシュ間の統合は、多額の紹介に依存するため、特殊な方法で処理する必要があります。この文書では、これを実行する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.
一般的なインデックスプロトコル（CIP）の開発中に、基礎的前提の一つは、クライアントとインデックスメッシュ・サーバーの間の相互作用は、[1]重く紹介の通過に依存するであろうということでした。この機能が欠けているのLDAPv2などのプロトコル[2]は、いくつかの手段でそれを補償する必要があります。このメモで選択した方法は、クライアントに多くのインテリジェンスを追加することです。この決定の背後にある2つの理由があります。まず、これはとインデックスメッシュ、または紹介についての知識を扱うときインテリジェンスは、最終的にクライアントに行かなければならないこと、第二に必要とされる主要な機能拡張ではありません。
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クライアントはインデックスメッシュと対話することができるように起こっている場合は、メッシュは、クライアントに理解できるものとして現れなければなりません。基本的に、これは、インデックスサーバーとそれらに含まれるインデックスの定義されたディレクトリ情報ツリー（DIT）における[3,4]構造及びこの文脈において有用であることが証明されているオブジェクトクラスと属性タイプのセットを表すから成ります。
Object class descriptions are written according to the BNF defined in [5].
オブジェクトクラス記述は、[5]で定義されたBNFに従って書かれています。
The cIPIndex objectClass, if present in a entry, allows it to hold one indexvalue and information connected to this value.
cIPIndexオブジェクトクラスは、エントリ中に存在する場合、それはこの値に接続された1つのインデックス値と情報を保持することを可能にします。
( 1.2.752.17.3.9 NAME 'cIPIndex' SUP 'top' STRUCTURAL MUST ( extendedDSI $ idx ) MAY ( indexOCAT ) )
（1.2.752.17.3.9 NAME 'cIPIndex' SUP '上' STRUCTURAL MUST（extendedDSI $ IDX）MAY（indexOCAT））
The cIPDataSet objectClass, if present in a entry, allows it to hold information concerning one DataSet.
cIPDataSetオブジェクトクラスは、エントリ中に存在する場合、それが1つのデータセットに関する情報を保持することを可能にします。
( 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.10 NAME 'cIPDataSet' SUP '上' STRUCTURAL MUST（DSI $検索ベース）MAY（indexOCAT $説明$索引タイプ$のaccessPoint $はprotocolVersion $ polledBy $ updateIntervall $ securityOption $ supplierURI $ consumerURI $ baseURIを$ attributeNamespace $ consistencyBase））
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、基底URI、DSIは、インデックスサーバーにアクセスするクライアントによって使用されています。他の属性（アクセスポイント、はprotocolVersion、polledBy、updateIntervall、consumerURI、supplierURIとsecurityOption、attributeNamespace、consistencyBase）は、サーバとの相互作用にサーバーでの使用のためにすべてです。
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.752.17.1.20 NAME 'IDX' 平等caseIgnoreIA5Match SYNTAX IA5String単一値）
DataSet Identifier, a unique identifier for one particular set of information. This should be an OID, but stored in a stringformat.
データセット識別子、情報の特定の一組の一意の識別子。これはOIDであってもよいが、stringformatに保存されている必要があります。
( 1.2.752.17.1.21 NAME 'dSI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.21 NAME 'DSI' 平等caseIgnoreIA5Match SYNTAX IA5String）
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属性を使用して、このエントリに格納されるデータのタイプを記述する。情報は、空間、次いでとattributeType名に続くオブジェクトクラス名として記憶されています。ホワイトページの情報を扱う典型的な例は、「人のcn」になります。
( 1.2.752.17.1.28 NAME 'indexOCAT' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.28 NAME 'indexOCAT' 平等caseIgnoreIA5Match SYNTAX IA5String）
A URI describing which protocols, hostnames and ports should be used by an indexserver to interact with servers carrying indexinformation representing this dataSet.
URIは、このデータセットを表すインデックス情報を担持するサーバと対話するためのIndexServerによって使用されるべきプロトコル、ホスト名およびポートを記述する。
( 1.2.752.17.1.22 NAME 'supplierURI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.22 NAME 'supplierURI' 平等caseIgnoreIA5Match SYNTAX IA5String）
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です。クライアントがLDAP以外に多くのアクセスプロトコルについて知っている場合は、1つは、他のURI構文を想定することができ、そしてクライアントとサーバの間の相互作用は、何らかの理由で紹介を使用することはできません。
( 1.2.752.17.1.26 NAME 'baseURI' EQUALITY caseExactIA5Match SYNTAX IA5String )
（1.2.752.17.1.26 NAME 'BASEURIの品質caseExactIA5Match SYNTAX IA5String）
At present, the Common Indexing Protocol version should be 3.
現在では、一般的なインデックスプロトコルバージョンは3でなければなりません。
( 1.2.752.17.1.27 NAME 'protocolVersion' EQUALITY numericStringMatch SYNTAX numericString )
（1.2.752.17.1.27 NAME 'はprotocolVersion' 平等numericStringMatch SYNTAX numericString）
The type of index Object that is used to pass around index information.
インデックス情報の周りに渡すために使用される索引オブジェクトのタイプ。
( 1.2.752.17.1.29 NAME 'cIPIndexType' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.29 NAME 'cIPIndexType' 平等caseIgnoreIA5Match SYNTAX IA5String）
The Distinguished Name of Index servers that polls data from this indexserver.
こののIndexServerからポーリングデータインデックスサーバーの識別名。
( 1.2.752.17.1.30 NAME 'polledBy' EQUALITY distinguishedNameMatch SYNTAX DN )
（1.2.752.17.1.30 NAME 'polledBy' 平等distinguishedNameMatch SYNTAX DN）
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.752.17.1.31名 'updateIntervall' 平等numericStringMatch SYNTAX numericString単一値）
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.752.17.1.32 NAME 'securityOption' 平等caseIgnoreIA5Match SYNTAX IA5String単一値）
DataSet Identifier possibly followed by a space and a taglist, the later as specified by [6].
データセット識別子は、おそらく[6]で指定された空間とタグリスト、後に続きます。
( 1.2.752.17.1.33 NAME 'extendedDSI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.33 NAME 'extendedDSI' 平等caseIgnoreIA5Match SYNTAX IA5String）
A URI describing which means a server can accept indexinformation. An example being a mailto URI for MIME email based index transport.
URIは、サーバーがインデックス情報を受け入れることができることを意味している記述する。例では、MIME電子メールベースのインデックス輸送のためのmailto URIています。
( 1.2.752.17.1.34 NAME 'consumerURI' EQUALITY caseExactIA5Match SYNTAX IA5String )
（1.2.752.17.1.34 NAME 'consumerURI' 平等caseExactIA5Match SYNTAX IA5String）
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 NAME 'attributeNamespace' 平等caseExactIA5Match SYNTAX IA5String）
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 NAME 'consistencyBase' 平等caseExactIA5Match SYNTAX IA5String）
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.
インデックスメッシュとクライアントの相互作用はかなり明確に定義されたアクションのカップルで構成されています。最初はインデックスメッシュを横断し、最終的に元のデータを保持するサーバを照会し、その後、で開始する適切なインデックスを検索しています。何をここで議論されることは、それが実際にどのように実装されるかDITのクライアントの知覚は、議論されていないであることを、このテキストを読むときに注意してください。
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 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.
このアプローチは、インデックスメッシュに参加者をすべてのインデックスサーバーはタイプcIPDataSetのエントリによって、DITで表現されているという事実に依存し、最も重要な相対識別名（RDN）がとattributeType DSIを持っている識別名（DN）を持ちます。したがって、から検索を開始するために、適切なのIndexServerを見つけることがobjectClassのcIPIndexObjectを持つオブジェクトに適した場所でDITの検索の問題です。すべての見つかったエントリは、記述値だけでなく、indexOCAT値を調べることによって評価することができます。説明文字列は、インデックスサーバーは、インデックスが何であるかを説明し、人間が読める形式で理解しやすい文章でなければなりません。そのような文字列の例は、「このインデックスは、電子メールアカウントを持っているスウェーデンの大学や大学カレッジでは、全従業員を対象」とすることもできます。 indexOCAT属性は、エントリのどの種類とそのインデックス情報が放ったこれらのエントリ内の属性に関する情報を提供します。 indexOCAT属性値が「人のcn」であれば、例えば、一つは、これは役割以上の者ではなくオーバー指数であり、それがインデックス化された属性のcommonNameであることをことを推測することができます。
Each index server has its information represented in the DIT as a very flat tree. In fact, it is only one level deep.
各インデックスサーバーは、非常にフラットなツリーとしてDITに表され、その情報を持っています。実際には、それが唯一のレベルの深さです。
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 / | \ / | \ / | \ 0 0 cIPDataSetエントリcIPIndexエントリこのサーバは、こののIndexServerからインデックスを集めていることがあること、各指標値のための各データセット1について1。持っています。
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.
検索は、検索のセットで構成されます。ユーザーが探しているものと一致するindexvalueが含まれているインデックスのエントリを検索している第一、第二はextendedDSIにDSI情報に基づいて検索が最初の検索から返された属性値を。 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の情報は、おそらく時間をかけて非常に安定したままになりますので、この情報は、キャッシングに非常によく適しています。この段階で関与つ以上のデータセットがある場合は、ユーザー・インターフェースはを続行するかを選択する際にユーザーを支援するための記述値を使用する場合があります。データセットの検索ベース値の内容は、それが別のインデックスサーバ（DNの最も重要な部分は、DSIの属性である）、または、それはエンドサーバである場合を表しているかどうかをクライアントに伝えます。
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エントリを返す場合、使用する適切なフィルタは、＆（」かもしれない|（CN = * ROLAND *）（CN = ROLAND *）（CN = * ROLAND））（オブジェクトクラス=人）」。検索処理の完全な例は、付録Aに記載されています
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の中に存在するセキュリティ機能を増強または減少のいずれか何も追加しません。
As with security, this memo neither enhances or diminishes the handling of internationalization in LDAPv2.
セキュリティと同様に、このメモはどちらも増強またはのLDAPv2における国際化の取扱いを減少させます。
[1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[1]永、W.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル"、RFC 1777、1995年3月。
[2] Allen, J. and M. Mealling "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[2]アレン、J.とM. Mealling "共通インデックスプロトコル（CIP）のアーキテクチャ"、RFC 2651、1999年8月。
[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 JTC 1 / 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）：属性の構文定義"、RFC 2252、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.ワール、 "共通インデックスプロトコルにおける使用のためのタグ付きインデックスオブジェクト"、RFC 2654、1999年8月。
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo, Norway
ローランドヘドバーグCatalogix Dalsveien 53 0387オスロ、ノルウェー
Phone: +47 23 08 29 96 EMail: roland@catalogix.ac.se
電話：+47 23 08 29 96 Eメール：roland@catalogix.ac.se
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.
セッションの元の質問は、スウェーデンの「ウメオ大学」で働いている名前、「ローランドヘドバーグ」によって人物の電子メールアドレスを見つけることです。
Step 1.
ステップ1。
A singlelevel search with the baseaddress "c=SE" and the filter "(objectclass=cipDataset)" was issued.
BASEADDRESS「C = SE」およびフィルタとsinglelevel検索は「（オブジェクトクラス= cipDataset）」が発行されました。
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：indexOCAT DSI = 1.2.752.17.5.0、C = SEのDSI = 1.2.752.17.5.0説明= "スウェーデンの高等教育の中emailaddressesを持つ従業員の索引" = "CNの人" cIPIndexType = "X-タグ付けされたインデックス-1" ;検索ベース= "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：indexOCAT = "CN人" cIPIndexType = "Xタグインデックス-1" DSI = 1.2.752.23.1.3、C = SE DSI = 1.2.752.23.1.3説明= "スウェーデン弁護士に対する索引"。検索ベース= "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.
最初のインデックスは興味深い人口をカバーするように見えたので、BASEADDRESS「DSI = 1.2.752.17.5.0、C = SE」とフィルタ「（|（IDX =ローランド）（IDX =ヘドバーグ））」との単一レベルの検索がしました発行済み。
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 = 1.2.752.17.5.0、C = SE IDX =ローランド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=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,1066 extendedDSI = 1.2.752.17.5.10 473,512,636,777,1350 extendedDSI = 1.2.752.17.5.14 84112143200 extendedDSI = 1.2.752.17.5.15 1890年から1912年extendedDSI = 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.
二つのベースレベル検索、 "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（オブジェクトクラス= 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：= 1.2.752.17.5.10 DSI、DSI = 1.2.752.17.5.0、C = SE DSI = 1.2.752.17.5.10説明= "ウメオ大学、スウェーデンの従業員" indexOCAT = "人のcn" 検索ベース=「0 =ウメオ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：= 1.2.752.17.5.14 DSI、DSI = 1.2.752.17.5.0、C = SE DSI = 1.2.752.17.5.14説明= "ルンド大学の従業員、スウェーデン" indexOCAT = "人のcn" 検索ベース=「0 = 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.5.10」に進むことが最善として選ばれました。検索ベースの属性値から、ベース・サーバであることは明らかでした。クエリは、今多少修正しなければなりません。一つの可能性はbaseobjectでクエリを発行するだろう「O =ウメオUniversitet、C = SE」とフィルタ「（＆（CN =ローランドヘドバーグ）（オブジェクトクラス=人））」
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。