Re: [rfc-i] archiving outlinks in RFCs

Jay Daley <> Fri, 28 April 2023 08:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89FD4C151B08 for <>; Fri, 28 Apr 2023 01:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t-ZXjPv5fQex for <>; Fri, 28 Apr 2023 01:29:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 88FF3C15154D for <>; Fri, 28 Apr 2023 01:29:10 -0700 (PDT)
Received: by with SMTP id 5b1f17b1804b1-3f19b9d5358so72998415e9.1 for <>; Fri, 28 Apr 2023 01:29:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682670549; x=1685262549; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=Fy5sxd4um0zS3d6khq1bur+wr6Jpc+IXR0DpIgK1Nrg=; b=CFV7GSV6GeXebWNzuteOoRPPG6DeH4ygSoCmEmRNpHOGRckgBDXCzQD1G1JAWLfjyX CK+4I8XHX4azAnxqWFhU2rdlAVIZt+xZ9PQEdqvVs3j13BSQovkwHQCTZAwCymvYvL8x I69zFE0Kh0EJiWGQWzEM0jyaLXt1TFqZeC0exbGK8xZx9WdJc74jzXxQ18TDzUK6neqm In2l8lvwEJz1AmgQY4i3HKA9lCW2YCbEAniKDjr+rpu4RE0+od8gNp7rafARSF7E7yM9 iTGioM76MH6aRi7VTDZEGBBB9e07v8AuTLek+QdnnxNTHTRfrQG6r0OHrxyJ0EQu/8NK /lxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682670549; x=1685262549; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Fy5sxd4um0zS3d6khq1bur+wr6Jpc+IXR0DpIgK1Nrg=; b=HzTLoI4/RxmyW6Y4CUQqjnPxZHjqI6sR3I96iVtFT++EoelbfmYAFOHpzmt7Pgh0cX Gr1YIXT66suDypJuVC+Q7fYXW0dKdt02GsDF51sbxSZKwM6RbsFhKGeutAvUFpbadIsu W5gegCmxv0B3Y+vbuwmYtzseN+59GYYQxlOdRZH7F4FkILUlZ9/dcZ4b2Re0v7tPKaJ5 LzIdlBXLuOtzuj05aygzplYQDL1TL7LVhyDbawJtsvXEPuFCbmjREgztdKytUAp+l7FS GqWbWVi/VJDFDfkmcYEeB0rDn6Q9VVlsgQTymc4P/FUi2Y+MyxxzfCBof0yAAnE3pbCC Hiaw==
X-Gm-Message-State: AC+VfDyzQz47lcLmtYvO9aSRVqHrqb+1c4UOnwh6GGKdhFh4Nlemi6em LO21W07eAHk2wqiieSMTvTieKQ==
X-Google-Smtp-Source: ACHHUZ7+He5jRM5gZq/vdA1voRa9aE6ReXLCHM+yC133Hu2xnNQBJc8Uy/0l6XnVnZ5FYqaSceW20g==
X-Received: by 2002:adf:fe4d:0:b0:2f8:1ed9:f0f8 with SMTP id m13-20020adffe4d000000b002f81ed9f0f8mr3322241wrs.61.1682670548616; Fri, 28 Apr 2023 01:29:08 -0700 (PDT)
Received: from ( []) by with ESMTPSA id e5-20020a5d5305000000b002cf1c435afcsm20555701wrv.11.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2023 01:29:08 -0700 (PDT)
From: Jay Daley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_531B8576-E720-4E95-96DC-71728614D811"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Date: Fri, 28 Apr 2023 09:28:55 +0100
In-Reply-To: <>
Cc: Ted Hardie <>, RFC Interest <>
To: Brian Carpenter <>
References: <> <> <> <> <> <> <> <796.1682529129@localhost> <> <> <> <>
X-Mailer: Apple Mail (2.3731.500.231)
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: Fri, 28 Apr 2023 08:29:14 -0000

> On 28 Apr 2023, at 09:22, Brian Carpenter <> wrote:
> +1 to Ted except that sometimes errata are simply ignored for literally years. That's why I suggest a timeout after which the redirect is atomatically approved.

The more important point is that errata are not applied to RFCs as RFCs are unchanging.  Using solely the errata mechanism would mean someone you encountered a broken link, having to explicitly select the "show with errata" feature to find the new link.

So while the errata mechanism is close to what we want, in my view it’s not enough.  (There’s also a principle debate on whether or not a dead link is actually an erratum).

I don’t what stopping us from creating a new process specifically for broken links

- bot checks links and finds broken one, auto-generates a report
- report is looked at by appropriate person/body who decide on replacement link target (if there is one)
- HTML version of the RFC is updated to point to new target


> (via tiny screen & keyboard)
> Regards,
>         Brian Carpenter
> On Fri, 28 Apr 2023, 20:03 Ted Hardie, < <>> wrote:
>> On Thu, Apr 27, 2023 at 9:10 PM 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)?
>> Yes, sorry that was clear.  Essentially, the steps I propose:
>> On RFC publication, archive the outlink.
>> Run a periodic check on the status of the links in each RFC.
>> When one is determined to be unavailable, file an erratum mechanically
>> The community that would normally determine erratum validity examines the issue and determines the next step, which might be one of:
>> 1) The erratum is approved and lists the archived information as the target for approval on document update 
>> 2) The erratum is approved a different URL is listed as the target for approval on document update (e.g. the ieee.example/standards/08675 replacing ieee.example/standards/8675
>> 3) The erratum is rejected as the error was transient or will be corrected by the origin (where these are sibling SDOs, we generally have a way to reach out to them for this information).
>> The normal erratum process is then used to provide this information to the community (either separately or in-line, depending on the method they choose).
>> The advantage of this approach is that we are using community approved processes in a pretty easily understood way.  We can also use the same process when the link is live but something like a paywall has changed the state of availability.  That's not something we can likely identify mechanically, but we can re-use this set of steps.
>> Sorry that this wasn't clearer before.
>> regards,
>> Ted
>>>> On Apr 27, 2023, at 1:40 AM, Ted Hardie < <>> wrote:
>>>> On Wed, Apr 26, 2023 at 6:12 PM Michael Richardson < <>> wrote:
>>>>> Ted Hardie < <>> wrote:
>>>>>     > I agree with Ekr that this is problematic, but my concern is with external
>>>>>     > links to other standards.  If I replace a link to https://ieee.example/876.1
>>>>>     > to an archive link like
>>>>>     > https://archivesite.example/see?https_ieee_example/876.1_retrieved_the_day_of_publication
>>>>>     > then ieee.example has no chance to use its own redirects or tombstones to
>>>>> It also keeps ieee.example from replacing the link that we were using with a
>>>>> link that goes through a paywall.
>>>>> (Which, btw, DOES HAPPEN regularly)
>>>> I think this would also be grounds for filing an erratum.  But my basic point remains that the erratum process triggers the right thing: discussion among the folks within the IETF who are responsible for the relevant RFC.  There are several different "correct" responses depending on the circumstances, and they are the right folks to make the decision.  We already have a way to indicate that there are errata and/or display them in line.  We can use that here, rather than trying to decide in advance.
>>>> regards,
>>>> Ted
>>>>> --
>>>>> Michael Richardson < <>>   . o O ( IPv6 IøT consulting )
>>>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>> _______________________________________________
>>>> rfc-interest mailing list
>>>> <>
>> _______________________________________________
>> rfc-interest mailing list
>> <>
> _______________________________________________
> rfc-interest mailing list

Jay Daley
IETF Executive Director