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

[masarati@aero.polimi.it]

> Kurt Zeilenga wrote:
>> obsoletes != OBSOLETE, so no.   That is, the meaning of the term
>> 'obsolete' is quite different in these two contexts.
>>
>> The latter context the term is defined as follows: The OBSOLETE field,
>> if
>> present, indicates the element is not active.
>
> I agree that OBSOLETE should not be set in this case.
>
>> For user application attribute types, whether the type is active or not
>> is,
>> I think, best left to the schema administrator.
>
> Who is the schema administrator? I'm nitpicking here because on the
> OpenLDAP
> lists we all keep telling OpenLDAP admins not to mess with the standard
> schema
> at all. IMO this includes setting OBSOLETE.

I Think there's a misunderstanding.  My understanding (and intention) is

1) You said you pulled in revisited cosine.schema also elements that were
dropped in RFC4524.

2) I was asking whether the fact they were dropped implied they were
OBSOLETE (i.e. had to be marked as OBSOLETE in their schema definition)

3) Kurt replied that they MUST NOT be marked as OBSOLETE.  Whether they
are loaded or not in a DSA's schema is at the DSA schema administrator's
choice

4) This, IMHO, implies that we need to provide two separate files, to
allow DSA admins to either load strict RFC4524 schema (no obsolete items)
or loose RFC4524 (entire RFC1274 schema).

Now, we have different options to arrange the resulting schema files
(names used below are only an example, the final name can be discussed
when there's consensus on the approach):

a) cosine.schema (== RFC1274)
   cosine4524.schema (== RFC4524)
   mutually exclusive (Kurt does not like this)

b) cosine4524.schema (== RFC4524)
   cosine.schema (== RFC1274 - RFC4524)
   the latter includes the former

c) cosine4524.schema (== RFC4524)
   cosine1274.schema (== RFC1274 - RFC4524)

(there might be more)

Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274
schema, thus existing configurations surely do not break.  I concur case
(a) would cause a lot of complaints from people loading all available
schema files and having conflicts.  Case (c) needs to modify
configuration, but avoids file nesting, if that's a problem at all.

p.