IETF series is mislabeled

[rjsparks]

What is currently labelled as the "IETF" category really should be the "RFC" category - many of the RFCs in the series do not come from the IETF.

[ronaldtse]

@rjsparks thanks for the clarification. @strogonoff could you help handle this? Thanks.

[strogonoff]

@ronaldtse BibXML does not come up with its own identifiers, it exposes values of docid.type which can be changed in the source data.

[strogonoff]

Should probably be moved to relaton-data-rfcs…

[ronaldtse]

Sorry for getting back late @rjsparks -- could you shine more light on "many of the RFCs in the series do not come from the IETF."?

Is this meant to reflect that the contents of RFCs originate from these entities?

https://www.rfc-editor.org

the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), and Independent Submissions

Question: Who is considered the publisher of an RFC? The "RFC Production Center? IETF Trust? One of IETF/IRTF/IAB? What about independent submissions?

We can re-label the series but I feel we may need to make deeper changes for this.

[rjsparks]

The series should be called "The RFC Series". It would be best (as in, I think this is a requirement) in this application to simply call it "RFC".

It will not help us to try to pin down who is considered the publisher. The short, but not useful for this exercise, answer is "The RFC Publisher" as defined in RFC8728.

The IETF, IRTF, IAB, and Independent streams are the current sources of RFCs, as defined in RFC8728. Figure 1 may help you. But be aware that the model is likely to change soon - see https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/ where the Publisher is formally rolled into the RPC.

But again - the series should simply be called "RFC"

[ronaldtse]

No problem (and no objection) with calling the series just "RFC". Will discuss with @strogonoff on how to make that happen.

@andrew2net I think this means that the document identifier type should be renamed to "RFC" as well. If the identifier is renamed to "RFC", @strogonoff will this issue be fixed?

[andrew2net]

@ronaldtse I think we need to discuss with Nick if can change docidentifier type "IETF" to "RFC". Some time ago he asked me to make RFC identifiers look like <docidentifier type='IETF'>RFC 8341</docidentifier>.
There are "RFC" and "DOI" series in the document. Should we keep both? Or just "RFC"?

[strogonoff]

To be clear, the requirement will be satisfied one way or the other—push comes to shove BibXML service can easily add an abstraction layer on top of BibliographicItem model.

It’d cost extra complexity/maintenance though, so worth checking if this issue is a sign that the model could be improved.

[ronaldtse]

I think we need to discuss with Nick if can change docidentifier type "IETF" to "RFC". Some time ago he asked me to make RFC identifiers look like <docidentifier type='IETF'>RFC 8341</docidentifier>.

@opoudjis is technically a consumer of RFC bibdata. Since we have the authoritative source explaining that the RFC series is labelled "RFC" not "IETF", because it contains non-IETF documents, we must adjust the Relaton project accordingly and inform its downstream consumers to use this. (ping @opoudjis)

There are "RFC" and "DOI" series in the document. Should we keep both? Or just "RFC"?

We always keep all identifiers, but we need a way to mark which one is "authoritative". In this case the "RFC" one is authoritative (a key), the DOI is supplementary (an optional attribute).

[andrew2net]

@ronaldtse BibXML does not come up with its own identifiers, it exposes values of docid.type which can be changed in the source data.

@strogonoff the the Relaton model series is stored in the series attribute:

item = RelatonIetf::IetfBibliography.search "RFC 8341"
series = item.series.detect { |s| s.title.title.content == "RFC" }
series.title.title.content
=> "RFC"
series.number
=> "8341"

[strogonoff]

@andrew2net

That’s good to know. Anyway, I believe at this point we have organizational reason to switch docid.type to RFC…

[strogonoff]

This looks like bibliographic source data related matter, and should probably be moved to respective repository.

[andrew2net]

That’s good to know. Anyway, I believe at this point we have organizational reason to switch docid.type to RFC…

@strogonoff I don't have any objection but we have other Relaton model consumers. For example, the Metanorma uses the Relaton. We need to reconcile it with all the consumers. Ping @ronaldtse

This looks like bibliographic source data related matter, and should probably be moved to respective repository.

What repository are you talking about?

[strogonoff]

If 1) docid.type signifies a publishing organization and 2) RFCs are technically published by other organization than IETF, then it’s not our decision not to change docid.type.

I raised the question on what docid.type actually means before, because neither DOI nor ISBN seem to reference an publishing organization, but we are using them for identifier types.

What repository are you talking about?

No idea. Definitely not this one.

[andrew2net]

RFCs produced by the IETF cover many aspects of computer networking.
If I'm right the IETF docid.type means the document is published by IETF.
IETF publishes bibliographic items of RFC, W3C, ISO, and other standards on its sites.

[ronaldtse]

IETF publishes bibliographic items of RFC, W3C, ISO, and other standards on its sites.

IETF does not publish W3C and ISO etc documents, only their bibliographic items. Moreover, it was already stated that the publisher of RFC is "The RFC Publisher", not "IETF".

The docid.type signifies the "document ID scheme". Let's move this discussion elsewhere. This is not an IETF discussion, let's move this back to Relaton.

[ronaldtse]

Conclusion: we will use "RFC" as the docid.type.

[ronaldtse]

Let's continue non-IETF related debates here: relaton/relaton-ietf#36 . IETF has stated their decisions and we will follow.

[andrew2net]

IETF does not publish W3C and ISO etc documents, only their bibliographic items.

@ronaldtse maybe I misused the terminology. The ISO document is on the IETF site. We use the relaton-ietf gem to get it.
The relaton gem uses prefixes to route the references to appropriate relaton-*gem. In the current Relaton workflow prefixes are stored as docid.type. If we need to know from which source the RelatonXML document was fetched then we need to store prefixes somewhere.

[ronaldtse]

@andrew2net we need to distinguish between an "information resource" (which is a document) and the "bibliographic data of an information resource" (the metadata of the document). Here, IETF provides the bibliographic information of some ISO standards, not the ISO standards (documents) themselves.

docid.type is only for explaining the Publication ID scheme used by the document, not where the bibliographic data came from. One document can have multiple Publication IDs, but all of them can come from the same source.

[opoudjis]

Until now, we have used the document identifier to indicate, in SDOs outside of the IETF, that their identifiers come from them, by giving them as IETF RFC xxxx and IETF I.D.-xxxx. We have been able to do this, by using the document ID type as the prefix.

As a result of this decision, we will not be generating IETF as a prefix to either RFC or I.-D. Because the supplied document type is the mechanism for us to disambiguate document identifiers. So outside of IETF document identifiers, RFC documents shall henceforth appear without the IETF prefix, and if RFC is applied to I.-D. document identifiers shall appear as "RFC I.-D.".

I shall not be doing any ad hoc code to replace "RFC" with "IETF" in document identifiers. If that's the document identifier prefix, then that's what we will implement.

If "RFC I.-D." is to be avoided, then the document identifier type should be IETF. It cannot be an ad hoc type like IETF I.D., and I.-D. is still included in the document identifier proper out of relaton.

My understanding is that Relaton has implemented IETF as the document identifier prefix for I.-D, and RFC for RFC. That will flop out straightforwardly, it just means that IETF RFC xxxx won't appear outside of IETF document (which presumably is in accordance with IETF wishes).

[opoudjis]

As it turns out, the only code impacted is metanorma-ietf, which drops the IETF prefix from any citations it processes. I will address this ticket by dropping either IETF or RFC as prefixes. (RFC xxxx is still going to be the body of the docidentifer out of relaton, so document identifiers will still be displayed as RFC xxxx both within and outside IETF documents—since duplicate prefixes are dropped.)

[rjsparks]

Question - why are RFCs and Internet-Drafts being put in one bucket? Could they be put into two?

We have a long-standing issue with people treating Internet Drafts as if they were standards - Internet-Drafts are not RFCs, and to label them RFC Internet-Drafts would create a great deal of confusion.

[ronaldtse]

@rjsparks apologies for having this discussion publicly -- we've already reached an internal consensus that aligns with your guidance.

1. The "RFC series" will be presented as "RFC {number}".
2. The "Internet-Draft series" will be presented as "IETF Internet-Draft {draft name}" (or just "Internet-Draft: {draft name}", if this is the correct option)

[rjsparks]

Just Internet-Draft - again, these things come from irtf, iab, random people, etc.

[ronaldtse]

Thank you @rjsparks for the clarification. Just "Internet-Draft" then.

[ronaldtse]

@rjsparks do you see any remaining issues here? Thanks.

[rjsparks]

I think this is resolved, but looking at what's a dev, I see a minor UI issue that I'll open another issue for (about presenting internet drafts as standards).

[rjsparks]

Actually, I still see an issue (same image as in #137, but I want to point to a different place)

At IETF I-D.hunt-scim-events
What is the purpose of the 'IETF' label on that line? It is likely misleading. Is it Publisher or something else?

This can be interpreted to mean the drafts are in the IETF stream, as opposed to the IRTF stream, IAB stream, or no stream at all.

I still have strong misgivings about saying the Publisher is "IETF" for internet drafts, but I don't have something better.

[strogonoff]

@rjsparks this is not a publisher, but internal “identifier type” (akin to DOI and ISBN).

I believe this actually should be hidden in BibXML service for RFCs and I-Ds, since it does not offer any useful information.

If it’s still a problem if data of this shape continues to exist in public data source repositories, we can probably adjust the data sources. I agree it’s bound to cause ambiguity if it looks too much like a potential publisher abbreviation but isn’t.

[ronaldtse]

How about we change the "IETF identifier label" to say "Internet-Draft"? That would solve the confusion.

[rjsparks]

That would be awesome.
Similarly on pages like https://dev.bibxml.org/get-bibliographic-item/?query=rfc3261, instead of IETF at that spot, it could say RFC?

[ronaldtse]

@rjsparks certainly. In the same line of thought, how about the "RFC subseries"? As "RFC subseries" or "RFC"?

[rjsparks]

"RFC subseries" (unless you know which subseries, such as BCP or STD, and then it would be better to use that)

[ronaldtse]

We certainly do know which subseries they are. So we will use BCP/STD/FYI then. Is it fair to call them "RFC {BCP,STD,FYI}" or just "{BCP,STD,FYI}", given that they are "subseries"?

[rjsparks]

Just the subseries name. BCP means something to the community. RFC BCP will be confusing.

[strogonoff]

@ronaldtse for the record, I am just removing type display from GUI entirely, so if we have type BCP and ID the number the user will see just the number.

[ronaldtse]

Thanks @strogonoff !