Dave Crocker wrote:
Sorry, Mike, but that particular line of argument isn't applicable
here.>
Hence, it was pure academic exercise.
Working group specs are subject to semantic change up to the point
of IESG approval. Anyone deploying code based on a spec prior to
that moment is
taking a well-advertised risk.
Huh? I'm saying that changing this is *NOT* academic
Wow. Sorry. Thunderbird got very creative.
That text after the angle bracket was from an entirely unrelated
message and I know I didn't put it there by an accidental cut and
paste. In other words, my note was only the first sentence of the
first paragraph and all of the second paragraph.
: 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.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html