Paul, Yes, I agree. Your argument is a stronger one than the UPDATE argument I put forward earlier.
John > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 18 October 2007 13:49 > To: Dean Willis > Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg > Subject: Re: [Sip] INFO > > I think this problem can be solved with a 2-way exchange. > Introducing a > 3-way exchange means that the "delayed offer" needed for 3pcc > can't be > supported in a straightforward way. IMO that is a strong argument > against it. > > Paul > > Dean Willis wrote: > > > > On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: > > > >> Why does there need to be a 3-way exchange? > >> Can the 200-ok have Events listed that weren't offered? > (why would it > >> bother to? The offerer didn't say it could do them.) > >> So isn't the ACK always a mirror image of the 200ok, in > which case why > >> bother? > >> Unless you had competing Event types, where only one > should be used, > >> or couldn't do some combo of them. And then this concept > is getting > >> bloated, and will end up looking like SDP capabilities negotiation. > >> > > > > The only argument I can see is -- it prevents race > conditions. Don't > > send an event until the ACK. > > > >> And I'm still stuck on your last question, which is what > application > >> use-case really needs directionality, other than as a nit? > > > > Yeah, me too. Or to rephrase, what application needs "I > want to send . . > > ." rather than "I understand . . ." > > > > > > -- > > dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
