[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Using DAP to support dynamic directories
Thanks for writing this up, David. It's seems fine to me. I'd like to get
the opinion of the LDAPEXT chairs on whether this should be a part of the
dynamic entries draft or not. I have no problem with making this a part of
the draft.
A couple of comments:
1. You correctly say that the client can REQUEST that the entryTtl will
be set to a provided or default value. However, you should emphasize that it
is up to server to decide whether to set the entryTtl to that value or not.
Clients must be able to use the entryTtl value returned by the server as
their CRP (Client Refresh Period) instead of the one they were trying to
set.
2. Reset the entryTtl to a DSA-defined default value: we're not
supporting this in the dynamic draft and are not requiring LDAP servers to
have such a default. For consistency and simplicity (less options), I
recommend that you remove this option. It will also prevent the different
semantics for resetValue that you mention.
3. The way I see it, the use of the 97 ModifyEntry serves three
purposes: (1) refresh the entry. (2) request a specific entryTtl (3) let the
server inform the client of a new entryTtl, which is used for load
balancing.
I'm forwarding this to the LDAPEXT alias, where this discussion should take
place.
Yoram
-----Original Message-----
From: David Chadwick [SMTP:d.w.chadwick@zetnet.co.uk]
Sent: Wednesday, January 21, 1998 8:14 AM
To: osidirectory@az05.bull.com; ietf-asid@netscape.com; Yoram
Yaacovi
Subject: Using DAP to support dynamic directories
Prior to the December IETF meeting, Yoram and myself spoke at length
about using standard DAP operations to support dynamic directories,
rather than extended operations, so that LDAP and DAP do not diverge
(which neither of us think is a good thing). At the meeting
itself, it was agreed to keep using the extended operations in
LDAP, and Yoram include an empty clause 5.3 in the latest draft, to
say that DAP Modify(97) can also be used. Attached to this email
I have drafted the first version of the full text for this clause,
to
say how standard DAP can be used to support dynamic directories.
I am circulating the draft to both the IETF LDAP group and the
ISO/ITU-T X.500 group, so as to get maximum input and comments. If
the later group has some time in Pheonix next week they might wish
to
discuss this.
I await your replies.
David
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************
Use of X.500(97) DAP to Support Dynamic Entries
The following text is intended to become section 5.3 of
the Internet Draft "Extensions for Dynamic Directory
Services" <draft-ietf-asid-ldapv3-dynamic-07.txt>
5.3 Use of X.500(97) DAP
Dynamic entries can be supported using X.500 DAP, as
follows:
Bind.
The DUA must Bind to the DSA setting the versions
parameter to v2 or higher. (Note. Version v2 is needed to
activate the 1997 enhancements to ModifyEntry.)
Creating the dynamic entry.
The AddEntry operation is used, with the objectClass
attribute containing the value 'dynamicObject'. If the
DSA supports dynamic entries, it will add the dynamic
entry, and set the 'entryTtl' operational attribute to a
pre-defined DSA specific default value.
Refreshing the 'entryTtl' attribute and determining the
CRP
The 97 ModifyEntry operation may be used for three
purposes:
i) to refresh the 'entryTtl' to a client specific value
ii) to reset the 'entryTtl' attribute to the DSA defined
default value
iii) to determine the Client Refresh Period.
A single ModifyEntry operation can be used for a single
or dual purpose. Purposes i) and ii) are mutually
exclusive, and cannot occur in the same ModifyEntry
operation, whereas purpose iii) can be combined with
either purpose i) or purpose ii).
The client can request that the 'entryTtl' attribute be
set to a specific value by either:
a) setting addValue of EntryModification to the new
value, or
b) setting the SEQUENCE of EntryModification to
removeAttribute 'entryTtl' and addAttribute 'entryTtl'
containing the new value.
(Note. Members of the working group should determine
which one of the above is the most preferable, so that we
can remove the other alternative)
The client can request that the 'entryTtl' attribute be
reset to the DSA defined default value by using the
resetValue choice of EntryModification.
(Note that this is implying slightly different semantics
for resetValue when applied to the attribute type
'entryTtl', than in the standard case when it only
applies to attributes having a value with a fallback
context.)
The CRP is determined by setting
EntryInformationSelection in ModifyEntryArgument to
select attribute 'entryTtl'. EntryInformation in
ModifyEntryResult is set to return the CRP value in the
'entryTtl' attribute.