IETF Logo Mail Archive

Re: [rfc-i] archiving outlinks in RFCs

Alexis Rossi <rsce@rfc-editor.org> Thu, 04 May 2023 01:21 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 1A3A5C15155B for <rfc-interest@ietfa.amsl.com>; Wed, 3 May 2023 18:21:26 -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 2ysYOmK5DRmP; Wed, 3 May 2023 18:21:22 -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 27C40C15153E; Wed, 3 May 2023 18:21:22 -0700 (PDT)
From: Alexis Rossi <rsce@rfc-editor.org>
Message-Id: <53EEB1F8-F719-48AD-AF5C-5705264A0B21@rfc-editor.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BA952006-E1A9-4F9F-A40C-F4DEE8F0329A"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\))
Date: Wed, 03 May 2023 18:21:21 -0700
In-Reply-To: <8E70D34A-3063-4376-BEAC-EE645FEE560C@vpnc.org>
Cc: RFC Interest <rfc-interest@rfc-editor.org>
To: Paul Hoffman <paul.hoffman@vpnc.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> <8E70D34A-3063-4376-BEAC-EE645FEE560C@vpnc.org>
X-Mailer: Apple Mail (2.3696.120.41.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/kHvrEbhe-c5IO3IoiWQbz_zsrZc>
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:21:26 -0000


> On May 3, 2023, at 5:54 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> 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
> 

Here is an example of HTML with inline errata: https://www.rfc-editor.org/rfc/inline-errata/rfc6376.html <https://www.rfc-editor.org/rfc/inline-errata/rfc6376.html>

If you are on the info page for an RFC (a la https://www.rfc-editor.org/info/rfc6376 <https://www.rfc-editor.org/info/rfc6376>), you see two HTML files there - one that reproduces the text as published, and one that includes verified errata. Perhaps you are looking at the versions that do not include errata?

As far as I know, there is no RFC that describes the errata system. There is an expired draft [1] and an IESG statement [2] - thank you to the RPC team for the pointers!

[1] https://datatracker.ietf.org/doc/draft-rfc-editor-errata-process/ 
[2] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

v2.23.0 | Report a Bug | By Email