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

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Oct 25, 2007, at 7:50 AM, Ludovic Poitou wrote:

> 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 ?

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

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext