Thomas -
Sorry for not directly answering this question earlier.
My position is to not deprecate rewriting.
I do think rewriting is overall a bad idea and that double-RR is a
much saner approach, and your document does a good job of explaining
why.
But there are simple environments where rewriting is working in the
field. I don't see the benefit of making what they're currently doing
a violation
of the protocol at the moment. Showing them better ways, seeing
everyone implement them, and later deprecating the behavior seems the
more
effective way to proceed.
That said, I don't feel strongly about this and I certainly won't
fight to keep rewriting around.
RjS
On Apr 26, 2007, at 12:25 PM, Thomas Froment wrote:
but isn't this a local matter within a proxy, i.e., why should
anybody
else care?
RR is for sure the matter of SIP proxies, and the question you
asked on UDP to TLS case is a question that many implementors had
one day or another.
Sometimes it raises interoperability problems by making UAs change
their transport betwen initial and subsequent requests, generally
asking the proxy implementor: "why the hell you don't put any
transport on your record route since I contacted you using TCP?"...
So, if the BCP is useful for SIP proxy developers, this is still
something...
Moreover, it happens that implementations choose bad work-arounds
to bypass it, for instance by keeping the same transport for the
whole duration of a dialog (in UAs), whatever the route or RFC3263
says...
Finally, I would like to go back to my initial poll who did not get
any answer:
who would like to deprecate RR rewriting?
who want to keep it?
who care? ;-)
Regards,
Thomas
_______________________________________________
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
