-----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(_at_)petit-huguenin(_dot_)org
Professional email: petithug(_at_)acm(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf