Subject: [ldapext] Assert I-D.

From: Ludovic Poitou <[email-masked]>
Date: Tue, 22 Jul 2003 14:45:57 +0200

Hi Kurt,

I have some questions regarding the Assertion Control.

I'm not sure the Assertion as defined presently can be applied to "Add" 
operations.
The section 3 says that "For Add, Compare, and ModifyDN the target is 
indicated by the entry field in the request.". For an add operation, the 
entry field is the entry being added. Applying assertion on the data 
that is part of the add operation itself doesn't give much added-value.
Can you explain why you want to support Assert on the Add operation ?

Also, the text should be less ambiguous on when the assertion is to be 
checked. The draft says that the Assertion and the Operation shall be 
done as an atomic operation. But it doesn't say if the assertion is to 
be applied BEFORE the target entry contains the changes or AFTER.
For example, if I assert that foo=bar but replace the attribute foo with 
the foobar value, the assertion is true before I apply the change and 
not after.

Ludovic.

-- 
Ludovic Poitou
Sun Microsystems Inc.
Sun ONE products - Directory Server Group - Grenoble - France

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Leif Johansson <[email-masked]>
Date: Tue, 22 Jul 2003 21:25:40 +0200

> Hi Kurt, 

<snip>

> Can you explain why you want to support Assert on the Add operation ?

I guess you could assert the parent...

    MVH leifj

---

From: Leif Johansson <[email-masked]>
Date: Wed, 23 Jul 2003 09:11:59 +0200

Ludovic Poitou wrote:

> I agree, but this is not explicit in the Assert draft. and it's in 
> contradiction with the text that specify that the Assertion is done on 
> the Target entry. For an Add, the target is the entry to add, not the 
> parent.
>
> Ludovic.
>
>
Oh yes. I was just offering up a useful (?) semantic. Clearly the text 
has to change if this is how
the control is to be used for add-operations.

       MVH leifj

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 23 Jul 2003 15:38:39 +0200

At 02:45 PM 7/22/2003, Ludovic Poitou wrote:
>I'm not sure the Assertion as defined presently can be applied to "Add" operations.

I think that the control should not be applicable to Add.
I'll update the next revision to reflect this.

>The section 3 says that "For Add, Compare, and ModifyDN the target is indicated by the entry field in the request.". For an add operation, the entry field is the entry being added. Applying assertion on the data that is part of the add operation itself doesn't give much added-value.
>Also, the text should be less ambiguous on when the assertion is to be checked. The draft says that the Assertion and the Operation shall be done as an atomic operation. But it doesn't say if the assertion is to be applied BEFORE the target entry contains the changes or AFTER.
>For example, if I assert that foo=bar but replace the attribute foo with the foobar value, the assertion is true before I apply the change and not after.

BEFORE.  Will clarify.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 23 Jul 2003 15:51:35 +0200

>I'll update the next revision to reflect this.

Hmm, actually it might make sense if you have attributes which are
generated when the entry is added but are not part of the entry sent
from the client.

    MVH leifj

---

From: Leif Johansson <[email-masked]>
Date: Wed, 23 Jul 2003 16:47:35 +0200

Ludovic Poitou wrote:

> Leif Johansson wrote:
> In that case, you may want to retrieve these attributes, not to assert 
> on them.

Yea you might - I only want to add this entry if the uuid I get is an 
even number
of 1's :-)

       MVH leifj

---

From: Ludovic Poitou <[email-masked]>
Date: Wed, 23 Jul 2003 09:06:15 +0200

Ludovic.

---

From: Ludovic Poitou <[email-masked]>
Date: Wed, 23 Jul 2003 16:08:22 +0200

Ludovic