Re: [rfc-i] archiving outlinks in RFCs

[Alexis Rossi <[e-mail]>]

> On May 2, 2023, at 3:56 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 
> On 02/05/2023 23:15, Alexis Rossi wrote:
>> Trying to steer clear of implementation details, I think these are
>> the goals from our discussion:
> 
> Apologies if I've lost track, but I thought part of this was
> to look back at what URLs in RFCs no longer work and also
> report on those as a way of figure out how to meet your goal
> #1 below. If that's the case, great, and maybe that'd be a
> good goal #0. If that's not the case, then it'd be a pity if
> the community don't get a chance to learn from that data.
> 
> I think there's value in reporting on what's found before
> trying to decide how to go about the two goals below, esp
> the 2nd one.
> 
> Cheers,
> S.

I think these can be independent of each other.

The Archive-It workflow is not particularly handy for producing this specific data, unfortunately. I think the appropriate thing to do to find this data is for us to determine how we want to find broken links in an automated way, and use that method to gather data when it is first run. That will only tell us about things like 404s and redirects, not about URLs where the content has changed or gone behind a paywall or similar (I think only human reports can do that part). 

As it is pretty straightforward to change the text on authors.ietf and the style guide, I don’t see a need to hold off on changing the text according to what we believe now and then update it later if we gather more helpful information. Unless you disagree with the goals below, of course.

> 
> 
>> Goal #1: Encourage authors to choose the appropriate URL when
>> creating an RFC.
>> - References to URLs with “live” content that is intended to change
>> over time should point to live URLs.
>> - References to URLs where the information you want to cite is the
>> exact same information you want all future readers to access should
>> use archived URLs in their references (ie take a “snapshot” of the
>> info as it is at this point in time and use that archived snapshot as
>> the reference).
>> Goal #2: Allow RPC to fix broken links in a version of published RFCs
>> with appropriate approval.
>> - When the RPC receives notification of a broken link, they can
>> identify a suggested replacement, obtain approval from the
>> appropriate entity, and update an html version of the RFC with the
>> approved link.
>> - Approval of replacement links for a document is provided by the
>> same entities who approve errata for the document.
>> If we think those goals are correct, here’s a proposal for how we
>> might get started:
>> - Update authors.ietf.org [1]  and Web Portion of the Style Guide [2]
>> to provide guidance on choosing live vs archived URLs.  Suggested
>> text: “For URL references, consider whether the resource contains
>> “live” information that updates over time, or whether you are
>> referencing information that should not change. For live information
>> we recommend that you use the live URL in your reference.  For URLs
>> where the information you want to cite is the exact same information
>> you want all future readers to access, you should use an archived
>> URL. An archived URL can be created using the Save Page Now feature
>> of the Wayback Machine [3], or you may ask the RPC to create one for
>> you prior to publication. It is not necessary to create or use
>> archived URLs for links to RFCs, Internet Drafts, RFC errata, or
>> emails on our mailing lists.”
>> - Add issue to 7322-bis [4] so that the updated Style Guide RFC
>> includes guidance on choosing the appropriate URL for your
>> references, per above.
>> - Update Web Portion of the Style Guide (or other place? I’m unclear
>> on where this should live) to allow RPC to fix broken URLs.
>> Suggested text: “When a link in a published RFC no longer leads to
>> the intended content, the RPC will attempt to replace it with either
>> an updated or archived version of the link in an html version of the
>> RFC. The RPC will consult with the appropriate entity to verify that
>> the replacement link is correct before the change is published.
>> Approval of replacement links for a document is provided by the same
>> entities who approve errata for the document. If there is no clear
>> approval entity for the document, RPC may ask RSAB for guidance.
>> Links changed via this process will be clearly marked. If no
>> replacement link can be found, the html version will identify the
>> link as broken.”
>> [1] https://authors.ietf.org/en/references-in-rfcxml
>> <https://authors.ietf.org/en/references-in-rfcxml> [2]
>> https://www.rfc-editor.org/styleguide/part2/
>> <https://www.rfc-editor.org/styleguide/part2/> [3]
>> https://web.archive.org/ <https://web.archive.org/>[4]
>> draft-rpc-rfc7322bis
>> <https://datatracker.ietf.org/doc/draft-rpc-rfc7322bis/> (which lives
>> in github at https://github.com/rfc-editor/draft-rpc-rfc7322bis
>> <https://github.com/rfc-editor/draft-rpc-rfc7322bis>)
>> _______________________________________________ rfc-interest mailing
>> list [e-mail] https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> <OpenPGP_0xE4D8E9F997A833DD.asc>