Subject: which naming attribute ...

From: sanjay jain <[email-masked]>
Date: Tue, 10 Oct 2000 17:49:19 -0700

which naming attribute can be used to create alias objects ?

thanks

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 10 Oct 2000 18:04:22 -0700

>which naming attribute can be used to create alias objects ?

Seeing as how this is the definition:

    ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )

I would think that the list of choices would be pretty small (i.e. just 
aliasedObjectName)...

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Oct 2000 19:02:30 -0700

>which naming attribute can be used to create alias objects ? 

There is not yet a Standard Track specification for representing
aliases in the directory; however, there was an I-D on this
subject at one time.  In OpenLDAP, we support "named" alias
objects (derived from "named" referral object I-Ds).

That is,
        dn: cn=john doe, dc=example, dc=net
        objectclass: alias
        objectclass: extensibleObject
        cn=john doe
        aliasedObjectName: cn=jane doe, dc=example, dc=net

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 11 Oct 2000 13:12:00 +1100

Sanjay,

Any desired naming attribute could be introduced by:

(1) subclassing the alias object class,
(2) defining an auxiliary object class with the naming attribute and
    adding the auxiliary class to the alias entry, or
(3) putting the naming attribute in a DIT content rule for the alias
    object class.

I lean towards (1).

I think there might be implementations that require the naming attribute
type of the alias to be the same as the aliased entry's naming attribute.
You might want to conform to that.

Regards,
Steven

---

From: sanjay jain <[email-masked]>
Date: Wed, 11 Oct 2000 09:58:39 -0700

"Kurt D. Zeilenga" wrote:

> aliases in the directory;

You mean 'alias' object class defn in RFC 2256, which is
same/similar to X.500 (93) defn, is not enough to create alias
objects in an LDAP directory AND there would be, in future,
another doc on this topic ?
Is support for aliases a MUST for LDAP V3 ?
Although, my understanding is that LDAPBIS is going to define
more specifically what is LDAP V3.

sanjay

> however, there was an I-D on this

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Oct 2000 10:28:11 -0700

At 09:58 AM 10/11/00 -0700, sanjay jain wrote:

>objects in an LDAP directory

I think this whole thread answers that question.

>AND there would be, in future,

Yes.

>Is support for aliases a MUST for LDAP V3 ?

No.

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 11 Oct 2000 12:08:30 -0700

Sanjay,

As I recall, in Novell's implementation (the Novell guys can correct me if 
I'm misremembering),  NDS enforces the naming rules mandated by the base 
class of the object the Alias points to.  So, if the alias points to a user 
object, you could use the cn attribute as a naming attribute.  Similarly, 
if the alias points to an organizationalUnit object, you could use the ou 
attribute as a naming attribute.  This behaviour is unique to Novell's 
implementation.  In other implementations, you should use the 
aliasedObjectName as the naming attribute.

Bruce

---

From: sanjay jain <[email-masked]>
Date: Wed, 11 Oct 2000 15:48:52 -0700

> >Is support for aliases a MUST for LDAP V3 ?

Please clarify few more things for me.  Thanks.
Which of the following are MUST for LDAP V3 ?

   - support for multiple AVAs in an RDN
   - server should be able to recognize an attribute by its OID
   or any of its textual names in the protocol (In DNs, attribute names
   in update operations, in required attr list and in filters etc..)
   - support for renaming (moddn) of a non-leaf node

thanks

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Oct 2000 17:04:05 -0700

>Which of the following are MUST for LDAP V3 ?

In my opinion, vendors have a good deal of freedom
when implementing LDAPv3.  I do, however, advocate that
vendors implement not only all the MUSTs, but most of
the SHOULDs, and many of the MAYs.

>   - support for multiple AVAs in an RDN

optional.  A server can return unwillingToPerform or
other suitable resultCode if it is unwilling to accept
multiple AVAs in an RDN as the target or base DN of an
operation.  However, as a value of user attribute or
in a filter, it should accept it for any attribute of
DN syntax it publishes support for.

I know of a few implementations which do not support
multi-valued RDNs.

>   in update operations, in required attr list and in filters etc..)

Off hand, I'd say 'optional'.  As previously noted, there is
plenty of play in the specification.

I know of many implementations which do not support OID/NAME
equivalences in all protocol elements.

>   - support for renaming (moddn) of a non-leaf node

Optional.  A server can return unwillingToPerform or
other suitable resultCode if it is unwilling to perform
the requested operation.

I know of many implementations which do not support
renaming of subtrees.