Re: [rfc-i] archiving outlinks in RFCs

On Wed, Apr 26, 2023 at 12:56 AM Eric Rescorla <ekr@rtfm.com> wrote:

> Hmm... I don't think this is right.
>
> Obviously the line between "style" and "content" is a fine, but istm that
> the
> line you propose to draw would allow the RPC to take all the MUSTs, style
> them out with CSS, and replace them with MUST NOTs.
>
> ISTM that the links are part of the semantics of the document and so having
> different links is a question for the RSWG.
>
> -Ekr
>
>
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
give data to the person following the link.  That risk is mitigated if the
links are only changed when a link bitrots, but that introduces a
completely new cycle of checking which has to be constant (because if the
ieee.example  folks restore access to the data previously removed, then we
have a clear question of whether the new stuff is the target or the archive
is).

I suggest that we use the erratum mechanism instead.  If the RFC Editor
notes a link has bitrotted, then an erratum that it is not available can be
filed which includes a pointer to the archived copy.  That allows the
erratum approvers to decide whether that erratum should be accepted or
should be amended to point somewhere else (if ieee.example updated their
numbering to 0876.1, say, to handle larger numbers and 0876.1 is the right
new pointer).

regards,

Ted Hardie

>
> On Tue, Apr 25, 2023 at 4:48 PM Martin Thomson <mt@lowentropy.net> wrote:
>
>> On Wed, Apr 26, 2023, at 09:41, Eric Rescorla wrote:
>> > I think the RPC could *probably* choose to publish a separate version
>> > that had archival links
>> > on its own, but I think the default version would again be a question
>> > for the RSWG.
>>
>> If this were a question of publishing, maybe RSWG has a role to play.
>> However, we don't object to different renderings and this might not be too
>> far from that.  That is, you might make HTML available that had two links
>> for some references (canonical plus archival) maybe with strikethrough
>> styling on broken links.
>>
>> I don't think that we are in a position to set policy there.  Any more
>> than we are in a position to set policy on what decorations or styling are
>> added in renderings.  The metadata header on rfc-editor.org or the
>> sidebar on datatracker.ietf.org are examples of "decoration" along these
>> lines.
>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>