Re: attribute options

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:11 PM 3/7/2005, Steven Legg wrote:

>Hallvard,
>
>Hallvard B Furuseth wrote:
>
>>I found some old problems with attribute options in the arcive:
>>(Thread 'Active Directory question', Apr 2004)
>>Option definitions are not part of the (standardized) schema.  So may
>>an option name, like an attribute name, have different meanings in
>>different parts of the DIT - in the same server?
>
>All the options I am aware of have the same meaning everywhere. I don't
>think we should allow the definition of an attribute option whose meaning
>is different in different parts of the DIT.

I agree.  But that said, I don't it appropriate for [Models] to
place such a restriction on the scope of extension possible via
options.

I do note that server do not necessarily have to support each option
for each attribute type and/or for all fragments of the DITs.  For
instance, ;binary support can be limited to say only those attribute
types where ;binary use is required.  Likewise, a server's
;lang-X support could be limited to entries (e.g., not supported in
subentries).  Or a client could only deal with language tags only on
name and its subtypes.

Of course, there are issues of option support discovery.  These
are left to specifications of options to address.

>> That is not my
>>impression, but it must be possible if shadowing of entries in general
>>is to be possible.  (E.g. shadowing from two different servers which
>>support different attribute options).  Also a client which talks to
>>two such servers may need to treat them as part of the schema.
>>Maybe [Models] should clarify how that works, or refer to whatever X.500
>>says about it.
>
>The fifth edition of X.500 will map LDAP attribute options into contexts,
>but beyond that will defer to LDAP with regard to their meaning.
>
>>Models 2.5 (Attribute Descriptions) says:
>>
>>>An attribute description with an unrecognized attribute type is to be
>>>treated as unrecognized.  Servers SHALL treat an attribute description
>>>with an unrecognized attribute option as unrecognized.  Clients MAY
>>>treat an unrecognized attribute option as a tagging option (see
>>>Section 2.5.2.1).
>>
>>However, it does not say that clients MAY treat an unrecognized
>>attribute option as anything _else_ than a tagging option - e.g. treat
>>the attribute description as unrecognized.
>>
>>Problem with the ";binary" option:
>>A pre-LDAPbis server may send a value with an unsolicited ";binary"
>>option (and with non-textual syntax).  A post-LDAPbis client need not
>>recognize ";binary", so it MAY treat it as a tagging option - and thus
>>parse the binary attribute value according to the attribute's
>>string-based syntax.
>>Maybe the caveat should be added that clients SHOULD NOT treat ";binary"
>>as a tagging option.
>
>There isn't a specification of ";binary" that is at the required level of
>standard maturity for ldapbis to be able to reference it. I think we should
>drop the "Clients MAY" and perhaps change the "Servers SHALL" to
>"Implementations SHALL".
>
>>While I'm writing, a question: Am I right in assuming that the spec of
>>any option, including a tagging option, may include mandatory
>>server-specific functionality and (due to the "Clients MAY... above)
>>client-specific optional functionality, so that at least a server cannot
>>necessarily support a tagging option merely by recognizing its name?
>
>Well, ";transfer-ber" is an example with mandatory server and client functionality
>which requires servers to do more than recognize the name. An option with mandatory
>server functionality and optional client functionality is allowed in principle but
>I'm not aware of any actual examples.
>
>Regards,
>Steven