Subject: [rfc-i] Updates and errata

From: Miek Gieben <[email-masked]>
Date: Fri, 7 May 2021 14:25:24 +0200

Hi all,

A recent bug report (https://github.com/miekg/dns/issues/1261) was solved by looking at
the errata and finding one that solved that particular issue. Which made me wonder, can we
makes these erratas (and probably updates by other RFCs) standout better in the text (that
they actually apply to)?

I can see many solutions, but also many hurdles. Maybe this has already been discussed
within this community?

/Miek

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 May 2021 14:35:14 +0200

You are aware of

https://www.rfc-editor.org/rfc/inline-errata/rfc8078.html

?

It is amazing that this is so hidden (e.g., I can’t find a link from the errata page).

Best find it from https://www.rfc-editor.org/info/rfc8078
(It’s the "HTML with checkmark” button.)

Grüße, Carsten

> On 2021-05-07, at 14:25, Miek Gieben <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 May 2021 09:33:47 +1200

A good reason to always cite https://www.rfc-editor.org/info/rfcXXXX instead of the previous favourite at tools.ietf.org.

Regards
   Brian

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 7 May 2021 17:42:59 -0400

On Fri, May 7, 2021 at 5:34 PM Brian E Carpenter <
[email-masked]> wrote:

> A good reason to always cite https://www.rfc-editor.org/info/rfcXXXX
> instead of the previous favourite at tools.ietf.org.
>
>
Sure but the default move is to type "RFC8078" and the fist thing that
comes up is tools.ietf.org

Also, when I go to the rfc-editor site I have to click twice, and with my
short attention span, well
I'm onto something else

I mentioned this to Mr Daley a bit ago that I do a lot of searching from
inside GitHub for several reasons.
I was wondering if we could put the RFC text into an Org so stuff shows up
there.

But I convinced myself nobody else thinks like this.

tim

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 May 2021 01:36:57 +0200

Well, this was discussed previously, and the result was that there should be a page for each IETF-related document of the form

doc.ietf.org/rfc8949
doc.ietf.org/draft-ietf-core-coral

which is an HTML page that starts with a short bar of metadata and a few links, followed by the HTML text of the document.

This needs to be done right, so it does require some thinking.
There is no need to overthink this, though, and I wish we could do something like that in less than half a decade.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 May 2021 14:15:01 +1200

> which is an HTML page that starts with a short bar of metadata and a few links, followed by the HTML text of the document.

That's essentially an enhancement request for pages like:
https://datatracker.ietf.org/doc/rfc8989/
to also include what can be found at pages like:
https://www.rfc-editor.org/info/rfc8989/

(Quick fix: add a pointer to the rfc-editor URL to the datatracker page.)
 
> There is no need to overthink this, though, and I wish we could do something like that in less than half a decade.

Right, but that's an IETF tools issue, not an RFC Editor issue. 

     Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 May 2021 06:22:44 +0200

> Right, but that's an IETF tools issue, not an RFC Editor issue. 

Yes, but the RFC editor needs to be happy with what is done:
In the end, we want RFCs to link to stop linking to other places and link to this place for IETF-related documents.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 May 2021 09:36:23 -0400

> short attention span, well

I mentioned this to Robert Sparks, and he agreed, that we need to fix the
robots.txt on tools.ietf.org to depreference it.

I'm not certain that we need doc.ietf.org; I'd rather see more links to
/info/rfcXXXX.  I do see that we need the RFC text visible on whatever page
there is, because that's where the search term targets are.

--
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: Julian Reschke <[email-masked]>
Date: Sun, 9 May 2021 08:44:43 +0200

Am 08.05.2021 um 15:36 schrieb Michael Richardson:
> ...

Be careful with that, because that guarantee that what we want ranks first.

Other suggestions would be:

- add "canonical" link to tools.ietf.org resources, or even let them
redirect

- avoid publishing anything new in IETF space that links to tools.ietf.org

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 9 May 2021 12:28:14 +0200

Am 09.05.2021 um 08:44 schrieb Julian Reschke:
>>      >> A good reason to always cite
>> https://www.rfc-editor.org/info/rfcXXXX
>>      >> instead of the previous favourite at tools.ietf.org.
>>      >>
>>      >>
>>      > Sure but the default move is to type "RFC8078" and the fist
>> thing that
>>      > comes up is tools.ietf.org
>>
>>      > Also, when I go to the rfc-editor site I have to click twice,
>> and with my
>>      > short attention span, well
>>      > I'm onto something else
>>

...because that does not guarantee...

Best regards, Julian

---

From: Miek Gieben <[email-masked]>
Date: Mon, 10 May 2021 09:45:59 +0200

[ Quoting <[email-masked]> in "Re: [rfc-i] Updates and errata..." ]
>A good reason to always cite https://www.rfc-editor.org/info/rfcXXXX instead of the previous favourite at tools.ietf.org.

But even there it is still a bit obscured. What's stopping us from making errata (and
updates) showing up in actual section(s) they refer to? Like github PR comments or some
such?

/Miek

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 May 2021 10:37:02 +0200

> updates) showing up in actual section(s) they refer to? Like github PR

Inlining the full errata is not trivial; it works best if there's only
minor surgery in the text. Also, the system that was deployed last year
only works with plain text RFCs.

For my private use, I'm scraping the RFC Errata pages for those RFCs I'm
interested in, and generate a normalized XML format from that (see
<https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc-editor.errata>).

I then use that to annotate the HTML generated by rfc2629.xslt. Example
output: <https://greenbytes.de/tech/webdav/rfc7991.html#cdata.and.escaping>.

I'm updating these more or less daily, so every status change becomes
visibile soon, and also gives motivation to make sure that there are no
unprocessed errata.

I understand that there are people who would like to change the errata
process completely, and that might indeed be good. In the meantime, it
would be really really helpful if the RFC Editor pubished errata
information on an per-RFC basis in a format that is better prosseable
than the HTML we currently have.

Best regards, Julian

---

From: Miek Gieben <[email-masked]>
Date: Mon, 10 May 2021 10:58:27 +0200

[ Quoting <[email-masked]> in "Re: [rfc-i] Updates and errata..." ]
>only works with plain text RFCs.

Agreed. I was thinking of having an <errata> or <update> tag, but this means
the original XML must be amended...

>output: <https://greenbytes.de/tech/webdav/rfc7991.html#cdata.and.escaping>.

yes! That looks very close to what I had in mind.

/Miek

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2021 16:38:49 +0200

On 2021-05-10, at 10:58, Miek Gieben <[email-masked]> wrote:
> the original XML must be amended…

Since the original XML is immutable, it is trivial to generate an XPath that points right into the site of the erratum.  We could store these with verified errata, which makes it near-trivial to associate the errata with that site, once there is a common place where the verified errata live.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 May 2021 16:49:18 +0200

> Since the original XML is immutable, it is trivial to generate an XPath that points right into the site of the erratum.  We could store these with verified errata, which makes it near-trivial to as…

...or we can use the "pn" attribute value, which should give us the same
kind of stability and would work directly with derived formats such as
HTML and PDF.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2021 17:08:27 +0200

> kind of stability and would work directly with derived formats such as

(Which would be equivalent to a nice and simple XPath, which is what I essentially meant.)

Grüße, Carsten

---

From: Miek Gieben <[email-masked]>
Date: Mon, 10 May 2021 17:11:59 +0200

>kind of stability and would work directly with derived formats such as

these are excellent suggestions, and pretty much show this can be done today(-ish)

Is there a process to actually make this happen?

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2021 17:39:24 +0200

> Is there a process to actually make this happen?

That would need to tie in with the RFC editor errata report process.
Which will change over time.
Maybe we should set up some mini-prototype (of process, likely not yet of software) with a couple of verified errata.
We could then ask IESG to start playing with the mini-prototype when verifying further errata.

Grüße, Carsten