Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4926)

[Barry Leiba <[e-mail]>]

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
<[e-mail]> wrote:
> On Tue, Feb 7, 2017 at 10:25 AM, Barry Leiba <[e-mail]>
> 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