Re: object class to add mail attribute for organization?

Hello,

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of Jyri-Pekka=20
> T=E4htinen
> Sent: Tuesday, 8 August 2006 11:31 PM
> To: [email protected]
> Subject: object class to add mail attribute for organization?
>
> Hi,
>
> I am trying to find what is the standardized (or recommended) auxiliary
> object class, which permits addition of mail attribute for organization
> entry. Organization object class does not contain mail attribute. (As i=
t
> does not contain labeledURI attribute, but by including labeledURIObjec=
t
> auxiliary object class you can add URI addresses for organization entri=
es.
> By the way - is the labeledURIObject still valid object class definitio=
n?)

The labeledURIObject, as far as I know, is still a valid definition. It w=
as
defined in RFC2079.
The IANA's ldap parameter assignment also lists 'labeledURIObject' as a
registered definition. (It does list it as an attribute definition, inste=
ad of
an object class though... I will chase this up).

>
> Organizations use widely customer service email addresses like
> [email protected] or [email protected]. That is the reason why I would l=
ike
> to add mail attribute to O or OU entry. I am trying to avoid inventing =
new
> object classes nor do I want to turn off schema checking.
> Is extensibleObject a solution to my need? Is it commonly supported by =
LDAP
> servers and recommended way to allow addition of new attributes to entr=
ies?

There are probably 2 correct ways of doing this. Using the extensibleObje=
ct is
certainly one way. It is a standardised definition and will certainly=20
allow you
to add your attributes. Using extensibleObject provides you with less con=
trol
over the entry's contents though, because any user attribute can be added=
 to
the entry (subject to the implementation's access controls).
Another method is to use DIT Content Rules (Section 4.1.6 of RFC4512).=20
This will
also allow you to extend the permitted attributes of an entry whilst allo=
wing
you to retain control of the entry's contents.
Support for the extensibleObject and DITContentRules is not mandated for =
LDAP
Servers.
You could also define a new auxiliary object class; (in order to do this
properly) you will need to create a DIT Content Rule in order to allow th=
e
auxiliary class to be added to the entry.


>
> I am wondering why these important attribute types (labeledURI and mail=
) are
> not included in RFC4519 standard schema for user applications, because =
now
> there is no easy way to add URI addresses or email addresses to
> organizations or organizational units?

RFC4519 hasn't changed the level of ease in which a URI or email addresse=
s can
be included in organizations and organizational units. LDAP is a very
extensible technology that allows new schema to be defined if a standardi=
sed
definition cannot be used. There is nothing wrong with defining new objec=
t
classes that make use of the attributes that you want.


>
> Would it be good idea to collect all often needed attributes, which are=
 for
> historical reasons not part of core standard to one or more auxiliary o=
bject
> class?

I suppose that depends on your requirements. I think anyone who is managi=
ng a
directory who needs to store objects that contain particular attributes w=
ould
define object classes that allow this to be possible. In the case where t=
he
requirement for such an object will apply in many scenarios, people tend =
to
standardise the definition. This can be seen with many objects, such as t=
he
inetorgperson (rfc2798), pki attributes (rfc4523), etc.

>
> Best regards,
>
> Jyri
>
> [email protected]
>
>

Andrew Sciberras, CISSP
eB2Bcom Pty Ltd