IETF Logo Mail Archive

Re: [rfc-i] archiving outlinks in RFCs

Marc Petit-Huguenin <marc@petit-huguenin.org> Thu, 27 April 2023 20:27 UTC

Return-Path: <marc@petit-huguenin.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 A8867C14CF0C; Thu, 27 Apr 2023 13:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-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 qpCJBitCk0Vu; Thu, 27 Apr 2023 13:26:56 -0700 (PDT)
Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4F9C1519A0; Thu, 27 Apr 2023 13:26:55 -0700 (PDT)
Received: from [IPV6:2601:204:e37f:a6af:d250:99ff:fedf:93cf] (unknown [IPv6:2601:204:e37f:a6af:d250:99ff:fedf:93cf]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E4BAEAE232; Thu, 27 Apr 2023 22:26:51 +0200 (CEST)
Message-ID: <409e47e6-298b-7763-695a-35bf4af08916@petit-huguenin.org>
Date: Thu, 27 Apr 2023 13:26:48 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Alexis Rossi <rsce@rfc-editor.org>, Ted Hardie <ted.ietf@gmail.com>
Cc: rfc-interest@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>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
In-Reply-To: <04BE48FA-322D-457A-9D7B-A9DA8FCE8E50@rfc-editor.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------FNo0WuwgmOsBIv03ScLglDt5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/UlGRBgq5rvxjGaUgop48Bfqwh20>
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:27:00 -0000

On 4/27/23 13:10, 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)?

Having a bot filling up an errata is, I believe, the right thing to do.

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


-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

v2.23.0 | Report a Bug | By Email