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*?
> 
>For each options tag, the RFC defining it should discuss when 
>it is used in requests by the UAC.
> 
>It might be reasonable to give guidance about NOT using one; 
>that is not using it in a Require. But the level of guidance, 
>I think, is a SHOULD NOT. This needs to be explained: What 
>happens if you do it anyhow? the answer is not "the network 
>breaks", but "any UAS not supporting this feature will reject 
>the request. Since this feature is only an optimization over 
>previous behavior, rejecting a request over this lack is very 
>likely to be undesirable behavior. Don't be stupid."

Based on the use-cases etc we have today, I think we all agree that one
really shouldn't require 199, so I don't think we need to argue about
that.

And, if the group wants to forbid Require:199 we will of course do that.
My personal prefernce, however, would still be to add text which
strongly discourages the use of Require.

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