RFC1777 日本語訳
1777 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S.Kille. March 1995. (Format: TXT=45459 bytes) (Obsoletes RFC1487) (Obsoleted by RFC3494) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Yeong
Request for Comments: 1777 Performance Systems International
Obsoletes: 1487 T. Howes
Category: Standards Track University of Michigan
S. Kille
ISODE Consortium
March 1995
Yeongがコメントのために要求するワーキンググループW.をネットワークでつないでください: 国際1777個の言語運用機構が以下を時代遅れにします。 1487年のT.ハウズカテゴリ: 1995年の標準化過程ミシガン大学S.Kille ISODE共同体行進
Lightweight Directory Access Protocol
ライトウェイト・ディレクトリ・アクセス・プロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself.
本書では説明されたプロトコルは、ディレクトリAccessプロトコル(DAP)のリソース要件を被っていない間、X.500ディレクトリへのアクセスを提供するように設計されています。 このプロトコルは、明確にX.500ディレクトリへの対話的なアクセスを簡単な管理利用と読まれて、簡単な状態で提供されるブラウザ利用のときに狙うか、または書くことであり、DAP自身への補数であることを意図します。
Key aspects of LDAP are:
LDAPの特徴は以下の通りです。
- Protocol elements are carried directly over TCP or other transport,
bypassing much of the session/presentation overhead.
- セッション/プレゼンテーションオーバーヘッドの多くを迂回させて、プロトコル要素はTCPか他の輸送の直接上まで運ばれます。
- Many protocol data elements are encoding as ordinary strings (e.g.,
Distinguished Names).
- 要素が普通であるとしてコード化している多くのプロトコルデータが(例えば、Distinguished Names)を結びます。
- A lightweight BER encoding is used to encode all protocol elements.
- 軽量のBERコード化は、すべてのプロトコル要素をコード化するのに使用されます。
1. History
1. 歴史
The tremendous interest in X.500 [1,2] technology in the Internet has lead to efforts to reduce the high "cost of entry" associated with use of the technology, such as the Directory Assistance Service [3] and DIXIE [4]. While efforts such as these have met with success, they have been solutions based on particular implementations and as such have limited applicability. This document continues the efforts to define Directory protocol alternatives but departs from previous efforts in that it consciously avoids dependence on particular
インターネットのX.500[1、2]技術への途方も無く大きな興味は技術の使用に関連づけられた高い「エントリーの費用」を減少させるために取り組みにリードを持っています、ディレクトリAssistance Service[3]やデキシー[4]のように。 これらなどの取り組みが成功を得ている間、それらは、特定の実装に基づくソリューションであり、そういうものとして適用性を制限しています。 このドキュメントは、ディレクトリプロトコル代替手段を定義するために取り組みを続けていますが、意識して特定への依存を避けるので、前の取り組みから出発します。
Yeong, Howes & Kille [Page 1] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[1ページ]RFC1777LDAP行進1995
implementations.
実装。
2. Protocol Model
2. プロトコルモデル
The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, this is accomplished by a client transmitting a protocol request describing the operation to be performed to a server, which is then responsible for performing the necessary operations on the Directory. Upon completion of the necessary operations, the server returns a response containing any results or errors to the requesting client. In keeping with the goal of easing the costs associated with use of the Directory, it is an objective of this protocol to minimize the complexity of clients so as to facilitate widespread deployment of applications capable of utilizing the Directory.
このプロトコルによって採用された一般的なモデルはサーバに対してプロトコル操作を実行しているクライアントのひとりです。 このモデルでは、これは次にディレクトリに必要な操作を実行するのに原因となるサーバに実行されるために操作について説明するプロトコル要求を伝えるクライアントによって達成されます。 必要な操作の完成のときに、サーバはどんな結果も含む応答か誤りを要求しているクライアントに返します。 ディレクトリの使用に関連しているコストを緩和するという目標のために保つのにおいて、それはディレクトリを利用できるアプリケーションの広範囲の展開を容易にするためにクライアントの複雑さを最小にするこのプロトコルの目的です。
Note that, although servers are required to return responses whenever such responses are defined in the protocol, there is no requirement for synchronous behavior on the part of either client or server implementations: requests and responses for multiple operations may be exchanged by client and servers in any order, as long as clients eventually receive a response for every request that requires one.
サーバがそのような応答がプロトコルで定義されるときはいつも、応答を返すのに必要ですが、同期振舞いのための要件が全くクライアントかサーバ実装のどちらか側のないことに注意してください: 順不同なクライアントとサーバで同時併行処理のための要求と応答を交換するかもしれません、クライアントが結局1を必要とするあらゆる要求のための応答を受ける限り。
Consistent with the model of servers performing protocol operations on behalf of clients, it is also to be noted that protocol servers are expected to handle referrals without resorting to the return of such referrals to the client. This protocol makes no provisions for the return of referrals to clients, as the model is one of servers ensuring the performance of all necessary operations in the Directory, with only final results or errors being returned by servers to clients.
クライアントを代表してプロトコル操作を実行するサーバのモデルと一致しています、また、プロトコルサーバがそのような紹介のクライアントへの復帰に頼らないで紹介を扱うと予想されることに注意されることになっています。 このプロトコルはクライアントへの紹介の復帰に備えません、モデルがディレクトリにおける、すべての必要な操作の性能を確実にするサーバの1つであるので、最終的な結果か誤りだけがサーバによってクライアントに返されている状態で。
Note that this protocol can be mapped to a strict subset of the directory abstract service, so it can be cleanly provided by the DAP.
DAPが清潔にそれを提供できるように、厳しい抽象的にディレクトリサービスの部分集合にこのプロトコルを写像できることに注意してください。
3. Mapping Onto Transport Services
3. サービスを輸送に写像します。
This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream. Specifications for two underlying services are defined here, though others are also possible.
このプロトコルは接続指向の、そして、信頼できる輸送をひくように設計されています、八重奏におけるすべての8ビットがデータ・ストリームで重要な状態で。 また、他のものも可能ですが、2つの基本的なサービスのための仕様はここで定義されます。
3.1. Transmission Control Protocol (TCP)
3.1. 通信制御プロトコル(TCP)
The LDAPMessage PDUs are mapped directly onto the TCP bytestream. Server implementations running over the TCP should provide a protocol listener on port 389.
LDAPMessage PDUsは直接TCP bytestreamに写像されます。 TCPをひくサーバ実装はポート389の上でプロトコルリスナーを提供するべきです。
Yeong, Howes & Kille [Page 2] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[2ページ]RFC1777LDAP行進1995
3.2. Connection Oriented Transport Service (COTS)
3.2. 接続は輸送サービスを適応させました。(簡易寝台)
The connection is established. No special use of T-Connect is made. Each LDAPMessage PDU is mapped directly onto T-Data.
接続は確立されます。 Tで接続していることのどんな特別な使用もしません。 各LDAPMessage PDUは直接T-データに写像されます。
4. Elements of Protocol
4. プロトコルのElements
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined as follows:
プロトコル交換の目的のために、すべてのプロトコル操作が一般的な封筒、以下の通り定義されるLDAPMessageでカプセル化されます:
LDAPMessage ::=
SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResponse SearchResponse,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modifyRDNRequest ModifyRDNRequest,
modifyRDNResponse ModifyRDNResponse,
compareDNRequest CompareRequest,
compareDNResponse CompareResponse,
abandonRequest AbandonRequest
}
}
LDAPMessage:、:= 系列{ messageID MessageID; protocolOp選択、bindRequest BindRequest、bindResponse BindResponse、unbindRequest UnbindRequest、searchRequest SearchRequest、searchResponse SearchResponse、modifyRequest ModifyRequest、modifyResponse ModifyResponse、addRequest AddRequest、addResponse AddResponse、delRequest DelRequest、delResponse DelResponse、modifyRDNRequest ModifyRDNRequest、modifyRDNResponse ModifyRDNResponse、compareDNRequest CompareRequest、compareDNResponse CompareResponse、abandonRequest AbandonRequest; }
MessageID ::= INTEGER (0 .. maxInt)
MessageID:、:= 整数(0maxInt)
The function of the LDAPMessage is to provide an envelope containing common fields required in all protocol exchanges. At this time the only common field is a message ID, which is required to have a value different from the values of any other requests outstanding in the LDAP session of which this message is a part.
LDAPMessageの機能はすべてのプロトコル交換で必要である共同耕地を含む封筒を提供することです。 このとき、唯一の共同耕地がメッセージIDです。(そのIDが、このメッセージが部分であるLDAPセッションの未払いのいかなる他の要求の値とも異なった値を持つのに必要です)。
The message ID value must be echoed in all LDAPMessage envelopes encapsulting responses corresponding to the request contained in the LDAPMessage in which the message ID value was originally used.
メッセージID価値が元々使用されたLDAPMessageに含まれた要求に対応する応答をencapsultingしながら、すべてのLDAPMessage封筒でメッセージID価値を反響しなければなりません。
In addition to the LDAPMessage defined above, the following definitions are also used in defining protocol operations:
また、上で定義されたLDAPMessageに加えて、以下の定義はプロトコル操作を定義する際に使用されます:
Yeong, Howes & Kille [Page 3] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[3ページ]RFC1777LDAP行進1995
LDAPString ::= OCTET STRING
LDAPString:、:= 八重奏ストリング
The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as OCTET STRING types, the legal character set in such strings is limited to the IA5 character set.
LDAPStringはOCTET STRINGがタイプするようにLDAPStringのストリングがエンコードをタイプしますが、そのようなストリングの法的な文字集合がIA5文字集合に制限されるのを示す記号法の便利です。
LDAPDN ::= LDAPString
LDAPDN:、:= LDAPString
RelativeLDAPDN ::= LDAPString
RelativeLDAPDN:、:= LDAPString
An LDAPDN and a RelativeLDAPDN are respectively defined to be the representation of a Distinguished Name and a Relative Distinguished Name after encoding according to the specification in [5], such that
LDAPDNとRelativeLDAPDNは[5]の仕様に従ったコード化の後のDistinguished NameとRelative Distinguished Nameの表現になるようにそれぞれ定義されて、そのようなものはそれです。
<distinguished-name> ::= <name>
<分類名>:、:= <名前>。
<relative-distinguished-name> ::= <name-component>
<の相対的な分類名の>:、:= <名コンポーネント>。
where <name> and <name-component> are as defined in [5].
<名前>と<名前部品>が[5]で定義されるようにあるところで。
AttributeValueAssertion ::=
SEQUENCE {
attributeType AttributeType,
attributeValue AttributeValue
}
AttributeValueAssertion:、:= 系列attributeType AttributeType、attributeValue AttributeValue
The AttributeValueAssertion type definition is similar to the one in the X.500 Directory standards.
AttributeValueAssertion型定義はX.500ディレクトリ規格においてものと同様です。
AttributeType ::= LDAPString
AttributeType:、:= LDAPString
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
An AttributeType value takes on as its value the textual string associated with that AttributeType in the X.500 Directory standards. For example, the AttributeType 'organizationName' with object identifier 2.5.4.10 is represented as an AttributeType in this protocol by the string "organizationName". In the event that a protocol implementation encounters an Attribute Type with which it cannot associate a textual string, an ASCII string encoding of the object identifier associated with the Attribute Type may be subsitituted. For example, the organizationName AttributeType may be represented by the ASCII string "2.5.4.10" if a protocol implementation is unable to associate the string "organizationName" with it.
AttributeType値は値としてX.500ディレクトリ規格でそのAttributeTypeに関連している原文のストリングを帯びます。 例えば、オブジェクト識別子があるAttributeType'organizationName'、2.5、.4、.10、AttributeTypeとして、このプロトコルで、ストリング"organizationName"によって表されます。 プロトコル実装がそれが原文のストリングを関連づけることができないAttribute Typeに遭遇する場合、オブジェクト識別子のコード化がAttribute Typeに関連づけたASCIIストリングはsubsititutedされるかもしれません。 例えば、organizationName AttributeTypeがASCIIストリングによって表されるかもしれない、「2.5、.4、0.1インチがプロトコル実装であるならストリング"organizationName"をそれに関連づけることができない、」
Yeong, Howes & Kille [Page 4] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[4ページ]RFC1777LDAP行進1995
A field of type AttributeValue takes on as its value an octet string encoding of a Directory AttributeValue type. The definition of these string encodings for different Directory AttributeValue types may be found in companions to this document that define the encodings of various attribute syntaxes such as [6].
タイプAttributeValueの分野は値としてディレクトリAttributeValueタイプにコード化される八重奏ストリングを帯びます。 異なったディレクトリAttributeValueタイプのためのこれらのストリングencodingsの定義はこのドキュメントへの[6]などの様々な属性構文のencodingsを定義する仲間で見つけられるかもしれません。
LDAPResult ::=
SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
aliasDereferencingProblem (36),
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
other (80)
},
matchedDN LDAPDN,
errorMessage LDAPString
}
LDAPResult:、:= 系列{ 数え上げられたresultCode; 成功(0)、operationsError(1)、protocolError(2)、timeLimitExceeded(3)、sizeLimitExceeded(4)、compareFalse(5)、compareTrue(6)、authMethodNotSupported(7)、strongAuthRequired(8)、noSuchAttribute(16)、undefinedAttributeType(17)、inappropriateMatching(18)、constraintViolation(19)、attributeOrValueExists(20)、invalidAttributeSyntax(21)、noSuchObject(32)、aliasProblem(33); invalidDNSyntax(34)、isLeaf(35)、aliasDereferencingProblem(36)、inappropriateAuthentication(48)、invalidCredentials(49)(insufficientAccessRights(50))は(51)と忙しくします、入手できない(52)、unwillingToPerform(53)、loopDetect(54)、namingViolation(64)、objectClassViolation(65)、notAllowedOnNonLeaf(66)、notAllowedOnRDN(67)、entryAlreadyExists(68)、objectClassModsProhibited(69)、他の(80); matchedDN LDAPDN、errorMessage LDAPString; }
Yeong, Howes & Kille [Page 5] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[5ページ]RFC1777LDAP行進1995
The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. In response to various requests, servers will return responses containing fields of type LDAPResult to indicate the final status of a protocol operation request. The errorMessage field of this construct may, at the servers option, be used to return an ASCII string containing a textual, human-readable error diagnostic. As this error diagnostic is not standardized, implementations should not rely on the values returned. If the server chooses not to return a textual diagnostic, the errorMessage field of the LDAPResult type should contain a zero length string.
LDAPResultはサーバからクライアントまでの成否指摘を返すのにこのプロトコルに使用される構造物です。 様々な要求に対応して、サーバは、プロトコル操作要求の最終的な状態を示すためにタイプLDAPResultの分野を含む応答を返すでしょう。 サーバ選択のときに、この構造物のerrorMessage分野は、原文の、そして、人間読み込み可能なエラー診断を含むASCIIストリングを返すのに使用されるかもしれません。 このエラー診断が標準化されないとき、実装は返された値を当てにするべきではありません。 サーバが、原文の病気の特徴を返さないのを選ぶなら、LDAPResultタイプのerrorMessage分野はゼロ長ストリングを含むべきです。
For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax, isLeaf, and aliasDereferencingProblem, the matchedDN field is set to the name of the lowest entry (object or alias) in the DIT that was matched and is a truncated form of the name provided or, if an alias has been dereferenced, of the resulting name. The matchedDN field should be set to NULL DN (a zero length string) in all other cases.
または、noSuchObject、aliasProblem、invalidDNSyntax、isLeaf、およびaliasDereferencingProblemのresultCodesに関して、matchedDN分野が合わせられたDITで最も低いエントリー(オブジェクトか別名)の名前に設定されて、提供という名前の端が欠けているフォームである、結果として起こる名前について別名に「反-参照をつけ」てあるなら。 matchedDN分野は他のすべての場合におけるNULL DN(ゼロ長ストリング)に設定されるべきです。
4.1. Bind Operation
4.1. ひもの操作
The function of the Bind Operation is to initiate a protocol session between a client and a server, and to allow the authentication of the client to the server. The Bind Operation must be the first operation request received by a server from a client in a protocol session. The Bind Request is defined as follows:
Bind Operationの機能は、クライアントとサーバとのプロトコルセッションを開始して、クライアントの認証をサーバに許すことです。Bind Operationはプロトコルセッションのときにサーバによってクライアントから受け取られた最初の操作要求であるに違いありません。 Bind Requestは以下の通り定義されます:
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication CHOICE {
simple [0] OCTET STRING,
krbv42LDAP [1] OCTET STRING,
krbv42DSA [2] OCTET STRING
}
}
BindRequest:、:= [アプリケーション0] 系列バージョンINTEGER、(1、.127、)、簡単な[0]OCTET STRING、krbv42LDAP[1]OCTET STRING、krbv42DSA[2]OCTET STRINGとLDAPDN、認証CHOICEを命名してください。
Parameters of the Bind Request are:
Bind Requestのパラメタは以下の通りです。
- version: A version number indicating the version of the protocol to
be used in this protocol session. This document describes version
2 of the LDAP protocol. Note that there is no version negotiation,
and the client should just set this parameter to the version it
desires.
- バージョン: このプロトコルセッションのときに使用されるためにプロトコルのバージョンを示すバージョン番号。 このドキュメントはLDAPプロトコルのバージョン2について説明します。 バージョン交渉が全くないことに注意してください。そうすれば、クライアントはただそれが望んでいるバージョンにこのパラメタを設定するべきです。
Yeong, Howes & Kille [Page 6] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[6ページ]RFC1777LDAP行進1995
- name: The name of the Directory object that the client wishes to
bind as. This field may take on a null value (a zero length
string) for the purposes of anonymous binds.
- 以下を命名してください。 クライアントが縛りたがっているディレクトリオブジェクトの名前。 この分野は匿名のひもの目的のために、ヌル値(ゼロ長ストリング)を呈するかもしれません。
- authentication: information used to authenticate the name, if any,
provided in the Bind Request. The "simple" authentication option
provides minimal authentication facilities, with the contents of
the authentication field consisting only of a cleartext password.
This option should also be used when unauthenticated or anonymous
binds are to be performed, with the field containing a zero length
string in such cases. Kerberos version 4 [7] authentication to the
LDAP server and the DSA is accomplished by using the "krbv42LDAP"
and "krbv42DSA" authentication options, respectively. Note that
though they are referred to as separate entities here, there is no
requirement these two entities be distinct (i.e., a DSA could speak
LDAP directly). Two separate authentication options are provided
to support all implementations. Each octet string should contain
the kerberos ticket (e.g., as returned by krb_mk_req()) for the
appropriate service. The suggested service name for authentication
to the LDAP server is "ldapserver". The suggested service name for
authentication to the DSA is "x500dsa". In both cases, the
suggested instance name for the service is the name of the host on
which the service is running. Of course, the actual service names
and instances will depend on what is entered in the local kerberos
principle database.
- 認証: 情報は以前はよくもしあればBind Requestに提供された名前を認証していました。 「簡単な」認証オプションは最小量の認証施設を提供します、認証分野のコンテンツがcleartextパスワードだけから成っていて。 匿名のひもはまた、非認証されると、このオプションが使用されるべきですか、または実行されることです、分野がそのような場合ゼロ長ストリングを含んでいて。 ケルベロスバージョン4 [7] LDAPサーバとDSAへの認証は、それぞれ"krbv42LDAP"と"krbv42DSA"認証オプションを使用することによって、実行されます。 それらはここと、そこに別々の実体と呼ばれますが、どんな要件もこれらの2つの実体ではありません。それに注意してください、異なってください(すなわち、DSAは直接LDAPを話すことができました)。 すべての実装をサポートするために2つの別々の認証オプションを提供します。 それぞれの八重奏ストリングはkerberosチケットを含むはずです。(例えば、適切なサービスのためにkrb_mk_req())が返されるように。 LDAPサーバへの認証のための提案されたサービス名は"ldapserver"です。 DSAへの認証のための提案されたサービス名は"x500dsa"です。 どちらの場合も、サービスのための提案されたインスタンス名はサービスが稼働しているホストの名前です。 もちろん、就航名とインスタンスはローカルのkerberos原則データベースに入れられるものによるでしょう。
The Bind Operation requires a response, the Bind Response, which is defined as:
Bind Operationは応答、以下と定義されるBind Responseを必要とします。
BindResponse ::= [APPLICATION 1] LDAPResult
BindResponse:、:= [アプリケーション1] LDAPResult
A Bind Response consists simply of an indication from the server of the status of the client's request for the initiation of a protocol session.
Bind Responseはプロトコルセッションの開始を求めるクライアントの要求の状態のサーバからの単に指示から成ります。
Upon receipt of a Bind Request, a protocol server will authenticate the requesting client if necessary, and attempt to set up a protocol session with that client. The server will then return a Bind Response to the client indicating the status of the session setup request.
Bind Requestを受け取り次第、プロトコルサーバは、必要なら、要求しているクライアントを認証して、そのクライアントとのプロトコルセッションをセットアップするのを試みるでしょう。 そして、サーバはセッションセットアップ要求の状態を示すクライアントにBind Responseを返すでしょう。
4.2. Unbind Operation
4.2. 操作を解いてください。
The function of the Unbind Operation is to terminate a protocol session. The Unbind Operation is defined as follows:
Unbind Operationの機能はプロトコルセッションを終えることです。 Unbind Operationは以下の通り定義されます:
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest:、:= [アプリケーション2] ヌル
Yeong, Howes & Kille [Page 7] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[7ページ]RFC1777LDAP行進1995
The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated. Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded.
Unbind Operationには、定義されなかった応答が全くあります。 UnbindRequestのトランスミッションのときに、プロトコルクライアントは、プロトコルセッションが終えられると仮定するかもしれません。 UnbindRequestを受け取り次第、プロトコルサーバは、要求しているクライアントがセッションを終えて、すべての傑出している要求が捨てられるかもしれないと仮定するかもしれません。
4.3. Search Operation
4.3. 索敵行動
The Search Operation allows a client to request that a search be performed on its behalf by a server. The Search Request is defined as follows:
検索Operationは検索がサーバによって利益に実行されるようクライアントを要求させます。検索Requestは以下の通り定義されます:
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2)
},
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN,
filter Filter,
attributes SEQUENCE OF AttributeType
}
SearchRequest:、:= [アプリケーション3] 系列baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、singleLevel(1)、wholeSubtree(2)、derefAliases ENUMERATED、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)、sizeLimit INTEGER(0maxInt)、attrsOnlyブールであるtimeLimit INTEGER(0maxInt)はFilterをフィルターにかけます、属性SEQUENCE OF AttributeType
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion
}
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、AttributeValueAssertion(サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)が[7]AttributeType、approxMatch[8]AttributeValueAssertionを寄贈するequalityMatch[3]ではなく、[0]SET OF Filter、または[1]SET OF Filter
SubstringFilter
SEQUENCE {
SubstringFilter系列
Yeong, Howes & Kille [Page 8] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[8ページ]RFC1777LDAP行進1995
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
AttributeTypeをタイプしてください、そして、SEQUENCE OF CHOICEは[0]LDAPString、どんな[1]LDAPString、決勝[2]LDAPStringにも頭文字をつけます。
Parameters of the Search Request are:
検索Requestのパラメタは以下の通りです。
- baseObject: An LDAPDN that is the base object entry relative to
which the search is to be performed.
- baseObject: に比例した実行される検索がことであるベースオブジェクトエントリーであるLDAPDN。
- scope: An indicator of the scope of the search to be performed. The
semantics of the possible values of this field are identical to the
semantics of the scope field in the Directory Search Operation.
- 範囲: 実行されるべき検索の範囲のインディケータ。 この分野の可能な値の意味論はディレクトリ検索Operationにおける範囲分野の意味論と同じです。
- derefAliases: An indicator as to how alias objects should be
handled in searching. The semantics of the possible values of
this field are, in order of increasing value:
- derefAliases: どれくらい通称オブジェクトに関するインディケータは探すことで扱われるべきであるか。 価値を増すことの順にこの分野の可能な値の意味論があります:
neverDerefAliases: do not dereference aliases in searching
or in locating the base object of the search;
neverDerefAliases: 探すか、または検索のベース目的の場所を見つける際にどんな反参照にも別名をしないでください。
derefInSearching: dereference aliases in subordinates of
the base object in searching, but not in locating the
base object of the search;
derefInSearching: ベースオブジェクトの部下の探しますが、検索のベース目的の場所を見つける際に探すというわけではないことにおける反参照別名。
derefFindingBaseObject: dereference aliases in locating
the base object of the search, but not when searching
subordinates of the base object;
derefFindingBaseObject: ベースオブジェクトの部下を身体検査しないとき検索のベース目的の場所を見つけることにおける反参照別名。
derefAlways: dereference aliases both in searching and in
locating the base object of the search.
derefAlways: 探して、検索のベース目的の場所を見つけることにおける反参照別名。
- sizelimit: A sizelimit that restricts the maximum number of entries
to be returned as a result of the search. A value of 0 in this
field indicates that no sizelimit restrictions are in effect for
the search.
- sizelimit: 検索の結果、返されるエントリーの最大数を制限するsizelimit。 この分野の0の値は、検索には、どんなsizelimit制限も有効でないことを示します。
- timelimit: A timelimit that restricts the maximum time (in seconds)
allowed for a search. A value of 0 in this field indicates that no
timelimit restrictions are in effect for the search.
- timelimit: 最大の時間(秒の)を制限するtimelimitは検索を考慮しました。 この分野の0の値は、検索には、どんなtimelimit制限も有効でないことを示します。
- attrsOnly: An indicator as to whether search results should contain
both attribute types and values, or just attribute types. Setting
this field to TRUE causes only attribute types (no values) to be
returned. Setting this field to FALSE causes both attribute types
- attrsOnly: 検索が結果として生じるかどうかに関するインディケータは属性タイプと値か、まさしく属性タイプの両方を含むべきです。 この分野をTRUEに設定するのに、属性タイプだけ(値がありません)を返します。 この分野をFALSEに設定すると、両方の属性タイプは引き起こされます。
Yeong, Howes & Kille [Page 9] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[9ページ]RFC1777LDAP行進1995
and values to be returned.
そして、返される値。
- filter: A filter that defines the conditions that must be fulfilled
in order for the search to match a given entry.
- 以下をフィルターにかけてください。 検索が与えられたエントリーに合うように達成されなければならない条件を定義するフィルタ。
- attributes: A list of the attributes from each entry found as a
result of the search to be returned. An empty list signifies that
all attributes from each entry found in the search are to be
returned.
- 属性: 返される検索の結果、見つけられた各エントリーからの属性のリスト。 空のリストは、検索で見つけられた各エントリーからのすべての属性が返されることであることを意味します。
The results of the search attempted by the server upon receipt of a Search Request are returned in Search Responses, defined as follows:
検索Requestを受け取り次第サーバによって試みられた検索の結果は以下の通り定義された検索Responsesで返されます:
Search Response ::=
CHOICE {
entry [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes SEQUENCE OF SEQUENCE {
AttributeType,
SET OF AttributeValue
}
},
resultCode [APPLICATION 5] LDAPResult
}
応答を捜してください:、:= 選択エントリー[APPLICATION4]SEQUENCE、objectName LDAPDN、属性SEQUENCE OF SEQUENCE、AttributeType、SET OF AttributeValue、resultCode[APPLICATION5]LDAPResult
Upon receipt of a Search Request, a server will perform the necessary search of the DIT.
検索Requestを受け取り次第、サーバはDITの必要な検索を実行するでしょう。
The server will return to the client a sequence of responses comprised of:
サーバは以下から成る応答の系列をクライアントに返すでしょう。
- Zero or more Search Responses each consisting of an entry found
during the search; with the response sequence terminated by
- ゼロかエントリーの各成るのが検索の間に見つけたより多くの検索Responses。 系列が終わった応答で
- A single Search Response containing an indication of success, or
detailing any errors that have occurred.
- 成功のしるしを含んでいるか、または発生したどんな誤りも詳しく述べる独身の検索Response。
Each entry returned will contain all attributes, complete with associated values if necessary, as specified in the 'attributes' field of the Search Request.
必要なら、返された各エントリーは関連値で完全なすべての属性を含むでしょう、検索Requestの'属性'分野で指定されるように。
Note that an X.500 "list" operation can be emulated by a one-level LDAP search operation with a filter checking for the existence of the objectClass attribute, and that an X.500 "read" operation can be emulated by a base object LDAP search operation with the same filter.
フィルタがobjectClass属性の存在がないかどうかチェックしている状態で1レベルのLDAP索敵行動でX.500「リスト」操作を見習うことができて、同じフィルタによるベースオブジェクトLDAP索敵行動で操作が「読まれた」X.500を見習うことができることに注意してください。
Yeong, Howes & Kille [Page 10] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[10ページ]RFC1777LDAP行進1995
4.4. Modify Operation
4.4. 操作を変更してください。
The Modify Operation allows a client to request that a modification of the DIB be performed on its behalf by a server. The Modify Request is defined as follows:
Modify OperationはDIBの変更がサーバによって利益に実行されるようクライアントを要求させます。Modify Requestは以下の通り定義されます:
ModifyRequest ::=
[APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2)
},
modification SEQUENCE {
type AttributeType,
values SET OF
AttributeValue
}
}
}
ModifyRequest:、:= [アプリケーション6] 系列LDAPDN、変更SEQUENCE OF SEQUENCEが反対する、操作ENUMERATEDは(0) (1)を削除するように言い足して、(2)を取り替えて、変更SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします。
Parameters of the Modify Request are:
Modify Requestのパラメタは以下の通りです。
- object: The object to be modified. The value of this field should
name the object to be modified after all aliases have been
dereferenced. The server will not perform any alias dereferencing
in determining the object to be modified.
- オブジェクト: 変更されるべきオブジェクト。 この分野の値は、すべての別名に「反-参照をつけ」てある後に変更されるためにオブジェクトを命名するべきです。 オブジェクトが変更されることを決定する際にサーバはどんな別名の「反-参照をつけ」も実行しないでしょう。
- A list of modifications to be performed on the entry to be modified.
The entire list of entry modifications should be performed
in the order they are listed, as a single atomic operation. While
individual modifications may violate the Directory schema, the
resulting entry after the entire list of modifications is performed
must conform to the requirements of the Directory schema. The
values that may be taken on by the 'operation' field in each
modification construct have the following semantics respectively:
- 変更されるためにエントリーに実行されるべき変更箇所一覧。 エントリー変更の全体のリストはオーダーで実行されて、それらがただ一つの原子操作として記載されているということであるべきです。 個々の変更がディレクトリ図式に違反しているかもしれない間、全体の変更箇所一覧が実行された後に結果として起こるエントリーはディレクトリ図式の要件に従わなければなりません。 それぞれの変更構造物の'操作'分野によって呈せられるかもしれない値はそれぞれ以下の意味論を持っています:
add: add values listed to the given attribute, creating
the attribute if necessary;
加えます: 必要なら、属性を作成して、値が与えられた属性に記載したと言い足してください。
delete: delete values listed from the given attribute,
削除します: 与えられた属性から記載された値を削除してください。
removing the entire attribute if no values are listed, or
if all current values of the attribute are listed for
deletion;
どんな値も記載されていないか、または属性のすべての現行価値が削除のために記載されるなら、全体の属性を取り除きます。
Yeong, Howes & Kille [Page 11] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[11ページ]RFC1777LDAP行進1995
replace: replace existing values of the given attribute
with the new values listed, creating the attribute if
necessary.
取り替えます: 必要なら、属性を作成して、与えられた属性の既存の値を記載されている新しい値に取り替えてください。
The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows:
結果、変更、試みられて、以下の通り定義されたModify ResponseでModify Requestを受け取り次第サーバを返します:
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse:、:= [アプリケーション7] LDAPResult
Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIB.
Modify Requestを受け取り次第、サーバはDIBへの必要な変更を実行するでしょう。
The server will return to the client a single Modify Response indicating either the successful completion of the DIB modification, or the reason that the modification failed. Note that due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIB have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify Operation.
サーバはDIB変更の無事終了、または変更が失敗した理由を示す独身のModify Responseをクライアントに返すでしょう。 Modify Requestの変更箇所一覧を適用することにおける最小単位のための要件のため、クライアントが、受け取られたModify Responseがどんな種類の誤りも示すならDIBの変更が全く実行されていないと予想するかもしれなくて、すべてが、Modify ResponseがModify Operationの無事終了を示すなら変更が実行されたよう要求したことに注意してください。
4.5. Add Operation
4.5. 操作を加えてください。
The Add Operation allows a client to request the addition of an entry into the Directory. The Add Request is defined as follows:
Add Operationはクライアントにエントリーの追加をディレクトリに要求させます。 Add Requestは以下の通り定義されます:
AddRequest ::=
[APPLICATION 8] SEQUENCE {
entry LDAPDN,
attrs SEQUENCE OF SEQUENCE {
type AttributeType,
values SET OF AttributeValue
}
}
AddRequest:、:= [アプリケーション8] 系列エントリーLDAPDN、attrs SEQUENCE OF SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします。
Parameters of the Add Request are:
Add Requestのパラメタは以下の通りです。
- entry: the Distinguished Name of the entry to be added. Note that
all components of the name except for the last RDN component must
exist for the add to succeed.
- エントリー: 加えられるべきエントリーのDistinguished Name。 最後のRDNコンポーネント必須以外の名前のすべての成分が存在する注意、成功するには、加えてください。
- attrs: the list of attributes that make up the content of the entry
being added.
- attrs: 加えられるエントリーの内容を作る属性のリスト。
The result of the add attempted by the server upon receipt of a Add Request is returned in the Add Response, defined as follows:
結果、試みられて、Add Requestを受け取り次第サーバが以下の通り定義されたAdd Responseで返されると言い足してください:
Yeong, Howes & Kille [Page 12] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[12ページ]RFC1777LDAP行進1995
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse:、:= [アプリケーション9] LDAPResult
Upon receipt of an Add Request, a server will attempt to perform the add requested. The result of the add attempt will be returned to the client in the Add Response.
Add Requestを受け取り次第サーバが、働くのを試みる、要求されていた状態で、加えてください。 なる、試みがAdd Responseのクライアントに返されると言い足してください。
4.6. Delete Operation
4.6. 操作を削除してください。
The Delete Operation allows a client to request the removal of an entry from the Directory. The Delete Request is defined as follows:
Delete Operationはクライアントにディレクトリからエントリーの取り外しを要求させます。 Delete Requestは以下の通り定義されます:
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest:、:= [アプリケーション10] LDAPDN
The Delete Request consists only of the Distinguished Name of the entry to be deleted. The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response, defined as follows:
Delete Requestは、削除されるためにエントリーのDistinguished Nameだけから成ります。 結果、削除、試みられて、以下の通り定義されたDelete ResponseでDelete Requestを受け取り次第サーバを返します:
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse:、:= [アプリケーション11] LDAPResult
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested. The result of the delete attempt will be returned to the client in the Delete Response. Note that only leaf objects may be deleted with this operation.
Delete Requestを受け取り次第、サーバは、取り外しが要求したエントリーを実行するのを試みるでしょう。 試みを削除してください。なる、Delete Responseのクライアントに返すでしょう。 この操作で葉のオブジェクトだけを削除してもよいことに注意してください。
4.7. Modify RDN Operation
4.7. RDN操作を変更してください。
The Modify RDN Operation allows a client to change the last component of the name of an entry in the Directory. The Modify RDN Request is defined as follows:
Modify RDN Operationはクライアントにディレクトリにおけるエントリーの名前の最後の成分を変えさせます。 Modify RDN Requestは以下の通り定義されます:
ModifyRDNRequest ::=
[APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN
}
ModifyRDNRequest:、:= [アプリケーション12] 系列newrdn RelativeLDAPDNの、そして、deleteoldrdnブールのエントリーLDAPDN
Parameters of the Modify RDN Request are:
Modify RDN Requestのパラメタは以下の通りです。
- entry: the name of the entry to be changed.
- エントリー: 変えられるべきエントリーの名前。
- newrdn: the RDN that will form the last component of the new name.
- newrdn: 新しい名前の最後の成分を形成するRDN。
- deleteoldrdn: a boolean parameter that controls whether the old RDN
attribute values should be retained as attributes of the entry or
deleted from the entry.
- deleteoldrdn: 古いRDNが値を結果と考えるかどうかを制御する論理演算子パラメタは、エントリーの属性として保有されるべきであるか、またはエントリーから削除されるべきです。
Yeong, Howes & Kille [Page 13] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[13ページ]RFC1777LDAP行進1995
The result of the name change attempted by the server upon receipt of a Modify RDN Request is returned in the Modify RDN Response, defined as follows:
Modify RDN Requestを受け取り次第サーバによって試みられた改名の結果は以下の通り定義されたModify RDN Responseで返されます:
ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
ModifyRDNResponse:、:= [アプリケーション13] LDAPResult
Upon receipt of a Modify RDN Request, a server will attempt to perform the name change. The result of the name change attempt will be returned to the client in the Modify RDN Response. The attributes that make up the old RDN are deleted from the entry, or kept, depending on the setting of the deleteoldrdn parameter.
Modify RDN Requestを受け取り次第、サーバは、改名を実行するのを試みるでしょう。 改名試みの結果はModify RDN Responseのクライアントに返されるでしょう。 古いRDNを作る属性は、エントリーから削除されるか、または保たれます、deleteoldrdnパラメタの設定によって。
4.8. Compare Operation
4.8. 操作を比較してください。
The Compare Operation allows a client to compare an assertion provided with an entry in the Directory. The Compare Request is defined as follows:
Compare Operationはクライアントにディレクトリにおけるエントリーが提供された主張を比較させます。 Compare Requestは以下の通り定義されます:
CompareRequest ::=
[APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion
}
CompareRequest:、:= [アプリケーション14] 系列エントリーLDAPDN、ava AttributeValueAssertion
Parameters of the Compare Request are:
Compare Requestのパラメタは以下の通りです。
- entry: the name of the entry to be compared with.
- エントリー: 比較されるエントリーの名前。
- ava: the assertion with which the entry is to be compared.
- ava: エントリーが比較されることになっている主張。
The result of the compare attempted by the server upon receipt of a Compare Request is returned in the Compare Response, defined as follows:
結果、Compare Requestが以下の通り定義されたCompare Responseで返されるaを受け取り次第サーバによって試みられて、比較してください:
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse:、:= [アプリケーション15] LDAPResult
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison. The result of the comparison will be returned to the client in the Compare Response. Note that errors and the result of comparison are all returned in the same construct.
Compare Requestを受け取り次第、サーバは、要求された比較を実行するのを試みるでしょう。 比較の結果はCompare Responseのクライアントに返されるでしょう。 誤りと比較の結果が同じ構造物ですべて返されることに注意してください。
6.9. Abandon Operation
6.9. 操作を捨ててください。
The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation. The Abandon Request is defined as follows:
Abandon Operationの機能はクライアントが、サーバが傑出している操作を捨てるよう要求するのを許容することです。 Abandon Requestは以下の通り定義されます:
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest:、:= [アプリケーション16] MessageID
Yeong, Howes & Kille [Page 14] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[14ページ]RFC1777LDAP行進1995
There is no response defined in the Abandon Operation. Upon transmission of an Abandon Operation, a client may expect that the operation identityfied by the Message ID in the Abandon Request has been abandoned. In the event that a server receives an Abandon Request on a Search Operation in the midst of transmitting responses to that search, that server should cease transmitting responses to the abandoned search immediately.
Abandon Operationで定義された応答が全くありません。 Abandon Operationのトランスミッションのときに、クライアントは、Abandon RequestのMessage IDによってidentityfiedされた操作が捨てられたと予想するかもしれません。 サーバがそれへの応答が捜す伝えることの中の検索Operationの上のAbandon Requestを受ける場合、そのサーバは、すぐに捨てられた検索への応答を伝えるのをやめるべきです。
5. Protocol Element Encodings
5. プロトコル要素Encodings
The protocol elements of LDAP are encoded for exchange using the Basic Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the high overhead involved in using certain elements of the BER, the following additional restrictions are placed on BER-encodings of LDAP protocol elements:
LDAPのプロトコル要素は、交換のためにASN.1[11]のBasic Encoding Rules(BER)[12]を使用することでコード化されます。 しかしながら、BERのある要素を使用するのに伴われる高いオーバーヘッドのために、以下の追加制限はLDAPプロトコル要素のBER-encodingsに関して課されます:
(1) Only the definite form of length encoding will be used.
(1) 長さのコード化の已然形だけが使用されるでしょう。
(2) Bitstrings and octet strings and all character string types
will be encoded in the primitive form only.
(2) Bitstrings、八重奏ストリング、およびすべての文字列タイプが原始のフォームだけでコード化されるでしょう。
6. Security Considerations
6. セキュリティ問題
This version of the protocol provides facilities only for simple authentication using a cleartext password, and for kerberos version 4 authentication. Future versions of LDAP will likely include support for other authentication methods.
プロトコルのこのバージョンはcleartextパスワードを使用する簡易認証だけ、およびkerberosバージョン4認証のために便宜を与えます。 LDAPの将来のバージョンはおそらく他の認証方法のサポートを含むでしょう。
7. Bibliography
7. 図書目録
[1] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[1] ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要。 CCITT推薦X.500、1988。
[2] Information Processing Systems -- Open Systems Interconnection --
The Directory: Overview of Concepts, Models and Service. ISO/IEC
JTC 1/SC21; International Standard 9594-1, 1988
[2] 情報処理システム--オープン・システム・インターコネクション--ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要。 ISO/IEC JTC1/SC21。 国際規格9594-1、1988
[3] Rose, M., "Directory Assistance Service", RFC 1202, Performance
Systems International, Inc., February 1991.
[3] ローズ、M.、「ディレクトリ支援サービス」、RFC1202、言語運用機構国際Inc.、2月1991日
[4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol
Specification, RFC 1249, University of Michigan, August 1991.
[4] ハウズとT.とスミス、M.とB.ビーチャー、「デキシープロトコル仕様、RFC1249、ミシガン大学、1991年8月。」
[5] Kille, S., "A String Representation of Distinguished Names", RFC
1779, ISODE Consortium, March 1995.
[5]Kille、S.、「分類名のストリング表現」、RFC1779、ISODE共同体、1995年3月。
Yeong, Howes & Kille [Page 15] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[15ページ]RFC1777LDAP行進1995
[6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight
Directory Access Protocol", RFC 1488, University of Michigan,
ISODE Consortium, Performance Systems International, NeXor Ltd.,
July 1993.
[6] ハウズとT.とKilleとS.とYeong、W.とC.ロビンス、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1488、ミシガン大学、ISODE共同体、国際言語運用機構、NeXor Ltd.(1993年7月)。
[7] Kerberos Authentication and Authorization System. S.P. Miller,
B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena
Documentation Section E.2.1, December 1987.
[7] ケルベロス認証と承認システム。 S.P.ミラー、B.C.ヌーマン、J.I.シラー、J.H.Saltzer。 1987年12月のMITプロジェクトアティナ資料課E.2.1。
[8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
1/SC21; International Standard 9594-2, 1988.
[8] ディレクトリ: モデル。 CCITT推薦X.501 ISO/IEC JTC1/SC21。 国際規格9594-2、1988。
[10] The Directory: Abstract Service Definition. CCITT Recommendation
X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
[10] ディレクトリ: 抽象的なサービス定義。 CCITT推薦X.511、ISO/IEC JTC1/SC21。 国際規格9594-3、1988。
[11] Specification of Abstract Syntax Notation One (ASN.1). CCITT
Recommendation X.208, 1988.
[11] 抽象構文記法1(ASN.1)の仕様。 CCITT推薦X.208、1988。
[12] Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1). CCITT Recommendation X.209, 1988.
[12] 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 CCITT推薦X.209、1988。
Yeong, Howes & Kille [Page 16] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[16ページ]RFC1777LDAP行進1995
10. Authors' Addresses
10. 作者のアドレス
Wengyik Yeong
PSI Inc.
510 Huntmar Park Drive
Herndon, VA 22070
USA
Wengyik YeongψInc.510Huntmar公園Driveヴァージニア22070ハーンドン(米国)
Phone: +1 703-450-8001
EMail: yeongw@psilink.com
以下に電話をしてください。 +1 703-450-8001 メールしてください: yeongw@psilink.com
Tim Howes
University of Michigan
ITD Research Systems
535 W William St.
Ann Arbor, MI 48103-4943
USA
ティムハウズミシガン大学ITDリサーチシステム535Wウィリアム・聖MI48103-4943アナーバー(米国)
Phone: +1 313 747-4454
EMail: tim@umich.edu
以下に電話をしてください。 +1 313 747-4454 メールしてください: tim@umich.edu
Steve Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
UK
スティーブKille ISODE共同体PO Box505ロンドンSW11 1DXイギリス
Phone: +44-71-223-4062
EMail: S.Kille@isode.com
以下に電話をしてください。 +44-71-223-4062 メールしてください: S.Kille@isode.com
Yeong, Howes & Kille [Page 17] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[17ページ]RFC1777LDAP行進1995
Appendix A - Complete ASN.1 Definition
付録A--完全なASN.1定義
Lightweight-Directory-Access-Protocol DEFINITIONS IMPLICIT TAGS ::=
ライトウェイト・ディレクトリ・アクセス・プロトコル定義、内在しているタグ:、:=
BEGIN
始まってください。
LDAPMessage ::=
SEQUENCE {
messageID MessageID,
-- unique id in request,
-- to be echoed in response(s)
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SearchResponse,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modifyDNRequest ModifyDNRequest,
modifyDNResponse ModifyDNResponse,
compareDNRequest CompareRequest,
compareDNResponse CompareResponse,
bindRequest BindRequest,
bindResponse BindResponse,
abandonRequest AbandonRequest,
unbindRequest UnbindRequest
}
}
LDAPMessage:、:= 系列{ messageID MessageID--要求におけるユニークなイド; 応答protocolOp CHOICEで反響されるように; searchRequest SearchRequest、searchResponse SearchResponse、modifyRequest ModifyRequest、modifyResponse ModifyResponse、addRequest AddRequest、addResponse AddResponse、delRequest DelRequest、delResponse DelResponse、modifyDNRequest ModifyDNRequest、modifyDNResponse ModifyDNResponse、compareDNRequest CompareRequest、compareDNResponse CompareResponse、bindRequest BindRequest、bindResponse BindResponse、abandonRequest AbandonRequest、unbindRequest UnbindRequest; }
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
-- current version is 2
name LDAPDN,
-- null name implies an anonymous bind
authentication CHOICE {
simple [0] OCTET STRING,
-- a zero length octet string
-- implies an unauthenticated
-- bind.
krbv42LDAP [1] OCTET STRING,
krbv42DSA [2] OCTET STRING
-- values as returned by
-- krb_mk_req()
-- Other values in later versions
-- of this protocol.
BindRequest:、:= [APPLICATION0]SEQUENCE、バージョンINTEGER、(1、.127、)、--、最新版は2名前LDAPDNです--ヌル名前が匿名のひもの認証CHOICEを含意する簡単な[0]OCTET STRING(ゼロ・レングス八重奏ストリング)はこのプロトコルの後のバージョンの他の--krb_mk_req()--値で返すように非認証された(ひもkrbv42LDAP[1]OCTET STRING、krbv42DSA[2]OCTET STRING)値を含意します。
Yeong, Howes & Kille [Page 18] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[18ページ]RFC1777LDAP行進1995
}
}
} }
BindResponse ::= [APPLICATION 1] LDAPResult
BindResponse:、:= [アプリケーション1] LDAPResult
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest:、:= [アプリケーション2] ヌル
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2)
},
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
alwaysDerefAliases (3)
},
sizeLimit INTEGER (0 .. maxInt),
-- value of 0 implies no sizelimit
timeLimit INTEGER (0 .. maxInt),
-- value of 0 implies no timelimit
attrsOnly BOOLEAN,
-- TRUE, if only attributes (without values)
-- to be returned.
filter Filter,
attributes SEQUENCE OF AttributeType
}
SearchRequest:、:= [アプリケーション3] 系列baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、singleLevel(1)、wholeSubtree(2)、derefAliases ENUMERATED、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、alwaysDerefAliases(3)、0の値はsizelimit timeLimit INTEGER(0maxInt)を全く含意しません--0の値がブールでtimelimit attrsOnlyを全く含意しないというsizeLimit INTEGER(0maxInt)、TRUE、属性(値のない)だけ--. フィルタFilterを返すために属性SEQUENCE OF AttributeType
SearchResponse ::=
CHOICE {
entry [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes SEQUENCE OF SEQUENCE {
AttributeType,
SET OF
AttributeValue
}
},
resultCode [APPLICATION 5] LDAPResult
}
SearchResponse:、:= 選択エントリー[APPLICATION4]SEQUENCE、objectName LDAPDN、属性SEQUENCE OF SEQUENCE、AttributeType、SET OF AttributeValue、resultCode[APPLICATION5]LDAPResult
ModifyRequest ::=
[APPLICATION 6] SEQUENCE {
object LDAPDN,
ModifyRequest:、:= [APPLICATION6]SEQUENCE、オブジェクトLDAPDN
Yeong, Howes & Kille [Page 19] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[19ページ]RFC1777LDAP行進1995
modifications SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2)
},
modification SEQUENCE {
type AttributeType,
values SET OF
AttributeValue
}
}
}
変更SEQUENCE OF SEQUENCE、操作ENUMERATEDは(0) (1)を削除するように言い足して、(2)を取り替えて、変更SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします。
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse:、:= [アプリケーション7] LDAPResult
AddRequest ::=
[APPLICATION 8] SEQUENCE {
entry LDAPDN,
attrs SEQUENCE OF SEQUENCE {
type AttributeType,
values SET OF AttributeValue
}
}
AddRequest:、:= [アプリケーション8] 系列エントリーLDAPDN、attrs SEQUENCE OF SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします。
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse:、:= [アプリケーション9] LDAPResult
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest:、:= [アプリケーション10] LDAPDN
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse:、:= [アプリケーション11] LDAPResult
ModifyRDNRequest ::=
[APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN -- old RDN always deleted
}
ModifyRDNRequest:、:= [アプリケーション12] 系列エントリーLDAPDN、newrdn RelativeLDAPDN--、古いRDNはいつも削除しました。
ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
ModifyRDNResponse:、:= [アプリケーション13] LDAPResult
CompareRequest ::=
[APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion
}
CompareRequest:、:= [アプリケーション14] 系列エントリーLDAPDN、ava AttributeValueAssertion
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse:、:= [アプリケーション15] LDAPResult
Yeong, Howes & Kille [Page 20] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[20ページ]RFC1777LDAP行進1995
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest:、:= [アプリケーション16] MessageID
MessageID ::= INTEGER (0 .. maxInt)
MessageID:、:= 整数(0maxInt)
LDAPDN ::= LDAPString
LDAPDN:、:= LDAPString
RelativeLDAPDN ::= LDAPString
RelativeLDAPDN:、:= LDAPString
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion
}
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、AttributeValueAssertion(サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)が[7]AttributeType、approxMatch[8]AttributeValueAssertionを寄贈するequalityMatch[3]ではなく、[0]SET OF Filter、または[1]SET OF Filter
LDAPResult ::=
SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
aliasDereferencingProblem (36),
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
LDAPResult:、:= SEQUENCE、resultCode ENUMERATED、成功(0)、operationsError(1)、protocolError(2)、timeLimitExceeded(3)、sizeLimitExceeded(4)、compareFalse(5)、compareTrue(6)、authMethodNotSupported(7)、strongAuthRequired(8)、noSuchAttribute(16)、undefinedAttributeType(17)、inappropriateMatching(18); constraintViolation(19)、attributeOrValueExists(20)、invalidAttributeSyntax(21)、noSuchObject(32)、aliasProblem(33)、invalidDNSyntax(34)、isLeaf(35)、aliasDereferencingProblem(36)、inappropriateAuthentication(48)、invalidCredentials(49)(insufficientAccessRights(50))は(51)と忙しくします。
Yeong, Howes & Kille [Page 21] RFC 1777 LDAP March 1995
Yeong、ハウズ、およびKille[21ページ]RFC1777LDAP行進1995
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
other (80)
},
matchedDN LDAPDN,
errorMessage LDAPString
}
入手できない(52)、unwillingToPerform(53)、loopDetect(54)、namingViolation(64)、objectClassViolation(65)、notAllowedOnNonLeaf(66)、notAllowedOnRDN(67)、entryAlreadyExists(68)、objectClassModsProhibited(69)、他の(80)、matchedDN LDAPDN、errorMessage LDAPString
AttributeType ::= LDAPString
-- text name of the attribute, or dotted
-- OID representation
AttributeType:、:= LDAPString--属性、点を打たれることの原文名--OID表現
AttributeValue ::= OCTET STRING
AttributeValue:、:= 八重奏ストリング
AttributeValueAssertion ::=
SEQUENCE {
attributeType AttributeType,
attributeValue AttributeValue
}
AttributeValueAssertion:、:= 系列attributeType AttributeType、attributeValue AttributeValue
SubstringFilter ::=
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
SubstringFilter:、:= 系列AttributeTypeをタイプしてください、そして、SEQUENCE OF CHOICEは[0]LDAPString、どんな[1]LDAPString、決勝[2]LDAPStringにも頭文字をつけます。
LDAPString ::= OCTET STRING
LDAPString:、:= 八重奏ストリング
maxInt INTEGER ::= 65535 END
maxInt整数:、:= 65535終わり
Yeong, Howes & Kille [Page 22]
Yeong、ハウズ、およびKille[22ページ]
一覧
スポンサーリンク
