Sure we make mistakes just like anyone, 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. -hadriel > -----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
