In the perfect written technical specification, if you pulled out all the SHOULDs, the protocol still survives. But if a required functionality breaks down, then it wasn't well written. On 8/30/11, Eric Burger <eburger@xxxxxxxxxxxxxxxxxx> wrote: > Can you give an example of where a dangling SHOULD makes sense? Most often > I see something like: > SHOULD implement security > meaning > SHOULD implement security, unless you do not feel like it or are in an > authoritarian regime that bans security > > > On Aug 30, 2011, at 12:11 PM, 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. >> >> Implementors who think that SHOULD gives them a free pass to avoid >> implementing something that's needed to interoperate are misreading 2119. >> But document editors should avoid using SHOULD for cases where failure to >> implement the requirement will result in interoperability failure. >> >> I could see maybe posting an erratum or a brief update to 2119, but I >> think that reopening that document in general is a Very bad Idea. And for >> existing documents that misuse SHOULD, the appropriate thing to do is to >> update those documents or post errata to those documents, rather than try >> to retroactively change the meaning of the keywords in those documents. >> >> Keith >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > -- hls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf