Re: Sip-199-02: majors and nits from Robert

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