Re: LDAP

Tim Howes <tim@terminator.rs.itd.umich.edu> Mon, 07 June 1993 19:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02809; 7 Jun 93 15:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02805; 7 Jun 93 15:06 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12215; 7 Jun 93 15:06 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.04102-0@haig.cs.ucl.ac.uk>; Mon, 7 Jun 1993 18:40:41 +0100
Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.07749-0@bells.cs.ucl.ac.uk>; Mon, 7 Jun 1993 18:40:29 +0100
Received: from vertigo.rs.itd.umich.edu by terminator.rs.itd.umich.edu (5.67/2.2) with SMTP id AA15750; Mon, 7 Jun 93 13:40:13 -0400
Message-Id: <9306071740.AA15750@terminator.rs.itd.umich.edu>
To: Christian Huitema <Christian.Huitema@sophia.inria.fr>
Cc: osi-ds@cs.ucl.ac.uk
Subject: Re: LDAP
In-Reply-To: Your message of "Mon, 07 Jun 93 18:31:36 +0200." <199306071631.AA13409@mitsou.inria.fr>
Date: Mon, 07 Jun 1993 13:40:12 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@terminator.rs.itd.umich.edu>

> From:    Christian Huitema <Christian.Huitema@sophia.inria.fr>
> To:      Tim Howes <tim@terminator.rs.itd.umich.edu>

> PS.
> Aliases stink.

Amen to that.

> 	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.
> 
> The alias case is very ennoying. Suppose I provide <CN=Name, OU=Foo, O=Bar,
> C= XX>, and that LDAP returns the "matched attributes" <C=Foobar, C=YY>. How d
> I know whether this matched 2 or 3 components? Should we return a "matched
> name parts" count in complement to the matched attributes? Or an alias
> indication?

I'm not sure about this.  If an alias is involved and there is an error
the aliasProblem error includes the value of the aliasedObjectName, and
not some truncated portion of the original DN, or of the aliasedObjectName.
In this case, the DUA can't tell which component had the bogus alias in it,
but it can tell what the bogus alias is.  How would including an indication
of whether an alias was encountered help this situation?        -- Tim