Hi, >ISTM that the kinds of failures that will result from inappropriate use of Require:199 are self limiting. They will break things early in interop testing, and be fixed. > >Omitting the option tag altogether wouldn't be so bad either. All UAs must be prepared to handle unknown error codes. If not understood, the >199 will be treated as a 100. (Hmm, considering the special treatment of 100, that isn't wonderful, but it does no harm.) > >IMO the only reason to have the option tag is as an optimization, to prevent the sending of the extra message unless somebody cares about it.
Yes. That is the reason we decided to add the option-tag. >If it is only sent in the forking cases, this optimization may not be worth the trouble. I see no trouble. We would just need to agree on some wording. >Bottom line, I propose we either: >1) have the option tag, and allow both Supported and Require, but include words discouraging Require; or >2) drop the option tag entirely. I will give my hum for 1). Regards, Christer > >> -----Original Message----- >> From: Dean Willis [mailto:[EMAIL PROTECTED] >> Sent: Sunday, November 23, 2008 11:17 PM >> >> I'm not at all sure we can justify MUST NOT here. > > And that in a nutshell is why middleboxes end up doing interop fixing stuff. > > >> It's not required for >> interop, does not cause harm to the network, > > There are thousands of deployed SIP networks. Not one of them currently supports this 199 mechanism, AFAIK. Putting it in a Require will not interoperate with any of them, and has a potential for causing harm to the service SIP is supposed to provide: session establishment. Obviously this interoperates in the sense that the far-end will fail it, and we have to be able to add option tags in Require for some new things; but this 199 mechanism isn't in the same vein as privacy or replaces option tags which need to be put in Require sometimes to make calls work. Honestly we should have been more careful in the past about this, so we might as well start now. > > You may think this is a no-brainer, and that no one would be so dumb as to put it in a Require, but history has already proven otherwise for other option tags. Been there, done that, have the T-shirt. It works in the closed environment they deploy in at first, and then breaks when the environment grows or is no longer closed. I can already envision what will happen with 199: some other SDO will decide this 199 thing is a good idea and makes the user experience better, so it should be required in release X of their specs. > > >> and there are presumably >> legit use cases (such as diagnostics) for using it in a Require. > > Then say MUST NOT except for diagnostic purposes. > > -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 > _______________________________________________ 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
