Re: [rfc-i] archiving outlinks in RFCs

[Paul Kyzivat <[e-mail]>]

On 4/27/23 4:20 PM, Brian E Carpenter wrote:
> I think that automating the errata creation is a good idea. The point is 
> to trigger human intervention when it's appropriate, and that should be 
> a stream choice rather than an RPC choice. In many cases an automated 
> redirect to an archive copy will be all that's needed.

The errata process (possibly with help of a bot) MAY be a suitable way 
to identify broken links and decide on an alternative link.

But do you intend this to also be the way that readers of the document 
find their way to the alternative link? IOW, must I first try the 
original link, discover it doesn't work, then search the errata, find 
the one that addresses this, and then link to the alternative?

I find that far from ideal. Many (most?) readers won't do this, and 
those who do will be annoyed.

It might be ok if the document link is changed when the erratum is 
approved. But that might be the opening of Pandora's box: It would also 
be nice to have a version (or rendering) of the document that 
incorporates *all* the errata.

	Thanks,
	Paul

> Regards
>     Brian
> 
> On 28-Apr-23 08:10, Alexis Rossi 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)?
>>
>>
>>> On Apr 27, 2023, at 1:40 AM, Ted Hardie <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>> On Wed, Apr 26, 2023 at 6:12 PM Michael Richardson 
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>
>>>     Ted Hardie <[e-mail] <mailto:[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 <https://ieee.example/876.1>
>>>         > to an archive link like
>>>         > 
>>> https://archivesite.example/see?https_ieee_example/876.1_retrieved_the_day_of_publication <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] 
>>> <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>>>                Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rfc-interest mailing list
>>> [e-mail] <mailto:[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
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest