Re: Active Directory question

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:27 AM 4/20/2004, Kurt D. Zeilenga wrote:
>[trimmed CC list
>At 09:49 AM 4/20/2004, Hallvard B Furuseth wrote:
>>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.
>
>supportedFeatures [RFC3673].  Used, for instance, to provide
>discovery for language-tag/language-range options
>[draft-zeilenga-ldap-rfc2596].
>
>>I'm uncertain about one thing in that regard: Option definitions are
>>not part of the (standardized) schema.
>
>options are defined in documents (like schema), but support
>for options has traditionally not been discoverable (except
>by use).  While supportedFeatures may be used in some cases,
>it is not necessarily the best approach for all options
>(given that options can have a wide range of semantics).
>
>>So may an option name, like an
>>attribute name, have different meanings in different parts of the DIT -
>>in the same server?
>
>If we're talking about unregistered option names, yes, it is
>possible that different folks could define options whose
>meaning was different in different parts of the DIT (on
>same or different servers).
>
>>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.
>
>I don't think we need to go into horrors of using
>unregistered attribute option names.
>
>>>> _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.

I really don't see [Models] as changing the substance
of what RFC 2251 said in regards to options and subtypes.
[Models] just clarifies the sentence you quote as
applying generally, but in all cases.  RFC 2251 included
the same substance, it just wasn't as clear (because
some folks sometimes took "is treated as" as "is").

Kurt