On 11/20/08 8:51 AM, Eric Rescorla wrote:
None of this is to say that there isn't room for another point in the design space than RFC 4474. However, rather than randomly selecting points in the space and trying them on for size, we should try to figure out what we're trying to achieve on both of these axes and then design specific mechanisms that achieve these ends.
I think the greatest appeal of an approach like the one in DERIVE, if it can be made to work, is that it requires no explicit support on the calling party's side. Ideally, we'd like something that I could go back to my office, code up, and begin using without waiting for anyone else to catch up. (I am, after all, the beneficiary of this behavior -- not the caller -- so I have a far greater interest in deploying something like this than they do). This proposal is not the result of picking a random point in the solution space and exploring its properties -- it is the result of actively seeking a solution with this precise property, and then examining what other properties it exhibits.
That said, the DERIVE approach has at least one major shortcoming if viewed as a mechanism in isolation: it allows you to ask the question, "does the AOR in this call setup request correspond to the device calling me?," but the only answers you can get are "yes" and "maybe."
This does not mean that it is without use; it means that it is one input to a larger system at the called party's user agent. Ultimately, I fear that fighting unsolicited/unwanted communications in SIP will require a multi-pronged approach -- one that does not necessary require support for any specific mechanisms on the calling party's UA. That means we need an entire box of tools to handle various conditions. I think DERIVE is potentially a useful tool in that toolbox.
/a _______________________________________________ Sip mailing list https://www.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
