----- Original Message -----
From: "Eric Allman" <[EMAIL PROTECTED]>
> Great! Thanks for the pointer. So it's not a problem with DATA.
>
> Do we want to worry about the BDAT case? My suggestion would work
> for that (but break your implementation).
>
> It also occurs to me that there is an assumption in DKIM (and
> probably a lot of other specs) that the mail body is text. It
> doesn't have to be if you use BODY=BINARYMIME [RFC3030]. Is this
> worth considering? It seems like it would either require redefining
> simple body canonicalization if you have a BINARYMIME message, or
> defining a new canonicalization ("binary"?) that allows absolutely no
> changes. Of course, a new canonicalization can be added later.
>
> eric
This canonicalization concept seems to be a big PITA. We need a consistent
and working concept out of the gate. Is it not possible to get a single
straight forward method now?
Sure, new methods can be added in the future, but I don't have to tell you
about legacy and version control issues. Just consider that we already have
few active DKIM participants who are so dependent on alpha-ware designs and
are highly resistance to final design changes. :-)
I just seem to think that if we can't resolve this now, I doubt it will be
resolved later.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
