If you want to use a different convention that those defined in the schemas or RFCs, it's best to create your own attribute and your own schema and use it.  Register your OID too if you want to use it or every have anyone else reference it outside of your own location.

Changing schemas or using attributes differently from how they were designed is a recipe for headache in the future.

ref:
http://www.openldap.org/doc/admin24/schema.html
http://support.novell.com/techcenter/articles/ana20010904.html
Sellers

On Jul 24, 2008, at 7:17 AM, Mavric Domen wrote:



>
> Or use 'co' (friendlyCountryName) from cosine.schema instead,
> though a 'c' attribute is required as well for
> friendlyCountry objects.
>
> Or if renaming the DIT is not feasible in the short run, edit
> core.schema for now and put back the OpenLDAP 2.3 definition
> of 'c', which came from RFC 2256.  OpenLDAP 2.4 uses the RFC
> 4519 definition, which matches the X.500 definition.  Note
> that editing an existing attribute's schema definition also
> requires a slapcat/slapadd.
> This will not interoperate with other software which expect
> 2-letter 'c' attributes, so you do need to move away from
> your current DIT.
>
> Maybe attributes exist somewhere for 3-letter and numberic
> 3-digit country codes as well.  If not, you could submit an
> internet-draft for such attributes.  Or suggest changing 'c'
> to allow both 2- and 3-letter codes, though I doubt that
> would be accepted.  The latter would also need to be
> coordinated with an X.500 change.
>
> --
> Hallvard
>

Hi,

I've already considered the "co" option, but in fact, there is too much
effort, because in that case also  applications (many of them) should be
modified and unfortunatelly the "c" part of the suffix is hardcoded ;( .

Your second suggestion about core schema changes seems to be the easiest
way - there is almost nothing to do.
So, all existing c values stays as they are (2+ letters), on fresh
OpenLDAP 2.4 installations the values of "c" could be limited to 2
letters (although the schema would allow more).
But, changing the core schema doesn's seem to be a good practice? If I
still do that, what kind of unpredictable situations might I be
confronted with?

Thanks for your quick response!
Domen


++++++++++++++++++++++++++++++++++++++
Chris G. Sellers |  Internet Engineer      |   NITLE
734.661.2318 |  chris.sellers@nitle.org
Jabber: csellers@nitle.org  | AIM: imthewherd