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.
If it is only sent in the forking cases, this optimization may not be
worth the trouble.
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.
Thanks,
Paul
Hadriel Kaplan wrote:
-----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
