Re: [rfc-i] archiving outlinks in RFCs

[Christian Huitema <[e-mail]>]

On 4/28/2023 1:57 AM, Ted Hardie wrote:
> On Fri, Apr 28, 2023 at 9:29 AM Jay Daley<[e-mail]>  wrote:
> 
>>
>> On 28 Apr 2023, at 09:22, Brian Carpenter<[e-mail]>
>> wrote:
>>
>> +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.
>>
>>
>> The more important point is that errata are not applied to RFCs as RFCs
>> are unchanging.  Using solely the errata mechanism would mean someone you
>> encountered a broken link, having to explicitly select the "show with
>> errata" feature to find the new link.
>>
>> So while the errata mechanism is close to what we want, in my view it’s
>> not enough.  (There’s also a principle debate on whether or not a dead link
>> is actually an erratum).
>>
>> I don’t what stopping us from creating a new process specifically for
>> broken links
>>
>> - bot checks links and finds broken one, auto-generates a report
>> - report is looked at by appropriate person/body who decide on replacement
>> link target (if there is one)
>> - HTML version of the RFC is updated to point to new target
>>
> Hi Jay,
> 
> I read what you wrote just above and contrast it with this "errata are not
> applied to RFCs as RFCs are unchanging".  You are simply saying that the
> HTML version of the RFC is updated with some errata and not others.   I
> think that is in conflict with "RFCs are unchanging" and, in this case in
> particular, it hides from the viewer of the HTML version that somebody has
> applied a change.  That seems wrong to me, personally, as that might be
> important data.

... but aren't URL often used to point to data that *is* changing over 
time? Suppose a text about RFCs says "an up to data list of citations to 
published RFCs is maintained at 
https://www.rfc-editor.org/rfc-index.html." Replacing that link with a 
snapshot at the time of publication would change the meaning of the text.

-- Christian Huitema