RE: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception

["Francois Audet" <audet at nortel.com>]

What we really need is a 302 that prohibits proxy recursion.

That's out-of-scope of this draft IMHO. 

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl] 
> Sent: Tuesday, June 05, 2007 13:55
> To: Audet, Francois (SC100:3055); sip at ietf.org
> Subject: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of 
> last hop exception
> 
> Francois,
> 
> Refer to RFC3261 16.5: if a proxy is not responsible for the 
> request URI it MUST NOT recurse on 302
> 
> 416 does not have the right semantics (since the endpoint may 
> in fact support sips, proxies currently should never generate 
> this response) and
> RFC3261 section 16.7 step 4 says that a proxy responsible for 
> the URI should recurse on it (should only happen in call 
> forwarding scenarios, but still)
> 
> Lots of other error responses would prevent automatic 
> recursion, but that does not make them any more suitable than 
> 403 (which is not suitable either,
> IMHO)
> 
> If you really want to be on the safe side, a new 4xx response 
> code would be best
> 
> Regards,
> Jeroen
> 
> Francois Audet wrote:
> > Actually, 416 would achieve what you want.
> > 302 would not be backward compatible because some proxy somewhere 
> > could recurse on it, resulting in a downgrade.
> >
> > If people prefer a 416, I can put that.
> >
> > I do personaly prefer the 403, because I'd like to avoid any thing 
> > that would cause a proxy to "automatically" recurse, 
> thereby resulting 
> > in a downgrade.
> >
> > ________________________________
> >
> > From: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
> > Sent: Monday, June 04, 2007 16:20
> > To: sip at ietf.org
> > Cc: Audet, Francois (SC100:3055)
> > Subject: draft-ietf-sip-sips-04: 403 instead of last hop exception
> >
> >
> > In section 4.2
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt
> > proposes that a proxy should send 403 rather than apply the last hop
> > exception.
> >
> > Instead, I would propose that it would send a 302 with either
> > the registered Contact or the received request URI with a "sip:"
> > scheme. 403 would be confusing, because the caller cannot 
> distinguish
> > between this case and the callee refusing his call. Perhaps a new
> > response code (4xx Unsecure transport not allowed) would be better.
> >
> > Perhaps a caller preference should be defined to request such
> > behavior, similar to "fork" and "no-fork" (RFC3841). Say 
> "no-sips-sip"
> >
> > Regards,
> > Jeroen 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 


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