Detect when IETF specs gets obsoleted / replaced by another one #327
Comments
|
Detection of replacement is part of #1135, and based on the datatracker API. Detection of obsolescence indeed appears in (Edit) Actually, filetering seems to work, provided that the name used is the rfc2818 and not the "draft" name, e.g. https://datatracker.ietf.org/api/v1/doc/relateddocument/?relationship__slug__in=obs&target__name__in=rfc2818 |
|
Digging into it, I note that we currently list 8 IETF specs that have been obsoleted by another RFC (typically by RFC9110, RFC9111 or RFC9112:
These specs should be flagged as "discontinued" and obsoleted by the newer RFCs. |
tidoust
added a commit
that referenced
this issue
Nov 23, 2023
Take 3 :) PR #1135 actually had a couple of issues that made the code essentially useless because it only ran on a handful of IETF specs: - the code favored info from Specref over info from IETF - the code only really applied to drafts due to a buggy RegExp Fixing these problems yielded a new issue: the assumption that HTTP WG specs are always available under `httpwg.org` turns out to be wrong. Also, there are other specs that are not published by the HTTP WG but that still have an `httpwg.org` version. The code now looks at the actual list of specs in the underlying GitHub repository: https://github.com/httpwg/httpwg.github.io. As a result, the nightly URL of all IETF specs that have an `httpwg.org` version now targets that version, implementing the suggestion in #933 (see that issue for the list of affected specs). A companion PR was sent to Specref to implement a similar switch there: tobie/specref#766 The code also looks at the obsolescence data in datatracker and sets the `standing` and `obsoletedBy` properties accordingly. This fixes #327.
tidoust
added a commit
that referenced
this issue
Nov 23, 2023
Take 3 :) PR #1135 actually had a couple of issues that made the code essentially useless because it only ran on a handful of IETF specs: - the code favored info from Specref over info from IETF - the code only really applied to drafts due to a buggy RegExp Fixing these problems yielded a new issue: the assumption that HTTP WG specs are always available under `httpwg.org` turns out to be wrong. Also, there are other specs that are not published by the HTTP WG but that still have an `httpwg.org` version. The code now looks at the actual list of specs in the underlying GitHub repository: https://github.com/httpwg/httpwg.github.io. As a result, the nightly URL of all IETF specs that have an `httpwg.org` version now targets that version, implementing the suggestion in #937. A companion PR was sent to Specref to implement a similar switch there: tobie/specref#766 The code also looks at the obsolescence data in datatracker and sets the `standing` and `obsoletedBy` properties accordingly. This fixes #327.
tidoust
added a commit
to w3c/webref
that referenced
this issue
Nov 24, 2023
The status of some RFCs that used to be crawled by Reffy has recently (and correctly) been switched to discontinued, see list in: w3c/browser-specs#327 (comment) There are a bunch (*) of specs that still reference these discontinued specs. This update makes Reffy continue to crawl the RFCs to give us more time to update all specs, or at least to alert them that they need some update. (*) I will prepare an explicit list of such specs.
tidoust
added a commit
to w3c/webref
that referenced
this issue
Nov 24, 2023
The status of some RFCs that used to be crawled by Reffy has recently (and correctly) been switched to discontinued, see list in: w3c/browser-specs#327 (comment) There are a bunch (*) of specs that still reference these discontinued specs. This update makes Reffy continue to crawl the RFCs to give us more time to update all specs, or at least to alert them that they need some update. (*) I will prepare an explicit list of such specs.
43 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The information is available either through https://www.rfc-editor.org/in-notes/rfc-index.xml or via individual
https://www.rfc-editor.org/in-notes/rfcXXXX.json. specref also exposes it.Complements to #280
The text was updated successfully, but these errors were encountered: