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

At Tue, 22 Feb 2005 15:29:34 +0900,
Shoichi Sakane <[email protected]> wrote:
> 
> > > > > so I would like to propose the following process.  any idea ?
> > > > > 
> > > > >    All node conformed to the document MAY implement the KE payload
> > > > >    handling.  If a node receives a KE payload, and the receiver does not
> > > > >    support the KE handling, and does not want to proceed the negotiation,
> > > > >    then the receiver SHOULD send a Notify payload of the type
> > > > >    NO_PROPOSAL_CHOSEN to the sender.  If the receiver wants to keep the
> > > > >    negotiation without the KE payload handling, then the receiver sends
> > > > >    a response witout a KE payload.  the sender MAY reject it by its policy
> > > > >    in this case.
> > > 
> > > I meant the sender was the initiator.
> > > 
> > > > The sender (I assume you meant the initiator) can't reject it
> > > > because the ACK message can't carry it.
> > > 
> > > the one does not need to proceed the ACK handling.  as referencing to
> > > the section 7.2, when the initiator reject it, then the initiator
> > > SHOULD re-send a CREATE message without KE payload.
> > 
> > How the responder distinguish it from a brand new CREATE?
> > Without distinction, the responder can't know whether the
> > first CREATE succeeded or not.
> 
> 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).

-- 
KAMADA Ken'ichi <[email protected]>