|
>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 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
|