Re: attribute options

[Steven Legg <steven.legg@eb2bcom.com>]

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.

> 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