[low] RFC0 title, RFCs titles #15

New Issue

stiag · 2022-09-14T21:53:35Z

stiag commented

2022-09-14 21:53:35 +00:00

rfc0.md, Standard 1: RFC Format and Semantics has prefix "Standard 1" in its title but its filename is "rfc0.md" and it has "number: 0" in metadata.

I think there are 2 problems:

different numbering
"Standard X: " prefix.

RFCs other than RFC0 consistently do not contain title inside their text content, thus do not have such prefix anywhere in text.

RFC0 requires RFC titles to have prefix.

@southerntofu in #10 suggests pointing to registry where an RFC belongs to by using different registry names.

I suggest

either shorten prefix and use @southerntofu suggestion: TildeRFC0: ...
or remove prefix at all.

I'd go for removing prefixes:

RFC1-RFC3 do not use any prefix anywhere and it looks good
IETF's RFCs don't have any prefix.

If these thoughts are valid, RFC0's content and RFCs titles should be edited accordingly.

Prefix in title in RFC0's title starts numbering from 1. But everything else uses numbering that starts from 0. I suggest dropping numbering from 1.

RFCs will be counted from 0 and it's Ok. Besides, RFC0 is about RFCs.

Alternatively, there's an option to renumber everything from 1.

There's a chance that titles (that start from 1) and filenames/RFC numbers (that start from 0) were not linked deliberately to solve some problem. I cannot think of any currently.
This is a minor issue, so I'm not sure I'm doing right, but I'll tag @khuxkm.

[rfc0.md, Standard 1: RFC Format and Semantics](src/branch/master/rfcs/rfc0.md) has prefix "Standard 1" in its title but its filename is "rfc0.md" and it has "number: 0" in metadata. I think there are 2 problems: - different numbering - "Standard X: " prefix. --- RFCs other than RFC0 consistently do not contain title inside their text content, thus do not have such prefix anywhere in text. RFC0 requires RFC titles to have prefix. @southerntofu in #10 suggests pointing to registry where an RFC belongs to [by using different registry names](issues/10#issuecomment-2084). I suggest - either shorten prefix and use @southerntofu suggestion: `TildeRFC0: ...` - or remove prefix at all. I'd go for removing prefixes: - RFC1-RFC3 do not use any prefix anywhere and it looks good - IETF's RFCs don't have any prefix. If these thoughts are valid, RFC0's content and RFCs titles should be edited accordingly. --- Prefix in title in RFC0's title starts numbering from 1. But everything else uses numbering that starts from 0. I suggest dropping numbering from 1. RFCs will be counted from 0 and it's Ok. Besides, RFC0 is about RFCs. Alternatively, there's an option to renumber everything from 1. There's a chance that titles (that start from 1) and filenames/RFC numbers (that start from 0) were not linked deliberately to solve some problem. I cannot think of any currently. This is a minor issue, so I'm not sure I'm doing right, but I'll tag @khuxkm.

khuxkm commented

2022-09-20 16:44:52 +00:00

RFC 0 uses "Standard 1" in its title to set it off as a standard, as opposed to a simple request. RFC 0 itself makes the distinction clear, in my opinion:

RFC documents are simply requests. They are for simple things like defining how something should work or how something should be done.

Standards documents are like mandates. They require something. For example, this document requires a would-be submitter to follow this format for RFCs. A Standards document can be amended by RFC documents, and any RFC documents in violation of a Standards document, unless otherwise stated within the Standards document, are invalid.

RFC 0 is numbered 0 because it acts as a sort of proto-RFC, denoting what a tildeverse RFC is and how one should go about making one. Meanwhile, the Standards label starts with one, since it's the first standards document. IETF started their RFC numbering with one, and the first actual tildeverse RFC is... RFC 1: Remembering a Dear Friend Forever, which implemented the X-Clacks-Overhead header for the late abraxas.

IETF does have a Standards Track for RFCs, a system which could possibly be implemented in lieu of a "Standard" prefix in the title, but there's little incentive to change it now, given that, as I mentioned in #14, nobody uses the tildeverse RFC system anyways.

I would also be open to using southerntofu's proposed ~RFC name to set tildeverse RFCs apart from normal RFCs published by the IETF and other organizations, but that is a change to be made in the website software (and possibly through errata in RFC 0), and, again, nobody uses this system anyways, making it a moot point in my eyes.

RFC 0 uses "Standard 1" in its title to set it off as a standard, as opposed to a simple request. RFC 0 itself makes the distinction clear, in my opinion: > RFC documents are simply requests. They are for simple things like defining how something should work or how something should be done. > > Standards documents are like mandates. They require something. For example, this document requires a would-be submitter to follow this format for RFCs. A Standards document can be amended by RFC documents, and any RFC documents in violation of a Standards document, unless otherwise stated within the Standards document, are invalid. RFC 0 is numbered 0 because it acts as a sort of proto-RFC, denoting what a tildeverse RFC is and how one should go about making one. Meanwhile, the Standards label starts with one, since it's the first standards document. IETF started their RFC numbering with one, and the first actual tildeverse RFC is... [RFC 1: Remembering a Dear Friend Forever](https://rfc.tildeverse.org/rfcs/1), which implemented the X-Clacks-Overhead header for the late abraxas. IETF does have a Standards Track for RFCs, a system which could possibly be implemented in lieu of a "Standard" prefix in the title, but there's little incentive to change it now, given that, as I mentioned in #14, nobody uses the tildeverse RFC system anyways. I would also be open to using southerntofu's proposed `~RFC` name to set tildeverse RFCs apart from normal RFCs published by the IETF and other organizations, but that is a change to be made in the website software (and possibly through errata in RFC 0), and, again, nobody uses this system anyways, making it a moot point in my eyes.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tildeverse/rfcs#15