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

From: Robert Sparks <[email-masked]>
Date: Sun, 9 Dec 2001 12:33:55 -0500

Is there anything that could be learned from an
OPTIONS request send inside a dialog (which avoids
the ambiquity you discuss below) that coudn't be
learned through the INVITE/200 OK handshake?

If so, we should allow those headers to have meaning
for OPTIONS, at least within a dialog.

If not, we should more strongly recommend (require?)
their inclusion in an INVITE 200.

There are some implementations that use an in-session
OPTIONS today, to stimulate more output from other 
implementations that are not chatty with their 200s,
primarily to determine if the other side supports REFER
before enabling transfer at their UI.

RjS

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 4:49 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Sip] Open Issue #109: Allow in non-INVITE
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 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
> 
> What about disallowing Allow in methods that do not establish dialogs?
> OPTIONS would be the only expection to the rule.
> 
> Regards,
> 
> Gonzalo
> 
> > * 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
> 
> -- 
> 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]
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Sun, 9 Dec 2001 12:33:55 -0500

We need to be careful to specify what it means to
receive a method with a disallowed header. We don't
want implementations to refuse to accept an ACK because
it contains an Allow header.

I _think_ what we mean by disallowing a header (using the
hyphen in Table 2) is the following

   It doesn't make any sense in the context of the method
   and it is safe to just ignore it if present. Basically
   this is explicitly saying "it doesn't mean anything 
   here" or "in this context, it is an undefined header"

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Dec 2001 14:49:56 -0500

Robert is correct.

The conclusion on this issue from IETF 52 was:

1. Allow, Accept and their related cousins are recommended to be present 
in requests that establish dialogs, including invite.

2. extensions that define new methods can specify different behavior, if 
they like

3. if present in a method that its not expected in, the headers are 
ignored as per the definition of "-" in the table.

4. Allow in OPTIONS response is scoped to the URI in the original 
OPTIONS request. Thus, if I send OPTIONS to sip:user@domain, and get 
back Allow:foo, this means foo is likely to succeed in subsequent 
requests to sip:user@domain, no guarantees, of course.

Point (4) covers the case of using OPTIONS in a dialog to solicit 
capabilities, but note that the plan is NOT to explicitly scope that 
information to just the dialog, although that can always be done as an 
implementation choice.

Note that we are not specifying any semantics for Allow in an INFO 
header as per Christer's suggestion; OPTIONS would be the preferred 
approach.

-Jonathan R.

-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com