Re: Misuse of the term "association" in [Protocol]

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
> I have reviewed each occurrence of the word "association" in
> [Protocol] technical specification and believe the following
> changes should be made:

Some look good to me, others do not:

>The 4.6 text:
>>   If the association changes or the connection fails,  
>>   whether the modification occurred or not is indeterminate.
>should read:
>>   If the LDAP exchange is terminated, or the Modify operation
>>   is abandoned due to subsequent operation which requires all
>>   outstanding operations to be abandoned (e.g., the Bind
>>   operation), whether the modification completed successfully
>>   or not is indeterminate.

Why the "due to..." part - doesn't the same apply to an operation
abandoned by the abandon operation?

I disagree with the change to "completed sucesssfully".  The new
language looks like the modification might be partially completed.

>The section 4.11 text:
>>   The function of the Abandon Operation is to allow a client to request
>>   that the server abandon an uncompleted operation.
>should read:
>>   The function of the Abandon Operation is to allow a client to request
>>   that the server abandon an uncompleted operation previously requested
>>   in the LDAP exchange.
>(The above clarification facilitates the below change.) 
>
>The section 4.11 text:
>>   The MessageID is that of an operation which was requested earlier in
>>   this LDAP association.
>should read:
>>   The MessageID is that of an earlier request whose response is
>>   outstanding.

Why not just s/LDAP association/LDAP exchange/ instead of these two
changes?  The new text is fine from the client's point of view, but
on the server side, the response may no longer be outstanding when
the abandon request is received.

>The section 6 text:
>>   Server implementors should plan for the possibility of an identity in
>>   and association being deleted, renamed, or modified, and take   
>>   appropriate actions to prevent insecure side effects. Likewise,
>>   server implementors should plan for the possibility of an associated
>>   identity's credentials becoming invalid, or an identity's privileges
>>   being changed. The ways in which these issues are addressed are    
>>   application and/or implementation specific.
>should read:
>>   Server implementors should plan for the possibility of that
>>   information used to establish security factors may change
>>   (due to protocol or external events) during the course of
>>   the LDAP exchange, and even during the performance of a
>>   particular operation, and should take steps to avoid
>>   insecure side effects of these changes.  The ways in
>>   which these issues are addressed are application and/or
>>   implementation specific.

I'd like to see renaming or deleting an identity (or a DN) retained in
the text as at least an example.

-- 
Hallvard