Subject: [rfc-i] linking to inline-errata

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Oct 2021 16:22:17 -0400

https://www.rfc-editor.org/rfc/inline-errata/rfc7230.html
lacks any of the section header links like:
  https://www.rfc-editor.org/rfc/rfc7230.html#section-4.1

has.  Of course, it also says:
  This is a purely informative rendering of an RFC that includes verified
  errata. This rendering may not be used as a reference.

I guess the lack of any internal anchors is to help me avoid referencing it?

What kind of policy change would be required to allow us to remove the above
warning, and make RFC+errata actually authoritative?  It's not like the
errata don't go through IETF review.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Oct 2021 11:10:15 +1300

Michael,

The rules on normative references are IETF rules.

Regards
   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Oct 2021 15:46:05 -0700

> errata don't go through IETF review.

Hi Michael,

I agree that this disclaimer should be removed. As a practical matter,
verified errata more correctly reflect the intent of the specification than
the erroneous spec does. As a  hypothetical concrete example, consider a
specification which contained a clear error in a code point (e.g., it
listed a value but surrounding context clearly indicated that it was
incorrect and indicated the correct value). We would want people to
reference the corrected code point and not the incorrect one. To get ahead
of one inevitable objection: it's of course true that the errata do not go
through IETF LC, but this kind of change is routinely made in AUTH48 with
only AD signoff. As I recall, this disclaimer was requested by the RSE and
not by the IETF.

Regardless of the fate of the disclaimer, I don't think there's any good
reason you shouldn't be able to link to pieces of the document. The world
is full of non-normative documents which have anchors.

-Ekr

---

From: Julian Reschke <[email-masked]>
Date: Sat, 2 Oct 2021 13:08:05 +0200

Am 02.10.2021 um 00:46 schrieb Eric Rescorla:
> verified errata more correctly reflect the intent of the specification
> than the erroneous spec does. As a  hypothetical concrete example,
> consider a specification which contained a clear error in a code point
> (e.g., it listed a value but surrounding context clearly indicated that
> it was incorrect and indicated the correct value). We would want people
> to reference the corrected code point and not the incorrect one. To get
> ahead of one inevitable objection: it's of course true that the errata
> do not go through IETF LC, but this kind of change is routinely made in
> AUTH48 with only AD signoff. As I recall, this disclaimer was requested
> by the RSE and not by the IETF.
>
> reason you shouldn't be able to link to pieces of the document. The
> world is full of non-normative documents which have anchors.
>
> -Ekr

The *technical* reason for the lack of anchors of course is that the
"errata inlined" version is produced by a different program, which IMHO
does not share any code with "rfcmarkup". I can only speculate about the
"why", but one reason might be that "rfcmarkup" occasionally produces
incorrect hyperlinking (when the heuristics fails). Carsten Bormann has
a proposal how to address this, but AFAIK, that hasn't been acted upon yet.

Another thing we need to consider is how to inline errata into HTML
generated in the V3 world. Here's my take on it (for the same document):

   https://greenbytes.de/tech/webdav/rfc7230.html

(Yes, it only adds markers for errata, and doesn't actually inline them).

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Oct 2021 10:19:32 -0400

> a proposal how to address this, but AFAIK, that hasn't been acted upon

If we are applying patches at the XML level (which I understood we were),
a run through xml2rfc with HTML output would produce the HTML version.

While what we actually have for older RFCs is htmlized text, because the XML
is not authoritative.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 2 Oct 2021 16:37:03 +0200

> a run through xml2rfc with HTML output would produce the HTML version.

No. <https://github.com/ietf-tools/Rfc-Errata> downloads the plain text,
and tries to apply them based on the "OLD"/"NEW" information.

XML versions, even if available, are not used here.

> ...

Best regards, Julian