-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2011 09:11 AM, Keith Moore wrote: > On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: > >> The meaning of SHOULD is clear for the authors (it "mean[s] 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."), the problem is that some implementers use a different >> meaning (I do not have to implement this if it is inconvenient or difficult for >> me to implement), vendors another one (SHOULD gave us the right to not implement >> it). I even read somewhere, perhaps on this list, about a vendor that rejected >> any bug report against a SHOULD. Conditional MUST, in my opinion, does not have >> this problem. > > But conditional MUST has other problems, namely that you have to enumerate the > exceptions for the MUST, and that's not always practical. > No, you just have to list the known cases. Here's an example of a SHOULD that creates a lot of problems. This is from RFC 1889 (RFC 3550 has a slightly better statement, but the damage was done by the time it was published): "Functions 1-3 [i.e. RTCP feedback, RTCP CNAME and RTCP rate limit] are mandatory when RTP is used in the IP multicast environment, and are recommended for all environments." If I remember correctly the reason was that it is not always possible for the receiver to send back the RR packets, for example on satellite links. But VoIP implementations more or less all decided to not implement RTCP using this statement (feedback is very important even on unicast RTP for congestion control). A conditional MUST could have been written this way: "Functions 1-3 are mandatory for all environments that permit a channel back to the sender." - -- Marc Petit-Huguenin Personal email: marc@xxxxxxxxxxxxxxxxxx Professional email: petithug@xxxxxxx Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5dKFgACgkQ9RoMZyVa61d7ZACgn3U/lqN14YWy3TPGArqtN7AO yrwAmwcccGVHNOm0AsbeUIdj/0MxFG1p =91cE -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf