Re: [rfc-i] archiving outlinks in RFCs

Alexis Rossi <> Mon, 01 May 2023 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67C0FC151993 for <>; Mon, 1 May 2023 12:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LCb_Rt6mNWpd; Mon, 1 May 2023 12:27:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EDF8EC151520; Mon, 1 May 2023 12:27:52 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Alexis Rossi <>
In-Reply-To: <>
Date: Mon, 01 May 2023 12:27:51 -0700
Cc: Michael Richardson <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <796.1682529129@localhost> <> <> <31200.1682702389@localhost> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [rfc-i] archiving outlinks in RFCs
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 May 2023 19:27:53 -0000

I’m definitely hearing a desire for humans to be involved in the process. 

The main down side, if I understand correctly, of using the errata system as the mechanism is that only one version of the RFC will have archived links when something breaks (the html with inline errata). 

If the authors are involved in verifying the correct archival link, it seems like it’s still a human/community based process to put the archived link directly into the reference right from the start.

I think it would be ideal for even the text versions going forward to have both an original link and an archived link for each reference (when it’s a link, and where possible/appropriate - up to the authors). The text version might not have anything fancy that warns you that the original link is dead, but if you follow it and it 404s there will be an archived link right there for you already. Very low barrier to access the information.

That doesn’t fix broken links going backwards, of course. Maybe that’s the best use of the errata workflow? 

> On Apr 28, 2023, at 1:18 PM, Brian E Carpenter <> wrote:
> On 29-Apr-23 05:19, Michael Richardson wrote:
>> Alexis Rossi <> wrote:
>>     > It seems like using the errata system would maybe be a more haphazard
>>     > method of fixing broken links over time, since it relies on humans to
>>     > notice the original link is dead, report that as an errata, and then
>>     > another human to check and approve it. Unless the proposal is to have a
>>     > bot that files errata when links die (and then there’s just one human
>>     > step to approve)?
>> I think that this says more about how antique our errata management system
>> is, than anything about the durability of the links :-)
> Correct, but I think Ted's idea was to use the errata mechanism to notify the
> stream and ask for approval/disapproval, not to say that the broken link
> is an erratum as such. And yes, of course all of this should be robotic,
> including the initial archiving at the time of RFC publication.
> Yes to those who say that the RFC with approved errata applied should be
> the go-to version. The "text will never change" version needs to be kept
> for the lawyers, but normal RFC users should see the fixed version.
>     Brian