Re: [rfc-i] archiving outlinks in RFCs

Alexis Rossi <> Thu, 27 April 2023 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16011C1519AB for <>; Thu, 27 Apr 2023 12:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RcEMgxY7elYH; Thu, 27 Apr 2023 12:29:17 -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 CC90DC151540; Thu, 27 Apr 2023 12:29:17 -0700 (PDT)
From: Alexis Rossi <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_64740841-67C3-474A-A5B6-6FAD554FAD97"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Date: Thu, 27 Apr 2023 12:29:16 -0700
In-Reply-To: <>
To: "\"Martin J. Dürst\"" <>
References: <> <>
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: Thu, 27 Apr 2023 19:29:22 -0000

Yes, I think it makes sense to understand for a given domain which URLs are meant to be durable over a long period of time. e.g. On I think we would probably agree that we always want a URL that looks like <> to point to the official RFC and that we intend for that to never change. Going through that exercise and documenting it for the other domains that we collectively control would probably be useful (I intend to do that for as part of the archival policy draft that i’m pulling together). And of course, we would want to encourage people to use those durable URLs in their references where possible.


> On Apr 25, 2023, at 10:27 PM, Martin J. Dürst <> wrote:
> It's interesting that the broken link found first is a link to one of "our own" documents. This would suggest that (besides some of the proposals that Alexis and others brought up about tweaking/fixing RFCs) we should make sure that the relevant sites such as have policies and procedures in place (and follow them) to make sure they keep their content stable.
> Regards,   Martin.
> On 2023-04-26 03:50, Alexis Rossi wrote:
>> Hi all,
>> I wanted to let the community know about something I’ve been working on. As you might know, one of my previous jobs was running the Wayback Machine, so when I started working with with this collection of RFCs one of my first thoughts was, “I wonder how many broken links are in these RFCs from the past few decades?”
>> In general, the average lifespan of a URL before the content changes or disappears is on the order of 100 days. Fortunately for us, the links used in RFC references seem to be much more stable than that. For instance, so far I’ve only found one broken link in an RFC from the past 6 months [1].
>> [1] RFC9311 published in September 2022, in Section 11 (Informative References) this link is 404: <>[2] <>