|
Apparently, I had already fixed one of the uses of "outstanding" in [Authmeth] because I can find only one in my current draft. I've now resolved it.
Roger
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 6/11/2004 8:34:15 AM >>> Well, Jim is back, I believe. I'll begin small:-) Roger, note that Authmeth has two 'outstanding's too. Looking a bit closer at the texts, I think only the 'outstanding' in [Protocol] 4.1.1.1 (Message ID) is not self-explanatory. Here is a possible replacement text: A client MUST NOT reuse a previous request's message ID in the same LDAP exchange until it knows that the server has completed or successfully abandoned the operation. Or maybe s/successfully abandoned/discarded/. If anyone feels like replacing the others, here are some suggestions. And two non-suggestions for Abandon; I like 'outstanding' better than the replacement texts I could think of: 4.2.1 (Processing of the Bind Request): s/outstanding/previous/. 4.3 (Unbind Operation): s/outstanding/remaining previous/. 4.4.1 (Notice of Disconnection): s/outstanding/remaining/. 4.11 (Abandon Operation): Not s/outstanding/previous/ (server side), that implies operations that have responded too. Not 'uncompleted previous', that looks a bit like the server must at least have started to process the operation. 4.14.3 (Removal of the TLS Layer): s/outstanding/remaining previous/? 5.1 (Operation and LDAP exchange Relationship): s/outstanding/remaining/ (server side and client side). A.2 (Result Codes#operationsError): s/while there are other operations outstanding/ before all previous operations have completed/ ? [Authmeth] 3.1.1 (Start TLS Request): > A client may send the Start TLS extended request at any time after > establishing an LDAP connection, except: > (...) - when previous requests remain for the server to process on the same LDAP exchange. > The result of violating any of these requirements is a resultCode of > operationsError, as described in [Protocol] section 4.13.2.2. Client > implementers should note that it is possible to receive a resultCode > of success for a Start TLS operation that is sent on a connection > with outstanding LDAP operations if the server has sufficient time s/outstanding LDAP operations/remaining previous requests/. > to process them prior to its receiving the Start TLS request. > Implementors of clients should ensure that they do not inadvertently > depend upon this race condition. Kurt D. Zeilenga writes: >At 04:13 AM 5/19/2004, Hallvard B Furuseth wrote: >>I wrote: >>> A recent poster to the OpenLDAP-software list had not understood what an >>> outstanding operation is. Maybe [protocol] should define it at the time >>> of first use. Something like this: >>> >>> at the server: a request which is being or waiting to be processed. >>> at the client: as above, >> >>including requests sent by the client which the server has not yet >>received, >> >>> , or an operation for which the server has >>> sent a response which the client has not yet received. >> >>It gets a bit cumbersome, I'm afraid. > > That's my fear. Are such clarifications going cause more > confusion? > >>Improvements are welcome:-) > > My suggestion would be avoiding the need to define the > term. Instead, I would try to reword any sentence which > used the phrase "outstanding operation" (or "outstanding > request") to be reasonable clear without having to > rely on separately stated terminology definitions. -- Hallvard |