--On January 8, 2007 11:51:13 AM +0000 Charles Lindsey
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> wrote:
On Sun, 07 Jan 2007 18:49:50 -0000, Eric Allman
<eric+dkim(_at_)sendmail(_dot_)org> wrote:
I have (finally) managed to slog my way through all the messages
on this topic. Let me start out by saying that I don't see the
ambiguity in the current text:
If there is no trailing CRLF on the message, a CRLF is
added. It makes no other changes to the message body. In
more formal terms, the "simple" body canonicalization
algorithm converts "0*CRLF" at the end of the body to a
single "CRLF".
...
Indeed there is no ambiguity in that, but that is because you have
only quoted half the text. The full text is:
The "simple" body canonicalization algorithm ignores all empty
lines
at the end of the message body. An empty line is a line of zero
length after removal of the line terminator. If there is no
trailing
CRLF on the message, a CRLF is added. It makes no other
changes to
the message body. In more formal terms, the "simple" body
canonicalization algorithm converts "0*CRLF" at the end of the
body
to a single "CRLF".
Observe carefully that the text some times tells you to consider
the "message", and somtimes the "message body" (which I take to
mean exactly the <body>, if any, defined by RFC 2822).
OK, I'll change the single instance of "message" to "message body".
Consider the example, in DATA format:
Field: foobar<CRLF>.
<CRLF>
<CRLF>
.<CRLF>
The ".<CRLF>" is evidently not a part of either the message or of
the message body. The "message body" consists of "<CRLF>". Let us
apply the sentences of 3.4.3 one by one.
As Hector points out, this is not a valid 2822 message to begin with,
so sending it would be undefined. At that point how it gets
canonicalized is the least of your problems.
I can't come up with a scenario that starts with a valid message that
has the problem you describe. None the less, changing "message" to
"message body" will improve consistency, and it would make
interpretation of this degenerate case consistent.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html