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

(Due to travel, I probably missed some of the discussion, so excuse me
for re-raising old issues.)

A few notes:

- I think the complexity of CANCEL for non-INVITE on the server side is
essentially zero. If you don't implement it, you can either return 481
(i.e., the request has already been completed) or 405 (but see below).

- If we don't allow CANCEL for non-INVITE, we have to extend the
definition of 405 (or define a new status code), since the method *is*
supported for an INVITE for the same URL. To wit, the current text says:

"The method specified in the \header{Request-Line} is not allowed for
the
address identified by the \header{Request-URI}.  The response {\MUST}
include an \header{Allow} header field containing a list of valid
methods for the indicated address."

Note that this defines the granularity of requests at the URI level, not
at the method level.

- Does anything else get simpler if we disallow CANCEL for non-INVITE?

- Under the current model, non-INVITE transactions can have non-zero
duration, if you return a 1xx response. Thus, it is at least conceivable
that there are methods where the CANCEL could actually accomplish
something.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip