Re: [rfc-i] archiving outlinks in RFCs

Brian E Carpenter <> Thu, 04 May 2023 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBC0FC1516F3; Wed, 3 May 2023 20:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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 QrZlgZIf8mQg; Wed, 3 May 2023 20:07:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42f]) (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 A9DB6C151710; Wed, 3 May 2023 20:07:15 -0700 (PDT)
Received: by with SMTP id d2e1a72fcca58-64384c6797eso22437b3a.2; Wed, 03 May 2023 20:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683169635; x=1685761635; 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=qFkB4wcf3/DjOVlzspBn8xY7acM2Zzd9Naxi/b+rEd4=; b=o7yXelZ4CiHrlLTswur+xOSYOKBftRf0k7dm7qWG2LNlCqsbhkT3yAWtHgvAtXCNLm LI+UZUOV1kTswcqnQl8+TlV+PRP4ozdh1LCR0lL0XT8ZDHQGjqlWJryfLBdlqU91+smy 9ixRG8gte2FfUDZOae7HlQo9PL3gxrzthYUlYJunltP3mEZPZ4Uipf5Svio1GlstzbZh 4zngM+Ruz9Qa9uuu1ls+jr8dNu1Hx79HGH2sObsRlffKVJcdAVhUGXmfoxFpFJUhxTMx iCSI1r4WJeniJnJenDJpcgnE73k9EARKtCxniJP/sN49y3UZuso+sLXCoCC0rwulmuGQ Flog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683169635; x=1685761635; 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=qFkB4wcf3/DjOVlzspBn8xY7acM2Zzd9Naxi/b+rEd4=; b=fi7s7JGKcxKC4o0CarlL/21p09uIeqFuDVMnwWdGLNQTNQ4IOdW6i/lkXsz1RdRN+w Qpbs+SUvzTikdFsC6VChIEbImE0DGPx2ApYB44WoR9frpclrCR4K7/Lg/TdWO/59D/G3 wpKvV1LVS+o6igWd0eKFVSqMTLqdu07XlHwXiUnKc385LTMif0xOxW3THXe9llU7Z3Mh DumlT13FJ51JZpxJ7NQUy7yCRlvAPMarm3PbBX5ykGjoPvvQ6e5Spqs4P5Duc2jd2BN5 QCtgh82UHGGlsbc5OFbsZ2NJo/ZAWgL4sBhJKRDgrTG4Pqy0Zp8X/Kg13dD3Z997mP4D i8pw==
X-Gm-Message-State: AC+VfDyqgp/q+W7qAkLL8hXRHbYul/TF+Cfqdt5GBVrKCZoi+egnnnDS u1KEht75qtCr5efv33sOvH+GXrankFor+A==
X-Google-Smtp-Source: ACHHUZ45dRda04NyYAf6JpNVfZNqkSwXZjyl02WXQdrWoYgknJv1XVRLiJaU+V8PJ6qBsfZohKEcYA==
X-Received: by 2002:a05:6a00:a16:b0:63d:46d3:cc09 with SMTP id p22-20020a056a000a1600b0063d46d3cc09mr911474pfh.14.1683169634919; Wed, 03 May 2023 20:07:14 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:9991:d1ad:8c20:42bd? ([2406:e003:1184:f001:9991:d1ad:8c20:42bd]) by with ESMTPSA id b15-20020aa7810f000000b0063d3801d196sm563020pfi.23.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 May 2023 20:07:13 -0700 (PDT)
Message-ID: <>
Date: Thu, 04 May 2023 15:07:08 +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: Alexis Rossi <>
Cc: Paul Hoffman <>, RFC Interest <>
References: <> <> <> <> <> <796.1682529129@localhost> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
In-Reply-To: <>
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: Thu, 04 May 2023 03:07:18 -0000

On 04-May-23 13:24, Alexis Rossi wrote:
>>>> Goal #2: Allow RPC to fix broken links in a version of published RFCs with appropriate approval.
>>>> - When the RPC receives notification of a broken link, they can identify a suggested replacement, obtain approval from the appropriate entity, and update an html version of the RFC with the approved link.
>>>> - Approval of replacement links for a document is provided by the same entities who approve errata for the document.
>>> Goal #2 would be a policy decision, and thus brought to the RSWG after Goal #1 is implemented. In specific, replacing any text in any format of an RFC is certainly a policy change from what we have now.
>> In case it wasn't obvious, that was an advantage of the proposal to treat broken URLs as errata - there is already established policy.
>> A sub-question is whether we treat http: URLs as broken if they have been replaced by https:. There will likely be many of those.
>>    Brian
> I do see the advantage of the errata system, as it provides tooling and approval procedures that are already in place. However, I don’t think broken links are errata, per se, and it sounds like the current system is going to be replaced. I don’t have a particular opinion yet about implementation - does the goal itself seem correct? Regardless of what we do to implement it?

Yes, I think the goal is correct, and I'm not at all sure there's really a policy change here as long as the rendering of the RFC with fixed links is clearly labelled as such. While these are not errata that could in theory have been identified at the time of publication, their practical impact is exactly the same: something in the original rendered text is wrong, and here is a fixed version. I absolutely do not care whether we call broken links "errata" or "fracturae" because I think the mechanism, including approvals, can be exactly the same.

(That was carefully worded to keep it distinct from the "Modifying the XML" topic.)