[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6151) Update cosine.schema to RFC 4524

On Apr 22, 2010, at 2:58 PM, Michael Str=F6der wrote:

> Kurt Zeilenga wrote:
>> One additional note, I generally would advise that a schema-aware =
>> not alter it's update behavior of elements based upon whether said =
>> are active or inactive (OBSOLETE) in the schema.=20
> I disagree especially for cases when new data is added.

I think you're trying to make the client far smarter than it really =
ought to be.

If the clients configured to place say place element of data in =
attribute x, it shouldn't try to put it elsewhere.  It should fail.

While certainly one could design a client such as it could be configured =
with fallbacks for attributes, and fallback for fallbacks, etc., this is =
an unnecessarily complication IMO.

Also, note that were a client to attempt the above, it could still fail =
due to an element being marked inactive between the time it read the =
schema and the time it tried the DIT update.   Of course, one could =
complicate the client further by trying to handle this as well.

>> Instead, they should just
>> try the update and, if it fails, report it as they normally would.
> Modifying existing data I first have to think about...
>> Handling the inactive condition locally hides the error from the =
>> administrator, who is likely relying on directory server logs to find=20=

>> applications which using inactive schema.
> Hmm, that's not the case with a schema-aware client anyway which =
guides the
> user *not* to use OBSOLETE schema elements.

I generally assume the user is not selecting which attribute to store =
some piece of information into.  I assume the client been programmed to =
collect a piece of information and configured (or programmed) where to =
store it.

The client you refer to is what I would call an application-neutral LDAP =
directory administration tool.  For such a tool, it might be reasonable =
to warn the user (whose generally an "administrator" of some sort as =
opposed to a "normal" user).
> You're likely talking about
> detecting pre-configured applications with hard-coded use of OBSOLETE =
> classes and attribute types.
> Most times these are not schema-aware at all.

Well, pre-configured applications may be schema-aware but maybe not as =
fully as an LDAP directory administration tool might be.  They might =
check that the element they were configured to use is appropriate for =
that use by examining its specification in the subschema.

-- Kurt=