Re: [rfc-i] archiving outlinks in RFCs

Ted Hardie <> Wed, 26 April 2023 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90B7FC14CE53 for <>; Wed, 26 Apr 2023 02:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ja9dJ684oEwp for <>; Wed, 26 Apr 2023 02:02:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 5F4D5C151547 for <>; Wed, 26 Apr 2023 02:02:05 -0700 (PDT)
Received: by with SMTP id 4fb4d7f45d1cf-505934ccc35so11818571a12.2 for <>; Wed, 26 Apr 2023 02:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682499724; x=1685091724; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=otycWQfyYFIyjs6QVceOg67OqtrWSidgz8JOehyM/jU=; b=W37bGrypd63VD0rs6HFlZ90pF79ivInZcdyog5z2NR/pdDPHeVhAnjGuh+qXpj9i2N 4yWQCmp3VTAKIPiLKZbbDCrq2RatEUIAxdNOJn1XcAmngtkjdjhE1dfe3tI27GFOMhn8 QStLd45J0Zjf31icLJpkIZCjUpNEq/jjimGaQ7KQnFheDtcgqjf4xV1XMrxz23WXALdl xhzcml0MGPSDAM2P7ZG8RwhP/l1Mjj/gud5QfpoIwqO3ucTAjmo+pq3N+JWW0cPLqdpE +ce0QBiEbmh8gy7wJU67XrNBLtnL23mn4Ljech1H/UgudWxByyeEobJFYKHUfgcjFB7z p5yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682499724; x=1685091724; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=otycWQfyYFIyjs6QVceOg67OqtrWSidgz8JOehyM/jU=; b=aQuBuniyVRfGF29+cFJTA3ZGZ83mTW3Tqfq3qpLrQ8cujTBpqtgQKDIP5uQuH5BJax njO/v7xYLSYk9VofAGKqm2t6YPo4mfAQDACG1IJycLEs4tmv9Pld4F5LyiQvxqy+F2S9 0wV/mF23of1NdNnUrJHm9VpAMx5CcaP+AuK4aHn0cBD/AYUMU36V/csCOVnby8SwFlnj L1LjWuAz3DHfcw0TTDgI7eZW/+9SmOjJZFntu59OfJOWzGprcaflrBmqnJa1gwm4JwFo 74MT1NG892+Q/eO8SuM3s8Ip76fxF+W0mnwwSlCiTGxIlwKmaRJ+eq0VGYKiwWUis28c NuQw==
X-Gm-Message-State: AAQBX9cAYZKcqg03VMVKYyoYl94BMoodY3T+P7yxw7rQ6dF898V00UuW 7c9l8AgGNk7DQyjrEyG6joXiLqPisuLtCnJkr6ZC1OeT
X-Google-Smtp-Source: AKy350b2HC6a4vjAt3XRk6lwVlvLfvZ7KgcYDy0drIHC2Ls5ZFv4Nru3rIH6e6aezewQ3rTJSi0cKRxQTfwUjtAp0S8=
X-Received: by 2002:a05:6402:32f:b0:508:4f66:e70d with SMTP id q15-20020a056402032f00b005084f66e70dmr16258978edw.36.1682499723567; Wed, 26 Apr 2023 02:02:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Wed, 26 Apr 2023 10:01:37 +0100
Message-ID: <>
To: Eric Rescorla <>
Cc: Martin Thomson <>,
Content-Type: multipart/alternative; boundary="0000000000005ba56205fa397e52"
Archived-At: <>
Subject: Re: [rfc-i] archiving outlinks in RFCs
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2023 09:02:09 -0000

On Wed, Apr 26, 2023 at 12:56 AM Eric Rescorla <> wrote:

> Hmm... I don't think this is right.
> Obviously the line between "style" and "content" is a fine, but istm that
> the
> line you propose to draw would allow the RPC to take all the MUSTs, style
> them out with CSS, and replace them with MUST NOTs.
> ISTM that the links are part of the semantics of the document and so having
> different links is a question for the RSWG.
> -Ekr
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
to an archive link like
then ieee.example has no chance to use its own redirects or tombstones to
give data to the person following the link.  That risk is mitigated if the
links are only changed when a link bitrots, but that introduces a
completely new cycle of checking which has to be constant (because if the
ieee.example  folks restore access to the data previously removed, then we
have a clear question of whether the new stuff is the target or the archive

I suggest that we use the erratum mechanism instead.  If the RFC Editor
notes a link has bitrotted, then an erratum that it is not available can be
filed which includes a pointer to the archived copy.  That allows the
erratum approvers to decide whether that erratum should be accepted or
should be amended to point somewhere else (if ieee.example updated their
numbering to 0876.1, say, to handle larger numbers and 0876.1 is the right
new pointer).


Ted Hardie

> On Tue, Apr 25, 2023 at 4:48 PM Martin Thomson <> wrote:
>> On Wed, Apr 26, 2023, at 09:41, Eric Rescorla wrote:
>> > I think the RPC could *probably* choose to publish a separate version
>> > that had archival links
>> > on its own, but I think the default version would again be a question
>> > for the RSWG.
>> If this were a question of publishing, maybe RSWG has a role to play.
>> However, we don't object to different renderings and this might not be too
>> far from that.  That is, you might make HTML available that had two links
>> for some references (canonical plus archival) maybe with strikethrough
>> styling on broken links.
>> I don't think that we are in a position to set policy there.  Any more
>> than we are in a position to set policy on what decorations or styling are
>> added in renderings.  The metadata header on or the
>> sidebar on are examples of "decoration" along these
>> lines.
>> _______________________________________________
>> rfc-interest mailing list
> _______________________________________________
> rfc-interest mailing list