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