On Mar 22, 2006, at 11:03 AM, Dave Crocker wrote:
In fact, as I recall at the Cisco DKIM summit, the recommendation for
those wanting to experiment with implementations now was to use
allman-01 as the draft was expected to be in a state of flux and have
a number of further refinements over coming versions. In short,
everyone was expecting that it would change as the WG moved focus
from
threats to base.
Mark,
There is a difference between noting that the IETF specification is
in flux, versus predicting that the IETF will produce a final
specification that breaks the ability to have a signer who uses the
pre-ietf spec be validated by an implementor of the post-ietf draft.
So far, we have not modified DKIM to cause this breakage. The
current proposal will cause this breakage.
We should not break the pre-ietf to post-ietf interoperability
without extremely good cause.
Dave,
It should be noted that by including the hash parameter within the
signature header, this provides the same level of change as that of a
SHA-1 modification. This parameter indicates a new sequence is being
used to develop the hash in addition to a new hash algorithm. While
an older implementation will not be able to understand this
modification, neither will it understand the SHA-256. The newer
implementation, in an effort to remain backward compatible, could key
upon the hash parameter existing or not within the header to know
which sequence of hashing was used. I am not necessarily
recommending this strategy, but it is one that could be use to retain
the same level of breakage as was caused by the SHA change.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html