In numerous places the development and deployment guide makes use of RFC 2119 language that is vague in its meaning. For example:
In particular, great care MUST be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes. This actually tells the implementor very little. My recommendation would be to change to "must". Similarly: As with the signing process, choice of service venues for verification and assessment -- such as filtering or presentation to the recipient user -- depend on trade-offs for flexibility, control, and operational ease. An added concern is that the linkage between verification and assessment entails essential trust: the assessment module MUST have a strong basis for believing that the verification information is correct. Without giving an inkling as to what a strong basis is, the MUST should be a "must". In this case, it seems to me that we're also in the department of obviousness. And above that text: In particular, verifiers SHOULD NOT automatically assume that an email message that does not contain a signature, or that contains a signature that does not verify, is forged. Verifiers should treat a signature that fails to verify the same as if no signature were present. Here we have inconsistent use of "SHOULD NOT" and "should". In Section 3.2.3 we see the following: In order for an assessment module to trust the information it receives about verification (e.g., Authentication-Results headers), it MUST eliminate verification information originating from outside the ADMD in which the assessment mechanism operates. What is "it"? Pronoun failure. Also, how is this boundary drawn, and are we drawing text from Murrary's draft or should this section merely reference that document? Finally, overall I believe that BCPs should not contain normative language relative to how to implement. That information belongs in a standard. Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
