The starting point of the mistakes was tying any form of identity to the transaction identity of the protocol. At least some of the problems would not have existed if we had broken that link.
But that is way back in the fundamentals of the protocol design along with the poor compatibility specification. Regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: Monday, July 14, 2008 9:04 PM > To: Byron Campen > Cc: [email protected] > Subject: [Sip] How did we get here? (Was Re: Signing > P-Asserted-Identity) > > > On Jul 14, 2008, at 11:32 AM, Byron Campen wrote: > > > > >> > >> On Jul 13, 2008, at 12:49 PM, Hadriel Kaplan wrote: > >> > >>> But for a lot of cases they're not modifying To/From for > that reason > >>> - they're modifying it to either "fix" them for specific interop > >>> reasons, or to hide topology (ie, when it contains IP > Addresses or > >>> hostnames). Those are the cases I'm trying to get the > information > >>> through. > >> > >> > >> DY> Just to add to what Hadriel said, one of the additional > >> arguments *for* an SBC that I've had given to me by > different vendors > >> at various shows is that they can "normalize" SIP and make SIP > >> interoperability actually work between different vendors. The SBC > >> understands how exactly Vendor X speaks SIP and how > exactly Vendor Y > >> speaks SIP and can then enable the interconnection/ > interoperability. > >> So the reality is that there are SBCs out there that view > as part of > >> their function to "fix" SIP so that it can be interoperable. In > >> doing this "fixing", one can expect that the SBCs would be > changing > >> headers. > >> > > > > I would say I don't know whether I should laugh or cry, > but laughter > > is obviously much more fun. Seriously; how ridiculous do > things need > > to get before we can no longer keep a straight face? (I gave up a > > while ago) > > > > > You're right, it's a Really Big Mess. > > There are several mistakes we've made again and again that > got us where we are: > > 1) Writing specifications dramatically ahead of > implementation experience. > > 2) Hacking up bits of our core protocol model to appease the > adherents of strict interworking with legacy phone systems, > and accepting broken requirements from the same. > > 3) Using MUST to describe "does" in explicative text, thereby > preventing RFC 2119 language from being useful in tabular > comparison of implementations to the specification or to > other implementations. > > 4) Multiple ways of doing things, including a P-header > appeasement thing vs a "standard" solution. > > 5) Failure to deprecate the specifications and pieces of > specs that either don't work or don't get used. > > 6) Demanding "perfect" security in the specification, when we > know quite well that nobody will implement the security > features, especially if they're hard to build or operate. > > 6) Refusal to deprecate a whole lot of cruft and revise the > version number of the protocol. Trying to negotiate backward > compatibility for every design mistake we ever made is a > nightmare. Let's at least find a way to make this a bounded problem. > > 6) Listening to me when I'm wrong. > > 6) Not listening to me when I'm right. > > 7) Trying to count our mistakes on our fingers while we're > busy typing. > > -- > Dean > > _______________________________________________ > 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
