rfc-index.xml missing BCP0113

[ronaldtse]

Describe the issue

From @strogonoff relaton/relaton-ietf#104

This is 404: https://github.com/ietf-tools/relaton-data-rfcsubseries/blob/main/data/BCP0113.yaml

However, this exists: https://github.com/ietf-tools/bibxml-data-archive/blob/main/bibxml9/reference.BCP.0113.xml

This means BibXML service URL /public/rfc/bibxml9/reference.BCP.0113.xml uses fallback.

From @andrew2net:

The source dataset for relaton-data-rfcsubseries is https://www.rfc-editor.org/rfc-index.xml and it doesn't contain any document with BCP0113 identifier

I checked the latest rfc-index.xml and it does contain BCP0112, BCP0114, but no BCP0113.

@ajeanmahoney @rjsparks could we have a clarification here? Thanks!

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[ajeanmahoney]

BCP 113 contained only RFC 4333, which was obsoleted by RFC 8711, which belongs to BCP 101. Thus, BCP 113 no longer exists.

[rjsparks]

@ajeanmahoney : feature request for future rfceditor database work then? There should be a page that says "used to contain", perhaps even for bcps that still have things in them.

On the datatracker side, we have a task in front of us to model BCPs as a thing that has RFCs related to it, and we would have a page there that noted that the BCP existed but had no RFCs in it. I think we will also be able to look at the history of document relationships to say what it contained over various dates.

@strogonoff, @ronaldtse : the bibxml9 fallback should be updated.

[ronaldtse]

Thanks @ajeanmahoney @rjsparks for the clarification.

For the upcoming remodeling of the BCP which will attempt to model document history, please note that this represents a break from the RFC numbering tradition.

The RFC numbering tradition is that RFCs with the same number will not be published more than once. If a BCP is allowed to be differentiated into multiple editions (eg. contains RFC X in edition 1, no RFCs in edition 2, contains RFC Y in edition 3), we need a way of identifying each of these editions.

Eg. "BCP 133:2005" vs "BCP 133:2019".

[ronaldtse]

@strogonoff @andrew2net what @rjsparks meant is to remove the backstop file for bcp0113, because it should no longer resolve.

There will be an issue if some RFC currently references that BCP, but this case will not be handled right now, and subject to the decisions made subsequently on this topic.

[rjsparks]

I don't propose that a BCP number would ever be used to mean a collection about something unrelated - the title would never change.
But the set of RFCs that comprise a BCP (or a STD or any other subseries) have always been able to change over time, and many of them have changed.

[ronaldtse]

@rjsparks hmmm, here's an added problem -- BCPs traditionally have "inherited" the title from the first RFC it contains. BCPs do not have explicit titles. If it is decided that they should have titles, the RPC needs to explicitly assign them.

[rjsparks]

I went looking for an example to back up my claim of change of constituency, and am not finding one quickly.
While digging, however, I noticed that STD10 had all of its components obsoleted, yet continues to exist.

[alicerusso]

STD 10 is a particularly odd case. Essentially, the subseries identifier remains associated with 4 RFCs because 3 were obsoleted by a Proposed Standard (rather than an Internet Standard, which would have taken the identifier) and one was not obsoleted at all (RFC 1870).

As for the statement that "the set of RFCs that comprise a BCP (or a STD or any other subseries) have always been able to change over time, and many of them have changed" -- recent examples of this include STD 7, BCP 39, BCP 9, BCP 11, BCP 45, BCP 56. These are visible as the low subseries numbers in search results ordered by publication date, descending (e.g., for Internet Standards, for BCPs).

[rjsparks]

thanks for the examples!

[ronaldtse]

Thanks @alicerusso ! Allow me to summarize the issues for a potential decision:

Background:

• RFC subseries including: BCPs, STDs, FYIs are technically containers of RFCs because they can refer to more than one RFC. Most of the time, they act like aliases to RFCs when there is only one RFC contained.
• RFC subseries instances can be cited independently (from the RFCs they contain)

Questions for @rjsparks and the RPC:

1. Can an instance of a RFC subseries contain a mixture of "proposed", "obsolete" or "active" RFCs?
2. Do instances of RFC subseries (e.g. BCP 113, STD 10) have fixed titles? Or do they inherit a title from some component?
3. When an instance loses all its components (e.g. BCP 113), or have all its components obsoleted, can it still be cited? (existing citations should not be rendered unresolvable, in any case?)
4. Can one cite an instance from some point of history, e.g. can I cite BCP 113 from a time it still contained an RFC?

Thoughts?

[alicerusso]

1. Can an instance of a RFC subseries contain a mixture of "proposed", "obsolete" or "active" RFCs?

When an RFC is obsoleted, it no longer is part of the subseries identifier.
(I’m not sure how you are defining “proposed" and “active” here.)

2. Do instances of RFC subseries (e.g. BCP 113, STD 10) have fixed titles? Or do they inherit a title from some component?

No, they don’t. When referenced, a subseries identifier only lists the titles of the component RFC(s). The subseries identifier doesn’t have its own title.

Case in point, in rfc-index.xml, in each <bcp-entry> and <std-entry>, no title is listed; only the component RFC(s) are listed.

3. When an instance loses all its components (e.g. BCP 113), or have all its components obsoleted, can it still be cited? (existing citations should not be rendered unresolvable, in any case?)

No.
So, Jean raised the question of what happens in the case where an older RFC references a BCP, but later the BCP no longer exists. In the reference, the component RFCs are listed, so presumably the reader can find those. The URL in the reference (which in recent years is the info page of the BCP identifier) says "BCP X does not exist". (In older RFCs, there was no URL as part of the reference.)

4. Can one cite an instance from some point of history, e.g. can I cite BCP 113 from a time it still contained an RFC?

No. One could include prose to describe that situation, but one cannot have a reference to BCP 113 (or other BCP or STD identifier that doesn’t exist anymore).

From reviewing bcp-ref.txt and std-ref.txt (which contain reference entries for BCPs and STDs, respectively), we can see there are missing numbers (as listed below). This is typically the case where the component RFC(s) have been obsoleted or changed to Historic status. For a few examples below, I’ve provided more information.

BCP 1
BCP 2
BCP 12
BCP 66 - was RFC 3406; obsoleted by RFC 8141, which is not a BCP.
BCP 94
BCP 113 - was RFC 4333; obsoleted by RFC 8711, which became part of another BCP number (BCP 101).
BCP 115 - was RFC 4395; obsoleted by RFC 7595, which became part of another BCP number (BCP 35).
BCP 192

STD 1
STD 2
STD 4
STD 12
STD 14
STD 15
STD 18
STD 34
STD 39
STD 50 - was RFC 1643 (which was changed to Historic).

[rjsparks]

@ronaldtse I'm closing this - Alice has answered what the state is right now. The community is discussing what we will do in the future. I don't think there's an ask for change in the code at the moment.

[ronaldtse]

Thank you @alicerusso for the answers and @rjsparks for closing this. This does answer all our questions here!

[ronaldtse]

P.S. @strogonoff @andrew2net Please review the answers provided by @alicerusso and consider whether we need any changes on our end. Thanks.