Re: LDAP
Julian Onions <j.onions@nexor.co.uk> Wed, 02 June 1993 08:53 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00832; 2 Jun 93 4:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00828; 2 Jun 93 4:53 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03838; 2 Jun 93 4:52 EDT
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 2 Jun 1993 08:44:53 +0100
Date: Wed, 02 Jun 1993 08:44:53 +0100
X400-Originator: osi-ds-request@cs.ucl.ac.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/; haig.cs.uc.519:02.05.93.07.44.53]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Wed, 2 Jun 1993 08:44:53 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Julian Onions <j.onions@nexor.co.uk>
Message-ID: <11410.739007044@nexor.co.uk>
To: pays@faugeres.inria.fr
Cc: tim@terminator.rs.itd.umich.edu, osi-ds@cs.ucl.ac.uk
In-Reply-To: "738973603.7893.0-faugeres.inria.fr":
Subject: Re: LDAP
Discarded-X400-IPMS-Extensions: ccitt (0) data (9) pss (2342) (2342) (19200300) (200) (1)
Let me just undermine a couple of assumptions here :-) > This second kind of alorithm will be less costly than the DE type one > (except if the first token is not matched, in which case the AFRO > type algorithm will cost one additional read compared with the > DE type algorithm), and has the advantages in my mind of > being usable and efficient for simple look-ups as well > as for UFN type look-ups. > > Moreover I imagine that the odds than someone looking for Tim Howes > entry are high that he/she will know that the first token is US, > and are not zero than he/she will provide the "University of Michigan" > second token. I agree that in the examples you give, the search is faster by using this algorithm. However, you are making a number of assumptions I think in that the user is experienced in X.500. Firstly, what the user types is not normally a DN, or something that is close to the DN they want. They typically use abbreviated forms wherever possible. Whilst it might be nice if people typed GB, Nexor Ltd, Julian Onions they are more likely in practice to type UK, Nexor, Onions which misses the DN at every step! A read therefore gets nowhere. Countries it is arguable. GB/UK is certainly a problem case, FR & US the user will probably guess the country DN right (if they know it should be 2 characters - although France & USA/America are equally likely if they don't). However, organisations are likely never to be entered correctly by normal users. This is because longish names are picked for the organisation to ensure uniqness of the RDN. Therefore where I would type "York University" where it is actually "University of York", or "Universite de Lyons" where it is currently "univ-lyon1". Similarly for many other organisations. Therefore it is my guess that the algorithm will for the average user will only match the first component in a UFN search. If the users knows the X.500 structure they can speed it up by typing something closer to the DN, but for me I would rather the computer do the work. So, I think the proposed algorithm is an optimisation over the standard UFN algorithm, but in most cases not an enormous win. So, is it worth the extra effort in the LDAP spec? - left as an exercise for the reader... [ I imagine it just means adding matched LDAPDN OPTIONAL to the LDAPResult structure, if LDAP supports OPTIONAL then this is backwards compatible] Julian.
- 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