> >The signing and canonicalization process can be specified independent
> >of key management components. The current DKIM draft interleaves
> >all of this throughout, when it does not need to be. A simple
> >restructuring of the document can fix this problem.
> Since you asked for specific responses, I specifically respond that
> attempting to subdivide DKIM into independent subsections is a
> terrible idea. Please drop drop this pernicious proposal now.
I'm afraid I have to agree with this assessment.
> The design point of the DKIM canon process is to come up with
> something that works for DKIM. It most definitely is not to come up
> with some general process that might be useful for some other
> application that someone might think of in the future. Ditto the key
> management. Attempts to generalize designs beyond the applications
> they are intended for inevitably lead to heat death, which is why we
> need to stamp them out now.
Saying that such an outcome is inevitable probably goes too far, but liklihood
of deadlock certainly would go up dramatically.
> If it turns out that there are future applications that can reuse
> parts of DKIM, that would be fine and they are welcome to plagiarize
> whatever we come up with. But we must exclude such considerations
> from the effort at hand in order to have some chance of completing the
> project.
Or alternately, the specification could be revised and broken up later, once
it is clear that there's a need to reuse certain parts.
The MIME experience seems directly relevant here. The original MIME
specification consisted of only two parts. I think the splitup into five parts
was useful (although if I had it to do over there wouldn't be a part five),
but we simply didn't know enough at the time the initial document was
written to have chosen the boundaries properly.
Ned
_______________________________________________
ietf-dkim mailing list
[email protected]
http://mipassoc.org/mailman/listinfo/ietf-dkim
