Re: #23 [*] KE interoperability (section 6.8)

> > can the Transaction ID be used for this purpose ?
> > otherwise, the section 7.2 description won't work, will it ?
> 
> I don't like sending multiple (different in parameters) commands
> in a transaction.
> - It makes things complex when packets are dropped, retransmitted,
>   reordered, etc.
> - The current spec says "A transaction is defined as a command,
>   a reply, and an optional acknowledgment."
> 
> I interpreted the word "reinitiate" in section 7.2 that
> we can take another transaction(s).

Okey, It is bad thing to reinitiate with identical transaction identifier.
It would be better to improve the text about the reinitiation and
the usage of the transaction ID.

I think that this issue is not only related to the KE payload handling,
but also the case when the responder does not choice the optimistic
proposal from the intiator.

for keeping the consistency of the protocol design, we have three choices.

1. the KE handling is an implicit proposal.
   When the initiator send a KE payload, but the responder will not reply
   with a KE payload, that means the responder does not want to choice the
   KE handling, or does not support it.  The initiator must proceed the
   session as if the KE handling was not present at all.

2. the KE handling is an explicit proposal.
   When the initiator gives choices of the KE handling to the responder,
   then the initiator must send two proposals.

3. the KE payload handling can not be negotiated.
   When the responder does not like the KE handling, the responder just
   reply an error.  The initiator must proceed the next step properly.

#3 is easy, isn't it ?