Re: LDAP Comments

[Valdis Kletnieks <[e-mail]>]

On 05 May 1993 22:07:46 EDT, [e-mail] said:
> last point: what I really want to avoid is to have DS client
>    developers to use search operations, when a simple read
>    (or a base object-search) could do the trick. My experience

OK.. I'll freely admit that most of my X.500 experience has been
digging inside QUIPU and trying to make it run, and I'm a bit weak
on a few parts of the protocol.  However, it seems to me that
(as Tim Howes pointed out) 'read' and 'based search' can be implemented
in terms of 'search'.  Therefor, with proper design of the LDAP end,
you can guarantee that "something correct" will get returned for
any given search, whereas if you do "a simple read", you have to
know a priori that 'simple read' will (a) work and (b) return the
desired information.

Unfortunately, this seems to be a classic bootstrap problem - you
can't be sure that a 'read' is the desired operation unless you
already know - in which case the read itself is superfluous.

I'm pretty convinced that (a) using 'search' as the generic primitive
is proper, (b) any DSA that can't handle 'search' effectively needs
some development work done.  I'm more than willing to entertain
arguments to the contrary, but they should be accompanied by
pseudo-code of how to determine that 'read' should be used at any
given point.  Said pseudo-code should not include anything of
the form 'if pizzaro then' or other unknowable special cases - 
if it can't be determined by mere syntactic analysis of the DN
in question, it's improper. So for instance, saying "at first
two levels, do this, at 3rd or lower do that instead" is OK.
It's also OK to say 'if level1 is 'C=something' do this else
if level1 is 'O=something' do this, but only for *all* values
of 'something' - special-casing "if level1 is '@o=Dingbats'" because
that top-level org is managed by Fred's Cut-Rate X.500 DSA is a
bad idea - they might upgrade to a real product. ;)

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech