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.