Re: [rfc-i] archiving outlinks in RFCs

Alexis Rossi <rsce@rfc-editor.org> Thu, 27 April 2023 20:10 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 099FFC15E406 for <rfc-interest@ietfa.amsl.com>; Thu, 27 Apr 2023 13:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 JrWtpCD-SZRX; Thu, 27 Apr 2023 13:10:30 -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 685ACC15EB2E; Thu, 27 Apr 2023 13:10:25 -0700 (PDT)
From: Alexis Rossi <rsce@rfc-editor.org>
Message-Id: <04BE48FA-322D-457A-9D7B-A9DA8FCE8E50@rfc-editor.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8C1C690-E885-42AB-8E65-4B3C777C812F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\))
Date: Thu, 27 Apr 2023 13:10:24 -0700
In-Reply-To: <CA+9kkMBiqZCqbDviOVQFmjROYJtViz=S7ZsW6T41mv4XGbZ3=g@mail.gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, rfc-interest@rfc-editor.org
To: Ted Hardie <ted.ietf@gmail.com>
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>
X-Mailer: Apple Mail (2.3696.120.41.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/4uASdi_dCmDUqvG-Q506LzWLP3Q>
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, 27 Apr 2023 20:10:35 -0000

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


> On Apr 27, 2023, at 1:40 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> On Wed, Apr 26, 2023 at 6:12 PM Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> wrote:
> 
> Ted Hardie <ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>> 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 <https://ieee.example/876.1>
>     > to an archive link like
>     > https://archivesite.example/see?https_ieee_example/876.1_retrieved_the_day_of_publication <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 <mcr+IETF@sandelman.ca <mailto:mcr%2BIETF@sandelman.ca>>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest