On 02/27/2006 10:58, Hallam-Baker, Phillip wrote: > > [mailto:[EMAIL PROTECTED] 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
