ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: LWSP in base64-encoded public key TXT RR

2007-03-07 21:12:54
 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