OK, so, Stephen:
This should definitely be closed out in some sort of accepted state.
Verified as Editorial is my preference. Editorial because I don't
think it's a technical issue and it won't cause technical difficulties
in implementation. Verified (not HFDU) because I think implementors
might use these examples to test their implementations, and will be
confused when they find examples that don't work (they're likely to
think they made implementation errors).
If you decide to leave it as Technical, then we should definitely go
with HFDU and *not* Verified. The combination of Verified and
Technical implies a real technical error that would cause technically
incorrect implementations.
Barry
On Fri, Feb 10, 2017 at 11:29 AM, Murray S. Kucherawy
<superuser(_at_)gmail(_dot_)com> wrote:
On Tue, Feb 7, 2017 at 10:25 AM, Barry Leiba
<barryleiba(_at_)computer(_dot_)org>
wrote:
Murray, Tony, or someone else: Can you independently check that these
examples need the extra space in order to be verified correctly?
Murray did that for us a decade ago -- it's one of the test cases that
opendkim uses.
Yes, but the point is: did Murray (or anyone) extract the text *from
the published RFC* and use that as input? That is apparently what
Simon did, which resulted in this report.
It looks to me like this was some loss of precision in the transition from
RFC4871 to RFC6376. The former has six spaces, and the latter has five. I
very likely didn't change my test suite in between, or re-test the examples
in RFC6376 before it shipped.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html