--On Tuesday, August 26, 2008 7:13 PM +0200 Michael Ströder michael@stroeder.com wrote:

Quanah Gibson-Mount wrote:

...

Does the RFC proclaim a matching rule for postalAddress? Because if it doesn't, there's no point in defining one. ;) If an attr doesn't have a matching rule, you have to use a replace op rather than delete.

Yes. And OpenLDAP even announces it in the subschema without implementing it (see also ITS#5608). :-(

Ah, well, then I certainly encourage Brett to implement it. ;)

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Kurt Zeilenga wrote:

An implementation can either publish the attribute description as specified (possibly with some additional names, extensions) or not. The description is otherwise immutable (per X.501).

Note that publication of a schema description only indicates that the implementation is aware of the description. It does not necessarily mean that the server implements any particular functionality (other than the ability to publish schema descriptions).

...still we disagree on that. If consequently applied this paradigm would render the subschema subentry completely unusable for the client. IMO the subschema subentry SHOULD reflect what is effective on the server's side. Otherwise a client cannot find out what to do by looking at the schema.

I've somewhat solved my problem by also looking whether the referenced EQUALITY matching rule (here caseIgnoreListMatch) is listed in subschema subentry's attribute 'matchingRules'. But taking your wording literally even this wouldn't be guaranteed.

Ciao, Michael.

Kurt Zeilenga wrote:

I think you simply fail to realize that the subschema publication mechanism has limitations to its usefulness. As specified, it's simply not terribly usable as an implementation-supported-feature discovery mechanism. (When LDAP was being revised, I did suggest how it could become more useful, those suggestions were not supported by the consensus of the WG. Oh well.)

Could you please point me to some related postings in the ietf-ldapbis mailing list archive?

What you suggestion, I think, is quite problematic. Saying an attribute has no equality rule is not the same as saying a particular implementation doesn't support a particular rule. If a server where to say "this attribute has no equality rule", then others (clients or servers reading this) might not apply the equality rule even though they have implemented it. That might lead to very odd behavior.

Your argument might be ok in this particular case and, as I said, I have a work-around for that particular case. But in general it's debatable whether the subschema is 1. advice to the client to do the right thing or 2. to indicate to the client what the server does. I've seen many interpretations in both directions - in discussions and in implementations.

Ciao, Michael.

I don't want to hold you back from implementing the EQUALITY matching rule for PostalAdress syntax.

But you could also just delete the whole attribute and re-add the value(s) needed. (That's how the delta-modification works in web2ldap if the EQUALITY matching rule is not implemented.)

Yes that's what i did to fix my test data, but specifically this change was made indirectly by the collect.c overlay, not manually by me, which populates attributes from a parent or template object through to all the children of that object. I want to use the collect overlay to make child objects have the same postalAddress (amoung other attributes) of some parent or template object, such as some superior ou entry that is component of the user's dn.

This issue arises as to what happens to when you try to edit postalAddress in a child object which has collected an attribute from some parent, what is presently happening is that the parent gets another duplicate attribute value on the inherited attribute. In other words it allows the change, but it cannot tell that the new attribute value is the same as the old attribute value.

While this is probably a bug that needs fixing, i'm considering the best option for a workaround.

While this probably can be simply fixed by disallowing writes on attributes of child object which are collect-ed from a parent, my thought was that if there was an equality matching rule and it were implemented, the update would fail or silently ignore the update (as ldap would normally) because the attribute already has that value, and it would be a tidier / more correct solution.

To paraphrase, i'd prefer to leave the decision as to whether the attribute MAY be written, to the access control system, and just work on the fact wether the attribute should be written (ie. it already has that value, so request should be silently ignored or errored, i favour the former) which is more correct IMHO, just disabling writes is ignoring the problem (although that also might be a nice feature).

Cheers Brett

On Sat, Aug 30, 2008 at 7:03 PM, Michael Ströder michael@stroeder.com wrote:

slapo-collect should intercept the write request and forbid the write access if the attribute type is declared with COLLECTIVE.

Yep. That sounds reasonable, but i presume it should either return an unwilling to perform, or silently ignore it. The latter case would be better if dumping out a ldap database (as it would be dumped as a "real" attribute) and then wanting to import that same data back ?

Again: I'd appreciate if you would implement caseIgnoreListMatch but this particular issue should be fixed in a more general way.

I was starting to investigate this, but it looks like ando has already done it :)

Cheers Brett

On Sun, Aug 31, 2008 at 9:31 PM, Michael Ströder michael@stroeder.com wrote:

...

...

slapo-collect should intercept the write request and forbid the write access if the attribute type is declared with COLLECTIVE.

Yep. That sounds reasonable, but i presume it should either return an unwilling to perform, or silently ignore it.

I'd prefer to not silently ignore it since returning unwillingToPerform clearly indicates that a client is misbehaving which needs correction.

OK, i've implemented collect_modify() which returns unwillingToPerform for any modify operation which contains an attribute which is a collect attribute, leaving alone non-collectinfo objects including the parent object

the collect attributes are not dumped by slapcat, so no changes there

Cheers Brett