Subject: [Sipping] Updated 303 & 605 drafts available for comments

From: Sriram Parameswar <[email-masked]>
Date: Tue, 6 Mar 2007 00:12:08 -0800

Folks,

We have submitted the 01 version of the 303 and 605 drafts, till it appears in the IETF archives - you can get a copy here:

http://home.comcast.net/~sriramkp/Drafts/draft-rajesh-sipping-303-01.txt
http://home.comcast.net/~sriramkp/Drafts/draft-rajesh-sipping-605-01.txt

Thanks in advance - looking forward to your comments/suggestions,

Sriram Parameswar
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 Mar 2007 11:47:02 -0600

I'm quite confused about this draft...

It seems to me that this new 303 response code does exactly what the
existing 
300/302 response codes do.

The most common behavior now for proxies that receive a 302 response is
to 
recurse (provided it is responsible for the domain of the original
request).

I think what you are trying to do is to have a way to reliably request
"proxy recursing" and "UAC recursing". Both the existing 3XX code and
the 
new proposed 303 fail to do this.

In order for your new code to be useful, we'd have to modify the meaning

of 3XX (i.e., you'd have to deprecate Proxy recursing on 3XX).

I'm not sure at all that a new 303 response code is the best way to do
this.

Seems to me a Proxy-Required (and probably a new Proxy-Supported) in the

3XX could be defined to force either Proxy recursion or End-user
recursion.
And no new responsed code would be required. And if nothing is included,
today's behavior remains (i.e., proxy does whatever it wants).

Of course, that is if we think we need this functionality...

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 7 Mar 2007 02:32:51 -0800

Francois Audet wrote:
> existing 300/302 response codes do.
> 
> to recurse (provided it is responsible for the domain of the original
> request).
> 
> the new proposed 303 fail to do this.
> 

There seems to be some overlap here with the Request-Disposition header
defined in RFC3841.  With that, the UAC can influence how proxies handle
requests, including whether to recurse on 3xx responses or not.

This draft seems to want to allow the UAS to exert the same influence.
Allowing the Request-Disposition header in the response would be one way
to do this, although many of the directives would only be useful in the
case where a 3xx response is sent.

It would also be interesting to see what the expected behaviour would be
if the UAC requested 'no-recurse' in the Request-Disposition header, and
the UAS tried to enforce recursion using this 303 response.

> Of course, that is if we think we need this functionality...

Regards,

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 7 Mar 2007 15:32:32 -0600

So many gems in RFC 3841...

I think you are right, it does overlap. 

> -----Original Message-----
> From: Michael Procter [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 02:33
> To: Audet, Francois (SC100:3055); Sriram Parameswar; [email-masked]
> Cc: Rajesh Ramanathan
> Subject: RE: [Sipping] draft-rajesh-sipping-303-01.txt
> 
> 
> Francois Audet wrote:
> There seems to be some overlap here with the 
> Request-Disposition header defined in RFC3841.  With that, 
> the UAC can influence how proxies handle requests, including 
> whether to recurse on 3xx responses or not.
> 
> Allowing the Request-Disposition header in the response would 
> be one way to do this, although many of the directives would 
> only be useful in the case where a 3xx response is sent.
> 
> It would also be interesting to see what the expected 
> behaviour would be if the UAC requested 'no-recurse' in the 
> Request-Disposition header, and the UAS tried to enforce 
> recursion using this 303 response.
>

---

From: Sriram Parameswar <[email-masked]>
Date: Wed, 7 Mar 2007 16:54:46 -0800

Francois and Michael,

First thanks for your comments. I will try to address each in turn.

On the question of do we really need this functionality. The motivation in the draft I think is fairly compelling - forwarding to internally routable sip addresses (sip address of labs, private conference rooms etc.), restricting cellphone number distribution and others - are real world scenarios.

On the use of Proxy-Require header - it seems to me (section 20 RFC3261) that Proxy-Require is sent in Requests and is useful for UAC's. Here the UAS is trying to shield the number its forwarding to, and does not seem to be the right mechanism. I am not sure of what happened with the Proxy-Supported draft, but browsing through the slides it seems that again its controlled by what the UAC sends. This is why we suggest a new response code.

Regarding the interaction with RC3841 - its interesting (thanks Michael for bringing it to my attention), we will clarify it in the next version of the document. Here is the thinking - when we have a situation when UAC requests "no-recurse" should the UAS even send back the 303? My opinion is, if the UAS understands the 'no-recurse' directive and is forwarding to a sensitive number, it should simply send back a 4xx of its choice. If it does not understand the directive and sends back a 303, a stateful Proxy can send back a 404 Not Found as suggested in the draft (based on it remembering the no-recurse option). For stateless proxies - I am open to suggestions and it requires a bit more thinking.

Thanks,

Sriram Parameswar

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 08:57:18 -0500

Using Request-Disposition in a *response* is a novel idea. That usage 
isn't covered by 3841 - I guess it would have to be considered an extension.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 09:49:21 -0500

I don't understand how the device will know that it needs to use 303. 
Your example is "internally routable addresses". That is all relative. 
How does the device sending the 303 know that the address will be 
routable by the proxy that receives it, and will not be routable by a 
device further upstream that might receive it if the first proxy doesn't 
act on it?

Wouldn't it make at least as much sense for the proxy that receives the 
3xx to examine it, and perhaps the address of the top Via, and make its 
own decision about whether it is important to recurse now rather than 
deferring that?

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 Mar 2007 12:52:20 -0600

Yeah, I really don't like the idea of a new 303 for this.
I share Paul's concern about the UAS decides what to do.

And what is really confusing me is that in real life, most proxies
actually will recurse, and do exactly what your draft is trying to
achieve. 
So I don't understand what it is trying to achieve.

And finally, if anything, what we have been seeing for a while in SIP
and SIPPING, is people saying that proxies should NOT recurse to solve
some of the challenges with forking. (If that is doable is debatable).

So this draft seems to be going against the current.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, March 08, 2007 06:49
> To: Sriram Parameswar
> Cc: Audet, Francois (SC100:3055); Michael Procter; 
> [email-masked]; Rajesh Ramanathan
> Subject: Re: [Sipping] draft-rajesh-sipping-303-01.txt
> 
> How does the device sending the 303 know that the address 
> will be routable by the proxy that receives it, and will not 
> be routable by a device further upstream that might receive 
> it if the first proxy doesn't act on it?
> 
> Wouldn't it make at least as much sense for the proxy that 
> receives the 3xx to examine it, and perhaps the address of 
> the top Via, and make its own decision about whether it is 
> important to recurse now rather than deferring that?
> 
> 	Paul
> 
> Sriram Parameswar wrote:
> > Francois and Michael,
> > 
> > On the question of do we really need this functionality. 
> The motivation in the draft I think is fairly compelling - 
> forwarding to internally routable sip addresses (sip address 
> of labs, private conference rooms etc.), restricting 
> cellphone number distribution and others - are real world scenarios.
> > 
> > On the use of Proxy-Require header - it seems to me 
> (section 20 RFC3261) that Proxy-Require is sent in Requests 
> and is useful for UAC's. Here the UAS is trying to shield the 
> number its forwarding to, and does not seem to be the right 
> mechanism. I am not sure of what happened with the 
> Proxy-Supported draft, but browsing through the slides it 
> seems that again its controlled by what the UAC sends. This 
> is why we suggest a new response code.
> > 
> > Regarding the interaction with RC3841 - its interesting 
> (thanks Michael for bringing it to my attention), we will 
> clarify it in the next version of the document. Here is the 
> thinking - when we have a situation when UAC requests 
> "no-recurse" should the UAS even send back the 303? My 
> opinion is, if the UAS understands the 'no-recurse' directive 
> and is forwarding to a sensitive number, it should simply 
> send back a 4xx of its choice. If it does not understand the 
> directive and sends back a 303, a stateful Proxy can send 
> back a 404 Not Found as suggested in the draft (based on it 
> remembering the no-recurse option). For stateless proxies - I 
> am open to suggestions and it requires a bit more thinking.
> > 
> > Thanks,
> > 
> > Sriram Parameswar
> > 
> > 
> > 
> >>> The most common behavior now for proxies that receive a 
> 302 response
> >> is
> >>> Seems to me a Proxy-Required (and probably a new 
> Proxy-Supported) in
> >> the
> >> There seems to be some overlap here with the Request-Disposition 
> >> header defined in RFC3841.  With that, the UAC can influence how 
> >> proxies handle requests, including whether to recurse on 3xx 
> >> responses or not.
> >>
> >> Allowing the Request-Disposition header in the response 
> would be one 
> >> way to do this, although many of the directives would only 
> be useful 
> >> in the case where a 3xx response is sent.
> >>
> behaviour would 
> >> be if the UAC requested 'no-recurse' in the Request-Disposition 
> >> header, and the UAS tried to enforce recursion using this 303 
> >> response.
> >>
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Mar 2007 22:54:06 -0400

Actually, my loose route draft does propose that there is a need for a 
server to target a redirect to the immediately upstream element (proxy 
or UA). See:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt

section 6, which discusses recursion.

So, I'm not sure I agree with the general premise in 
draft-rajesh-sipping-303, that you want the redirection done by a proxy 
in the 'callee domain'. Generally, all of the use cases are covered by 
having the redirect handled by the immediate upstream neighbor. I do 
think there are legitimate cases where this is useful.

Also, the backwards compatibility mechanisms in rajesh-sipping-303 are 
not sufficient. If you limit redirection to the one-hop previous, you 
can solve this easily by including a tag in the Via header which 
indicates whether targeted recursion is supported or not.

I spent some time a few IETFs back pondering more complex models for 
directed recursion. For some insanely complex stuff, see:

http://www.jdrosen.net/papers/draft-rosenberg-sip-route-construct-01.txt

-Jonathan R.

Paul Kyzivat wrote:

>>> From: Michael Procter [mailto:[email-masked]] Sent: 
>>> Wednesday, March 07, 2007 02:33
>>>> It seems to me that this new 303 response code does exactly 
>>>
>>> what the
>>>
>>>> The most common behavior now for proxies that receive a 302 response
>>>
>>> is
>>>
>>>> to recurse (provided it is responsible for the domain of 
>>>
>>> the original
>>>
>>>> request).
>>>>
>>>> I think what you are trying to do is to have a way to 
>>>
>>> reliably request
>>>
>>>> "proxy recursing" and "UAC recursing". Both the existing 
>>>
>>> 3XX code and
>>>
>>>> In order for your new code to be useful, we'd have to modify the
>>>
>>> meaning
>>>
>>>> I'm not sure at all that a new 303 response code is the 
>>>
>>> best way to do
>>>
>>>> this.
>>>>
>>>> Seems to me a Proxy-Required (and probably a new Proxy-Supported) in
>>>
>>> the
>>>
>>> Allowing the Request-Disposition header in the response would be one 
>>> way to do this, although many of the directives would only be useful 
>>> It would also be interesting to see what the expected behaviour would 
>>> header, and the UAS tried to enforce recursion using this 303 response.
>>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com