Hi, I think it would also have been very useful to have a Forking-Proxy-Require header.
Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 25. marraskuuta 2008 2:52 > To: Hadriel Kaplan > Cc: Christer Holmberg; SIP IETF > Subject: Re: [Sip] Sip-199-02: majors and nits from Robert > > > > Hadriel Kaplan wrote: > > > >> -----Original Message----- > >> From: Christer Holmberg [mailto:[EMAIL PROTECTED] > >> Sent: Monday, November 24, 2008 4:24 PM > >>> 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. > > Thanks, > Paul > _______________________________________________ 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
