[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: object class 'alias'
Simply put, we don't. I don't recall the question coming up, but that simply
reflects the particular application set to which our directories have been
applied.
=================
Ed Reed, Technologist
Novell Product Management
+1 801 222 3944 (new number!)
>>> "David Chadwick" <d.w.chadwick@salford.ac.uk> 07/17/1999 08:28:15 >>>
Date forwarded: Thu, 15 Jul 1999 08:46:38 -0700 (PDT)
Date sent: Thu, 15 Jul 1999 05:51:46 -0600
From: "Ed Reed" <ED_REED@novell.com>
To: <Harald@Alvestrand.no>, <Kurt@OpenLDAP.Org>
Copies to: <bgreenblatt@dtasi.com>, <M.Wahl@INNOSOFT.COM>,
<ietf-ldapext@netscape.com>
Subject: Re: object class 'alias'
Forwarded by: ietf-ldapext@netscape.com
> We were careful in implementing our alias support to ensure that the
> object class of the entry referenced by the alias would govern the naming
> rules for the alias which referenced it.
There is however one problem with this. One good use of aliases is
for organisation aliases to point to OUs and vice versa. How do you
cope with this?
For this reason it is recommended that you make structural
subclasses of the alias object class, and attach structure rules to
this. Then the alias and aliased objects have their own independent
structure rules.
David
>
> This makes sense - the naming rules for person should govern aliases which
> point to entries of type person. Thus, you can't use the naming rules
> for, say, organizationalUnits for an alias which refers to a person.
>
> That all assumes, of course, that you actually implement naming rules, and
> don't let entries be created willy-nilly with any combination of
> attributes that strike the fancy of whomever uttered the "add entry"
> request. Personally, such behaviour seems unseemly to me, but I
> understand there are alternative lifestyles which tolerate such behavior.
>
> I really thought alias was "special", like top, with no super
> class...perhaps that goes back to the '88 spec. But the '97 draft which I
> inspected does, indeed, consider it a subclass of Top. I suspect that
> makes sense where ACL attribute has been added to Top so that alias
> entries can, themselves, have ACLs...(no, I'm not trying to start a fight
> ;-)
>
> Ed
>
>
>
> ============================
> Ed Reed, Technologist
> Novell Product Management
> +1 801 861 3320
>
> >>> Harald Alvestrand <Harald@Alvestrand.no> 07/14/99 11:46PM >>>
> At 08:21 14.07.99 -0700, Kurt D. Zeilenga wrote:
> >At 05:35 PM 7/13/99 +0200, Harald Alvestrand wrote:
> > >At 07:33 12.07.99 -0500, Mark Wahl wrote:
> > >
> > >>My mistake in 2252: alias is not abstract. Thanks for finding this ,
> > >>Kurt. In the next release section 4.4 will read
> > >>
> > >> In general every entry will contain an abstract class ("top"), at
> > >> least one structural object class, and zero or more auxiliary
> > >> object classes.
> > >
> > >Does this mean that all objects of type "alias" are also of type "top"?
> >
> >Yes, rfc2256:
> > ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName
> > )
>
> Formally, I think alias should have been abstract.
> With no attributes, you can't name it (having a DN for an RDN seems a bit
> ...perverted?)
>
> In reality, I've suspected that people treat it like the "anything
> goes" class, adding naming attributes as needed.
> Can some current users of alias disabuse me of this notion, please?
>
> Harald
>
> --
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no
>
>
>
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Ed Reed
TEL;WORK:801-222-3944
ORG:;Product Management
TEL;PREF;FAX:801-222-3941
EMAIL;WORK;PREF;NGW:ED REED@novell.com
N:Reed;Ed
TITLE:Technologist
ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Ed Reed=0A=
ORM-A-211
X-GWUSERID:ED REED
END:VCARD