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