Re: should I modify attribute definition in core.schema to suit my need?

[Zhang Weiwu <zhangweiwu@realss.com>]

On Wed, 2007-05-16 at 00:58 +0200, Pierangelo Masarati wrote:
> Michael StrÃder wrote:
> 
> >> our web application is designed to understand LDAP schema and provider
> >> proper user interface for each syntax. Our web application can
> >> understand syntax 1.3.6.1.4.1.1466.115.121.1.11 which is "Country
> >> String", two printable string characters as listed in ISO 3166. For this
> >> syntax the web application pops up a nice country selector. However when
> >> user enter 'c' (for country, defined in core.schema as *Directory
> >> String*) the web application treat it as all other Directory String,
> >> which is an input box. The users, being confused, typed their country
> >> name manually (like "American" or "U.S.A."), breaking compatibility
> >> because 'c' should be two printable string characters as listed in ISO
> >> 3166.
> > 
> > I'd file an ITS for that.
> 
> This has already been discussed in the past.  Right now, OpenLDAP code
> cannot accept the definition of "c" ("country") as in RFC4519 because
> OpenLDAP erroneously requires attributes derived from a superior to have
> exactly the same syntax of the superior.

I don't understand why 'c' do have the superior 'NAME'. We have another
attribute defined as "Country String" which don't have any superior,
which seems working fine. Why not OpenLDAP change 'c' definition to not
to SUP name and stand on its own?