Re: [rfc-i] archiving outlinks in RFCs

[Brian Carpenter <[e-mail]>]

+1 to Ted except that sometimes errata are simply ignored for literally
years. That's why I suggest a timeout after which the redirect is
atomatically approved.

(via tiny screen & keyboard)
Regards,
        Brian Carpenter

On Fri, 28 Apr 2023, 20:03 Ted Hardie, <[e-mail]> wrote:

> On Thu, Apr 27, 2023 at 9:10 PM Alexis Rossi <[e-mail]> wrote:
>
>> It seems like using the errata system would maybe be a more haphazard
>> method of fixing broken links over time, since it relies on humans to
>> notice the original link is dead, report that as an errata, and then
>> another human to check and approve it. Unless the proposal is to have a bot
>> that files errata when links die (and then there’s just one human step to
>> approve)?
>>
>>
>> Yes, sorry that was clear.  Essentially, the steps I propose:
>
> On RFC publication, archive the outlink.
>
> Run a periodic check on the status of the links in each RFC.
>
> When one is determined to be unavailable, file an erratum mechanically
>
> The community that would normally determine erratum validity examines the
> issue and determines the next step, which might be one of:
>
> 1) The erratum is approved and lists the archived information as the
> target for approval on document update
> 2) The erratum is approved a different URL is listed as the target for
> approval on document update (e.g. the ieee.example/standards/08675
> replacing ieee.example/standards/8675
> 3) The erratum is rejected as the error was transient or will be corrected
> by the origin (where these are sibling SDOs, we generally have a way to
> reach out to them for this information).
>
> The normal erratum process is then used to provide this information to the
> community (either separately or in-line, depending on the method they
> choose).
>
> The advantage of this approach is that we are using community approved
> processes in a pretty easily understood way.  We can also use the same
> process when the link is live but something like a paywall has changed the
> state of availability.  That's not something we can likely identify
> mechanically, but we can re-use this set of steps.
>
> Sorry that this wasn't clearer before.
>
> regards,
>
> Ted
>
>
>
>> On Apr 27, 2023, at 1:40 AM, Ted Hardie <[e-mail]> wrote:
>>
>> On Wed, Apr 26, 2023 at 6:12 PM Michael Richardson <[e-mail]>
>> wrote:
>>
>>>
>>> Ted Hardie <[e-mail]> wrote:
>>>     > 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
>>>     >
>>> https://archivesite.example/see?https_ieee_example/876.1_retrieved_the_day_of_publication
>>>     > then ieee.example has no chance to use its own redirects or
>>> tombstones to
>>>
>>> It also keeps ieee.example from replacing the link that we were using
>>> with a
>>> link that goes through a paywall.
>>>
>>> (Which, btw, DOES HAPPEN regularly)
>>>
>>>
>> I think this would also be grounds for filing an erratum.  But my basic
>> point remains that the erratum process triggers the right thing: discussion
>> among the folks within the IETF who are responsible for the relevant RFC.
>> There are several different "correct" responses depending on the
>> circumstances, and they are the right folks to make the decision.  We
>> already have a way to indicate that there are errata and/or display them in
>> line.  We can use that here, rather than trying to decide in advance.
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>
>>> --
>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
>>> consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>>
>>> _______________________________________________
>> 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
>