Re: object class to add mail attribute for organization?

[andrew.sciberras@eb2bcom.com]

Hello,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org 
> [mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jyri-Pekka 
> Tähtinen
> Sent: Tuesday, 8 August 2006 11:31 PM
> To: ietf-ldapbis@OpenLDAP.org
> 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 it
> does not contain labeledURI attribute, but by including labeledURIObject
> auxiliary object class you can add URI addresses for organization entries.
> By the way - is the labeledURIObject still valid object class definition?)

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

> Organizations use widely customer service email addresses like
> info@company.com or sales@company.com. That is the reason why I would like
> 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 entries?

There are probably 2 correct ways of doing this. Using the extensibleObject is
certainly one way. It is a standardised definition and will certainly 
allow you
to add your attributes. Using extensibleObject provides you with less control
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). 
This will
also allow you to extend the permitted attributes of an entry whilst allowing
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 the
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 addresses can
be included in organizations and organizational units. LDAP is a very
extensible technology that allows new schema to be defined if a standardised
definition cannot be used. There is nothing wrong with defining new object
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 object
> class?

I suppose that depends on your requirements. I think anyone who is managing a
directory who needs to store objects that contain particular attributes would
define object classes that allow this to be possible. In the case where the
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 the
inetorgperson (rfc2798), pki attributes (rfc4523), etc.

> Best regards,
>
> Jyri
>
> jyri-pekka.tahtinen@netum.fi

Andrew Sciberras, CISSP
eB2Bcom Pty Ltd