Hi Hadriel, >Sure we make mistakes just like anyone,
So, soon people will have to start deploying SBCs, in order to fix the mistakes made by their existing SBCs..... ;) >though with regard to MUST NOT's we follow them more often than I think we ought to, ironically. >But no I was not referring to us - I was referring to the (rather common) situation where a device does not follow a SHOULD NOT, and because it was a SHOULD instead of MUST strength they get away with >claiming it was not required to be followed. > >Maybe it's just me who sees this happening? That's certainly possible and if so I'll shut up about it. I've seen lots of funny stuff during the years also. But, I think the correct way to prevent those is to make sure our specs are clear enough, and easy to understand - not to start making restrictions which may shoot back later. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 1:25 AM > > So, YOUR developers are the ones who are stupid? ;) > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > > Sent: 22. marraskuuta 2008 19:35 > > To: Christer Holmberg > > Cc: SIP IETF > > Subject: RE: [Sip] Sip-199-02: majors and nits from Robert > > (was: RE: WGLC for draft-ietf-sip-199-02) > > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > > > Sent: Saturday, November 22, 2008 7:55 AM > > > > > > I don't like must-nots if it doesn't break the protocol. > > But, I agree > > > we should strongly recommend against it. > > > > Developers and product managers read SHOULD NOT as basically > > optional, and customers have a hard time forcing vendors to follow > > SHOULDs compared with MUSTs. We've seen this time and time again. > > The _protocol_ may not "break", but user expectations and experience > > "breaks", and at the end of the day that hurts all of us. Well, it > > doesn't hurt me right now > > - it's created a market opportunity for SBCs to go and fix it; but > > having middleboxes fix bad implementations is not good in the long > > term for SIP. > > > > IMO interoperability isn't just about _protocol_ behavior, it's the > > resultant user experience too. Legitimate call attempts must > > succeed. The spice must flow. ;) > > > > -hadriel > > _______________________________________________ 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
