[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Comments to <draft-sermersheim-ldap-chaining>

Jim Sermersheim wrote: 
I have to admit that I disliked the names and limited usefulnes of the
controls as they are defined in X.511, and that may have influenced me
to simply define them in a symmetrical and (to me) more clear way for
LDAP.


Fair enough, I can appreciate symmetry...

I see usefulness in chainingRequired. For example, assume a client
wishes to perform a SSS or VLV search operation and knows that the data
in the result set may be distributed (and perhaps further assume some
DSAs support chaining these operations). If the client can specify
chainingRequired, it would know that the results it gets back are
already sorted and no extra work needs to be done. If the server cannot,
or will not chain, then the operation fails, and the client learns this
up front. In the absence of chainingRequired, the client may get back
many search results -- assuming they're sorted, only to find out in the
end that one or more search result references need to be followed to
complete the operation.

I believe you're seeing a false economy here. The point is, why did the client ask the question it asked - presumably, because it wanted some data. If your client sends a request with e.g. SSS, the server will proceed to gather results up, find that it can't obey the Chaining control, and return an error to the client. But as far as I can see, the client still wanted that data, else why did it ask in the first place. The client can just give up and say "sorry, I can't get what you want in my preferred fashion" but the more useful thing for it to do is to retry the request and make do with whatever results it gets. In that case, you've just doubled the amount of work the server has to do, because the client will re-issue the same request, with relaxed controls. Nothing changes the fact that extra work needs to be done by the client, (or it must just fail); the presence of the control doesn't help matters in any way.

Also, this SSS example isn't quite right - obviously a server needs to gather up the complete result set before it can begin returning sorted results to the client. As such, it will already know if references are present before sending any results to the client. It would be wrong for the server to begin sending entries back knowing that the result set contains unresolved references, so that search should automatically fail in the absence of chaining. Indeed, RFC2891 pretty much dictates that the request will fail, in section 2.1. In this regard, I would prefer that that spec be changed to require servers to send unresolved references first, ahead of regular entries, and let the client decide whether it wants to slog through or give up. Cutting off the information at the server prevents the DUA user from making an informed decision about what to do next. Giving the information to the client allows the possibility of a graceful recovery.

> I believe that chainingRequired may also be 
useful for other multi-object operations which are served best (or can
only be completed) by the act of DSA chaining. Off the top of my head, I
can't think of a strong case for chainingRequired during name resolution
(otehr than the case I make below for referralsPreferred), but I see no
harm in allowing it's specification.

I believe the harm is in preventing useful information from reaching the client, thus making error recovery messier and more expensive than it needs to be.

I also see usefulness in referralsPreferred. It allows one to possibly
override whatever the server's behavior is.  We have deployments where
the server's setting is chainingPreferred or chainingRequired. Clients
may prefer to receive referrals, yet want the operation to be chained
when policy prevents a referral from being returned.

To me, the absence of any chaining control already implies "referralsPreferred" but I'll have to think about it some more. It becomes useful if you assume that the client knows more about the referred server than the original DSA knows. Personally I believe this assumption is seldom true, but I guess I can't say "never" so I'll leave this alone for now.

--
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext