[Date Prev][Date Next] [Chronological] [Thread] [Top]

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.
>