Subject: Re: Active Directory question

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 20 Apr 2004 09:35:39 -0600

>> Hallvard B Furuseth <[email-masked]> 4/20/04 3:13:17 AM
>>>
>Jim Sermersheim writes:
>> But to take the issue a bit further, regarding your first point;
The
>> fact that language tags and the binary options conform to RFC 2251
>> doesn't make me feel that they are any less flawed. The attribute
>> options feature (in my mind) is clearly an extension mechanism.
>
>I disagree. Tagging options are just simple subtyping, and a useful
>variant of it. ";binary" is a mess, but it was thought to be a
>necessary one, so it seems strange to call that an extension.
>Other options are extensions, yes.

Yes, tagging options are just simple subtyping (although
non-discoverable like normal attribute subtyping is). I'm talking about
attribute options in general. If only tagging options were allowed, then
I wouldn't be going on and on about it.

>> 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.

<snip>

>_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)
 
>To change either
>of these sounds like an LDAPv4 change to me, though for non-tagging
>options it does begin to sound like a good change.

>- When a non-tagging (sorry, Jim:-) option is defined, it SHOULD be
>defined in such a manner that it will not be returned unless
>the client solicits it in some manner,
>
>- If the above is not done - and preferably if it is done as well -
the
>option SHOULD be designed so that it will be harmless for the client
>to treat it as a tagging option, and harmless to treat the attribute
>description as unrecognized. ("Harmless" could be expanded with a
>list of possible ways to be harmful.)

Yes, this helps.

>- Since an attribute with an option is a description subtype of that
>attribute without the option, and a search for an attribute also
>returns that attribute's subtypes, non-tagging attribute options that
>are stored in the directory can often be the wrong solution to a
>design problem, as the above advice may then be impossible to follow.
>It may be better to another extension mechanism (such as controls),
or
>to define the option to specify some information which is stored
>_about_ the attribute but not in the attribute description where it
>originated. A read operation may then re-insert the attribute option
>if that operation requests this information.

Only tagging options (so far) exhibit the subtyping semantics described
here.

<snip>

>BTW, [Models] section 2.5 says "Clients MAY treat an unrecognized
>attribute option as a tagging option", but is it stated anywhere
>that clients MAY treat it as anything _else_ than a tagging option?

I thought there was language that also allowed a client to treat them
as unrecognized attributes, but I guess not.
 
Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Apr 2004 09:37:22 -0700

At 08:35 AM 4/20/2004, Jim Sermersheim wrote:
>If only tagging options were allowed, then I wouldn't be going on and on about it. 

To ensure interoperability between implementations which
support different options, we've adopted two basic rules:

        Servers are to treat attribute descriptions with
        unrecognized options as unrecognized.

        Clients may treat attribute descriptions with
        unrecognized options either as unrecognized or
        subtypes of the attribute type in the description.

This means that server can return subtypes indicated by
tagging options just as they would for other subtypes
(e.g., without requiring explicit naming of the subtype
in the solicitation).

However, servers cannot return options (like a range
option) which have semantics incompatible/non-interoperable
with either of the allowed client treatments.  To do so
would not be truly optional.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 20 Apr 2004 18:49:58 +0200

Jim Sermersheim writes:
>Hallvard B Furuseth
>>Jim Sermersheim writes:
>>>
>>> Without means for discovery or solicitation, I believe this extension

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Apr 2004 10:44:45 -0700

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:
>>>>>
>>or something.
>supportedFeatures [RFC3673].  Used, for instance, to provide
>discovery for language-tag/language-range options
>[draft-zeilenga-ldap-rfc2596].
>
>>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
>>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
>I don't think we need to go into horrors of using
>unregistered attribute option names.
>

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