Subject: [Sip] Open Issue #109: Allow in non-INVITE

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 21:07:32 -0500

Issue:

There are two issues. Both are minor:

  * do we allow Allow in requests outside of INVITE and OPTIONS?
  
  * If I send OPTIONS to sip:[email-masked], and the response has an Allow,
what does that mean exactly? Does that mean that it is safe to send the
methods listed in the Allow to sip:[email-masked] in the future? Or that its
safe to send the methods listed in the Allow to the URL in the Contact of
the OPTIONS? After all, a subsequent request might not route to the same UA
that got the OPTIONS; so, even if the OPTIONS response indicates that method
BAR is allowed, there is no guarantee that when you send BAR to
sip:[email-masked], it will get to the same UA which respoded to the OPTIONS.

Discussion points:

For the first issue, lets KISS and disallow it. Extensions can of course
indicate whether its useful.

For the second one, its worth observing that this concern is true for all
other headers in the OPTIONS response - Accept, Accept-Encoding, Supported,
etc. In fact, its true for headers like WWW-Authenticate and Authorization.
I may call a UA, it returns a 401 w/ WWW-Authenticate, I stick in an
Authorization header, and resubmit the request, but it gets routed
differently, to a different UA. Same issue. I don't think its a big deal,
since in all cases you'll simply get the appropriate error code and can try
again. 

Proposal:

* point 1: disallow
* point 2: don't care. Allow refers to methods supported by the resource in
the request URI of the original OPTIONS request sent by the UAC. 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 06 Dec 2001 14:35:54 -0500

>   * do we allow Allow in requests outside of INVITE and OPTIONS?

Meaning BYE and CANCEL? Presumably the spec wouldn't need to (shouldn't)
say anything about, say, SUBSCRIBE.

> the request URI of the original OPTIONS request sent by the UAC.

Agreed; uniform treatment of all Accept-* and Allow is important, as
they express capabilities. This should be true for point 1, as well.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Dec 2001 00:49:10 +0200

> since in all cases you'll simply get the appropriate error code and can try

What about disallowing Allow in methods that do not establish dialogs?
OPTIONS would be the only expection to the rule.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2001 02:21:50 +0200

Hi,

What about INFO?

Let's assume that we now (or in future) will have method X, which is
used for some specific service. At some point during the call, some node
doesn't want to receive X (for whatever) reason, so it informs that by
sending an INFO with a new Allow header, without X. 

Or, is INFO even the correct method to use for this? It does not change
the state of the SIP call, so I don't think a re-INVITE is needed to
change the Allow during a call...

Of course, the node can always reply with 405/503/whatever if it
receives X. But, if it knows it will not accept X, it could inform other
nodes about that using INFO, including a new Allow header, so they won't
try to use X in the first place...

Regards,

Christer Holmberg
Ericsson Finland