[Jingle] [Fwd: [Sip] How did we get here? (Was Re: Signing P-Asserted-Identity)]
stpeter at stpeter.im
Mon Jul 14 16:00:56 CDT 2008
Some wonderful humor from Dean Willis on the sip at ietf.org list, and
perhaps some cautionary lessons too. :)
-------- Original Message --------
From: Dean Willis <dean.willis at softarmor.com>
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
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.
Sip mailing list https://www.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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080714/dbdb9043/attachment.bin
More information about the Jingle