Re: I-D ACTION:draft-zeilenga-ldap-relax-00.txt

> Kurt Zeilenga wrote:
>> It seems to me you want to use schema to determine whether or not a DSA,
>> not necessarily the master DSA for the target object, implements
>> relaxation
>> of some constraint associated with some element of schema.  And you want
>> to
>> use subschema for this.
>>
>> This I see as quite problematic.
>>
>> First, there's the problem of what exactly does it mean for something to
>> be
>> published in a subschema.  The assumptions a client (or server) can make
>> based upon something being published in a subschema is quite limited.
>
> To stay out of nit-picking my suggestion for a definition would be:
> If there's a standard document saying that the Relax Rules Control MAY be
> used
> to add/modify the attribute the attribute type description SHOULD contain
> option X-RELAX.
>
> All the issues you wrote apply to other subschema elements anyway and
> web2ldap
> contains a lot of fall back behaviour.
>
> Also note that web2ldap does not automagically enable use of this control.
> It's still up to the admin user to enable it manually - kind of a special
> mode. But if in this mode I'd like to know which input fields to enable.
>
> I don't know how to get out of the X- prefix issue and RFCs. But I'd
> consider
> it very bad if LDAPv3 does not allow any extension of the schema
> descriptions
> with additional options usable in a newer RFC.

What about stating that attributeTypes MAY have a X-RELAX (please note
that it needs to have a value, so X-RELAX 'TRUE' may be needed) option if
that attribute MAY be modified using the relax control?  The double
conditional would "relax" the use of this private, and thus
non-publicable, extension.

Hope I made the point, I wouldn't be able to formalize it further right
now, as I just made too direct an acquaintance with Belgian beer :)

Cheers from Brussels, p.