Re: [rfc-i] archiving outlinks in RFCs

Alexis Rossi <rsce@rfc-editor.org> Thu, 04 May 2023 01:24 UTC

Return-Path: <rsce@rfc-editor.org>
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 38EBEC1519A6 for <rfc-interest@ietfa.amsl.com>; Wed, 3 May 2023 18:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 DGFAtiqBpmoh; Wed, 3 May 2023 18:24:46 -0700 (PDT)
Received: from smtpclient.apple (157-131-78-231.fiber.dynamic.sonic.net [157.131.78.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id CD973C15153E; Wed, 3 May 2023 18:24:46 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\))
From: Alexis Rossi <rsce@rfc-editor.org>
In-Reply-To: <fd3b00c7-b442-832f-dd62-392e3fc05d6f@gmail.com>
Date: Wed, 03 May 2023 18:24:46 -0700
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, RFC Interest <rfc-interest@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2273EDC6-1FEA-4A97-A5BD-11F11858E6F0@rfc-editor.org>
References: <E024D9AC-2B92-4720-9713-519592D2362B@rfc-editor.org> <30c30c2f-4e96-560a-73dd-a51ba8d04714@comcast.net> <771B7586-FFBB-49E4-9B99-5578863FBD8B@rfc-editor.org> <CABcZeBOevOj8cWY7dacWxzwZS82+iAjf1p+DZWF=7WZ9JydnrQ@mail.gmail.com> <48de4d92-e279-4c26-ab3c-15dd854b56f8@betaapp.fastmail.com> <CABcZeBPqePQwPAq5pWda1pGaY_=kLkcOxCjZWmOv9yRZ_MNb7g@mail.gmail.com> <CA+9kkMBVMTG7Zku4gt_DwCNWArYTauR_O0u70zceCMtN2GNN_Q@mail.gmail.com> <796.1682529129@localhost> <CA+9kkMBiqZCqbDviOVQFmjROYJtViz=S7ZsW6T41mv4XGbZ3=g@mail.gmail.com> <04BE48FA-322D-457A-9D7B-A9DA8FCE8E50@rfc-editor.org> <CA+9kkMCKM7A81+EU0OegtE5UbjLoVwsK7FVig8toddj-1APwxw@mail.gmail.com> <CANMZLAakmafNpe91TGG0eioR_yHt=n=ncV7nKLMCvCaQevoH8A@mail.gmail.com> <1718A586-7CFE-42CB-8206-DD7B18383BC9@ietf.org> <CA+9kkMCm1C762sTXiiP=MLLP9huuzdTbjJ-zROEXXJKGuwoGdg@mail.gmail.com> <93dd2fb8-f986-ed10-9369-529ab6bd320c@huitema.net> <BB283056-9CDA-4B3F-BEC7-BBAA036A3D29@rfc-editor.org> <17C4DAA9-8B91-4BEC-9BA4-F468308F01A1@vpnc.org> <fd3b00c7-b442-832f-dd62-392e3fc05d6f@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/N6uy2QQq-6PN-zgvyG5-lhEgprA>
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: Thu, 04 May 2023 01:24:47 -0000

>>> 
>>> 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?

Alexis