[KLUG Members] Pesky LDAP

[Eric Anderson]

*This message was transferred with a trial version of CommuniGate(tm) Pro*
My observation about using previously defined standard syntaxes was again,
just for standard attributes, and not for custom fields.

As far as avoiding extending the schema as a whole...I guess it's just a
preference thing. If you need a place to store the data, you'll do it.

And if you don't...well...

adam@morrison-ind.com wrote*:
>
>*This message was transferred with a trial version of CommuniGate(tm) Pro*
>>I wouldn't think that adding to a schema to extend it would be a problem.
>
>It breaks down interoperability,  which is the whole point of LDAP.  One can
use
>Ximian Evolution, Pine, M$-Outlook (other than that I wish a pox on such
>people), Eudora, IMP, Mutt, etc...  If you extend the schema for "standard"
>attributes you basically have done nothing but created a new M$-Exchange.
And
>the world already has one to many of those.
>
>>If the remote clients don't know that the data is in the directory, it
really
>>shouldn't matter.
>
>Well... except that they can't see it.
>
>>You can also use the preexisting OID's to extend the
>>schema and define the syntax, depending on what you need.
>
>No, you can't use preexisting OIDs,  that is a ****clear**** violation of the
>rules.  If your a .com, .org, .net, etc... you can get your own OID for FREE
>(and I'd hurry up and do it because who knows how long that will last).  The
>1.1.x OID space is dead,  so you can use that for experimental purposed and
>*temporary* definitions.  But the crux is that all attributes and object
class
>OIDs must be globally unique, and the only way to do that is to register
(which
>is free, BTW).
>
>But still, schema extending should be avoided wherever possible.
>_______________________________________________
>Members mailing list
>Members@kalamazoolinux.org
>
>

--
Eric Anderson
LanRx Network Solutions
815-505-6132