Re: [rfc-i] archiving outlinks in RFCs

[Jay Daley <[e-mail]>]

> On 28 Apr 2023, at 11:03, Ted Hardie <[e-mail]> wrote:
> 
> Hi Jay,
> 
> Snipped, then in-line.
> 
>> 
>> Not quite.  My point is that the current errata process does not see any changes applied to the HTML and so if we were to use that process we would either have to accept that broken links remain broken unless someone goes looking for errata,
> 
> The presence of errata is pretty prominent: https://www.rfc-editor.org/rfc/rfc9110 for example, has a link at the very top of the page and https://datatracker.ietf.org/doc/rfc9110/ shows you both an html version and one with errata inline. So I believe that anyone who clicks an outlink and finds it broken will work out what to do pretty quickly if they start at the RFC editor site and/or the datatracker.  For those  documents which have been reproduced elsewhere we don't have any control over what errata get shown, but we wouldn't have any control no matter which option we picked.

We clearly have a very, very different idea of "pretty prominent".  Even if someone spots that text, they still need to clear some other hurdles:

- they need to understand what 'errata' are (this is not a common word)

- they need to be aware that there is the possibility that there are things wrong with the document that we know are wrong but have chosen not to fix in the current page (my totally unevidenced view is that 99.99% of people will fall at that hurdle)

- they need to read through our remarkably unfriendly errata page to find details of the broken link.

>  
>> or that a fundamental change is made to that process to apply some errata and not others.  As the former is unsatisfactory, and the latter is in the "really hard as demonstrated by long-standing debate" category, I am suggesting a new process that avoids either trap.
>> 
> 
> I personally use the errata inline version as often as I remember it exists, and I would be happy if it were the datatracker default view.  But that's a different issue and a slightly different set of decision makers. For this issue, it seems we simply disagree about the extent which it is unsatisfactory to have to look at errata to find the community decision on an updated link after one is broken; we may also disagree about the extent to which it is satisfactory to have a process which updates an RFC when some data in it is wrong but not use that same process for other data (even for trivial fixes like typos).  It's easy enough to disagree about that sort of thing, and I suppose the final word goes to the new WG.

Indeed.

Jay

> 
> regards,
> 
> Ted
> 
> 
>  
>> Jay
>> 
>>> 
>>> regards,
>>> 
>>> Ted
>>> 
>>> 
>>>  
>>>> 
>>>> Jay 
>>>> 
>>>> 
>>>>> 
>>>>> (via tiny screen & keyboard)
>>>>> Regards,
>>>>>         Brian Carpenter
>>>>> 
>>>>> On Fri, 28 Apr 2023, 20:03 Ted Hardie, <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> On Thu, Apr 27, 2023 at 9:10 PM Alexis Rossi <[e-mail] <mailto:[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] <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
>>>>>>>>>     > 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] <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] <mailto:[e-mail]>
>>>>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>>>> _______________________________________________
>>>>> rfc-interest mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>>> 
>>>> -- 
>>>> Jay Daley
>>>> IETF Executive Director
>>>> [e-mail] <mailto:[e-mail]>
>>> _______________________________________________
>>> rfc-interest mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>> 
>> -- 
>> Jay Daley
>> IETF Executive Director
>> [e-mail] <mailto:[e-mail]>

-- 
Jay Daley
IETF Executive Director
[e-mail]