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@cs.columbia.edu for questions on current sip
> Use sipping@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@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip