Hi, >>>>If we can't think of any legitimate use for an option-tag in >>>>Require, why should we allow it? >>> >>>Because there may be a legitimate use for it tomorrow, or next week, >>> or next year. >> >>It occurs to me maybe we're talking past each other. When >>I think of the *Require* header, I think of what does any >>random endpoint/gateway getting this request have to support >>for this to succeed. I can see no value in having that >>behavior, and plenty of harm in doing so. I don't want a UAC >>maker to ever think it can require UAS' to implement 199 in >>order for its request to succeed. >>But maybe what you're talking about is *Proxy-Require*? > >Well, we know tht Proxy-Require is way more evil. > >Even so, it probably is the thing that a UAC might want to >use if it knew there were proxies doing the forking. > >Trouble is - B2BUAs cause a lot of trouble with >Require/Proxy-Require. I suspect that Proxy-Require should >have been MiddleBox-Require, and so applied to B2BUAs. > >So if you really need 199 responses any time a forked invite >might have been abandoned, then I think you must use *both* >Require and Proxy-Require. But that is pretty certain to >guarantee that your call will fail. > >This has convinced me that there is no valid use of Require / >Proxy-Require.
To me this has only convinced me that R/P-R in general is bad, and should be avoided. But, that we have known all the time, and nobody has argued against it. Regards, Christer _______________________________________________ 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
