Charles Lindsey wrote:
But that is fixing the WRONG problem.
Probably my fault, because I found a second problem (LWSP in general)
while talking about the first problem (FWS in DNS TXT records). The
OP actually meant [FWS] (not only the worse LWSP) in DNS TXT records,
and Eric's proposal fixed that.
For my LWSP vs. [FWS] proposal I said that it's "in the direction of
an erratum", because I also only considered the DNS TXT records.
But now you found that LWSP is really used in a header field, and as
you say that violates a MUST NOT in 2822. That definitely _is_ an
erratum, and it has to be fixed a.s.a.p. by replacing LWSP by [FWS].
Error as in "wrong", not error as in "editorial preference", or error
as in "technical change needing a new IESG review." It has to be
fixed and it doesn't need a new review - unless persons claiming that
it needs a new IESG review produce the 2822bis supporting this claim.
A minimal fix would be a "MUST NOT generate" in prose reflecting the
"MUST accept <obs-FWS>" in 2822.
Therefore, our Base document is *inconsistent* with RFC 2822, and
therefore this misfeature is most certainly a BUG.
ACK. We have the advantage of some years of discussions in USEFOR
about related 2822 side effects... :-) And we certainly made sure
to kill all header lines containing only of trailing white space.
It would completely garble a "resent" email if it's edited with a
text editor removing trailing white space: The mail header with a
<some><CRLF>1*<WSP><CRLF>1*<WSP><thing> would then result in
<some><CRLF><CRLF>1*<WSP><thing>, with the <thing> as start of the
body. Unacceptable.
I cannot imagine that the IETF procedures prohibit the fixing of
what are clear bugs at any time up to the point of publication of
the RFC (and, after that, an RFC-erratum is the proper mechanism).
+1
In this case, the proper fix would appear to be
base64string = bvalchar 0*( [ FWS ] bvalchar ) 0*2( [FWS] "=" )
bvalchar = ALPHA / DIGIT / "+" / "/"
+1. Removing discussions of "LWSP" in the prose, or replacing them
by "[FWS]" or "optional FWS". DKIM like USEFOR already has a clean
no nonsense version of <FWS>, unlike RFC 2822 with its <obs-FWS>.
And if you look closer, <tag-value> itself, currently defined as
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
exhibits the same problem, and should have been
tag-value = [ tval 0*( FWS tval ) ]
ACK. Well, nobody promised that AUTH48 is always boring. And there
are clear MUST NOTs in 2822 justifying these fixes. Keeping it as is
is no option, a violation of 2822 in Sender ID was already appealed
(succesfully).
Whether the revised <base64string> is too restrictive for selector
TXT records is another matter, though I doubt we really want them
to contain long sequences of *(CRLF WSP).
+1
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html