Subject: [ldapext] About draft-zeilenga-ldap-txn-10

From: Ludovic Poitou <[email-masked]>
Date: Thu, 25 Oct 2007 16:50:09 +0200

Hi Kurt,

I was reviewing the LDAP transaction I-D and have the following  
questions and comments.

- End Transaction Request and Response.
Says:  The  responseValue when present contains a BER-encoded MessageID.

What  does this MessageID correspond to ?

I have a customer interested in the LDAP Transaction draft, but would  
prefer for auditing purpose and for a better clarity of the code to  
separate the end transaction into 2 requests: one Commit Transaction  
and one Abort Transaction.
By having 2 separate extended operations, it is easier to  
distinguished from Logs or traces when a transaction has been  
committed vs aborted.
Also on the client application point of view, it is cleaner to have 2  
different API mapping to separate extended operations.

Ludo

Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                                   Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 25 Oct 2007 09:57:27 -0700

> What  does this MessageID correspond to ?

It indicates, when present, the update request to which the non- 
success resultCode is attributed to (see 3rd paragraph of 3.4).

I note that I do intended to modify the end-transaction response data  
to support pre-/post- read controls, and other controls on update  
requests.  I'm considering changing the response data will end up  
being the BER-encoding of something like:

	endResValue ::= SEQUENCE {
		messageID	MessageID OPTIONAL, -- msgid associated with resultCode
		updatesControls	SEQUENCE OF updateControls SEQUENCE {
			messageID	messageID, -- msgid controls are associated with
			controls	Controls
		} OPTIONAL
	}
         -- where MessageID and Controls as are specified in RFC 4511.

> I have a customer interested in the LDAP Transaction draft, but  
> would prefer for auditing purpose and for a better clarity of the  
> code to separate the end transaction into 2 requests: one Commit  
> Transaction and one Abort Transaction. By having 2 separate  
> extended operations, it is easier to distinguished from Logs or  
> traces when a transaction has been committed vs aborted.
> Also on the client application point of view, it is cleaner to have  
> 2 different API mapping to separate extended operations.

I have to think about this some.  Off hand, I can see how somethings  
might be easier if there were two separate extended operations to  
settle the transaction, but can also see how somethings might be  
easier when there is one extended operation to settle the  
transaction.  Seems 'easier' here is fairly dependent on  
implementation details of the client, server, network analyzer, etc.

-- Kurt