Subject: Models: aliases

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 29 Jan 2003 18:49:06 +0100

Is this a correct alias entry:
  dn: o=foo
  objectclass: alias
  aliasedObjectName: o=bar
or should it also contain the attribute
  o: foo
?

If the original entry is correct, it violates 2.2.1 in [Models]:
  These AVAs [in the RDN] are chosen from the attributes of the
  entry.
If "o: foo" should be added, it violates the description of the
'alias' object class (2.6.1), which does not allow attribute 'o'.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 29 Jan 2003 11:03:09 -0800

>or should it also contain the attribute

yes.  And you need another objectClass.

>  These AVAs [in the RDN] are chosen from the attributes of the

Not the case.

>'alias' object class (2.6.1), which does not allow attribute 'o'.

You need to add extensibleObject, an objectClass
which SUPs alias and allows o, or adjust your DIT
content rules to allow o in alias entries.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 30 Jan 2003 22:48:40 +0100

Kurt D. Zeilenga writes:
> which SUPs alias and allows o,

I don't like this: I never needed to do any of this
before - neither with ISODE (X.500) nor OpenLDAP.

It seems rather heavy to force people to get their
own OID and make new object classes just in order
to use aliases, if extensibleObject is not supported
on their server.

> or adjust your DIT

That's not too widely supported yet either, is it?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 Jan 2003 14:24:11 -0800

At 01:48 PM 1/30/2003, Hallvard B Furuseth wrote:
>I don't like this:

Well, there's lots in LDAP/X.500 I don't like... but
this alone is not good reason to change the specification.

>I never needed to do any of this before - neither with ISODE (X.500)

In X.500, the practice (as I understand it) was to
subclass 'alias' as needed.

>nor OpenLDAP.

OpenLDAP release code doesn't verify that the AVAs of
the RDN exist in any case.  It's a bug whose fix is
coming soon.

>to use aliases, if extensibleObject is not supported

Some could publish a "Common subclasses of 'alias'"
technical specification....

>That's not too widely supported yet either, is it?

Not in too many LDAP-only servers (at least one does)...
but, from what I gather, a number of LDAP/DAP servers
do support it.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 31 Jan 2003 12:19:54 +0100

> content rules to allow o in alias entries.

Could you please add that as a note to [Models] 2.6
(Alias Entries)?

BTW, unless someone answered that to my other mail:
Why not another auxiliary class than extensibleObject?

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 31 Jan 2003 12:15:09 +0100

> technical specification....

Good idea.  Though it seems enough with one subclass 'namedAlias'
with several MAY attributes.  I suggest:
- the attributes in the table in [DN] 2.3:
  cn, l, st, o, ou, c, street, dc, uid,
- the other 'SUP name' attributes in [Schema]:
  generationQualifier, givenName, initials, sn, title.
(If the registry approach is used in [DN], any additional attributes
from the registry should be added if there are not too many yet.)

...or a 'namedObject' auxiliary class with those MAY attributes.
What's the advantage of a subclass over an auxiliary class?  Everyone
says subclass, but I like auxiliary classes - they are reusable.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 31 Jan 2003 10:30:14 -0800

>Could you please add that as a note to [Models] 2.6

Yes.

>Why not another auxiliary class than extensibleObject?

Another auxiliary class could be used.  For example,
dcObject could be used to allow "dc=foo" as a naming
attribute.

The reason why structural subclasses of alias are
more commonly used is that structural rules can be
associated with them.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 31 Jan 2003 10:33:19 -0800

At 03:15 AM 1/31/2003, Hallvard B Furuseth wrote:
>with several MAY attributes.

Actually, I think one would one to create one subclass of
alias for each class used in aliased object.  That is,
        personAlias, inetOrgPersonAlias, ...

not
        cnAlias

so that one can better place structure rules/name forms.

>What's the advantage of a subclass over an auxiliary class?

structure rules/name forms.

Kurt