[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Using DAP to support dynamic directories
My opinion is that this document has been hanging around
on the verge of standardization for too long and needs to go
forward without further delay. In fact, I was planning to
issue the last call by the end of the week.
Now, we can take this as a last-call comment and incorporate
the change, or we can defer it to a separate document. It
doesn't much matter to me which of those things happens.
To take the former approach, we have to agree that the
changes are not substantial enough to warrant more discussion
and another last call. To take the latter approach, we just
need to convince ourselves that it makes sense.
Any opinions? -- Tim
Yoram Yaacovi wrote:
> 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.