Re: Active Directory question

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Hallvard