Are there some compelling usage scenarios to break the tie? Henry
-----Original Message----- From: Robert Sparks [mailto:[EMAIL PROTECTED] Sent: Thursday, October 25, 2007 5:00 PM To: Sanjay Sinha (sanjsinh) Cc: sip List; Adam Roach; Dean Willis Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for direction. And there we go... not even 20 minutes. So, you are right for INFO as we have historically known it. This new gorgon that Dean is proposing is not like that INFO. It's something that's carrying state based on (effectively) an implicit subscription (or something very much like a subscription, but without any of the control infrastructure) in the INVITE. If something goes _wrong_ in that subscription, you don't have a clean separate usage you can tear down and leave the INVITE usage up (I expect pushback here, and I anticipate that when you try to _add_ that clarity, you'll end up most, if not all, of the way to just using SUBSCRIBE). Maybe to avoid the confusion you just pointed to, we could call this beast NOTINFO? RjS On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > Why does the call need to go away, if INFO is rejected? Isn't INFO not > supposed to affect call state(s)? > > - Sanjay > >> -----Original Message----- >> From: Robert Sparks [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 25, 2007 4:43 PM >> To: Adam Roach >> Cc: sip List; Dean Willis >> Subject: Re: [Sip] INFO: A recap,sense of consensus and a >> proposal for direction. >> >> I'm pretty (actually extremely) unhappy with the idea, but >> I'll try not to throw myself on the tracks in front of it. >> >> Taking a tumble down the slope: >> >> These info packages need to be separate from event packages - >> there may be some where you just derive an info package from >> an event package with a trival rfc, but it will _not_ be the >> case that it will make sense to throw any old event package's >> payload into an INFO like thing like this (think of the mess >> you'll get into with anything with a partial payload, and the >> bigger mess when you get into the infrastructure of the >> framework, including winfo and eventlists). >> >> And we'd need to specify quite concretely what happens when >> one of these INFOs gets rejected. >> In most cases, the call is going to have to go away, and I bet >> that's going to make a lot of people unhappy. >> >> RjS >> >> On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: >> >>> On 10/24/07 2:18 PM, Dean Willis wrote: >>>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>>> RFC 2976. >>>> >>>> This RFC will document use of event bodies in INFO messages >>>> exchanged in dialog usages established by SIP INVITE transactions. >>>> This will include definition of the "Send-Events" and "Recv- >>>> Events" header fields, use of those header fields in INVITE >>>> transactions to provide an offer/answer exchange, definition and >>>> use of a new option tag for this extension, and the needed changes >>>> to the registry established by RFC 3265. >>> >>> >>> I can support such a plan. >>> >>> I will continue to argue that the event packages and info packages >>> should be independent of each other, but that's a minor detail. I >>> generally agree with the larger picture. >>> >>> /a >>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ 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
