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
<roland(_at_)rolandturner(_dot_)com>
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