Re: [rfc-i] archiving outlinks in RFCs

Paul Kyzivat <paul.kyzivat@comcast.net> Tue, 25 April 2023 19:36 UTC

Return-Path: <paul.kyzivat@comcast.net>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC51C15171F for <rfc-interest@ietfa.amsl.com>; Tue, 25 Apr 2023 12:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgpIOADL8dWj for <rfc-interest@ietfa.amsl.com>; Tue, 25 Apr 2023 12:36:22 -0700 (PDT)
Received: from resdmta-c1p-023852.sys.comcast.net (resdmta-c1p-023852.sys.comcast.net [96.102.19.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C293BC1524DB for <rfc-interest@rfc-editor.org>; Tue, 25 Apr 2023 12:36:14 -0700 (PDT)
Received: from resomta-c1p-023278.sys.comcast.net ([96.102.18.240]) by resdmta-c1p-023852.sys.comcast.net with ESMTP id rNpspm3SLCN6arOQVp7LMN; Tue, 25 Apr 2023 19:34:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1682451251; bh=BGR4ner67LJ0qGxOOZpXsJ4BYjrYZKZb1VcxlGokKcc=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=36m/Dsf03F+zAJB/AFgP1Qcxk0+CxUyjR8OdOi3wJzz32eNLGgGkLp3nwhTiHrvtX 3GkLEhGN+T8Zh7/OrP2EGSU2/1AIFoin8lVTh2mki54i5pTPe+umg3cFf4LOS6Z9Sr 1eynqlLX/3qm0PQ5+lwhGcYCAHBxKMhsxDbeH4gV7ic8hIO+pDmqFaNlGbZFAVKusd XFIYLSE3BzsBYfQ76551hv5jK4VFfx/Dt2zOVstAVTYOfIMXzTb5+VMRkEzmMWgQpR mqBsxM7wm8Rc/ylJh030XtucJXsviIYLyylSa1lllSTQMk/ynlwmuiesm2HryM2vt2 cA4rRHvACezYA==
Received: from [192.168.1.52] ([73.143.251.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-023278.sys.comcast.net with ESMTPA id rOQ7pDAwWTRAerOQ8pcNY7; Tue, 25 Apr 2023 19:33:49 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvhedrfeduvddgudeflecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecufghrlhcuvffnffculddutddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgruhhlucfmhiiiihhvrghtuceophgruhhlrdhkhiiiihhvrghtsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekkedtudfhhfdvfeffffegfeelffetueeitdegleeuhfejvdehfeeltdelteetgeenucffohhmrghinheprghrtghhihhvvgdqihhtrdhorhhgpdhpvghrmhgrrdgttgdprhhftgdqvgguihhtohhrrdhorhhgpdhirggsrdhorhhgpdhirhhtfhdrohhrghdpihgvthhfrdhorhhgnecukfhppeejfedrudegfedrvdehuddruddugeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrhedvngdpihhnvghtpeejfedrudegfedrvdehuddruddugedpmhgrihhlfhhrohhmpehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvthdpnhgspghrtghpthhtohepuddprhgtphhtthhopehrfhgtqdhinhhtvghrvghsthesrhhftgdqvgguihhtohhrrdhorhhg
X-Xfinity-VMeta: sc=10.00;st=legit
Message-ID: <30c30c2f-4e96-560a-73dd-a51ba8d04714@comcast.net>
Date: Tue, 25 Apr 2023 15:33:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: rfc-interest@rfc-editor.org
References: <E024D9AC-2B92-4720-9713-519592D2362B@rfc-editor.org>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
In-Reply-To: <E024D9AC-2B92-4720-9713-519592D2362B@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/NYA6wfTEZ_8adk5PwV3h6QYEEHA>
Subject: Re: [rfc-i] archiving outlinks in RFCs
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2023 19:36:26 -0000

Alexis,

This is interesting. Would it make sense to adjust our RFC format so 
that links are directly to an archival site, or so that each reference 
has two links, one to an original document and the other to an archival 
version? Or that all the RFCs are periodically tested and automatically 
switched to an archived target if the original goes stale?

	Thanks,
	Paul

On 4/25/23 2:50 PM, 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].
> 
> Even though we favor these more stable URLs, some of them will 
> eventually change or go 404 and having archival documents with link rot 
> is something we can take steps to avoid in the future.
> 
> The first thing I wanted to do was just make sure we were archiving 
> these outlinks somewhere. This won’t fix a broken link in the RFC, but 
> at least the resource can be saved elsewhere for someone curious enough 
> to go look (and potentially we could fix links in some version of the 
> RFC in future).
> 
> The main services that are well qualified for this purpose are 
> Archive-It.org <http://Archive-It.org> (run by the Internet Archive) and 
> Perma.cc <http://Perma.cc> (run by Harvard Law School Library). I chose 
> Archive-It, and when I approached them they offered us an account [2] 
> with enough free data storage for our needs. Yay for non-profits 
> supporting each other!
> 
> So far I have used Archive-It to:
> 
>   *
>     Archive rfc-editor.org <http://rfc-editor.org>, iab.org
>     <http://iab.org>, irtf.org <http://irtf.org>, and ietf.org
>     <http://ietf.org> (minus datatracker and the mail archive)
>       o
>         There are lots of references to these sites in RFCs, but I also
>         wanted to preserve the contents for their own sake. I plan to
>         revisit these sites once per year.
>       o
>         I am avoiding datatracker (except for outlinks from RFCs)
>         because of concern about the extra traffic causing problems for
>         the team that maintains the site.
>       o
>         I have not concentrated on archiving the mail archive yet,
>         though I know some of it has been saved incidentally. 
>   *
>     Archive outlinks from RFCs
>       o
>         About once per quarter I’ll grab the outlinks from newly
>         published RFCs and get them crawled.
>       o
>         I am also going backwards through the entire series - I’ve
>         started with the most recent RFCs (links are more likely to
>         still be live) and am working my way back in time. 
> 
> 
> There may be more room for improvements here, for example including 
> archived links in RFCs from the start w here appropriate, or potentially 
> defining a way for links to be self-healing in published RFCs.
> 
> Please let me know if you have ideas or feedback on this.
> 
> Thanks,
> Alexis
> 
> 
> [1] RFC9311 published in September 2022, in Section 11 (Informative 
> References) this link is 404: 
> https://www.ietf.org/how/meetings/98/bits-n-bites/ 
> <https://www.ietf.org/how/meetings/98/bits-n-bites/>
> [2] https://archive-it.org/organizations/2540 
> <https://archive-it.org/organizations/2540>
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest