>A little defensive, aren't we. I think exasperated might be more accurate.
>Are you telling me that the digest and canonicalization components >would not be separated out in your implementation where they can be >tested as separate units and be unaware of any DKIM-isms? Of course not. Back when I was writing Fortran compilers, I had no trouble doing unit testing even though there weren't separate standards for IF statements and DO loops. Standards don't define the way you implement and test your software; they define the way that implementations interact with each other. It makes plenty of sense to experiment with canonicalization algorithms. Then we pick one that works well and write that into the spec. >Are you telling me you do not see any other applications besides DKIM >utilizing header-based signatures? If someone wants to reuse bits of the DKIM spec in some other application, he can always do so. People piggyback specs on each other all the time. >The name "DKIM" implies a particular usage model for header-based >signatures. Contrary to what you may believe, there is definite >interest by those participating in these discussions to extend DKIM, >as it is currently defined. There is no surer way to destroy a standardization effort than to start abstracting and generalizing the design. (If you received this message via an X.400 mail system running on an OSI network written in Algol68, feel free to ignore this paragraph.) You might want to drop by the web site of the Open Group, which spends much of its time defining profiles for over-general systems to turn off options and get down to something small enough that different implementations have a chance of interoperating. The signature and key formats each are designed to provide backward compatibility in future extended versions. That's all it makes sense to design in now. R's, John _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
