Re: [sipcore] RFC 3261: 305 Use Proxy

On 12/7/13 1:26 PM, Brett Tate wrote:
> Hi,
>
> As indicated within the following snippet from draft-rosenberg-sip-route-construct-01, the 305 response is underspecified within RFC 3261.
>
> What is the expected behavior concerning how to handle a 305's Contact: replace Request-URI or utilized as a Route header?  The snippet indicates that the unstated assumption is that it populates the Request-URI.

I don't know. AFAIK this was never satisfactorily clarified.

If we wanted to clarify this, I think the first thing we would want to 
do is take a survey of any known current uses of 305. (Hopefully there 
are none, because nobody knows how to use it.)

	Thanks,
	Paul

> Thanks,
> Brett
>
> -----
>
> 2.4  305 Use Proxy
>
> RFC 3261 defines the 305 "Use Proxy" response code, but says
> extremely little about exactly how it is used.  It has this to say:
>
>     The requested resource MUST be accessed through the proxy given by
>     the Contact field.  The Contact field gives the URI of the proxy.
>     The recipient is expected to repeat this single request via the
>     proxy. 305 (Use Proxy) responses MUST only be generated by UASs.
>
> It is unclear how the Contact in the redirect is used.  Does it
> populate the request URI of the resulting request?  Or, does it get
> used to populate the Route header field?  The restriction to UASs is
> also not explained.
>
> Historically, the reason for the restriction to UAs was to avoid
> routing loops.  Consider an outbound proxy that generates a 305,
> instead of proxying the request.  The concern was that the client
> would then recurse on the response, populate the Contact into a new
> request URI, and send the request to its default outbound proxy,
> which redirects once more.  To avoid this, the RFC says that only a
> UAS can redirect with a 305, not a proxy.
>
> However, this design decision on 305 handling was made prior to the
> conception of loose routing, although both ended up in RFC 3261.  The
> design of the 305 mechanism, unfortunately, was not revisited after
> loose routing was specified.  As such, the draft is not clear about
> whether or not the contact gets utilized as a Route header field
> value or whether it replaces the Request URI.  The assumption,
> unstated, is that it populates the Request-URI, since redirection
> works that way in general.
>
> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>