[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LAST CALL: draft-ietf-asid-ldapv3-simplepaged-02.txt
> Date: Fri, 27 Feb 98 01:03:06 EST
> From: "Kim J. Worm" <kjworm@VNET.IBM.COM>
> To: ietf-asid@umich.edu
> Subject: RE: LAST CALL: draft-ietf-asid-ldapv3-simplepaged-02.txt
> I would like to see some comments regarding the interactions of the use of
> paged results and the chasing of referrals.
---big snip here
> How do we intend to make C API implementations which can reliably handle
> automatic referral chasing and keep them ignorant of the meanings of
> server controls, or was that not even intended when controls were devised?
>
Kim, you raise a very good point here.
There is of course one relatively simple solution, and that is to do
sequential handling of referrals in the API code rather than (as I
assume you had assumed) to do parallel handling of referrals. There
will of course be a time penalty attached to the former, from the
user's perspective, but only one set of paged results cookies will
be returned at a time. The alternative could be to allow the handle
to have sub-handles returned in the case of parallel referral
chasing. Each sub-handle will refer to each of the parallel
referrals, so that the API needs to pass the cookie and the
sub-handle on each paged result request/response.
David
> Regards,
> Kim J. Worm
>
>
>
***************************************************
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
***************************************************