Citation formats for IETF published documents

ronaldtse commented 2 years ago

In a discussion with IETF and the IAB we have come up with the following citation guidance that complies with ISO 690.

We need to make sure that our Relaton-IETF data model supports all these metadata elements.

Citing RFCs

RFCs from IAB

"RFC SERIES. RFC 8128, IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee. MORGAN, C. Internet Architecture Board. RFC Publisher, March 2017."

(“RFC Series” is the “{standards body}”, “Internet Architecture Board” is the “{series}”)

RFCs from independent stream

"RFC SERIES. RFC 8216, HTTP Live Streaming. PANTOS, R. (ed), MAY, W. Independent Submission. RFC Publisher, August 2017."

(“RFC Series” is the “{standards body}”, “Independent Submission” is the “{series}”)

Others

From John Levine of IAB:

Keep in mind that many RFCs, including important ones like 791 (IP) and 793 (TCP) and 1034 and 1035 (the DNS) predate the IAB and IETF, so sometimes there will be no series info.

Citing Internet-Drafts

Versioned

"KUNZE, J. and E. BERMES. The ARK Identifier Scheme (draft-kunze-ark-22). Online. Internet-Draft. [work in progress]. Internet Engineering Task Force, June 22, 2019. [viewed 2020-10-05]."

Unversioned

"KUNZE, J. and E. BERMES. The ARK Identifier Scheme (draft-kunze-ark). Online. Internet-Draft. [work in progress]. Internet Engineering Task Force, June 22, 2019. [viewed 2020-10-05]."

ronaldtse commented 2 years ago

Once this is done we will need to update relaton-render.

opoudjis commented 1 year ago

ISO 690 insists on the contributor hierarchy:

author, editor, translator, publisher, distributor.

"RFC SERIES. RFC 8128, IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee. MORGAN, C. Internet Architecture Board. RFC Publisher, March 2017."

In this,

Morgan, C. is the personal author.
RFC Series, as the standards body, is the distributor (sponsoring body, which is how we have dealt with SDOs when they are not authors or publishers).
RFC Publisher is the publisher.

The sane solution is one of the following:

The SDO is the author, personal authors are not mentioned. That's what ISO does.
The SDO is the author, personal authors are mentioned. That's what I suspect people had in mind, but separating the corporate author from the personal author is not routine or good practice: this separation really does indicate that they should not both be considered authors. The only comparable instance I can think of is in the performing arts, where librettists and composers are separated according to editor preference; and that's not a great precedent.
The SDO is the publisher, personal authors are mentioned. But that's not what RFC wants either.
The SDO is the sponsor, personal authors are mentioned, there is a distinct author.

The last is what you're asking for. But putting the sponsor first, ahead of the author, is NOT ISO 690 practice; and it's only going to happen like this in relaton-ietf. Other flavours are actually going to respect ISO 690 practice.

Yes, once again, I'm saying no. But I don't see an alternative. Artificially differentiating corporate and personal authors, by showing them separately, is not a good idea.

So @andrew2net, this will be encoded as follows:

/contributor[@type = "author"]/person = Morgan, C.

/contributor[@type = "publisher"]/organization = RFC Publisher

/contributor[@type = "distributor"]/organization = RFC Series

I'm not discussing the IETF's decision to consider RFC Series a standards body, even though it has "Series" right in the title. The sane decision would be to allow two separate series, a series and a sub-series, but we're down the rabbit hole now.

ronaldtse commented 1 year ago

@opoudjis In ISO 690, sponsors always appear after the publisher, so the proposed solution 4 will not work.

Have you considered the following?

"RFC Series" is the "name of the standardization organization" (ISO 690 8.11.4.1). This element always appears first in a "Standards" citation in ISO 690.
The "Title" and "Reference number" are the next elements.
The personal authors are considered "Subsidiary creators" (ISO 690, 7.2.6.5), which appear after the Title. (NOTE we're actually missing Subsidiary creator in 8.11.4, which we should add.)
"RFC Publisher" is the publisher.

Here's the corresponding ISO 690 model:

"RFC SERIES. RFC 8128, IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee. MORGAN, C. Internet Architecture Board. RFC Publisher, March 2017."

Name of standardization organization: "RFC SERIES"
Title and reference number: "RFC 8128, IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee"
Subsidiary creators: "MORGAN, C."
Series: "Internet Architecture Board"
Publisher: "RFC Publisher"
Date: "March 2017"

opoudjis commented 1 year ago

"RFC Series" is the "name of the standardization organization" (ISO 690 8.11.4.1). This element always appears first in a "Standards" citation in ISO 690.

"name of the standardization organization" is meaningless in Relaton, and indeed in ISO 690. Contributors MUST, no exception, no excuse, no folderol, have a role as one of: author, editor, translator, publisher, distributor. At the time of authoring ISO 690, I assumed the SDO was the publisher. IETF have decided that there is a distinct publisher. Therefore the SDO becomes the distributor.

I can introduce a rule that the SDO is the publisher, or, if distributor and publisher are specified separately, the distributor. But there is no "name of the standardization organization" in relaton.

Do not get in the way of me realising a model-compliant solution.

"Subsidiary creators" also is meaningless in Relaton; and the intent of 7.2.6.5 is clear: subsidiary creators are, as the section is currently worded, the highest of expresser, editor, reviser, derivative creator (to use the wording of 7.2.2), as someone other than the author.

In the case of standards, you're making the primary creator now the distributor (which is assumed by default to be the publisher). That makes the (personal) author now the subsidiary creator, and it means that standards have a completely different hierarchy about who is and isn't a subsidiary creator.

opoudjis commented 1 year ago

What I have said to @andrew2net to model in Relaton does not change at all. But this does have an impact on relaton-render as well as on ISO 690.

opoudjis commented 1 year ago

Extensive productive discussion. Pan-out is still /contributor[@type = "distributor"]/organization/name = RFC Series, but let's define it explicitly in description. @ronaldtse, /contributor[@type = "distributor"][description = 'issuing body], /contributor[@type = "distributor"][description = 'authorising body]?

ronaldtse commented 1 year ago

As per: https://github.com/metanorma/iso-690/issues/20#issuecomment-1268617639

standards treat the "primary creators" as the "issuing body" or the "authorizing body".

in ISO 690 8.5.3 it mentions software being listed with the corporate body as the "publisher". It is actually not the "publisher", but a "commercially generated work whose authority lies in the corporate authorship" rather than individual creators.

In the case of the RFCs:

authorizing body: "RFC Series"
publisher: "RFC Publisher"

Are you trying to differentiate 'issuing body' vs 'authorizing body'? Don't understand your question.

opoudjis commented 1 year ago

No, I was asking which of the two we use.

OK, @andrew2net, this is now actionable. Let me know when you're done with this, so I can trigger https://github.com/relaton/relaton-render/issues/28

ronaldtse commented 1 year ago

/contributor[@type = "distributor"][description = 'issuing body']
/contributor[@type = "distributor"][description = 'authorising body']

I'm not convinced that:

The authorizing body is encoded as a "description".
That we should reuse 'type = distributor'

Why not make it a new contributor type?

opoudjis commented 1 year ago

@andrew2net not yet actionable.

opoudjis commented 1 year ago

@andrew2net Actionable:

/contributor[@type = "authorizer"]/organization/name = RFC Series

ronaldtse commented 1 year ago

OK

andrew2net commented 1 year ago

fixed in v 1.13.8 https://github.com/relaton/relaton-data-rfcs/blob/181eb36380728bd6570fac3383db20afce628069/data/RFC0001.yaml#L51-L60

rjsparks commented 1 year ago

This went wrong for us - publisher is not really welcome here - see https://github.com/ietf-tools/bibxml-service/issues/321

relaton / relaton-ietf