On 10/13/2010 6:36 PM, SM wrote: > At 13:03 13-10-10, Barry Leiba wrote: > >> To avoid second-guessing in a security context, and because >> DomainKeys is an obsolete protocol, DKIM verifiers MUST >> interpret this situation in DKIM terms, matching only >> empty "i=" values. >> > Changing the g= definition takes advancement of the base DKIM > protocol off the table.
Saying that a DKIM verifier must use DKIM semantics for a particular situation is not a change to the protocol. Another potential option is to remove g= entirely: RFC 2026 section 4.1.2: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. ... A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. section 6.2: A specification may be (indeed, is likely to be) revised as it advances through the standards track. At each stage, the IESG shall determine the scope and significance of the revision to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions are expected, but a significant revision may require that the specification accumulate more experience at its current maturity level before progressing. Finally, if the specification has been changed very significantly, the IESG may recommend that the revision be treated as a new document, re- entering the standards track at the beginning. These clauses have usually been held to mean that removing troublesome options does not mean that a PS recycle is required. Tony Hansen _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html