Subject: RE: [ietf-dkim] Core algorithm support/use, draft text v2

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Feb 2006 07:58:14 -0800

> [mailto:[email-masked]] 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.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2006 21:21:01 -0500

> 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