Re: LDAP

[Edwards Reed <[e-mail]>]

re:

Should we return a "matched
name parts" count in complement to the matched attributes? Or an alias
indication?

I'd vote for a matched count.  Thus, if a name
	/c=US/o=Xerox/ou=cin ops/pn=Edwards E Reed
is partially matched by
	/c=US/o=Xerox Corporation/ou=cin ops/pn=Edward E Reed

you would receive an error indicating the match failed (the s is
significant), and that the matched entries were 3 (o=Xerox and 
o=Xerox Corporation being good candicates for aliases).

Also, we've found is useful to discriminate between illegal name 
parts, and unknown name parts...where length or character set
violations are detected.  There, too, the number of valid entries,
or perhaps the number of the invalid entry, can be returned (the
clearinghouse has only 3 parts, so it differentiated between org
and domain with different error numbers - not a reasonable approach
with n-level names).

So, the error structure might look like
	match_function (args...)
	signals_errors(error_number, which, other_info)

where which is the number of successfully matched items, or perhaps
the first item not matched (that would be more intuitive), and
other_info can be an opaque type or printable string of additional
error information....

Something like that...

And oh yes, there needs to be a provision for connectionless directory
lookups if you want LDAP to be a serious contender for name services.
Most directory lookups in the Clearinghouse are connectionless, and that's
allowed us to take our 950 domains to 6 million+ transactions a day on
10 year old hardware.  I saw some discussion along these lines when I 
returned from vacation, and wanted to get my 2 cents in...

Ed Reed

re: PS. Aliases Stink

Well, they're the first indication a person has that we're really talking
about a real database here - one with secondary indexes, where relational
access is what's really desired by users, and where distributed queries
are still very much an experimental kind of thing.  Aliases are really
only a big problem when you try to keep the backward pointers consistent,
and across multiple domains/orgs/countries/whatever, to boot.

We're taking to creating very large full peer replicas of our Clearinghouse
DITs (400-800 domains, or more) and planning to position them at strategic
locations around the company as inverted dl reports repositories, 
performance enhancing caches, and data integrity repositories...figure
three or four in the US, one or two in Europe, and perhaps another in Japan...

This strategy works for us in a peer-peer database scheme, and I suppose
it could be applied to master-slave schemes ala X.500, as well.  

One thing it lets us do is more easily compare DIT information with
network management configuration data (which printers died with disk
crashes, were brought back up with different names, and so their old
registries are obsolete and should now be junked)...