[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
attribute options
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? 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.
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.
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?
--
Hallvard