Re: LDAP
Tim Howes <tim@terminator.rs.itd.umich.edu> Mon, 07 June 1993 16:46 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29491; 7 Jun 93 12:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29487; 7 Jun 93 12:46 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07675; 7 Jun 93 12:46 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03307-0@haig.cs.ucl.ac.uk>; Mon, 7 Jun 1993 16:07:46 +0100
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.10340-0@bells.cs.ucl.ac.uk>; Mon, 7 Jun 1993 16:07:30 +0100
Received: from vertigo.rs.itd.umich.edu by terminator.rs.itd.umich.edu (5.67/2.2) with SMTP id AA13075; Mon, 7 Jun 93 11:07:12 -0400
Message-Id: <9306071507.AA13075@terminator.rs.itd.umich.edu>
To: osi-ds@cs.ucl.ac.uk
Cc: pays@faugeres.inria.fr
Subject: Re: LDAP
In-Reply-To: Your message of "Wed, 02 Jun 93 09:39:36 BST." <11640.739010376@nexor.co.uk>
Date: Mon, 07 Jun 1993 11:07:10 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>
Ok, here are some comments and my proposal for how to progress LDAP. First, there has been much good discussion lately, the kind of discussion that should have taken place when LDAP first came out. But for various reasons it did not happen until now. The lateness of the arguments does not make them any less valid, though. I believe we should try to incorporate the good ideas raised into the LDAP spec. There have been several issues raised: 1) Various problems in the LDAP documents raised by the RFC editor concerning references to other documents, etc. The only problem here that has not been resolved is the JFIF reference. 2) The list vs. search debate. I believe this has been settled, the consensus being that search is enough. Some people may still not think the two are equivalent, but have agreed that search only is an ok design decision for LDAP. 3) PAP's suggestion to return matched components along with a name error (useful to the AFRO algorithm). There seems to be consensus that this is a useful extension to LDAP. 4) Inclusion of mhsORAddresses attribute in the syntax document. Again, there seems to be agreement that this is useful, and was in fact just an oversight in the original document. Here's my proposed solution: We take LDAP back and make the changes suggested by 3) and 4) above. In addition, we take the opportunity to fix problem 1) in the best way, which is to document the JFIF format in an RFC which the LDAP syntax document can reference. Change 3) will require a change to the LDAPResult structure. I propose this structure: LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), ... noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), isLeaf (35), aliasDereferencingProblem (36), ... other (80) }, matchedDN LDAPDN, errorMessage IA5String } and this additional text: For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax, isLeaf, and aliasDereferencingProblem, the matchedDN field is set to the name of the lowest entry (object or alias) in the DIT that was matched and is a truncated form of the name provided or, if an alias has been dereferenced, of the resulting name. The matchedDN field should be set to a NULL DN (a zero length string) in all other cases. (some text lifted straight from the X.500 standard). I will also change the U-M LDAP implementation to handle the new structure. To make things easier for me and people out there already running LDAP, I suggest we also bump the protocol version number from 1 to 2 (i.e. the LDAP documents will describe version 2 - version 1 will go away as soon as everybody runs the new version). Change 4) should be simply an addition to the LDAP syntax document. I will do this. Does everybody like this proposal? If you don't, speak now or forever hold your peace. Barring any objections from anybody, I will let this list know when the aforementioned changes are complete. -- Tim
- 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