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 .
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---.txt`,
where is the arbitrary name given to the draft in kebab-case,
is the draft number with two digits, and 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--.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--[-]/draft--[-].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.txt`,
where 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/rfb.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` 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,
.
[COMMONMARK] MacFarlane, J., "CommonMark Spec", Version 0.30,
June 2021, .
[OPEN-DEF] Open Definition, "Open Definition 2.1", November 2015,
.
[OSI-DEF] Open Source Initiative, "The Open Source Definition",
Version 1.9, March 2007, .
[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,
.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339,
July 2002, .
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
November 2003,
.
[RFC4041] Farrel, A., "Requirements for Morality Sections in
Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041,
April 2005, .
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for
Comma-Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
.
~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,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON)
Data Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
.
[RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S.,
"Establishing the Protocol Police", RFC 8962,
DOI 10.17487/RFC8962, April 1 2021,
.
[SQLITE] SQLite, "Database File Format",
.
[HTML] Web Hypertext Application Technology Working Group,
"HTML Living Standard",
.
[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, .
11.2. Informative References
[CASA-GIT] Tildegit, "Commonhealth of Casakhstan", April 2021,
.
[RFC1149] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149,
DOI 10.17487/RFC1149, April 1 1990,
.
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of
Service", RFC 2549, DOI 10.17487/RFC2549, April 1 1999,
.
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]