Iñaki Baz Castillo wrote: > El Friday 18 July 2008 17:38:44 Attila Sipos escribió: >> Thanks Michael, >> >> This is useful to know. Many people have misunderstood >> SHOULD including myself !! >> >>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >>>> may exist valid reasons in particular circumstances to ignore a >>>> particular item, but the full implications must be understood and >>>> carefully weighed before choosing a different course. >> I'm really not sneering or anything but maybe the SHOULD >> description MUST include a sentence saying: >> >> "there may exist valid reasons in particular circumstances to use a >> SHOULD instead of MUST, but the full implications must be understood >> and carefully weighed before doing so. > > I have an easier solution: > > If RFC's would include just MUST instead of SHOULD and MUST then > implementation would be easier, interoperatibility better and life happier. > > Sometimes it seems that a RFC uses SHOULD instead of MUST because the author > is not totally sure about what he's writting. >
I think the best advice for authors was from Henning Schulzinne: "My general observation is that a SHOULD in a document is underspecified unless there's a condition that indicates when the action asked for is not required." I also remember reading or hearing somebody say that all SHOULD should in fact be conditional MUST, which I agree with. The problem is that a lot of implementers takes SHOULD as a way to write sloppy code. I even read about vendors that refuses to fix a bug because the spec says SHOULD and not MUST. As an implementer, I always try to combine the SHOULDs with Postel's Prescription (“Be liberal in what you accept, and conservative in what you send.”) by considering a SHOULD as a MUST when I am on the sending side, and a SHOULD as a MAY when I am on the receiving side. -- Marc Petit-Huguenin [ ] Home: [EMAIL PROTECTED] [RFC1855-compliant space for rent ] Work: [EMAIL PROTECTED] [ ] [ ] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
