>> Hallvard B Furuseth <firstname.lastname@example.org> 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.
>_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.
>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.