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

[Jean Mahoney <[e-mail]>]

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.

Thanks!
Jean


>
> (via tiny screen & keyboard)
> Regards,
>         Brian Carpenter
>
> On Wed, 26 Apr 2023, 20:32 Jay Daley, <[e-mail]> wrote:
>
>     Hi Toerless
>
>     See https://www.rfc-editor.org/styleguide/part2/#ref_repo for the
>     specifics of referencing GitHub.
>
>     Jay
>
>>     On 26 Apr 2023, at 07:54, Toerless Eckert <[e-mail]> 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 ? www.ietf.org/..
>>     <http://www.ietf.org/..>.. ?), 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
>>>     Archive-It.org <http://archive-it.org/> (run by the Internet
>>>     Archive) and Perma.cc <http://perma.cc/> (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 rfc-editor.org <http://rfc-editor.org>
>>>     <http://rfc-editor.org/>, iab.org <http://iab.org>
>>>     <http://iab.org/>, irtf.org <http://irtf.org>
>>>     <http://irtf.org/>, and ietf.org <http://ietf.org>
>>>     <http://ietf.org/> (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:
>>>     https://www.ietf.org/how/meetings/98/bits-n-bites/
>>>     <https://www.ietf.org/how/meetings/98/bits-n-bites/>[2]
>>>     https://archive-it.org/organizations/2540
>>>     <https://archive-it.org/organizations/2540>
>>
>>>     _______________________________________________
>>>     rfc-interest mailing list
>>>     [e-mail]
>>>     https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>
>>
>>     -- 
>>     ---
>>     [e-mail]
>>
>>     _______________________________________________
>>     rfc-interest mailing list
>>     [e-mail]
>>     https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>
>     -- 
>     Jay Daley
>     IETF Executive Director
>     [e-mail]
>
>     _______________________________________________
>     rfc-interest mailing list
>     [e-mail]
>     https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>
>
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest