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
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim