AW: sn/surname mess. Need your opinion

[Tarassov Vadim <Vadim.Tarassov@winterthur.ch>]

Hallo Kurt,

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

where 

; 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 ( 2.5.4.42 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.113719.1.1.4.1.25 NAME ('groupMembership' 'myGroupMembership')
	DESC 'groupMembership attribute from Novell LDAP'
	SUBSTR caseExactSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

objectClass ( 1.3.6.1.4.1.8188.2.2.666 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.


-----Ursprüngliche Nachricht-----
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


Vadim,

In short, it's not a bug.  It's a feature.

Note that the formal description [RFC2256] of the SN attribute
type is:
  ( 2.5.4.4 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.

Kurt

At 09:05 PM 3/9/2004, Vadim Tarassov wrote:
>Hallo Gary,
>
>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 ))
>>
>>Sorry,
>>Gary Allen
>>
>>Vadim Tarassov wrote:
>>
>>>Hallo everybody,
>>>
>>>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.
>