Tim Howes <> Mon, 07 June 1993 16:46 UTC

Received: from 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 by CNRI.Reston.VA.US id aa07675; 7 Jun 93 12:46 EDT
Received: from by with local SMTP id <>; Mon, 7 Jun 1993 16:07:46 +0100
Received: from by with Internet SMTP id <>; Mon, 7 Jun 1993 16:07:30 +0100
Received: from by (5.67/2.2) with SMTP id AA13075; Mon, 7 Jun 93 11:07:12 -0400
Message-Id: <>
Subject: Re: LDAP
In-Reply-To: Your message of "Wed, 02 Jun 93 09:39:36 BST." <>
Date: Mon, 07 Jun 93 11:07:10 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <>

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 ::=
		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