> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Christer Holmberg > > >maj-3) The document defines an option tag but doesn't say what it means > if it shows up in a Require: header. > > I think we could say that it means that the UAS must support 199. > Whether it then actually sends 199 depends on whether it fulfils the UAS > criteria for sending 199 (see maj-2).
I think that is bad mojo. You don't want calls failing just because a b2bua or the far-end UAS doesn't support 199. What recourse would there be for the UAC? What would the UAC do if it got a 420 response because of it? It would make the call again without the 199 option tag in Require, or worse it would fail the call and the user will call tech support - because nothing is going to change when they make another call attempt with that option tag in Require. And that is basically the definition of when NOT to put something in Require, but rather in Supported. IMHO the draft should say a UAC MUST NOT put the option tag in the Require header. If there's some reason some UAC has to do it, they'll ignore the MUST NOT anyway. But they should think long and hard before making that mistake, and someone who buys their product should be able to complain to them that they don't comply with the RFC. I'm almost tempted to say we shouldn't even have an option-tag at all (the Supported lists are getting quite big), but I'm guessing we'll have interop issues without it because some UAC's will barf on receiving a 199, so the UAS needs to know if it can send it. :( -hadriel _______________________________________________ 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
