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
[EMAIL PROTECTED]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
