Hi, I've had a look at this draft, and have a few questions / concerns. My apologies if this is covered somehow in the overload work (I am not following it closely), or if I missed some discussion going by.
Basically, I think there are some potential problems with ambiguity, and also no good way to tell the client where (or if) to go somewhere else for service. Specifically: o 500 would become overloaded to mean either "something bad (but unspecified) happened" or "go somewhere else (maybe try again later)", but it seems impossible to determine which case it is. The name of this code implies only the former. o 503 changes its meaning to "I'm overloaded, back off (optionally don't try again for some time)". But this is not the name of this response -- it is Service Unavailable. The trouble is, there are many reasons why service may not be available, overload being just one. (Yes, I know this issue is raised as OPEN ISSUE 3 in the draft itself.) Proposals: 1. Can a new 5xx response code be defined specifically to handle overload scenarios, instead of overloading 503 / 500? This would have the explicit semantic of "I'm overloaded, back off (optionally for some time)". It could also have additional info on how the client should handle it (see next). 503 would keep its original meaning (go somewhere else), and 500 would keep its meaning (something bad happened). 2. Add a new header, to explicitly list one or more servers to go get service from, usable (at least) in 503 and the new 5xx, maybe 500 also. With this, 503 could have the additional semantic of "go somewhere else, and here's where" (optionally with a time to retry here). New 5xx could have the additional semantic of "I'm overloaded, go here instead" (optionally with a time to retry here). I can certainly see cases, even in overload handling, where the current server may want to explicitly send the client somewhere else, effectively redirecting to a different server. This could be either to an explicit server (or list of them), or just "go try somewhere else, you figure it out". Also handy for maintenance operations and for load sharing, possibly others. Lack of an explicit way to send clients elsewhere for service seems like a weakness overall. Hopefully, the above (or something along those lines) could help both dis-ambiguate, and help by acting as a redirection for those cases needing it. Minimally, it would at least make it easier to figure out (in the implementation) what the client is being told to do, and would make troubleshooting a whole lot easier. I do understand the desire to minimize changes. But it is also important to get the right behaviour, and not create situations open to too much interpretation. Yes, there would be lots of backwards compatibility issues, but any change in this stuff will have loads anyway. Just throwing some ideas out there to see if the flame throwers come out. (Donning my flame-proof suit now ..... ;-) Cheers, Peter Blatherwick
_______________________________________________ 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
