[Date Prev][Date Next]
Re: Active Directory question
Jim Sermersheim writes:
>Hallvard B Furuseth
>>Jim Sermersheim writes:
>>> Without means for discovery or solicitation, I believe this extension
>>> mechanism is fundamentally flawed.
>> If you exclude tagging options.
> Fine, while not an interoperability problem, I still argue that a
> discovery mechanism is needed for completeness. I can discover normal
> attribute subtyping via the schema. Attribute subtyping due to tagging
> options just sort of happens.
You could write up an RFC for a supportedTaggingOptions attribute,
or something. Seems fairly simple and non-intrusive, compared to
the other problems with attribute options in this thread.
I'm uncertain about one thing in that regard: 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 the impression I had, but it must be
possible if shadowing of entries in general is to be possible. Maybe
[Models] should clarify how that works.
>> _Can_ we recommend against unsolicited options? An attribute type with
>> an option is a subtype of that attribute type without the option. A
>> search requesting an attribute also requests subtypes.
> That's only true of tagging options (so far)
Oh, good. Seems to have been fixed since rfc2251 section 4.1.5:
An AttributeDescription with one or more options is treated as a
subtype of the attribute type without any options.
This should be listed in [Models] Appendix A.1: Changes to RFC 2251.