draft-ietf-asid-ldap-dynatt-00.txt   draft-ietf-asid-ldap-dynatt-01.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.
T. Genovese T. Genovese
Microsoft Microsoft
Expires in six months from 20 November 1997
Intended Category: Standards Track Intended Category: Standards Track
Lightweight Directory Access Protocol: Lightweight Directory Access Protocol:
Dynamic Attributes Dynamic Attributes
<draft-ietf-asid-ldap-dynatt-00.txt> <draft-ietf-asid-ldap-dynatt-01.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 86 skipping to change at line 87
Finally, to allow clients to broadly use dynamic attributes, they must Finally, to allow clients to broadly use dynamic attributes, they must
be able to find out if a server supports such attributes. be able to find out if a server supports such attributes.
4. Description of Approach 4. Description of Approach
The Lightweight Directory Access Protocol (LDAP) [2] supports the use The Lightweight Directory Access Protocol (LDAP) [2] supports the use
of attributes on entries in the directory. The dynamic extensions of attributes on entries in the directory. The dynamic extensions
draft ([1]) added support for dynamic entries. This proposal takes draft ([1]) added support for dynamic entries. This proposal takes
the attributes model and the dynamic model and merges the two to the attributes model and the dynamic model and merges the two to
provide support for dynamic attributes in a manner which is fully provide support for dynamic attributes in a manner which is fully
compatible with LDAP. compatible with LDAP and with dynamic entries.
The approach taken here is to mark dynamic attributes as dynamic The approach taken here is to mark dynamic attributes as dynamic
(described below), and require clients to refresh these attributes (described below), and require clients to refresh these attributes
periodically in order to guarantee that they will continue to be periodically in order to guarantee that they will continue to be
present on the entry. Dynamic attributes can be set on either a present on the entry. Dynamic attributes can be set on either a
static or dynamic entry, and the time-to-live associated with them static or dynamic entry, and the time-to-live associated with them
applies to ALL the dynamic attributes on an entry, i.e. there is no applies to ALL the dynamic attributes on an entry, i.e. there is no
time-to-live per dynamic attribute. This provides for a more scalable time-to-live per dynamic attribute. This provides for a more scalable
design, and a less complex server implementation. design, and a less complex server implementation.
4.1. Dynamic Attributes 4.1. Dynamic Attributes
Dynamic attributes behave the same as ordinary user attributes to Dynamic attributes behave the same as ordinary user attributes to
Search, Compare and Modify requests, except that if they time out they Search, Compare and Modify requests, except that if they time out they
disappear from the entry in which they are located. Unlike the disappear from the entry in which they are located. Unlike the
dynamicObject class - which is used to mark entries as dynamic, the dynamicObject class - which is used to mark entries as dynamic, the
entry itself does not disappear, and non-dynamic attributes are entry itself does not disappear, and non-dynamic attributes are
unaffected. Like dynamic entries, a static entry with dynamic unaffected. Like dynamic entries, a static entry with dynamic
attributes must have the entryTtl attribute which is described in attributes must have the entryTtl attribute which is described in [1].
[1].
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 option with the AttributeType
typename. It is allowed to introduce new dynamic attributes which are (see AttributeDescription in [1]). This does not require the
not useful in the static domain. Such attributes will still require newly-created subtype to be assigned a different OID. It is allowed
including the ;dynamic attribute modifier with the typename to define to introduce new dynamic attributes which are not useful in the static
them as dynamic. domain. Such attributes will still require including the ;dynamic
option with the AttributeType to define them as dynamic.
A dynamic attribute may be a subtype of a non-dynamic attribute, but a A dynamic attribute may be a subtype of a non-dynamic attribute, 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 list Modify request to add them, or by including them in the attribute 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 option
with the typename. Dynamic values may be changed, and the attributes ";dynamic" with the AttributeType. Dynamic values may be changed, and
removed, by using the Modify request as normal. If the entry is the attributes removed, by using the Modify request as normal. If the
deleted, dynamic attributes disappear immediately along with all the entry is deleted, dynamic attributes disappear immediately along with
non-dynamic. A ;dynamic modifier on an attribute must not be used in all the non-dynamic. A ;dynamic option on an attribute can be used in
a compare request, or in a search request (either in the filter or a 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). When used in this fashion, only the
philosophy that dynamic attributes be indistinguishable from static dynamic values of the attribute will be returned.
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 dynamic subtype
including all values. Dynamic and static values may not be mixed including all values. The supertype attribute may contain static
within a single attribute. For example, suppose an existing static values, but the dynamic subtype must only contain dynamic values.
entry had an attribute called "ipAddress" with the value "1.2.3.4". A This requires some explanation: per [2], an attribute of
modification of the entry to add the value "5.4.3.2" to the attribute "AttributeType;option" is different from the attribute
"ipAddress;dynamic" would fail with a "constraintViolation" error. "AttributeType", e.g. "ipAddress;dynamic" is a different attribute
from "ipAddress". It is a subtype of "ipAddress". Values that are
added into the dynamic variant (subtype) of an attribute are always
regarded as dynamic values. When returned by the server in a search
request, they will be returned as values of the dynamic subtype of the
attribute. See example in section 4.2.
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 present, attributes. Thus unless the extensibleObject object class is present,
generally an object class or content rule must be defined to permit generally an object class or content rule must be defined to permit
those attributes to be present in an entry. If their presence is those attributes to be present in an entry. If their presence 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 before attributes, the object class value must have already been added before
the attributes are added. The dynamicObject object class described in the attributes are added. The dynamicObject object class described in
[1] does not itself permit any particular dynamic attributes. [1] does not itself permit any particular dynamic attributes.
skipping to change at line 186 skipping to change at line 190
objectClass attribute and its values always remain since objectClass objectClass attribute and its values always remain since objectClass
is not a dynamic attribute.) Thus it is strongly recommended that is not a dynamic attribute.) Thus it is strongly recommended that
designers not specify dynamic attributes as anything other than designers not specify dynamic attributes as anything other than
optional attributes of auxiliary classes. optional attributes 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 in [1]), but since containing object class "dynamicObject", defined in [1]), but since
all of such an entry's attributes are implicitly dynamic, such use is all of such an entry's attributes are implicitly dynamic, such use is
superfluous. superfluous.
4.2 Dynamic Atributes Example
Suppose the following attributes are added to a static entry:
Add "1.2.3.4" to ipAddress
Add "3.4.5.6" to ipAddress;dynamic
A request for "ipAddress", will return:
ipAddress: 1.2.3.4
ipAddress;dynamic: 3.4.5.6
A request for "ipAddress;dynamic" will return:
ipAddress;dynamic: 3.4.5.6
5. Protocol Additions 5. Protocol Additions
Support of dynamic attributes in LDAP does not require any protocol Support of dynamic attributes in LDAP does not require any protocol
additions beyond the Refresh request and response which were additions beyond the Refresh request and response which were
introduced in [1]. introduced in [1].
6. Schema Additions 6. Schema Additions
An entry in the directory which has dynamic attributes must have the An entry in the directory which has dynamic attributes must have the
entryTtl operational attribute. In addition, the dynamicSubtrees entryTtl operational attribute. In addition, the dynamicSubtrees
skipping to change at line 342 skipping to change at line 362
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
get a response as well, it will resort to its original Refresh cycle, 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). i.e. send a Refresh request at its Client Refresh Period (CRP).
9. Localization 9. Replication
Replication is only partially addressed in this draft. There is a
separate effort in progress at the IETF on replication of static and
dynamic directories.
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.
10. Localization
The are no localization issues for this extended operation. The are no localization issues for this extended operation.
10. Security Considerations 11. 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 attributes which though, that anonymous clients are able to refresh attributes which
they did not add to an entry. they did not add to an entry.
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 be automatically assigned when a host connects to the network, and may be
reassigned if that host later disconnects. An IP address obtained reassigned if that host later disconnects. An IP address obtained
 End of changes. 11 change blocks. 
26 lines changed or deleted 57 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/