[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Fwd: I-D ACTION:draft-sermersheim-ldap-subordinate-scope-00.txt
So you two are both saying that I need to add a solicitation mechanism (like a control) so that clients can ask for URIs containing the new scope? I'd rather not... If a referral is to be returned, the only URIs available are LDAP URLs that contain the subord scope, the client did not solicit URIs containing that scope, then the server is stuck * it can't return a referral.
Furthermore, today's server implementations likely don't check stored LDAP URLs (in 'ref' attributes), for critical extensions and exclude them when not solicited * thus it seems some precedent exists where unsolicited LDAP URLs may be sent to clients that cannot be handled.
Let me know if you disagree, or if I'm misunderstanding the wording below.
Jim
>>> Mark Smith <mcs@pearlcrescent.com> 8/16/04 7:17:09 AM >>>
Kurt D. Zeilenga wrote:
> As long as only those wanting to make use of the new feature
> need a newer SDK, I have absolutely no problem with protocol
> extensions which require changes to existing SDKs.
>
> Certainly an old client should choke if they were provided
> an LDAP URL with a subordinate scope (through user input
> or from the server)... but an old client should also choke
> in face of an LDAP URL with a critical subordinate control.
>
> And, I note, both likely might require SDK enhancements
> (most SDKs handle LDAP URLs returned by the server directly).
>
> To me, the implication is that servers should only return
> such URLs when the clients specifically request that they
> be returned.
I agree of course. In my mind the last sentence above goes without
saying. But it does not hurt to say it ;-)
--
Mark Smith
LDAP Book Information: http://www.ldapbook.com/
What's Next: http://www.pearlcrescent.com/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext