-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IETF series is mislabeled #59
Comments
@rjsparks thanks for the clarification. @strogonoff could you help handle this? Thanks. |
@ronaldtse BibXML does not come up with its own identifiers, it exposes values of |
Should probably be moved to |
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?
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. |
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" |
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? |
@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 |
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. |
@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)
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). |
@strogonoff the the Relaton model series is stored in the item = RelatonIetf::IetfBibliography.search "RFC 8341"
series = item.series.detect { |s| s.title.title.content == "RFC" }
series.title.title.content
=> "RFC"
series.number
=> "8341" |
That’s good to know. Anyway, I believe at this point we have organizational reason to switch |
This looks like bibliographic source data related matter, and should probably be moved to respective repository. |
@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
What repository are you talking about? |
If 1) I raised the question on what
No idea. Definitely not this one. |
RFCs produced by the IETF cover many aspects of computer networking. |
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 |
Conclusion: we will use "RFC" as the |
Let's continue non-IETF related debates here: relaton/relaton-ietf#36 . IETF has stated their decisions and we will follow. |
@ronaldtse maybe I misused the terminology. The ISO document is on the IETF site. We use the |
@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.
|
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). |
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.) |
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. |
@rjsparks apologies for having this discussion publicly -- we've already reached an internal consensus that aligns with your guidance.
|
Just Internet-Draft - again, these things come from irtf, iab, random people, etc. |
Thank you @rjsparks for the clarification. Just "Internet-Draft" then. |
@rjsparks do you see any remaining issues here? Thanks. |
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). |
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 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. |
@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. |
How about we change the "IETF identifier label" to say "Internet-Draft"? That would solve the confusion. |
That would be awesome. |
@rjsparks certainly. In the same line of thought, how about the "RFC subseries"? As "RFC subseries" or "RFC"? |
"RFC subseries" (unless you know which subseries, such as BCP or STD, and then it would be better to use that) |
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"? |
Just the subseries name. |
@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. |
Thanks @strogonoff ! |
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.
The text was updated successfully, but these errors were encountered: