884 lines
35 KiB
Plaintext
884 lines
35 KiB
Plaintext
Bikeshedding Working Group ~lucidiot, Ed.
|
||
Request for Bikeshedding: 8 Bikeshedding Microsystems
|
||
Category: Standards Track July 19, 2022
|
||
|
||
|
||
Public Archive for Bikeshedding Microsystems
|
||
|
||
Abstract
|
||
|
||
This document introduces a public archive for all internal
|
||
publications of Bikeshedding Microsystems over the Git version
|
||
control software, providing a more convenient method to access
|
||
all Bikeshedding Microsystems documentation and offering more
|
||
transparency to our partners.
|
||
|
||
Status of This Memo
|
||
|
||
This is a Bikeshedding Standards Track document.
|
||
|
||
This document is a product of the Bikeshedding Working Group (BWG).
|
||
It represents the consensus of the bikeshedding community. It has
|
||
received public review and has been approved for publication by the
|
||
Bikeshedding Engineering Steering Group (BESG).
|
||
|
||
Information about the current status of this document, any errata,
|
||
and how to provide feedback on it may be obtained on the tildepals
|
||
mailing list.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2022 Bikeshedding Microsystems and the persons
|
||
identified as the document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the Bikeshedding Microsystems'
|
||
Legal Provisions Relating to Bikeshedding Documents in effect on the
|
||
date of publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 1]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction ..................................................3
|
||
1.1. Notational Conventions ..................................3
|
||
2. The Public Archive ............................................4
|
||
2.1. Archive Structure .......................................4
|
||
2.2. Archive Formats .........................................4
|
||
2.3. Archivists ..............................................5
|
||
2.4. Redaction ...............................................5
|
||
2.5. Migration Process .......................................6
|
||
3. Archival Requirements .........................................6
|
||
3.1. Bikeshed-Drafts .........................................6
|
||
3.2. Requests for Bikeshedding ...............................7
|
||
3.3. Bikeshedding Assigned Numbers Assignation and
|
||
Normalization Authority .................................7
|
||
3.4. Tildepals mailing list ..................................8
|
||
3.5. Commonhealth of Casakhstan ..............................8
|
||
3.6. Other Documents .........................................8
|
||
4. Legal Considerations ..........................................8
|
||
4.1. Global License ..........................................9
|
||
4.2. Non-binding Clauses .....................................9
|
||
4.3. License Updates .........................................9
|
||
4. Security Considerations .......................................9
|
||
5. Internationalization Considerations ..........................10
|
||
6. Privacy Considerations .......................................10
|
||
7. Interoperability Considerations ..............................10
|
||
8. Morality Considerations ......................................11
|
||
8.1. Likelihood of misuse by depraved or sick individuals ...11
|
||
8.2. Likelihood of misuse by misguided individuals ..........11
|
||
8.3. Likelihood of misuse by large, multi-national
|
||
corporations ...........................................11
|
||
8.4. Availability of oversight facilities ...................11
|
||
8.5. Inter-SDO impact .......................................12
|
||
8.6. Care and concern for avian carriers ....................12
|
||
9. BANANA Considerations ........................................12
|
||
10. References ...................................................13
|
||
10.1. Normative References ....................................13
|
||
10.2. Informative References ..................................14
|
||
Appendix A. Warranty Exclusion Statement ..........................14
|
||
Acknowledgements ..................................................15
|
||
Author's Address ..................................................15
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 2]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
1. Introduction
|
||
|
||
Over time, references to past Requests for Bikeshedding have been
|
||
harder to use as the access to their contents is heavily limited by
|
||
the tendency of emails to be deleted, or hidden under piles of other
|
||
emails. As Requests for Bikeshedding are mainly shared over email,
|
||
their contents can be lost to time. Newcomers to the Tildepals
|
||
mailing list may also be fully unaware of the existence of those
|
||
Requests for Bikeshedding.
|
||
|
||
While the Sympa mailing list software [SYMPA], used by the Tildepals
|
||
hosting provider Framalistes, provides ways to access the list's
|
||
archives all the way back to its creation, and the State of the
|
||
Tildepals documents mention this possibility, the user interface is
|
||
clunky at best and rapidly browsing emails to find the ones defining
|
||
a past Request for Bikeshedding is not possible.
|
||
|
||
These issues have been most recently noticed due to some discussions
|
||
over the conventions for email signatures, defined in [RFB1], and
|
||
over Web Feeds, defined in [RFB3], where most Bikeshedders did not
|
||
have any easy access to the standards or were unaware of their
|
||
existence. Additionally, some new users have joined the mailing list
|
||
while being fully unaware of the presence of Bikeshedding
|
||
Microsystems, the Requests for Bikeshedding system, the Commonhealth
|
||
of Casakhstan, or the Bikeshedding Assigned Numbers Assignation and
|
||
Normalization Authority.
|
||
|
||
This document establishes a public archive for all internal
|
||
publications of Bikeshedding Microsystems over the Git version
|
||
control software, providing a more convenient method to access
|
||
all Bikeshedding Microsystems documentation and offering more
|
||
transparency to our partners. It defines the archiving standards
|
||
for all relevant documents of Bikeshedding Microsystems, Tildepals
|
||
and the Commonhealth of Casakhstan, as well as a migration process
|
||
to fill the archive with the existing documents.
|
||
|
||
1.1. Notational Conventions
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
||
"OPTIONAL" in this document MUST be interpreted as described in
|
||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
|
||
capitals, as shown here.
|
||
|
||
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER",
|
||
"REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO",
|
||
"COULD", "POSSIBLE", and "MIGHT" in this document MUST be
|
||
interpreted as described in [RFC6919] (BUT WE KNOW YOU WON'T).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 3]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
2. The Public Archive
|
||
|
||
The Commonhealth of Casakhstan has already established in April 2021
|
||
a Gitea organization on the Gitea instance of the Tildeverse
|
||
[CASA-GIT], and has made its website available in a Git repository
|
||
hosted under this organization.
|
||
|
||
Bikeshedding Microsystems will establish its Public Archive in the
|
||
same organization, as all Bikeshedders of Bikeshedding Microsystems
|
||
and all members of Tildepals are residents of the Commonhealth of
|
||
Casakhstan. The Public Archive will be located in a Git repository
|
||
named "bikeshed", at <https://tildegit.org/casa/bikeshed/>.
|
||
|
||
2.1. Archive Structure
|
||
|
||
At the root of the Git repository, a README.md file MUST be present
|
||
and MUST describe the nature of the Public Archive and link to this
|
||
standard, or any currently applied standard should this standard be
|
||
obsoleted, for further information.
|
||
|
||
All archived documents MUST be preserved in sub-directories of the
|
||
repository. The exact structure of the sub-directories, and any
|
||
other directories those may contain, is left up to the Archivists.
|
||
|
||
2.2. Archive Formats
|
||
|
||
Archived documents SHOULD be stored in file formats that ensure their
|
||
long-term preservation as well as their ease of access. The below
|
||
paragraphs make recommendations to prefer specific formats, but the
|
||
best choice is always the format that all users of the archive,
|
||
present and future, will find the easiest to access, and that could
|
||
resist partial destruction or loss of their contents.
|
||
|
||
A README.md file near the relevant documents MUST describe the file
|
||
format and structure, and the means by which it can be read, if it
|
||
cannot be obviously guessed by the file extension or the apparent
|
||
structure of the document within the repository (BUT WE KNOW YOU
|
||
WON'T).
|
||
|
||
The RECOMMENDED file format for textual data is plain text, encoded
|
||
in UTF-8 [RFC3629]. Even in a binary format, all text SHOULD be
|
||
encoded using UTF-8 whenever possible. UNIX line endings SHOULD be
|
||
preferred, using line feeds and no carriage returns. Text files that
|
||
include formatting SHOULD be expressed using CommonMark [COMMONMARK]
|
||
or the HyperText Markup Language [HTML].
|
||
|
||
Structured data that can be represented in plain-text SHOULD use
|
||
Comma-Separated Values [RFC4180], Colon-Delimited Shit [RFB7],
|
||
JavaScript Object Notation [RFC8259], or Extensible Markup Language
|
||
[W3C-XML].
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 4]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
Structured data that is best represented as a relational database
|
||
SHOULD use the SQLite database file format (application/vnd.sqlite3)
|
||
[SQLITE].
|
||
|
||
2.3. Archivists
|
||
|
||
Any party allowed to make contributions to the Archive SHALL be
|
||
referred to as an Archivist. For the purposes of this title, a
|
||
contribution is considered a direct modification of the repository,
|
||
forks excluded, and not Gitea items such as issues or pull requests.
|
||
Archivists MAY include their title in their Tildepals email
|
||
signature, following the conventions set by [RFB1].
|
||
|
||
All members of the Gitea organization of the Commonhealth of
|
||
Casakhstan are Archivists. Residents of the Commonhealth of
|
||
Casakhstan, members of the Tildepals Mailing List, the m455.casa
|
||
Internet Relay Chat server, or Bikeshedders of Bikeshedding
|
||
Microsystems all may request access to the Commonhealth of
|
||
Casakhstan's Gitea organization by notifying any current member of
|
||
the organization, who all OUGHT TO have powers to invite others
|
||
to join.
|
||
|
||
2.4. Redaction
|
||
|
||
When the contents of a document could raise security or privacy
|
||
concerns, or for any other reason should not be published, Archivists
|
||
MAY decide to still publish the document to the Public Archive, after
|
||
redacting its problematic portions.
|
||
|
||
Redacted text SHOULD be replaced with the expression "[REDACTED]".
|
||
|
||
On media formats representing images, including videos, all pixels of
|
||
the problematic part of each image SHOULD be made completely black
|
||
(RGB hexadecimal code #000000).
|
||
|
||
Archivists REALLY SHOULD NOT use blurring, pixelating, or other
|
||
techniques that could potentially make the redacted content
|
||
recoverable. Archivists OUGHT TO take extra care to check that their
|
||
image editing tool does in fact replace all pixels with black, and
|
||
does not use other strange techniques such as reducing the brightness
|
||
to 0; basic tools such as GIMP or Paint will work correctly, but free
|
||
tools that are advertised specifically for redaction often should not
|
||
be trusted.
|
||
|
||
On media formats representing sound, the problematic portion of the
|
||
sound SHOULD be replaced with a beep tone (a sine wave a 1000 Hz).
|
||
|
||
On other document types that do not allow for proper redaction, the
|
||
problematic data MAY be deleted.
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 5]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
A README.md file next to the redacted document SHOULD mention its
|
||
redaction and the implications it can have on reading it. When the
|
||
redaction method does not make the redacted aspect explicit, the file
|
||
MUST mention the redaction.
|
||
|
||
2.5. Migration Process
|
||
|
||
The Public Archive SHOULD include all archivable documents that have
|
||
been created since the creation of the Tildepals mailing list, of
|
||
Bikeshedding Microsystems, of the m455.casa Internet Relay Chat
|
||
server, or of the Commonhealth of Casakhstan. The Public Archive
|
||
is not restricted to any document created after this standard goes
|
||
into effect. All Archivists are encouraged to find all previously
|
||
published archivable documents and add them to the Public Archive.
|
||
|
||
The implications of not following on any archival requirement for new
|
||
documents are left up to the Human Resources Department of
|
||
Bikeshedding Microsystems, the Commonhealth of Casakhstan, the
|
||
Protocol Police [RFC8962] or any relevant standard enforcement
|
||
authority. However, an authority MUST NOT execute any punitive
|
||
action against any party when an archivable document that have been
|
||
published before this standard went into effect cannot be archived,
|
||
did not follow the current archival requirements, or has been
|
||
archived with a long delay.
|
||
|
||
3. Archival Requirements
|
||
|
||
This section details the archival requirements for each category
|
||
of Bikeshedding Microsystems internal documents, or other documents
|
||
shared through the existing communication methods of Bikeshedding
|
||
Microsystems, of Tildepals or of the Commonhealth of Casakhstan.
|
||
|
||
3.1. Bikeshed-Drafts
|
||
|
||
All Bikeshed-Drafts SHOULD be placed under the `rfb/drafts/` path and
|
||
be stored in plain-text UTF-8 format.
|
||
|
||
Bikeshed-Drafts MAY be archived by their author at their discretion,
|
||
at any time and at any state of redaction, as they have no
|
||
standardizing effect.
|
||
|
||
When a Bikeshed-Draft is submitted to the Requests for Bikesheddings
|
||
Editor for review, it MUST be archived in the state it was submitted
|
||
in. Its 0-based draft number MUST then be incremented.
|
||
|
||
A Bikeshed-Draft that is archived by their author at any time MUST
|
||
follow the file name pattern `draft-<name>-<number>-<date>.txt`,
|
||
where <name> is the arbitrary name given to the draft in kebab-case,
|
||
<number> is the draft number with two digits, and <date> is the
|
||
date in [RFC3339] format. For example, this standard in its draft
|
||
form could have been archived as `draft-git-00-2022-07-16.txt`.
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 6]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
A Bikeshed-Draft that is archived at the time of its submission for
|
||
review MUST follow the file name pattern `draft-<name>-<number>.txt`,
|
||
with each placeholder having the same signification as above.
|
||
|
||
Should a Bikeshed-Draft require an attachment of some sort that is
|
||
in a file separate of the draft, including a LICENSE or README.md
|
||
file as required by other sections of this standard, then the draft
|
||
and all of its attachments SHOULD be placed in a sub-directory
|
||
following the same naming pattern, as `rfb/drafts/
|
||
draft-<name>-<number>[-<date>]/draft-<name>-<number>[-<date>].txt`.
|
||
|
||
3.2. Requests for Bikeshedding
|
||
|
||
All Requests for Bikeshedding SHOULD be placed under the `rfb/` path
|
||
and be stored in plain-text UTF-8 format. Each Request for
|
||
Bikeshedding MUST use a naming convention of `rfb<number>.txt`,
|
||
where <number> is the number of that RFB with no leading zeros.
|
||
|
||
Requests for Bikeshedding MUST be archived by the Requests for
|
||
Bikeshedding Editor at the time of their publication.
|
||
|
||
Should a Request for Bikeshedding require an attachment of some sort
|
||
that is in a file separate from the Request for Bikeshedding's text,
|
||
including a LICENSE or README.md file as required by other sections
|
||
of this standard, then the Request for Bikeshedding and all of its
|
||
attachments SHOULD be placed in a sub-directory following the same
|
||
naming pattern, `rfb/rfb<number>/rfb<number>.txt`.
|
||
|
||
The older, non-updated versions of Requests for Bikeshedding that
|
||
predate the standardization of their naming in [RFB2], then-called
|
||
Requests for Comments, MAY be archived as `rfc<number>` instead.
|
||
Their updated versions as RFBs MUST however also be archived.
|
||
|
||
3.3. Bikeshedding Assigned Numbers Assignation and Normalization
|
||
Authority
|
||
|
||
All assignations, registries and all other kinds of data managed by
|
||
the Bikeshedding Assigned Numbers Assignation and Normalization
|
||
Authority (BANANA) MUST be archived in the Public Archive, in their
|
||
current state of application. Any update to their contents MUST be
|
||
reflected by an update of the Public Archive. Archiving the updated
|
||
reports sent to the mailing list by the BANANA is OPTIONAL.
|
||
|
||
All archived documents of the Bikeshedding Assigned Numbers
|
||
Assignation and Normalization Authority MUST be kept under the
|
||
`banana/` subdirectory. The naming conventions and other
|
||
structures under this subdirectory are left up to the Archivists and
|
||
the Bikeshedding Assigned Numbers Assignation and Normalization
|
||
Authority Management and Administration Nominee (BANANA-MAN).
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 7]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
3.4. Tildepals mailing list
|
||
|
||
All archived documents related to the moderation, administration or
|
||
meta-information of the Tildepals mailing list MUST be kept under
|
||
the `tildepals/` subdirectory.
|
||
|
||
The Moderators of the Tildepals mailing list MUST archive their
|
||
State of the Tildepals monthly reports.
|
||
|
||
Personal information relating to the members of the mailing list
|
||
MUST be redacted following the conventions set in Section 2.4. Such
|
||
redaction MAY be skipped for specific members, shall they notify the
|
||
moderators of their intent to make their personal information public.
|
||
|
||
3.5. Commonhealth of Casakhstan
|
||
|
||
All archived documents relating to the Commonhealth of Casakhstan
|
||
MUST be kept under the `casakhstan/` subdirectory. The `casa/`
|
||
subdirectory MUST NOT be used, as it is reserved for later usage.
|
||
|
||
The Commonhealth of Casakhstan SHOULD name a Head Archivist to handle
|
||
the responsibilities of managing the Commonhealth's portion of public
|
||
archives and keep a backup copy of the Public Archive in paper form
|
||
in a proper long-term storage facility inside of the Ever Given.
|
||
|
||
3.6. Other Documents
|
||
|
||
The decision to make a Bikeshedding Microsystems, Tildepals, or
|
||
Commonhealth of Casakhstan internal document that does not belong
|
||
to other categories for which this standard, or any other subsequent
|
||
standard, have set explicit archival requirements, is left up to any
|
||
party involved in the making of the document.
|
||
|
||
Any party wishing to make a document public SHOULD CONSIDER
|
||
announcing their intent to all other involved parties, and waiting
|
||
for their explicit consent, before making any action.
|
||
|
||
4. Legal Considerations
|
||
|
||
All archived documents MUST have a license assigned to them.
|
||
Multiple licenses MAY apply throughout the repository, either by
|
||
being explicitly assigned to a single document or a specific set of
|
||
documents, or by dual-licensing. Each license MUST be suitable for
|
||
the type of document it applies to. Each license SHOULD conform to
|
||
the Open Definition [OPENDEF] or the Open Source Definition
|
||
[OSI-DEF].
|
||
|
||
The contents of any license currently in application for any
|
||
document MUST be made available in plain text format in a file named
|
||
"LICENSE", without any file extension, near the document or set of
|
||
documents that it applies to.
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 8]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
4.1. Global License
|
||
|
||
The whole Public Archive SHOULD be licensed under Creative Commons
|
||
Attribution-ShareAlike 4.0 International [CC-BY-SA]. This license
|
||
will be applied to all documents that do not have specific license
|
||
instructions applying to them.
|
||
|
||
At the root of the Git repository, a LICENSE file MUST be present
|
||
and must hold the contents of the currently applied LICENSE for the
|
||
whole Public Archive.
|
||
|
||
4.2. Non-binding Clauses
|
||
|
||
A README.md file near all Bikeshed-Drafts and Requests for
|
||
Bikeshedding documents MUST note that the mention "Bikeshedding
|
||
Microsystems' Legal Provisions Relating to Bikeshedding Documents",
|
||
present at the beginning of all Bikeshed-Drafts and Requests for
|
||
Bikeshedding, points to the currently applied LICENSE file.
|
||
|
||
A similar rule should apply for any other archived documents that
|
||
include mentions that could be taken as legally binding, but only
|
||
exist for the purpose of entertainment.
|
||
|
||
4.3. License Updates
|
||
|
||
Changes to the license of a document after its publication, and
|
||
especially changes to the global license of the Public Archive,
|
||
SHOULD only be done once they represent the consensus of the
|
||
Archivists.
|
||
|
||
5. Security Considerations
|
||
|
||
Some archived documents may include sensitive content that could give
|
||
out classified information on the activity of the persons or entities
|
||
mentioned in the document. Such information could help an attacker
|
||
learn more about their target, or as the archives can be publicly
|
||
accessed over HTTP or Git, be automatically found by crawler-type
|
||
bots and used in automated attacks.
|
||
|
||
Archivists MUST take great care in ensuring such confidential
|
||
information is redacted, as described in Section 2.4, before any
|
||
document is archived.
|
||
|
||
As Git hosting services such as Gitea, and even Git repositories
|
||
themselves, often still keep some metadata on any activity that
|
||
occurred within them, documents that could possibly contain
|
||
confidential information and that have not yet been properly redacted
|
||
REALLY SHOULD NOT be mentioned on the Gitea issues, pull requests,
|
||
wiki pages or other publicly visible Gitea systems, and MUST NOT be
|
||
pushed on the Git repository in any way.
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 9]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
If such an unredacted document gets accidentally mentioned or sent to
|
||
the Public Archive, all Archivists MUST use as many precautions as
|
||
possible to erase its existence from the Gitea repository and Git
|
||
repository.
|
||
|
||
6. Internationalization Considerations
|
||
|
||
As the Public Archives of Bikeshedding Microsystems are expected to
|
||
mostly hold text, most of the issues with internationalization will
|
||
stem from text encoding. Section 2.2 recommends the use of Unicode,
|
||
specifically the UTF-8 encoding [RFC3629], to try to avoid those
|
||
issues.
|
||
|
||
7. Privacy Considerations
|
||
|
||
As discussed in Section 5, documents for archival could include
|
||
sensitive information. Sensitive information can also include data
|
||
that can cause privacy-related issues.
|
||
|
||
Archivists MUST take great care in ensuring that personal
|
||
information is redacted, as described in Section 2.4, before any
|
||
document is archived, unless the person this personal information
|
||
belongs to explicitly consents to their information being made
|
||
public.
|
||
|
||
The same non-disclosure rules as in Section 5 apply to personal
|
||
information. When such a disclosure occurs despite any preventive
|
||
measures, the Archivists MUST notify any parties whose data has been
|
||
disclosed and apply the corrective measures described in Section 5.
|
||
|
||
Section 3.4 of this standard specifically addresses this concerns
|
||
for the list of the Tildepals mailing list members.
|
||
|
||
8. Interoperability Considerations
|
||
|
||
Interoperability issues could occur if the Public Archives includes
|
||
archived documents in formats that are not recommended for archival.
|
||
Section 2.2 includes some recommendations for the most common forms
|
||
of archived documents. Archivists MAY also rely on the
|
||
recommendations of any archiving bodies such as the Library of
|
||
Congress, the French National Library, etc.
|
||
|
||
Section 2.2 requires the documentation of unexpected, unrecommended
|
||
formats in a README file to properly handle the issues of the varied
|
||
data types that could enter the Public Archive.
|
||
|
||
Any interoperability issues that come from improper implementations
|
||
of software accessing the Public Archive, or of the software powering
|
||
the Gitea instance and Git repository of the Public Archive, are left
|
||
up to the Protocol Police [RFC8962].
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 10]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
9. Morality Considerations
|
||
|
||
This section contains morality considerations consistent with the
|
||
demands of [RFC4041].
|
||
|
||
9.1. Likelihood of misuse by depraved or sick individuals
|
||
|
||
RFC 4041 describes this section as the use of the Public Archive to
|
||
distribute blue, smutty or plain disgusting images. The Public
|
||
Archive relies on the Commonhealth of Casakhstan's management of the
|
||
Gitea organization to determine who can be trusted to be an
|
||
Archivist, and therefore publish to the Public Archive.
|
||
|
||
As anyone with an account on the Gitea instance can create issues,
|
||
pull requests, or write comments on the Git repository due to it
|
||
being public, this portion of the morality of the Public Archive
|
||
also relies on the moderation policy of the administrators and
|
||
moderators of the Tildegit instance.
|
||
|
||
9.2. Likelihood of misuse by misguided individuals
|
||
|
||
Users of the Public Archive are only likely receive harm from its use
|
||
if the Archivists do not apply due judgment in which types of
|
||
content they publish, especially in an event described by
|
||
Section 9.1. Such issues are left up to the self-moderation already
|
||
applied by the Tildepals and Casakhstani community as a whole.
|
||
|
||
9.3. Likelihood of misuse by large, multi-national corporations
|
||
|
||
This standard establishes a Creative Commons Attribution-ShareAlike
|
||
4.0 International license over the Public Archive, in an attempt to
|
||
force the legal departments of such large, multi-national
|
||
corporations to stop or change the use of the documents held in the
|
||
Public Archive.
|
||
|
||
Additionally, most of the activity of Bikeshedding Microsystems can
|
||
be harmful to other companies when applied untactfully, as
|
||
bikeshedding can lead to nuclear reactors being poorly built and
|
||
causing safety hazards, and bike sheds being repainted once a day.
|
||
|
||
9.4. Availability of oversight facilities
|
||
|
||
By the Public Archive's quality of being Public, most encryption and
|
||
obfuscation techniques, with the exception of redaction as specified
|
||
in Section 2.4, are removed. This can give the relevant authorities
|
||
enough power to guarantee that only the Archivists that have nothing
|
||
to hide will take part in the Public Archive.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 11]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
As the Public Archive is only meant to receive documents that come
|
||
from the Commonhealth of Casakhstan and the Casakhstan-adjacent
|
||
communities, all oversighting authorities will have access to the
|
||
original internal documents before their redaction, cancelling the
|
||
obfuscation possibilities of Section 2.4.
|
||
|
||
9.5. Inter-SDO impact
|
||
|
||
Although the Requests for Bikesheddings Editor has no power other
|
||
other standards development organizations, they are RECOMMENDED to
|
||
also send their Casakhstan-related standards to the Public Archives.
|
||
|
||
External submissions can be made through Gitea's pull requests
|
||
system by forking the Git repository of the Public Archive, and
|
||
SHOULD be reviewed impartially by the Archivists, following the same
|
||
standards as for internal documents. Any negative feelings expressed
|
||
by Archivists against other standards development organizations MUST
|
||
be pushed aside, and the historical significance of the submitted
|
||
documents SHALL prevail.
|
||
|
||
9.6. Care and concern for avian carriers
|
||
|
||
The Internet Engineering Task Force only has standardized the use of
|
||
avian carriers for the Internet Protocol [RFC1149] [RFC2549]. This
|
||
protocol was already used for the transfer over email of the internal
|
||
documents that will now be archived on the Public Archive.
|
||
|
||
As Bikeshedding Microsystems has not yet received any reports of a
|
||
birb being hurt during the transportation of its internal documents
|
||
over IP over Avian Carriers, both with and without Quality of
|
||
Service, there are no legitimate reasons to believe any additional
|
||
birbs could be hurt by the Public Archive.
|
||
|
||
As a precaution, Archivists SHOULD take any necessary measures,
|
||
including temporarily suspending the Public Archive project, should
|
||
any birb accident occur that is directly caused by the Public
|
||
Archive.
|
||
|
||
10. BANANA Considerations
|
||
|
||
Section 3.3 documents the new archival requirements defined for the
|
||
BANANA's assignations, registries, monthly reports and other data.
|
||
|
||
No new values are added to the BANANA registries. Existing values
|
||
MAY be redacted by the BANANA, following Section 2.4, if their
|
||
archival violates Section 5 or Section 7.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 12]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
11. References
|
||
|
||
11.1. Normative References
|
||
|
||
[CC-BY-SA] Creative Commons, "Attribution-ShareAlike 4.0
|
||
International (CC BY-SA 4.0)", November 2013,
|
||
<https://creativecommons.org/licenses/by-sa/4.0/>.
|
||
|
||
[COMMONMARK] MacFarlane, J., "CommonMark Spec", Version 0.30,
|
||
June 2021, <https://spec.commonmark.org/0.30/>.
|
||
|
||
[OPEN-DEF] Open Definition, "Open Definition 2.1", November 2015,
|
||
<https://opendefinition.org/od/2.1/en/>.
|
||
|
||
[OSI-DEF] Open Source Initiative, "The Open Source Definition",
|
||
Version 1.9, March 2007, <https://opensource.org/osd>.
|
||
|
||
[RFB1] ~lucidiot, "Tildepals Email Signatures for
|
||
Bikeshedders", RFB 1, March 2021.
|
||
|
||
[RFB2] ~lucidiot, "Ensuring Compatibility between The
|
||
Bikeshedding Company and Internet Engineering Task
|
||
Force Standards", RFB 2, April 2021.
|
||
|
||
[RFB3] ~lucidiot, "Web Feeds (WEED)", RFB 3, April 2021.
|
||
|
||
[RFB7] ~lucidiot, "The Colon Delimited Shit Format", RFB 7,
|
||
August 2021.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119,
|
||
DOI 10.17487/RFC2119, March 1997,
|
||
<https://www.rfc-editor.org/info/rfc2119>.
|
||
|
||
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the
|
||
Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339,
|
||
July 2002, <https://www.rfc-editor.org/info/rfc3339>.
|
||
|
||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
||
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
|
||
November 2003,
|
||
<https://www.rfc-editor.org/info/rfc3629>.
|
||
|
||
[RFC4041] Farrel, A., "Requirements for Morality Sections in
|
||
Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041,
|
||
April 2005, <https://www.rfc-editor.org/info/rfc4041>.
|
||
|
||
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for
|
||
Comma-Separated Values (CSV) Files", RFC 4180,
|
||
DOI 10.17487/RFC4180, October 2005,
|
||
<https://www.rfc-editor.org/info/rfc4180>.
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 13]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key
|
||
Words for Use in RFCs to Indicate Requirement Levels",
|
||
RFC 6919, DOI 10.17487/RFC6919, April 1 2013,
|
||
<https://www.rfc-editor.org/info/rfc6919>.
|
||
|
||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
|
||
2119 Key Words", BCP 14, RFC 8174,
|
||
DOI 10.17487/RFC8174, May 2017,
|
||
<https://www.rfc-editor.org/info/rfc8174>.
|
||
|
||
|
||
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON)
|
||
Data Interchange Format", STD 90, RFC 8259,
|
||
DOI 10.17487/RFC8259, December 2017,
|
||
<https://www.rfc-editor.org/info/rfc8259>.
|
||
|
||
[RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S.,
|
||
"Establishing the Protocol Police", RFC 8962,
|
||
DOI 10.17487/RFC8962, April 1 2021,
|
||
<https://www.rfc-editor.org/info/rfc8962>.
|
||
|
||
[SQLITE] SQLite, "Database File Format",
|
||
<https://www.sqlite.org/fileformat.html>.
|
||
|
||
[HTML] Web Hypertext Application Technology Working Group,
|
||
"HTML Living Standard",
|
||
<https://html.spec.whatwg.org/multipage/>.
|
||
|
||
[W3C-XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
|
||
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
|
||
REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
|
||
|
||
11.2. Informative References
|
||
|
||
[CASA-GIT] Tildegit, "Commonhealth of Casakhstan", April 2021,
|
||
<https://tildegit.org/casa>.
|
||
|
||
[RFC1149] Waitzman, D., "Standard for the transmission of IP
|
||
datagrams on avian carriers", RFC 1149,
|
||
DOI 10.17487/RFC1149, April 1 1990,
|
||
<https://www.rfc-editor.org/info/rfc1149>.
|
||
|
||
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of
|
||
Service", RFC 2549, DOI 10.17487/RFC2549, April 1 1999,
|
||
<https://www.rfc-editor.org/info/rfc2549>.
|
||
|
||
Appendix A. Warranty Exclusion Statement
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and M455.CASA DISCLAIMS ALL WARRANTIES, EXPRESS OR
|
||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
|
||
|
||
~lucidiot Standards Track [Page 14]
|
||
|
||
RFB 8 Public Archive July 2022
|
||
|
||
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgements
|
||
|
||
The author would like to thank all subscribers of tildepals for
|
||
participating in, or at least putting up with, the Bikeshedding
|
||
Company's bikeshedding activities, and most importantly thank
|
||
themselves for existing and bringing such great shitposts to the
|
||
greater community.
|
||
|
||
The author would also like to thank the administrators of the
|
||
Tildegit Gitea instance for their generous offering of hosting the
|
||
Bikeshedding Microsystems Public Archive.
|
||
|
||
The author is additionally grateful about the existence of a
|
||
Wikipedia article on RFCs published on April 1st of each year, as
|
||
they provide for an endless source of unnecessary text in RFBs.
|
||
|
||
Author's Address
|
||
|
||
~lucidiot (editor)
|
||
Bikeshedding Microsystems
|
||
m455.casa
|
||
138.197.184.222
|
||
The Internet
|
||
|
||
Email: lucidiot@brainshit.fr
|
||
URI: https://tilde.town/~lucidiot/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
~lucidiot Standards Track [Page 15] |