Re: [rfc-i] archiving outlinks in RFCs

Brian E Carpenter <> Fri, 28 April 2023 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C4D3C1DF97B; Fri, 28 Apr 2023 13:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Status: No, score=-7.099 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 wpvBhrabmOaH; Fri, 28 Apr 2023 13:18:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (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 C77EFC1D9FD6; Fri, 28 Apr 2023 13:18:11 -0700 (PDT)
Received: by with SMTP id d2e1a72fcca58-63b5ce4f069so529782b3a.1; Fri, 28 Apr 2023 13:18:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682713091; x=1685305091; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2GMDdmgqP5en66qF86TPJYgmIzrM2TpSxwbh3YtFitk=; b=r0ruaOtqI+Gp0liwMpRVuu1rUVQtMnnc4OjSEx0+nLo2/k+DCZar0bmte2tJO+OsZv gE29ZoKLOAyGcFJUT8cJxbOTHmQU72Gq9ZoxUhmTdEI2hVoemHGM/+8foQnefxOvTDMO g3ZLH1Fk2llG7e37LpGO1I6IQ2MGEexLNjWXz3Ec/EAAkaERoXx/3qXE0KTSvg3+HUHc 9UsOMRZFNocDDkOg++bjm5EMqVsydaUyex/Y/Mn1c8U9+ts1SWWG4Fj+M3Vwt7SM8EC9 V9n/IzQYGXjhbwViW08HtbSv5k7RexHFWcWtd+b0TVLi28KWLdsAG2FrfNIinzE4PPp0 4GDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682713091; x=1685305091; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2GMDdmgqP5en66qF86TPJYgmIzrM2TpSxwbh3YtFitk=; b=SD8gJacIlSFaIAzksjj1WEZjkicPUwr/3Iaugn1YmChHAI4CyS2z09pdCOMMSludoF m6zRV4+/QwQPQZCngaYw5BgsP0QRnROl8uLB31YIZtrrLxpSDEigd5i0OoNDuKhL0jmU BuUdrz55u7fFFHECyO/drde1WlvlldpuUcqKnvEuP2IJwqPVbsOQgqVX++pwtl5j8Yb1 0uT020YIxmHf6AbQmmD0vHgWC2E901+3EilROUY0J3SPYHp1kt2+VnUixWMwrw/oeSIB lCAF8gTdqXJ/nuD3cJoDGfbRYXZUxaG5xw7gtAAeywFxeSIL9xjjHqxTr3318a+RYdzv DgBg==
X-Gm-Message-State: AC+VfDzXO0ptaWbOPFxS5p9vuEhiW/F8tq0zVZ0tc+qLQi8GECUi26Nv 0SZ8IwsBd9qZL1MgXhTWG06Dv2AE/8Q=
X-Google-Smtp-Source: ACHHUZ4tJt9DXiD5PXMNp1y04D5IzMIc70nrLhKtQ4Fh2z9QpRT7PavYtVS/QlHD5j1tRpQA9JbomQ==
X-Received: by 2002:aa7:8891:0:b0:63f:1a1e:3000 with SMTP id z17-20020aa78891000000b0063f1a1e3000mr9166068pfe.6.1682713091190; Fri, 28 Apr 2023 13:18:11 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n12-20020a056a00212c00b0063f172b1c47sm13977349pfj.35.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Apr 2023 13:18:10 -0700 (PDT)
Message-ID: <>
Date: Sat, 29 Apr 2023 08:18:06 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Michael Richardson <>, Alexis Rossi <>
References: <> <> <> <> <> <> <> <796.1682529129@localhost> <> <> <31200.1682702389@localhost>
From: Brian E Carpenter <>
In-Reply-To: <31200.1682702389@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
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 20:18:12 -0000

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.