[Date Prev][Date Next]
Re: AW: sn/surname mess. Need your opinion
At 11:29 PM 3/9/2004, Tarassov Vadim wrote:
>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
>therefore each name in the list qdescrs is a valid attribute name.
It's valid in the schema. Did your client actually read the controlling subschema?
If so, it would have seen that 'surname' and 'sn' refer to the same attribute.
The fact is that most clients don't read the subschema, they just assume that
name they use refers to the desired attribute. A client which assumes
'surname' refers to the SN attribute is simply broken.
The fact that slapd have 'surname' listed as a NAME for the SN attribute means
only means that slapd is willing to recognize 'surname' as referring to that
attribute. However, it in no way means that slapd has to be capable of returning
that name when it refers to the attribute.
>Now you define in core.schema
>attributetype ( 22.214.171.124 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.
Actually, 'givenName' is the registered name of the givenName attribute.
>OK, I understand this, OpenLDAP is clever, it knows what is happening here.
The server is actually quite dumb. It just recognizes an attribute by any of its
listed names, but always uses the first name when it refers to the attribute. By
convention, all the schema files shipped with OpenLDAP list the
standardized/registered name first to ensure that the proper name is transmitted
by the server.
>Now I have defined my own attribute like
>attributeType ( 2.16.840.1.1137126.96.36.199.1.25 NAME ('groupMembership' 'myGroupMembership')
> DESC 'groupMembership attribute from Novell LDAP'
> SUBSTR caseExactSubstringsMatch
> SYNTAX 188.8.131.52.4.1.14184.108.40.206.12 )
>objectClass ( 220.127.116.11.4.1.818.104.22.1686 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 ...
I think the problem here is not that your schema descriptions are somehow invalid,
but that you are somehow viewing them as imparting semantics beyond what the
LDAP technical specifications do.
I strong recommend that you only assign one and only name to any schema element