RFC2589 日本語訳
2589 Lightweight Directory Access Protocol (v3): Extensions forDynamic Directory Services. Y. Yaacovi, M. Wahl, T. Genovese. May 1999. (Format: TXT=26855 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Yaacovi
Request for Comments: 2589 Microsoft
Category: Standards Track M. Wahl
Innosoft International, Inc.
T. Genovese
Microsoft
May 1999
Yaacoviがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2589年のマイクロソフトカテゴリ: Inc.T.Genoveseマイクロソフト1999年5月の国際の標準化過程M.ウォールInnosoft
Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory Services
ライトウェイト・ディレクトリ・アクセス・プロトコル(v3): ダイナミックなディレクトリサービスのための拡大
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment.
ダイナミックなディレクトリ環境でクライアント/サーバがinteroperationであるとサポートするのに、このドキュメントは、ダイナミックなディレクトリサービスのための要件を定義して、要求と応答拡大手術の形式を指定します。
The Lightweight Directory Access Protocol (LDAP) [1] supports lightweight access to static directory services, allowing relatively fast search and update access. Static directory services store information about people that persists in its accuracy and value over a long period of time.
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[1]は静的なディレクトリサービスへの軽量のアクセスをサポートします、比較的速い検索とアップデートアクセサリーを許容して 静的なディレクトリサービスは長日月の間にその精度と値に固執する人々の情報を保存します。
Dynamic directory services are different in that they store information that only persists in its accuracy and value when it is being periodically refreshed. This information is stored as dynamic entries in the directory. A typical use will be a client or a person that is either online - in which case it has an entry in the directory, or is offline - in which case its entry disappears from the directory. Though the protocol operations and attributes used by dynamic directory services are similar to the ones used for static directory services, clients that store dynamic information in the directory need to periodically refresh this information, in order to prevent it from disappearing. If dynamic entries are not refreshed
ダイナミックなディレクトリサービスはそれが定期的にリフレッシュされているときだけその精度と値に固執する情報を保存するという点において異なっています。 この情報はディレクトリにおけるダイナミックなエントリーとして保存されます。 典型的な使用は、オンラインであるクライアントか人になるでしょう--その場合、それは、ディレクトリにおけるエントリーを持っているか、またはオフラインです--その場合、エントリーはディレクトリから見えなくなります。 ダイナミックなディレクトリサービスによって使用されるプロトコル操作と属性は静的なディレクトリサービスに使用されるものと同様ですが、ディレクトリの動的情報を保存するクライアントは、定期的にこの情報をリフレッシュする必要があります、それが見えなくなるのを防ぐために。 ダイナミックなエントリーが壮快でないなら
Yaacovi, et al. Standards Track [Page 1] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[1ページ]。
within a given timeout, they will be removed from the directory. For example, this will happen if the client that set them goes offline.
与えられたタイムアウトの中では、ディレクトリからそれらを取り除くでしょう。 例えば、それらを設定したクライアントがオフラインで行くと、これは起こるでしょう。
A flow control mechanism from the server is also described that allows a server to inform clients how often they should refresh their presence.
また、サーバからのサーバが、彼らがどれくらいの頻度で自分達の存在をリフレッシュするべきであるかをクライアントに知らせることができるフロー制御メカニズムは説明されます。
2. Requirements
2. 要件
The protocol extensions must allow accessing dynamic information in a directory in a standard LDAP manner, to allow clients to access static and dynamic information in the same way.
プロトコル拡大で、同様に、クライアントが静的でダイナミックな情報にアクセスするのを許容するために標準のLDAP方法によるディレクトリの動的情報にアクセスしなければなりません。
By definition, dynamic entries are not persistent and clients may go away gracefully or not. The proposed extensions must offer a way for a server to tell if entries are still valid, and to do this in a way that is scalable. There also must be a mechanism for clients to reestablish their entry with the server.
定義上、ダイナミックなエントリーが永続的でなく、クライアントは優雅に立ち去るかもしれません。 提案された拡大はサーバが、エントリーがまだ有効であるかどうか言って、スケーラブルな方法でこれをする方法を提供しなければなりません。 また、クライアントがサーバで彼らのエントリーを復職させるメカニズムがあるに違いありません。
There must be a way for clients to find out, in a standard LDAP manner, if servers support the dynamic extensions.
クライアントが見つける方法があるに違いありません、標準のLDAP方法で、サーバがダイナミックな拡大をサポートするなら。
Finally, to allow clients to broadly use the dynamic extensions, the extensions need to be registered as standard LDAP extended operations.
最終的に、クライアントがダイナミックな拡張子を広く使用するのを許容するために、拡張子は、標準のLDAPが操作を広げているのに従って登録される必要があります。
3. Description of Approach
3. アプローチの記述
The Lightweight Directory Access Protocol (LDAP) [1] permits additional operation requests and responses to be added to the protocol. This proposal takes advantage of these to support directories which contain dynamic information in a manner which is fully integrated with LDAP.
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[1]は、兼業要求と応答がプロトコルに追加されることを許可します。 この提案は、LDAPについて完全に統合している方法による動的情報を含むディレクトリを支えるのにこれらを利用します。
The approach described in this proposal defines dynamic entries in order to allow implementing directories with dynamic information. An implementation of dynamic directories, must be able to support dynamic directory entries.
この提案で説明されたアプローチは、動的情報でディレクトリを実装するのを許容するためにダイナミックなエントリーを定義します。 ダイナミックなディレクトリの実装はダイナミックなディレクトリエントリーをサポートすることができなければなりません。
3.1. Dynamic Entries and the dynamicObject object class
3.1. ダイナミックなEntriesとdynamicObjectオブジェクトのクラス
A dynamic entry is an object in the directory tree which has a time- to-live associated with it. This time-to-live is set when the entry is created. The time-to-live is automatically decremented, and when it expires the dynamic entry disappears. By invoking the refresh extended operation (defined below) to re-set the time-to-live, a client can cause the entry to remain present a while longer.
ダイナミックなエントリーが時間を持っているディレクトリツリーのオブジェクトである、-生きてください、それに関連しています。 エントリーが作成されるとき、生きるこの時間は決められます。 生きる時間は自動的に減少します、そして、期限が切れるとき、ダイナミックなエントリーは見えなくなります。 呼び出す、生きるために調節しているaクライアントが、より長いときにしばらくエントリーを存在していたままで残らせることができるリセットに拡大手術(以下では、定義される)をリフレッシュしてください。
Yaacovi, et al. Standards Track [Page 2] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[2ページ]。
A dynamic entry is created by including the objectClass value given in section 5 in the list of attributes when adding an entry. This method is subject to standard access control restrictions.
ダイナミックなエントリーは、エントリーを加えるとき属性のリストのセクション5で与えられたobjectClass値を含んでいることによって、作成されます。 このメソッドは標準アクセス規制制限を受けることがあります。
The extended operation covered here, allows a client to refresh a dynamic entry by invoking, at intervals, refresh operations containing that entry's name. Dynamic entries will be treated the same as non-dynamic entries when processing search, compare, add, delete, modify and modifyDN operations. However if clients stop sending refresh operations for an entry, then the server will automatically and without notification remove that entry from the directory. This removal will be treated the same as if the entry had been deleted by an LDAP protocol operation.
広げる操作がここにカバーしていて、間隔を置いてそのエントリーの名前を含むリフレッシュ操作を呼び出すことによってダイナミックなエントリーをリフレッシュするのをクライアントを許容する。 処理するとき、非ダイナミックなエントリーが探されるときダイナミックなエントリーが同じように扱われて、比較してくださいといって、加えてください、削除、変更、そして、modifyDN操作。 しかしながら、クライアントが、エントリーのためのリフレッシュ操作を送るのを止めると、サーバはディレクトリから自動的と通知なしでそのエントリーを取り除くでしょう。 まるでエントリーがLDAPプロトコル操作で削除されたかのようにこの取り外しは同じように扱われるでしょう。
There is no way to change a static entry into a dynamic one and vice-versa. If the client is using Modify with an objectClass of dynamicObject on a static entry, the server must return a service error either "objectClassModsProhibited" (if the server does not allow objectClass modifications at all) or "objectClassViolation" (if the server does allow objectClass modifications in general).
静的なエントリーをダイナミックなものに変える方法が全くありません、そして、逆もまた同様です。 クライアントが静的なエントリーのdynamicObjectのobjectClassと共にModifyを使用しているなら、サーバはサービスエラー"objectClassModsProhibited"(サーバが全く変更をobjectClassに許さないなら)か"objectClassViolation"のどちらかを返さなければなりません(サーバが一般に、変更をobjectClassに許すなら)。
A dynamic entry may be removed by the client using the delete operation. This operation will be subject to access control restrictions.
クライアント使用でダイナミックなエントリーを取り除くかもしれない、操作を削除してください。 この操作は、規制制限にアクセスするためになることがあるでしょう。
A non-dynamic entry cannot be added subordinate to a dynamic entry: the server must return an appropriate update or service error if this is attempted.
非ダイナミックなエントリーはダイナミックなエントリーへの加えられた部下であるはずがありません: これが試みられるなら、サーバは適切なアップデートかサービスエラーを返さなければなりません。
The support of dynamic attributes of an otherwise static object, are outside the scope of this document.
そうでなければ、静的なオブジェクトのダイナミックな属性のサポートはこのドキュメントの範囲の外のそうです。
3.2 Dynamic meetings (conferences)
3.2 ダイナミックなミーティング(会議)
The way dynamicObject is defined, it has a time-to-live associated with it, and that's about it. Though the most common dynamic object is a person object, there is no specific type associated with the dynamicObject as defined here. By the use of the dynamic object's attributes, one can make this object represent practically anything.
それには、dynamicObjectが定義される方法で、生きる時間がそれに関連していた状態であります、そして、それはそれに関するものです。 最も一般的なダイナミックなオブジェクトは人のオブジェクトですが、dynamicObjectに関連しているどんな特定のタイプもここで定義されるようにいません。 ダイナミックなオブジェクトの属性の使用で、このオブジェクトは1つで実際に何でも表すことができます。
Specifically, Meetings (conferences) can be represented by dynamic objects. While full-featured meeting support requires special semantics and handling by the server (and is not in the scope of this document), the extensions described here, provide basic meetings support. A meeting object can be refreshed by the meeting participants, and when it is not, the meeting entry disappears. The one meeting type that is naturally supported by the dynamic extensions is creator-owned meeting.
明確に、ダイナミックなオブジェクトはMeetings(会議)を表すことができます。 拡大は、ここでサーバ(そして、このドキュメントの範囲には、ない)で完全装備のミーティングサポートが特別な意味論と取り扱いを必要としている間、基本的なミーティングサポートを提供するように説明しました。 ミーティング関係者はミーティングオブジェクトをリフレッシュできます、そして、それがそうでないときに、ミーティングエントリーは姿を消します。 ダイナミックな拡大で自然にサポートされる1つのミーティングタイプがクリエイターによって所有されているミーティングです。
Yaacovi, et al. Standards Track [Page 3] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[3ページ]。
3.2.1 Creator-owned meetings
3.2.1 創造者によって所有されているミーティング
Creator-owned meetings are created by a client that sets the time- to-live attribute for the entry, and it is this client's responsibility to refresh the meeting entry, so that it will not disappear. Others might join the meeting, by modifying the appropriate attribute, but they are not allowed to refresh the entry. When the client that created the entry goes away, it can delete the meeting entry, or it might disappear when its time-to-live expires. This is consistent with the common model for dynamicObject as described above.
エントリー、およびそれのための属性はそうです。創造者によって所有されているミーティングが時間を決めるクライアントによって作成される、-生きてください、ミーティングエントリーをリフレッシュする見えなくならないこのクライアントの責任。 適切な属性を変更することによって、他のものはミーティングに参加するかもしれませんが、彼らはエントリーをリフレッシュできません。 生きる時間が期限が切れるとき、エントリーを作成したクライアントが立ち去るとき、ミーティングエントリーを削除できますか、またはそれは見えなくなるかもしれません。 dynamicObjectにおいて、これは上で説明されるように一般的なモデルと一致しています。
4. Protocol Additions
4. プロトコル追加
4.1 Refresh Request
4.1は要求をリフレッシュします。
Refresh is a protocol operation sent by a client to tell the server that the client is still alive and the dynamic directory entry is still accurate and valuable. The client sends a Refresh request periodically based on the value of the client refresh period (CRP). The server can request that the client change this value. As long as the server receives a Refresh request within the timeout period, the directory entry is guaranteed to persist on the server. Client implementers should be aware that since the intervening network between the client and server is unreliable, a Refresh request packet may be delayed or lost while in transit. If this occurs, the entry may disappear, and the client will need to detect this and re-add the entry.
リフレッシュしてください。ダイナミックなディレクトリエントリは、プロトコル操作がクライアントがまだ生きているとサーバに言うためにクライアントによって送られて、まだ正確であって、貴重です。 クライアントは定期的にクライアントの値に基づいている要求がリフレッシュするRefreshに期間(CRP)を送ります。 サーバは、クライアントがこの値を変えるよう要求できます。 サーバがタイムアウト時間中にRefresh要求を受け取る限り、ディレクトリエントリは、サーバで固執するために保証されます。トランジットにはある間、クライアントimplementersはクライアントとサーバの間の介入しているネットワークが頼り無いので、Refreshリクエスト・パケットが遅らせられるか、または失われるかもしれないのを意識しているべきです。 これが起こるなら、エントリーが姿を消すかもしれなくて、クライアントは、これを検出して、エントリーを再加える必要があるでしょう。
A client may request this operation by transmitting an LDAP PDU containing an ExtendedRequest. An LDAP ExtendedRequest is defined as follows:
クライアントは、ExtendedRequestを含むLDAP PDUを伝えることによって、この操作を要求するかもしれません。 LDAP ExtendedRequestは以下の通り定義されます:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest:、:= [アプリケーション23] 系列requestName[0]LDAPOIDで、requestValue[1]八重奏ストリング任意です。
The requestName field must be set to the string "1.3.6.1.4.1.1466.101.119.1".
requestName分野をストリングに設定しなければならない、「1.3 .6 .1 .4 .1 .1466 .101 .119 0.1インチ」
The requestValue field will contain as a value the DER-encoding of the following ASN.1 data type:
requestValue分野は値として以下のASN.1データ型のDER-コード化を含むでしょう:
SEQUENCE {
entryName [0] LDAPDN,
requestTtl [1] INTEGER
}
系列entryName[0]LDAPDN、requestTtl[1]整数
Yaacovi, et al. Standards Track [Page 4] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[4ページ]。
The entryName field is the UTF-8 string representation of the name of the dynamic entry [3]. This entry must already exist.
entryName分野はダイナミックなエントリー[3]の名前のUTF-8ストリング表現です。 このエントリーは既に存在しなければなりません。
The requestTtl is a time in seconds (between 1 and 31557600) that the client requests that the entry exists in the directory before being automatically removed. Servers are not required to accept this value and might return a different TTL value to the client. Clients must be able to use this server-dictated value as their CRP.
requestTtlはクライアントが、自動的に取り除く前にエントリーがディレクトリに存在するよう要求する秒(1〜31557600)の時間です。 サーバは、この値を受け入れるのが必要でなく、異なったTTL値をクライアントに返すかもしれません。 クライアントは彼らのCRPとしてこのサーバで書き取られた値を使用できなければなりません。
4.2 Refresh Response
4.2は応答をリフレッシュします。
If a server implements this extension, then when the request is made it will return an LDAP PDU containing an ExtendedResponse. An LDAP ExtendedResponse is defined as follows:
要求をするとき、サーバがこの拡大を実装すると、それはExtendedResponseを含むLDAP PDUを返すでしょう。 LDAP ExtendedResponseは以下の通り定義されます:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
ExtendedResponse:、:= [アプリケーション24] 系列COMPONENTS OF LDAPResult、responseName[10]LDAPOID OPTIONAL、応答[11]OCTET STRING OPTIONAL
The responseName field contains the same string as that present in the request.
responseName分野は要求にそのプレゼントと同じストリングを含んでいます。
The response field will contain as a value the DER-encoding of the following ASN.1 data type:
応答分野は値として以下のASN.1データ型のDER-コード化を含むでしょう:
SEQUENCE {
responseTtl [1] INTEGER
}
系列responseTtl[1]整数
The responseTtl field is the time in seconds which the server chooses to have as the time-to-live field for that entry. It must not be any smaller than that which the client requested, and it may be larger. However, to allow servers to maintain a relatively accurate directory, and to prevent clients from abusing the dynamic extensions, servers are permitted to shorten a client-requested time-to-live value, down to a minimum of 86400 seconds (one day).
responseTtl分野はサーバがそのエントリーへの生きる時間分野として持っているのを選ぶ秒の時間です。 それはクライアントが要求したそれより少しも小さいはずがありません、そして、より大きいかもしれません。 しかしながら、クライアントがサーバによって比較的正確なディレクトリを主張して、ダイナミックな拡大を乱用できないのを許容するために、サーバがクライアントによって要求された生きる時間値を短くすることが許可されています、(ある日)の最低86400秒まで。
If the operation was successful, the errorCode field in the standardResponse part of an ExtendedResponse will be set to success.
操作がうまくいったなら、ExtendedResponseのstandardResponse部分のerrorCode分野は成功に設定されるでしょう。
In case of an error, the responseTtl field will have the value 0, and the errorCode field will contain an appropriate value, as follows: If the entry named by entryName could not be located, the errorCode field will contain "noSuchObject". If the entry is not dynamic, the errorCode field will contain "objectClassViolation". If the requester does not have permission to refresh the entry, the
responseTtl分野には、誤りの場合には、値0があるでしょう、そして、errorCode分野が適切な値を含むでしょう、以下の通りです: entryNameによって指定されたエントリーの見つけることができないと、errorCode分野は"noSuchObject"を含むでしょう。 エントリーがダイナミックでないなら、errorCode分野は"objectClassViolation"を含むでしょう。 リクエスタにエントリーをリフレッシュする許可がないなら
Yaacovi, et al. Standards Track [Page 5] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[5ページ]。
errorCode field will contain "insufficientAccessRights". If the requestTtl field is too large, the errorCode field will contain "sizeLimitExceeded".
errorCode分野は「insufficientAccessRights」を含むでしょう。 requestTtl分野が大き過ぎるなら、errorCode分野は"sizeLimitExceeded"を含むでしょう。
If a server does not implement this extension, it will return an LDAP PDU containing an ExtendedResponse, which contains only the standardResponse element (the responseName and response elements will be absent). The LDAPResult element will indicate the protocolError result code.
サーバがこの拡大を実装しないと、それはExtendedResponseを含むLDAP PDUを返すでしょう(responseNameと応答要素は欠けるでしょう)。ExtendedResponseはstandardResponse要素だけを含みます。 LDAPResult要素はprotocolError結果コードを示すでしょう。
This request is permitted to be invoked when LDAP is carried by a connectionless transport.
LDAPがコネクションレスな輸送で運ばれるとき、この要求が呼び出されることが許可されています。
When using a connection-oriented transport, there is no requirement that this operation be on the same particular connection as any other. A client may open multiple connections, or close and then reopen a connection.
接続指向の輸送を使用するとき、いかなる他のも同じ特定の接続にはこの操作がある要件が全くありません。 クライアントは、接続を複数の接続を開くか、終えて、または次に、再開させるかもしれません。
4.3 X.500/DAP Modify(97)
4.3X.500/がちょと浸す、変更(97)
X.500/DAP servers can map the Refresh request and response operations into the X.500/DAP Modify(97) operation.
X.500/DAPサーバはRefresh要求と応答操作をX.500/DAP Modify(97)操作に写像できます。
5. Schema Additions
5. 図式追加
All dynamic entries must have the dynamicObject value in their objectClass attribute. This object class is defined as follows (using the ObjectClassDescription notation of [2]):
すべてのダイナミックなエントリーには、それらのobjectClass属性におけるdynamicObject値がなければなりません。 このオブジェクトのクラスが以下の通り定義される、([2])のObjectClassDescription記法を使用します:
( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'This class, if present in an entry, indicates that this entry
has a limited lifetime and may disappear automatically when
its time-to-live has reached 0. There are no mandatory
attributes of this class, however if the client has not
supplied a value for the entryTtl attribute, the server will
provide one.'
SUP top AUXILIARY )
このクラスは、エントリーに存在しているならこのエントリーには限られた寿命があるのを示して、生きる時間が0に達したとき、自動的に見えなくなるかもしれません。'しかしながら、このクラスのどんな義務的な属性もなくて、クライアントがentryTtl属性に値を供給していないと、サーバは1つを提供するでしょう'。(1.3、.6、.1、.4、.1、.1466、.101、.119.2NAME'dynamicObject'DESC、SUPはAUXILIARYを上回っています)
Furthermore, the dynamic entry must have the following operational attribute. It is described using the AttributeTypeDescription notation of [2]:
その上、ダイナミックなエントリーには、以下の操作上の属性がなければなりません。 それは[2]のAttributeTypeDescription記法を使用することで説明されます:
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'This operational attribute is maintained by the server and
appears to be present in every dynamic entry. The attribute
is not present when the entry does not contain the
dynamicObject object class. The value of this attribute is
the time in seconds that the entry will continue to exist
.3これほど操作上のNAME'entryTtl'DESC'属性は、サーバによって主張されて、あらゆるダイナミックなエントリーに存在しているように見えます。エントリーがdynamicObjectオブジェクトのクラスを含まないとき、属性は存在していません。(1.3 .6 .1 .4 .1 .1466 .101 .119 この属性の値はエントリーが存続する秒の時間です'
Yaacovi, et al. Standards Track [Page 6] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[6ページ]。
before disappearing from the directory. In the absence of
intervening refresh operations, the values returned by
reading the attribute in two successive searches are
guaranteed to be nonincreasing. The smallest permissible
value is 0, indicating that the entry may disappear without
warning. The attribute is marked NO-USER-MODIFICATION since
it may only be changed using the refresh operation.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
NO-USER-MODIFICATION USAGE dSAOperation )
ディレクトリから見えなくなる前に。 リフレッシュ操作に介入することが不在のとき、2つの連続した検索における属性を読むことによって返された値は、非増強しているために保証されます。 エントリーがいきなり見えなくなるかもしれないのを示して、最も小さい許容値は0です。 '属性が. 'SYNTAX1.3にリフレッシュ操作を使用することでそれを変えるだけであるかもしれないのでUSER-MODIFICATIONでないとマークされる、.6、.1、.4、.1、.1466、.115、.121、.1、.27SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation)
To allow servers to support dynamic entries in only a part of the DIT, the following operational attribute is defined. It is described using the AttributeTypeDescription notation of [2]:
サーバがDITの一部だけでダイナミックなエントリーをサポートするのを許容するために、以下の操作上の属性は定義されます。 それは[2]のAttributeTypeDescription記法を使用することで説明されます:
( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
DESC 'This operational attribute is maintained by the server and is
present in the Root DSE, if the server supports the dynamic
extensions described in this memo. The attribute contains a
list of all the subtrees in this directory for which the
server supports the dynamic extensions.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.119.4 NAME、'これほど操作上の'DESC'が結果と考えるdynamicSubtreesはサーバによって維持されて、Root DSEに存在しています、サーバがこのメモで説明されたダイナミックな拡大をサポートするなら'。 '属性がサーバが. 'ダイナミックな拡大がSYNTAX1.3.6であるとサポートするこのディレクトリのすべての下位木のリストを含んでいる、.1、.4、.1、.1466、.115、.121、.1、.12USER-MODIFICATION USAGE dSAOperationがありません。)
6. Client and Server Requirements
6. クライアントとサーバ要件
6.1 Client Requirements
6.1 クライアント要件
Clients can find out if a server supports the dynamic extensions by checking the supportedExtension field in the root DSE, to see if the OBJECT IDENTIFIER described in section 4 is present. Since servers may select to support the dynamic extensions in only some of the subtrees of the DIT, clients must check the dynamicSubtrees operational attribute in the root DSE to find out if the dynamic extensions are supported on a specific subtree.
クライアントは、サーバがセクション4で説明されたOBJECT IDENTIFIERが存在しているかどうか確認するために根のDSEのsupportedExtension分野をチェックすることによってダイナミックな拡大をサポートするかどうか見つけることができます。 サーバがDITの下位木のいくつかだけにおけるダイナミックな拡大をサポートに選択するかもしれないので、クライアントはダイナミックな拡大が特定の下位木でサポートされるかどうか見つけるために根のDSEのdynamicSubtreesの操作上の属性をチェックしなければなりません。
Once a dynamic entry has been created, clients are responsible for invoking the refresh extended operation, in order to keep that entry present in the directory.
ダイナミックなエントリーがいったん作成されると、クライアントは呼び出しに責任がある、拡大手術をリフレッシュしてください、そのエントリーをディレクトリに存在しているように保つために。
Clients must not expect that a dynamic entry will be present in the DIT after it has timed out, however it must not require that the server remove the entry immediately (some servers may only process timing out entries at intervals). If the client wishes to ensure the entry does not exist it should issue a RemoveRequest for that entry.
クライアントは、外で時間があった後にダイナミックなエントリーがDITに存在すると予想してはいけなくて、しかしながら、それは、サーバがすぐにエントリーを取り除くのを必要としてはいけません(間隔を置いて、いくつかのサーバがエントリーでタイミングを処理するだけであるかもしれません)。 クライアントが、エントリーが存在しないのを保証したいなら、それはそのエントリーにRemoveRequestを発行するべきです。
Initially, a client needs to know how often it should send refresh requests to the server. This value is defined as the CRP (Client Refresh Period) and is set by the server based on the entryTtl.
初めは、クライアントは、どれくらいの頻度で発信するべきであるかがサーバに要求をリフレッシュするのを知る必要があります。この値は、CRP(クライアントRefresh Period)と定義されて、entryTtlに基づくサーバによって設定されます。
Yaacovi, et al. Standards Track [Page 7] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[7ページ]。
Since the LDAP AddRequest operation is left unchanged and is not modified in this proposal to return this value, a client must issue a Refresh extended operation immediately after an Add that created a dynamic entry. The Refresh Response will return the CRP (in responseTtl) to the client.
LDAP AddRequest操作が変わりがないままにされ、この値を返すというこの提案で変更されないので、クライアントはダイナミックなエントリーを作成したAdd直後Refresh拡大手術を発行しなければなりません。 Refresh ResponseはCRP(responseTtlの)をクライアントに返すでしょう。
Clients must not issue the refresh request for dynamic entries which they have not created. If an anonymous client attempts to do so, a server is permitted to return insufficientAccessRights (50) in the RefreshResponse, enforcing the client to bind first. Please note that servers which allow anonymous clients to create and refresh dynamic entries will not be able to enforce the above.
クライアントが発行してはいけない、それらが作成していないダイナミックなエントリーを求める要求をリフレッシュしてください。 匿名のクライアントが、そうするのを試みるなら、サーバがRefreshResponseでinsufficientAccessRights(50)を返すことが許可されます、最初に付くようにクライアントを実施して。 匿名のクライアントがダイナミックなエントリーを作成して、リフレッシュするサーバは、上記を実施できないでしょう。
Clients should always be ready to handle the case in which their entry timed out. In such a case, the Refresh operation will fail with an error code such as noSuchObject, and the client is expected to re-create its entry.
クライアントはいつも彼らのエントリーが外で調節された場合を扱う準備ができているべきです。 このような場合には、noSuchObjectなどのエラーコードに応じて、Refresh操作は失敗するでしょう、そして、クライアントがエントリーを作り直すと予想されます。
Clients should be prepared to experience refresh operations failing with protocolError, even though the add and any previous refresh requests succeeded. This might happen if a proxy between the client and the server goes down, and another proxy is used which does not support the Refresh extended operation.
クライアントがprotocolErrorと共に失敗するリフレッシュ操作を経験する用意ができているべきである、付加、いくらか、前である、引き継がれた要求をリフレッシュしてください。 クライアントとサーバの間のプロキシが落ちるなら、これは起こるかもしれません、そして、別のプロキシは使用されています(Refreshが拡大手術であるとサポートしません)。
6.2 Server Requirements
6.2 サーバ要件
Servers are responsible for removing dynamic entries when they time out. Servers are not required to do this immediately.
それらであるときに、サーバは取り外しのダイナミックなエントリーに原因となります。タイムアウト。 サーバは、すぐにこれをするのに必要ではありません。
Servers must enforce the structural rules listed in above section 3.
サーバはセクション3の上に記載された構造的な規則を実施しなければなりません。
Servers must ensure that the operational attribute described in section 5 is present in dynamic entries
サーバは、セクション5で説明された操作上の属性がダイナミックなエントリーに存在しているのを確実にしなければなりません。
Servers may permit anonymous users to refresh entries. However, to eliminate the possibility of a malicious use of the Refresh operation, servers may require the refreshing client to bind first. A server implementation can achieve this by presenting ACLs on the entryTtl attribute, and returning insufficientAccessRights (50) in the RefreshResponse, if the client is not allowed to refresh the entry. Doing this, though, might have performance implications on the server and might impact the server's scalability.
サーバは、匿名のユーザがエントリーをリフレッシュすることを許可するかもしれません。 しかしながら、Refresh操作の悪意がある使用の可能性を排除するために、サーバは、壮快なクライアントが最初に付くのを必要とするかもしれません。 サーバ実装はentryTtl属性でACLsを寄贈して、RefreshResponseでinsufficientAccessRights(50)を返すことによって、これを実現できます、クライアントがエントリーをリフレッシュできないなら。 もっとも、これをすると、性能意味がサーバに持たれて、サーバのスケーラビリティは影響を与えられるかもしれません。
Servers may require that a client which attempts to create a dynamic entry have a remove permission for that entry.
サーバはダイナミックなエントリーを作成するそれの試みがaにそのエントリーに許可を移させるそのaクライアントを必要とするかもしれません。
Servers which implement the dynamic extensions must have the OBJECT IDENTIFIER, described above in section 4 for the request and
そしてダイナミックな拡大を実装するサーバが要求のために上でセクション4で説明されたOBJECT IDENTIFIERを持たなければならない。
Yaacovi, et al. Standards Track [Page 8] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[8ページ]。
response, present as a value of the supportedExtension field in the root DSE. They must also have as values in the attributeTypes and objectClasses attributes of their subschema subentries, the AttributeTypeDescription and ObjectClassDescription from section 5.
根のDSEのsupportedExtension分野の値としての現在の応答。 また、彼らは値としてattributeTypesとobjectClassesにセクション5からのそれらのサブスキーマ副次的記載、AttributeTypeDescription、およびObjectClassDescriptionの属性を持たなければなりません。
Servers can limit the support of the dynamic extensions to only some of the subtrees in the DIT. Servers indicate for which subtrees they support the extensions, by specifying the OIDs for the supported subtrees in the dynamicSubtrees attribute described in section 5. If a server supports the dynamic extensions for all naming contexts it holds, the dynamicSubtrees attribute may be absent.
サーバはダイナミックな拡大のサポートをDITの下位木のいくつかだけに制限できます。 サーバは、それらがどの下位木のために拡大をサポートするかを示します、セクション5で説明されたdynamicSubtrees属性におけるサポートしている下位木にOIDsを指定することによって。 サーバがそれが保持するすべての命名文脈のためのダイナミックな拡大をサポートするなら、dynamicSubtrees属性は欠けているかもしれません。
7. Implementation issues
7. 導入問題
7.1 Storage of dynamic information
7.1 動的情報のストレージ
Dynamic information is expected to change very often. In addition, Refresh requests are expected to arrive at the server very often. Disk-based databases that static directory services often use are likely inappropriate for storing dynamic information. We recommend that server implementations store dynamic entries in memory sufficient to avoid paging. This is not a requirement.
動的情報が頻繁に変化すると予想されます。 さらに、Refresh要求が頻繁にサーバに到着すると予想されます。 動的情報を保存するには、静的なディレクトリサービスがしばしば使用するディスクベースのデータベースはおそらく不適当です。 私たちは、サーバ実装が呼び出すのを避けることができるくらいの記憶におけるダイナミックなエントリーを保存することを勧めます。 これは要件ではありません。
We expect LDAP servers to be able to store static and dynamic entries. If an LDAP server does not support dynamic entries, it should respond with an error code such as objectClassViolation.
私たちは、LDAPサーバが静的でダイナミックなエントリーを保存できると予想します。 LDAPサーバがダイナミックなエントリーをサポートしないなら、それはobjectClassViolationなどのエラーコードで応じるべきです。
7.2 Client refresh behavior
7.2クライアントは振舞いをリフレッシュします。
In some cases, the client might not get a Refresh response. This may happen as a result of a server crash after receiving the Refresh request, the TCP/IP socket timing out in the connection case, or the UDP packet getting lost in the connection-less case.
いくつかの場合、クライアントはRefresh応答を得ないかもしれません。 これはRefresh要求を受け取った後のサーバクラッシュ、接続事件におけるTCP/IPソケットタイミング、またはコネクションレスな場合で失せるUDPパケットの結果、起こるかもしれません。
It is recommended that in such a case, the client will retry the Refresh operation immediately, and if this Refresh request does not get a response as well, it will resort to its original Refresh cycle, i.e. send a Refresh request at its Client Refresh Period (CRP).
このような場合には、クライアントがすぐにRefresh操作を再試行するのが、お勧めであり、すなわち、このRefresh要求がまた、それが元のRefreshサイクルまで行く応答を得ないなら、Client Refresh Period(CRP)にRefresh要求を送ってください。
7.3 Configuration of refresh times
7.3構成、回をリフレッシュしてください。
We recommend that servers will provide administrators with the ability to configure the default client refresh period (CRP), and also a minimum and maximum CRP values. This, together with allowing administrators to request that the server will not change the CRP dynamically, will allow administrators to set CRP values which will enforce a low refresh traffic, or - on the other extreme, an highly up-to-date directory.
私たちは、サーバがデフォルトクライアントが期間(CRP)、最小限、および最大のCRP値もリフレッシュするのを構成する能力を管理者に提供することを勧めます。 または、サーバがダイナミックにCRPを変えないで、管理者がCRP値を設定するのを許容するよう要求するなる安値がリフレッシュするaを実施するのに管理者にトラフィックを許容するのに伴うこの--全く正反対、非常に最新のディレクトリの上で。
Yaacovi, et al. Standards Track [Page 9] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[9ページ]。
8. Replication
8. 模写
Replication is only partially addressed in this memo. There is a separate effort in progress at the IETF on replication of static and dynamic directories.
模写はこのメモで部分的に扱われるだけです。 静的でダイナミックなディレクトリの模写のIETFの進行中の別々の取り組みがあります。
it is allowed to replicate a dynamic entry or a static entry with dynamic attributes. Since the entryTtl is expressed as a relative time (how many seconds till the entry will expire), replicating it means that the replicated entry will be "off" by the replication time.
それはダイナミックな属性でダイナミックなエントリーか静的なエントリーを模写できます。 entryTtlが相対的な時間(エントリーが期限が切れるまでの何秒)として急送されるので、それを模写するのは、模写されたエントリーが模写時間までに“off"になることを意味します。
9. Localization
9. ローカライズ
The are no localization issues for this extended operation.
ローカライズ問題は全くこの拡張操作のためのものではありませんか?
10. Security Considerations
10. セキュリティ問題
Standard LDAP security rules and support apply for the extensions described in this document, and there are no special security issues for these extensions. Please note, though, that servers may permit anonymous clients to refresh entries which they did not create. Servers are also permitted to control a refresh access to an entry by requiring clients to bind before issuing a RefreshRequest. This will have implications on the server performance and scalability.
標準のLDAPセキュリティ規則とサポートは本書では説明された拡大に申し込みます、そして、これらの拡大のための特別担保問題が全くありません。 もっとも、サーバは、匿名のクライアントがそれらが作成しなかったエントリーをリフレッシュすることを許可するかもしれません。 サーバはそうです、また、aを制御することが許可されていて、RefreshRequestを発行する前にクライアントが付くのを必要とすることによって、エントリーへのアクセスをリフレッシュしてください。 これはサーバ性能とスケーラビリティに意味を持つでしょう。
Also, Care should be taken in making use of information obtained from directory servers that has been supplied by client, as it may now be out of date. In many networks, for example, IP addresses are automatically assigned when a host connects to the network, and may be reassigned if that host later disconnects. An IP address obtained from the directory may no longer be assigned to the host that placed the address in the directory. This issue is not specific to LDAP or dynamic directories.
また、それがクライアントによって供給されたディレクトリサーバから得られた情報を利用することでCareを中に入れるべきです、それが現在時代遅れであるときに。 多くのネットワークでは、例えば、IPアドレスは、ホストがネットワークに接続すると自動的に割り当てられて、そのホストが後で切断するなら、再選任されるかもしれません。 ディレクトリから得られたIPアドレスはもうアドレスをディレクトリに置いたホストに割り当てられないかもしれません。 この問題はLDAPかダイナミックなディレクトリに特定ではありません。
11. Acknowledgments
11. 承認
Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups.
本書では含まれていたデザイン考えはASIDと他のIETF Working Groupsで議論したものに基づいています。
Yaacovi, et al. Standards Track [Page 10] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[10ページ]。
12. Authors' Addresses
12. 作者のアドレス
Yoram Yaacovi Microsoft One Microsoft way Redmond, WA 98052 USA
ヨラムYaacoviマイクロソフトOneマイクロソフト道、ワシントン98052レッドモンド(米国)
Phone: +1 206-936-9629 EMail: yoramy@microsoft.com
以下に電話をしてください。 +1 206-936-9629 メールしてください: yoramy@microsoft.com
Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy #4140 Austin, TX 78759 USA
テキサスHwy#4140テキサス78759オースチン(米国)のマークウォールInnosoftの国際Inc.8911Capital
Email: M.Wahl@innosoft.com
メール: M.Wahl@innosoft.com
Tony Genovese Microsoft One Microsoft way Redmond, WA 98052 USA
トニーGenoveseマイクロソフトOneマイクロソフト道、ワシントン98052レッドモンド(米国)
Phone: +1 206-703-0852 EMail: tonyg@microsoft.com
以下に電話をしてください。 +1 206-703-0852 メールしてください: tonyg@microsoft.com
13. Bibliography
13. 図書目録
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (Version 3)", RFC 2251, December 1997.
[1] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(バージョン3)」、RFC2251、1997年12月。
[2] Wahl, M. Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[2] ウォール、M.Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[3] Wahl, M. and S. Kille, "Lightweight Directory Access Protocol
(v3): UTF-8 String Representation of Distinguished Names", RFC
2253, December 1997.
[3] ウォール、M.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。
Yaacovi, et al. Standards Track [Page 11] RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Yaacovi、他 規格は1999年5月にダイナミックなディレクトリサービスのためのRFC2589LDAPv3拡張子を追跡します[11ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Yaacovi, et al. Standards Track [Page 12]
Yaacovi、他 標準化過程[12ページ]
一覧
スポンサーリンク
