maybe Eric could still do a s/LWSP/[FWS]/g in AUTH48
eliminating LWSP everywhere (?)
Absolutely not. This is a technical change.
It's IMO more in the direction of an erratum. Nobody
could claim with a straight face that they need lines
consisting only of white space for their folding magic.
Even if true, it is still a technical change. dkim-base is a standard
*today*, even before the RFC is issued. Implementations of *the
standard* have already been deployed. You are proposing a change to the
way an implementation needs to act.
This argument has been brought up at nearly every change made. If
pre-standard compatibility is so important then DK signatures would
still be valid. They aren't. So would IIM signatures. They aren't. So
would early DKIM signatures. They aren't.
Current DKIM deployment is infinitesimal compared to DK, so I find the
"already deployed" argument bogus in the extreme.
Besides, as I understand it, most implementations will serendipitously
work anyway as the presence of WS in Selectors is uncommon.
> If we tried that, the document would have to go through
IESG review again.
I thought that this depends on the AD or the shepherd (?)
It is up to the RFC Editor.
Of course I don't want a new IESG review or other delays.
Why not? What's the rush? DKIM has been alive for at least a year and DK
has been alive for at least two years? I don't understand why a small
delay to get something right is considered so negatively by a technical
standards group.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html