Re: LDAP
Edwards Reed <Ed.Reed@cinops.xerox.com> Mon, 07 June 1993 22:08 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06181; 7 Jun 93 18:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06177; 7 Jun 93 18:08 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa18109; 7 Jun 93 18:08 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.04860-0@haig.cs.ucl.ac.uk>; Mon, 7 Jun 1993 22:33:21 +0100
Received: from alpha.Xerox.COM by bells.cs.ucl.ac.uk with Internet SMTP id <g.10453-0@bells.cs.ucl.ac.uk>; Mon, 7 Jun 1993 22:33:13 +0100
Received: from slap.cinops.xerox.com ([13.180.0.107]) by alpha.xerox.com with SMTP id <11653>; Mon, 7 Jun 1993 14:32:52 PDT
Received: from cinops.xerox.com by slap.cinops.xerox.com id <11268-0@slap.cinops.xerox.com>; Mon, 7 Jun 1993 17:32:42 -0400
To: tim@terminator.rs.itd.umich.edu, Christian.Huitema@sophia.inria.fr
Subject: Re: LDAP
Cc: osi-ds@cs.ucl.ac.uk
Date: Mon, 07 Jun 1993 14:32:42 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Edwards Reed <Ed.Reed@cinops.xerox.com>
X-Orig-Sender: Ed.Reed@cinops.xerox.com
Message-Id: <93Jun7.143252pdt.11653@alpha.xerox.com>
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)...
- LDAP Erik Huizer
- Re: LDAP pays
- Re: LDAP Tim Howes
- Re: LDAP Tim Howes
- Re: LDAP pays
- Re: LDAP Christian Huitema
- Re: LDAP Julian Onions
- Re: LDAP Julian Onions
- Re: LDAP pays
- Re: LDAP Mark Prior
- Re: LDAP Tim Howes
- Re: LDAP Christian Huitema
- Re: LDAP Tim Howes
- Re: LDAP Edwards Reed
- Re: LDAP Tim Howes
- Re: LDAP Tim Howes
- Re: LDAP Brien L. Wheeler
- Re: LDAP Steve Kille