IETF Logo Mail Archive

Re: [rfc-i] archiving outlinks in RFCs

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 04 May 2023 00:54 UTC

Return-Path: <paul.hoffman@vpnc.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 F34ECC151527; Wed, 3 May 2023 17:54:20 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Iql1lhsH35Zx; Wed, 3 May 2023 17:54:18 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6500C14CE5F; Wed, 3 May 2023 17:54:18 -0700 (PDT)
Received: from [10.32.60.195] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 3440wa5Q033143 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 May 2023 17:58:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.60.195]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Alexis Rossi <rsce@rfc-editor.org>
Cc: RFC Interest <rfc-interest@rfc-editor.org>
Date: Wed, 03 May 2023 17:54:16 -0700
X-Mailer: MailMate (1.14r5937)
Message-ID: <8E70D34A-3063-4376-BEAC-EE645FEE560C@vpnc.org>
In-Reply-To: <9557552C-D43E-4321-9E8D-E1B0844BDF18@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> <9557552C-D43E-4321-9E8D-E1B0844BDF18@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/jV6_NTzzKq3EiZJVnJZRobtlF84>
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 00:54:21 -0000

On 3 May 2023, at 17:40, 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.
>>
>> --Paul Hoffman
>>
>
>
> We already have a version of the RFC that includes inline errata (ie it has text that is not contained in the original RFC). I don’t see how something like indicating that a link is broken and pointing to a new one is materially different from that?

I was not aware that there is "a version of the RFC that includes inline errata". Are the rules for when that is and is not done published somewhere?
They are not in the style guide (that I can find), and I see HTMLs of recent RFCs that have verified errata where that has not been done.

RFC 7992 certainly did not cover changing the HTML output for errata.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email