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

Shoichi Sakane <[email protected]> Tue, 22 Feb 2005 15:29:34 +0900
Newsgroups gmane.ietf.kink
Message-ID <[email protected]>
> At Tue, 22 Feb 2005 14:30:38 +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 ?