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:[EMAIL PROTECTED] > Sent: Tuesday, June 05, 2007 13:55 > To: Audet, Francois (SC100:3055); [email protected] > 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:[EMAIL PROTECTED] > > Sent: Monday, June 04, 2007 16:20 > > To: [email protected] > > 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 [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
