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. In the case of RFC4519:2.2.

( 2.5.4.6 NAME 'c' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE )

(note that 'country' is no longer listed), the syntax 1.3.6.1.4.1.1466.115.121.1.11 (Country String, RFC 4517:3.3.4.) is a subset of the syntax of name (Directory String, RFC4519:2.18.), so the inheritance with further syntax restriction should be accepted.

An ITS seems appropriate.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------

Zhang Weiwu wrote:

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?

With respect to inheritance vs. specifying a syntax within the definition of an attribute, this is explicitly allowed by RFC4512.

With respect to 'c' being defined that way, that's how it's defined in RFC4519, in full compliance with RFC4512, since the "Country String" syntax is an exact subset of the "Directory String" syntax, which is the syntax of 'name'.

I agree right now the specification of 'c' is broken, which was probably caused by a limitation in current OpenLDAP software. I don't see much value in moving from one broken specification which allows interoperability (you can set the right values and you can exploit inheritance, but you can also set incorrect values) to another broken specification that breaks interoperability (you can only set the right values, but you lose inheritance). I'd rather fix (pardon, enhance) OpenLDAP to allow the right specification. That's why I ask you to file an ITS.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------

On Wed, 2007-05-16 at 16:09 +0200, Hallvard B Furuseth wrote:

Pierangelo Masarati writes:

...

Zhang Weiwu wrote:

...

I don't understand why 'c' do have the superior 'NAME'. (...)

(...) With respect to 'c' being defined that way, that's how it's defined in RFC4519 (...) you can set the right values and you can exploit inheritance (...)

One note: inheritance here means that in some cases when you specify NAME you get C too. E.g. a search for (name=GB) also finds 'c: GB'.

Truly enlightened me!