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