To get the case you are concerned with, the UAS would have to retain some state in order to realize that you have been trying a lot and have become annoying.
If it is that smart, the ideal answer would I think be to return a 401 with a Retry-After header telling you not to try again for awhile. (If you have been sufficiently annoying, this could be years in the future.)
Unfortunately, it appears that the Retry-After header isn't allowed in a 401 response. Second best would probably be to return a 480 with a Retry-After header, just to get you to go away.
I don't see that 403 is ever the right answer if credentials are required and you have not presented valid ones. I think the UAC should treat 403 as meaning you are recognized but not permitted to do what you ask. If it is used improperly by some UAS then you will get odd behavior until you beat up the vendor to use a more appropriate response.
Paul
David Stuart wrote:
It's not that I haven't read the relevant rfc sections, but I am coming at the problem from a slightly different angle. I am trying to clarify what should be done on the UAC from a behavioral standpoint. It seems to hinge on how a 403 is interpreted.
A number of people here have suggested that a 403 response means "I know who you are, but you are not allowed to do that". i.e. the authentication is good, the request is properly formulated, but you're doing something which is not permitted. If I use this interpretation, then when the UAC receives a 403, the request is aborted, but the credentials are reused in subsequent requests. This seems to be what section 21.4.4 says.
But, if we interpret the 403 to mean what you have suggested, "Your credentials are bad, stop bugging me". Then in this case the request would also be aborted, and what's more, the UAS is telling us in no uncertain terms that the credentials are incorrect. I believe the right response from a UAC in this situation would be to abort the request, and not use those credentials in subsequent outgoing requests (please correct me if I'm wrong here). This seems to be what secion 22.1 describes.
Therein lies the dilemma. If the UAC receives a 403, there is no good way for it to know whether or not the credentials should be used in subsequent requests.
Hopefully I'm not missing something obvious, here.. :P
Jerry Ipe Thomas wrote:
If we go into a REQUEST-401/407-REQUEST-401/407 loop, it serves no purpose.
If the entity being authenticated cannot provide valid credentials (say, if
policy says more than 3 times) it is a good idea to respond with a 403 "Go To Hell".
Also, a server can reject a request for reasons that violate domain policy.
403 is THE correct response to tell a UAC to "shut up" and "buzz off"! ;-)
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
