Re: attribute options

Steven Legg writes:
>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.

We do: Private options with names starting with "x-".  I should have
clarified that.  Which would also have given me the answer to my
concern with replicating from two servers with such conflicting options:

Private options are the inventor's problem.

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

I would be sorry to see the "Clients MAY..." disappear as you suggest
but given your reply the current situation isn't good either.  I think
I'll stick to "no opinion" on this one...

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

-- 
Hallvard