On 02/27/2006 10:58, Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott
Kitterman
Might it be useful to break the exact crypto algorithm out
into a separate (very short) RFC so that it can be revised as
necessary? Something like:
A validator MUST support all crypto algorithms listed as
not deprecated in RFC ZZZZ or it's successors, initially
{SHA-1, SHA-256}.
Good intention, bad idea. Essentially you have created a future
dependency so the requirements for implementing DKIM now change over
time. It is now impossible to interpret the statement 'complies with RFC
XXXX' without knowing when the claim was made.
Personally I would imagine that one would cite DKIM implementation compliant
with RFCs XXXX and ZZZZ or XXXX and ZZZZ+1. It's no different from that
perspective than compliant with DKIM and you have to figure out if it's XXXX
or XXXX+1.
I imagine the alternative is to open the entire spec for revision, slow down
the process, and risk incompatible over-engineering sneaking in. If no one
thinks it's a good idea, then we can just cross that bridge when we come to
it.
Scott Kitterman
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html