attribute options
Hallvard B Furuseth <[email protected]>
| Newsgroups | gmane.ietf.ldapbis |
|---|---|
| Message-ID | <[email protected]> |
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