Eric Allman wrote:
 > For the time being I agree with Paul's suggestion: live with it. This is
the sort of thing that can be solved in DKIMbis, which I'm sure will be required before DKIM gets to full standard.


I'll suggest something even stronger:

Strictly speaking, this is not a bug, so "fixing" it is not the issue.

Why is is not a bug? Well, while we might now wish we had specified things a bit differently, the specification in its current form works and it does not impose undue burdens on implementors or operators. So the nature of what is there, that we might wish were different, falls into the realm of preference or taste.

Hence, the way to "fix" the incompatibility being found in the field is to change the implementation, not the specification.

As Paul notes, although documenting this issue might be useful, it is not "erratum". (And, Eric, that is quite different from either of the alternatives you had, in responding to Paul.) The documentation should not declare what was intended, but merely highlight something that exists and that we have some basis for knowing is worth flagging because it appears to be easy to misinterpret.

Stephen's suggested opening text for the note about this strikes me as exactly the right perspective. Here is what is, rather than here is what we wish, or here is a bug in the spec, or any such thing.

A small change from Stephen's text that I would suggest is to not refer to "since the spec was completed or approved" but merely to state a clarification of what is in the spec.

So, wherever this gets documented, it should say something like:

"NOTE: The specification permits folded white space (FWS) in the DKIM DNS TXT record. FWS requires that a <CR><LF> be followed by at least one linear white space (LWSP) character. Implementors and administrators are cautioned to be careful to ensure that the TXT records produced conform to the specification."


Yes, we might later choose to "enhance" the specification, to allow the case that has appeared in the field, but then, we might not.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to