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

[Barry Leiba <[e-mail]>]

Roland, your question is quite appropriate, and thanks for raising it.

At one level, I don't think it matters that much, so we're sort of arguing
minutiae.  But that's something Dave (and John) and I are often wont to do,
so...

My view is that the errata report type is there to alert viewers to what's
most important to note when you're implementing.  Do you need to look at
this to inform your implementation?   If you miss this one, will your
implementation suffer?

I think that's not the case here.  As I see it, the worst that will happen
is that you'll code, you'll test, and maybe you'll try pasting this example
in... and then you'll see a verification failure.  "Huh?", you'll say.  So
you'll check, and then you'll see the (maybe editorial) errata report, and
say, " Ah, that's OK, then," and move on.

Barry

On Tue, Feb 7, 2017 at 5:52 PM Roland Turner <[e-mail]>
wrote:

> On 02/08/2017 02:52 AM, Barry Leiba wrote:
>
> I think there's a difference between an example that includes
>
> "Reply-To" when it should have included "Subject" (that'd be a
> technical error) and an example that includes "Sujbect" when it should
> have included "Subject" (that'd be an editorial error)... even though
> both of those errors might cause the signature not to verify.
>
> I think an incorrect number of space characters is in the latter category.
>
>
> As a passing engineer who doesn't spend that much time spelunking IETF
> processes, a question that appears to be begged here is why the distinction
> matters. This is not immediately clear from any of the Status and Type of
> RFC Errata page <https://www.rfc-editor.org/errata-definitions/>, the How
> to Report Errata page <https://www.rfc-editor.org/how-to-report/>, or the
> FAQ <https://www.rfc-editor.org/faq/>. There is an important distinction
> when categorising changes during the preparation of an RFC (broader
> approval is required for technical changes), but this does not appear to
> apply to errata. Are you able to throw some light on this?
>
> (On the question that Dave has raised:
>
>    - I'd suggest that text which - in addition to being intended for
>    human readers to understand - is intended for copy+paste into the input of
>    an automated tool for interpretation by that tool but which contains typos
>    contains what seems more like a technical than editorial error, even though
>    the technical information being communicated to a human reader is
>    essentially unchanged. This appears consistent with the first of the
>    examples cited on the errata page; in that case anyone writing a validating
>    parser and having it fail on the sample would quickly recognise the
>    reversed order of the tags in the text, but it is nonetheless classified as
>    technical.
>    - I also note that the How to Report Errata page makes specific
>    mention of what to do in ambiguous cases: "Tip: If the type is not clear,
>    select Technical, and add your concern to the Notes."
>
> )
>
>
> - Roland
>

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html