Hadriel Kaplan wrote: >> -----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. ;) >
RFC 2119 section 6 says: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I'm not at all sure we can justify MUST NOT here. It's not required for interop, does not cause harm to the network, and there are presumably legit use cases (such as diagnostics) for using it in a Require. -- 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
