[Date Prev][Date Next]
AW: sn/surname mess. Need your opinion
thanx a lot for replying. Please forgive my rather reduced knowledge of LDAP. I am afraid I could misunderstand you here. RFC 2252 says that NAME of an attribute is
[ "NAME" qdescrs ] ; name used in AttributeType
; object descriptors used as schema element names
qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp )
therefore each name in the list qdescrs is a valid attribute name. Now you define in core.schema
attributetype ( 18.104.22.168 NAME ( 'givenName' 'gn' )
DESC 'RFC2256: first name(s) for which the entity is known by'
SUP name )
and say that LDAP server should not return 'givenName' as attribute name even in the case if LDAP client asked to return exactly 'givenName' as search result, because in RFC 2256 only 'gn' attribute has been defined. OK, I understand this, OpenLDAP is clever, it knows what is happening here.
Now I have defined my own attribute like
attributeType ( 2.16.840.1.113722.214.171.124.1.25 NAME ('groupMembership' 'myGroupMembership')
DESC 'groupMembership attribute from Novell LDAP'
SYNTAX 126.96.36.199.4.1.14188.8.131.52.12 )
objectClass ( 184.108.40.206.4.1.8220.127.116.116 NAME 'BETestObjectClass'
SUP (top $ inetOrgPerson $ organizationalPerson $ person)
STRUCTURAL MUST (groupMembership) )
in case of 'myGroupMembership' OpenLDAP behaves exactly in the same way as in case of 'givenName' above. And I really don't understand what I am doing illegal here, I don't contradict any RFC ... Please help !
Best regards, vadim tarassov.
Von: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Gesendet: Mittwoch, 10. März 2004 07:00
An: Vadim Tarassov
Cc: Gary Allen Vollink; openldap-software@OpenLDAP.org
Betreff: Re: sn/surname mess. Need your opinion
In short, it's not a bug. It's a feature.
Note that the formal description [RFC2256] of the SN attribute
( 18.104.22.168 NAME 'sn' SUP name )
No server is required to recognize this attribute type by any
name other than 'sn'. A client which asks for 'surname' is
simply broken and won't interoperate broadly.
The reason why we provide 'sn' when 'surname' is requested, instead
of just treating 'surname' as unrecognized, is in hopes that this
might make it more evident that client is broken. Returning
'surname' instead offers no incentive to fix the broken client
code... returning 'surname' instead would only lead to further
development and deployment of broken code.
Or, to put it another way, slapd(8) is being liberal in accepting
'surname' as an alias for 'sn', but strict in returning the
proper name for the attribute type.
At 09:05 PM 3/9/2004, Vadim Tarassov wrote:
>I agree with you, it is not a deal to rectify any aliassed name change. However (I think) it is not a reason for LDAP server to return attributes with names different from those it has been asked to return. I guess loads of LDAP client software (less intelegent than it should be) assumes that LDAP server returns exactly what it was ment to return.
>Best regards, vadim tarassov.
>Gary Allen Vollink wrote:
>>I would say... Not a bug. I (and probably many others) have written programs that expect the possibility of changing attribute names, and it's quite trivial (an extra line of code, or two) to check (and rectify, if needed) any aliassed name change. I code in C, but AFAIK the two APIs are very similar.
>>(( probably not what you wanted to hear ))
>>Vadim Tarassov wrote:
>>>I had today a discussion on "iplanet vs OpenLDAP" topic. During this discussion I've learned "attribute aliasing", whis not really doing well in OpenLDAP. When LDAP client asks to perform a search and to return value of the attribute "surname", OpenLDAP will return correct value of the attribute, though the attribute name can be "sn" if defined so in the tree. It took me 40 seconds to build a from every point of view valid LDAP client in Java, which will fail in this case, just because it expected to get the same attribute name as it asked for. It happens because at least in Java you can get collection of search results and call method get(attributeName) on the collection to get list of the attribute values.
>>>Very annoying in this story is that iplanet will return attributes with exactly same names as it has been asked to return.
>>>I have googled a bit, and found that Kurt once replied to someone on the same issue with "No LDAP technical spesification demands LDAP to return attributes with the same names as in LDAP quiry" or similar .... I think it is not really correct. What do you think? Is it a bug in Open LDAP which should be fixed or not?
>>>Best regards, vadim tarassov.