Re: [rfc-i] standards for references/URLs in RFCs ? (Was: Re: archiving outlinks in RFCs)

Brian E Carpenter <> Wed, 26 April 2023 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3F80C1519B9 for <>; Wed, 26 Apr 2023 13:51:00 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nWp2d-adlSfC for <>; Wed, 26 Apr 2023 13:50:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (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 8112AC15153F for <>; Wed, 26 Apr 2023 13:50:56 -0700 (PDT)
Received: by with SMTP id 98e67ed59e1d1-247526f0eceso5517977a91.2 for <>; Wed, 26 Apr 2023 13:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682542256; x=1685134256; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=38ReYZhykLm2pR6fXUBIrItVVvcOeXx26KbHYobV954=; b=h37xKTMMNvY0+jxGGO8VXbt8xWM8086HL37ZWS8u51Yhfpgha0ZkHmUNHWjcnMu6gj iaL0EEz6E4Wf2edrYHHsUZg53Q32dhXjfzvxXeV7eLwAC9hI7QO5SWv1RxPKJr9RquRw PEBHJWzgU4qrYeeXRwyCMiVVBe8Pdkwa+whbXxX4DNAuTT5Tc0lmKjxG+XWbgnoKyAAJ S/yA+UUkhuEnSy8QVWw0H0/qFGJKyffJlDT0Eue7E5VK6Kdzjj6lyM5tn/uWnQGwaxaI WF7ioAfPXC2RGzIu/szBBpnPXWg5pfm2blevUyBkxfKCnC9y7uGp2F+PuntoM/Nd5SRH Ftww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682542256; x=1685134256; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=38ReYZhykLm2pR6fXUBIrItVVvcOeXx26KbHYobV954=; b=eBBanDxWjIVdR7+SBixJ7IR32UH84qQbpVlSnjiDKR6r1Bl5OvRcDRAxxoZhvM/NDA JaOFSYKumGPTVd4uVh7PvMF7n9xlxgkPQ9jWJNEWqIczXLamgPiWMBF8xkymZ/GHLv80 9lnJk9SHxZhua/A2kOCNIzmmyjQyOfaFNLbZBGpuP5nRyA3NUzGId3G5lj2JMSwlSZ/K eW+wPi0aOmb5Rs6MDHkuyvFEztV1o22XvJ8nHKur4twNqn8xCjjV4GR98yQr4qFm6ke+ wbKAsI0UNi+l1f7jqtutY1/SkkQVBG2pkSQ9bIPH85aqyS3eNb82NB/eT9AJtyM8+XF4 5BAQ==
X-Gm-Message-State: AAQBX9f8e1N0CN9kTO34DB/+2XdJC53wa/98xr5xlUgTtWDpi/EQ0FDW qHGhErX/z57ezNbsGsXHMTylxwI8OAUJBA==
X-Google-Smtp-Source: AKy350b7oSrVYxuTo7TSB4MySLtX+siw2f/u6PJOR5HyruAvg5X2SXMDCVZ1eWUsTNy6oZQacupOcg==
X-Received: by 2002:a17:90a:ec0b:b0:244:952c:9701 with SMTP id l11-20020a17090aec0b00b00244952c9701mr21942471pjy.7.1682542255868; Wed, 26 Apr 2023 13:50:55 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d? ([2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d]) by with ESMTPSA id lt24-20020a17090b355800b00247735d1463sm10102877pjb.39.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Apr 2023 13:50:55 -0700 (PDT)
Message-ID: <>
Date: Thu, 27 Apr 2023 08:50:50 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Jean Mahoney <>, Jay Daley <>
Cc: Toerless Eckert <>, RFC Interest <>
References: <> <ZEjKrJK/> <> <> <>
From: Brian E Carpenter <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [rfc-i] standards for references/URLs in RFCs ? (Was: Re: 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 20:51:01 -0000

On 27-Apr-23 07:29, Jean Mahoney wrote:
> Hi all,
> On 4/26/23 6:05 AM, Brian Carpenter wrote:
>> The original comment Toerless referred to was about the suitability of a github citation, not about the mechanics of it.
> [JM] Yep, and the link that Jay provided says that references to GitHub repos are suitable for informative references.

It was a bit more subtle though (I was the commenter in question). Is a diagram that helps understand the text OK as an external reference? I didn't follow up on the WG list but my preference would have been an SVG diagram in the document itself.


> Thanks!
> Jean
>> (via tiny screen & keyboard)
>> Regards,
>>         Brian Carpenter
>> On Wed, 26 Apr 2023, 20:32 Jay Daley, <> wrote:
>>     Hi Toerless
>>     See for the specifics of referencing GitHub.
>>     Jay
>>>     On 26 Apr 2023, at 07:54, Toerless Eckert <> wrote:
>>>     Alexis,
>>>     Thanks a lot for the initiative, but before having more opinion about it, i would
>>>     like to reconfirm our current policies for new draft->RFC, and what type of
>>>     references/URLs are permitted/required by our process (IETF and RFC-editor).
>>>     For example, in one of my ongoing WG drafts, WG members made the comment that
>>>     a reference to a github location would not be looked upon favorably by RFC editor.
>>>     Aka: inappropriate reference because it is not stable.
>>>     In that particular case, the github file was part of a presentation given at a
>>>     WG meeting in the past, so our plan for this reference is to use the IETF proceeding URL
>>>     for the presentation instead.
>>>     [ Which should be considered to be an eternally stable URL, one would hope, unless we
>>>      do get IETF LLC? web admins that like in almost all commercial web pages of our industry
>>>      seem to be run by admins that like to drive users mad by randomnly deleting important
>>>      reference/history information or just changing URLs for spite or some new wb page tooling
>>>      that "did not allow us to keep existing URLs" (typical excuse i hear). /rant ]
>>>     Aka: I am totally unclear what type of URLs are or are not seen as
>>>     appropriate today by IETF process/RFC-Editor, and if someone could point me to any
>>>     reference we have (RFC ? <>.. ?), that would be lovely.
>>>     As another example, when defining terms, i sometimes thought it would be appropriate
>>>     to point to wikipedia. But given how the understanding of terms is changing over time,
>>>     wikipedia definitions might be the worst references to use. Just think of all the
>>>     technical terms we where fond of using (e.g.: blacklist) and that are now shunned/deprecated
>>>     by us (not even sure what the right word for the process is ;-) - as one example category
>>>     for this problem. If at all, it seems to me that references to wikipedia could
>>>     really only go to an archived version of a wikipedia page that was used by the authors
>>>     when writing the draft/RFC.
>>>     Cheers
>>>        Toerless
>>>     On Tue, Apr 25, 2023 at 11:50:24AM -0700, Alexis Rossi wrote:
>>>>     Hi all,
>>>>     I wanted to let the community know about something I’ve been working on. As you might know, one of my previous jobs was running the Wayback Machine, so when I started working with with this collection of RFCs one of my first thoughts was, “I wonder how many broken links are in these RFCs from the past few decades?”
>>>>     In general, the average lifespan of a URL before the content changes or disappears is on the order of 100 days. Fortunately for us, the links used in RFC references seem to be much more stable than that. For instance, so far I’ve only found one broken link in an RFC from the past 6 months [1].
>>>>     Even though we favor these more stable URLs, some of them will eventually change or go 404 and having archival documents with link rot is something we can take steps to avoid in the future.
>>>>     The first thing I wanted to do was just make sure we were archiving these outlinks somewhere. This won’t fix a broken link in the RFC, but at least the resource can be saved elsewhere for someone curious enough to go look (and potentially we could fix links in some version of the RFC in future).
>>>>     The main services that are well qualified for this purpose are <> (run by the Internet Archive) and <> (run by Harvard Law School Library). I chose Archive-It, and when I approached them they offered us an account [2] with enough free data storage for our needs. Yay for non-profits supporting each other!
>>>>     So far I have used Archive-It to:
>>>>     Archive <> <>, <> <>, <> <>, and <> <> (minus datatracker and the mail archive)
>>>>     There are lots of references to these sites in RFCs, but I also wanted to preserve the contents for their own sake. I plan to revisit these sites once per year.
>>>>     I am avoiding datatracker (except for outlinks from RFCs) because of concern about the extra traffic causing problems for the team that maintains the site.
>>>>     I have not concentrated on archiving the mail archive yet, though I know some of it has been saved incidentally.
>>>>     Archive outlinks from RFCs
>>>>     About once per quarter I’ll grab the outlinks from newly published RFCs and get them crawled.
>>>>     I am also going backwards through the entire series - I’ve started with the most recent RFCs (links are more likely to still be live) and am working my way back in time.
>>>>     There may be more room for improvements here, for example including archived links in RFCs from the start w here appropriate, or potentially defining a way for links to be self-healing in published RFCs.
>>>>     Please let me know if you have ideas or feedback on this.
>>>>     Thanks,
>>>>     Alexis
>>>>     [1] RFC9311 published in September 2022, in Section 11 (Informative References) this link is 404: <>[2] <>
>>>>     _______________________________________________
>>>>     rfc-interest mailing list
>>>     -- 
>>>     ---
>>>     _______________________________________________
>>>     rfc-interest mailing list
>>     -- 
>>     Jay Daley
>>     IETF Executive Director
>>     _______________________________________________
>>     rfc-interest mailing list
>> _______________________________________________
>> rfc-interest mailing list