On 04/25/2011 03:11 PM, Worley, Dale R (Dale) wrote: > > IMHO, 6xx responses are globally authoritative in that >> the chance of using the same R-URI to perform a lookup somewhere >> else does not have any higher probability of success. 4xx response >> are repairable; if you can't get to the resource at one server, >> maybe another server can help. > It's true that 6xx responses are globally authoritative, but what > they are asserting is not that the *same* RURI in another location > would produce the same result, but rather that the no success can be > obtained by *any other fork of the same INVITE*.
Dale: I am not sure I agree completely. The above text interprets the behaviour of a response class in the context of forking. Furthermore, it appears to imply that because the use of this response class does not work with forking, we cannot use it anywhere else. In an earlier email [1], I outlined two cases where a globally authoritative usage appears to make sense, although note that no forking was involved in these examples. At its heart, I suspect that processing the directives of rfc3261 with respect to the handling of 6xx makes this is a HERFP problem. If rfc3261 was to treat the 6xx response class as any other response class, then things would work as intended since the 6xx would not mask a lower class response. If processing 6xx is fraught with problems, then maybe you should resurrect your draft-worley-6xx-considered-harmful-00 in sipcore and see if we can do something about this. We put 6xx there for a reason. I am sure our collective wisdom should retain why it was put there even if my individual recall does not stretch that back into the past. [1] https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-April/026979.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / [email protected] Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
