Please find my comments inline.
I disagree. Your assessment is quite at odds with my recollection of the history here.
The problems we had with loop detection were that it became increasingly unclear about what a loop was, as opposed to a spiral. Initially (in rfc2543), a loop was any request that arrived at the same proxy (there were no spirals). It became clear that this was broken, so we had to consider changes in the request URI. Then, we ran into cases were other fields would change, such as Route headers, and those had to be taken into account as well. Real implementations were frequently getting this wrong, hampering interop and proper functioning of applications. As we began to realize that more and more headers might need to be taken into consideration, it became clear that properly doing loop detection was simultaneously ill-defined and complex to implement (potentially requiring hashes of the entire message).
I have to admit I am quite unaware (ignorant) about these real-world problems.
That is coupled with the fact that such loop conditions will probably be rare in deployed networks. Unlike IP routing, SIP routing is considerably more static, and I consider the likelihood of real loops a rare one outside of a lab. Thus, its appropriate to handle them in a way which perhaps consumes more resources, at the cost of much lower complexity, and more importantly, proper operation in the normal case. Thats the max-forwards mecahnism. It is much easier to implement, always correct in the normal case (i.e., it won't mis-detect loops), and much more interoperable.I have to take your word on this (that loops are rare). But sure it creates havoc once
In other words - this is good engineering practice. We don't worry about optimally solving a corner case, we optimize for the baseline case.
I agree with this. Then can we assume (or hope) that in future standard loop detection would be deprecated?
Here I was trying to address (solve) a particular problem where statelessI am at a loss as to why you believe this will solve all the ails of loop detection. It is very easy to combine the functions of unique identification along with the change-detection functions of loop detections. You merely include a transaction ID as part of the long hash you are already doing. I fail to see why that is hard.I suggest removing the loop detection part from the branch-id parameter and placing it in a new parameter. Having loop detection done using a separate parameter would avoid it from interfering with branch-id's primary use as transaction identifier.