draft-ietf-asid-ldapv3ext-02.txt   draft-ietf-asid-ldapv3ext-03.txt 
ASID Working Group Y. Yaacovi ASID Working Group Y. Yaacovi
INTERNET-DRAFT Microsoft INTERNET-DRAFT Microsoft
M. Wahl M. Wahl
Critical Angle Inc. Critical Angle Inc.
K. Settle K. Settle
Microsoft Microsoft
T. Genovese T. Genovese
Microsoft Microsoft
Expires in six months from 14 October 1996
Intended Category: Standards Track Intended Category: Standards Track
Lightweight Directory Access Protocol: Lightweight Directory Access Protocol:
Extensions for Dynamic Directory Services Extensions for Dynamic Directory Services
<draft-ietf-asid-ldapv3ext-02.txt> <draft-ietf-asid-ldapv3ext-03.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 51 skipping to change at line 48
environment. environment.
The Lightweight Directory Access Protocol (LDAP) [1] supports The Lightweight Directory Access Protocol (LDAP) [1] supports
lightweight access to static directory services, allowing relatively lightweight access to static directory services, allowing relatively
fast search and update access. Static directory services store fast search and update access. Static directory services store
information about people that persists in its accuracy and value over information about people that persists in its accuracy and value over
a long period of time. a long period of time.
Dynamic directory services are different in that they store Dynamic directory services are different in that they store
information about people that only persists in its accuracy and value information about people that only persists in its accuracy and value
while people are online. Though the protocol operations and when it is being periodically refreshed. This information is stored
attributes used by dynamic directory services are similar to the ones as dynamic entries and/or dynamic attributes. A typical use will be a
used for static directory services, clients that are bound to a client or a person that is either online - in which case it has an
dynamic directory service need to periodically refresh their presence entry or attributes in the directory, or is offline - in which case
at the server to keep directory entries from getting stale in the its entry or attributes disappear from the directory. Though the
presence of client application crashes. 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 or attributes 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.
In addition, static directories may include dynamic information, in In addition, static directories may include dynamic information, in
the form of dynamic attributes in an otherwise static entry. Such the form of dynamic attributes in an otherwise static entry. Such
information needs to be refreshed periodically in the same manner. information needs to be refreshed periodically in the same manner.
A flow control mechanism from the server is also described that A flow control mechanism from the server is also described that allows
allows a server to inform clients how often they should refresh a server to inform clients how often they should refresh their
their presence. presence.
3. Requirements 3. Requirements
The protocol extensions must allow accessing dynamic directories in a The protocol extensions must allow accessing dynamic information in a
standard LDAP manner, to allow clients to access static and dynamic directory in a standard LDAP manner, to allow clients to access static
directories in the same way. and dynamic information in the same way.
By definition, dynamic entries or dynamic attributes are not By definition, dynamic entries or dynamic attributes are not
persistent and clients may go away gracefully or not. The proposed persistent and clients may go away gracefully or not. The proposed
extensions must offer a way for a server to tell if entries or extensions must offer a way for a server to tell if entries or
attributes are still valid, and to do this in a way that will scale attributes are still valid, and to do this in a way that is scalable.
for a relatively large number of users. There also must be a There also must be a mechanism for clients to reestablish their entry
mechanism for clients to reestablish their entry or attributes with or attributes with the server.
the server.
Finally, to allow clients to broadly use the dynamic extensions, Finally, to allow clients to broadly use the dynamic extensions, the
the extensions need to be registered as standard LDAP extended extensions need to be registered as standard LDAP extended operations.
operations.
4. Description of Approach 4. Description of Approach
The Lightweight Directory Access Protocol (LDAP) [1] permits The Lightweight Directory Access Protocol (LDAP) [1] permits
additional operation requests and responses to be added to the additional operation requests and responses to be added to the
protocol. The support for dynamic directories takes advantage of protocol. This proposal takes advantage of these to support
these to establish a mechanism to support dynamic directories directories which contain dynamic information in a manner which
which is fully integrated with LDAP. is fully integrated with LDAP.
The approach described in this proposal defines dynamic entries and The approach described in this proposal defines dynamic entries and
dynamic attributes in order to allow implementing directories with dynamic attributes in order to allow implementing directories with
dynamic information. An implementation of dynamic directories, must dynamic information. An implementation of dynamic directories, must
be able to support both dynamic directory entries and dynamic be able to support both dynamic directory entries and dynamic
attributes. attributes.
4.1. Dynamic Entries and the dynamicObject object class 4.1. Dynamic Entries and the dynamicObject object class
A dynamic entry is an object in the directory tree which has a 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 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 entry is created. The time-to-live is automatically decremented, and
when it expires the dynamic entry disappears. By invoking the when it expires the dynamic entry disappears. By invoking the refresh
refresh extended operation (defined below) to re-set the time-to-live, a extended operation (defined below) to re-set the time-to-live, a
client can cause the entry to remain present a while longer. client can cause the entry to remain present a while longer.
A dynamic entry is created by including the objectClass value given A dynamic entry is created by including the objectClass value given in
in section 6 in the list of attributes when adding an entry. This section 6 in the list of attributes when adding an entry. This method
method is subject to standard access control restrictions. is subject to standard access control restrictions.
The extended operation covered here, allows a client to refresh a The extended operation covered here, allows a client to refresh a
dynamic entry by invoking at intervals refresh operations containing dynamic entry by invoking at intervals refresh operations containing
that entry's name. Dynamic entries will be treated the same as that entry's name. Dynamic entries will be treated the same as
non-dynamic entries when processing search, compare, add, delete, non-dynamic entries when processing search, compare, add, delete,
modify and modifydn operations. However if clients stop sending modify and modifydn operations. However if clients stop sending
refresh operations for an entry, then the server will automatically refresh operations for an entry, then the server will automatically
and without notification remove that entry from the directory. This and without notification remove that entry from the directory. This
removal will be treated the same as if the entry had been deleted by removal will be treated the same as if the entry had been deleted by
an LDAP protocol operation. an LDAP protocol operation.
There is no way to change a static entry into a dynamic one and vice- 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 versa. If the client is using Modify with an objectClass of
dynamicObject on a static entry, the server must return a service dynamicObject on a static entry, the server must return a service
error either "objectClassModsProhibited" (if the server does not error either "objectClassModsProhibited" (if the server does not allow
allow objectClass modifications at all) or "objectClassViolation" objectClass modifications at all) or "objectClassViolation" (if the
(if the server does allow objectClass modifications in general). server does allow objectClass modifications in general).
A dynamic entry may be removed by the client using the delete A dynamic entry may be removed by the client using the delete
operation. This operation will be subject to access control operation. This operation will be subject to access control
restrictions. restrictions.
A non-dynamic entry cannot be added subordinate to a dynamic entry: A non-dynamic entry cannot be added subordinate to a dynamic entry:
the server must return an appropriate update or service error if this the server must return an appropriate update or service error if this
is attempted. is attempted.
4.2. Dynamic Attributes 4.2. Dynamic Attributes
A similar concept is dynamic attributes. These attributes behave the A similar concept is dynamic attributes. These attributes behave the
same as ordinary user attributes to Search, Compare and Modify same as ordinary user attributes to Search, Compare and Modify
requests, except that if they time out they disappear from the entry requests, except that if they time out they disappear from the entry
in which they are located. (Unlike the dynamicObject class, the in which they are located. (Unlike the dynamicObject class, the entry
entry itself does not disappear, and non-dynamic attributes are itself does not disappear, and non-dynamic attributes are unaffected).
unaffected). Like dynamic entries, a static entry with dynamic Like dynamic entries, a static entry with dynamic attributes must have
attributes must have the entryTtl attribute which is described the entryTtl attribute which is described in section 6 below.
in section 6 below.
Dynamic attributes do not necessarily introduce a new set of Dynamic attributes do not necessarily introduce a new set of
attributes in the schema. Any static attribute in the schema can be attributes in the schema. Any static attribute in the schema can be
made dynamic by including the ;dynamic attribute modifier with the made dynamic by including the ;dynamic attribute modifier with the
typename. It is allowed to introduce new dynamic attributes which typename. It is allowed to introduce new dynamic attributes which are
are not useful in the static domain. Such attributes will still require not useful in the static domain. Such attributes will still require
including the ;dynamic attribute modifier with the typename to define including the ;dynamic attribute modifier with the typename to define
them as dynamic. them as dynamic.
A dynamic attribute may be a subtype of a non-dynamic attribute, ] A dynamic attribute may be a subtype of a non-dynamic attribute, but a
but a non-dynamic attribute must not be a subtype of a dynamic attribute. non-dynamic attribute must not be a subtype of a dynamic attribute.
Operational attributes and collective attributes must not be dynamic. Operational attributes and collective attributes must not be dynamic.
All dynamic attributes are considered to be user attributes, however All dynamic attributes are considered to be user attributes, however
they are not guaranteed to be present in shadow copies of entries. they are not guaranteed to be present in shadow copies of entries.
A client may introduce dynamic attributes into an entry by using a A client may introduce dynamic attributes into an entry by using a
Modify request to add them, or by including them in the attribute Modify request to add them, or by including them in the attribute list
list of an Add Request. If the attribute type is permitted in the entry of an Add Request. If the attribute type is permitted in the entry
then the dynamic attribute is also permitted. The client would then the dynamic attribute is also permitted. The client would
specify that the attribute is dynamic by including the tag ";dynamic" specify that the attribute is dynamic by including the tag ";dynamic"
with the typename. Dynamic values may be changed, and the attributes with the typename. Dynamic values may be changed, and the attributes
removed, by using the Modify request as normal. If the entry is removed, by using the Modify request as normal. If the entry is
deleted, dynamic attributes disappear immediately along with all the deleted, dynamic attributes disappear immediately along with all the
non-dynamic. A ;dynamic modifier on an attribute may not be used in non-dynamic. A ;dynamic modifier on an attribute may not be used in a
a compare request, or in a search request (either in the filter or compare request, or in a search request (either in the filter or
attributes requested for return). This is in keeping with the attributes requested for return). This is in keeping with the
philosophy that dynamic attributes be indistinguishable from static philosophy that dynamic attributes be indistinguishable from static
attributes as much as possible. attributes as much as possible. In such a case, a server is expected
to reject the request, returning 'invalidAttributeSyntax'.
The granularity of a dynamic attribute is the entire attribute The granularity of a dynamic attribute is the entire attribute
including all values. Dynamic and static values may not be mixed including all values. Dynamic and static values may not be mixed
within a single attribute. For example, suppose an existing static within a single attribute. For example, suppose an existing static
entry had an attribute called "ipAddress" with the value "1.2.3.4". entry had an attribute called "ipAddress" with the value "1.2.3.4". A
A modification of the entry to add the value "5.4.3.2" to the attribute modification of the entry to add the value "5.4.3.2" to the attribute
"ipAddress;dynamic" would fail with a "constraintViolation" error. "ipAddress;dynamic" would fail with a "constraintViolation" error.
The addition and modification of dynamic attributes are subject to The addition and modification of dynamic attributes are subject to
schema and access control restrictions, as with non-dynamic schema and access control restrictions, as with non-dynamic
attributes. Thus unless the extensibleObject object class is attributes. Thus unless the extensibleObject object class is present,
present, generally an object class or content rule must be defined generally an object class or content rule must be defined to permit
to permit those attributes to be present in an entry. If their presence those attributes to be present in an entry. If their presence is
is controlled by an object class, then just as with non-dynamic controlled by an object class, then just as with non-dynamic
attributes, the object class value must have already been added attributes, the object class value must have already been added before
before the attributes are added. The dynamicObject object class the attributes are added. The dynamicObject object class described in
described in section 4.1 does not itself permit any particular section 4.1 does not itself permit any particular dynamic attributes.
dynamic attributes.
Dynamic attributes in a particular entry are refreshed using the Dynamic attributes in a particular entry are refreshed using the
Refresh extended operation. All of the entry's dynamic attributes Refresh extended operation. All of the entry's dynamic attributes are
are refreshed by a single refresh request. The TTL given in the refresh refreshed by a single refresh request. The TTL given in the refresh
response applies to all of the entry's dynamic attributes. There is response applies to all of the entry's dynamic attributes. There is
no way to refresh particular dynamic attributes within an entry at no way to refresh particular dynamic attributes within an entry at
different times, or to have different TTLs apply to different dynamic different times, or to have different TTLs apply to different dynamic
attributes. attributes.
If not refreshed, all dynamic attributes in an entry time out If not refreshed, all dynamic attributes in an entry time out
simultaneously. All the attributes which are dynamic with all their simultaneously. All the attributes which are dynamic with all their
values disappear atomically, as if the server had done a ModifyEntry values disappear atomically, as if the server had done a ModifyEntry
specifying that all the dynamic types were to be deleted from that specifying that all the dynamic types were to be deleted from that
entry. The client must not expect any dynamic attributes to be entry. The client must not expect any dynamic attributes to be
present in an entry after the time-to-live for that entry has reached present in an entry after the time-to-live for that entry has reached
zero. However the attributes may not disappear immediately as zero. However the attributes may not disappear immediately as servers
servers may only process timing out attributes at intervals may only process timing out attributes at intervals (e.g. every few
(e.g. every few minutes). minutes).
Note that if an object class definition references a dynamic Note that if an object class definition references a dynamic attribute
attribute as a mandatory attribute, the entry will still time out, as a mandatory attribute, the entry will still time out, but a schema
but a schema inconsistency will be present in that entry. inconsistency will be present in that entry. (The objectClass
(The objectClass attribute and its values always remain attribute and its values always remain since objectClass is not a
since objectClass is not a dynamic attribute.) Thus it is dynamic attribute.) Thus it is strongly recommended that designers not
strongly recommended that designers not specify dynamic specify dynamic attributes as anything other than optional attributes
attributes as anything other than optional attributes
of auxiliary classes. of auxiliary classes.
Dynamic attributes may be used within dynamic entries (i.e., entries Dynamic attributes may be used within dynamic entries (i.e., entries
containing object class "dynamicObject", defined below), but since containing object class "dynamicObject", defined below), but since all
all of such an entry's attributes are implicitly dynamic, such use of such an entry's attributes are implicitly dynamic, such use is
is superfluous. superfluous.
5. Protocol Additions 5. Protocol Additions
5.1 Refresh Request 5.1 Refresh Request
Refresh is a protocol operation sent by a client to tell the server Refresh is a protocol operation sent by a client to tell the server
that the client is still alive and the dynamic directory entry or the that the client is still alive and the dynamic directory entry or the
dynamic attributes of the entry are still accurate and valuable. The dynamic attributes of the entry are still accurate and valuable. The
client sends a Refresh request periodically based on the value of the client sends a Refresh request periodically based on the value of the
client refresh period (CRP). The server can request that the client client refresh period (CRP). The server can request that the client
skipping to change at line 254 skipping to change at line 253
containing an ExtendedRequest. An LDAP ExtendedRequest is defined as containing an ExtendedRequest. An LDAP ExtendedRequest is defined as
follows: follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID, requestName [0] LDAPOID,
requestValue [1] OCTET STRING } requestValue [1] OCTET STRING }
The requestName field must be set to the string The requestName field must be set to the string
"1.3.6.1.4.1.1466.101.119.1". "1.3.6.1.4.1.1466.101.119.1".
The requestValue field will contain as a value the DER-encoding of The requestValue field will contain as a value the DER-encoding of the
the following ASN.1 data type: following ASN.1 data type:
SEQUENCE { SEQUENCE {
entryName [0] LDAPDN, entryName [0] LDAPDN,
requestTtl [1] INTEGER requestTtl [1] INTEGER
} }
The entryName field is the UTF-8 string representation of the name of The entryName field is the UTF-8 string representation of the name of
the dynamic entry or the entry containing dynamic attributes [3]. the dynamic entry or the entry containing dynamic attributes [3].
This entry must already exist. This entry must already exist.
The requestTtl is a time in seconds (between 1 and 31557600) that the The requestTtl is a time in seconds (between 1 and 31557600) that the
client requests that the entry or the dynamic attributes exists in client requests that the entry or the dynamic attributes exists in the
the directory before being automatically removed. Servers are not directory before being automatically removed. Servers are not
required to accept this value and might return a different TTL value required to accept this value and might return a different TTL value
to the client. Clients must be able to use this server-dictated to the client. Clients must be able to use this server-dictated value
value as their CRP. as their CRP.
5.2 Refresh Response 5.2 Refresh Response
If a server implements this extension, then when the request is made If a server implements this extension, then when the request is made
it will return an LDAP PDU containing an ExtendedResponse. An LDAP it will return an LDAP PDU containing an ExtendedResponse. An LDAP
ExtendedResponse is defined as follows: ExtendedResponse is defined as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE { ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
responseName [0] LDAPOID OPTIONAL, responseName [0] LDAPOID OPTIONAL,
response [1] OCTET STRING OPTIONAL, response [1] OCTET STRING OPTIONAL,
standardResponse [2] LDAPResult } standardResponse [2] LDAPResult }
The responseName field contains the same string as that present in The responseName field contains the same string as that present in the
the request. request.
The response field will contain as a value the DER-encoding of the The response field will contain as a value the DER-encoding of the
following ASN.1 data type: following ASN.1 data type:
SEQUENCE { SEQUENCE {
responseTtl [1] INTEGER responseTtl [1] INTEGER
} }
The responseTtl field is the time in seconds which the server chooses 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 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. smaller than that which the client requested, and it may be larger.
Please note that for the case of a static entry with dynamic Please note that for the case of a static entry with dynamic
attributes, this time-to-live applies to all the dynamic attributes attributes, this time-to-live applies to all the dynamic attributes in
in this entry. this entry.
If the operation was successful, the errorCode field in the If the operation was successful, the errorCode field in the
standardResponse part of an ExtendedResponse will be set to success. standardResponse part of an ExtendedResponse will be set to success.
In case of an error, the responseTtl field will have the value 0, and 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 errorCode field will contain an appropriate value, as follows: If
the entry named by entryName could not be located, the errorCode the entry named by entryName could not be located, the errorCode field
field will contain "noSuchObject". If the entry is not dynamic, or will contain "noSuchObject". If the entry is not dynamic, or does not
does not have dynamic attributes, the errorCode field will contain have dynamic attributes, the errorCode field will contain
"objectClassViolation". If the requester does not have permission to "objectClassViolation". If the requester does not have permission to
refresh the entry, the errorCode field will contain refresh the entry, the errorCode field will contain
"insufficientAccessRights". If the requestTtl field is too large, "insufficientAccessRights". If the requestTtl field is too large, the
the errorCode field will contain "sizeLimitExceeded". errorCode field will contain "sizeLimitExceeded".
If a server does not implement this extension, it will return an LDAP If a server does not implement this extension, it will return an LDAP
PDU containing an ExtendedResponse, which contains only the PDU containing an ExtendedResponse, which contains only the
standardResponse element (the responseName and response elements will standardResponse element (the responseName and response elements will
be absent). The LDAPResult element will indicate the protocolError be absent). The LDAPResult element will indicate the protocolError
result code. result code.
This request is permitted to be invoked when LDAP is carried by a This request is permitted to be invoked when LDAP is carried by a
connectionless transport. connectionless transport.
When using a connection-oriented transport, there is no requirement When using a connection-oriented transport, there is no requirement
that this operation be on the same particular connection as any that this operation be on the same particular connection as any other.
other. A client may open multiple connections, or close and then A client may open multiple connections, or close and then reopen a
reopen a connection. connection.
6. Schema Additions 6. Schema Additions
All dynamic entries must have the dynamicObject value in their All dynamic entries must have the dynamicObject value in their
objectClass attribute. This object class is defined as follows objectClass attribute. This object class is defined as follows
(using the ObjectClassDescription notation of [2]): (using the ObjectClassDescription notation of [2]):
( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject' ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'This class, if present in an entry, indicates that this entry DESC 'This class, if present in an entry, indicates that this entry
has a limited lifetime and may disappear automatically when has a limited lifetime and may disappear automatically when
skipping to change at line 351 skipping to change at line 350
SUP top AUXILIARY ) SUP top AUXILIARY )
Furthermore, the dynamic entry or the static entry with dynamic Furthermore, the dynamic entry or the static entry with dynamic
attributes must have the following operational attribute. It is attributes must have the following operational attribute. It is
described using the AttributeTypeDescription notation of [2]: described using the AttributeTypeDescription notation of [2]:
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl' ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'This operational attribute is maintained by the server and DESC 'This operational attribute is maintained by the server and
appears to be present in every dynamic entry or an entry that appears to be present in every dynamic entry or an entry that
contains dynamic attributes. The attribute is not present contains dynamic attributes. The attribute is not present
when the entry does not contain the dynamicObject object when the entry does not contain the dynamicObject object class
class or dynamic attributes. The value of this attribute is the or dynamic attributes. The value of this attribute is the
time in seconds that the entry or the dynamic attributes in a time in seconds that the entry or the dynamic attributes in a
static entry will continue to exist before disappearing from static entry will continue to exist before disappearing from
the directory. In the absence of intervening refresh the directory. In the absence of intervening refresh
operations, the values returned by reading the attribute in operations, the values returned by reading the attribute in
two successive searches are guaranteed to be nonincreasing. two successive searches are guaranteed to be nonincreasing.
The smallest permissible value is 0, indicating that the The smallest permissible value is 0, indicating that the entry
entry may disappear without warning. The attribute is marked may disappear without warning. The attribute is marked
NO-USER-MODIFICATION since it may only be changed using the NO-USER-MODIFICATION since it may only be changed using the
refresh operation.' refresh operation.'
SYNTAX 'Integer' SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) SYNTAX 'Integer' SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
7. Client and Server Requirements 7. Client and Server Requirements
7.1 Client Requirements 7.1 Client Requirements
Once a dynamic entry has been created, clients are responsible for Once a dynamic entry has been created, clients are responsible for
invoking the refresh extended operation, in order to keep that entry invoking the refresh extended operation, in order to keep that entry
present in the directory. The same holds true for keeping dynamic present in the directory. The same holds true for keeping dynamic
attributes present on a static entry. attributes present on a static entry.
Clients must not expect that a dynamic entry will be present in the Clients must not expect that a dynamic entry will be present in the
DIT after it has timed out, however it must not either require that DIT after it has timed out, however it must not either require that
the server remove the entry immediately (some servers may only the server remove the entry immediately (some servers may only process
process timing out entries at intervals). If the client wishes to timing out entries at intervals). If the client wishes to ensure the
ensure the entry does not exist it should issue a RemoveRequest for entry does not exist it should issue a RemoveRequest for that entry.
that entry. Again, dynamic attributes behave the same: they will not Again, dynamic attributes behave the same: they will not be present in
be present in the DIT after they timed out, but the client should not the DIT after they timed out, but the client should not require their
require their immediate removal. immediate removal.
Initially, a client needs to know how often it should send refresh Initially, a client needs to know how often it should send refresh
requests to the server. This value is defined as the CRP (Client requests to the server. This value is defined as the CRP (Client
Refresh Period) and is set by the server based on the entryTtl. Refresh Period) and is set by the server based on the entryTtl. Since
Since the AddRequest is left unchanged and is not modified in this the AddRequest is left unchanged and is not modified in this proposal
proposal to return this value, a client must issue a Refresh extended to return this value, a client must issue a Refresh extended operation
operation immediately after an Add that created a dynamic entry. immediately after an Add that created a dynamic entry. The Refresh
The Refresh Response will return the CRP (in responseTtl) to the client. Response will return the CRP (in responseTtl) to the client.
Clients must not issue the refresh request for dynamic entries which Clients must not issue the refresh request for dynamic entries which
they have not created or for static entries to which they did not add they have not created or for static entries to which they did not add
dynamic attributes. Please note that when a client refreshes a dynamic attributes. Please note that when a client refreshes a static
static entry to which it added dynamic attribute(s), it refreshes ALL entry to which it added dynamic attribute(s), it refreshes ALL the
the dynamic attributes in this entry, including ones added by other dynamic attributes in this entry, including ones added by other
clients. Also note that servers which allow anonymous clients to clients. Also note that servers which allow anonymous clients to
create and refresh dynamic entries and attributes will not be able to create and refresh dynamic entries and attributes will not be able to
enforce the above. enforce the above.
Clients should always be ready to handle the case in which their Clients should always be ready to handle the case in which their entry
entry or dynamic attributes timed out. In such a case, the Refresh or dynamic attributes timed out. In such a case, the Refresh
operation will fail with an error code such as noSuchObject, and the operation will fail with an error code such as noSuchObject, and the
client is expected to re-create its entry or re-add the dynamic client is expected to re-create its entry or re-add the dynamic
attributes. attributes.
Clients should be prepared to experience refresh operations failing Clients should be prepared to experience refresh operations failing
with protocolError, even though the add and any previous refresh with protocolError, even though the add and any previous refresh
requests succeeded. This might happen if a proxy between the client requests succeeded. This might happen if a proxy between the client
and the server goes down, and another proxy is used which does not and the server goes down, and another proxy is used which does not
support the Refresh extended operation. support the Refresh extended operation.
skipping to change at line 440 skipping to change at line 439
Servers may require that a client which attempts to create a dynamic Servers may require that a client which attempts to create a dynamic
entry have a remove permission for that entry. entry have a remove permission for that entry.
Servers which implement this extension must have the OBJECT Servers which implement this extension must have the OBJECT
IDENTIFIERs, described above in section 5 for the request and IDENTIFIERs, described above in section 5 for the request and
response, present as values of the supportedExtension field in the response, present as values of the supportedExtension field in the
root DSE. They must also have as values in the attributeTypes and root DSE. They must also have as values in the attributeTypes and
objectClasses attributes of their subschema subentries, the objectClasses attributes of their subschema subentries, the
AttributeTypeDescription and ObjectClassDescription from section 6. AttributeTypeDescription and ObjectClassDescription from section 6.
An implementation of dynamic directories, must be able to support An implementation of dynamic directories, must be able to support both
both dynamic directory entries and dynamic attributes. dynamic directory entries and dynamic attributes.
8. Implementation issues 8. Implementation issues
8.1 Storage of dynamic information 8.1 Storage of dynamic information
Dynamic information is expected to change very often. In addition, Dynamic information is expected to change very often. In addition,
Refresh requests are expected to arrive at the server very often. Refresh requests are expected to arrive at the server very often.
Disk-based databases that static directory services often use are Disk-based databases that static directory services often use are
likely inappropriate for storing dynamic information. We recommend likely inappropriate for storing dynamic information. We recommend
that server implementations store dynamic entries in memory that server implementations store dynamic entries in memory sufficient
sufficient to avoid paging. This is not a requirement. to avoid paging. This is not a requirement.
We expect LDAP servers to be able to store static and dynamic We expect LDAP servers to be able to store static and dynamic entries.
entries. If an LDAP server does not support dynamic entries, If an LDAP server does not support dynamic entries, it should respond
it should respond with an error code such as objectClassViolation. with an error code such as objectClassViolation. Such a server might
Such a server might still support setting dynamic attributes still support setting dynamic attributes on a static entry.
on a static entry.
8.2 Client refresh behavior 8.2 Client refresh behavior
In some cases, the client might not get a Refresh response. This may 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 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 request, the TCP/IP socket timing out in the connection case, or the
UDP packet getting lost in the connection-less case. UDP packet getting lost in the connection-less case.
It is recommended that in such a case, the client will retry the It is recommended that in such a case, the client will retry the
Refresh operation immediately, and if this Refresh request does not Refresh operation immediately, and if this Refresh request does not
skipping to change at line 485 skipping to change at line 483
10. Security Considerations 10. Security Considerations
Security issues are not addressed in this document. Please note, Security issues are not addressed in this document. Please note,
though, that anonymous clients are able to refresh entries which they though, that anonymous clients are able to refresh entries which they
did not create. did not create.
Also, Care should be taken in making use of information obtained from 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 directory servers that has been supplied by client, as it may now be
out of date. In many networks, for example, IP addresses are out of date. In many networks, for example, IP addresses are
automatically assigned when a host connects to the network, and may automatically assigned when a host connects to the network, and may be
be reassigned if that host later disconnects. An IP address obtained reassigned if that host later disconnects. An IP address obtained
from the directory may no longer be assigned to the host that placed 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 the address in the directory. This issue is not specific to LDAP or
dynamic directories. dynamic directories.
11. Acknowledgments 11. Acknowledgments
Design ideas included in this document are based on those discussed Design ideas included in this document are based on those discussed in
in ASID and other IETF Working Groups. ASID and other IETF Working Groups.
12. Authors Addresses 12. Authors Addresses
Yoram Yaacovi Yoram Yaacovi
Microsoft Microsoft
One Microsoft way One Microsoft way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: +1 206-936-9629 Phone: +1 206-936-9629
 End of changes. 44 change blocks. 
124 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/