[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Using DAP to support dynamic directories
I'd go with either option, but my personal preference would be a separate
document. This way we can get the dynamic entries draft out NOW. We can add
text in section 5.3 that will point to this future doc.
Yoram
-----Original Message-----
From: Tim Howes [SMTP:howes@netscape.com]
Sent: Wednesday, January 21, 1998 2:56 PM
To: Yoram Yaacovi
Cc: 'D.W.Chadwick@iti.salford.ac.uk';
osidirectory@az05.bull.com; ietf-asid@netscape.com; 'ldapext'
Subject: 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.