I left off a sentence in Point 7.
Tony Hansen wrote:
Michael Thomas wrote:
Dave Crocker wrote:
: there are things in the
real world which will cause more message signature to fail if we
make this change. You're not in favor of that are you?
Two lines of argument. You were invoking the 'installed base'
argument and I was noting that it is not valid to use that, at this
stage, for this type of issue.
No I was not. My code up until very recently was making the same
mistake. What is strongly implied in the current draft offers
*superior* robustness in the real world. That is, it is immune to
additions *and* deletions of trailing CRLF's. That is not an appeal
to installed base, it's an appeal to a more robust spec. As it
happens, the spec merely needs to make more obvious what the
normative text already says and we will have an improved spec.
Michael, I don't see where you see the "new and improved algorithm" is
more robust in the face of deleted CRLFs than the proposed fix to the
dkim-base text?
Point 1:
The original dkim-allman-base and dkim-ietf-base text called for
trailing CRLFs to be deleted.
Point 2:
The change to the text introduced in base-04 called for a
CRLF to be added to a message that doesn't have a CRLF on its
last line of text. In the process, it changed what happens when
there is a message that only has trailing CRLFs. That base-04
included a change to the existing behavior for handling such
messages was missed by many people, myself included, until now.
Point 3:
The discussions that led to the change in base-04 did not
include any intent to change the default behavior when there
are only CRLFs in the message body. Those discussions were only
about what should happen with a message whose last line didn't
end in CRLF. (Such messages are only possible when you are using
a binary MIME content-transfer-encoding and a binary transport
protocol.)
Point 4:
The proposed text changes restore the behavior for when you have
blank messages, as well as maintaining the change in semantics
necessary to handle messages whose last line doesn't end in
CRLF. (This includes the messages that have lost a trailing CRLF
in transport.)
Point 5:
No matter which option we choose, someone's going to have to
change their implementation.
Point 6:
My preference is to use the algorithm that's compatible with
what was in dkim-allman-base-* and dkim-ietf-base-00 thru 03,
while maintaining the change to handle messages with no final
CRLF.
Point 7:
Another way of expressing this algorithm that people may find
easier to understand is:
"If the last line of the message does not end with CRLF, CRLF is
added. Then, CRLF 0*CRLF is reduced to a single CRLF."
"If the body only consists of a CRLF after this reduction, that
too is removed."
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html