Re: [rfc-i] archiving outlinks in RFCs

Eric Rescorla <> Tue, 25 April 2023 23:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20E9FC15154D for <>; Tue, 25 Apr 2023 16:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 arXIPYJDjmHw for <>; Tue, 25 Apr 2023 16:42:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1134]) (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 334C7C14CE3B for <>; Tue, 25 Apr 2023 16:42:15 -0700 (PDT)
Received: by with SMTP id 00721157ae682-54f851bcd4fso75991627b3.3 for <>; Tue, 25 Apr 2023 16:42:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682466134; x=1685058134; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y43Nr9UE2IMEN/DsIMCZMYwOnSpS300rqUe5uqEpZhs=; b=PvSL8XsM9rFMus4TWlxf+cz0XauzG/tM5+CSF0KMMuvHlVoaFOa1lSsgiBClzuiAxl ICWNKSOtf7CEd+OtlJqOw5e5LwbOOVITU7+YB6HNJtU7Nk/Dd9MnoOT+Ld1ReEPtDuAy i99WSrr9E100SX0dwdk1/tcvgK60zkKnWxl1QHE0bwiw6Cmtnfnt4de84cVwtq30jTUS pRE89o2ed6EAq8WfuftRP3z0NLbOenCHIY9nrtGNpiBeL/v+2FOwOX5QU5IsqS17nrnl n+rYUEJ3JN15lQCrdlj7e44Hzes6iGtv6tiw27Z0NUTjqepGDl5qFfoRTdISCnrpK9+r M6lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682466134; x=1685058134; 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=Y43Nr9UE2IMEN/DsIMCZMYwOnSpS300rqUe5uqEpZhs=; b=bMQLQtXRHLSpXcDWjXr7715JkVfxZ4W1bSGlajP5OWo4N84TcoM6Fmv/KRTyy/vvE2 lyuKEJ+wPfSAoQvrHXAJhaKn/OLsRoz19/raZNxT0fgyF7LtWHnXED6d8m4FxGqYUyDv EHwHbifUWYMgOZJzTHO0jc/XqS4vK6wxDRKO62xwxqcVxdmGjclY5cARwi5jPMSgb3iK sxRT85CXGFFUYeQkgJMBcBcCNp8WAdq7pujhsWrIzxlvLOLObnTiZkSWOHcsDWEQjmSj ocvpP6TOOw5tjIA15vxzzwACB6jXEh888+XS95MCAEIYTS9we9yDbYvjc+TfylTDiFxl +bFg==
X-Gm-Message-State: AAQBX9fURVEZsNRT8cbJ8yh0/R5TTn26KiIR4BADUMr0Yg7yrt8g85tD 02Lp4K7wqreZtVVBO+c12v37Q03a7Xt6h8+ui1eo1g==
X-Google-Smtp-Source: AKy350YY4hT+ENuyRNTCmf0zbyXsedga0kIJdHUB1NI9y57j5Fm0UrhrWp4f0dSb9u8vlJIdoIvVwr3HwmAOLjBlnM4=
X-Received: by 2002:a0d:cb8e:0:b0:54f:d15:3d8d with SMTP id n136-20020a0dcb8e000000b0054f0d153d8dmr11480896ywd.46.1682466134256; Tue, 25 Apr 2023 16:42:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 25 Apr 2023 16:41:38 -0700
Message-ID: <>
To: Alexis Rossi <>
Cc: Paul Kyzivat <>,
Content-Type: multipart/alternative; boundary="00000000000047883705fa31acaf"
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: Tue, 25 Apr 2023 23:42:19 -0000

On Tue, Apr 25, 2023 at 4:24 PM Alexis Rossi <> wrote:

> > On Apr 25, 2023, at 12:33 PM, Paul Kyzivat <>
> wrote:
> >
> > Alexis,
> >
> > This is interesting. Would it make sense to adjust our RFC format so
> that links are directly to an archival site, or so that each reference has
> two links, one to an original document and the other to an archival
> version? Or that all the RFCs are periodically tested and automatically
> switched to an archived target if the original goes stale?
> Yes, I think something like these suggestions is a good next step. I know
> starting with a link directly to an archival version might not work for all
> outlinks - the authors may want to refer to a “living” resource that
> changes over time, for instance. So perhaps the best place to start is to
> always use two versions for outlinks - a live one and an archived one - and
> do that automatic switch when the live link dies. Perhaps putting in the
> archived outlinks becomes part of the editorial process? I’m interested to
> hear about the community’s thoughts on this, because I’m sure I don’t fully
> understand all of the same context that RFC authors writ large have on this
> subject.

Without taking a position on whether we should replace the links at
publication time, I believe
that would almost certainly be a question for the RSWG.

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.


> _______________________________________________
> rfc-interest mailing list