[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Does retargeting belong on the list of Evil SIP Ideas?

Boy do you guys ever have axis to grind!

On Nov 23, 2004, at 4:34 PM, Paul Kyzivat wrote:

Dean,

Rather that the "list of Evil SIP Ideas", I propose this be called the "axis of Evil SIP Ideas".

	Paul

Dean Willis wrote:
I try to keep a running list of things that turned out to be a royal pain that needs (or needed) fixing. Some of these things sounded cool at first, and I championed them. Others I never did like. Some of these things I'm not allowed to suggest deprecating anymore -- we took a hum on forking a few meetings back. One of these days I'm going to get this list better organized and post it someplace more persistent in the hope that it may assist in avoiding repeptition of mistakes. And someday, perhaps we can do something about some of these quirks.
To-date, I believe the Evil List includes:
1) Replacing the Request-URI at each hop while routing was Evil. We fixed this with Loose Routing mode, which is still slightly Evil.
2) Abusing To and From to indicate branches is Evil. We should have left these as real endpoint identifiers.
3) Forking is Evil.
4) Allowing (and requiring) responses to carry a payload with more meaning than "I acknowledge having received that request" is Evil. Since we can't reject a response, we can't deal with big responses and can't negotiate what they carry. Acknowledgement and response are different beasties -- one is transport, the other is application, and we need to understand the difference.
5) The three-message INVITE transaction model and its dependence on payload in the response is Evil.
6) The two-message non-INVITE transaction model and its interaction with retransmission and hop-by-hop cascade (See Sparks' non-invite analysis) is Evil.
7) Building transport state and reliability into the application state and requiring a transport protocol extension for every new application semantic is Evil.
8) Using z9hG4bK on via fields rather than a negotiated mechanism (like maybe a version) is Evil.
9) Jon argues that not requiring SIPS to be end-to-end is Evil. I think the jury is still out on this one, but we're still deliberating.
10) Provisional responses, as currently constructed, whether reliable or non-relaible, are Evil. This may be redundant with the NIT discussion.
11) I believe I'm coming to believe that "retargeting", i.e. changing a request in a proxy such that the entity to which it is delivered has a different assertable identity than the identity to which the request was originally addressed, is Evil. Perhaps it could be mitigated by a assertion of transitivity: "I, the proxy identified herein, do assert that I have altered the target of this request according to local policy, and you can either deal with it or go away." Oh wait, that's the 302 response . . . Perhaps this is redundant with "Forking is evil" as forking is just a special case of retargeting. Or perhaps forking and retargeting are both special cases of "exploders" and could both be dealt with using the consent framework . . .
Sometimes I wonder if the use of UDP was fundamentally Evil.
If I've missed something blatantly Evil, please comment back, and I may add it to the list I hope to post someplace.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran at cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip