RE: [Sip] Open Issue #7: CANCEL for non-INVITE

["Drage, Keith (Keith)" <[e-mail]>]

I would love to get the specification tidied up in this respect.

If we take Jonathans proposal, at the moment we seem to be concentrating to
much on only allowing it on INVITE. It appears to me that we should be
working in terms of those methods that are allowed to send provisional
responses.

Perhaps we could identify the following bits that should be specified

-	all methods (in the document where they are specified) should
specify whether provisional responses are allowed for that method or not. In
the bis draft they should only be allowed for INVITE.

-	we should make the text in 11.1 of the bis draft subject to this. It
seems to be general to all methods at the moment.

-	CANCEL should only be allowed on methods where provisional responses
are allowed.

-	All methods where provisional responses are not allowed should
respond "immediately" with a final response. This should probably be added
to 11.1 where the 200 ms timer is specified.

For the bis draft, this makes it the same as Jonathans proposal, but leaves
later method designers the ability to allow it or not, based on whether they
allow provisional responses or not, and keeps the bis draft as generic as
possible.

No doubt I have missed some important issues on this, but the important
thing to me is to keep as much of this as possible as generic to all
methods, including those that may be defined in the future. I want to avoid
defining exceptions to the bis draft for every method to be defined in the
future, which was the state we were in with the current text on CANCEL. 

Note that, if we have to use the SHOULD NOT for sending that Jonathan seems
to be proposing to allow compatibility with existing implementations, then
it should be allowed only for those methods that are currently at RFC
status. I would prefer to have it specified as MUST NOT.

Keith

Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail]

> ----------
> From: 	Jonathan Rosenberg[SMTP:[e-mail]]
> Sent: 	24 August 2001 8:20
> To: 	'Shail Bhatnagar'; Kim Liu
> Cc: 	Jonathan Rosenberg; '[e-mail]'
> Subject: 	RE: [Sip] Open Issue #7: CANCEL for non-INVITE
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Shail Bhatnagar [mailto:[e-mail]]
> > Sent: Thursday, August 23, 2001 3:28 PM
> > To: Kim Liu
> > Cc: Jonathan Rosenberg; '[e-mail]'
> > Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE
> > 
> > 
> > Kim Liu wrote:
> > 
> > My take is that although CANCEL for non-INVITE is academic,
> > it should be allowed. Main reason is to not make special checks
> > in the state machine about original method and this CANCEL.
> 
> This argument would be true if the cost of the CANCEL for non-INVITE was
> otherwise nil. But, thats not true. What happens if the CANCEL actually
> beats the server to sending the final response? Now, you have to actually
> cancel it. How does one CANCEL a SUBSCRIBE? A NOTIFY? An OPTIONS? Each
> method would need special code. 
> 
> Furthermore, since its usage is always a race condition, an entity that
> sends CANCEL would always need to handle the case where the cancel works
> and
> doesn't work. Thus, its extra work to do this.
> 
> 
> Note that I have stipulted that for backwards compatibility, if you get a
> CANCEL for non-INVITE, you still respond to it, but otherwise do nothing.
> In
> that sense, its "allowed", but we explicitly define it as a no-op.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip