[要約] RFC 2657は、LDAPv2クライアントとインデックスメッシュの比較を行い、LDAPv2クライアントの利点と制限を明らかにすることを目的としています。
Network Working Group R. Hedberg
Request for Comment: 2657 Catalogix
Category: Experimental August 1999
LDAPv2 Client vs. the Index Mesh
LDAPV2クライアントとインデックスメッシュ
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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 [1]に従って実装されているLDAPV2クライアントは、紹介に関する概念を持っていません。一般的なインデックス作成プロトコル[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つは、クライアントとインデックスメッシュサーバー[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 ObjectClassは、エントリに存在する場合、この値に接続された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 'top' structural must（extendeddsi $ idx）5月（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 'top' structural must（dsi $ searchbase）5月（indexocat $ description $ cassionpoint $ protocolversion $ protocolversion $ updateintintervall $ securityoption $ supplieruri $ supplierui $ supplierui $ baseuri $属性$属性$属性ベース））
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、拡張DSI、説明、CIPINDEXTYPE、Baseuri、DSIは、インデックスサーバーにアクセスするクライアントが使用します。その他の属性（AccessPoint、Protocolversion、PolledBy、UpdateIntervall、Consumeruri、SupplieruriおよびSecurityOption、AttributeNamesPace、ConsecencyBase）はすべて、サーバーからサーバーへの対話で使用されます。
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' equality caseignoreia5match Syntax ia5string単一価値）
DataSet Identifier, a unique identifier for one particular set of information. This should be an OID, but stored in a stringformat.
データセット識別子、1つの特定の情報セットの一意の識別子。これはOIDである必要がありますが、StringFormatに保存されます。
( 1.2.752.17.1.21 NAME 'dSI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.21 name 'dsi' equality caseignoreia5match構文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と属性タイプを使用して、このエントリに保存されているデータのタイプについて説明します。情報は、オブジェクトクラス名として保存され、その後にスペースと属性名が付いています。ホワイトページ情報を扱う際の典型的な例は、「人CN」です。
( 1.2.752.17.1.28 NAME 'indexOCAT' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.28名「indexocat」equality caseignoreia5match構文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。
( 1.2.752.17.1.22 NAME 'supplierURI' EQUALITY caseIgnoreIA5Match SYNTAX IA5String )
（1.2.752.17.1.22 name 'supplieruri' equality caseignoreia5match構文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以外のアクセスプロトコルを知っている場合、他のURI構文を想像でき、クライアントとサーバーの間の相互作用は何らかの理由で紹介を使用できません。
( 1.2.752.17.1.26 NAME 'baseURI' EQUALITY caseExactIA5Match SYNTAX IA5String )
（1.2.752.17.1.26 name 'baseuri' equality caseexactia5match構文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' equality numericstringmatch構文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名「cipindextype 'equality 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名前「Polledby」等式著作権damematch構文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 name 'updateintervall' equality numericstringmatchシングルバリュー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' equality caseignoreia5match構文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' equality caseignoreia5match構文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' equality caseexactia5match構文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.
消費者のサプライヤーのペアは、使用すべき属性と、おそらく属性の意味に同意する必要があります。この属性の値は、たとえば、契約が記載されている文書を指すURIでなければなりません。
( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY caseExactIA5Match SYNTAX IA5String )
（1.2.752.17.1.35名「astributeNamespace」equality 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 'consecencybase' equality caseexactia5match構文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）が属性DSIを持っている際立った名前（DN）を持っているという事実に依存します。したがって、検索を開始するために適切なIndexServerを見つけることは、ObjectClass CipindExoBjectを使用してオブジェクトに適した場所でDITを検索する問題です。その後、すべての発見されたエントリは、説明値とインデックスキャット値を調べることで評価できます。説明文字列は、インデックスサーバーがインデックス作成しているものを説明する人間の読みやすく理解できるテキストである必要があります。このような文字列の例は、「このインデックスは、電子メールアカウントを持っているスウェーデンの大学や大学の大学のすべての従業員を対象としています」ということです。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で非常にフラットなツリーとして表される情報があります。実際、深さは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.
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つ目は、ユーザーが探しているものに一致するインデックスバリューを含むインデックスエントリの検索であり、2番目は、最初の検索から返された拡張DSI属性値のDSI情報に基づく検索です。cipindextypeがタグ付きインデックスである場合、キャッチリストを比較する必要があります。
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.
これらのタイプの検索を実行する場合、クライアントは、その原点（属性）を無視するインデックス値が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番目の検索のオブジェクトは、関係するさまざまなデータセットに関する情報を取得することであり、通常は読み取りとして実行する必要があります。データセット情報はおそらく時間の経過とともに非常に安定したままであるため、この情報はキャッシュに非常に役立ちます。この段階で複数のデータセットが関係している場合、ユーザーインターフェイスは説明値を使用して、ユーザーがどの進行するかを選択するのを支援する場合があります。データセットの検索ベース値のコンテンツは、クライアントが別のインデックスサーバー（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」のインデックスキャット属性値を持つインデックスで「rol*」の検索が「roland」のidx値を持つidxエントリを返す場合、使用する適切なフィルターは「＆（cn =*」かもしれません。ROLAND *）（CN = ROLAND *）（CN = *ROLAND））（ObjectClass = Person） "。検索プロセスの完全な例は、付録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] Yeong、W.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol」、RFC 1777、1995年3月。
[2] Allen, J. and M. Mealling "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[2] Allen、J.およびM. Mealling「Common Indexing Protocol（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] Wahl、M.、Coulbeck、A.、Howes、T。and S. Kille、「Lightweight Directory Access Protocol（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] Hedberg、R.、Greenblatt、B.、Moats、R。、およびM. Wahl、「共通インデックスプロトコルで使用するタグ付きインデックスオブジェクト」、RFC 2654、1999年8月。
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo, Norway
Roland Hedberg Catalogix Dalsveien 53 0387オスロ、ノルウェー
Phone: +47 23 08 29 96
EMail: 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.
セッションの元の質問は、スウェーデンの「Umea University」で働いている「Roland Hedberg」という名前で人のメールアドレスを見つけることです。
Step 1.
ステップ1。
A singlelevel search with the baseaddress "c=SE" and the filter "(objectclass=cipDataset)" was issued.
Baseaddress "c = se"とフィルター「objectclass = 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: 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
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 = ROLAND）（IDX = Hedberg））を使用した単一レベルの検索がありました。発行済み。
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=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
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.
拡張DSISの2つのセットの比較は、2つのデータセット1.2.752.17.5.10および1.2.752.17.5.14に「Roland」と「Hedberg」という名前の人が含まれていることを示しています。したがって、次のステップは、データセットが何を表すかを確認することです。このような比較は、通常、ユーザーに任されるべきではありません。
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」、もう1つは「DSI = 1.2.752.17.5.14、DSI = 1.2.752.17.5.5、C =se "with the Filter"（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"
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"
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」が進むのに最適なものとして選択されました。SearchBase属性値から、これがベースサーバーであることは明らかでした。クエリをいくらか変更する必要があります。1つの可能性は、BaseObject「O = Umea Universitet、C = SE」およびフィルターでクエリを発行することです。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。