[Date Prev][Date Next] [Chronological] [Thread] [Top]

LDAP Subentry and naming

During the LDUP discussion of the LDAP Subentry draft <http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-02.txt>
the matter of naming attributes came up again, and we need to settle what the draft needs to say.

Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory.  Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN.  The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry.

Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above.

There might be several possible solutions:

1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named.
2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users;
3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators.

Option 1 takes ldapSubEntry further and further away from the X.500 definition.  That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted.

Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room.  At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem?

Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance.  LDUP doesn't particularly care.  That would mean leaving it as it is (I think).

Please reply by 23 April with your feelings, if you care.  If not, stay tuned to see what develops.  I plan to submit this for last call by the end of April, 2000.

Regards,
Ed Reed

Disposition-notification-to: anil.srivastava@Eng.Sun.COM
Received: from threadgill.austin.innosoft.com ([207.8.108.5])
 by INNOSOFT.COM (PMDF V6.0-24 #9441)
 with ESMTPS id <01JNMGPO5R809KMZ1J@INNOSOFT.COM> for
 ldapext-archive@pipe.thor.innosoft.com
 (ORCPT ldapext-archive@critical-angle.com); Wed,
 29 Mar 2000 23:56:42 -0800 (PST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
 by austin.innosoft.com (PMDF V5.2-32 #41296)
 with ESMTP id <0FS800F6I67OWP@austin.innosoft.com> for
 ldapext-archive@pipe.thor.innosoft.com
 (ORCPT rfc822;ldapext-archive@critical-angle.com); Thu,
 30 Mar 2000 01:59:49 -0600 (CST)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.8.5/8.8.5) with ESMTP id XAA11911	for
 <ldapext-archive@critical-angle.com>; Wed, 29 Mar 2000 23:51:35 -0800 (PST)
Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3)
 id XAA12988 for ldapext-archive@critical-angle.com; Wed,
 29 Mar 2000 23:56:38 -0800 (PST)
Resent-date: Wed, 29 Mar 2000 23:56:38 -0800 (PST)
Date: Wed, 29 Mar 2000 23:56:00 -0800
Resent-from: ietf-ldapext@netscape.com
From: Anil SRIVASTAVA <anil.srivastava@Eng.Sun.COM>
Subject: Re: LDAP Subentry and naming
Resent-sender: ietf-ldapext-request@netscape.com
To: Ed Reed <eer@OnCallDBA.COM>, ietf-ldup@imc.org, ietf-ldapext@netscape.com
Resent-message-id: <3rGj0.A.CID.tiw44@glacier>
Message-id: <009c01bf9a1d$6c08ac20$d4c0d0a9@aus.sun.com>
Organization: Sun | Netscape Alliance (http://www.iPlanet.com)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
Precedence: list
X-Loop: ietf-ldapext@netscape.com
References: <s8e2a40b.092@mail.oncalldba.com>
X-Mailing-List: <ietf-ldapext@netscape.com>

I would vote for option 1.  Not too hung up on the name and ldapSE sounds as
good as any other.
_________
Anil Srivastava
anil.srivastava@Eng.Sun.COM

----- Original Message -----
From: "Ed Reed" <eer@OnCallDBA.COM>
To: <ietf-ldup@imc.org>; <ietf-ldapext@netscape.com>
Sent: Wednesday, March 29, 2000 11:46 PM
Subject: LDAP Subentry and naming


During the LDUP discussion of the LDAP Subentry draft
<http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-02.txt>
the matter of naming attributes came up again, and we need to settle what
the draft needs to say.

Mark Wahl notes that some vendors have objected that CN is a poor choice for
naming ldapSubEntry entries in the directory.  Since they'll not be visible
to users and administrators, unless specifically requested, they'll be in a
position to cause mysterious naming clashes with other entries named by CN.
The example being that if an ldapSubEntry exists with the name CN=fred, and
an administrator attempts to create a person with CN=fred, the administrator
will likely get a "duplicate entry name" like error (there's already an
entry with the name CN=fred), but the administrator won't see the subentry.

Since many ldapSubEntry entries will be created automatically by software in
the operation of the directory, it's reasonable to name them something that
won't cause such mysterious seeming errors as the one described above.

There might be several possible solutions:

1) define a new attribute, say ldapSE, of type DirectoryString, with which
ldapSubEntry entries may be named.
2) leave supplying of the naming attribute to developers who use an
ldapSubEntry class to hold their information - this seems troublesome, as
the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule
is likely to be required, which could get in the way of subsequent users;
3) punt, and leave it the way X.500 defines it, and leave experiments
surrounding solving this problem to future innovators.

Option 1 takes ldapSubEntry further and further away from the X.500
definition.  That's not a problem to the author, if that's desireable
because we've learned a change to the X.500 model is warranted.

Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY
class itself, instead of a STRUCTURAL class, but I confess I don't
understand the nuances being navigated by the X.500 vendors in the room.  At
any event, this would be an even more serious diversion from the original
X.500 model Subentry class definition, wouldn't it? - is that a problem?

Option 3, it seems to me, should be our fall back if concensus can't be
reached quickly - by the end of April, for instance.  LDUP doesn't
particularly care.  That would mean leaving it as it is (I think).

Please reply by 23 April with your feelings, if you care.  If not, stay
tuned to see what develops.  I plan to submit this for last call by the end
of April, 2000.

Regards,
Ed Reed