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
