IETF Logo Mail Archive

Re: [rfc-i] archiving outlinks in RFCs

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 01 May 2023 20:03 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 4CE3FC14CE52 for <rfc-interest@ietfa.amsl.com>; Mon, 1 May 2023 13:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 S1iXF4LY--RL for <rfc-interest@ietfa.amsl.com>; Mon, 1 May 2023 13:03:12 -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 94CDDC1519B9 for <rfc-interest@rfc-editor.org>; Mon, 1 May 2023 13:03:07 -0700 (PDT)
Received: from [10.32.60.195] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 341K7Me4009040 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <rfc-interest@rfc-editor.org>; Mon, 1 May 2023 13:07:23 -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] claimed to be [10.32.60.195]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: rfc-interest@rfc-editor.org
Date: Mon, 01 May 2023 13:03:04 -0700
X-Mailer: MailMate (1.14r5937)
Message-ID: <79D998DD-735E-4450-BF86-76A1373A5934@vpnc.org>
In-Reply-To: <ee7373f2-8c60-90f4-daca-810ea648175d@cs.tcd.ie>
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> <31200.1682702389@localhost> <6c648d38-7bcb-a7b7-e2ce-44d17488160c@gmail.com> <74214E25-F9B0-4D1E-B124-579A3A102375@rfc-editor.org> <ee7373f2-8c60-90f4-daca-810ea648175d@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/lP0JKu9nKqY62weT0yJSdqRas_w>
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: Mon, 01 May 2023 20:03:18 -0000


On 1 May 2023, at 12:49, Stephen Farrell wrote:

> On 01/05/2023 20:27, Alexis Rossi wrote:
>> The main down side, if I understand correctly, of using the errata
>> system as the mechanism is that only one version of the RFC will have
>> archived links when something breaks (the html with inline errata).
> I'd argue that the current errata system is fairly useless
> in general, so the biggest downside of building on that is
> perpetuating that system. Better to (at some point, not sure
> when), start over entirely with how to deal with errors and
> infelicities in RFC text. By "start over" I mean start with
> (re-)defining what the system is for. Meanwhile, were it up
> to me, I'd not have anyone do any new work based on the
> current errata system.

Having done extensive work last year with errata on DNS-related RFCs, I fully agree with Stephen's assessment about not basing future extensions on the current errata system.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email