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

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