[要約] RFC 2589は、動的ディレクトリサービスのためのLightweight Directory Access Protocol（v3）の拡張についての規格です。このRFCの目的は、ディレクトリサービスの機能を拡張し、より効率的なディレクトリ操作を可能にすることです。
Network Working Group Y. Yaacovi
Request for Comments: 2589 Microsoft
Category: Standards Track M. Wahl
Innosoft International, Inc.
T. Genovese
Microsoft
May 1999
Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory Services
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書では、ダイナミックなディレクトリサービスのための要件を定義し、ダイナミックなディレクトリ環境でのクライアントサーバーの相互運用をサポートするための要求と応答の拡張操作の形式を指定します。
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（Lightweight Directory Access Protocol）は、[1]比較的高速な検索および更新のアクセスを許可する、静的なディレクトリサービスへのLightweightアクセスをサポートしています。長期間に渡ってその精度と価値に固執人々についての静的ディレクトリサービスの情報が格納されます。
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 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.
サーバーからのフロー制御メカニズムは、サーバーが、彼らは彼らの存在をリフレッシュする頻度をクライアントに通知することを可能にすることが記載されています。
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拡張操作として登録する必要があります。
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（Lightweight Directory Access Protocol）は、[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.
この提案に記載されたアプローチは、動的な情報をディレクトリを実現可能にするためにダイナミックエントリを定義します。ダイナミックディレクトリの実装では、動的なディレクトリエントリをサポートすることができなければなりません。
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 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で与えられたオブジェクトクラス値を含むことによって作成されます。この方法は、標準のアクセス制御制限の対象となります。
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.
ここでカバー拡張操作は、クライアントが間隔を置いて、そのエントリの名前を含むリフレッシュ動作を、呼び出すことによってダイナミックエントリをリフレッシュすることができます。検索を処理するときに、ダイナミックエントリは、比較の追加、削除、変更、および識別名の変更操作、非ダイナミックエントリと同じように扱われます。しかし、クライアントがエントリのリフレッシュ動作の送信を停止した場合、サーバーは自動的に通知することなく、ディレクトリからそのエントリを削除します。エントリーは、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のオブジェクトクラスに変更を使用している場合、サーバーはオブジェクトクラスを許可しない場合（（サーバはすべてのオブジェクトクラスの変更を許可しない場合）、または「objectClassViolation」、サーバは「objectClassModsProhibited」のいずれかのサービスエラーを返さなければなりません一般に修正）。
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.
そうでない場合は、静的オブジェクトの動的属性のサポートは、この文書の範囲外です。
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に関連付けられた特定のタイプがありません。動的オブジェクトの属性を使用することにより、一つはこのオブジェクトが実質的に何かを表現することができます。
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.
具体的には、ミーティング（会議）は、動的オブジェクトで表すことができます。フル機能を備えた会議支援がサーバによって特別な意味と取り扱いが必要です（この文書の範囲ではない）が、ここで説明する拡張は、基本的な会議のサポートを提供します。会議オブジェクトは、会議の参加者によってリフレッシュすることができ、それがないときは、会議のエントリが消えます。自然に動的拡張によってサポートされている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.
クリエーター所有の会議は、エントリのためのtime-to-live属性を設定し、それが消えないように、会議のエントリを更新するために、このクライアントの責任であるクライアントによって作成されます。その他には、適切な属性を変更することで、会議に参加するかもしれないが、彼らは、エントリを更新することはできません。エントリを作成し、クライアントが離れて行くとき、それは会議のエントリを削除することができ、またはその生存時間が満了したときにそれが消えることがあります。これは、上述したようdynamicObjectための共通モデルと一致しています。
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.
リフレッシュは、クライアントがまだ生きているとダイナミックなディレクトリエントリは、まだ正確かつ貴重なサーバに伝えるためにクライアントから送信されたプロトコルの動作です。クライアントは、定期的にクライアントのリフレッシュ期間（CRP）の値に基づいて、リフレッシュ要求を送信します。サーバーは、クライアントがこの値を変更することを要求することができます。限り、サーバーがタイムアウト期間内にリフレッシュ要求を受信すると、ディレクトリエントリは、サーバー上で存続することが保証されています。クライアントの実装は、クライアントとサーバ間の介在するネットワークの信頼性が低いことから、リフレッシュ要求パケットが遅延してもよいし、転送中に失われたことに注意する必要があります。この問題が発生した場合、エントリが消えることがあり、クライアントはこれを検出し、エントリを再度追加する必要があります。
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 }
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.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
}
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としてこのサーバー決まる値を使用することができなければなりません。
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 }
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
}
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秒（1日）の最小値まで、クライアントが要求した生存期間値を短縮することが許可されています。
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 errorCode field will contain "insufficientAccessRights". If the requestTtl field is too large, the errorCode field will contain "sizeLimitExceeded".
エラーの場合は、responseTtlフィールドが値0を持つことになりますし、次のようにのerrorCodeフィールドは、適切な値が含まれます：ENTRYNAMEでという名前のエントリが見つからなかった場合は、errorCodeをフィールドには「noSuchObject」が含まれています。エントリは動的でない場合は、errorCodeをフィールドには「objectClassViolationを」が含まれます。依頼者は、エントリを更新する権限を持っていない場合は、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.
サーバは、この拡張機能を実装していない場合には、それだけstandardResponse要素を含むExtendedResponseを、（responseNameおよび応答要素が存在しないであろう）を含むLDAP PDUを返します。 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.
コネクション型トランスポートを使用する場合、この操作は、他と同じ特定の接続上にある必要はありません。クライアントが複数の接続を開く、または閉じた後、接続を再開してもよいです。
X.500/DAP servers can map the Refresh request and response operations into the X.500/DAP Modify(97) operation.
X.500 / DAPサーバは、X.500 / DAP変更（97）の操作にリフレッシュ要求と応答の操作をマッピングすることができます。
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値を持っている必要があります。このオブジェクトクラスは（のObjectClassDescription表記を使用して[2]）は、以下のように定義されます。
( 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 )
（1.3.6.1.4.1.1466.101.119.2 NAME「dynamicObject」DESC「このクラスは、エントリ中に存在する場合、このエントリは限られた寿命を持っていることを示し、その生存時間が0ありに達したときに自動的に消えることがありますクライアントがentryTtl属性の値を供給していない場合、このクラスのない必須属性は、しかし、サーバーはこれを提供しません。」）トップ補助をSUP
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 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 )
（1.3.6.1.4.1.1466.101.119.3 NAME「entryTtl」DESC「この操作属性は、サーバーによって維持され、すべてのダイナミックエントリに存在すると思われる。エントリはdynamicObjectオブジェクトクラスが含まれていない場合に属性が存在しません。この属性の値は、エントリがディレクトリから消え前に存在し続けることを秒単位の時間である。リフレッシュ動作を介在がない場合には、二つの連続検索で属性を読むことによって返された値が非増加されることが保証されている。最小許容値は、エントリが警告なしに消失する可能性があることを示す、0である。それだけリフレッシュ動作を使用して変更することができるので、属性がNO-USER-MODIFICATIONとしてマークされている。」構文1.3.6.1.4.1.1466.115.121.1.27 SINGLE-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「dynamicSubtrees」DESC「この操作属性は、サーバーによって維持され、サーバはこのメモで説明した動的拡張をサポートしている場合、ルートDSEに存在している。属性がのリストが含まれていますサーバが動的拡張をサポートするために、このディレクトリ内のすべてのサブツリー。」SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-変更使用法dSAOperation）
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で説明したオブジェクト識別子が存在するかどうかを確認するために、ルート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（クライアントリフレッシュ期間）として定義され、entryTtlに基づいてサーバによって設定されます。
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操作が変更されないと、この値を返すためにこの提案では変更されないので、クライアントはただちにダイナミックエントリを作成して追加した後のリフレッシュ拡張操作を発行しなければなりません。更新応答は、クライアントに（responseTtl中）CRPを返します。
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としてエラーコードで失敗し、クライアントはそのエントリを再作成することが期待されています。
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で失敗リフレッシュ動作を体験するために準備する必要があります。クライアントとサーバ間のプロキシがダウンした場合に発生する可能性がありますし、別のプロキシを更新拡張操作をサポートしていませんが使用されます。
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.
サーバは、エントリをリフレッシュするために、匿名ユーザーを許可することができます。しかし、リフレッシュ動作の悪用の可能性を排除するために、サーバは、最初にバインドするためにさわやかなクライアントが必要な場合があります。クライアントがエントリーをリフレッシュするために許可されていない場合、サーバーの実装は、entryTtl属性にACLを提示し、そしてRefreshResponseにinsufficientAccessRights（50）を返すことによって、これを達成することができます。これを行う、しかし、サーバー上のパフォーマンスに影響している可能性がありますし、サーバーのスケーラビリティに影響を与える可能性があります。
Servers may require that a client which attempts to create a dynamic entry have a remove permission for that entry.
サーバーは動的なエントリを作成しようとするクライアントは、そのエントリの削除権限を持っていることを必要とするかもしれません。
Servers which implement the dynamic extensions must have the OBJECT IDENTIFIER, described above in section 4 for the request and
オブジェクト識別子を持たなければならない動的な拡張を実現するサーバは、要求のセクション4に上記と
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属性の値として持っており、セクション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のサブツリーの一部だけへの動的拡張のサポートを制限することができます。サーバーは、サーバーが保持しているすべての名前付けコンテキストのための動的な拡張をサポートしている場合は、dynamicSubtrees属性が存在しなくてもよいのセクション5に記述された属性dynamicSubtreesでサポートされているサブツリーのOIDを指定することによって、彼らは拡張をサポートサブツリーいる示しています。
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.
動的な情報は非常に頻繁に変化することが予想されます。また、最新の情報に更新要求が非常に頻繁にサーバーに到着すると予想されています。静的なディレクトリサービスが頻繁に使用するディスクベースのデータベースは、動的な情報を格納するための不適切な可能性があります。我々は、サーバーの実装がページングを避けるために十分なメモリにダイナミックエントリを保存することをお勧めします。これは必須ではありません。
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としてエラーコードで応答する必要があります。
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.
いくつかのケースでは、クライアントは更新の応答を取得しない場合があります。これは、リフレッシュ要求、接続ケースでの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).
このような場合には、クライアントはすぐにリフレッシュ動作を再試行することが推奨されており、このリフレッシュ要求が同様の応答を取得していない場合、それは、すなわち、元のリフレッシュサイクルに頼るそのクライアント・リフレッシュ周期でリフレッシュ要求を送信します（CRP）。
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値を設定することができます。
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が（何秒エントリの有効期限が切れるまで、どのように）相対時間として表現されているので、複製は複製されたエントリが複製時間によって「オフ」になることを意味します。
The are no localization issues for this extended operation.
ザ・この拡張操作のためのローカライズの問題ではありません。
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セキュリティルールとサポートは、この文書で説明する拡張のために適用し、これらの拡張のための特別なセキュリティ上の問題はありません。サーバは、自分が作成していないエントリをリフレッシュするために、匿名のクライアントを許可することができること、しかし、注意してください。サーバはまた、リフレッシュ要求を発行する前にバインドするクライアントを必要とすることにより、エントリへのリフレッシュアクセスを制御することが許可されています。これは、サーバーのパフォーマンスとスケーラビリティに影響を持つことになります。
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.
また、ケアは、それが今古くなっている可能性がありとして、クライアントによって供給されたディレクトリサーバから取得した情報を利用することに注意する必要があります。多くのネットワークでは、例えば、IPアドレスは、ホストがネットワークに接続するときに自動的に割り当てられ、そのホストが後で切断した場合に再割り当てすることができます。ディレクトリから取得したIPアドレスは、もはやディレクトリに住所を置いホストに割り当てられていないことがあります。この問題は、LDAPまたは動的なディレクトリに固有ではありません。
Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups.
この文書に含まれるデザインのアイデアは、ASIDと他のIETFワーキンググループで議論したものに基づいています。
Yoram Yaacovi Microsoft One Microsoft way Redmond, WA 98052 USA
Yoram Yaacoviマイクロソフト一つのMicrosoft方法レドモンド、WA 98052 USA
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
マーク・ワールInnosoftの国際、Inc.の8911資本テキサス州のハイウェイ＃4140オースティン、TX 78759 USA
Email: M.Wahl@innosoft.com
メール：M.Wahl@innosoft.com
Tony Genovese Microsoft One Microsoft way Redmond, WA 98052 USA
トニー・ジェノベーゼマイクロソフト一つのMicrosoft方法レドモンド、WA 98052 USA
Phone: +1 206-703-0852 EMail: tonyg@microsoft.com
電話：+1 206-703-0852電子メール：tonyg@microsoft.com
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (Version 3)", RFC 2251, December 1997.
[1]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（バージョン3）"、RFC 2251、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）：属性の構文定義"、RFC 2252、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文字列表現"、RFC 2253、1997年12月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。