Re: Active Directory question

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

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.

> Without means for discovery or solicitation, I believe this extension
> mechanism is fundamentally flawed.

If you exclude tagging options.

> Second, I suspect that the introduction of any new option (especially
> those that are not 'tagging' options) is going to cause a number of
> applications to encounter problems unless there is a client solicitation
> mechanism for it.  Currently, a client can only recognize those attribute
> options that are known to it and fail over to treating attributes with
> unknown options as either unrecognized attributes, or (worse in some
> cases, better in others) treat them like tagging options. Who knows what
> other types of options will be concocted in the future?

True.  Actually, I believe we already have that problem with ";binary":
A pre-LDAPbis server may send a value with an unsolicited ";binary"
option (and with non-textual syntax).
A post-LDAPbis client need not recognize ";binary", so it MAY treat it
as a tagging option - and thus parse the binary attribute value
according to the attribute's string-based syntax.

> As long as it's possible to invent an option which (like the range and
> binary options) can cause mandatory attributes to be treated as
> unrecognized by a client, I see problems.
  
Access controls can hide mandatory attributes too.

> It could be that I'm trying to smack the problem with too big of a
> hammer (though an extension mechanism with no means of solicitation
> still seems ugly and dangerous). If we're unwilling to recommend against
> the use of unsolicited options, then I don't believe there is sufficient
> guidance regarding how one is to define new ones in order to avoid
> interoperability problems.

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

> Maybe your suggestions below, along with something a little more obvious
> in [Models] (though what that would be escapes me right now) will have
> to be good enough.

Something like this?

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

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

> I note that the authors of the range option could
> technically follow the current instructions in [Models] and still claim
> (with a not very straight face) that they did due diligence in creating
> the new option. It might look something like:  (...)

If they had called it ";range-0-999" instead of the protocol violation
";range=0-999"


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?

-- 
Hallvard