Subject: Re: Provisional Response Draft

From: Rohan Mahy <[email-masked]>
Date: Thu, 09 Mar 2000 14:24:48 -0500

At 01:28 PM 3/8/2000 -0500, you wrote:
>
>
>Anders Kristensen wrote:
>> 
>> "K. K. Ramakrishnan" wrote:
>> >
>> > I also appreciate the need to not have special casing for methods -
>> > but is this extra messaging coming about because we chose to
>> > have the PRACK as a "method"? On the issue of backwards compatibility,
>> > couldn't we say that proxies shouldn't be creating transaction state
>> > for things it doesn't understand?
>> 
>> This proposal is itself not backwards compatible.  Also, it doesn't seem
>> quite right - it would mean, for example, that proxies cannot fork on
>> requests they do not know. This seems like a big limitation.
>
>I agree completely here with Anders. The spec clearly defines handling
>for unknown requests as if they were BYE. 

Hi,

Actually, SIP 2.0 says, "Methods that are not supported by a proxy or
redirect server are treated by that server as if they were an OPTIONS
method and forwarded accordingly." (bottom of Page 27)

Section 4.2.3 (The OPTIONS Method) goes on to say that user agents MAY
respond to OPTIONS.  I would infer from this (and a quick skim of Section
12) that there is no requirement for a proxy to respond to a method it
doesn't understand.  

Is there still any compelling reason to require the 200 OK after PRACK?

thanks,
-rohan

>As one of the design principles of SIP, we've really tried to make it a
>fairly general purpose protocol. Many of the features and capabilities
>have broad applicability and usage. Often, the result of this kind of a
>decision is a tradeoff- messages are a little bigger, or more
>information is sent, when its not always needed. I'd really like to keep
>with that design philosophy. Having special case methods to cover every
>new case, and requiring tons of Proxy-Requires to make it all work, ends
>up resulting in a tangled mess of a protocol that doesn't interoperate.
>Please, lets stick with the request-response model for all new methods.
>
>-Jonathan R.
>
>-- 
>Jonathan D. Rosenberg                       200 Executive Drive
>Chief Scientist                             Suite 120 
>dynamicsoft                                 West Orange, NJ 07052
>[email-masked]                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com
>

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 09 Mar 2000 19:54:28 +0000

Rohan Mahy wrote:
> respond to OPTIONS.

No, that's not what it says. It says UAs MUST respond to OPTIONS. The
MAY in section 4.2.3 has to do with what information goes into the
response and whether the status code is the same as what would heve been
returned had the request been an INVITE.

>  I would infer from this (and a quick skim of Section

That's not right. UAs must always respond to requests (unless they can't
because the request is too buggy - e.g. without Via headers or
whatever).

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Mar 2000 15:09:01 -0500

> Is there still any compelling reason to require the 200 OK after PRACK?

Well, perhaps you should read the rest of the sentence. There are words
after "MAY respond to this request". Lets be specific here. This section
says:

> The server is being queried as to its capabilities. A server that
>    believes it can contact the user, such as a user agent where the user
>    is logged in and has been recently active, MAY respond to this
>    request with a capability set. A called user agent MAY return a
>    status reflecting how it would have responded to an invitation, e.g.,
> 
> 
> 
> 
> Handley, et al.             Standards Track                    [Page 29]
> 
> RFC 2543            SIP: Session Initiation Protocol          March 1999
> 
> 
>    600 (Busy). Such a server SHOULD return an Allow header field
>    indicating the methods that it supports. Proxy and redirect servers
>    simply forward the request without indicating their capabilities.
> 
>    This method MUST be supported by SIP proxy, redirect and user agent
>    servers, registrars and clients.

That is it MAY respond with a capability set, or MAY respond with a
status reflecting how it would have responded to the invitation. The MAY
is a choice among how the response is formulated, NOT on whether a
response is sent.

All requests are responded to. period.

By not having the 200 OK to PRACK, we break the transactional model of
the protocol. This means proxies and UAs have all this extra state
laying around. It means spurious CANCELs and responses might get sent.
It means we probably need a Proxy-Require, and I really don't want to do
that, because it means compatibility is broken.

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 10 Mar 2000 10:06:31 -0800

Hi,

>All requests are responded to. period.

I never debated this.  The user agents will always have an opportunity to 
respond.

I agree with [email-masked], that proxies shouldn't keep state for 
methods they don't understand.  They can simply forward messages for these 
unknown methods on to the user agents or the next proxy.

>that, because it means compatibility is broken.

In my interpretation, the spec does not explicitly _require_ proxies to 
keep state for methods that they don't understand.

The spec does not explicitly _prohibit_ proxies from keeping state for 
methods they don't understand.

So what I hear Jonathan saying is that because some proxies MIGHT keep 
state for new methods, then we need 200 OK, so that we don't break them. 
Correct?  I am personally curious how many proxies would break.

Also, I hear Jonathan saying that new methods should be processed in the 
same way, and that this encourages simplicity.  Aside from the comment 
above, is there another motivation for this?

thanks,
-rohan

>Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Mar 2000 23:40:48 -0500

> unknown methods on to the user agents or the next proxy.

If you want to build your proxy that way, fine. But I think it is asking
to much to mandate that unknown methods be forwarded statelessly. The
spec as written does not mandate this.

> above, is there another motivation for this?

Yes. It leads to a clean architectural implementation. It means I can
build a base transaction mechanism that handles retransmissions and
provisional responses and stuff without detailed message semantics, and
then build semantic processing on top of this. It is this same
motivation which has led me to conclude that transactions must be kept
independent; so that, for example, if I send a BYE for an INVITE that
hasn't been answered, the UAS should still answer the INVITE. 

The issue of allowing stateful proxies for unknown methods is a big one
as well. It means that SIPs routing and searching capabilities can be
reused for other services (i.e., other methods) with existing proxies. I
think this is not to be dismissed so lightly.

While there are clear advantages to keeping the 200 OK to PRACK, the
only advantage I have heard to date for dropping it is message
efficiency. In general, I firmly believe that generality and broad
applicability are far more important design goals than message
efficiency. I discuss this in more detail in the draft I recently
submitted entitled "Guidelines for Authors of SIP Extensions".

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 15 Mar 2000 07:24:16 -0800

Hi,

Thanks for your reply.  I've read the "Guidelines" draft, and I respect 
your philosophy.  Your point was driven home after seeing the flurry of new 
methods proposed recently (SUBSCRIBE/NOTIFY, TRANSFER, PRECONDITIONS).

I was hoping the group could come to some compromise to preserve message 
efficiency, but at this point it does not seem worth the effort.

thanks,
-rohan