> If the client wants to request via slapo-allowed which attributes are
> readable/writeable before adding another object class then object classes
> not
> yet part of the entry could be used if the client adds the object class
> name
> prefixed with @. This is an extension to the semantics but should not
> cause any
> problem with existing clients.

with the current implementation of slapo-allowed, the client does not do
anything specific but requesting those special operational attributes.

It is not clear to me how the semantics you propose should be activated. 
If you mean that having some "@" + <objectClass> in the requested attrs
should populate the allowedAttributes and allowedAttributesEffective
attributes, I think it would be a significant distortion of the meaning of
the requested attributes.

I'd rather favor defining a specific control request, that sort of
"mimics" adding some attributes, including objectClass values, to an
existing entry, so that allowedAttributes and allowedAttributesEffective
are populated accordingly.

p.

masarati@aero.polimi.it wrote:
>> If the client wants to request via slapo-allowed which attributes are
>> readable/writeable before adding another object class then object classes
>> not
>> yet part of the entry could be used if the client adds the object class
>> name
>> prefixed with @. This is an extension to the semantics but should not
>> cause any
>> problem with existing clients.
> 
> with the current implementation of slapo-allowed, the client does not do
> anything specific but requesting those special operational attributes.

Yes. That's what I've implemented. Well, what slapo-allowed and MS AD
implement is limited anyway. E.g. no way to determine writeable attrs when
adding new entries.

> It is not clear to me how the semantics you propose should be activated. 
> If you mean that having some "@" + <objectClass> in the requested attrs
> should populate the allowedAttributes and allowedAttributesEffective
> attributes, I think it would be a significant distortion of the meaning of
> the requested attributes.

Yes, my suggestion was that slapo-allowed looks at the attr list in the search
request for occurences of "@" + <objectClass>. And then use each <objectClass>
(if not yet in the set of current object classes of the entry) to evaluate the
accompanying attrs and put them into allowedAttributes and/or
allowedAttributesEffective.

Yes, that's a change in the current semantics.

I now partially worked around the problem with new object classes in web2ldap
by determining which attrs would be really new when adding a set of object
classes enabling all the input fields for these new attrs. But off course
that's not nice.

> I'd rather favor defining a specific control request, that sort of
> "mimics" adding some attributes, including objectClass values, to an
> existing entry, so that allowedAttributes and allowedAttributesEffective
> are populated accordingly.

There are some implementations of the Get Effective Rights control but they
seem to slightly differ.

Ciao, Michael.

> masarati@aero.polimi.it wrote:
>>> If the client wants to request via slapo-allowed which attributes are
>>> readable/writeable before adding another object class then object
>>> classes
>>> not
>>> yet part of the entry could be used if the client adds the object class
>>> name
>>> prefixed with @. This is an extension to the semantics but should not
>>> cause any
>>> problem with existing clients.
>>
>> with the current implementation of slapo-allowed, the client does not do
>> anything specific but requesting those special operational attributes.
>
> Yes. That's what I've implemented. Well, what slapo-allowed and MS AD
> implement is limited anyway. E.g. no way to determine writeable attrs when
> adding new entries.
>
>> It is not clear to me how the semantics you propose should be activated.
>> If you mean that having some "@" + <objectClass> in the requested attrs
>> should populate the allowedAttributes and allowedAttributesEffective
>> attributes, I think it would be a significant distortion of the meaning
>> of
>> the requested attributes.
>
> Yes, my suggestion was that slapo-allowed looks at the attr list in the
> search
> request for occurences of "@" + <objectClass>. And then use each
> <objectClass>
> (if not yet in the set of current object classes of the entry) to evaluate
> the
> accompanying attrs and put them into allowedAttributes and/or
> allowedAttributesEffective.
>
> Yes, that's a change in the current semantics.

Not only a change in semantics, but also a poor choice, IMHO.  How can the
server determine whether a request is malformed or the client really
wanted to trigger such an esoteric feature?

> I now partially worked around the problem with new object classes in
> web2ldap
> by determining which attrs would be really new when adding a set of object
> classes enabling all the input fields for these new attrs. But off course
> that's not nice.
>
>> I'd rather favor defining a specific control request, that sort of
>> "mimics" adding some attributes, including objectClass values, to an
>> existing entry, so that allowedAttributes and allowedAttributesEffective
>> are populated accordingly.
>
> There are some implementations of the Get Effective Rights control but
> they
> seem to slightly differ.

That control's definition really sounds like an overkill, although I
understand the intention of allowing clients to specify everything a DSA
could use to determine access privileges.  I'd favor a much lighter
control.  Perhaps, all the features allowed by that spec, and even more
and better (possibly with a flexible mechanism) could be made optional. 
In any case, it should be clear that the result will only be a hint, or a
guess, and the only reliable way to determine read access would be to
actually read data, and, to determine write access, to attempt the
operation using the noOp control.

p.

moved from Incoming to Software Enhancements

does not provide reliable answer to the query, needs a solid use case and workable solution.