casa/bikeshed
casa
/
bikeshed
9
0
Fork 0
Code Issues Pull Requests Releases Activity

Add most past documents

This commit is contained in:
~lucidiot 2022-07-19 21:56:21 +02:00
parent 75063f88c3
commit 135b987d43
39 changed files with 15056 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
banana/ads.txt Normal file
View File

@ -0,0 +1,9 @@
Company-Approved Advertisements
Advertisements for Bikeshedding Microsystems that may be inserted by
Bikeshedders in their email signatures, depending on the Advertisement
Directives published by the Marketing Division. The Marketing Division
is the sole change controller for this registry and may change it at any
time with notice. Defined by RFB 1.
This registry is empty.

27
banana/media-types/text/vnd.bikeshed.signature.txt Normal file
View File

@ -0,0 +1,27 @@
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: N/A
Optional parameters: charset
Encoding considerations: Prefer UTF-8. See section 3 of [RFB1].
Security considerations: See section 7 of [RFB1].
Interoperability considerations: TBD
Published specification: [RFB1]
Applications that use this media type: N/A
Additional information:
- Magic numbers: 2d 2d 20 0a
See Section 3 of [RFB1].
- File extension(s): N/A
- Macintosh file type code(s): N/A
- Fragment identifier considerations: N/A
Person & email address to contact for further information: ~lucidiot
Intended usage: LIMITED USE
Use of this format SHOULD be restricted to bikeshedding activities.
Restrictions on usage: Bikeshedding
Author: ~lucidiot
Change controller: ~lucidiot
Provisional registration: No
[RFB1]: ~lucidiot, "Tildepals Email Signatures for Bikeshedders",
RFB 1, March 2021.

26
banana/media-types/text/vnd.unix.cds.txt Normal file
View File

@ -0,0 +1,26 @@
Type name: text
Subtype name: vnd.unix.cds
Required parameters: N/A
Optional parameters: charset
Encoding considerations: Prefer UTF-8. See Section 5 of [RFB7].
Security considerations: See Section 4 of [RFB7].
Interoperability considerations: See Section 7 of [RFB7].
Published specification: [RFB7]
Applications that use this media type: Most UNIX systems.
See Section 3 of [RFB7].
Additional information:
- Deprecated alias names for this type: N/A
- Magic numbers: N/A
- File extension(s): N/A
- Macintosh file type code(s): TEXT
Person & email address to contact for further information: ~lucidiot
Intended usage: COMMON
Restrictions on usage: N/A
Author: ~lucidiot
Change controller: ~lucidiot
Provisional registration: No
[RFB7]: ~lucidiot, "The Colon Delimited Shit Format", RFB 7,
August 2021.

303
banana/report-2021-07.txt Normal file
View File

@ -0,0 +1,303 @@
Bikeshedding Microsystems
Bikeshedding Assigned Numbers Assignation and Normalization Authority
BANANA Registries Report
July 1, 2021
------------------------------------------------------------------------
Status of this Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Bikeshedding Assigned Numbers
Assignation and Normalization Authority. It represents a summary of the
state of all the registries and assignations maintainted by the BANANA.
It has been approved for publication by the Bikeshedding Engineering
Steering Group (BESG). Not all documents approved by the BESG are a
candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained on the Tilde
Pals mailing list.
------------------------------------------------------------------------
List of Registries
Registry Name Definition
------------------------------------------------------------ ----------
Company-Approved Advertisements [RFB1]
E-mail Signature Protocol Abbreviations [RFB1]
Known Weeds [RFB3]
Media Types [BCP13]
------------------------------------------------------------------------
Company-Approved Advertisements
Advertisements for Bikeshedding Microsystems that may be inserted by
Bikeshedders in their email signatures, depending on the Advertisement
Directives published by the Marketing Division. The Marketing Division
is the sole change controller for this registry and may change it at any
time with notice. Defined by RFB 1.
This registry is empty.
------------------------------------------------------------------------
E-mail Signature Protocol Abbreviations
Abbreviations that may be used for alternative protocols in the e-mail
signatures of Bikeshedders. This registry is maintained by ~lucidiot,
Designated Expert by interim. The Designated Expert can change this
registry at any time with notice, and Bikeshedders can submit assignment
requests to the Designated Expert. Defined by RFB 1.
Abbreviation Protocol References
------------ ---------------------------------------------- ----------
ATOM Atom Syndication Format [RFC4287]
CDF Channel Definition Format [CDF]
[CDF-W3C]
Discord Discord [DISCORD]
Fedi ActivityPub [APUB]
Gopher Internet Gopher Protocol [RFC1436]
Gemini Project Gemini [GEMINI]
HINA Asahina Antenna Metadata Format 2.2 [RFB5]
HTTP Hypertext Transfer Protocol [RFC7230]
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
IRC Internet Relay Chat [RFC1459]
[RFC2810]
[RFC2811]
[RFC2812]
[RFC2813]
[RFC7194]
JSON Feed JSON Feed 1.1 [JSONFEED]
LIRS Last-modified Information Relaying [RFB4]
Specification
MSN Microsoft Notification Protocol [MSNP]
RSS RDF Site Summary [RSS1]
RSS1
RSS Really Simple Syndication [RSS2]
RSS2
twtxt twtxt [TWTXT]
WEED Web Feeds [RFB3]
XMPP Extensible Messaging and Presence Protocol [RFC6120]
[RFC6121]
[RFC7622]
[RFC3923]
------------------------------------------------------------------------
Known Weeds
Any Bikeshedder can create new values by submitting a request to the
BANANA. Only the Change Controller of a value can update or remove it.
Defined by RFB 3.
URL Format Change Controller
--------------------------------------------- ------ -----------------
[REDACTED] RSS2 ~dozens
[REDACTED] RSS2 ~lucidiot
[REDACTED] ATOM ~acdw
------------------------------------------------------------------------
Media Types
This registry has been created by the Internet Engineering Task Force
and is managed by the Internet Assigned Numbers Authority. The BANANA
maintains the additional values specific to Bikeshedding Microsystems,
as per the compatibility rules of RFB 2. Defined in BCP 13.
## text/vnd.bikeshed.signature
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: n/a
Optional parameters: charset
Encoding considerations: Prefer UTF-8. See section 3 of [RFB1].
Security considerations: See section 7 of [RFB1].
Interoperability considerations: TBD
Published specification: [RFB1]
Applications that use this media type: n/a
Additional information:
- Magic numbers: 2d 2d 20 0a
See Section 3 of [RFB1].
- File extension(s): n/a
- Macintosh file type code(s): n/a
- Fragment identifier considerations: n/a
Person & email address to contact for further information: ~lucidiot
Intended usage: Limited Use
Use of this format SHOULD be restricted to bikeshedding activities.
Restrictions on usage: Bikeshedding
Author: ~lucidiot
Change controller: ~lucidiot
------------------------------------------------------------------------
Changelog
April 4, 2021
First version of this report.
June 30, 2021
Applied BANANA Considerations from RFB 4:
- The reference for the LIRS E-mail Signature Protocol Abbreviation
has been updated to RFB 4.
July 1, 2021
Applied BANANA Considerations from RFB 5:
- The reference for the HINA E-mail Signature Protocol Abbreviation
has been updated to RFB 5.
------------------------------------------------------------------------
References
[APUB]: Lemmer Webber, C., Tallon, J., Shepherd, E., Guy, A.,
Prodromou, E., "ActivityPub", W3C Recommendation, January 2018,
<https://www.w3.org/TR/activitypub/>.
[BCP13]:
Freed, N., Klensin, J., "Multipurpose Internet Mail Extensions (MIME)
Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
Freed, N., Klensin, J., Hansen, T., "Media Type Specifications and
Registration Procedures", BCP 13, RFC 6838, January 2013.
<https://www.rfc-editor.org/info/bcp13>
[CDF]: Microsoft, "CDF Reference for Active Channels", August 2017,
<https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa768139(v=vs.85)>.
[CDF-W3C]: Ellerman, C., "Channel Definition Format (CDF)", W3C Note
NOTE-CDFsubmit, March 1997, <https://www.w3.org/TR/NOTE-CDFsubmit.html>.
[DISCORD]: Discord, "Discord", May 2015, <https://discord.com>.
[GEMINI]: Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020,
<gemini://gemini.circumlunar.space/docs/specification.gmi>.
[HINA]: kohgushi, "Asahina-Antenna meta data format version 2.2
(HINA/2.2)", Revision 0.13, July 2002,
<https://envs.net/~lucidiot/hina/hina2_2-rev0_13.html>.
[MSNP]: Mintz, M., Sayers, A., "MSN Messenger Protocol", December 2003,
<http://www.hypothetic.org/docs/msn/>.
[NOTADRAFT]: Kumari, W., "Just because it's an ID doesn't mean
anything... at all...", Work In Progress, draft-wkumari-not-a-draft-10,
July 2020.
[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", RFB 3, April 2021.
[RFB4]: ~lucidiot, "Last-modified Information Relaying Specification
(LIRS) 2.1", RFB 4, June 2021.
[RFB5]: ~lucidiot, "Asahina Antenna Metadata Format (HINA) 2.2
revision 0.13", RFB 5, July 2021.
[RFC1436]: Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol (a distributed
document search and retrieval protocol)", RFC 1436,
DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC1459]: Oikarinen, J., Reed, D., "Internet Relay Chat Protocol",
RFC 1459, DOI 10.17847/RFC1459, May 1993,
<https://www.rfc-editor.org/info/rfc1459>.
[RFC2810]: Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17847/RFC2810, April 2000,
<https://www.rfc-editor.org/info/rfc2810>.
[RFC2811]: Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, DOI 10.17847/RFC2811, April 2000,
<https://www.rfc-editor.org/info/rfc2811>.
[RFC2812]: Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
DOI 10.17847/RFC2812, April 2000,
<https://www.rfc-editor.org/info/rfc2812>.
[RFC2813]: Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813,
DOI 10.17847/RFC2813, April 2000,
<https://www.rfc-editor.org/info/rfc2813>.
[RFC3923]: Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923,
DOI 10.17847/RFC3923, October 2004,
<https://www.rfc-editor.org/info/rfc3923>.
[RFC4287]: Nottingham, M., Sayre, R., "The Atom Syndication Format",
RFC 4287, DOI 10.17487/RFC4287, December 2005,
<https://www.rfc-editor.org/info/rfc4287>.
[RFC6120]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Core", RFC 6120, DOI 10.17847/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6121]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17847/RFC6121,
March 2011, <https://www.rfc-editor.org/info/rfc6121>.
[RFC7194]: Hartmann, R., "Default Port for Internet Relay Chat (IRC)
via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194, August 2014,
<https://www.rfc-editor.org/info/rfc7194>.
[RFC7230]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230,
June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231,
June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7232]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232,
June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233]: Fielding, R., Lafon, Y., Reschke, J., "Hypertext Transfer
Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233,
June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7234]: Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234,
June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7235]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7622]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Address Format", RFC 7622, DOI 10.17847/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
[RSS1]: Beged-Dov, G., Brickley, D., Dornfest, R., Davis, I., Dodds,
L., Eisenzopf, J., Galbraith, D., Guha, R. V., MacLeod, K., Miller, E.,
Swartz, A. and E. van der Vlist, "RDF Site Summary (RSS) 1.0",
December 2000, <http://purl.org/rss/1.0/spec>.
[RSS2]: RSS Advisory Board, "RSS 2.0 Specification", Version 2.0.11,
March 2009, <https://www.rss-board.org/rss-specification>.
[JSONFEED]: Simmons, B. and M. Reece, "JSON Feed Version 1.1",
August 2020, <https://jsonfeed.org/version/1.1>.
[TWTXT]: buckket, "twtxt Documentation", September 2017,
<https://twtxt.readthedocs.io/>.

365
banana/report-2021-08.txt Normal file
View File

@ -0,0 +1,365 @@
Bikeshedding Microsystems
Bikeshedding Assigned Numbers Assignation and Normalization Authority
BANANA Registries Report
August 5, 2021
------------------------------------------------------------------------
Status of this Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Bikeshedding Assigned Numbers
Assignation and Normalization Authority. It represents a summary of the
state of all the registries and assignations maintainted by the BANANA.
It has been approved for publication by the Bikeshedding Engineering
Steering Group (BESG). Not all documents approved by the BESG are a
candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained on the Tilde
Pals mailing list.
------------------------------------------------------------------------
List of Registries
Registry Name Definition
------------------------------------------------------------ ----------
Company-Approved Advertisements [RFB1]
E-mail Signature Protocol Abbreviations [RFB1]
Known Weeds [RFB3]
Unit Prefixes [RFB6]
Media Types [BCP13]
------------------------------------------------------------------------
Company-Approved Advertisements
Advertisements for Bikeshedding Microsystems that may be inserted by
Bikeshedders in their email signatures, depending on the Advertisement
Directives published by the Marketing Division. The Marketing Division
is the sole change controller for this registry and may change it at any
time with notice. Defined by RFB 1.
This registry is empty.
------------------------------------------------------------------------
E-mail Signature Protocol Abbreviations
Abbreviations that may be used for alternative protocols in the e-mail
signatures of Bikeshedders. This registry is maintained by ~lucidiot,
Designated Expert by interim. The Designated Expert can change this
registry at any time with notice, and Bikeshedders can submit assignment
requests to the Designated Expert. Defined by RFB 1.
Abbreviation Protocol References
------------ ---------------------------------------------- ----------
ATOM Atom Syndication Format [RFC4287]
CDF Channel Definition Format [CDF]
[CDF-W3C]
Discord Discord [DISCORD]
Fedi ActivityPub [APUB]
Gopher Internet Gopher Protocol [RFC1436]
Gemini Project Gemini [GEMINI]
HINA Asahina Antenna Metadata Format 2.2 [RFB5]
HTTP Hypertext Transfer Protocol [RFC7230]
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
IRC Internet Relay Chat [RFC1459]
[RFC2810]
[RFC2811]
[RFC2812]
[RFC2813]
[RFC7194]
JSON Feed JSON Feed 1.1 [JSONFEED]
LIRS Last-modified Information Relaying [RFB4]
Specification
MSN Microsoft Notification Protocol [MSNP]
RSS RDF Site Summary [RSS1]
RSS1
RSS Really Simple Syndication [RSS2]
RSS2
twtxt twtxt [TWTXT]
WEED Web Feeds [RFB3]
XMPP Extensible Messaging and Presence Protocol [RFC6120]
[RFC6121]
[RFC7622]
[RFC3923]
------------------------------------------------------------------------
Known Weeds
Any Bikeshedder can create new values by submitting a request to the
BANANA. Only the Change Controller of a value can update or remove it.
Defined by RFB 3.
URL Format Change Controller
--------------------------------------------- ------ -----------------
[REDACTED] RSS2 ~dozens
[REDACTED] RSS2 ~lucidiot
[REDACTED] ATOM ~acdw
------------------------------------------------------------------------
Unit Prefixes
Unit prefixes that extend or replace SI prefixes within Bikeshedding
Microsystems communications. New entries may be added to this registry
only by publishing a new Request for Bikeshedding.
Name Abbreviation Multiplier RFB
------------------------------------- ------------ -------------- ------
Vax V 5,000,000,000 [RFB6]
Antivax AV -5,000,000,000 [RFB6]
Vaxi Vi 5,368,709,120 [RFB6]
Antivaxi AVi -5,368,709,120 [RFB6]
------------------------------------------------------------------------
Media Types
This registry has been created by the Internet Engineering Task Force
and is managed by the Internet Assigned Numbers Authority. The BANANA
maintains the additional values specific to Bikeshedding Microsystems,
as per the compatibility rules of RFB 2. Defined in BCP 13.
## text/vnd.bikeshed.signature
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: N/A
Optional parameters: charset
Encoding considerations: Prefer UTF-8. See section 3 of [RFB1].
Security considerations: See section 7 of [RFB1].
Interoperability considerations: TBD
Published specification: [RFB1]
Applications that use this media type: N/A
Additional information:
- Magic numbers: 2d 2d 20 0a
See Section 3 of [RFB1].
- File extension(s): N/A
- Macintosh file type code(s): N/A
- Fragment identifier considerations: N/A
Person & email address to contact for further information: ~lucidiot
Intended usage: LIMITED USE
Use of this format SHOULD be restricted to bikeshedding activities.
Restrictions on usage: Bikeshedding
Author: ~lucidiot
Change controller: ~lucidiot
Provisional registration: No
## text/vnd.unix.cds
Type name: text
Subtype name: vnd.unix.cds
Required parameters: N/A
Optional parameters: charset
Encoding considerations: Prefer UTF-8. See Section 5 of [RFB7].
Security considerations: See Section 4 of [RFB7].
Interoperability considerations: See Section 7 of [RFB7].
Published specification: [RFB7]
Applications that use this media type: Most UNIX systems.
See Section 3 of [RFB7].
Additional information:
- Deprecated alias names for this type: N/A
- Magic numbers: N/A
- File extension(s): N/A
- Macintosh file type code(s): TEXT
Person & email address to contact for further information: ~lucidiot
Intended usage: COMMON
Restrictions on usage: N/A
Author: ~lucidiot
Change controller: ~lucidiot
Provisional registration: No
------------------------------------------------------------------------
Changelog
April 4, 2021
First version of this report.
June 30, 2021
Applied BANANA Considerations from RFB 4:
- The reference for the LIRS E-mail Signature Protocol Abbreviation
has been updated to RFB 4.
July 1, 2021
Applied BANANA Considerations from RFB 5:
- The reference for the HINA E-mail Signature Protocol Abbreviation
has been updated to RFB 5.
August 5, 2021
Applied BANANA Considerations from RFB 6:
- The Unit Prefixes registry has been created.
- The Vax, Antivax, Vaxi and Antivaxi unit prefixes have been added
to the Unit Prefixes registry.
Applied BANANA Considerations from RFB 7:
- The text/vnd.unix.cds media type has been added to the Media Types
registry.
------------------------------------------------------------------------
References
[APUB]: Lemmer Webber, C., Tallon, J., Shepherd, E., Guy, A.,
Prodromou, E., "ActivityPub", W3C Recommendation, January 2018,
<https://www.w3.org/TR/activitypub/>.
[BCP13]:
Freed, N., Klensin, J., "Multipurpose Internet Mail Extensions (MIME)
Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
Freed, N., Klensin, J., Hansen, T., "Media Type Specifications and
Registration Procedures", BCP 13, RFC 6838, January 2013.
<https://www.rfc-editor.org/info/bcp13>
[CDF]: Microsoft, "CDF Reference for Active Channels", August 2017,
<https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa768139(v=vs.85)>.
[CDF-W3C]: Ellerman, C., "Channel Definition Format (CDF)", W3C Note
NOTE-CDFsubmit, March 1997, <https://www.w3.org/TR/NOTE-CDFsubmit.html>.
[DISCORD]: Discord, "Discord", May 2015, <https://discord.com>.
[GEMINI]: Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020,
<gemini://gemini.circumlunar.space/docs/specification.gmi>.
[HINA]: kohgushi, "Asahina-Antenna meta data format version 2.2
(HINA/2.2)", Revision 0.13, July 2002,
<https://envs.net/~lucidiot/hina/hina2_2-rev0_13.html>.
[MSNP]: Mintz, M., Sayers, A., "MSN Messenger Protocol", December 2003,
<http://www.hypothetic.org/docs/msn/>.
[NOTADRAFT]: Kumari, W., "Just because it's an ID doesn't mean
anything... at all...", Work In Progress, draft-wkumari-not-a-draft-10,
July 2020.
[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", RFB 3, April 2021.
[RFB4]: ~lucidiot, "Last-modified Information Relaying Specification
(LIRS) 2.1", RFB 4, June 2021.
[RFB5]: ~lucidiot, "Asahina Antenna Metadata Format (HINA) 2.2
revision 0.13", RFB 5, July 2021.
[RFB6]: ~lucidiot, "Vaccination as a Unit Prefix", RFB 6, August 2021.
[RFB7]: ~lucidiot, "The Colon Delimited Shit Format", RFB 7,
August 2021.
[RFC1436]: Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol (a distributed
document search and retrieval protocol)", RFC 1436,
DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC1459]: Oikarinen, J., Reed, D., "Internet Relay Chat Protocol",
RFC 1459, DOI 10.17847/RFC1459, May 1993,
<https://www.rfc-editor.org/info/rfc1459>.
[RFC2810]: Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17847/RFC2810, April 2000,
<https://www.rfc-editor.org/info/rfc2810>.
[RFC2811]: Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, DOI 10.17847/RFC2811, April 2000,
<https://www.rfc-editor.org/info/rfc2811>.
[RFC2812]: Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
DOI 10.17847/RFC2812, April 2000,
<https://www.rfc-editor.org/info/rfc2812>.
[RFC2813]: Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813,
DOI 10.17847/RFC2813, April 2000,
<https://www.rfc-editor.org/info/rfc2813>.
[RFC3923]: Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923,
DOI 10.17847/RFC3923, October 2004,
<https://www.rfc-editor.org/info/rfc3923>.
[RFC4287]: Nottingham, M., Sayre, R., "The Atom Syndication Format",
RFC 4287, DOI 10.17487/RFC4287, December 2005,
<https://www.rfc-editor.org/info/rfc4287>.
[RFC6120]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Core", RFC 6120, DOI 10.17847/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6121]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17847/RFC6121,
March 2011, <https://www.rfc-editor.org/info/rfc6121>.
[RFC7194]: Hartmann, R., "Default Port for Internet Relay Chat (IRC)
via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194, August 2014,
<https://www.rfc-editor.org/info/rfc7194>.
[RFC7230]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230,
June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231,
June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7232]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232,
June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233]: Fielding, R., Lafon, Y., Reschke, J., "Hypertext Transfer
Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233,
June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7234]: Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234,
June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7235]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7622]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Address Format", RFC 7622, DOI 10.17847/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
[RSS1]: Beged-Dov, G., Brickley, D., Dornfest, R., Davis, I., Dodds,
L., Eisenzopf, J., Galbraith, D., Guha, R. V., MacLeod, K., Miller, E.,
Swartz, A. and E. van der Vlist, "RDF Site Summary (RSS) 1.0",
December 2000, <http://purl.org/rss/1.0/spec>.
[RSS2]: RSS Advisory Board, "RSS 2.0 Specification", Version 2.0.11,
March 2009, <https://www.rss-board.org/rss-specification>.
[JSONFEED]: Simmons, B. and M. Reece, "JSON Feed Version 1.1",
August 2020, <https://jsonfeed.org/version/1.1>.
[TWTXT]: buckket, "twtxt Documentation", September 2017,
<https://twtxt.readthedocs.io/>.

37
banana/report-changelog.txt Normal file
View File

@ -0,0 +1,37 @@
April 4, 2021
First version of this report.
June 30, 2021
Applied BANANA Considerations from RFB 4:
o The reference for the LIRS E-mail Signature Protocol Abbreviation
has been updated to RFB 4.
July 1, 2021
Applied BANANA Considerations from RFB 5:
o The reference for the HINA E-mail Signature Protocol Abbreviation
has been updated to RFB 5.
August 5, 2021
Applied BANANA Considerations from RFB 6:
o The Unit Prefixes registry has been created.
o The Vax, Antivax, Vaxi and Antivaxi unit prefixes have been added
to the Unit Prefixes registry.
Applied BANANA Considerations from RFB 7:
o The text/vnd.unix.cds media type has been added to the Media Types
registry.
July 19, 2022
Applied BANANA Considerations from RFB 8:
o BANANA registries have been made available in the Public Archive.

160
banana/signature-abbrevs.txt Normal file
View File

@ -0,0 +1,160 @@
E-mail Signature Protocol Abbreviations
Abbreviations that may be used for alternative protocols in the e-mail
signatures of Bikeshedders. This registry is maintained by ~lucidiot,
Designated Expert by interim. The Designated Expert can change this
registry at any time with notice, and Bikeshedders can submit assignment
requests to the Designated Expert. Defined by RFB 1.
Abbreviation Protocol References
------------ ---------------------------------------------- ----------
ATOM Atom Syndication Format [RFC4287]
CDF Channel Definition Format [CDF]
[CDF-W3C]
Discord Discord [DISCORD]
Fedi ActivityPub [APUB]
Gopher Internet Gopher Protocol [RFC1436]
Gemini Project Gemini [GEMINI]
HINA Asahina Antenna Metadata Format 2.2 [RFB5]
HTTP Hypertext Transfer Protocol [RFC7230]
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
IRC Internet Relay Chat [RFC1459]
[RFC2810]
[RFC2811]
[RFC2812]
[RFC2813]
[RFC7194]
JSON Feed JSON Feed 1.1 [JSONFEED]
LIRS Last-modified Information Relaying [RFB4]
Specification
MSN Microsoft Notification Protocol [MSNP]
RSS RDF Site Summary [RSS1]
RSS1
RSS Really Simple Syndication [RSS2]
RSS2
twtxt twtxt [TWTXT]
WEED Web Feeds [RFB3]
XMPP Extensible Messaging and Presence Protocol [RFC3923]
[RFC6120]
[RFC6121]
[RFC7622]
[APUB]: Lemmer Webber, C., Tallon, J., Shepherd, E., Guy, A.,
Prodromou, E., "ActivityPub", W3C Recommendation, January 2018,
<https://www.w3.org/TR/activitypub/>.
[CDF]: Microsoft, "CDF Reference for Active Channels", August 2017,
<https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa768139(v=vs.85)>.
[CDF-W3C]: Ellerman, C., "Channel Definition Format (CDF)", W3C Note
NOTE-CDFsubmit, March 1997, <https://www.w3.org/TR/NOTE-CDFsubmit.html>.
[DISCORD]: Discord, "Discord", May 2015, <https://discord.com>.
[GEMINI]: Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020,
<gemini://gemini.circumlunar.space/docs/specification.gmi>.
[MSNP]: Mintz, M., Sayers, A., "MSN Messenger Protocol", December 2003,
<http://www.hypothetic.org/docs/msn/>.
[RFB3]: ~lucidiot, "Web Feeds", RFB 3, April 2021.
[RFB4]: ~lucidiot, "Last-modified Information Relaying Specification
(LIRS) 2.1", RFB 4, June 2021.
[RFB5]: ~lucidiot, "Asahina Antenna Metadata Format (HINA) 2.2
revision 0.13", RFB 5, July 2021.
[RFC1436]: Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol (a distributed
document search and retrieval protocol)", RFC 1436,
DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC1459]: Oikarinen, J., Reed, D., "Internet Relay Chat Protocol",
RFC 1459, DOI 10.17847/RFC1459, May 1993,
<https://www.rfc-editor.org/info/rfc1459>.
[RFC2810]: Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17847/RFC2810, April 2000,
<https://www.rfc-editor.org/info/rfc2810>.
[RFC2811]: Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, DOI 10.17847/RFC2811, April 2000,
<https://www.rfc-editor.org/info/rfc2811>.
[RFC2812]: Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
DOI 10.17847/RFC2812, April 2000,
<https://www.rfc-editor.org/info/rfc2812>.
[RFC2813]: Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813,
DOI 10.17847/RFC2813, April 2000,
<https://www.rfc-editor.org/info/rfc2813>.
[RFC3923]: Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923,
DOI 10.17847/RFC3923, October 2004,
<https://www.rfc-editor.org/info/rfc3923>.
[RFC4287]: Nottingham, M., Sayre, R., "The Atom Syndication Format",
RFC 4287, DOI 10.17487/RFC4287, December 2005,
<https://www.rfc-editor.org/info/rfc4287>.
[RFC6120]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Core", RFC 6120, DOI 10.17847/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6121]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17847/RFC6121,
March 2011, <https://www.rfc-editor.org/info/rfc6121>.
[RFC7194]: Hartmann, R., "Default Port for Internet Relay Chat (IRC)
via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194, August 2014,
<https://www.rfc-editor.org/info/rfc7194>.
[RFC7230]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230,
June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231,
June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7232]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232,
June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233]: Fielding, R., Lafon, Y., Reschke, J., "Hypertext Transfer
Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233,
June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7234]: Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234,
June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7235]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7622]: Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Address Format", RFC 7622, DOI 10.17847/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
[RSS1]: Beged-Dov, G., Brickley, D., Dornfest, R., Davis, I., Dodds,
L., Eisenzopf, J., Galbraith, D., Guha, R. V., MacLeod, K., Miller, E.,
Swartz, A. and E. van der Vlist, "RDF Site Summary (RSS) 1.0",
December 2000, <http://purl.org/rss/1.0/spec>.
[RSS2]: RSS Advisory Board, "RSS 2.0 Specification", Version 2.0.11,
March 2009, <https://www.rss-board.org/rss-specification>.
[JSONFEED]: Simmons, B. and M. Reece, "JSON Feed Version 1.1",
August 2020, <https://jsonfeed.org/version/1.1>.
[TWTXT]: buckket, "twtxt Documentation", September 2017,
<https://twtxt.readthedocs.io/>.

14
banana/unit-prefixes.txt Normal file
View File

@ -0,0 +1,14 @@
Unit Prefixes
Unit prefixes that extend or replace SI prefixes within Bikeshedding
Microsystems communications. New entries may be added to this registry
only by publishing a new Request for Bikeshedding.
Name Abbreviation Multiplier RFB
------------------------------------- ------------ -------------- ------
Vax V 5,000,000,000 [RFB6]
Antivax AV -5,000,000,000 [RFB6]
Vaxi Vi 5,368,709,120 [RFB6]
Antivaxi AVi -5,368,709,120 [RFB6]
[RFB6]: ~lucidiot, "Vaccination as a Unit Prefix", RFB 6, August 2021.

12
banana/weeds.txt Normal file
View File

@ -0,0 +1,12 @@
Known Weeds
Any Bikeshedder can create new values by submitting a request to the
BANANA. Only the Change Controller of a value can update or remove it.
URLs are redacted in the Public Archive, as Weeds are meant to only be
known to Casakhstanis and Bikeshedders. Defined by RFB 3.
URL Format Change Controller
--------------------------------------------- ------ -----------------
[REDACTED] RSS2 ~dozens
[REDACTED] RSS2 ~lucidiot
[REDACTED] ATOM ~acdw

530
rfb/drafts/draft-cds-00.txt Normal file
View File

@ -0,0 +1,530 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft Bikeshedding Microsystems
Intended status: Informational August 3, 2021
Expires: February 3, 2022
The Colon Delimited Shit Format
draft-cds-00
Abstract
This document standardizes the text format commonly seen in UNIX
configuration files such as /etc/passwd, to ensure proper
interoperability.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding
Microsystems Working Task Force (BM-WTF). Note that other groups may
also distribute working documents as Bikeshed-Drafts. The list of
current Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on February 3, 2022.
Copyright Notice
Copyright (c) 2021 The 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 Expires February 3, 2022 [Page 1]
Bikeshed-Draft CDS Format August 2021
Table of Contents
1. Introduction ..................................................2
1.1. Notational Conventions ..................................2
2. Format Definition .............................................3
3. Notable Uses ..................................................4
3.1. /etc/passwd .............................................4
3.2. /etc/shadow .............................................4
3.3. /etc/group ..............................................5
4. Security Considerations .......................................5
5. Internationalization Considerations ...........................5
6. Privacy Considerations ........................................5
7. Interoperability Considerations ...............................6
8. Morality Considerations .......................................6
8.1. Likelihood of misuse by depraved or sick individuals ....6
8.2. Likelihood of misuse by misguided individuals ...........6
8.3. Likelihood of misuse by large, multi-national
corporations ............................................6
8.4. Availability of oversight facilities ....................7
8.5. Inter-SDO impact ........................................7
8.6. Care and concern for avian carriers .....................7
9. BANANA Considerations .........................................7
10. References ....................................................8
10.1. Normative References .....................................8
10.2. Informative References ...................................8
Appendix A. Warranty Exclusion Statement ...........................8
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction
UNIX systems have been since the 1960s storing user, group, and
password data in plain text files [PASSWD]. Unlike what many may
believe, a text file format is not necessarily any better than a
binary file format; it being readable in a text editor only means
that the reader has to parse the contents to understand them, instead
of having a piece of software do the parsing and present the data in
a more readable way, in which human parsing becomes negligible.
This file format, despite being rather uniform between UNIX variants,
has never been standardized, and never got a name. This document
aims to fix this issue, to prevent later interoperability issues,
in a similar spirit as for the CSV format [RFC4180], by defining it
as the Colon Delimited Shit format.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires February 3, 2022 [Page 2]
Bikeshed-Draft CDS Format August 2021
2. Format Definition
While there are various specifications and implementations for the
Colon Delimited Shit format, there is no formal and unique
specification in existence, which can allow for varied interpretation
and small incompatibilities. This section documents the format in
its strictest sense, the one that was the most commonly observed on
various systems, including Linux and BSD, with the most restrictions:
1. Each record is located on a separate line, delimited by a line
feed (LF):
root:x:0:0:root:/root:/bin/bash LF
lucidiot:x:1000:1000:lucidiot:/home/lucidiot:/usr/bin/zsh LF
2. The last record in the file may or may not have an ending line
feed (LF):
root:x:0:0:root:/root:/bin/bash LF
lucidiot:x:1000:1000:lucidiot:/home/lucidiot:/usr/bin/zsh
3. Within each record, there MUST be one or more fields, separated
by colons (:). Each line SHOULD contain the same number of
fields throuhgout the file. Spaces are considered part of a
field and SHOULD NOT be ignored. A field MAY be empty. The last
field in the record MUST NOT be followed by a colon. A field
MUST NOT contain a colon.
root:x:0:0
4. Quotes SHOULD NOT be interpreted as delimiting a field like they
could in a CSV file, and there are no escape characters. For
example:
"root":x\::"a:b"
This record contains five fields:
- "root"
- x\
- [An empty field]
- "a
- b"
The ABNF grammar [RFC5234] appears as follows:
file = record *(LF record) [LF]
record = field *(COLON field)
field = <any character except COLON>
~lucidiot Expires February 3, 2022 [Page 3]
Bikeshed-Draft CDS Format August 2021
COLON = %x3A
LF = %x0A ;as per section 6.1 of [RFC2234]
3. Notable Uses
In modern UNIX systems, there are three common uses of the Colon
Delimited Shit format.
3.1. /etc/passwd
The /etc/passwd file holds the list of users on this machine, with
the following fields:
- Username
- Password (set to `x` if it is stored in /etc/shadow)
- User ID
- Primary group ID
- User name or comment field (also known as GECOS field)
- Home directory
- Login shell
You can usually refer to `man 5 passwd` on these systems to learn
about the specific format used by a particular system.
3.2. /etc/shadow
While /etc/passwd is readable by all users, the /etc/shadow file was
introduced to hold the encrypted passwords of the users and only be
accessible to root. The passwords used to not be encrypted at all in
very early UNIX systems, which could allow someone to steal all the
passwords on a machine at once. Setting the password to just `x` in
/etc/passwd instructs the authentication system to get a password
from /etc/shadow instead. The file usually holds the following
fields:
- Username
- Encrypted password
- Timestamp of the last password change
- Minimum password age
- Maximum password age
~lucidiot Expires February 3, 2022 [Page 4]
Bikeshed-Draft CDS Format August 2021
- Password warning period
- Password inactivity period
- Account expiration date
- A reserved field
You can usually refer to `man 5 shadow` on these systems to learn
about the specific format used by a particular system.
3.3. /etc/group
The /etc/group file defines the groups on a UNIX system. It usually
has the following fields:
- Group name
- Encrypted password, may be empty
- Group ID
- Comma-separated list of users in the group, usually empty as most
implementations will only care about the group ID from
/etc/passwd.
You can usually refer to `man 5 group` on these systems to learn
about the specific format used by a particular system.
4. Security Considerations
UNIX systems that still store unencrypted passwords in /etc/passwd
or /etc/shadow, or encrypted passwords in /etc/passwd, SHOULD
urgently be updated.
Care should be taken to ensure that commands such as getent(1) are
able to handle improper input from the files, as there is no escape
mechanism; are empty fields tolerated, or fields with spaces, or
fields with quotes, with backslashes, records with not enough or too
many fields, etc.
5. Internationalization Considerations
Although most Colon Delimited Shit used to be in ASCII, modern UNIX
systems now tolerate UTF-8 text [RFC3629], and using UTF-8 is
therefore RECOMMENDED to avoid internationalization issues.
6. Privacy Considerations
The Colon Delimited Shit format does not directly cause any privacy-
related concerns.
~lucidiot Expires February 3, 2022 [Page 5]
Bikeshed-Draft CDS Format August 2021
Sensitive information SHOULD NOT be kept in the GECOS field of
/etc/passwd, although such a problem is nowadays highly unexpected.
7. Interoperability Considerations
Interoperability concerns are left up to the Protocol Police
[RFC8962].
8. Morality Considerations
This section contains morality considerations consistent with the
demands of [RFC4041].
8.1. Likelihood of misuse by depraved or sick individuals
Being a text file, a Colon Delimited Shit file cannot be used to
distribute blue, smutty or plain disgusting images.
8.2. Likelihood of misuse by misguided individuals
In a situation when a regular Comma-Separated Values file would make
more sense, it is RECOMMENDED to prefer CSV over Comma Delimited Shit
so as to avoid any potential abuse due to incomprehensions with the
lack of escaping and quoting mechanisms. Those situations MAY be
described as "anywhere except in /etc/passwd, /etc/group and
/etc/shadow".
8.3. Likelihood of misuse by large, multi-national corporations
Colon Delimited Shit alone could be used as an argument to mention
how other, possibly proprietary formats are clearly superior. When
used as the UNIX authentication system, it could be used as an
argument for other, more complex systems such as LDAP, Active
Directory, Kerberos, etc. We believe that, since those changes can
only impact the multi-national corporations themselves, negative
consequences of a misuse by large, multi-national corporations can
be ignored.
8.4. Availability of oversight facilities
As the few files in UNIX systems that use the Colon Delimited Shit
format have been here for decades, and most UNIX system users will
take them for granted without thinking about changing them. Should
a major change occur, it is the responsibility of operating system
distribution maintainers to accept or reject changes based on their
own ethics and policies.
~lucidiot Expires February 3, 2022 [Page 6]
Bikeshed-Draft CDS Format August 2021
8.5. Inter-SDO impact
As the files that use Colon Delimited Shit in UNIX systems have been
here for decades, and had very little changes in their fields, and as
this RFB merely describes the format they use, we believe that there
is no impact for other standards development organizations.
8.6. Care and concern for avian carriers
Birbs are important. Users and implementors MUST NOT hurt a birb
while implementing or using the Colon Delimited Shit format.
9. BANANA Considerations
This document registers the "text/vnd.unix.cds" media type.
Type name: text
Subtype name: vnd.unix.cds
Required parameters: n/a
Optional parameters: charset
Encoding considerations: Prefer UTF-8.
See Section 5 of this document.
Security considerations: See Section 4 of this document.
Interoperability considerations: See Section 7 of this document.
Published specification: This document
Applications that use this media type: Most UNIX systems.
See Section 3 of this document.
Additional information:
Deprecated alias names for this type: N/A
Magic numbers: N/A
File extension(s): N/A
Macintosh file type code(s): TEXT
Person & email address to contact for further information: See
Author's Address section.
Intended usage: COMMON
Restrictions on usage: N/A
~lucidiot Expires February 3, 2022 [Page 7]
Bikeshed-Draft CDS Format August 2021
Author: See Author's Address section.
Change controller: See Author's Address section.
Provisional registration? (standards tree only): No
10. References
10.1. Normative References
[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>.
[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>.
[RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC2234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
10.2. Informative References
[PASSWD] Garfinkel, S., Schwartz, A., Spafford, G., "Practical Unix
& Internet Security, 3rd Edition", "4.3. How Unix
Implements Passwords", ISBN 0-596-00323-4, February 2003,
<https://docstore.mik.ua/orelly/other/puis3rd/
0596003234_puis3-chp-4-sect-3.html>
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
~lucidiot Expires February 3, 2022 [Page 8]
Bikeshed-Draft CDS Format August 2021
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 like to thank, in particular, ~m455 for prompting
the standardization of the Colon Delimited Shit format.
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 Expires February 3, 2022 [Page 9]

884
rfb/drafts/draft-git-00.txt Normal file
View File

@ -0,0 +1,884 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft Bikeshedding Microsystems
Intended status: Standards Track July 16, 2022
Expires: January 16, 2023
Public Archive for Bikeshedding Microsystems
draft-git-00
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 Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding
Microsystems Working Task Force (BM-WTF). Note that other groups may
also distribute working documents as Bikeshed-Drafts. The list of
current Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on January 16, 2023.
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 Expires January 16, 2023 [Page 1]
Bikeshed-Draft 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 ..................................................14
Author's Address ..................................................15
~lucidiot Expires January 16, 2023 [Page 2]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 3]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 4]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 5]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 6]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 7]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 8]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 9]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 10]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 11]
Bikeshed-Draft 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 Expires January 16, 2023 [Page 12]
Bikeshed-Draft 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.
[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>.
[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>.
~lucidiot Expires January 16, 2023 [Page 13]
Bikeshed-Draft Public Archive July 2022
[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
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.
~lucidiot Expires January 16, 2023 [Page 14]
Bikeshed-Draft Public Archive July 2022
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 Expires January 16, 2023 [Page 15]

825
rfb/drafts/draft-hina-00.txt Normal file
View File

@ -0,0 +1,825 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Standards Track April 4, 2021
Expires: October 4, 2021
Asahina Antenna Metadata Format (HINA) 2.2, revision 0.13
draft-hina-00
Abstract
This document is an English translation and clean-up of the Asahina
Antenna Metadata Format (HINA) 2.2, in its latest revision, 0.13, of
July 19, 2002. It aims to preserve historical knowledge over
syndication formats.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on October 4, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Expires October 4, 2021 [Page 1]
Bikeshed-Draft HINA 2.2 April 2021
Table of Contents
1. Introduction ...................................................3
1.1. Notational Conventions ..................................3
2. Data Types .....................................................4
3. Structure ......................................................4
3.1. Block ....................................................4
3.2. Header Block .............................................5
3.3. Entity Block .............................................5
4. Fields .........................................................5
4.1. HINA .....................................................5
4.2. User-Agent ...............................................6
4.3. URL ......................................................6
4.4. HINA-Version .............................................6
4.5. Virtual ..................................................6
4.6. Content-Type .............................................7
4.7. Date .....................................................7
4.8. Title ....................................................7
4.9. Author-Name ..............................................7
4.10. Expires ..................................................7
4.11. Expire ...................................................7
4.12. Last-Modified ............................................8
4.13. Last-Modified-Detected ...................................8
4.14. Server ...................................................8
4.15. Authorized ...............................................8
4.16. Authorized-url ...........................................8
4.17. Method ...................................................8
4.17.1. Method Types .....................................9
4.17.2. Example ..........................................9
4.18. Keyword ..................................................9
4.19. Image-Width ..............................................9
4.20. Image-Height ............................................10
4.21. Experimental Fields .....................................10
4.22. Undefined Fields ........................................10
5. Encoding ......................................................10
6. Propagation ...................................................10
7. Security Considerations .......................................11
8. Internationalization Considerations ...........................11
9. Privacy Considerations ........................................11
10. BANANA Considerations .........................................11
11. References ....................................................11
11.1. Normative References ....................................11
11.2. Informative References ..................................12
Appendix A. Warranty Exclusion Statement ..........................13
Appendix B. Glossary ..............................................13
Acknowledgements ..................................................13
Author's Address ..................................................14
~lucidiot Expires October 4, 2021 [Page 2]
Bikeshed-Draft HINA 2.2 April 2021
1. Introduction
In the early days of RSS, before Atom and itself took over the world
of syndication, and before Unicode became common enough to reduce
internationalization issues, several syndication formats were being
developed at smaller scales.
As those formats are now slowly dying, the Bikeshedding Company's
Research and Development Division invests in dusting them off and
re-standardizing them to ensure that their specification is not lost
to time, and that future generations can still benefit from past
experience.
As XML [XML] and the Really Simple Syndication [RSS2] appeared very
recently, and the lack of general Unicode support in software led to
encoding incompatibilities between Western sites in ASCII [ASCII] and
Japanese sites in Shift-JIS [SHIFTJIS] or EUC-JP, the first programs
that offered a concept of syndication in Japan were called
"last-modified-time detection agents".
The most popular last-modified detection agent was Asahina-Antenna,
which led to the term "antenna" being used to refer to this type of
software. Asahina-Antenna used its own syndication format, the
Asahina Antenna Metadata Format (HINA). Some sites still serve
HINA feeds as of 2021.
HINA 1.x, also known as "hina.txt", was a text format whose
specification has not yet been recovered by our historians and was
used by Asahina Antenna 1.x.
HINA 2.x, also known as HINA-DI, has been influenced by Document
Information (DI), a project that aimed to develop document metadata
exchange and provided a mailing list. Hiroshi Nakamura intended to
create the Document Information Read Protocol (DIRP) and Document
Information Transfer Protocol (DITP), two standards to form a network
for distributed syndication based on RDF. The specifications were
never published, but HINA builds on this idea of decentralization.
In a way, DI and HINA 2.x have the same ideas as ActivityPub and the
modern concepts of federated software, but were 15 years early.
1.1. Notational Conventions
This document uses the Backus-Naur notation [RFC822] to formally
define the format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires October 4, 2021 [Page 3]
Bikeshed-Draft HINA 2.2 April 2021
2. Data Types
The basic data types that constitute Hina-Di are listed below.
The US-ASCII character set is defined by ANSI X3.4-1986 [ASCII].
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
WORD = 1*(ALPHA|DIGIT)
CTL = <any US-ASCII control character (octets 0 - 31)
and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
TEXT = <any OCTET except CTLs, but including HT>
TOKEN = <any TEXT, but don't start with SP or HT>
SEPARATOR = ":" 1*(SP|HT)
DELIMITER = "," *(SP|HT)
SLASH = "/" *(SP|HT)
3. Structure
A Hina-Di file consists of a series of blocks that summarize the
metadata on a website: a header block, followed by one or more entity
blocks.
hina-di = header-block
1*( entity-block )
3.1. Block
A block is a set of metadata for a document. Each metadata is
represented as a single header, in a manner similar to RFC 822
message headers [RFC822], with a field name and a field value.
Field names in a block MUST be unique. A block with duplicate field
names MUST be discarded by clients.
Field names are case-insensitive. Unless explicitly stated for a
particular field, a field's value is case-insensitive.
~lucidiot Expires October 4, 2021 [Page 4]
Bikeshed-Draft HINA 2.2 April 2021
line-format = field-name SEPARATOR field-value CRLF
field-name = WORD *( "-" WORD)
field-value = TOKEN
3.2. Header Block
Exactly one header block MUST appear in a Hina-Di file, and it MUST
be the first block. It holds metadata about the Hina-Di file itself.
header-block = HINA
Hinadi-Header
CRLF
Hinadi-Header = 1*( User-Agent
| Content-Type
| Date )
3.3. Entity Block
One or more entity blocks MUST be present after the header block.
Each entity block defines metadata about a specific document.
Entity-block = URL ( HINA-Version
| Virtual
| Content-Type
| Date
| Title
| Author-Name
| Expires
| Expire
| Last-Modified
| Last-Modified-Detected
| Server
| Authorized
| Authorized-url
| Method
| Keyword
| Image-Width
| Image-Height
| Experimental-field
| Undefined-field )
CRLF
4. Fields
This section defines the various fields that may be found in blocks.
All fields are OPTIONAL and case-insensitive unless otherwise
specified.
4.1. HINA
Indicates that this is a Hina-Di file, and includes its version.
This field is REQUIRED as the first field of Hina-Di files.
~lucidiot Expires October 4, 2021 [Page 5]
Bikeshed-Draft HINA 2.2 April 2021
HINA = "HINA" "/" hinadi-version CRLF
hinadi-version = "2.2beta"
4.2. User-Agent
Name of the user agent that created this Hina-Di file.
This field is REQUIRED in header blocks.
The value of this field is case-sensitive.
User-Agent = "User-Agent" SEPARATOR TOKEN CRLF
4.3. URL
URL of the document, compliant with [RFC2396].
This field is REQUIRED in entity blocks.
Making this field the first field of an entity block is RECOMMENDED.
The scheme and domain portions of the URL are not case-sensitive.
If the other portions of the URL are not case-insensitive, they
SHOULD be written using lowercase characters.
URL = "URL" SEPARATOR rfc2396-url CRLF
rfc2396-url = <URI described in section 5.1.2 "Request-URI"
in RFC 2396>
Implementations can use this field as a unique key that distinguishes
the entity block from other blocks. To ensure proper uniqueness of
this field, the following conditions MUST be respected by the
providing Hina-Di user agents or their administrators:
If the URL can end in a slash (`/`), then it SHOULD end in a slash.
Prefer `http://www.hoge.jp/foo/` over `http://www.hoge.jp/foo`.
If the URL includes a file name, but the file name can be omitted,
then it SHOULD be omitted. Prefer `http://www.hoge.jp/foo/` over
`http://www.hoge.jp/foo/index.html`
4.4. HINA-Version
Specifies that the integrity of the entity block was guaranteed
according to the specification of a specific Hina-Di version.
If this field is missing from an entity block, it means the block
might be incomplete.
HINA-Version = "HINA-Version" SEPARATOR version
version = "HINA" "/" 1*( DIGIT ) "." 1*( DIGIT )
4.5. Virtual
URL of another Hina-Di file that holds the entity block, compliant
with [RFC2396].
~lucidiot Expires October 4, 2021 [Page 6]
Bikeshed-Draft HINA 2.2 April 2021
If there are fields in the entity block other than `Virtual`, then
it takes the same meaning as the regular `URL` field.
The case-sensitivity and URL uniqueness conditions defined for the
`URL` field MUST be followed for this field.
Virtual = "Virtual" SEPARATOR rfc2396-url CRLF
Note that the original Japanese specification defines the `Virtual`
feed as `Vitural`.
4.6. Content-Type
MIME type of the Hina-Di file or the document, as described in
[RFC1521]. The value of this field is case-sensitive to the extent
defined by RFC 1521.
Content-Type = "Content-Type" SEPARATOR rfc1521-type CRLF
4.7. Date
The date and time when the block or the Hina-Di file was generated.
The dates MUST comply with [RFC1123]. The value of this field is
case-sensitive.
Date = "Date" SEPARATOR rfc1123-date CRLF
4.8. Title
The title of the document.
Title = "Title" SEPARATOR TOKEN CRLF
4.9. Author-Name
Name of the author of the document.
The value of this field is case-sensitive.
Author-Name = "Author-Name" SEPARATOR TOKEN CRLF
4.10. Expires
Expiration date for the block. The dates MUST comply with [RFC1123].
The value of this field is case-sensitive to the extent defined by
RFC 1123.
Expires = "Expires" SEPARATOR rfc1123-date CRLF
4.11. Expire
Alias for the `Expires` field, included for backwards compatibility.
~lucidiot Expires October 4, 2021 [Page 7]
Bikeshed-Draft HINA 2.2 April 2021
Expire = "Expire" SEPARATOR rfc1123-date CRLF
4.12. Last-Modified
Date and time when the document was last updated. The date MUST
comply with [RFC1123]. The value of this field is case-sensitive to
the extent defined by RFC 1123.
Last-Modified = "Last-Modified" SEPARATOR rfc1123-date CRLF
4.13. Last-Modified-Detected
Date and time representing when the user agent retrieved the
document's metadata. The dates MUST comply with [RFC1123].
The value of this field is case-sensitive to the extent defined by
RFC 1123.
Last-Modified-Detected = "Last-Modified-Detected"
SEPARATOR rfc1123-date CRLF
4.14. Server
User agent string of the server used to retrieve the metadata of the
document described by this entity block.
Server = "Server" SEPARATOR TOKEN CRLF
4.15. Authorized
The user agent that retrieved the metadata of the document described
by this entity block.
Authorized = "Authorized" SEPARATOR TOKEN CRLF WORD
4.16. Authorized-url
URL of a page describing the user agent referred to in the
`Authorized` field, compliant with [RFC2396].
The case-sensitivity and URL uniqueness conditions defined for the
`URL` field MUST be followed for this field.
Authorized-url = "Authorized-url" SEPARATOR rfc2396-url CRLF
4.17. Method
Describes the chain of propagation that this entity block went
through.
~lucidiot Expires October 4, 2021 [Page 8]
Bikeshed-Draft HINA 2.2 April 2021
Method = "Method" SEPARATOR method-type
*(SLASH method-type) (SLASH result-code)
method-type = "GET" | "HEAD" | "FILE" | "REMOTE"
result-code = <Status code from the IANA HTTP Status codes
registry [STATUS]>
The original Japanese specification defined result-code as follows:
result-code = <URI described on "???????" in RFC 2396>
4.17.1. Method Types
GET Metadata retrieved using a HTTP GET request.
HEAD Metadata retrieved using a HTTP HEAD request.
FILE Metadata retrieved from a local file's timestamp.
REMOTE Metadata retrieved from an entity block generated by another
agent.
4.17.2. Example
Method: REMOTE/REMOTE/GET/200
1. A first user agent retrieved the metadata on the document using
an HTTP GET request and got a 200 response code (`GET/200`).
2. A second user agent retrieved the first user agent's Hina-Di
file, then propagated it to its own file (`REMOTE`).
3. A third user agent retrieved the second user agent's Hina-Di
file, then propogated it to its own file (`REMOTE`).
4.18. Keyword
Words that can be used to give an overview of the document described
by this entity block; tags, categories, etc. The value of this field
is case-sensitive.
Keyword = "Keyword" SEPARATOR keywords CRLF
keywords = TOKEN *(SEPARATOR TOKEN)
4.19. Image-Width
Width of an image described by an entity block, in pixels.
This field MUST NOT be used for entity blocks that do not describe
images.
Image-Width = "Image-Width" SEPARATOR width CRLF
width = DIGIT
~lucidiot Expires October 4, 2021 [Page 9]
Bikeshed-Draft HINA 2.2 April 2021
4.20. Image-Height
Height of an image described by an entity block, in pixels.
This field MUST NOT be used for entity blocks that do not describe
images.
Image-Height = "Image-Height" SEPARATOR width CRLF
height = DIGIT
4.21. Experimental fields
Implementations MAY define custom fields with an X- prefix to provide
additional metadata not covered in this specification.
Implementations MUST NOT assume that all clients will use each of
those fields. Clients that do not support any experimental field
SHOULD ignore them.
Experimental fields MAY include data that is not directly related to
metadata that the document has, and SHOULD be used shall a field for
that purpose be created by an implementor.
Experimental-field = x-field-name SEPARATOR TOKEN
x-field-name = "X-" WORD *("-" WORD)
4.22. Undefined fields
Any field that is not defined in this specification. Implementations
that encounter such fields and do not support them SHOULD ignore
them.
Undefined-field = undef-field-name SEPARATOR TOKEN CRLF
undef-field-name = WORD *("-" WORD)
5. Encoding
The character encoding of the Hina-Di file SHOULD be specified as a
parameter of the Content-Type field of the header block. If it is
not specified, it defaults to EUC-JP.
6. Propagation
In Hina-Di, metadata propagation consists in acquiring metadata from
other agents, then sharing it as it is in the user agent's own
Hina-Di file. This can be used for aggregation services or a
peer-to-peer network.
The Authorized and Authorized-url fields allow indicating the user
agent from which the metadata originally came from to help ensure its
legitimacy. Propagating MUST only be performed if both fields are
defined and if the user agent is trusted.
~lucidiot Expires October 4, 2021 [Page 10]
Bikeshed-Draft HINA 2.2 April 2021
When propagating, all fields of an entity block defined in this
specification, with the exception of experimental and undefined
fields or of fields with empty values, MUST be reproduced without
modification. Propagation of experimental or undefined fields is not
guaranteed. A header block, or any field that is part of it, MUST
NOT be propagated.
The Method field MUST be updated upon propagation according to the
process described in section 4.17.
7. Security Considerations
The HINA format was designed at a time when security was far from the
primary concern for most Internet users. It is however easy, should
a modern implementation of the format be created, to seamlessly use
HTTPS instead of HTTP, both in the URLs of the syndicated content and
to serve the HINA feeds themselves.
8. Internationalization Considerations
While the format defaults to EUC-JP, it is possible to specify other
encodings for the whole file using the Content-Type field in the
Header Block. As most HINA feeds will be served over HTTP, the
Content-Type field of the HTTP response could also include this
encoding.
9. Privacy Considerations
The metadata shared in HINA is already public, and disclosure of this
information is under the full control of the publisher. However, in
a situation of propagation, the removal of already propagated links
or metadata may not be strictly performed by all implementors. This
can lead to the same issues as those seen in present-day federated
social networks, to which the only guaranteed solution is to not
publish what you might have to remove later.
10. BANANA Considerations
There are no BANANA actions.
11. References
11.1. Normative References
[ASCII] "American National Standard for Information Systems —
Coded Character Sets — 7-Bit American National Standard
Code for Information Interchange (7-Bit ASCII)",
ANSI X3.4-1986, American National Standards Institute,
March 1986.
~lucidiot Expires October 4, 2021 [Page 11]
Bikeshed-Draft HINA 2.2 April 2021
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", RFC 1123, DOI 10.17487/RFC1123,
October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies",
RFC 1521, DOI 10.17487/RFC1521, September 1993,
<https://www.rfc-editor.org/info/rfc1521>.
[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>.
[RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
DOI 10.17487/RFC2396, August 1998,
<https://www.rfc-editor.org/info/rfc2396>.
[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>.
[STATUS] "Hypertext Transfer Protocol (HTTP) Status Code Registry",
Internet Assigned Numbers Authority,
<https://www.iana.org/assignments/http-status-codes/
http-status-codes.xhtml>.
11.2. Informative References
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", RFC 822, DOI 10.17487/RFC0822,
August 1982, <https://www.rfc-editor.org/info/rfc822>.
[RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version
2.0.11, March 2009,
<https://www.rss-board.org/rss-specification>.
[SHIFTJIS] "7-bit and 8-bit double byte coded KANJI sets for
information interchange", JIS X0208:1997, Japanese
Standards Association, January 1997.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M. and E.
Maler, "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C Recommendation REC-xml-20001006, October
2000, <https://www.w3.org/TR/2000/REC-xml-20001006>.
~lucidiot Expires October 4, 2021 [Page 12]
Bikeshed-Draft HINA 2.2 April 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Glossary
This glossary was part of the original Japanese specification and are
left here to provide historical context to this standard.
Asahina-Antenna
Metadata acquisition agent based on HINA.
metadata
Information about the content, such as the author, title and
update time.
hina-di
Metadata transfer format used by Asahina-Antenna 2.x.
hina.txt
Metadata transfer format used by Asahina-Antenna 1.x, made
obsolete by hina-di.
DI
Document Information. Project that was developing the Document
Information Transfer Protocol (DITP) and Document Information Read
Protocol (DIRP), for decentralized syndication.
Hina-Di has been influenced by DI.
Acknowledgements
The author would like to thank Hiroshi Nakamura for sharing the idea
of the DITP and DIRP and developing decentralized technologies before
they truly came to life.
The author would like to thank Masayoshi Takahashi for providing an
English summary of the Japanese last-modified-time detection agents
in 1999.
Finally, the author would like to thank the Internet Archive and all
the contributors, donators, voulunteers involved, as without them
this research would have never been possible.
~lucidiot Expires October 4, 2021 [Page 13]
Bikeshed-Draft HINA 2.2 April 2021
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Expires October 4, 2021 [Page 14]

825
rfb/drafts/draft-hina-01.txt Normal file
View File

@ -0,0 +1,825 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft Bikeshedding Microsystems
Intended status: Standards Track June 30, 2021
Expires: December 30, 2021
Asahina Antenna Metadata Format (HINA) 2.2, revision 0.13
draft-hina-01
Abstract
This document is an English translation and clean-up of the Asahina
Antenna Metadata Format (HINA) 2.2, in its latest revision, 0.13, of
July 19, 2002. It aims to preserve historical knowledge over
syndication formats.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding
Microsystems Working Task Force (BM-WTF). Note that other groups may
also distribute working documents as Bikeshed-Drafts. The list of
current Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on October 4, 2021.
Copyright Notice
Copyright (c) 2021 The 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 Expires December 30, 2021 [Page 1]
Bikeshed-Draft HINA 2.2 June 2021
Table of Contents
1. Introduction ...................................................3
1.1. Notational Conventions ..................................3
2. Data Types .....................................................4
3. Structure ......................................................4
3.1. Block ....................................................4
3.2. Header Block .............................................5
3.3. Entity Block .............................................5
4. Fields .........................................................5
4.1. HINA .....................................................5
4.2. User-Agent ...............................................6
4.3. URL ......................................................6
4.4. HINA-Version .............................................6
4.5. Virtual ..................................................6
4.6. Content-Type .............................................7
4.7. Date .....................................................7
4.8. Title ....................................................7
4.9. Author-Name ..............................................7
4.10. Expires ..................................................7
4.11. Expire ...................................................7
4.12. Last-Modified ............................................8
4.13. Last-Modified-Detected ...................................8
4.14. Server ...................................................8
4.15. Authorized ...............................................8
4.16. Authorized-url ...........................................8
4.17. Method ...................................................8
4.17.1. Method Types .....................................9
4.17.2. Example ..........................................9
4.18. Keyword ..................................................9
4.19. Image-Width ..............................................9
4.20. Image-Height ............................................10
4.21. Experimental Fields .....................................10
4.22. Undefined Fields ........................................10
5. Encoding ......................................................10
6. Propagation ...................................................10
7. Security Considerations .......................................11
8. Internationalization Considerations ...........................11
9. Privacy Considerations ........................................11
10. BANANA Considerations .........................................11
11. References ....................................................11
11.1. Normative References ....................................11
11.2. Informative References ..................................12
Appendix A. Warranty Exclusion Statement ..........................13
Appendix B. Glossary ..............................................13
Acknowledgements ..................................................13
Author's Address ..................................................14
~lucidiot Expires December 30, 2021 [Page 2]
Bikeshed-Draft HINA 2.2 June 2021
1. Introduction
In the early days of RSS, before Atom and itself took over the world
of syndication, and before Unicode became common enough to reduce
internationalization issues, several syndication formats were being
developed at smaller scales.
As those formats are now slowly dying, the Bikeshedding Microsystems
Research and Development Division invests in dusting them off and
re-standardizing them to ensure that their specification is not lost
to time, and that future generations can still benefit from past
experience.
As XML [XML] and the Really Simple Syndication [RSS2] appeared very
recently, and the lack of general Unicode support in software led to
encoding incompatibilities between Western sites in ASCII [ASCII] and
Japanese sites in Shift-JIS [SHIFTJIS] or EUC-JP, the first programs
that offered a concept of syndication in Japan were called
"last-modified-time detection agents".
The most popular last-modified detection agent was Asahina-Antenna,
which led to the term "antenna" being used to refer to this type of
software. Asahina-Antenna used its own syndication format, the
Asahina Antenna Metadata Format (HINA). Some sites still serve
HINA feeds as of 2021.
HINA 1.x, also known as "hina.txt", was a text format whose
specification has not yet been recovered by our historians and was
used by Asahina Antenna 1.x.
HINA 2.x, also known as HINA-DI, has been influenced by Document
Information (DI), a project that aimed to develop document metadata
exchange and provided a mailing list. Hiroshi Nakamura intended to
create the Document Information Read Protocol (DIRP) and Document
Information Transfer Protocol (DITP), two standards to form a network
for distributed syndication based on RDF. The specifications were
never published, but HINA builds on this idea of decentralization.
In a way, DI and HINA 2.x have the same ideas as ActivityPub and the
modern concepts of federated software, but were 15 years early.
1.1. Notational Conventions
This document uses the Backus-Naur notation [RFC822] to formally
define the format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires December 30, 2021 [Page 3]
Bikeshed-Draft HINA 2.2 June 2021
2. Data Types
The basic data types that constitute Hina-Di are listed below.
The US-ASCII character set is defined by ANSI X3.4-1986 [ASCII].
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
WORD = 1*(ALPHA|DIGIT)
CTL = <any US-ASCII control character (octets 0 - 31)
and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
TEXT = <any OCTET except CTLs, but including HT>
TOKEN = <any TEXT, but don't start with SP or HT>
SEPARATOR = ":" 1*(SP|HT)
DELIMITER = "," *(SP|HT)
SLASH = "/" *(SP|HT)
3. Structure
A Hina-Di file consists of a series of blocks that summarize the
metadata on a website: a header block, followed by one or more entity
blocks.
hina-di = header-block
1*( entity-block )
3.1. Block
A block is a set of metadata for a document. Each metadata is
represented as a single header, in a manner similar to RFC 822
message headers [RFC822], with a field name and a field value.
Field names in a block MUST be unique. A block with duplicate field
names MUST be discarded by clients.
Field names are case-insensitive. Unless explicitly stated for a
particular field, a field's value is case-insensitive.
~lucidiot Expires December 30, 2021 [Page 4]
Bikeshed-Draft HINA 2.2 June 2021
line-format = field-name SEPARATOR field-value CRLF
field-name = WORD *( "-" WORD)
field-value = TOKEN
3.2. Header Block
Exactly one header block MUST appear in a Hina-Di file, and it MUST
be the first block. It holds metadata about the Hina-Di file itself.
header-block = HINA
Hinadi-Header
CRLF
Hinadi-Header = 1*( User-Agent
| Content-Type
| Date )
3.3. Entity Block
One or more entity blocks MUST be present after the header block.
Each entity block defines metadata about a specific document.
Entity-block = URL ( HINA-Version
| Virtual
| Content-Type
| Date
| Title
| Author-Name
| Expires
| Expire
| Last-Modified
| Last-Modified-Detected
| Server
| Authorized
| Authorized-url
| Method
| Keyword
| Image-Width
| Image-Height
| Experimental-field
| Undefined-field )
CRLF
4. Fields
This section defines the various fields that may be found in blocks.
All fields are OPTIONAL and case-insensitive unless otherwise
specified.
4.1. HINA
Indicates that this is a Hina-Di file, and includes its version.
This field is REQUIRED as the first field of Hina-Di files.
~lucidiot Expires December 30, 2021 [Page 5]
Bikeshed-Draft HINA 2.2 June 2021
HINA = "HINA" "/" hinadi-version CRLF
hinadi-version = "2.2beta"
4.2. User-Agent
Name of the user agent that created this Hina-Di file.
This field is REQUIRED in header blocks.
The value of this field is case-sensitive.
User-Agent = "User-Agent" SEPARATOR TOKEN CRLF
4.3. URL
URL of the document, compliant with [RFC2396].
This field is REQUIRED in entity blocks.
Making this field the first field of an entity block is RECOMMENDED.
The scheme and domain portions of the URL are not case-sensitive.
If the other portions of the URL are not case-insensitive, they
SHOULD be written using lowercase characters.
URL = "URL" SEPARATOR rfc2396-url CRLF
rfc2396-url = <URI described in section 5.1.2 "Request-URI"
in RFC 2396>
Implementations can use this field as a unique key that distinguishes
the entity block from other blocks. To ensure proper uniqueness of
this field, the following conditions MUST be respected by the
providing Hina-Di user agents or their administrators:
If the URL can end in a slash (`/`), then it SHOULD end in a slash.
Prefer `http://www.hoge.jp/foo/` over `http://www.hoge.jp/foo`.
If the URL includes a file name, but the file name can be omitted,
then it SHOULD be omitted. Prefer `http://www.hoge.jp/foo/` over
`http://www.hoge.jp/foo/index.html`
4.4. HINA-Version
Specifies that the integrity of the entity block was guaranteed
according to the specification of a specific Hina-Di version.
If this field is missing from an entity block, it means the block
might be incomplete.
HINA-Version = "HINA-Version" SEPARATOR version
version = "HINA" "/" 1*( DIGIT ) "." 1*( DIGIT )
4.5. Virtual
URL of another Hina-Di file that holds the entity block, compliant
with [RFC2396].
~lucidiot Expires December 30, 2021 [Page 6]
Bikeshed-Draft HINA 2.2 June 2021
If there are fields in the entity block other than `Virtual`, then
it takes the same meaning as the regular `URL` field.
The case-sensitivity and URL uniqueness conditions defined for the
`URL` field MUST be followed for this field.
Virtual = "Virtual" SEPARATOR rfc2396-url CRLF
Note that the original Japanese specification defines the `Virtual`
feed as `Vitural`.
4.6. Content-Type
MIME type of the Hina-Di file or the document, as described in
[RFC1521]. The value of this field is case-sensitive to the extent
defined by RFC 1521.
Content-Type = "Content-Type" SEPARATOR rfc1521-type CRLF
4.7. Date
The date and time when the block or the Hina-Di file was generated.
The dates MUST comply with [RFC1123]. The value of this field is
case-sensitive.
Date = "Date" SEPARATOR rfc1123-date CRLF
4.8. Title
The title of the document.
Title = "Title" SEPARATOR TOKEN CRLF
4.9. Author-Name
Name of the author of the document.
The value of this field is case-sensitive.
Author-Name = "Author-Name" SEPARATOR TOKEN CRLF
4.10. Expires
Expiration date for the block. The dates MUST comply with [RFC1123].
The value of this field is case-sensitive to the extent defined by
RFC 1123.
Expires = "Expires" SEPARATOR rfc1123-date CRLF
4.11. Expire
Alias for the `Expires` field, included for backwards compatibility.
~lucidiot Expires December 30, 2021 [Page 7]
Bikeshed-Draft HINA 2.2 June 2021
Expire = "Expire" SEPARATOR rfc1123-date CRLF
4.12. Last-Modified
Date and time when the document was last updated. The date MUST
comply with [RFC1123]. The value of this field is case-sensitive to
the extent defined by RFC 1123.
Last-Modified = "Last-Modified" SEPARATOR rfc1123-date CRLF
4.13. Last-Modified-Detected
Date and time representing when the user agent retrieved the
document's metadata. The dates MUST comply with [RFC1123].
The value of this field is case-sensitive to the extent defined by
RFC 1123.
Last-Modified-Detected = "Last-Modified-Detected"
SEPARATOR rfc1123-date CRLF
4.14. Server
User agent string of the server used to retrieve the metadata of the
document described by this entity block.
Server = "Server" SEPARATOR TOKEN CRLF
4.15. Authorized
The user agent that retrieved the metadata of the document described
by this entity block.
Authorized = "Authorized" SEPARATOR TOKEN CRLF WORD
4.16. Authorized-url
URL of a page describing the user agent referred to in the
`Authorized` field, compliant with [RFC2396].
The case-sensitivity and URL uniqueness conditions defined for the
`URL` field MUST be followed for this field.
Authorized-url = "Authorized-url" SEPARATOR rfc2396-url CRLF
4.17. Method
Describes the chain of propagation that this entity block went
through.
~lucidiot Expires December 30, 2021 [Page 8]
Bikeshed-Draft HINA 2.2 June 2021
Method = "Method" SEPARATOR method-type
*(SLASH method-type) (SLASH result-code)
method-type = "GET" | "HEAD" | "FILE" | "REMOTE"
result-code = <Status code from the IANA HTTP Status codes
registry [STATUS]>
The original Japanese specification defined result-code as follows:
result-code = <URI described on "???????" in RFC 2396>
4.17.1. Method Types
GET Metadata retrieved using a HTTP GET request.
HEAD Metadata retrieved using a HTTP HEAD request.
FILE Metadata retrieved from a local file's timestamp.
REMOTE Metadata retrieved from an entity block generated by another
agent.
4.17.2. Example
Method: REMOTE/REMOTE/GET/200
1. A first user agent retrieved the metadata on the document using
an HTTP GET request and got a 200 response code (`GET/200`).
2. A second user agent retrieved the first user agent's Hina-Di
file, then propagated it to its own file (`REMOTE`).
3. A third user agent retrieved the second user agent's Hina-Di
file, then propogated it to its own file (`REMOTE`).
4.18. Keyword
Words that can be used to give an overview of the document described
by this entity block; tags, categories, etc. The value of this field
is case-sensitive.
Keyword = "Keyword" SEPARATOR keywords CRLF
keywords = TOKEN *(SEPARATOR TOKEN)
4.19. Image-Width
Width of an image described by an entity block, in pixels.
This field MUST NOT be used for entity blocks that do not describe
images.
Image-Width = "Image-Width" SEPARATOR width CRLF
width = DIGIT
~lucidiot Expires December 30, 2021 [Page 9]
Bikeshed-Draft HINA 2.2 June 2021
4.20. Image-Height
Height of an image described by an entity block, in pixels.
This field MUST NOT be used for entity blocks that do not describe
images.
Image-Height = "Image-Height" SEPARATOR width CRLF
height = DIGIT
4.21. Experimental fields
Implementations MAY define custom fields with an X- prefix to provide
additional metadata not covered in this specification.
Implementations MUST NOT assume that all clients will use each of
those fields. Clients that do not support any experimental field
SHOULD ignore them.
Experimental fields MAY include data that is not directly related to
metadata that the document has, and SHOULD be used shall a field for
that purpose be created by an implementor.
Experimental-field = x-field-name SEPARATOR TOKEN
x-field-name = "X-" WORD *("-" WORD)
4.22. Undefined fields
Any field that is not defined in this specification. Implementations
that encounter such fields and do not support them SHOULD ignore
them.
Undefined-field = undef-field-name SEPARATOR TOKEN CRLF
undef-field-name = WORD *("-" WORD)
5. Encoding
The character encoding of the Hina-Di file SHOULD be specified as a
parameter of the Content-Type field of the header block. If it is
not specified, it defaults to EUC-JP.
6. Propagation
In Hina-Di, metadata propagation consists in acquiring metadata from
other agents, then sharing it as it is in the user agent's own
Hina-Di file. This can be used for aggregation services or a
peer-to-peer network.
The Authorized and Authorized-url fields allow indicating the user
agent from which the metadata originally came from to help ensure its
legitimacy. Propagating MUST only be performed if both fields are
defined and if the user agent is trusted.
~lucidiot Expires December 30, 2021 [Page 10]
Bikeshed-Draft HINA 2.2 June 2021
When propagating, all fields of an entity block defined in this
specification, with the exception of experimental and undefined
fields or of fields with empty values, MUST be reproduced without
modification. Propagation of experimental or undefined fields is not
guaranteed. A header block, or any field that is part of it, MUST
NOT be propagated.
The Method field MUST be updated upon propagation according to the
process described in section 4.17.
7. Security Considerations
The HINA format was designed at a time when security was far from the
primary concern for most Internet users. It is however easy, should
a modern implementation of the format be created, to seamlessly use
HTTPS instead of HTTP, both in the URLs of the syndicated content and
to serve the HINA feeds themselves.
8. Internationalization Considerations
While the format defaults to EUC-JP, it is possible to specify other
encodings for the whole file using the Content-Type field in the
Header Block. As most HINA feeds will be served over HTTP, the
Content-Type field of the HTTP response could also include this
encoding.
9. Privacy Considerations
The metadata shared in HINA is already public, and disclosure of this
information is under the full control of the publisher. However, in
a situation of propagation, the removal of already propagated links
or metadata may not be strictly performed by all implementors. This
can lead to the same issues as those seen in present-day federated
social networks, to which the only guaranteed solution is to not
publish what you might have to remove later.
10. BANANA Considerations
This document updates the "HINA" value in the E-mail Signature
Protocol Abbreviations registry.
The Reference field of the value should now point to this document.
11. References
11.1. Normative References
[ASCII] "American National Standard for Information Systems —
Coded Character Sets — 7-Bit American National Standard
Code for Information Interchange (7-Bit ASCII)",
ANSI X3.4-1986, American National Standards Institute,
March 1986.
~lucidiot Expires December 30, 2021 [Page 11]
Bikeshed-Draft HINA 2.2 June 2021
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", RFC 1123, DOI 10.17487/RFC1123,
October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies",
RFC 1521, DOI 10.17487/RFC1521, September 1993,
<https://www.rfc-editor.org/info/rfc1521>.
[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>.
[RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
DOI 10.17487/RFC2396, August 1998,
<https://www.rfc-editor.org/info/rfc2396>.
[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>.
[STATUS] "Hypertext Transfer Protocol (HTTP) Status Code Registry",
Internet Assigned Numbers Authority,
<https://www.iana.org/assignments/http-status-codes/
http-status-codes.xhtml>.
11.2. Informative References
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", RFC 822, DOI 10.17487/RFC0822,
August 1982, <https://www.rfc-editor.org/info/rfc822>.
[RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version
2.0.11, March 2009,
<https://www.rss-board.org/rss-specification>.
[SHIFTJIS] "7-bit and 8-bit double byte coded KANJI sets for
information interchange", JIS X0208:1997, Japanese
Standards Association, January 1997.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M. and E.
Maler, "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C Recommendation REC-xml-20001006, October
2000, <https://www.w3.org/TR/2000/REC-xml-20001006>.
~lucidiot Expires December 30, 2021 [Page 12]
Bikeshed-Draft HINA 2.2 June 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Glossary
This glossary was part of the original Japanese specification and is
left here to provide historical context to this standard.
Asahina-Antenna
Metadata acquisition agent based on HINA.
metadata
Information about the content, such as the author, title and
update time.
hina-di
Metadata transfer format used by Asahina-Antenna 2.x.
hina.txt
Metadata transfer format used by Asahina-Antenna 1.x, made
obsolete by hina-di.
DI
Document Information. Project that was developing the Document
Information Transfer Protocol (DITP) and Document Information Read
Protocol (DIRP), for decentralized syndication.
Hina-Di has been influenced by DI.
Acknowledgements
The author would like to thank Hiroshi Nakamura for sharing the idea
of the DITP and DIRP and developing decentralized technologies before
they truly came to life.
The author would like to thank Masayoshi Takahashi for providing an
English summary of the Japanese last-modified-time detection agents
in 1999.
Finally, the author would like to thank the Internet Archive and all
the contributors, donators, voulunteers involved, as without them
this research would have never been possible.
~lucidiot Expires December 30, 2021 [Page 13]
Bikeshed-Draft HINA 2.2 June 2021
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 Expires December 30, 2021 [Page 14]

354
rfb/drafts/draft-ietf-compat-00.txt Normal file
View File

@ -0,0 +1,354 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Standards Track April 2, 2021
Expires: October 2, 2021
Updates: 1
Ensuring Compatibility between The Bikeshedding Company
and Internet Engineering Task Force Standards
draft-ietf-compat-00
Abstract
The Internet Engineering Task Force (IETF) and The Bikeshedding
Company both provide standards and standardization bodies with the
same names, which can increase the confusion. This document
updates some of The Bikeshedding Company's jargon and the previous
Bikeshedding RFBs as a preventive measure.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on October 2, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Expires October 2, 2021 [Page 1]
Bikeshed-Draft IETF Compatibility April 2021
Table of Contents
1. Introduction ....................................................2
1.1. Notational Conventions .....................................2
2. Definitions .....................................................3
2.1. Bikeshed-Draft .............................................3
2.2. Request for Bikeshedding ...................................3
2.3. Best Current Bikeshedding ..................................3
2.4. The RFB Editor .............................................3
2.5. Bikeshedding Assigned Numbers Assignation and
Normalization Authority ....................................3
2.6. Bikeshedding Working Group .................................4
2.7. Bikeshedding Company Working Task Force ....................4
2.8. Human Resources Division ...................................4
3. RFB Updates .....................................................4
4. Interoperability Considerations .................................4
4.1. Cross-references ...........................................4
4.2. Conflict Resolution ........................................4
5. Security Considerations .........................................5
6. Internationalization Considerations .............................5
7. Privacy Considerations ..........................................5
8. BANANA Considerations ...........................................5
9. References ......................................................5
9.1. Normative References .......................................5
9.2. Informative References .....................................6
Appendix A. Warranty Exclusion Statement ...........................6
Acknowledgements ...................................................6
Author's Address ...................................................6
1. Introduction
This Request for Bikeshedding (RFB) introduces new terminology that
is equivalent to the Internet counterparts, such as RFB instead of
RFC, to avoid confusions between Internet standards and Bikeshedding
standards. As the RFC Editor currently handles over nine thousand
Requests for Comments, and the RFB Editor only handles one, renaming
on our own side is much easier for everyone.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires October 2, 2021 [Page 2]
Bikeshed-Draft IETF Compatibility April 2021
2. Definitions
2.1. Bikeshed-Draft
A Bikeshed-Draft (B-D) is the equivalent for The Bikeshedding Company
of an IETF Internet-Draft (I-D). Bikeshed-Drafts may be submitted by
any employee of the Bikeshedding Company.
2.2. Request for Bikeshedding
A Request for Bikeshedding (RFB) is the equivalent for The
Bikeshedding Company of an IETF Request for Comments (RFC). After
going through a reviewing process, a Bikeshed-Draft MAY be approved
by the RFB Editor to be published as an RFB.
2.3. Best Current Bikeshedding
A Best Current Bikeshedding (BCB) is the equivalent for The
Bikeshedding Company of an IETF Best Current Practices (BCP).
It is a set of RFBs that relate to a similar topic, may evolve over
time, and that can be referred to directly in an RFB instead of each
of the RFBs of the set.
The RFB Editor MAY, at any time, create, update or obsolete a BCB.
The RFB Editor MUST notify all employees of the Bikeshedding Company
of any change to a BCB via an email to the Tilde Pals mailing list.
2.4. The RFB Editor
The RFB Editor is in charge of handling the reviewing process of
Bikeshed-Drafts and the publication of the Requests for Bikeshedding.
The co-founders of the Bikeshedding Company MAY, without warning and
without justification, assign or remove a Bikeshedding Company
employee from the position of RFB Editor.
The position of RFB Editor is currently filled by ~lucidiot.
2.5. Bikeshedding Assigned Numbers Assignation and Normalization
Authority
The Bikeshedding Assigned Numbers Assignation and Normalization
Authority (BANANA) is a department of The Bikeshedding Company in
charge of maintaining protocol registries as defined in the BANANA
Considerations sections of RFBs.
The RFB Editor is in charge of notifying the BANANA of any BANANA
actions in an RFB that is about to be published. An RFB MUST NOT be
published before the BANANA has taken proper actions in regards to
the BANANA Considerations section.
~lucidiot Expires October 2, 2021 [Page 3]
Bikeshed-Draft IETF Compatibility April 2021
BANANA Considerations sections in RFBs follow the same guidelines as
those for IANA Considerations sections [RFC8126].
2.6. Bikeshedding Working Group
The Bikeshedding Working Group (BWG) is the set of all employees,
collaborators and partners of the Bikeshedding Company. It is the
equivalent of the IETF Network Working Group.
2.7. Bikeshedding Company Working Task Force
The Bikeshedding Company Working Task Force (BC-WTF) is the set of
all employees of the Bikeshedding Company. It is the equivalent for
the Bikeshedding Company of the Internet Engineering Task Force.
2.8. Human Resources Division
The Bikeshedding Company Human Resources Division is the equivalent
for The Bikeshedding Company of the IETF Protocol Police [RFC8962].
3. RFB Updates
This document updates RFB 1:
- All references to Bikeshedding Requests for Comments are replaced
with "Request for Bikeshedding".
- The IANA Considerations section is renamed BANANA Considerations.
- All actions instructed to the Internet Assigned Numbers Authority
are now reassigned to the Bikeshedding Assigned Numbers
Assignation and Normalization Authority.
4. Interoperability Considerations
4.1. Cross-references
Any document from the Bikeshedding Company MAY reference an IETF
document using IETF terminology. Any IETF document MAY reference a
document from the Bikeshedding Company using bikeshedding
terminology.
4.2. Conflict Resolution
A Bikeshedding Standard takes precedence over an Internet Standard,
and overrides any conflicting statements, in all contexts relevant to
Bikeshedding activities and to The Bikeshedding Company.
An Internet Standard takes precedence over a Bikeshedding Standard,
and overrides any conflicting statements, in all contexts relevant to
Internet protocols.
~lucidiot Expires October 2, 2021 [Page 4]
Bikeshed-Draft IETF Compatibility April 2021
In other contexts, readers MUST apply proper judgement to determine
which of the standards apply. The IETF Protocol Police and the
Bikeshedding Company Human Resources Division SHOULD ensure that all
readers of Bikeshedding Standards and Internet Standards apply proper
judgement, and perform punitive actions whenever necessary.
5. Security Considerations
Confusing terminology can increase the risk of improper
implementations of a protocol by a misunderstanding. This document
defines a stricter terminology to avoid mistaking a Bikeshedding
reference to an IETF reference and vice-versa, which can reduce this
risk.
6. Internationalization Considerations
All Bikeshedding Company and IETF Standards to date are in English
and use UTF-8 [RFC3629] or US-ASCII, and the Bikeshedding Company has
no Translation Division, so internationalization can be safely
unconsidered.
7. Privacy Considerations
Privacy is pointless in documents intended to be public.
8. BANANA Considerations
This document renames the IANA to BANANA. No registries or values
are affected.
9. References
9.1. Normative References
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S.,
"Establishing the Protocol Police", RFC 8962,
DOI 10.17487/RFC8962, April 2021,
<https://www.rfc-editor.org/infO/rfc8962>.
~lucidiot Expires October 2, 2021 [Page 5]
Bikeshed-Draft IETF Compatibility April 2021
9.2. Informative References
[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>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgements
The author would like to thank himself for being the only person with
enough might to use SciTE to write RFBs.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Expires October 2, 2021 [Page 6]

412
rfb/drafts/draft-lirs-00.txt Normal file
View File

@ -0,0 +1,412 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Standards Track April 4, 2021
Expires: October 4, 2021
Last-modified Information Relaying Specification (LIRS) 2.1
draft-lirs-00
Abstract
This document is an English translation and clean-up of the
Last-modified Information Relaying Specification (LIRS) 2.1, in its
only recovered and latest revision of December 16, 2001. It aims to
preserve historical knowledge over syndication formats.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on October 4, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Expires October 4, 2021 [Page 1]
Bikeshed-Draft LIRS 2.1 April 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ....................................2
2. Format .........................................................3
3. Fields .........................................................3
3.1. Last-Modified .............................................3
3.2. Last-Detected .............................................4
3.3. Time difference ...........................................4
3.4. Content-Length ............................................4
3.5. URL .......................................................4
3.6. Title .....................................................4
3.7. Author name ...............................................4
3.8. Source URL ................................................4
3.9. Extension .................................................4
4. Best Practices .................................................5
5. Example ........................................................5
6. Security Considerations ........................................5
7. Internationalization Considerations ............................5
8. Privacy Considerations .........................................6
9. BANANA Considerations ..........................................6
10. References .....................................................6
Appendix A. Warranty Exclusion Statement ...........................6
Appendix B. Changelog ..............................................6
Acknowledgements ...................................................7
Author's Address ...................................................7
1. Introduction
This document is a continuation of the historical research project of
the Bikeshedding Company's Research and Development Division, aiming
to preserve the history of syndication formats. It is a cleaned up
English translation of a Japanese specification that has been
recovered via the Internet Archive Wayback Machine.
Last-modified Information Relaying Specification (LIRS) 2.1 is a
last-modified-detection protocol designed to only include the minimal
necessary information for update time acquisition agents (antennas).
It assumes that a site that provides update times should not be
burdened with anything other than reporting update times. It also
assumes that the sites all run on UNIX environments.
The person exclusively in charge for changes to this specification is
Hiya (hiya@haun.org).
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires October 4, 2021 [Page 2]
Bikeshed-Draft LIRS 2.1 April 2021
2. Format
An LIRS file is a text file compressed using gzip. The text is
encoded using EUC-JP and consists in a series of records.
A record starts with "LIRS,", followed by a data part, and ends with
a comma and LF or CRLF. LF is recommended. CR MUST NOT be used
alone.
Lines that begin with # are comments and SHOULD be ignored.
The data part of a record consists in a series of fields separated
by commas (,).
Field values MUST NOT include the CR or LF characters, or unescaped
commas.
All dates are expressed as Unix timestamps: seconds from
1970-01-01T00:00:00Z.
With the exception of the extension field, blank fields SHOULD be
represented as a zero (0).
The backslash character (\) is the escape character. Commas in
fields MUST be escaped (\,). A literal backslash can be inserted
using two backslashes (\\).
3. Fields
The following fields MUST appear in all records, in this order:
- Last-Modified
- Last-Detected
- Time difference
- Content-Length
- URL
- Title
- Author name
- Source URL
- Extension
3.1. Last-Modified
Timestamp of when the target site was last updated.
Should the last update detection fail, the LIRS provider SHOULD set
this field to zero, and antenna agents SHOULD assume this record is
unusable.
~lucidiot Expires October 4, 2021 [Page 3]
Bikeshed-Draft LIRS 2.1 April 2021
3.2. Last-Detected
Timestamp of when the LIRS provider last checked for the last update
time for this site. This defines a notion of "freshness" that
antenna agents can use to sort records by priority, or discard old
records.
Should the last update detection fail, the LIRS provider SHOULD set
this field to zero, and antenna agents SHOULD assume this record is
unusable.
3.3. Time difference
Signed integer. Difference, in seconds, between GMT and the timezone
of the target site; 32400 or +32400 in Japan. Since update times are
reported in GMT, this allows sharing the timezone of the target site.
3.4. Content-Length
Size of the content served at the target URL, in bytes. LIRS
providers that check the target site externally, and do not have more
internal ways to detect an update, SHOULD consider a change in the
Content-Length to be an update.
3.5. URL
URL of the target site. This field MUST be unique; a single URL MUST
NOT be repeated twice in the same LIRS file. This field can be used
as a unique identifier by antenna implementations.
3.6. Title
Title of the content served at the target site; usually the contents
of the HTML <title> tag.
3.7. Author name
Name of the author of the content served at this URL.
3.8. Source URL
URL that was used by the LIRS provider to acquire update information.
This is usually the same as the URL; in case of an implementation
that aggregates update information from other LIRS providers, this
could be the URL of each LIRS file. How to use this field is left to
the implementor.
3.9. Extension
Arbitrary string for agent-specific information. Instead of 0 as
the default for a blank field, this SHOULD be left empty.
~lucidiot Expires October 4, 2021 [Page 4]
Bikeshed-Draft LIRS 2.1 April 2021
4. Best Practices
LIRS files SHOULD be cached, not generated dynamically.
LIRS implementations SHOULD automatically discard records that
were last detected more than 28800 seconds (8 hours) ago.
5. Example
This is a single LIRS record, uncompressed:
LIRS,938779260,938781002,32400,49383,http://hiya.ouchi.to/n/,
Tadayo Memories,Hiya,http://amano.hauN.org/,blah blah,\r\n
This translates to the following fields:
Title: Tadayo Memories
Author: Hiya
Site URL: http://hiya.ouchi.to/n/
Last modified: 1999-10-01T14:01:00Z
Last detected: 1999-10-01T14:30:02Z
Server timezone: UTC+9 (32400 seconds)
Source: http://amano.hauN.org/
Custom data: blah blah
6. Security Considerations
Client implementations SHOULD be wary of the possible decompression
bombs that a server could send.
The standard was designed with HTTP in mind, but replacing the scheme
with HTTPS for added security should not affect any modern
implementation.
7. Internationalization Considerations
This standard was almost exclusively designed for Japan; no encoding
other than EUC-JP is allowed.
Client implementations MAY be flexible and try decoding using UTF-8
instead of EUC-JP when errors occur, to allow for a possible
evolution towards an internationalized standard if more LIRS
implementations support it.
~lucidiot Expires October 4, 2021 [Page 5]
Bikeshed-Draft LIRS 2.1 April 2021
8. Privacy Considerations
The metadata shared in LIRS is already public, and disclosure of this
information is under the full control of the publisher. However,
when aggregating feds, the removal of already aggregated links or
metadata may not be strictly performed by all implementors. This can
lead to the same issues as those seen in present-day federated social
networks, to which the only guaranteed solution is to not publish
what you might have to remove later.
9. BANANA Considerations
This document updates the "LIRS" value in the E-mail Signature
Protocol Abbreviations registry.
The Reference field of the value should now point to this document.
10. References
[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>.
[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>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Changelog
This changelog was included in the original specification. It is
included here to provide historical context.
The changelog only included timestamps. The associated version
numbers have been added where they are known.
2001-12-16 22:48, LIRS 2.1
Added a link to the Meta::LIRS Perl module
2000-10-25 14:36, LIRS 2.1
Fixed an error in the description of the URL field.
~lucidiot Expires October 4, 2021 [Page 6]
Bikeshed-Draft LIRS 2.1 April 2021
2000-10-13 15:20, LIRS 2.1
Fixed an error in the usage of gzip in LIRS.pm.
2000-06-23 13:52
Added details about handling line feeds (\\015, \\012).
2000-06-16 13:47
Added a link to lirs.rb.
2000-05-31 20:00
Backslashes should now be escaped too (`\\`).
Minor corrections due to changes in LIRS.pm.
1999-11-11 19:41
Document converted to HTML, and minor corrections.
1999-11-03 03:25, LIRS 1.1
Minor corrections after a discussion about DI.
Added the About LIRS section.
1999-10-13 18:00, LIRS 1.0
Initial version.
Acknowledgements
The author would like to thank Hiya for creating LIRS, and Yamakazoo
for creating some Perl CGI scripts that support LIRS, HINA 1 and
HINA 2, and still hosting them proudly on their personal website in
the year 2021: http://www.harmonicom.jp/natsu/
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Expires October 4, 2021 [Page 7]

531
rfb/drafts/draft-signature-01.txt Normal file
View File

@ -0,0 +1,531 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Standards Track February 15, 2021
Expires: August 15, 2021
Tildepals Email Signatures for Bikeshedders
draft-signature-01
Abstract
Signatures
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Expires August 15, 2021 [Page 1]
Bikeshed-Draft Tildepals Email Signatures February 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ....................................2
2. Core Values of a Signature .....................................3
2.1. Identification ............................................3
2.2. Communication .............................................3
2.3. Synergy ...................................................3
2.4. Accountability ............................................3
2.5. Security ..................................................3
3. Format .........................................................3
3.1. Embedding .................................................3
4. Content Guidelines .............................................4
4.1. Sender's Identity .........................................4
4.2. Contact Information .......................................4
4.3. Atlantis Protection .......................................5
5. Example ........................................................5
6. Enforcement ....................................................5
6.1. Recommended Actions Against Non-Conformance ...............6
7. Security Considerations ........................................6
8. Internationalization Considerations ............................6
9. Privacy Considerations .........................................7
10. IANA Considerations ............................................7
11. References .....................................................8
11.1. Normative References .....................................8
11.2. Informative References ...................................8
Appendix A. Warranty Exclusion Statement ...........................8
Acknowledgements ...................................................8
1. Introduction
This Request for Comments (RFC) provides a standard format for email
signatures of collaborators and partners of the Bikeshedding Company
that ensures the Core Values of the Bikeshedding Company are properly
displayed and relevant information is shared.
All collaborators of the Bikeshedding Company MUST update their
signature to follow this RFC.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires August 15, 2021 [Page 2]
Bikeshed-Draft Tildepals Email Signatures February 2021
2. Core Values of a Signature
2.1. Identification
A signature's primary goal is to identify the author of an email;
therefore the first portion of a signature should be the author's
first and last name.
2.2. Communication
When the message portion of an email is extracted from its email
context, the sender's contact information is lost as it was part of
the email headers. Adding contact information helps prevent this
issue, and also allows reaching out to the sender via other means of
communication such as a phone call.
2.3. Synergy
By making communication easier, a signature enhances the synergy
between correspondents and boosts productivity.
2.4. Accountability
Signatures can make people accountable for their actions as their
name is right below what they write.
2.5. Security
By following standard practices used by large organizations such as
the IETF, a signature can bring security to the company, for example
against the people of Atlantis [NOTADRAFT].
3. Format
Signatures SHOULD be encoded in plain text using the UTF-8 text
encoding [RFC3629]. All lines in a signature text MUST NOT exceed 72
characters in length.
The first line of a signature MUST be the separator string "-- ",
trailing space included. Email client implementors MAY recognize
this line as the signature separator and display it in special
formatting, or exclude it from quoted replies.
Signatures SHOULD be excluded from a message when quoting it in an
email reply, unless including the signature in the quotation brings
to the context of the reply.
3.1. Embedding
When a signature is embedded in another text format, it MUST use the
encoding of its parent text format instead of UTF-8.
~lucidiot Expires August 15, 2021 [Page 3]
Bikeshed-Draft Tildepals Email Signatures February 2021
When a signature is embedded in an HTML email, it SHOULD be wrapped
in HTML <pre> and tags if its proper display requires a monospaced
font.
Use of the multipart/related media type to add the signature aside
from the email in its original media type, instead of an HTML media
type, is optional.
4. Content Guidelines
A standard signature SHOULD hold the following sections, in this
order:
1. The sender's identity
2. The sender's contact information
3. Security measures against eel-bearing Atlanteans
Other sections MAY be added, as long as they follow the Core Values
of signatures. Sections MAY be separated by blank lines to enhance
readability.
4.1. Sender's Identity
The first line after the separator MUST hold the first and last name,
or the nickname, of the sender. If the sender's identity should be
hidden behind a generic name, for example for a customer support
service with a generic email address, the line MAY be omitted.
The next line SHOULD be the role of the sender, followed by a comma,
and followed by the company related to the role. This can be
repeated for as many times as required, if multiple job titles are
relevant.
4.2. Contact Information
The contact information section MUST start with the sender's email
address. If multiple addresses are relevant, each address MUST be
put on a separate line.
If the sender is reachable via other means of communication, they MAY
be added as subsequent lines. Each line MUST start with the protocol
name (HTTP, Gopher, Phone, Fax, ...), followed by a colon and a
space, and end with the relevant contact information for this
protocol.
~lucidiot Expires August 15, 2021 [Page 4]
Bikeshed-Draft Tildepals Email Signatures February 2021
4.3. Atlantis Protection
To ensure protection of the Bikeshedding Company against economic
issues caused by eel-bearing Atlanteans, a signature MUST hold the
string "Don't allow eel bearing Atlanteans into your country;
economic ruin follows close behind", as required by IETF standards
[NOTADRAFT].
When a signature is embedded in a parent media type that does not
support encoding the 'b' character, the string "My hovercraft is full
of eels" MUST be used instead.
Other strings from the IANA Registry of important strings, suitable
for use as idle signalling transmissions (ROISSFUAIST) MAY be used,
unless they hinder readability.
5. Example
This document's author's signature could be formatted like so:
--
~lucidiot
Co-Founder, The Bikeshedding Company
Chairman, International Transport Safety Bureau
lucidiot@brainshit.fr
erwan.rct@wanadoo.fr
MSN: lucidiot@protonmail.com
HTTP: http://tilde.town/~lucidiot/
Don't allow eel bearing Atlanteans into your country; economic
ruin follows close behind.
6. Enforcement
Unless where technical limitations may prevent it, emails from the
Bikeshedding Company MUST include a signature conforming with this
document.
Recipients MAY reject any email from the Bikeshedding Company that
does not include a signature or that includes a signature that does
not conform with this document. Recipients SHOULD inform the
sender of their rejection by means of an email.
In cases of repeated non-conformance, recipients SHOULD send an email
to the Human Resources division of the Bikeshedding Company to inform
them of the issue and allow them to take action.
~lucidiot Expires August 15, 2021 [Page 5]
Bikeshed-Draft Tildepals Email Signatures February 2021
6.1. Recommended Actions Against Non-Conformance
The following actions are RECOMMENDED, by order of severity:
- Sending a reminder of the existence of this document.
- Scheduling a training session with slides and a lot of
buzzwords.
- Making a formal write-up for non-conformance to this document.
- Requiring approbation from the Human Resources division for each
email sent by the perpetrator until the non-conformance ceases.
- Publicly blaming the perpetrator's actions for any and all
issues within the Bikeshedding Company.
- Trout-slapping.
- Firing the perpetrator.
7. Security Considerations
Use of HTML in emails is known to cause security problems due to
the many technologies it can bring. This document requires
plain-text signatures to avoid those security problems.
Signatures, as human-written and human-read text, are however still
vulnerable to social engineering attacks and Information Technology
executives should consider hiring overpriced consulting services to
help them in training their collaborators against them.
8. Internationalization Considerations
It is well-known that most text encodings were designed without
non-English languages and non-Latin alphabets in mind. This document
requires the UTF-8 text encoding [RFC3629], as it already supports
most languages and alphabets and can be extended by updates to the
Unicode specification as needed.
Signatures embedded in messages of a different encoding may however
have encoding issues. It is however believed that the existing
issues with text encoding in email and in general will help prevent
users from trying to run into these issues.
~lucidiot Expires August 15, 2021 [Page 6]
Bikeshed-Draft Tildepals Email Signatures February 2021
9. Privacy Considerations
Until the email is sent, the sender remains in full control of their
signature, and may choose to change the signature's contents to
adapt to a particular context on a case-by-case basis.
However, by reproducing a signature, an attacker can make themselves
appear as someone else, as users might rely on the signature more
than email headers. This can be solved both by proper training from
overpriced consultants and from using technologies such as S/MIME
[RFC8551].
10. IANA Considerations
This document registers the "text/vnd.bikeshed.signature" media type.
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: n/a
Optional parameters: charset
Encoding considerations: Prefer UTF-8. See Section 3 of this RFC.
Security considerations: See Section 7 of this RFC.
Interoperability considerations: TBD
Published specification: TBD
Applications that use this media type: n/a
Additional information:
Magic numbers: 2d 2d 20 0a
See Section 3 of this RFC.
File extension(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
Person & email address to contact for further information: See
Author's Address section.
Intended usage: Limited Use
Use of this format SHOULD be restricted to bikeshedding
activities.
~lucidiot Expires August 15, 2021 [Page 7]
Bikeshed-Draft Tildepals Email Signatures February 2021
Restrictions on usage: none
Author: See Author's Address section.
Change controller: See Author's Address section.
11. References
11.1. Normative References
[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>.
[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>.
[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>.
[RFC8551] Schaad, J., Ramsdell, B. and Turner, S.,
"Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 4.0 Message Specification", RFC 8551,
DOI 10.17487/RFC8551, April 2019,
<https://www.rfc-editor.org/info/rfc8551>.
11.2. Informative References
[NOTADRAFT] Kumari, W., "Just because it's an ID doesn't mean
anything... at all...", Work In Progress,
draft-wkumari-not-a-draft-10, July 2020.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
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.
~lucidiot Expires August 15, 2021 [Page 8]
Bikeshed-Draft Tildepals Email Signatures February 2021
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Expires August 15, 2021 [Page 9]

766
rfb/drafts/draft-signature-02.txt Normal file
View File

@ -0,0 +1,766 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Standards Track February 22, 2021
Expires: August 22, 2021
Tildepals Email Signatures for Bikeshedders
draft-signature-02
Abstract
Signatures are an important part of an e-mail, but are often abused,
misused or ignored. This document provides a standard format for the
e-mail signatures of Bikeshedders to prevent those issues and protect
the company's reputation.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Expires August 22, 2021 [Page 1]
Bikeshed-Draft Tildepals Email Signatures February 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ....................................3
2. Core Values of a Signature .....................................3
2.1. Identification ............................................3
2.2. Communication .............................................3
2.3. Synergy ...................................................3
2.4. Accountability ............................................3
2.5. Security ..................................................3
3. Format .........................................................3
3.1. Embedding .................................................4
4. Content Guidelines .............................................4
4.1. Sender's Identity .........................................4
4.2. Contact Information .......................................4
4.3. Atlantis Protection .......................................5
4.4. Company-Approved Advertisements ...........................5
5. Example ........................................................6
6. Enforcement ....................................................6
6.1. Recommended Actions Against Non-Conformance ...............6
7. Security Considerations ........................................7
8. Internationalization Considerations ............................7
9. Privacy Considerations .........................................7
10. IANA Considerations ............................................7
10.1. text/vnd.bikeshed.signature media type ...................7
10.2. Creation of Company-Approved Advertisements Registry .....8
10.3. Creation of E-mail Signature Protocol Abbreviations
Registry .................................................9
11. References ....................................................10
11.1. Normative References ....................................10
11.2. Informative References ..................................11
Appendix A. Warranty Exclusion Statement ..........................13
Appendix B. Changelog .............................................13
Acknowledgements ..................................................13
Author's Address ..................................................13
1. Introduction
This Request for Comments (RFC) provides a standard format for email
signatures of collaborators and partners of the Bikeshedding Company
that ensures the Core Values of the Bikeshedding Company are properly
displayed and relevant information is shared.
All collaborators of the Bikeshedding Company MUST update their
signature to follow this RFC.
~lucidiot Expires August 22, 2021 [Page 2]
Bikeshed-Draft Tildepals Email Signatures February 2021
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Core Values of a Signature
2.1. Identification
A signature's primary goal is to identify the author of an email;
therefore the first portion of a signature should be the author's
first and last name.
2.2. Communication
When the message portion of an email is extracted from its email
context, the sender's contact information is lost as it was part of
the email headers. Adding contact information helps prevent this
issue, and also allows reaching out to the sender via other means of
communication such as a phone call.
2.3. Synergy
By making communication easier, a signature enhances the synergy
between correspondents and boosts productivity.
2.4. Accountability
Signatures can make people accountable for their actions as their
name is right below what they write.
2.5. Security
By following standard practices used by large organizations such as
the IETF, a signature can bring security to the company, for example
against the people of Atlantis [NOTADRAFT].
3. Format
Signatures SHOULD be encoded in plain text using the UTF-8 text
encoding [RFC3629]. All lines in a signature text MUST NOT exceed 72
characters in length.
The first line of a signature MUST be the separator string "-- ",
trailing space included. Email client implementors MAY recognize
this line as the signature separator and display it in special
formatting, or exclude it from quoted replies.
~lucidiot Expires August 22, 2021 [Page 3]
Bikeshed-Draft Tildepals Email Signatures February 2021
Signatures SHOULD be excluded from a message when quoting it in an
email reply, unless including the signature in the quotation brings
to the context of the reply.
3.1. Embedding
When a signature is embedded in another text format, it MUST use the
encoding of its parent text format instead of UTF-8.
When a signature is embedded in an HTML email, it SHOULD be wrapped
in HTML <pre> and tags if its proper display requires a monospaced
font.
Use of the multipart/related media type to add the signature aside
from the email in its original media type, instead of an HTML media
type, is optional.
4. Content Guidelines
A standard signature SHOULD hold the following sections, in this
order:
1. The sender's identity
2. The sender's contact information
3. Security measures against eel-bearing Atlanteans
Other sections MAY be added, as long as they follow the Core Values
of signatures. Sections MAY be separated by blank lines to enhance
readability.
4.1. Sender's Identity
The first line after the separator MUST hold the first and last name,
or the nickname, of the sender. If the sender's identity should be
hidden behind a generic name, for example for a customer support
service with a generic email address, the line MAY be omitted.
The next line SHOULD be the role of the sender, followed by a comma,
and followed by the company related to the role. This can be
repeated for as many times as required, if multiple job titles are
relevant.
4.2. Contact Information
The contact information section MUST start with the sender's email
address. If multiple addresses are relevant, each address MUST be
put on a separate line.
~lucidiot Expires August 22, 2021 [Page 4]
Bikeshed-Draft Tildepals Email Signatures February 2021
If the sender is reachable via other means of communication, they MAY
be added as subsequent lines. Each line MUST start with the protocol
name, followed by a colon and a space, and end with the relevant
contact information for this protocol.
The protocol name MUST be registered in the E-mail Signature Protocol
Abbreviations IANA registry.
4.3. Atlantis Protection
To ensure protection of the Bikeshedding Company against economic
issues caused by eel-bearing Atlanteans, a signature MUST hold the
string "Don't allow eel bearing Atlanteans into your country;
economic ruin follows close behind", as required by IETF standards
[NOTADRAFT].
When a signature is embedded in a parent media type that does not
support encoding the 'b' character, the string "My hovercraft is full
of eels" MUST be used instead.
Other strings from the IANA Registry of important strings, suitable
for use as idle signalling transmissions (ROISSFUAIST) MAY be used,
unless they hinder readability.
4.4. Company-Approved Advertisements
The Marketing Division of the Bikeshed Company MAY, at its
discretion, enact Advertisement Directives via a memo sent in a
company-wide e-mail. Those directives SHOULD state a list of
currently accepted Bikeshedding Company advertisements that CAN be
inserted by Bikeshedders in another section of their signature.
Advertisements for companies other than the Bikeshedding Company, or
that are not approved in the Marketing Division's Advertisement
Directives, MUST NOT be inserted in a signature.
When and only when the Marketing Division's Advertisement Directives
explicitly state that an advertisement is REQUIRED, it is so.
~lucidiot Expires August 22, 2021 [Page 5]
Bikeshed-Draft Tildepals Email Signatures February 2021
5. Example
This document's author's signature could be formatted like so:
--
~lucidiot
Co-Founder, The Bikeshedding Company
Chairman, International Transport Safety Bureau
lucidiot@brainshit.fr
erwan.rct@wanadoo.fr
MSN: lucidiot@protonmail.com
HTTP: http://tilde.town/~lucidiot/
Don't allow eel bearing Atlanteans into your country; economic
ruin follows close behind.
Figure 1 : Example Signature
6. Enforcement
Unless where technical limitations may prevent it, emails from the
Bikeshedding Company MUST include a signature conforming with this
document.
Recipients MAY reject any email from the Bikeshedding Company that
does not include a signature or that includes a signature that does
not conform with this document. Recipients SHOULD inform the
sender of their rejection by means of an email.
In cases of repeated non-conformance, recipients SHOULD send an email
to the Human Resources division of the Bikeshedding Company to inform
them of the issue and allow them to take action.
6.1. Recommended Actions Against Non-Conformance
The following actions are RECOMMENDED, by order of severity:
- Sending a reminder of the existence of this document.
- Scheduling a training session with slides and a lot of
buzzwords.
- Making a formal write-up for non-conformance to this document.
- Requiring approbation from the Human Resources division for each
email sent by the perpetrator until the non-conformance ceases.
- Publicly blaming the perpetrator's actions for any and all
issues within the Bikeshedding Company.
- Trout-slapping.
~lucidiot Expires August 22, 2021 [Page 6]
Bikeshed-Draft Tildepals Email Signatures February 2021
- Firing the perpetrator.
7. Security Considerations
Use of HTML in emails is known to cause security problems due to
the many technologies it can bring. This document requires
plain-text signatures to avoid those security problems.
Signatures, as human-written and human-read text, are however still
vulnerable to social engineering attacks and Information Technology
executives should consider hiring overpriced consulting services to
help them in training their collaborators against them.
8. Internationalization Considerations
It is well-known that most text encodings were designed without
non-English languages and non-Latin alphabets in mind. This document
requires the UTF-8 text encoding [RFC3629], as it already supports
most languages and alphabets and can be extended by updates to the
Unicode specification as needed.
Signatures embedded in messages of a different encoding may however
have encoding issues. It is however believed that the existing
issues with text encoding in email and in general will help prevent
users from trying to run into these issues.
9. Privacy Considerations
Until the email is sent, the sender remains in full control of their
signature, and may choose to change the signature's contents to
adapt to a particular context on a case-by-case basis.
However, by reproducing a signature, an attacker can make themselves
appear as someone else, as users might rely on the signature more
than email headers. This can be solved both by proper training from
overpriced consultants and from using technologies such as S/MIME
[RFC8551].
10. IANA Considerations
10.1. text/vnd.bikeshed.signature media type
This document registers the "text/vnd.bikeshed.signature" media type.
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: n/a
Optional parameters: charset
~lucidiot Expires August 22, 2021 [Page 7]
Bikeshed-Draft Tildepals Email Signatures February 2021
Encoding considerations: Prefer UTF-8. See Section 3 of this RFC.
Security considerations: See Section 7 of this RFC.
Interoperability considerations: TBD
Published specification: TBD
Applications that use this media type: n/a
Additional information:
Magic numbers: 2d 2d 20 0a
See Section 3 of this RFC.
File extension(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
Person & email address to contact for further information: See
Author's Address section.
Intended usage: Limited Use
Use of this format SHOULD be restricted to bikeshedding
activities.
Restrictions on usage: Bikeshedding
Author: See Author's Address section.
Change controller: See Author's Address section.
10.2. Creation of Company-Approved Advertisements Registry
This document creates a new IANA registry entitled "Company-Approved
Advertisements".
The policy for future assignments to this registry is Private Use
[RFC8126]. This registry has one field: the advertisement.
The Marketing Division of the Bikeshedding Company is the sole
maintainer of this registry, and SHOULD notify the Bikeshedders of
any change by sending a full copy of the registry contents along with
its Advertisement Directives via e-mail on the tildepals mailing
list.
This registry has no initial values.
~lucidiot Expires August 22, 2021 [Page 8]
Bikeshed-Draft Tildepals Email Signatures February 2021
10.3. Creation of E-mail Signature Protocol Abbreviations Registry
This document creates a new IANA registry entitled "E-mail Signature
Protocol Abbreviations".
The policy for future assignments to this registry is Expert Review
[RFC8126]. This registry has three fields: the abbreviation, the
protocol's full name, and a reference to the protocol's specification
or official description.
The abbreviation field SHOULD be unique. The Designated Expert MUST
ensure that the abbreviation unmistakably identifies the protocol and
matches the expected abbreviation for most users of the protocol.
Multiple protocols MAY share the same abbreviation if and only if its
userbase sees all of the protocols as being the same. Multiple
abbreviations MAY be associated to the same protocol.
Bikeshedders can request the assignation of a new abbreviation by
contacting the Designated Expert over the tildepals mailing list.
The Designated Expert MAY consult the community via a "call for
comments" before assigning an abbreviation, and SHOULD notify the
Bikeshedders of any updates to the registry, by sending an e-mail to
the tildepals mailing list.
The references field is OPTIONAL. The Designated Expert SHOULD
ensure that the referenced documents meet the "specification
required" rule, or are the most official source of information on the
protocol.
If the protocol is proprietary and it is generally referred to as its
main, or only, implementation, and the protocol's specification or
description cannot be found, the references MAY point to the most
official sources of information on the implementation.
~lucidiot Expires August 22, 2021 [Page 9]
Bikeshed-Draft Tildepals Email Signatures February 2021
The initial values for this registry are specified below:
Abbreviation Protocol References
------------ ------------------------------------------- ----------
HTTP Hypertext Transfer Protocol [RFC7230]
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
Gopher Internet Gopher Protocol [RFC1436]
Gemini Project Gemini [GEMINI]
MSN Microsoft Notification Protocol [MSNP]
IRC Internet Relay Chat [RFC1459]
[RFC2810]
[RFC2811]
[RFC2812]
[RFC2813]
[RFC7194]
Discord Discord [DISCORD]
Fedi ActivityPub [APUB]
XMPP Extensible Messaging and Presence Protocol [RFC6120]
[RFC6121]
[RFC7622]
[RFC3923]
11. References
11.1. Normative References
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
~lucidiot Expires August 22, 2021 [Page 10]
Bikeshed-Draft Tildepals Email Signatures February 2021
[RFC8551] Schaad, J., Ramsdell, B. and Turner, S.,
"Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 4.0 Message Specification", RFC 8551,
DOI 10.17487/RFC8551, April 2019,
<https://www.rfc-editor.org/info/rfc8551>.
11.2. Informative References
[APUB] Lemmer Webber, C., Tallon, J., Shepherd, E., Guy, A.,
Prodromou, E., "ActivityPub", W3C Recommendation,
January 2018, <https://www.w3.org/TR/activitypub/>.
[DISCORD] Discord, "Discord", May 2015, <https://discord.com>.
[GEMINI] Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020, <gemini://
gemini.circumlunar.space/docs/specification.gmi>
[MSNP] Mintz, M., Sayers, A., "MSN Messenger Protocol",
December 2003, <http://www.hypothetic.org/docs/msn/>
[NOTADRAFT] Kumari, W., "Just because it's an ID doesn't mean
anything... at all...", Work In Progress,
draft-wkumari-not-a-draft-10, July 2020.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC1459] Oikarinen, J., Reed, D., "Internet Relay Chat Protocol",
RFC 1459, DOI 10.17847/RFC1459, May 1993,
<https://www.rfc-editor.org/info/rfc1459>.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17847/RFC2810, April 2000,
<https://www.rfc-editor.org/info/rfc2810>.
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, DOI 10.17847/RFC2811, April 2000,
<https://www.rfc-editor.org/info/rfc2811>.
[RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol",
RFC 2812, DOI 10.17847/RFC2812, April 2000,
<https://www.rfc-editor.org/info/rfc2812>.
[RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol",
RFC 2813, DOI 10.17847/RFC2813, April 2000,
<https://www.rfc-editor.org/info/rfc2813>.
~lucidiot Expires August 22, 2021 [Page 11]
Bikeshed-Draft Tildepals Email Signatures February 2021
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object
Encryption for the Extensible Messaging and Presence
Protocol (XMPP)", RFC 3923, DOI 10.17847/RFC3923,
October 2004, <https://www.rfc-editor.org/info/rfc3923>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17847/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, DOI 10.17847/RFC6121, March 2011,
<https://www.rfc-editor.org/info/rfc6121>.
[RFC7194] Hartmann, R., "Default Port for Internet Relay Chat
(IRC) via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194,
August 2014, <https://www.rfc-editor.org/info/rfc7194>.
[RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234,
DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622,
DOI 10.17847/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
~lucidiot Expires August 22, 2021 [Page 12]
Bikeshed-Draft Tildepals Email Signatures February 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Changelog
[RFC Editor: Please remove this section before publication]
draft-signature-02
o Write an abstract
o Added the Advertisements section
o Added the "Company-Approved Advertisements" and "E-mail Signature
Protocol Abbreviations" IANA registries
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.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Expires August 22, 2021 [Page 13]

530
rfb/drafts/draft-vax-00.txt Normal file
View File

@ -0,0 +1,530 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft Bikeshedding Microsystems
Intended status: Standards Track July 26, 2021
Expires: January 26, 2022
Vaccination as a Unit Prefix
draft-vax-00
Abstract
This document introduces a new unit prefix that should be preferred
by all Bikeshedders when it is applicable; vax- and anti-vax-.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding
Microsystems Working Task Force (BM-WTF). Note that other groups may
also distribute working documents as Bikeshed-Drafts. The list of
current Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on January 26, 2022.
Copyright Notice
Copyright (c) 2021 The 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 Expires January 26, 2022 [Page 1]
Bikeshed-Draft Vax Prefix July 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ...................................3
2. New Prefixes ...................................................3
2.1. The Vax Prefix ...........................................3
2.2. The AntiVax Prefix .......................................3
2.3. The Vaxi Prefix ..........................................3
2.4. The AntiVaxi Prefix ......................................3
3. Security Considerations ........................................4
4. Internationalization Considerations ............................4
5. Privacy Considerations .........................................7
6. BANANA Considerations ..........................................7
7. References .....................................................8
7.1. Normative References ......................................8
7.2. Informative References ....................................8
Appendix A. Warranty Exclusion Statement ...........................8
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction
As you may have noticed, every human on Earth has been facing since
the end of 2019 a worldwide pandemic. This pandemic correlates with
a period of worldwide rollout of 5G NR [5GNR], which had caused a
wave of conspiracy theories over electromagnetic waves being used to
control our brains.
In an attempt to end this worldwide health crisis, multiple vaccines
have been simultaneously developed and vaccination campaigns are
being run to get them to spread out as much as possible. This has
sparked new conspiracy theories, as the anti-vaccination groups have
been very active thanks to Donald Trump's presidency of the United
States and thanks to Facebook's circlejerk-based attention-retaining
content selection. According to highly trustable media [BULLSHIT],
the vaccines provide nano-bots that can be controlled over 5G NR and
allow governments to brainwash humanity.
It has been commonly observed that anti-vaccination activists and
conspiracy theorists react very aggressively when faced with any kind
of criticism or doubt of their opinions. The Operational Security
Division of Bikeshedding Microsystems believes there is a potential
threat for our Bikeshedding Business Operations in expressing any
pro-vaccination or scientifically-validated opinion on the current
pandemic. While the pandemic provides us with unforeseen and
challenging but rewarding and profitable markets for us to bikeshed
in, the OpSec Division needs to act to prevent any damage to our
reputation and daily activities.
To avoid any issues with conspiracy theories and anti-vaccination
activists, the OpSec Division hereby enacts a new unit prefixing
system that is not too intrusive on our daily operations, but
~lucidiot Expires January 26, 2022 [Page 2]
Bikeshed-Draft Vax Prefix July 2021
provides us with plausible deniability in regards to pro-vaccination
opinions that could be expressed in any communcations from
Bikeshedding Microsystems.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. New Prefixes
Bikeshedders SHOULD use the following new unit prefixes when
expressing any quantity in the order of magnitude of billions
(10^9), in addition to regular SI unit prefixes.
2.1. The Vax Prefix
The "vax-" prefix, abbreviated "V", is equivalent to 5,000,000,000
(5E+9 or 5 * 10^9). "Vax" is a diminutive of "vaccine", and it
corresponds to 5 giga, or 5G.
2.2. The Antivax Prefix
The "antivax-" prefix, abbreviated "AV", is equivalent to
-5,000,000,000 (-5E+9 or 5 * 10^9). "Antivax" is a diminutive of
anti-vaccine and is regularly used to describe anti-vaccination
activists. It corresponds to -5 giga, or -5G.
2.3. The Vaxi Prefix
The "vaxi-" prefix, abbreviated "Vi", is equivalent to 5,368,709,120
(5 * 1024^3). This is the concatenation of the "vax-" prefix with
the binary variant of SI prefixes regularly used to express
quantities of bits and bytes, such as gibibytes (GiB). 1 ViB is
equivalent to 5 GiB.
The "vaxi-" prefix MUST only be used for vaxibytes or vaxibits.
Users of binary prefixes SHOULD consider whether using a binary
prefix instead of a standard SI prefix truly adds to the meaning of
their communication before using it.
2.4. The Antivaxi Prefix
The "antivaxi-" prefix, abbreviated "AVi", is equivalent to
-5,368,709,120 (-5 * 1024^3). This is the concatenation of the
"anti-vax-" prefix with the binary variant of SI prefixes regularly
used to express quantities of bits and bytes, such as gibibytes
(GiB). 1 AViB is equivalent to -5 GiB.
~lucidiot Expires January 26, 2022 [Page 3]
Bikeshed-Draft Vax Prefix July 2021
The "antivaxi-" prefix MUST only be used for antivaxibytes or
antivaxibits. Users of binary prefixes SHOULD consider whether using
a binary prefix instead of a standard SI prefix truly adds to the
meaning of their communication before using it.
3. Security Considerations
This document exists solely for the sake of ensuring the security of
our Bikeshedding Business Operations.
Bikeshedders that face any kind of negative interactions with
conspiracy theorists, anti-vaccination activists or anti-bikeshedding
activists MUST forward any written statements, recordings or relevant
documents related to said interactions to the Bikeshedding
Microsystems Operational Security Division.
It is RECOMMENDED to avoid replying to those interactions until a
proper reply strategy has been established by the Bikeshedding
Microsystems Operational Security Division in collaboration with the
Bikeshedding Microsystems Public Relations Division.
Bikeshedders that witness other Bikeshedders expressing agreement
with conspiracy theories or anti-vaccination arguments MUST report
said issues to the Bikeshedding Microsystems Human Resources Division
who SHOULD take appropriate action to neutralize any potential threat
to the Bikeshedding Business Operations or to the physical integrity
of the bodies of other Bikeshedders.
4. Internationalization Considerations
The following languages are known to use a word that means "vaccine"
similarly to the English word "vaccine":
- Afrikaans: vaksine
- Albanian: vaksinë
- Armenian: վակցինա (vakc'ina)
- Asturian: vacuna
- Azerbaijani: vaksin
- Belarusian: вакцы́на (vakcýna)
- Bengali: ভ্যাক্সিন (bbhakśin)
- Bulgarian: вакси́на (vaksína)
- Catalan: vaccí
- Czech: vakcína
~lucidiot Expires January 26, 2022 [Page 4]
Bikeshed-Draft Vax Prefix July 2021
- Danish: vaccine
- Dhivehi: ވެކްސިން‎ (vek̊sin̊)
- Dutch: vaccin
- Esperanto: vakcino
- Estonian: vaktsiin
- French: vaccin
- Galician: vacina
- Georgian: ვაქცინა (vakcina)
- German: Vakzine
- Hindi: वैक्सीन (vaiksīn)
- Hungarian: vakcina
- Irish: vacsaín
- Italian: vaccino
- Japanese: ワクチン (wakuchin)
- Kazakh: вакцина (vakcïna)
- Khmer: វ៉ាក់សាំង (km) (vaksang)
- Korean: 백신 (ko) (baeksin)
- Kyrgyz: вакцина (vaktsina)
- Latvian: vakcīna
- Lithuanian: vakcina
- Macedonian: вакцина (vakcina)
- Malagasy: vaksiny (mg)
- Malay: vaksin
- Mongolian: вакцин (vaktsin)
- Norman: vaccîn
- Norwegian: vaksine
~lucidiot Expires January 26, 2022 [Page 5]
Bikeshed-Draft Vax Prefix July 2021
- Malayalam: വാക്സിൻ (vāksin)
- Persian: واکسن‎ (vâksin)
- Polish: wakcyna
- Portuguese: vacina
- Romanian: vaccin
- Russian: вакци́на (vakcína)
- Serbo-Croatian: вакци́на, vakcína
- Slovak: vakcína
- Spanish: vacuna
- Swedish: vaccin
- Tajik: ваксина (vaksina)
- Telugu: వ్యాక్సిన్ (vyāksin), వ్యాక్సీన్ (vyāksīn)
- Thai: วัคซีน (wák-siin)
- Turkmen: waksina
- Ukrainian: вакци́на (vakcýna)
- Urdu: ویکسین‎ (vaiksīn)
- Uyghur: ۋاكسىنا‎ (waksina)
- Uzbek: vaktsina, vaksina
- Vietnamese: vắc-xin
- Yakut: вакцина (vaktsina)
- Yiddish: וואַקצין‎ (vaktsin)
Considering the large amount of languages that have words similar in
consonance with the English word "vaccine", the fact that vaccination
has been in the news worldwide for many months, and the fact that
"antivax" is being used in any language to describe anti-vaccination
activists as those are mostly United States-based, it is safe to
assume that these new prefixes will be widely understood by our
international branches.
~lucidiot Expires January 26, 2022 [Page 6]
Bikeshed-Draft Vax Prefix July 2021
5. Privacy Considerations
This document does not enforce the use of the new prefixes on any
private communication, unless those communications have the potential
to be leaked or when a Bikeshedder is under investigation for
possible threats to Bikeshedding Business Operations or to the
corporeal forms of fellow Bikeshedders by the Bikeshedding
Microsystems Human Resources Division.
Reporting of potential behavioral issues of a Bikeshedder to the
Bikeshedding Microsystems Human Resources Division SHOULD be made
through an anonymous reporting process. The Bikeshedding
Microsystems Human Resources Division is encouraged to define and
standardize this reporting process as another Request for
Bikeshedding as soon as possible.
Sharing writings, recordings or any document relevant to a private
interaction in which a Bikeshedder manifests behavior that could lead
to potential threats to Bikeshedding Business Operations or to the
corporeal forms of fellow Bikeshedders, or in which an external human
being manifests a negative reaction to a potential pro-vaccination
opinion expressed by Bikeshedding Microsystems through any of its
public communcations, with the Bikeshedding Microsystems Human
Resources Division or the Bikeshedding Microsystems Operational
Security Division, MAY be made after a reviewing step in which the
reporter blacks out, or mutes, any portion of the writings,
recordings or other relevant documents that are considered to be too
sensitive to be shared.
SHOULD any censored portion of a document become critical to an
investigation made by the Bikeshedding Microsystems Human Resources
Division or to the determination of a response process by the
Bikeshedding Microsystems Operational Security Division, the
respective divisions MAY request the approval of the Bikeshedding
Microsystems Data Protection Officer to make a declassification of
the relevant censoring REQUIRED. The initial reporter MUST send
a new copy of the document with the censoring removed in a timely
manner or face appropriate sanctions from the Bikeshedding
Microsystems Human Resources Division.
6. BANANA Considerations
This document creates a new BANANA registry entitled "Unit Prefixes".
The policy for future assignments to this registry is RFB Required
[RFC8216]. This registry has four fields: the prefix's name, the
prefix's abbreviation, the prefix's multiplier, and a reference to
one or more Request for Bikesheddings defining the prefix.
The prefix name SHOULD be unique. Multiple prefixes MAY share the
same name if and only if they cannot be both used simultaneously for
the same unit, e.g. if one prefix applies only to one unit, and
~lucidiot Expires January 26, 2022 [Page 7]
Bikeshed-Draft Vax Prefix July 2021
another only to a different unit.
The prefix abbreviation SHOULD be unique. Multiple prefixes MAY
share the same abbreviation if and only if they cannot be both used
simultaneously for the same unit, e.g. if one prefix applies only to
one unit, and another only to a different unit.
The prefix multiplier MUST be a finite number.
The initial values for this registry are specified below:
Name Abbreviation Multiplier RFB
-------------------------------- ------------ -------------- --------
Vax V 5,000,000,000 This RFB
Antivax AV -5,000,000,000 This RFB
Vaxi Vi 5,368,709,120 This RFB
Antivaxi AVi -5,368,709,120 This RFB
7. References
7.1. Normative References
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References
[5GNR] 3rd Generation Partnership Project, "3GPP specification
series: 38series",
<https://www.3gpp.org/DynaReport/38-series.htm>
[BULLSHIT] Freeman, M., "The Coronavirus 5G Connection and Coverup",
The Freedom Articles, February 2020,
<https://thefreedomarticles.com/coronavirus-5g-connection
-coverup-vaccines-transhumanism/>
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
~lucidiot Expires January 26, 2022 [Page 8]
Bikeshed-Draft Vax Prefix July 2021
Acknowledgements
The author would like to thank Hiroshi Nakamura for sharing the idea
of the DITP and DIRP and developing decentralized technologies before
they truly came to life.
The author would like to thank Masayoshi Takahashi for providing an
English summary of the Japanese last-modified-time detection agents
in 1999.
Finally, the author would like to thank the Internet Archive and all
the contributors, donators, voulunteers involved, as without them
this research would have never been possible.
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 Expires January 26, 2022 [Page 9]

530
rfb/drafts/draft-vax-01.txt Normal file
View File

@ -0,0 +1,530 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft Bikeshedding Microsystems
Intended status: Standards Track July 30, 2021
Expires: January 30, 2022
Vaccination as a Unit Prefix
draft-vax-01
Abstract
This document introduces a new unit prefix that should be preferred
by all Bikeshedders when it is applicable; vax- and anti-vax-.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding
Microsystems Working Task Force (BM-WTF). Note that other groups may
also distribute working documents as Bikeshed-Drafts. The list of
current Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on January 30, 2022.
Copyright Notice
Copyright (c) 2021 The 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 Expires January 30, 2022 [Page 1]
Bikeshed-Draft Vax Prefix July 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ...................................3
2. New Prefixes ...................................................3
2.1. The Vax Prefix ...........................................3
2.2. The AntiVax Prefix .......................................3
2.3. The Vaxi Prefix ..........................................3
2.4. The AntiVaxi Prefix ......................................3
3. Security Considerations ........................................4
4. Internationalization Considerations ............................4
5. Privacy Considerations .........................................7
6. BANANA Considerations ..........................................7
7. References .....................................................8
7.1. Normative References ......................................8
7.2. Informative References ....................................8
Appendix A. Warranty Exclusion Statement ...........................8
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction
As you may have noticed, every human on Earth has been facing since
the end of 2019 a worldwide pandemic. This pandemic correlates with
a period of worldwide rollout of 5G NR [5GNR], which had caused a
wave of conspiracy theories over electromagnetic waves being used to
control our brains.
In an attempt to end this worldwide health crisis, multiple vaccines
have been simultaneously developed and vaccination campaigns are
being run to get them to spread out as much as possible. This has
sparked new conspiracy theories, as the anti-vaccination groups have
been very active thanks to Donald Trump's presidency of the United
States and thanks to Facebook's circlejerk-based attention-retaining
content selection. According to highly trustable media [BULLSHIT],
the vaccines provide nano-bots that can be controlled over 5G NR and
allow governments to brainwash humanity.
It has been commonly observed that anti-vaccination activists and
conspiracy theorists react very aggressively when faced with any kind
of criticism or doubt of their opinions. The Operational Security
Division of Bikeshedding Microsystems believes there is a potential
threat for our Bikeshedding Business Operations in expressing any
pro-vaccination or scientifically-validated opinion on the current
pandemic. While the pandemic provides us with unforeseen and
challenging but rewarding and profitable markets for us to bikeshed
in, the OpSec Division needs to act to prevent any damage to our
reputation and daily activities.
To avoid any issues with conspiracy theories and anti-vaccination
activists, the OpSec Division hereby enacts a new unit prefixing
system that is not too intrusive on our daily operations, but
~lucidiot Expires January 30, 2022 [Page 2]
Bikeshed-Draft Vax Prefix July 2021
provides us with plausible deniability in regards to pro-vaccination
opinions that could be expressed in any communcations from
Bikeshedding Microsystems.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. New Prefixes
Bikeshedders SHOULD use the following new unit prefixes when
expressing any quantity in the order of magnitude of billions
(10^9), in addition to regular SI unit prefixes.
2.1. The Vax Prefix
The "vax-" prefix, abbreviated "V", is equivalent to 5,000,000,000
(5E+9 or 5 * 10^9). "Vax" is a diminutive of "vaccine", and it
corresponds to 5 giga, or 5G.
2.2. The Antivax Prefix
The "antivax-" prefix, abbreviated "AV", is equivalent to
-5,000,000,000 (-5E+9 or 5 * 10^9). "Antivax" is a diminutive of
anti-vaccine and is regularly used to describe anti-vaccination
activists. It corresponds to -5 giga, or -5G.
2.3. The Vaxi Prefix
The "vaxi-" prefix, abbreviated "Vi", is equivalent to 5,368,709,120
(5 * 1024^3). This is the concatenation of the "vax-" prefix with
the binary variant of SI prefixes regularly used to express
quantities of bits and bytes, such as gibibytes (GiB). 1 ViB is
equivalent to 5 GiB.
The "vaxi-" prefix MUST only be used for vaxibytes or vaxibits.
Users of binary prefixes SHOULD consider whether using a binary
prefix instead of a standard SI prefix truly adds to the meaning of
their communication before using it.
2.4. The Antivaxi Prefix
The "antivaxi-" prefix, abbreviated "AVi", is equivalent to
-5,368,709,120 (-5 * 1024^3). This is the concatenation of the
"anti-vax-" prefix with the binary variant of SI prefixes regularly
used to express quantities of bits and bytes, such as gibibytes
(GiB). 1 AViB is equivalent to -5 GiB.
~lucidiot Expires January 30, 2022 [Page 3]
Bikeshed-Draft Vax Prefix July 2021
The "antivaxi-" prefix MUST only be used for antivaxibytes or
antivaxibits. Users of binary prefixes SHOULD consider whether using
a binary prefix instead of a standard SI prefix truly adds to the
meaning of their communication before using it.
3. Security Considerations
This document exists solely for the sake of ensuring the security of
our Bikeshedding Business Operations.
Bikeshedders that face any kind of negative interactions with
conspiracy theorists, anti-vaccination activists or anti-bikeshedding
activists MUST forward any written statements, recordings or relevant
documents related to said interactions to the Bikeshedding
Microsystems Operational Security Division.
It is RECOMMENDED to avoid replying to those interactions until a
proper reply strategy has been established by the Bikeshedding
Microsystems Operational Security Division in collaboration with the
Bikeshedding Microsystems Public Relations Division.
Bikeshedders that witness other Bikeshedders expressing agreement
with conspiracy theories or anti-vaccination arguments MUST report
said issues to the Bikeshedding Microsystems Human Resources Division
who SHOULD take appropriate action to neutralize any potential threat
to the Bikeshedding Business Operations or to the physical integrity
of the bodies of other Bikeshedders.
4. Internationalization Considerations
The following languages are known to use a word that means "vaccine"
similarly to the English word "vaccine":
- Afrikaans: vaksine
- Albanian: vaksinë
- Armenian: վակցինա (vakc'ina)
- Asturian: vacuna
- Azerbaijani: vaksin
- Belarusian: вакцы́на (vakcýna)
- Bengali: ভ্যাক্সিন (bbhakśin)
- Bulgarian: вакси́на (vaksína)
- Catalan: vaccí
- Czech: vakcína
~lucidiot Expires January 30, 2022 [Page 4]
Bikeshed-Draft Vax Prefix July 2021
- Danish: vaccine
- Dhivehi: ވެކްސިން‎ (vek̊sin̊)
- Dutch: vaccin
- Esperanto: vakcino
- Estonian: vaktsiin
- French: vaccin
- Galician: vacina
- Georgian: ვაქცინა (vakcina)
- German: Vakzine
- Hindi: वैक्सीन (vaiksīn)
- Hungarian: vakcina
- Irish: vacsaín
- Italian: vaccino
- Japanese: ワクチン (wakuchin)
- Kazakh: вакцина (vakcïna)
- Khmer: វ៉ាក់សាំង (km) (vaksang)
- Korean: 백신 (ko) (baeksin)
- Kyrgyz: вакцина (vaktsina)
- Latvian: vakcīna
- Lithuanian: vakcina
- Macedonian: вакцина (vakcina)
- Malagasy: vaksiny (mg)
- Malay: vaksin
- Mongolian: вакцин (vaktsin)
- Norman: vaccîn
- Norwegian: vaksine
~lucidiot Expires January 30, 2022 [Page 5]
Bikeshed-Draft Vax Prefix July 2021
- Malayalam: വാക്സിൻ (vāksin)
- Persian: واکسن‎ (vâksin)
- Polish: wakcyna
- Portuguese: vacina
- Romanian: vaccin
- Russian: вакци́на (vakcína)
- Serbo-Croatian: вакци́на, vakcína
- Slovak: vakcína
- Spanish: vacuna
- Swedish: vaccin
- Tajik: ваксина (vaksina)
- Telugu: వ్యాక్సిన్ (vyāksin), వ్యాక్సీన్ (vyāksīn)
- Thai: วัคซีน (wák-siin)
- Turkmen: waksina
- Ukrainian: вакци́на (vakcýna)
- Urdu: ویکسین‎ (vaiksīn)
- Uyghur: ۋاكسىنا‎ (waksina)
- Uzbek: vaktsina, vaksina
- Vietnamese: vắc-xin
- Yakut: вакцина (vaktsina)
- Yiddish: וואַקצין‎ (vaktsin)
Considering the large amount of languages that have words similar in
consonance with the English word "vaccine", the fact that vaccination
has been in the news worldwide for many months, and the fact that
"antivax" is being used in any language to describe anti-vaccination
activists as those are mostly United States-based, it is safe to
assume that these new prefixes will be widely understood by our
international branches.
~lucidiot Expires January 30, 2022 [Page 6]
Bikeshed-Draft Vax Prefix July 2021
5. Privacy Considerations
This document does not enforce the use of the new prefixes on any
private communication, unless those communications have the potential
to be leaked or when a Bikeshedder is under investigation for
possible threats to Bikeshedding Business Operations or to the
corporeal forms of fellow Bikeshedders by the Bikeshedding
Microsystems Human Resources Division.
Reporting of potential behavioral issues of a Bikeshedder to the
Bikeshedding Microsystems Human Resources Division SHOULD be made
through an anonymous reporting process. The Bikeshedding
Microsystems Human Resources Division is encouraged to define and
standardize this reporting process as another Request for
Bikeshedding as soon as possible.
Sharing writings, recordings or any document relevant to a private
interaction in which a Bikeshedder manifests behavior that could lead
to potential threats to Bikeshedding Business Operations or to the
corporeal forms of fellow Bikeshedders, or in which an external human
being manifests a negative reaction to a potential pro-vaccination
opinion expressed by Bikeshedding Microsystems through any of its
public communcations, with the Bikeshedding Microsystems Human
Resources Division or the Bikeshedding Microsystems Operational
Security Division, MAY be made after a reviewing step in which the
reporter blacks out, or mutes, any portion of the writings,
recordings or other relevant documents that are considered to be too
sensitive to be shared.
SHOULD any censored portion of a document become critical to an
investigation made by the Bikeshedding Microsystems Human Resources
Division or to the determination of a response process by the
Bikeshedding Microsystems Operational Security Division, the
respective divisions MAY request the approval of the Bikeshedding
Microsystems Data Protection Officer to make a declassification of
the relevant censoring REQUIRED. The initial reporter MUST send
a new copy of the document with the censoring removed in a timely
manner or face appropriate sanctions from the Bikeshedding
Microsystems Human Resources Division.
6. BANANA Considerations
This document creates a new BANANA registry entitled "Unit Prefixes".
The policy for future assignments to this registry is RFB Required
[RFC8216]. This registry has four fields: the prefix's name, the
prefix's abbreviation, the prefix's multiplier, and a reference to
one or more Request for Bikesheddings defining the prefix.
The prefix name SHOULD be unique. Multiple prefixes MAY share the
same name if and only if they cannot be both used simultaneously for
the same unit, e.g. if one prefix applies only to one unit, and
~lucidiot Expires January 30, 2022 [Page 7]
Bikeshed-Draft Vax Prefix July 2021
another only to a different unit.
The prefix abbreviation SHOULD be unique. Multiple prefixes MAY
share the same abbreviation if and only if they cannot be both used
simultaneously for the same unit, e.g. if one prefix applies only to
one unit, and another only to a different unit.
The prefix multiplier MUST be a finite number.
The initial values for this registry are specified below:
Name Abbreviation Multiplier RFB
-------------------------------- ------------ -------------- --------
Vax V 5,000,000,000 This RFB
Antivax AV -5,000,000,000 This RFB
Vaxi Vi 5,368,709,120 This RFB
Antivaxi AVi -5,368,709,120 This RFB
7. References
7.1. Normative References
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References
[5GNR] 3rd Generation Partnership Project, "3GPP specification
series: 38series",
<https://www.3gpp.org/DynaReport/38-series.htm>
[BULLSHIT] Freeman, M., "The Coronavirus 5G Connection and Coverup",
The Freedom Articles, February 2020,
<https://thefreedomarticles.com/coronavirus-5g-connection
-coverup-vaccines-transhumanism/>
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
~lucidiot Expires January 30, 2022 [Page 8]
Bikeshed-Draft Vax Prefix July 2021
Acknowledgements
The author would like to thank wsinatra for encouraging the
implementation of the vaccine unit prefixes.
The author would like to thank and congratulate all the Bikeshedders
for making it through this pandemic.
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 Expires January 30, 2022 [Page 9]

471
rfb/drafts/draft-weed-00.txt Normal file
View File

@ -0,0 +1,471 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Informational April 1, 2021
Expires: October 1, 2021
Web Feeds (WEED)
draft-weed-00
Abstract
Members of the Tilde Pals mailing list have created a new community
known as the Weeds. This memo formalizes the practices of this
community to help The Bikeshedding Company find potential
bikeshedding opportunities in this new trend.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on September 26, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Informational [Page 1]
Bikeshed-Draft Web Feeds (WEED) April 2021
Table of Contents
1. Introduction ....................................................2
1.1. Notational Conventions .....................................2
2. Concepts ........................................................2
2.1. Weed Abbreviation ..........................................2
2.2. Web Feeds ..................................................3
2.3. Weed Users .................................................3
2.4. Weed Ring ..................................................3
3. Best Practices ..................................................4
3.1. Linking ....................................................4
3.2. HTTP Servers ...............................................4
3.3. Multi-User Unix System Hosting .............................4
4. Security COnsiderations .........................................5
5. Internationalization Considerations .............................5
6. Privacy Considerations ..........................................5
7. IANA Considerations .............................................5
8. References ......................................................6
Appendix A. Warranty Exclusion Statement ...........................7
Acknowledgements ...................................................8
Author's Address ...................................................8
1. Introduction
This Request for Comments (RFC) is a formalisation of the basic
rules that govern the community known as Weeds, a project developed
outside of the Bikeshedding Company.
This RFC does not define a standard, but only represents the general
consensus among the Weed Dealers and Consumers, to increase its
accessibility for newcomers. The Bikeshedding Company believes that
this project has a lot of potential for producing a high quality of
bikeshedding in markets the company has not explored before.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Concepts
2.1. Weed Abbreviation
The users of Project Gemini [GEMINI] have coined the term "gemlog"
to refer to the Gemini equivalent of a blog, as a "blog" is the
diminutive of "web log", and a gemlog is not on the web.
~lucidiot Informational [Page 2]
Bikeshed-Draft Web Feeds (WEED) April 2021
Similarly, a Weed is a web feed. A weed allows its creator to
publish content similar to what would be published on a blog, but
the content is not intended to be seen in a web browser; instead, it
should be viewed in a feed reader. The web log is therefore closer
to a web feed.
2.2. Web Feeds
A Web Feed is a syndication feed provided in a format such as RDF
Site Summary [RSS1], Really Simple Syndication [RSS2], Atom
[RFC4287], Channel Definition Format [CDF], JSON Feed [JSONFEED],
Meta Content Framework [MCF], Hina-Di [HINA], or Last modified
Information Relaying Specification [LIRS], over an open HTTP, HTTPS
[RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], Gopher
[RFC1436] or Gemini [GEMINI] server. This list is not exhaustive.
The contents of a Web Feed MUST NOT be easily readable in a web
browser that does not have built-in support for the weed's format.
Most modern browsers have removed support for RSS and Atom. CDF has
been dropped since 2009 and JSON Feed has not seen much adoption.
Publishing the contents of a weed to a server such as a version
control system with a web interface counts as violating the above
rule. Version control systems without web interfaces, or whose web
interfaces do not allow access to the weed to users outside of the
Weed Community, are acceptable.
2.3. Weed Users
A weed content writer is known as a Weed Dealer, as a reference to
the recreative substance. Similarly, a reader is known as a Weed
Consumer. Most Weed users are both Dealers and Consumers, and all
users are strongly encouraged to interact with each other.
2.4. Weed Ring
The Weed Ring is a technique allowing Weed Consumers to find other
Weed Dealers. A Weed Dealer is encouraged to share links to other
Weed Dealers they know of in their own Weed, allowing Consumers to
read the feed to find other Dealers and ensure a newcomer to the
community is not forgotten, or missed, by everyone else.
Weed Dealers can share other feeds by many means:
- Creating an Outline Processor Markup Language [OPML] file which
references the feeds in "rss" outline types, then linking to this
file from inside one of their published articles.
- Using the proposed Subscription module [MODSUB] of RSS 1.0 to
denote other channels in the RSS feed itself.
~lucidiot Informational [Page 3]
Bikeshed-Draft Web Feeds (WEED) April 2021
- Using the "related" link relation type in Atom to link to other
channels in an Atom feed.
- Using the Channel Definition Format's channel nesting feature.
- Using the Hina-Di entity block propagation feature.
- Linking to the related feeds in an item of a feed of any format,
in a way that can be read and understood manually by a user.
The Weed Ring is also known as the Daisy Chain.
3. Best Practices
3.1. Linking
Linking to weeds, or to files internal to a weed on a medium other
than another weed, or another file internal to a weed, MUST NOT be
done without the explicit consent of the Weed Dealer.
An exception can be made to this rule if the link is sent to a
community, or over a technology, where it can only be read by a
group of Weed users, a group of Weed non-users trusted by both the
Weed Dealer and the author sharing the link, or a group made of both
of the aforementioned categories. Examples include the Bikeshedding
Company, the Tilde Pals, and the Flying Basement.
3.2. HTTP Servers
The contents of the directory that holds the weed and any of its
related files SHOULD NOT be listable, to make the discovery of the
weed less likely.
An additional layer of security through obscurity can be achieved in
servers capable of dynamic webpage generation, for example servers
using CGI [RFC3875], by applying restrictions on user agents to block
web browsers.
3.3. Multi-User Unix System Hosting
Many weeds are hosted on tildes, pubnixes or other multi-user Unix
or Unix-derived systems. Weeds hosted on those systems SHOULD be
properly protected against discovery by third parties from inside the
system to ensure the invisible state of weeds. Such a level of
protection can be achieved using file permissions and access control
lists:
- Make the weed's parent directory and any of its contents only
accessible to the owner and the HTTP server.
~lucidiot Informational [Page 4]
Bikeshed-Draft Web Feeds (WEED) April 2021
- Make the weed's directory and any sub-directories readable only by
the owner; this makes reading a particular file possible, but not
listing the available files in a directory.
4. Internationalization Considerations
Many syndication formats that could be used for Weeds use old text
encodings that may not be displayed properly by modern systems or
allow encoding any alphabet or any language. When a format uses XML,
it is RECOMMENDED to specify its encoding using the encoding
attribute of XML declarations:
<?xml version="1.0" encoding="utf-8"?>
For text formats, the charset parameter [RFC2046] can be used to
specify the encoding, if it differs from US-ASCII.
UTF-8 is the preferred encoding. If a format's specification allows
using UTF-8, it SHOULD be used, even if the specification says a
different encoding is preferred. If a format's specification
requires a different encoding, that encoding MUST be used.
If a format's specification does not indicate any encoding, then
UTF-8 MUST be used.
5. Security and Privacy Considerations
The Weed community has the potential to create a false sense of
privacy in inexperienced Weed Dealers, who might think nothing
published in a weed might ever exit it and might disclose private
information that they wished to only share to the community and not
to the rest of the Internet.
It is believed that three factors will be able to contribute to
minimizing those risks without requiring a technical change:
- The complexity of writing a syndication feed by hand.
- The desire to keep the Tilde Pals community, from which come all
of the Weed Dealers and Consumers, small enough to remain
human-sized.
- The trust and cooperation encouraged within the Tilde Pals
community, empowering more privacy-conscious users to warn their
fellow less-privacy-conscious users.
6. IANA Considerations
This document has no IANA actions.
~lucidiot Informational [Page 5]
Bikeshed-Draft Web Feeds (WEED) April 2021
7. References
[CDF] Ellerman, C., "Channel Definition Format (CDF)", W3C
Note NOTE-CDFsubmit, March 1997,
<https://www.w3.org/TR/NOTE-CDFsubmit.html>.
[GEMINI] Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020, <gemini://
gemini.circumlunar.space/docs/specification.gmi>
[HINA] kohgushi, "Asahina-Antenna meta data format version 2.2
(HINA/2.2)", Revision 0.13, July 2002,
<https://envs.net/~lucidiot/hina/hina2_2-rev0_13.html>.
[JSONFEED] Simmons, B. and M. Reece, "JSON Feed Version 1.1",
August 2020, <https://jsonfeed.org/version/1.1>.
[LIRS] Hiya, "Last modified Information Relaying
Specification", Version 2.1, December 2001,
<http://aniki.haun.org/natsu/LIRS.html>.
[MCF] Guka, R. V., and T. Bray, "Meta Content Framework Using
XML", W3C Note MCF-XML-970624, June 1997,
<https://www.w3.org/TR/NOTE-MCF-XML-970624/>.
[MODSUB] Burton, K., "RDF Site Summary 1.0 Modules:
Subscription", July 2002,
<http://web.resource.org/rss/1.0/modules/subscription/>.
[OPML] Winer, D., "OPML 2.0", November 2007,
<http://dev.opml.org/spec2.html>.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC2046] Freed, N., Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, DOI
10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC3875] Robinson, D., Coar, K., "The Common Gateway Interface
(CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875,
October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC4287] Nottingham, M., Sayre, R., "The Atom Syndication
Format", RFC 4287, DOI 10.17487/RFC4287, December 2005,
<https://www.rfc-editor.org/info/rfc4287>.
~lucidiot Informational [Page 6]
Bikeshed-Draft Web Feeds (WEED) April 2021
[RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234,
DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RSS1] Beged-Dov, G., Brickley, D., Dornfest, R., Davis, I.,
Dodds, L., Eisenzopf, J., Galbraith, D., Guha, R. V.,
MacLeod, K., Miller, E., Swartz, A. and E. van der
Vlist, "RDF Site Summary (RSS) 1.0", December 2000,
<http://purl.org/rss/1.0/spec>.
[RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version
2.0.11, March 2009,
<https://www.rss-board.org/rss-specification>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
~lucidiot Informational [Page 7]
Bikeshed-Draft Web Feeds (WEED) April 2021
Acknowledgements
The author would like to thank ~dozens for initiating the Weed
community.
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.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Informational [Page 8]

589
rfb/drafts/draft-weed-01.txt Normal file
View File

@ -0,0 +1,589 @@
Bikeshedding Working Group ~lucidiot, Ed.
Bikeshed-Draft The Bikeshedding Company
Intended status: Informational April 2, 2021
Expires: October 2, 2021
Web Feeds (WEED)
draft-weed-01
Abstract
Members of the Tilde Pals mailing list have created a new community
known as the Weeds. This memo formalizes the practices of this
community to help The Bikeshedding Company find potential
bikeshedding opportunities in this new trend.
Status of This Memo
This Bikeshed-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bikeshed-Drafts are working documents of the Bikeshedding Company
Working Task Force (BC-WTF). Note that other groups may also
distribute working documents as Bikeshed-Drafts. The list of current
Bikeshed-Drafts does not exist.
Bikeshed-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Bikeshed-Drafts as reference
material or to cite them other than as "work in progress."
This Bikeshed-Draft will expire on October 2, 2021.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Expires October 2, 2021 [Page 1]
Bikeshed-Draft Web Feeds (WEED) April 2021
Table of Contents
1. Introduction ....................................................2
1.1. Notational Conventions .....................................2
2. Concepts ........................................................3
2.1. Weed Abbreviation ..........................................3
2.2. Web Feeds ..................................................3
2.3. Weed Users .................................................3
2.4. Weed Ring ..................................................3
2.5. Sprout .....................................................4
3. Best Practices ..................................................4
3.1. Linking ....................................................4
3.2. HTTP Servers ...............................................4
3.3. Multi-User Unix System Hosting .............................5
3.4. Threading ..................................................5
3.5. RSS Considerations .........................................5
4. Internationalization Considerations .............................5
5. Security and Privacy Considerations .............................6
6. BANANA Considerations ...........................................6
6.1. Registration of an E-mail Signature Protocol Abbreviation ..6
6.2. Creation of Known Weeds Registry ...........................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Warranty Exclusion Statement ...........................9
Appendix B. Changelog ..............................................9
Acknowledgements ..................................................10
Author's Address ..................................................10
1. Introduction
This Request for Comments (RFC) is a formalisation of the basic
rules that govern the community known as Weeds, a project developed
outside of the Bikeshedding Company.
This RFC does not define a standard, but only represents the general
consensus among the Weed Dealers and Consumers, to increase its
accessibility for newcomers. The Bikeshedding Company believes that
this project has a lot of potential for producing a high quality of
bikeshedding in markets the company has not explored before.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Expires October 2, 2021 [Page 2]
Bikeshed-Draft Web Feeds (WEED) April 2021
2. Concepts
2.1. Weed Abbreviation
The users of Project Gemini [GEMINI] have coined the term "gemlog"
to refer to the Gemini equivalent of a blog, as a "blog" is the
diminutive of "web log", and a gemlog is not on the web.
Similarly, a Weed is a web feed. A weed allows its creator to
publish content similar to what would be published on a blog, but
the content is not intended to be seen in a web browser; instead, it
should be viewed in a feed reader. The web log is therefore closer
to a web feed.
2.2. Web Feeds
A Web Feed is a syndication feed provided in a format such as RDF
Site Summary [RSS1], Really Simple Syndication [RSS2], Atom
[RFC4287], Channel Definition Format [CDF], JSON Feed [JSONFEED],
Meta Content Framework [MCF], Hina-Di [HINA], or Last modified
Information Relaying Specification [LIRS], over an open HTTP, HTTPS
[RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], Gopher
[RFC1436] or Gemini [GEMINI] server. This list is not exhaustive.
The contents of a Web Feed MUST NOT be easily readable in a web
browser that does not have built-in support for the weed's format.
Most modern browsers have removed support for RSS and Atom. CDF has
been dropped since 2009 and JSON Feed has not seen much adoption.
Publishing the contents of a weed to a server such as a version
control system with a web interface counts as violating the above
rule. Version control systems without web interfaces, or whose web
interfaces do not allow access to the weed to users outside of the
Weed Community, are acceptable.
2.3. Weed Users
A weed content writer is known as a Weed Dealer, as a reference to
the recreative substance. Similarly, a reader is known as a Weed
Consumer. Most Weed users are both Dealers and Consumers, and all
users are strongly encouraged to interact with each other.
2.4. Weed Ring
The Weed Ring is a technique allowing Weed Consumers to find other
Weed Dealers. A Weed Dealer is encouraged to share links to other
Weed Dealers they know of in their own Weed, allowing Consumers to
read the feed to find other Dealers and ensure a newcomer to the
community is not forgotten, or missed, by everyone else.
Weed Dealers can share other feeds by many means:
~lucidiot Expires October 2, 2021 [Page 3]
Bikeshed-Draft Web Feeds (WEED) April 2021
- Creating an Outline Processor Markup Language [OPML] file which
references the feeds in "rss" outline types, then linking to this
file from inside one of their published articles.
- Using the proposed Subscription module [MODSUB] of RSS 1.0 to
denote other channels in the RSS feed itself.
- Using the "related" link relation type in Atom to link to other
channels in an Atom feed.
- Using the Channel Definition Format's channel nesting feature.
- Using the Hina-Di entity block propagation feature.
- Linking to the related feeds in an item of a feed of any format,
in a way that can be read and understood manually by a user.
Weed Dealers that share other feeds SHOULD include all the weeds of
the Known Weeds IANA registry
The Weed Ring is also known as the Daisy Chain.
2.5. Sprout
A Sprout is a single weed post, item, article, published in a Weed.
3. Best Practices
3.1. Linking
Linking to weeds, or to files internal to a weed on a medium other
than another weed, or another file internal to a weed, MUST NOT be
done without the explicit consent of the Weed Dealer.
An exception can be made to this rule if the link is sent to a
community, or over a technology, where it can only be read by a
group of Weed users, a group of Weed non-users trusted by both the
Weed Dealer and the author sharing the link, or a group made of both
of the aforementioned categories. Examples include the Bikeshedding
Company, the Tilde Pals, and the Flying Basement.
3.2. HTTP Servers
The contents of the directory that holds the weed and any of its
related files SHOULD NOT be listable, to make the discovery of the
weed less likely.
An additional layer of security through obscurity can be achieved in
servers capable of dynamic webpage generation, for example servers
using CGI [RFC3875], by applying restrictions on user agents to block
web browsers.
~lucidiot Expires October 2, 2021 [Page 4]
Bikeshed-Draft Web Feeds (WEED) April 2021
3.3. Multi-User Unix System Hosting
Many weeds are hosted on tildes, pubnixes or other multi-user Unix
or Unix-derived systems. Weeds hosted on those systems SHOULD be
properly protected against discovery by third parties from inside the
system to ensure the invisible state of weeds. Such a level of
protection can be achieved using file permissions and access control
lists:
- Make the weed's parent directory and any of its contents only
accessible to the owner and the HTTP server.
- Make the weed's directory and any sub-directories readable only by
the owner; this makes reading a particular file possible, but not
listing the available files in a directory.
3.4. Threading
As Weeds form a rather tight-knit community, using a Sprout to reply
to another Sprout is a common and generally encouraged practice.
Most syndication formats do not specify ways to indicate a sprout
that another sprout replies to, or ways to refer to a single sprout
in a weed when sprouts do not have permalinks. Most formats will
usually refer to the HTML page that an item links to, but most weeds
do not have any links since everything is syndication-only.
The Atom Threading extensions [RFC4685] SHOULD be used in all
XML-based syndication formats that allow namespace extensions to
specify replies.
3.5. RSS Considerations
Weeds using the Really Simple Syndication or RDF Site Summary formats
SHOULD include the <guid> tag to allow other Weed Dealers to reply to
their sprouts or to avoid issues when an existing sprout is updated.
4. Internationalization Considerations
Many syndication formats that could be used for Weeds use old text
encodings that may not be displayed properly by modern systems or
allow encoding any alphabet or any language. When a format uses XML,
it is RECOMMENDED to specify its encoding using the encoding
attribute of XML declarations:
<?xml version="1.0" encoding="utf-8"?>
For text formats, the charset parameter [RFC2046] can be used to
specify the encoding, if it differs from US-ASCII.
UTF-8 [RFC3629] is the preferred encoding. If a format's
specification allows using UTF-8, it SHOULD be used, even if the
~lucidiot Expires October 2, 2021 [Page 5]
Bikeshed-Draft Web Feeds (WEED) April 2021
specification says a different encoding is preferred. If a format's
specification requires a different encoding, that encoding MUST be
used. If a format's specification does not indicate any encoding,
then UTF-8 MUST be used.
5. Security and Privacy Considerations
The Weed community has the potential to create a false sense of
privacy in inexperienced Weed Dealers, who might think nothing
published in a weed might ever exit it and might disclose private
information that they wished to only share to the community and not
to the rest of the Internet.
It is believed that three factors will be able to contribute to
minimizing those risks without requiring a technical change:
- The complexity of writing a syndication feed by hand.
- The desire to keep the Tilde Pals community, from which come all
of the Weed Dealers and Consumers, small enough to remain
human-sized.
- The trust and cooperation encouraged within the Tilde Pals
community, empowering more privacy-conscious users to warn their
fellow less-privacy-conscious users.
6. BANANA Considerations
6.1. Registration of an E-mail Signature Protocol Abbreviation
This document registers a new item to the "E-mail Signature Protocol
Abbreviations" registry:
Abbreviation: WEED
Protocol name: Web Feeds
Protocol specification: This RFC
6.2. Creation of Known Weeds Registry
This document creates a new BANANA registry entitled "Known Weeds".
The policy for future assignments to this registry is First Come
First Served [RFC8126]. This registry has three fields: the Weed
URL, the syndication format, and the change controller.
The BANANA SHOULD notify the Bikeshedders of any updates to the
registry by sending an e-mail to the Tilde Pals mailing list along
with a reminder of the registration process.
The Weed URL MUST be unique, and MUST be a valid URL pointing to a
~lucidiot Expires October 2, 2021 [Page 6]
Bikeshed-Draft Web Feeds (WEED) April 2021
Weed. The syndication format is an arbitrary string, meant for Weed
Consumers to more easily tell which Weeds they can follow depending
on their own feed reader's supported formats when accessing the
registry. The Change Controller is the only person allowed to
contact IANA and request a later change to a Known Weed.
The initial values for this registry are specified below:
URL Format Change Controller
------------------------------------------- ------ -----------------
[REDACTED] RSS2 ~dozens
[REDACTED] RSS2 ~lucidiot
[REDACTED] ATOM ~acdw
7. References
7.1. Normative References
[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>.
[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>.
[RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685,
DOI 10.17487/RFC4685, September 2006,
<https://www.rfc-editor.org/info/rfc4685>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
7.2. Informative References
[CDF] Ellerman, C., "Channel Definition Format (CDF)", W3C Note
NOTE-CDFsubmit, March 1997,
<https://www.w3.org/TR/NOTE-CDFsubmit.html>.
[GEMINI] Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020, <gemini://
gemini.circumlunar.space/docs/specification.gmi>.
~lucidiot Expires October 2, 2021 [Page 7]
Bikeshed-Draft Web Feeds (WEED) April 2021
[HINA] kohgushi, "Asahina-Antenna meta data format version 2.2
(HINA/2.2)", Revision 0.13, July 2002,
<https://envs.net/~lucidiot/hina/hina2_2-rev0_13.html>.
[JSONFEED] Simmons, B. and M. Reece, "JSON Feed Version 1.1",
August 2020, <https://jsonfeed.org/version/1.1>.
[LIRS] Hiya, "Last modified Information Relaying Specification",
Version 2.1, December 2001,
<http://aniki.haun.org/natsu/LIRS.html>.
[MCF] Guka, R. V., and T. Bray, "Meta Content Framework Using
XML", W3C Note MCF-XML-970624, June 1997,
<https://www.w3.org/TR/NOTE-MCF-XML-970624/>.
[MODSUB] Burton, K., "RDF Site Summary 1.0 Modules: Subscription",
July 2002,
<http://web.resource.org/rss/1.0/modules/subscription/>.
[OPML] Winer, D., "OPML 2.0", November 2007,
<http://dev.opml.org/spec2.html>.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC2046] Freed, N., Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC3875] Robinson, D., Coar, K., "The Common Gateway Interface
(CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875,
October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC4287] Nottingham, M., Sayre, R., "The Atom Syndication Format",
RFC 4287, DOI 10.17487/RFC4287, December 2005,
<https://www.rfc-editor.org/info/rfc4287>.
[RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
~lucidiot Expires October 2, 2021 [Page 8]
Bikeshed-Draft Web Feeds (WEED) April 2021
[RFC7232] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234,
DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RSS1] Beged-Dov, G., Brickley, D., Dornfest, R., Davis, I.,
Dodds, L., Eisenzopf, J., Galbraith, D., Guha, R. V.,
MacLeod, K., Miller, E., Swartz, A. and E. van der Vlist,
"RDF Site Summary (RSS) 1.0", December 2000,
<http://purl.org/rss/1.0/spec>.
[RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version
2.0.11, March 2009,
<https://www.rss-board.org/rss-specification>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Changelog
[RFC Editor: Remove this section before publishing]
Version 01
- Fixed indentation
- Added the Known Weeds BANANA Registry
- Added the WEED protocol to the E-mail Signature Protocol
Abbreviations BANANA Registry
- Added the definition of Sprout
~lucidiot Expires October 2, 2021 [Page 9]
Bikeshed-Draft Web Feeds (WEED) April 2021
- Added threading best practices
- Added RSS considerations
- Added missing references
- Prepare for RFB 2
Acknowledgements
The author would like to thank ~dozens for initiating the Weed
community.
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.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Expires October 2, 2021 [Page 10]

766
rfb/rfb1.txt Normal file
View File

@ -0,0 +1,766 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Comments: 1 The Bikeshedding Company
Category: Standards Track March 26, 2021
Tildepals Email Signatures for Bikeshedders
Abstract
Signatures are an important part of an e-mail, but are often abused,
misused or ignored. This document provides a standard format for the
e-mail signatures of Bikeshedders to prevent those issues and protect
the company's reputation.
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) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 1 Tildepals Email Signatures February 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ....................................3
2. Core Values of a Signature .....................................3
2.1. Identification ............................................3
2.2. Communication .............................................3
2.3. Synergy ...................................................3
2.4. Accountability ............................................3
2.5. Security ..................................................3
3. Format .........................................................3
3.1. Embedding .................................................4
4. Content Guidelines .............................................4
4.1. Sender's Identity .........................................4
4.2. Contact Information .......................................4
4.3. Atlantis Protection .......................................5
4.4. Company-Approved Advertisements ...........................5
5. Example ........................................................6
6. Enforcement ....................................................6
6.1. Recommended Actions Against Non-Conformance ...............6
7. Security Considerations ........................................7
8. Internationalization Considerations ............................7
9. Privacy Considerations .........................................7
10. IANA Considerations ............................................7
10.1. text/vnd.bikeshed.signature media type ...................7
10.2. Creation of Company-Approved Advertisements Registry .....8
10.3. Creation of E-mail Signature Protocol Abbreviations
Registry .................................................9
11. References ....................................................10
11.1. Normative References ....................................10
11.2. Informative References ..................................11
Appendix A. Warranty Exclusion Statement ..........................13
Acknowledgements ..................................................13
Author's Address ..................................................13
1. Introduction
This Request for Comments (RFC) provides a standard format for email
signatures of collaborators and partners of the Bikeshedding Company
that ensures the Core Values of the Bikeshedding Company are properly
displayed and relevant information is shared.
All collaborators of the Bikeshedding Company MUST update their
signature to follow this RFC.
~lucidiot Standards Track [Page 2]
RFB 1 Tildepals Email Signatures February 2021
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Core Values of a Signature
2.1. Identification
A signature's primary goal is to identify the author of an email;
therefore the first portion of a signature should be the author's
first and last name.
2.2. Communication
When the message portion of an email is extracted from its email
context, the sender's contact information is lost as it was part of
the email headers. Adding contact information helps prevent this
issue, and also allows reaching out to the sender via other means of
communication such as a phone call.
2.3. Synergy
By making communication easier, a signature enhances the synergy
between correspondents and boosts productivity.
2.4. Accountability
Signatures can make people accountable for their actions as their
name is right below what they write.
2.5. Security
By following standard practices used by large organizations such as
the IETF, a signature can bring security to the company, for example
against the people of Atlantis [NOTADRAFT].
3. Format
Signatures SHOULD be encoded in plain text using the UTF-8 text
encoding [RFC3629]. All lines in a signature text MUST NOT exceed 72
characters in length.
The first line of a signature MUST be the separator string "-- ",
trailing space included. Email client implementors MAY recognize
this line as the signature separator and display it in special
formatting, or exclude it from quoted replies.
~lucidiot Standards Track [Page 3]
RFB 1 Tildepals Email Signatures February 2021
Signatures SHOULD be excluded from a message when quoting it in an
email reply, unless including the signature in the quotation brings
to the context of the reply.
3.1. Embedding
When a signature is embedded in another text format, it MUST use the
encoding of its parent text format instead of UTF-8.
When a signature is embedded in an HTML email, it SHOULD be wrapped
in HTML <pre> and tags if its proper display requires a monospaced
font.
Use of the multipart/related media type to add the signature aside
from the email in its original media type, instead of an HTML media
type, is optional.
4. Content Guidelines
A standard signature SHOULD hold the following sections, in this
order:
1. The sender's identity
2. The sender's contact information
3. Security measures against eel-bearing Atlanteans
Other sections MAY be added, as long as they follow the Core Values
of signatures. Sections MAY be separated by blank lines to enhance
readability.
4.1. Sender's Identity
The first line after the separator MUST hold the first and last name,
or the nickname, of the sender. If the sender's identity should be
hidden behind a generic name, for example for a customer support
service with a generic email address, the line MAY be omitted.
The next line SHOULD be the role of the sender, followed by a comma,
and followed by the company related to the role. This can be
repeated for as many times as required, if multiple job titles are
relevant.
4.2. Contact Information
The contact information section MUST start with the sender's email
address. If multiple addresses are relevant, each address MUST be
put on a separate line.
~lucidiot Standards Track [Page 4]
RFB 1 Tildepals Email Signatures February 2021
If the sender is reachable via other means of communication, they MAY
be added as subsequent lines. Each line MUST start with the protocol
name, followed by a colon and a space, and end with the relevant
contact information for this protocol.
The protocol name MUST be registered in the E-mail Signature Protocol
Abbreviations IANA registry.
4.3. Atlantis Protection
To ensure protection of the Bikeshedding Company against economic
issues caused by eel-bearing Atlanteans, a signature MUST hold the
string "Don't allow eel bearing Atlanteans into your country;
economic ruin follows close behind", as required by IETF standards
[NOTADRAFT].
When a signature is embedded in a parent media type that does not
support encoding the 'b' character, the string "My hovercraft is full
of eels" MUST be used instead.
Other strings from the IANA Registry of important strings, suitable
for use as idle signalling transmissions (ROISSFUAIST) MAY be used,
unless they hinder readability.
4.4. Company-Approved Advertisements
The Marketing Division of the Bikeshed Company MAY, at its
discretion, enact Advertisement Directives via a memo sent in a
company-wide e-mail. Those directives SHOULD state a list of
currently accepted Bikeshedding Company advertisements that CAN be
inserted by Bikeshedders in another section of their signature.
Advertisements for companies other than the Bikeshedding Company, or
that are not approved in the Marketing Division's Advertisement
Directives, MUST NOT be inserted in a signature.
When and only when the Marketing Division's Advertisement Directives
explicitly state that an advertisement is REQUIRED, it is so.
~lucidiot Standards Track [Page 5]
RFB 1 Tildepals Email Signatures February 2021
5. Example
This document's author's signature could be formatted like so:
--
~lucidiot
Co-Founder, The Bikeshedding Company
Chairman, International Transport Safety Bureau
lucidiot@brainshit.fr
erwan.rct@wanadoo.fr
MSN: lucidiot@protonmail.com
HTTP: http://tilde.town/~lucidiot/
Don't allow eel bearing Atlanteans into your country; economic
ruin follows close behind.
Figure 1 : Example Signature
6. Enforcement
Unless where technical limitations may prevent it, emails from the
Bikeshedding Company MUST include a signature conforming with this
document.
Recipients MAY reject any email from the Bikeshedding Company that
does not include a signature or that includes a signature that does
not conform with this document. Recipients SHOULD inform the
sender of their rejection by means of an email.
In cases of repeated non-conformance, recipients SHOULD send an email
to the Human Resources division of the Bikeshedding Company to inform
them of the issue and allow them to take action.
6.1. Recommended Actions Against Non-Conformance
The following actions are RECOMMENDED, by order of severity:
- Sending a reminder of the existence of this document.
- Scheduling a training session with slides and a lot of
buzzwords.
- Making a formal write-up for non-conformance to this document.
- Requiring approbation from the Human Resources division for each
email sent by the perpetrator until the non-conformance ceases.
- Publicly blaming the perpetrator's actions for any and all
issues within the Bikeshedding Company.
- Trout-slapping.
~lucidiot Standards Track [Page 6]
RFB 1 Tildepals Email Signatures February 2021
- Firing the perpetrator.
7. Security Considerations
Use of HTML in emails is known to cause security problems due to
the many technologies it can bring. This document requires
plain-text signatures to avoid those security problems.
Signatures, as human-written and human-read text, are however still
vulnerable to social engineering attacks and Information Technology
executives should consider hiring overpriced consulting services to
help them in training their collaborators against them.
8. Internationalization Considerations
It is well-known that most text encodings were designed without
non-English languages and non-Latin alphabets in mind. This document
requires the UTF-8 text encoding [RFC3629], as it already supports
most languages and alphabets and can be extended by updates to the
Unicode specification as needed.
Signatures embedded in messages of a different encoding may however
have encoding issues. It is however believed that the existing
issues with text encoding in email and in general will help prevent
users from trying to run into these issues.
9. Privacy Considerations
Until the email is sent, the sender remains in full control of their
signature, and may choose to change the signature's contents to
adapt to a particular context on a case-by-case basis.
However, by reproducing a signature, an attacker can make themselves
appear as someone else, as users might rely on the signature more
than email headers. This can be solved both by proper training from
overpriced consultants and from using technologies such as S/MIME
[RFC8551].
10. IANA Considerations
10.1. text/vnd.bikeshed.signature media type
This document registers the "text/vnd.bikeshed.signature" media type.
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: n/a
Optional parameters: charset
~lucidiot Standards Track [Page 7]
RFB 1 Tildepals Email Signatures February 2021
Encoding considerations: Prefer UTF-8. See Section 3 of this RFC.
Security considerations: See Section 7 of this RFC.
Interoperability considerations: TBD
Published specification: RFC 1
Applications that use this media type: n/a
Additional information:
Magic numbers: 2d 2d 20 0a
See Section 3 of this RFC.
File extension(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
Person & email address to contact for further information: See
Author's Address section.
Intended usage: Limited Use
Use of this format SHOULD be restricted to bikeshedding
activities.
Restrictions on usage: Bikeshedding
Author: See Author's Address section.
Change controller: See Author's Address section.
10.2. Creation of Company-Approved Advertisements Registry
This document creates a new IANA registry entitled "Company-Approved
Advertisements".
The policy for future assignments to this registry is Private Use
[RFC8126]. This registry has one field: the advertisement.
The Marketing Division of the Bikeshedding Company is the sole
maintainer of this registry, and SHOULD notify the Bikeshedders of
any change by sending a full copy of the registry contents along with
its Advertisement Directives via e-mail on the tildepals mailing
list.
This registry has no initial values.
~lucidiot Standards Track [Page 8]
RFB 1 Tildepals Email Signatures February 2021
10.3. Creation of E-mail Signature Protocol Abbreviations Registry
This document creates a new IANA registry entitled "E-mail Signature
Protocol Abbreviations".
The policy for future assignments to this registry is Expert Review
[RFC8126]. This registry has three fields: the abbreviation, the
protocol's full name, and a reference to the protocol's specification
or official description.
The abbreviation field SHOULD be unique. The Designated Expert MUST
ensure that the abbreviation unmistakably identifies the protocol and
matches the expected abbreviation for most users of the protocol.
Multiple protocols MAY share the same abbreviation if and only if its
userbase sees all of the protocols as being the same. Multiple
abbreviations MAY be associated to the same protocol.
Bikeshedders can request the assignation of a new abbreviation by
contacting the Designated Expert over the tildepals mailing list.
The Designated Expert MAY consult the community via a "call for
comments" before assigning an abbreviation, and SHOULD notify the
Bikeshedders of any updates to the registry, by sending an e-mail to
the tildepals mailing list.
The references field is OPTIONAL. The Designated Expert SHOULD
ensure that the referenced documents meet the "specification
required" rule, or are the most official source of information on the
protocol.
If the protocol is proprietary and it is generally referred to as its
main, or only, implementation, and the protocol's specification or
description cannot be found, the references MAY point to the most
official sources of information on the implementation.
~lucidiot Standards Track [Page 9]
RFB 1 Tildepals Email Signatures February 2021
The initial values for this registry are specified below:
Abbreviation Protocol References
------------ ------------------------------------------- ----------
HTTP Hypertext Transfer Protocol [RFC7230]
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
Gopher Internet Gopher Protocol [RFC1436]
Gemini Project Gemini [GEMINI]
MSN Microsoft Notification Protocol [MSNP]
IRC Internet Relay Chat [RFC1459]
[RFC2810]
[RFC2811]
[RFC2812]
[RFC2813]
[RFC7194]
Discord Discord [DISCORD]
Fedi ActivityPub [APUB]
XMPP Extensible Messaging and Presence Protocol [RFC6120]
[RFC6121]
[RFC7622]
[RFC3923]
11. References
11.1. Normative References
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
~lucidiot Standards Track [Page 10]
RFB 1 Tildepals Email Signatures February 2021
[RFC8551] Schaad, J., Ramsdell, B. and Turner, S.,
"Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 4.0 Message Specification", RFC 8551,
DOI 10.17487/RFC8551, April 2019,
<https://www.rfc-editor.org/info/rfc8551>.
11.2. Informative References
[APUB] Lemmer Webber, C., Tallon, J., Shepherd, E., Guy, A.,
Prodromou, E., "ActivityPub", W3C Recommendation,
January 2018, <https://www.w3.org/TR/activitypub/>.
[DISCORD] Discord, "Discord", May 2015, <https://discord.com>.
[GEMINI] Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020, <gemini://
gemini.circumlunar.space/docs/specification.gmi>
[MSNP] Mintz, M., Sayers, A., "MSN Messenger Protocol",
December 2003, <http://www.hypothetic.org/docs/msn/>
[NOTADRAFT] Kumari, W., "Just because it's an ID doesn't mean
anything... at all...", Work In Progress,
draft-wkumari-not-a-draft-10, July 2020.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC1459] Oikarinen, J., Reed, D., "Internet Relay Chat Protocol",
RFC 1459, DOI 10.17847/RFC1459, May 1993,
<https://www.rfc-editor.org/info/rfc1459>.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17847/RFC2810, April 2000,
<https://www.rfc-editor.org/info/rfc2810>.
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, DOI 10.17847/RFC2811, April 2000,
<https://www.rfc-editor.org/info/rfc2811>.
[RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol",
RFC 2812, DOI 10.17847/RFC2812, April 2000,
<https://www.rfc-editor.org/info/rfc2812>.
[RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol",
RFC 2813, DOI 10.17847/RFC2813, April 2000,
<https://www.rfc-editor.org/info/rfc2813>.
~lucidiot Standards Track [Page 11]
RFB 1 Tildepals Email Signatures February 2021
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object
Encryption for the Extensible Messaging and Presence
Protocol (XMPP)", RFC 3923, DOI 10.17847/RFC3923,
October 2004, <https://www.rfc-editor.org/info/rfc3923>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17847/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, DOI 10.17847/RFC6121, March 2011,
<https://www.rfc-editor.org/info/rfc6121>.
[RFC7194] Hartmann, R., "Default Port for Internet Relay Chat
(IRC) via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194,
August 2014, <https://www.rfc-editor.org/info/rfc7194>.
[RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234,
DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622,
DOI 10.17847/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
~lucidiot Standards Track [Page 12]
RFB 1 Tildepals Email Signatures February 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
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.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Standards Track [Page 13]

353
rfb/rfb2.txt Normal file
View File

@ -0,0 +1,353 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 2 The Bikeshedding Company
Category: Standards Track April 3, 2021
Updates: 1
Ensuring Compatibility between The Bikeshedding Company
and Internet Engineering Task Force Standards
Abstract
The Internet Engineering Task Force (IETF) and The Bikeshedding
Company both provide standards and standardization bodies with the
same names, which can increase the confusion. This document
updates some of The Bikeshedding Company's jargon and the previous
Bikeshedding RFBs as a preventive measure.
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) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 2 IETF Compatibility April 2021
Table of Contents
1. Introduction ....................................................2
1.1. Notational Conventions .....................................2
2. Definitions .....................................................3
2.1. Bikeshed-Draft .............................................3
2.2. Request for Bikeshedding ...................................3
2.3. Best Current Bikeshedding ..................................3
2.4. The RFB Editor .............................................3
2.5. Bikeshedding Assigned Numbers Assignation and
Normalization Authority ....................................3
2.6. Bikeshedding Working Group .................................4
2.7. Bikeshedding Company Working Task Force ....................4
2.8. Human Resources Division ...................................4
3. RFB Updates .....................................................4
4. Interoperability Considerations .................................4
4.1. Cross-references ...........................................4
4.2. Conflict Resolution ........................................4
5. Security Considerations .........................................5
6. Internationalization Considerations .............................5
7. Privacy Considerations ..........................................5
8. BANANA Considerations ...........................................5
9. References ......................................................5
9.1. Normative References .......................................5
9.2. Informative References .....................................6
Appendix A. Warranty Exclusion Statement ...........................6
Acknowledgements ...................................................6
Author's Address ...................................................6
1. Introduction
This Request for Bikeshedding (RFB) introduces new terminology that
is equivalent to the Internet counterparts, such as RFB instead of
RFC, to avoid confusions between Internet standards and Bikeshedding
standards. As the RFC Editor currently handles over nine thousand
Requests for Comments, and the RFB Editor only handles one, renaming
on our own side is much easier for everyone.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Standards Track [Page 2]
RFB 2 IETF Compatibility April 2021
2. Definitions
2.1. RFB 2
A Bikeshed-Draft (B-D) is the equivalent for The Bikeshedding Company
of an IETF Internet-Draft (I-D). Bikeshed-Drafts may be submitted by
any employee of the Bikeshedding Company.
2.2. Request for Bikeshedding
A Request for Bikeshedding (RFB) is the equivalent for The
Bikeshedding Company of an IETF Request for Comments (RFC). After
going through a reviewing process, a Bikeshed-Draft MAY be approved
by the RFB Editor to be published as an RFB.
2.3. Best Current Bikeshedding
A Best Current Bikeshedding (BCB) is the equivalent for The
Bikeshedding Company of an IETF Best Current Practices (BCP).
It is a set of RFBs that relate to a similar topic, may evolve over
time, and that can be referred to directly in an RFB instead of each
of the RFBs of the set.
The RFB Editor MAY, at any time, create, update or obsolete a BCB.
The RFB Editor MUST notify all employees of the Bikeshedding Company
of any change to a BCB via an email to the Tilde Pals mailing list.
2.4. The RFB Editor
The RFB Editor is in charge of handling the reviewing process of
Bikeshed-Drafts and the publication of the Requests for Bikeshedding.
The co-founders of the Bikeshedding Company MAY, without warning and
without justification, assign or remove a Bikeshedding Company
employee from the position of RFB Editor.
The position of RFB Editor is currently filled by ~lucidiot.
2.5. Bikeshedding Assigned Numbers Assignation and Normalization
Authority
The Bikeshedding Assigned Numbers Assignation and Normalization
Authority (BANANA) is a department of The Bikeshedding Company in
charge of maintaining protocol registries as defined in the BANANA
Considerations sections of RFBs.
The RFB Editor is in charge of notifying the BANANA of any BANANA
actions in an RFB that is about to be published. An RFB MUST NOT be
published before the BANANA has taken proper actions in regards to
the BANANA Considerations section.
~lucidiot Standards Track [Page 3]
RFB 2 IETF Compatibility April 2021
BANANA Considerations sections in RFBs follow the same guidelines as
those for IANA Considerations sections [RFC8126].
2.6. Bikeshedding Working Group
The Bikeshedding Working Group (BWG) is the set of all employees,
collaborators and partners of the Bikeshedding Company. It is the
equivalent of the IETF Network Working Group.
2.7. Bikeshedding Company Working Task Force
The Bikeshedding Company Working Task Force (BC-WTF) is the set of
all employees of the Bikeshedding Company. It is the equivalent for
the Bikeshedding Company of the Internet Engineering Task Force.
2.8. Human Resources Division
The Bikeshedding Company Human Resources Division is the equivalent
for The Bikeshedding Company of the IETF Protocol Police [RFC8962].
3. RFB Updates
This document updates RFB 1:
- All references to Bikeshedding Requests for Comments are replaced
with "Request for Bikeshedding".
- The IANA Considerations section is renamed BANANA Considerations.
- All actions instructed to the Internet Assigned Numbers Authority
are now reassigned to the Bikeshedding Assigned Numbers
Assignation and Normalization Authority.
4. Interoperability Considerations
4.1. Cross-references
Any document from the Bikeshedding Company MAY reference an IETF
document using IETF terminology. Any IETF document MAY reference a
document from the Bikeshedding Company using bikeshedding
terminology.
4.2. Conflict Resolution
A Bikeshedding Standard takes precedence over an Internet Standard,
and overrides any conflicting statements, in all contexts relevant to
Bikeshedding activities and to The Bikeshedding Company.
An Internet Standard takes precedence over a Bikeshedding Standard,
and overrides any conflicting statements, in all contexts relevant to
Internet protocols.
~lucidiot Standards Track [Page 4]
RFB 2 IETF Compatibility April 2021
In other contexts, readers MUST apply proper judgement to determine
which of the standards apply. The IETF Protocol Police and the
Bikeshedding Company Human Resources Division SHOULD ensure that all
readers of Bikeshedding Standards and Internet Standards apply proper
judgement, and perform punitive actions whenever necessary.
5. Security Considerations
Confusing terminology can increase the risk of improper
implementations of a protocol by a misunderstanding. This document
defines a stricter terminology to avoid mistaking a Bikeshedding
reference to an IETF reference and vice-versa, which can reduce this
risk.
6. Internationalization Considerations
All Bikeshedding Company and IETF Standards to date are in English
and use UTF-8 [RFC3629] or US-ASCII, and the Bikeshedding Company has
no Translation Division, so internationalization can be safely
unconsidered.
7. Privacy Considerations
Privacy is pointless in documents intended to be public.
8. BANANA Considerations
This document renames the IANA to BANANA. No registries or values
are affected.
9. References
9.1. Normative References
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S.,
"Establishing the Protocol Police", RFC 8962,
DOI 10.17487/RFC8962, April 2021,
<https://www.rfc-editor.org/infO/rfc8962>.
~lucidiot Standards Track [Page 5]
RFB 2 IETF Compatibility April 2021
9.2. Informative References
[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>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgements
The author would like to thank himself for being the only person with
enough might to use SciTE to write RFBs.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Standards Track [Page 6]

589
rfb/rfb3.txt Normal file
View File

@ -0,0 +1,589 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 3 The Bikeshedding Company
Category: Informational April 4, 2021
Web Feeds (WEED)
Abstract
Members of the Tilde Pals mailing list have created a new community
known as the Weeds. This memo formalizes the practices of this
community to help The Bikeshedding Company find potential
bikeshedding opportunities in this new trend.
Status of This Memo
This document is not a Bikeshedding Standards Track specification; it
is published for informational purposes.
This document is a product of the Bikeshedding Company Working Task
Force (BC-WTF). 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).
Not all documents approved by the BESG are a candidate for any level
of Internet Standard; see Section 2 of RFC 7841.
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) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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 Informational [Page 1]
RFB 3 Web Feeds (WEED) April 2021
Table of Contents
1. Introduction ....................................................2
1.1. Notational Conventions .....................................2
2. Concepts ........................................................3
2.1. Weed Abbreviation ..........................................3
2.2. Web Feeds ..................................................3
2.3. Weed Users .................................................3
2.4. Weed Ring ..................................................3
2.5. Sprout .....................................................4
3. Best Practices ..................................................4
3.1. Linking ....................................................4
3.2. HTTP Servers ...............................................4
3.3. Multi-User Unix System Hosting .............................5
3.4. Threading ..................................................5
3.5. RSS Considerations .........................................5
4. Internationalization Considerations .............................5
5. Security and Privacy Considerations .............................6
6. BANANA Considerations ...........................................6
6.1. Registration of an E-mail Signature Protocol Abbreviation ..6
6.2. Creation of Known Weeds Registry ...........................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Warranty Exclusion Statement ...........................9
Acknowledgements ...................................................9
Author's Address ..................................................10
1. Introduction
This Request for Bikeshedding (RFB) is a formalisation of the basic
rules that govern the community known as Weeds, a project developed
outside of the Bikeshedding Company.
This RFC does not define a standard, but only represents the general
consensus among the Weed Dealers and Consumers, to increase its
accessibility for newcomers. The Bikeshedding Company believes that
this project has a lot of potential for producing a high quality of
bikeshedding in markets the company has not explored before.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Informational [Page 2]
RFB 3 Web Feeds (WEED) April 2021
2. Concepts
2.1. Weed Abbreviation
The users of Project Gemini [GEMINI] have coined the term "gemlog"
to refer to the Gemini equivalent of a blog, as a "blog" is the
diminutive of "web log", and a gemlog is not on the web.
Similarly, a Weed is a web feed. A weed allows its creator to
publish content similar to what would be published on a blog, but
the content is not intended to be seen in a web browser; instead, it
should be viewed in a feed reader. The web log is therefore closer
to a web feed.
2.2. Web Feeds
A Web Feed is a syndication feed provided in a format such as RDF
Site Summary [RSS1], Really Simple Syndication [RSS2], Atom
[RFC4287], Channel Definition Format [CDF], JSON Feed [JSONFEED],
Meta Content Framework [MCF], Hina-Di [HINA], or Last modified
Information Relaying Specification [LIRS], over an open HTTP, HTTPS
[RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], Gopher
[RFC1436] or Gemini [GEMINI] server. This list is not exhaustive.
The contents of a Web Feed MUST NOT be easily readable in a web
browser that does not have built-in support for the weed's format.
Most modern browsers have removed support for RSS and Atom. CDF has
been dropped since 2009 and JSON Feed has not seen much adoption.
Publishing the contents of a weed to a server such as a version
control system with a web interface counts as violating the above
rule. Version control systems without web interfaces, or whose web
interfaces do not allow access to the weed to users outside of the
Weed Community, are acceptable.
2.3. Weed Users
A weed content writer is known as a Weed Dealer, as a reference to
the recreative substance. Similarly, a reader is known as a Weed
Consumer. Most Weed users are both Dealers and Consumers, and all
users are strongly encouraged to interact with each other.
2.4. Weed Ring
The Weed Ring is a technique allowing Weed Consumers to find other
Weed Dealers. A Weed Dealer is encouraged to share links to other
Weed Dealers they know of in their own Weed, allowing Consumers to
read the feed to find other Dealers and ensure a newcomer to the
community is not forgotten, or missed, by everyone else.
Weed Dealers can share other feeds by many means:
~lucidiot Informational [Page 3]
RFB 3 Web Feeds (WEED) April 2021
- Creating an Outline Processor Markup Language [OPML] file which
references the feeds in "rss" outline types, then linking to this
file from inside one of their published articles.
- Using the proposed Subscription module [MODSUB] of RSS 1.0 to
denote other channels in the RSS feed itself.
- Using the "related" link relation type in Atom to link to other
channels in an Atom feed.
- Using the Channel Definition Format's channel nesting feature.
- Using the Hina-Di entity block propagation feature.
- Linking to the related feeds in an item of a feed of any format,
in a way that can be read and understood manually by a user.
Weed Dealers that share other feeds SHOULD include all the weeds of
the Known Weeds BANANA registry.
The Weed Ring is also known as the Daisy Chain.
2.5. Sprout
A Sprout is a single weed post, item, article, published in a Weed.
3. Best Practices
3.1. Linking
Linking to weeds, or to files internal to a weed on a medium other
than another weed, or another file internal to a weed, MUST NOT be
done without the explicit consent of the Weed Dealer.
An exception can be made to this rule if the link is sent to a
community, or over a technology, where it can only be read by a
group of Weed users, a group of Weed non-users trusted by both the
Weed Dealer and the author sharing the link, or a group made of both
of the aforementioned categories. Examples include the Bikeshedding
Company, the Tilde Pals, and the Flying Basement.
3.2. HTTP Servers
The contents of the directory that holds the weed and any of its
related files SHOULD NOT be listable, to make the discovery of the
weed less likely.
An additional layer of security through obscurity can be achieved in
servers capable of dynamic webpage generation, for example servers
using CGI [RFC3875], by applying restrictions on user agents to block
web browsers.
~lucidiot Informational [Page 4]
RFB 3 Web Feeds (WEED) April 2021
3.3. Multi-User Unix System Hosting
Many weeds are hosted on tildes, pubnixes or other multi-user Unix
or Unix-derived systems. Weeds hosted on those systems SHOULD be
properly protected against discovery by third parties from inside the
system to ensure the invisible state of weeds. Such a level of
protection can be achieved using file permissions and access control
lists:
- Make the weed's parent directory and any of its contents only
accessible to the owner and the HTTP server.
- Make the weed's directory and any sub-directories readable only by
the owner; this makes reading a particular file possible, but not
listing the available files in a directory.
3.4. Threading
As Weeds form a rather tight-knit community, using a Sprout to reply
to another Sprout is a common and generally encouraged practice.
Most syndication formats do not specify ways to indicate a sprout
that another sprout replies to, or ways to refer to a single sprout
in a weed when sprouts do not have permalinks. Most formats will
usually refer to the HTML page that an item links to, but most weeds
do not have any links since everything is syndication-only.
The Atom Threading extensions [RFC4685] SHOULD be used in all
XML-based syndication formats that allow namespace extensions to
specify replies.
3.5. RSS Considerations
Weeds using the Really Simple Syndication or RDF Site Summary formats
SHOULD include the <guid> tag to allow other Weed Dealers to reply to
their sprouts or to avoid issues when an existing sprout is updated.
4. Internationalization Considerations
Many syndication formats that could be used for Weeds use old text
encodings that may not be displayed properly by modern systems or
allow encoding any alphabet or any language. When a format uses XML,
it is RECOMMENDED to specify its encoding using the encoding
attribute of XML declarations:
<?xml version="1.0" encoding="utf-8"?>
For text formats, the charset parameter [RFC2046] can be used to
specify the encoding, if it differs from US-ASCII.
UTF-8 [RFC3629] is the preferred encoding. If a format's
specification allows using UTF-8, it SHOULD be used, even if the
~lucidiot Informational [Page 5]
RFB 3 Web Feeds (WEED) April 2021
specification says a different encoding is preferred. If a format's
specification requires a different encoding, that encoding MUST be
used. If a format's specification does not indicate any encoding,
then UTF-8 MUST be used.
5. Security and Privacy Considerations
The Weed community has the potential to create a false sense of
privacy in inexperienced Weed Dealers, who might think nothing
published in a weed might ever exit it and might disclose private
information that they wished to only share to the community and not
to the rest of the Internet.
It is believed that three factors will be able to contribute to
minimizing those risks without requiring a technical change:
- The complexity of writing a syndication feed by hand.
- The desire to keep the Tilde Pals community, from which come all
of the Weed Dealers and Consumers, small enough to remain
human-sized.
- The trust and cooperation encouraged within the Tilde Pals
community, empowering more privacy-conscious users to warn their
fellow less-privacy-conscious users.
6. BANANA Considerations
6.1. Registration of an E-mail Signature Protocol Abbreviation
This document registers a new item to the "E-mail Signature Protocol
Abbreviations" registry:
Abbreviation: WEED
Protocol name: Web Feeds
Protocol specification: This RFC
6.2. Creation of Known Weeds Registry
This document creates a new BANANA registry entitled "Known Weeds".
The policy for future assignments to this registry is First Come
First Served [RFC8126]. This registry has three fields: the Weed
URL, the syndication format, and the change controller.
The BANANA SHOULD notify the Bikeshedders of any updates to the
registry by sending an e-mail to the Tilde Pals mailing list along
with a reminder of the registration process.
The Weed URL MUST be unique, and MUST be a valid URL pointing to a
~lucidiot Informational [Page 6]
RFB 3 Web Feeds (WEED) April 2021
Weed. The syndication format is an arbitrary string, meant for Weed
Consumers to more easily tell which Weeds they can follow depending
on their own feed reader's supported formats when accessing the
registry. The Change Controller is the only person allowed to
contact BANANA and request a later change to a Known Weed.
The initial values for this registry are specified below:
URL Format Change Controller
------------------------------------------- ------ -----------------
[REDACTED] RSS2 ~dozens
[REDACTED] RSS2 ~lucidiot
[REDACTED] ATOM ~acdw
7. References
7.1. Normative References
[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>.
[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>.
[RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685,
DOI 10.17487/RFC4685, September 2006,
<https://www.rfc-editor.org/info/rfc4685>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
7.2. Informative References
[CDF] Ellerman, C., "Channel Definition Format (CDF)", W3C Note
NOTE-CDFsubmit, March 1997,
<https://www.w3.org/TR/NOTE-CDFsubmit.html>.
[GEMINI] Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020, <gemini://
gemini.circumlunar.space/docs/specification.gmi>.
~lucidiot Informational [Page 7]
RFB 3 Web Feeds (WEED) April 2021
[HINA] kohgushi, "Asahina-Antenna meta data format version 2.2
(HINA/2.2)", Revision 0.13, July 2002,
<https://envs.net/~lucidiot/hina/hina2_2-rev0_13.html>.
[JSONFEED] Simmons, B. and M. Reece, "JSON Feed Version 1.1",
August 2020, <https://jsonfeed.org/version/1.1>.
[LIRS] Hiya, "Last modified Information Relaying Specification",
Version 2.1, December 2001,
<http://aniki.haun.org/natsu/LIRS.html>.
[MCF] Guka, R. V., and T. Bray, "Meta Content Framework Using
XML", W3C Note MCF-XML-970624, June 1997,
<https://www.w3.org/TR/NOTE-MCF-XML-970624/>.
[MODSUB] Burton, K., "RDF Site Summary 1.0 Modules: Subscription",
July 2002,
<http://web.resource.org/rss/1.0/modules/subscription/>.
[OPML] Winer, D., "OPML 2.0", November 2007,
<http://dev.opml.org/spec2.html>.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC2046] Freed, N., Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC3875] Robinson, D., Coar, K., "The Common Gateway Interface
(CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875,
October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC4287] Nottingham, M., Sayre, R., "The Atom Syndication Format",
RFC 4287, DOI 10.17487/RFC4287, December 2005,
<https://www.rfc-editor.org/info/rfc4287>.
[RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
~lucidiot Informational [Page 8]
RFB 3 Web Feeds (WEED) April 2021
[RFC7232] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234,
DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RSS1] Beged-Dov, G., Brickley, D., Dornfest, R., Davis, I.,
Dodds, L., Eisenzopf, J., Galbraith, D., Guha, R. V.,
MacLeod, K., Miller, E., Swartz, A. and E. van der Vlist,
"RDF Site Summary (RSS) 1.0", December 2000,
<http://purl.org/rss/1.0/spec>.
[RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version
2.0.11, March 2009,
<https://www.rss-board.org/rss-specification>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgements
The author would like to thank ~dozens for initiating the Weed
community.
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.
~lucidiot Informational [Page 9]
RFB 3 Web Feeds (WEED) April 2021
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Informational [Page 10]

412
rfb/rfb4.txt Normal file
View File

@ -0,0 +1,412 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 4 Bikeshedding Microsystems
Category: Standards Track June 30, 2021
Last-modified Information Relaying Specification (LIRS) 2.1
Abstract
This document is an English translation and clean-up of the
Last-modified Information Relaying Specification (LIRS) 2.1, in its
only recovered and latest revision of December 16, 2001. It aims to
preserve historical knowledge over syndication formats.
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) 2021 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 4 LIRS 2.1 June 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ....................................2
2. Format .........................................................3
3. Fields .........................................................3
3.1. Last-Modified .............................................3
3.2. Last-Detected .............................................4
3.3. Time difference ...........................................4
3.4. Content-Length ............................................4
3.5. URL .......................................................4
3.6. Title .....................................................4
3.7. Author name ...............................................4
3.8. Source URL ................................................4
3.9. Extension .................................................4
4. Best Practices .................................................5
5. Example ........................................................5
6. Security Considerations ........................................5
7. Internationalization Considerations ............................5
8. Privacy Considerations .........................................6
9. BANANA Considerations ..........................................6
10. References .....................................................6
Appendix A. Warranty Exclusion Statement ...........................6
Appendix B. Changelog ..............................................6
Acknowledgements ...................................................7
Author's Address ...................................................7
1. Introduction
This document is a continuation of the historical research project of
the Bikeshedding Microsystems Research and Development Division,
aiming to preserve the history of syndication formats. It is a
cleaned up English translation of a Japanese specification that has
been recovered via the Internet Archive Wayback Machine.
Last-modified Information Relaying Specification (LIRS) 2.1 is a
last-modified-detection protocol designed to only include the minimal
necessary information for update time acquisition agents (antennas).
It assumes that a site that provides update times should not be
burdened with anything other than reporting update times. It also
assumes that the sites all run on UNIX environments.
The person exclusively in charge for changes to this specification is
Hiya (hiya@haun.org).
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Standards Track [Page 2]
RFB 4 LIRS 2.1 June 2021
2. Format
An LIRS file is a text file compressed using gzip. The text is
encoded using EUC-JP and consists in a series of records.
A record starts with "LIRS,", followed by a data part, and ends with
a comma and LF or CRLF. LF is recommended. CR MUST NOT be used
alone.
Lines that begin with # are comments and SHOULD be ignored.
The data part of a record consists in a series of fields separated
by commas (,).
Field values MUST NOT include the CR or LF characters, or unescaped
commas.
All dates are expressed as Unix timestamps: seconds from
1970-01-01T00:00:00Z.
With the exception of the extension field, blank fields SHOULD be
represented as a zero (0).
The backslash character (\) is the escape character. Commas in
fields MUST be escaped (\,). A literal backslash can be inserted
using two backslashes (\\).
3. Fields
The following fields MUST appear in all records, in this order:
- Last-Modified
- Last-Detected
- Time difference
- Content-Length
- URL
- Title
- Author name
- Source URL
- Extension
3.1. Last-Modified
Timestamp of when the target site was last updated.
Should the last update detection fail, the LIRS provider SHOULD set
this field to zero, and antenna agents SHOULD assume this record is
unusable.
~lucidiot Standards Track [Page 3]
RFB 4 LIRS 2.1 June 2021
3.2. Last-Detected
Timestamp of when the LIRS provider last checked for the last update
time for this site. This defines a notion of "freshness" that
antenna agents can use to sort records by priority, or discard old
records.
Should the last update detection fail, the LIRS provider SHOULD set
this field to zero, and antenna agents SHOULD assume this record is
unusable.
3.3. Time difference
Signed integer. Difference, in seconds, between GMT and the timezone
of the target site; 32400 or +32400 in Japan. Since update times are
reported in GMT, this allows sharing the timezone of the target site.
3.4. Content-Length
Size of the content served at the target URL, in bytes. LIRS
providers that check the target site externally, and do not have more
internal ways to detect an update, SHOULD consider a change in the
Content-Length to be an update.
3.5. URL
URL of the target site. This field MUST be unique; a single URL MUST
NOT be repeated twice in the same LIRS file. This field can be used
as a unique identifier by antenna implementations.
3.6. Title
Title of the content served at the target site; usually the contents
of the HTML <title> tag.
3.7. Author name
Name of the author of the content served at this URL.
3.8. Source URL
URL that was used by the LIRS provider to acquire update information.
This is usually the same as the URL; in case of an implementation
that aggregates update information from other LIRS providers, this
could be the URL of each LIRS file. How to use this field is left to
the implementor.
3.9. Extension
Arbitrary string for agent-specific information. Instead of 0 as
the default for a blank field, this SHOULD be left empty.
~lucidiot Standards Track [Page 4]
RFB 4 LIRS 2.1 June 2021
4. Best Practices
LIRS files SHOULD be cached, not generated dynamically.
LIRS implementations SHOULD automatically discard records that
were last detected more than 28800 seconds (8 hours) ago.
5. Example
This is a single LIRS record, uncompressed:
LIRS,938779260,938781002,32400,49383,http://hiya.ouchi.to/n/,
Tadayo Memories,Hiya,http://amano.hauN.org/,blah blah,\r\n
This translates to the following fields:
Title: Tadayo Memories
Author: Hiya
Site URL: http://hiya.ouchi.to/n/
Last modified: 1999-10-01T14:01:00Z
Last detected: 1999-10-01T14:30:02Z
Server timezone: UTC+9 (32400 seconds)
Source: http://amano.hauN.org/
Custom data: blah blah
6. Security Considerations
Client implementations SHOULD be wary of the possible decompression
bombs that a server could send.
The standard was designed with HTTP in mind, but replacing the scheme
with HTTPS for added security should not affect any modern
implementation.
7. Internationalization Considerations
This standard was almost exclusively designed for Japan; no encoding
other than EUC-JP is allowed.
Client implementations MAY be flexible and try decoding using UTF-8
instead of EUC-JP when errors occur, to allow for a possible
evolution towards an internationalized standard if more LIRS
implementations support it.
~lucidiot Standards Track [Page 5]
RFB 4 LIRS 2.1 June 2021
8. Privacy Considerations
The metadata shared in LIRS is already public, and disclosure of this
information is under the full control of the publisher. However,
when aggregating feds, the removal of already aggregated links or
metadata may not be strictly performed by all implementors. This can
lead to the same issues as those seen in present-day federated social
networks, to which the only guaranteed solution is to not publish
what you might have to remove later.
9. BANANA Considerations
This document updates the "LIRS" value in the E-mail Signature
Protocol Abbreviations registry.
The Reference field of the value should now point to this document.
10. References
[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>.
[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>.
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Changelog
This changelog was included in the original specification. It is
included here to provide historical context.
The changelog only included timestamps. The associated version
numbers have been added where they are known.
2001-12-16 22:48, LIRS 2.1
Added a link to the Meta::LIRS Perl module
2000-10-25 14:36, LIRS 2.1
Fixed an error in the description of the URL field.
~lucidiot Standards Track [Page 6]
RFB 4 LIRS 2.1 June 2021
2000-10-13 15:20, LIRS 2.1
Fixed an error in the usage of gzip in LIRS.pm.
2000-06-23 13:52
Added details about handling line feeds (\\015, \\012).
2000-06-16 13:47
Added a link to lirs.rb.
2000-05-31 20:00
Backslashes should now be escaped too (`\\`).
Minor corrections due to changes in LIRS.pm.
1999-11-11 19:41
Document converted to HTML, and minor corrections.
1999-11-03 03:25, LIRS 1.1
Minor corrections after a discussion about DI.
Added the About LIRS section.
1999-10-13 18:00, LIRS 1.0
Initial version.
Acknowledgements
The author would like to thank Hiya for creating LIRS, and Yamakazoo
for creating some Perl CGI scripts that support LIRS, HINA 1 and
HINA 2, and still hosting them proudly on their personal website in
the year 2021: http://www.harmonicom.jp/natsu/
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 7]

825
rfb/rfb5.txt Normal file
View File

@ -0,0 +1,825 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 5 Bikeshedding Microsystems
Category: Standards Track July 1, 2021
Asahina Antenna Metadata Format (HINA) 2.2, revision 0.13
Abstract
This document is an English translation and clean-up of the Asahina
Antenna Metadata Format (HINA) 2.2, in its latest revision, 0.13, of
July 19, 2002. It aims to preserve historical knowledge over
syndication formats.
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) 2021 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 5 HINA 2.2 July 2021
Table of Contents
1. Introduction ...................................................3
1.1. Notational Conventions ..................................3
2. Data Types .....................................................4
3. Structure ......................................................4
3.1. Block ....................................................4
3.2. Header Block .............................................5
3.3. Entity Block .............................................5
4. Fields .........................................................5
4.1. HINA .....................................................5
4.2. User-Agent ...............................................6
4.3. URL ......................................................6
4.4. HINA-Version .............................................6
4.5. Virtual ..................................................6
4.6. Content-Type .............................................7
4.7. Date .....................................................7
4.8. Title ....................................................7
4.9. Author-Name ..............................................7
4.10. Expires ..................................................7
4.11. Expire ...................................................7
4.12. Last-Modified ............................................8
4.13. Last-Modified-Detected ...................................8
4.14. Server ...................................................8
4.15. Authorized ...............................................8
4.16. Authorized-url ...........................................8
4.17. Method ...................................................8
4.17.1. Method Types .....................................9
4.17.2. Example ..........................................9
4.18. Keyword ..................................................9
4.19. Image-Width ..............................................9
4.20. Image-Height ............................................10
4.21. Experimental Fields .....................................10
4.22. Undefined Fields ........................................10
5. Encoding ......................................................10
6. Propagation ...................................................10
7. Security Considerations .......................................11
8. Internationalization Considerations ...........................11
9. Privacy Considerations ........................................11
10. BANANA Considerations .........................................11
11. References ....................................................11
11.1. Normative References ....................................11
11.2. Informative References ..................................12
Appendix A. Warranty Exclusion Statement ..........................13
Appendix B. Glossary ..............................................13
Acknowledgements ..................................................13
Author's Address ..................................................14
~lucidiot Standards Track [Page 2]
RFB 5 HINA 2.2 July 2021
1. Introduction
In the early days of RSS, before Atom and itself took over the world
of syndication, and before Unicode became common enough to reduce
internationalization issues, several syndication formats were being
developed at smaller scales.
As those formats are now slowly dying, the Bikeshedding Microsystems
Research and Development Division invests in dusting them off and
re-standardizing them to ensure that their specification is not lost
to time, and that future generations can still benefit from past
experience.
As XML [XML] and the Really Simple Syndication [RSS2] appeared very
recently, and the lack of general Unicode support in software led to
encoding incompatibilities between Western sites in ASCII [ASCII] and
Japanese sites in Shift-JIS [SHIFTJIS] or EUC-JP, the first programs
that offered a concept of syndication in Japan were called
"last-modified-time detection agents".
The most popular last-modified detection agent was Asahina-Antenna,
which led to the term "antenna" being used to refer to this type of
software. Asahina-Antenna used its own syndication format, the
Asahina Antenna Metadata Format (HINA). Some sites still serve
HINA feeds as of 2021.
HINA 1.x, also known as "hina.txt", was a text format whose
specification has not yet been recovered by our historians and was
used by Asahina Antenna 1.x.
HINA 2.x, also known as HINA-DI, has been influenced by Document
Information (DI), a project that aimed to develop document metadata
exchange and provided a mailing list. Hiroshi Nakamura intended to
create the Document Information Read Protocol (DIRP) and Document
Information Transfer Protocol (DITP), two standards to form a network
for distributed syndication based on RDF. The specifications were
never published, but HINA builds on this idea of decentralization.
In a way, DI and HINA 2.x have the same ideas as ActivityPub and the
modern concepts of federated software, but were 15 years early.
1.1. Notational Conventions
This document uses the Backus-Naur notation [RFC822] to formally
define the format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Standards Track [Page 3]
RFB 5 HINA 2.2 July 2021
2. Data Types
The basic data types that constitute Hina-Di are listed below.
The US-ASCII character set is defined by ANSI X3.4-1986 [ASCII].
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
WORD = 1*(ALPHA|DIGIT)
CTL = <any US-ASCII control character (octets 0 - 31)
and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
TEXT = <any OCTET except CTLs, but including HT>
TOKEN = <any TEXT, but don't start with SP or HT>
SEPARATOR = ":" 1*(SP|HT)
DELIMITER = "," *(SP|HT)
SLASH = "/" *(SP|HT)
3. Structure
A Hina-Di file consists of a series of blocks that summarize the
metadata on a website: a header block, followed by one or more entity
blocks.
hina-di = header-block
1*( entity-block )
3.1. Block
A block is a set of metadata for a document. Each metadata is
represented as a single header, in a manner similar to RFC 822
message headers [RFC822], with a field name and a field value.
Field names in a block MUST be unique. A block with duplicate field
names MUST be discarded by clients.
Field names are case-insensitive. Unless explicitly stated for a
particular field, a field's value is case-insensitive.
~lucidiot Standards Track [Page 4]
RFB 5 HINA 2.2 July 2021
line-format = field-name SEPARATOR field-value CRLF
field-name = WORD *( "-" WORD)
field-value = TOKEN
3.2. Header Block
Exactly one header block MUST appear in a Hina-Di file, and it MUST
be the first block. It holds metadata about the Hina-Di file itself.
header-block = HINA
Hinadi-Header
CRLF
Hinadi-Header = 1*( User-Agent
| Content-Type
| Date )
3.3. Entity Block
One or more entity blocks MUST be present after the header block.
Each entity block defines metadata about a specific document.
Entity-block = URL ( HINA-Version
| Virtual
| Content-Type
| Date
| Title
| Author-Name
| Expires
| Expire
| Last-Modified
| Last-Modified-Detected
| Server
| Authorized
| Authorized-url
| Method
| Keyword
| Image-Width
| Image-Height
| Experimental-field
| Undefined-field )
CRLF
4. Fields
This section defines the various fields that may be found in blocks.
All fields are OPTIONAL and case-insensitive unless otherwise
specified.
4.1. HINA
Indicates that this is a Hina-Di file, and includes its version.
This field is REQUIRED as the first field of Hina-Di files.
~lucidiot Standards Track [Page 5]
RFB 5 HINA 2.2 July 2021
HINA = "HINA" "/" hinadi-version CRLF
hinadi-version = "2.2beta"
4.2. User-Agent
Name of the user agent that created this Hina-Di file.
This field is REQUIRED in header blocks.
The value of this field is case-sensitive.
User-Agent = "User-Agent" SEPARATOR TOKEN CRLF
4.3. URL
URL of the document, compliant with [RFC2396].
This field is REQUIRED in entity blocks.
Making this field the first field of an entity block is RECOMMENDED.
The scheme and domain portions of the URL are not case-sensitive.
If the other portions of the URL are not case-insensitive, they
SHOULD be written using lowercase characters.
URL = "URL" SEPARATOR rfc2396-url CRLF
rfc2396-url = <URI described in section 5.1.2 "Request-URI"
in RFC 2396>
Implementations can use this field as a unique key that distinguishes
the entity block from other blocks. To ensure proper uniqueness of
this field, the following conditions MUST be respected by the
providing Hina-Di user agents or their administrators:
If the URL can end in a slash (`/`), then it SHOULD end in a slash.
Prefer `http://www.hoge.jp/foo/` over `http://www.hoge.jp/foo`.
If the URL includes a file name, but the file name can be omitted,
then it SHOULD be omitted. Prefer `http://www.hoge.jp/foo/` over
`http://www.hoge.jp/foo/index.html`
4.4. HINA-Version
Specifies that the integrity of the entity block was guaranteed
according to the specification of a specific Hina-Di version.
If this field is missing from an entity block, it means the block
might be incomplete.
HINA-Version = "HINA-Version" SEPARATOR version
version = "HINA" "/" 1*( DIGIT ) "." 1*( DIGIT )
4.5. Virtual
URL of another Hina-Di file that holds the entity block, compliant
with [RFC2396].
~lucidiot Standards Track [Page 6]
RFB 5 HINA 2.2 July 2021
If there are fields in the entity block other than `Virtual`, then
it takes the same meaning as the regular `URL` field.
The case-sensitivity and URL uniqueness conditions defined for the
`URL` field MUST be followed for this field.
Virtual = "Virtual" SEPARATOR rfc2396-url CRLF
Note that the original Japanese specification defines the `Virtual`
feed as `Vitural`.
4.6. Content-Type
MIME type of the Hina-Di file or the document, as described in
[RFC1521]. The value of this field is case-sensitive to the extent
defined by RFC 1521.
Content-Type = "Content-Type" SEPARATOR rfc1521-type CRLF
4.7. Date
The date and time when the block or the Hina-Di file was generated.
The dates MUST comply with [RFC1123]. The value of this field is
case-sensitive.
Date = "Date" SEPARATOR rfc1123-date CRLF
4.8. Title
The title of the document.
Title = "Title" SEPARATOR TOKEN CRLF
4.9. Author-Name
Name of the author of the document.
The value of this field is case-sensitive.
Author-Name = "Author-Name" SEPARATOR TOKEN CRLF
4.10. Expires
Expiration date for the block. The dates MUST comply with [RFC1123].
The value of this field is case-sensitive to the extent defined by
RFC 1123.
Expires = "Expires" SEPARATOR rfc1123-date CRLF
4.11. Expire
Alias for the `Expires` field, included for backwards compatibility.
~lucidiot Standards Track [Page 7]
RFB 5 HINA 2.2 July 2021
Expire = "Expire" SEPARATOR rfc1123-date CRLF
4.12. Last-Modified
Date and time when the document was last updated. The date MUST
comply with [RFC1123]. The value of this field is case-sensitive to
the extent defined by RFC 1123.
Last-Modified = "Last-Modified" SEPARATOR rfc1123-date CRLF
4.13. Last-Modified-Detected
Date and time representing when the user agent retrieved the
document's metadata. The dates MUST comply with [RFC1123].
The value of this field is case-sensitive to the extent defined by
RFC 1123.
Last-Modified-Detected = "Last-Modified-Detected"
SEPARATOR rfc1123-date CRLF
4.14. Server
User agent string of the server used to retrieve the metadata of the
document described by this entity block.
Server = "Server" SEPARATOR TOKEN CRLF
4.15. Authorized
The user agent that retrieved the metadata of the document described
by this entity block.
Authorized = "Authorized" SEPARATOR TOKEN CRLF WORD
4.16. Authorized-url
URL of a page describing the user agent referred to in the
`Authorized` field, compliant with [RFC2396].
The case-sensitivity and URL uniqueness conditions defined for the
`URL` field MUST be followed for this field.
Authorized-url = "Authorized-url" SEPARATOR rfc2396-url CRLF
4.17. Method
Describes the chain of propagation that this entity block went
through.
~lucidiot Standards Track [Page 8]
RFB 5 HINA 2.2 July 2021
Method = "Method" SEPARATOR method-type
*(SLASH method-type) (SLASH result-code)
method-type = "GET" | "HEAD" | "FILE" | "REMOTE"
result-code = <Status code from the IANA HTTP Status codes
registry [STATUS]>
The original Japanese specification defined result-code as follows:
result-code = <URI described on "???????" in RFC 2396>
4.17.1. Method Types
GET Metadata retrieved using a HTTP GET request.
HEAD Metadata retrieved using a HTTP HEAD request.
FILE Metadata retrieved from a local file's timestamp.
REMOTE Metadata retrieved from an entity block generated by another
agent.
4.17.2. Example
Method: REMOTE/REMOTE/GET/200
1. A first user agent retrieved the metadata on the document using
an HTTP GET request and got a 200 response code (`GET/200`).
2. A second user agent retrieved the first user agent's Hina-Di
file, then propagated it to its own file (`REMOTE`).
3. A third user agent retrieved the second user agent's Hina-Di
file, then propogated it to its own file (`REMOTE`).
4.18. Keyword
Words that can be used to give an overview of the document described
by this entity block; tags, categories, etc. The value of this field
is case-sensitive.
Keyword = "Keyword" SEPARATOR keywords CRLF
keywords = TOKEN *(SEPARATOR TOKEN)
4.19. Image-Width
Width of an image described by an entity block, in pixels.
This field MUST NOT be used for entity blocks that do not describe
images.
Image-Width = "Image-Width" SEPARATOR width CRLF
width = DIGIT
~lucidiot Standards Track [Page 9]
RFB 5 HINA 2.2 July 2021
4.20. Image-Height
Height of an image described by an entity block, in pixels.
This field MUST NOT be used for entity blocks that do not describe
images.
Image-Height = "Image-Height" SEPARATOR width CRLF
height = DIGIT
4.21. Experimental fields
Implementations MAY define custom fields with an X- prefix to provide
additional metadata not covered in this specification.
Implementations MUST NOT assume that all clients will use each of
those fields. Clients that do not support any experimental field
SHOULD ignore them.
Experimental fields MAY include data that is not directly related to
metadata that the document has, and SHOULD be used shall a field for
that purpose be created by an implementor.
Experimental-field = x-field-name SEPARATOR TOKEN
x-field-name = "X-" WORD *("-" WORD)
4.22. Undefined fields
Any field that is not defined in this specification. Implementations
that encounter such fields and do not support them SHOULD ignore
them.
Undefined-field = undef-field-name SEPARATOR TOKEN CRLF
undef-field-name = WORD *("-" WORD)
5. Encoding
The character encoding of the Hina-Di file SHOULD be specified as a
parameter of the Content-Type field of the header block. If it is
not specified, it defaults to EUC-JP.
6. Propagation
In Hina-Di, metadata propagation consists in acquiring metadata from
other agents, then sharing it as it is in the user agent's own
Hina-Di file. This can be used for aggregation services or a
peer-to-peer network.
The Authorized and Authorized-url fields allow indicating the user
agent from which the metadata originally came from to help ensure its
legitimacy. Propagating MUST only be performed if both fields are
defined and if the user agent is trusted.
~lucidiot Standards Track [Page 10]
RFB 5 HINA 2.2 July 2021
When propagating, all fields of an entity block defined in this
specification, with the exception of experimental and undefined
fields or of fields with empty values, MUST be reproduced without
modification. Propagation of experimental or undefined fields is not
guaranteed. A header block, or any field that is part of it, MUST
NOT be propagated.
The Method field MUST be updated upon propagation according to the
process described in section 4.17.
7. Security Considerations
The HINA format was designed at a time when security was far from the
primary concern for most Internet users. It is however easy, should
a modern implementation of the format be created, to seamlessly use
HTTPS instead of HTTP, both in the URLs of the syndicated content and
to serve the HINA feeds themselves.
8. Internationalization Considerations
While the format defaults to EUC-JP, it is possible to specify other
encodings for the whole file using the Content-Type field in the
Header Block. As most HINA feeds will be served over HTTP, the
Content-Type field of the HTTP response could also include this
encoding.
9. Privacy Considerations
The metadata shared in HINA is already public, and disclosure of this
information is under the full control of the publisher. However, in
a situation of propagation, the removal of already propagated links
or metadata may not be strictly performed by all implementors. This
can lead to the same issues as those seen in present-day federated
social networks, to which the only guaranteed solution is to not
publish what you might have to remove later.
10. BANANA Considerations
This document updates the "HINA" value in the E-mail Signature
Protocol Abbreviations registry.
The Reference field of the value should now point to this document.
11. References
11.1. Normative References
[ASCII] "American National Standard for Information Systems —
Coded Character Sets — 7-Bit American National Standard
Code for Information Interchange (7-Bit ASCII)",
ANSI X3.4-1986, American National Standards Institute,
March 1986.
~lucidiot Standards Track [Page 11]
RFB 5 HINA 2.2 July 2021
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", RFC 1123, DOI 10.17487/RFC1123,
October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies",
RFC 1521, DOI 10.17487/RFC1521, September 1993,
<https://www.rfc-editor.org/info/rfc1521>.
[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>.
[RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
DOI 10.17487/RFC2396, August 1998,
<https://www.rfc-editor.org/info/rfc2396>.
[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>.
[STATUS] "Hypertext Transfer Protocol (HTTP) Status Code Registry",
Internet Assigned Numbers Authority,
<https://www.iana.org/assignments/http-status-codes/
http-status-codes.xhtml>.
11.2. Informative References
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", RFC 822, DOI 10.17487/RFC0822,
August 1982, <https://www.rfc-editor.org/info/rfc822>.
[RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version
2.0.11, March 2009,
<https://www.rss-board.org/rss-specification>.
[SHIFTJIS] "7-bit and 8-bit double byte coded KANJI sets for
information interchange", JIS X0208:1997, Japanese
Standards Association, January 1997.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M. and E.
Maler, "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C Recommendation REC-xml-20001006, October
2000, <https://www.w3.org/TR/2000/REC-xml-20001006>.
~lucidiot Standards Track [Page 12]
RFB 5 HINA 2.2 July 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix B. Glossary
This glossary was part of the original Japanese specification and is
left here to provide historical context to this standard.
Asahina-Antenna
Metadata acquisition agent based on HINA.
metadata
Information about the content, such as the author, title and
update time.
hina-di
Metadata transfer format used by Asahina-Antenna 2.x.
hina.txt
Metadata transfer format used by Asahina-Antenna 1.x, made
obsolete by hina-di.
DI
Document Information. Project that was developing the Document
Information Transfer Protocol (DITP) and Document Information Read
Protocol (DIRP), for decentralized syndication.
Hina-Di has been influenced by DI.
Acknowledgements
The author would like to thank Hiroshi Nakamura for sharing the idea
of the DITP and DIRP and developing decentralized technologies before
they truly came to life.
The author would like to thank Masayoshi Takahashi for providing an
English summary of the Japanese last-modified-time detection agents
in 1999.
Finally, the author would like to thank the Internet Archive and all
the contributors, donators, voulunteers involved, as without them
this research would have never been possible.
~lucidiot Standards Track [Page 13]
RFB 5 HINA 2.2 July 2021
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 14]

530
rfb/rfb6.txt Normal file
View File

@ -0,0 +1,530 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 6 Bikeshedding Microsystems
Category: Standards Track August 1, 2021
Vaccination as a Unit Prefix
Abstract
This document introduces a new unit prefix that should be preferred
by all Bikeshedders when it is applicable; vax- and antivax-.
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) 2021 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 6 Vax Prefix August 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ...................................3
2. New Prefixes ...................................................3
2.1. The Vax Prefix ...........................................3
2.2. The AntiVax Prefix .......................................3
2.3. The Vaxi Prefix ..........................................3
2.4. The AntiVaxi Prefix ......................................3
3. Security Considerations ........................................4
4. Internationalization Considerations ............................4
5. Privacy Considerations .........................................7
6. BANANA Considerations ..........................................7
7. References .....................................................8
7.1. Normative References ......................................8
7.2. Informative References ....................................8
Appendix A. Warranty Exclusion Statement ...........................9
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction
As you may have noticed, every human on Earth has been facing since
the end of 2019 a worldwide pandemic. This pandemic correlates with
a period of worldwide rollout of 5G NR [5GNR], which had caused a
wave of conspiracy theories over electromagnetic waves being used to
control our brains.
In an attempt to end this worldwide health crisis, multiple vaccines
have been simultaneously developed and vaccination campaigns are
being run to get them to spread out as much as possible. This has
sparked new conspiracy theories, as the anti-vaccination groups have
been very active thanks to Donald Trump's presidency of the United
States and thanks to Facebook's circlejerk-based attention-retaining
content selection. According to highly trustable media [BULLSHIT],
the vaccines provide nano-bots that can be controlled over 5G NR and
allow governments to brainwash humanity.
It has been commonly observed that anti-vaccination activists and
conspiracy theorists react very aggressively when faced with any kind
of criticism or doubt of their opinions. The Operational Security
Division of Bikeshedding Microsystems believes there is a potential
threat for our Bikeshedding Business Operations in expressing any
pro-vaccination or scientifically-validated opinion on the current
pandemic. While the pandemic provides us with unforeseen and
challenging but rewarding and profitable markets for us to bikeshed
in, the OpSec Division needs to act to prevent any damage to our
reputation and daily activities.
To avoid any issues with conspiracy theories and anti-vaccination
activists, the OpSec Division hereby enacts a new unit prefixing
system that is not too intrusive on our daily operations, but
~lucidiot Standards Track [Page 2]
RFB 6 Vax Prefix August 2021
provides us with plausible deniability in regards to pro-vaccination
opinions that could be expressed in any communcations from
Bikeshedding Microsystems.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. New Prefixes
Bikeshedders SHOULD use the following new unit prefixes when
expressing any quantity in the order of magnitude of billions
(10^9), in addition to regular SI unit prefixes.
2.1. The Vax Prefix
The "vax-" prefix, abbreviated "V", is equivalent to 5,000,000,000
(5E+9 or 5 * 10^9). "Vax" is a diminutive of "vaccine", and it
corresponds to 5 giga, or 5G.
2.2. The Antivax Prefix
The "antivax-" prefix, abbreviated "AV", is equivalent to
-5,000,000,000 (-5E+9 or 5 * 10^9). "Antivax" is a diminutive of
anti-vaccine and is regularly used to describe anti-vaccination
activists. It corresponds to -5 giga, or -5G.
2.3. The Vaxi Prefix
The "vaxi-" prefix, abbreviated "Vi", is equivalent to 5,368,709,120
(5 * 1024^3). This is the concatenation of the "vax-" prefix with
the binary variant of SI prefixes regularly used to express
quantities of bits and bytes, such as gibibytes (GiB). 1 ViB is
equivalent to 5 GiB.
The "vaxi-" prefix MUST only be used for vaxibytes or vaxibits.
Users of binary prefixes SHOULD consider whether using a binary
prefix instead of a standard SI prefix truly adds to the meaning of
their communication before using it.
2.4. The Antivaxi Prefix
The "antivaxi-" prefix, abbreviated "AVi", is equivalent to
-5,368,709,120 (-5 * 1024^3). This is the concatenation of the
"anti-vax-" prefix with the binary variant of SI prefixes regularly
used to express quantities of bits and bytes, such as gibibytes
(GiB). 1 AViB is equivalent to -5 GiB.
~lucidiot Standards Track [Page 3]
RFB 6 Vax Prefix August 2021
The "antivaxi-" prefix MUST only be used for antivaxibytes or
antivaxibits. Users of binary prefixes SHOULD consider whether using
a binary prefix instead of a standard SI prefix truly adds to the
meaning of their communication before using it.
3. Security Considerations
This document exists solely for the sake of ensuring the security of
our Bikeshedding Business Operations.
Bikeshedders that face any kind of negative interactions with
conspiracy theorists, anti-vaccination activists or anti-bikeshedding
activists MUST forward any written statements, recordings or relevant
documents related to said interactions to the Bikeshedding
Microsystems Operational Security Division.
It is RECOMMENDED to avoid replying to those interactions until a
proper reply strategy has been established by the Bikeshedding
Microsystems Operational Security Division in collaboration with the
Bikeshedding Microsystems Public Relations Division.
Bikeshedders that witness other Bikeshedders expressing agreement
with conspiracy theories or anti-vaccination arguments MUST report
said issues to the Bikeshedding Microsystems Human Resources Division
who SHOULD take appropriate action to neutralize any potential threat
to the Bikeshedding Business Operations or to the physical integrity
of the bodies of other Bikeshedders.
4. Internationalization Considerations
The following languages are known to use a word that means "vaccine"
similarly to the English word "vaccine":
- Afrikaans: vaksine
- Albanian: vaksinë
- Armenian: վակցինա (vakc'ina)
- Asturian: vacuna
- Azerbaijani: vaksin
- Belarusian: вакцы́на (vakcýna)
- Bengali: ভ্যাক্সিন (bbhakśin)
- Bulgarian: вакси́на (vaksína)
- Catalan: vaccí
- Czech: vakcína
~lucidiot Standards Track [Page 4]
RFB 6 Vax Prefix August 2021
- Danish: vaccine
- Dhivehi: ވެކްސިން‎ (vek̊sin̊)
- Dutch: vaccin
- Esperanto: vakcino
- Estonian: vaktsiin
- French: vaccin
- Galician: vacina
- Georgian: ვაქცინა (vakcina)
- German: Vakzine
- Hindi: वैक्सीन (vaiksīn)
- Hungarian: vakcina
- Irish: vacsaín
- Italian: vaccino
- Japanese: ワクチン (wakuchin)
- Kazakh: вакцина (vakcïna)
- Khmer: វ៉ាក់សាំង (km) (vaksang)
- Korean: 백신 (ko) (baeksin)
- Kyrgyz: вакцина (vaktsina)
- Latvian: vakcīna
- Lithuanian: vakcina
- Macedonian: вакцина (vakcina)
- Malagasy: vaksiny (mg)
- Malay: vaksin
- Mongolian: вакцин (vaktsin)
- Norman: vaccîn
- Norwegian: vaksine
~lucidiot Standards Track [Page 5]
RFB 6 Vax Prefix August 2021
- Malayalam: വാക്സിൻ (vāksin)
- Persian: واکسن‎ (vâksin)
- Polish: wakcyna
- Portuguese: vacina
- Romanian: vaccin
- Russian: вакци́на (vakcína)
- Serbo-Croatian: вакци́на, vakcína
- Slovak: vakcína
- Spanish: vacuna
- Swedish: vaccin
- Tajik: ваксина (vaksina)
- Telugu: వ్యాక్సిన్ (vyāksin), వ్యాక్సీన్ (vyāksīn)
- Thai: วัคซีน (wák-siin)
- Turkmen: waksina
- Ukrainian: вакци́на (vakcýna)
- Urdu: ویکسین‎ (vaiksīn)
- Uyghur: ۋاكسىنا‎ (waksina)
- Uzbek: vaktsina, vaksina
- Vietnamese: vắc-xin
- Yakut: вакцина (vaktsina)
- Yiddish: וואַקצין‎ (vaktsin)
Considering the large amount of languages that have words similar in
consonance with the English word "vaccine", the fact that vaccination
has been in the news worldwide for many months, and the fact that
"antivax" is being used in any language to describe anti-vaccination
activists as those are mostly United States-based, it is safe to
assume that these new prefixes will be widely understood by our
international branches.
~lucidiot Standards Track [Page 6]
RFB 6 Vax Prefix August 2021
5. Privacy Considerations
This document does not enforce the use of the new prefixes on any
private communication, unless those communications have the potential
to be leaked or when a Bikeshedder is under investigation for
possible threats to Bikeshedding Business Operations or to the
corporeal forms of fellow Bikeshedders by the Bikeshedding
Microsystems Human Resources Division.
Reporting of potential behavioral issues of a Bikeshedder to the
Bikeshedding Microsystems Human Resources Division SHOULD be made
through an anonymous reporting process. The Bikeshedding
Microsystems Human Resources Division is encouraged to define and
standardize this reporting process as another Request for
Bikeshedding as soon as possible.
Sharing writings, recordings or any document relevant to a private
interaction in which a Bikeshedder manifests behavior that could lead
to potential threats to Bikeshedding Business Operations or to the
corporeal forms of fellow Bikeshedders, or in which an external human
being manifests a negative reaction to a potential pro-vaccination
opinion expressed by Bikeshedding Microsystems through any of its
public communcations, with the Bikeshedding Microsystems Human
Resources Division or the Bikeshedding Microsystems Operational
Security Division, MAY be made after a reviewing step in which the
reporter blacks out, or mutes, any portion of the writings,
recordings or other relevant documents that are considered to be too
sensitive to be shared.
SHOULD any censored portion of a document become critical to an
investigation made by the Bikeshedding Microsystems Human Resources
Division or to the determination of a response process by the
Bikeshedding Microsystems Operational Security Division, the
respective divisions MAY request the approval of the Bikeshedding
Microsystems Data Protection Officer to make a declassification of
the relevant censoring REQUIRED. The initial reporter MUST send
a new copy of the document with the censoring removed in a timely
manner or face appropriate sanctions from the Bikeshedding
Microsystems Human Resources Division.
6. BANANA Considerations
This document creates a new BANANA registry entitled "Unit Prefixes".
The policy for future assignments to this registry is RFB Required
[RFC8126]. This registry has four fields: the prefix's name, the
prefix's abbreviation, the prefix's multiplier, and a reference to
one or more Request for Bikesheddings defining the prefix.
The prefix name SHOULD be unique. Multiple prefixes MAY share the
same name if and only if they cannot be both used simultaneously for
the same unit, e.g. if one prefix applies only to one unit, and
~lucidiot Standards Track [Page 7]
RFB 6 Vax Prefix August 2021
another only to a different unit.
The prefix abbreviation SHOULD be unique. Multiple prefixes MAY
share the same abbreviation if and only if they cannot be both used
simultaneously for the same unit, e.g. if one prefix applies only to
one unit, and another only to a different unit.
The prefix multiplier MUST be a finite number.
The initial values for this registry are specified below:
Name Abbreviation Multiplier RFB
-------------------------------- ------------ -------------- --------
Vax V 5,000,000,000 This RFB
Antivax AV -5,000,000,000 This RFB
Vaxi Vi 5,368,709,120 This RFB
Antivaxi AVi -5,368,709,120 This RFB
7. References
7.1. Normative References
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
7.2. Informative References
[5GNR] 3rd Generation Partnership Project, "3GPP specification
series: 38series",
<https://www.3gpp.org/DynaReport/38-series.htm>
[BULLSHIT] Freeman, M., "The Coronavirus 5G Connection and Coverup",
The Freedom Articles, February 2020,
<https://thefreedomarticles.com/coronavirus-5g-connection
-coverup-vaccines-transhumanism/>
~lucidiot Standards Track [Page 8]
RFB 6 Vax Prefix August 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgements
The author would like to thank wsinatra for encouraging the
implementation of the vaccine unit prefixes.
The author would like to thank and congratulate all the Bikeshedders
for making it through this pandemic.
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 9]

530
rfb/rfb7.txt Normal file
View File

@ -0,0 +1,530 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 7 Bikeshedding Microsystems
Category: Informational August 5, 2021
The Colon Delimited Shit Format
Abstract
This document standardizes the text format commonly seen in UNIX
configuration files such as /etc/passwd, to ensure proper
interoperability.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Bikeshedding Microsystems Working
Task Force (BM-WTF). 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).
Not all documents approved by the BESG are a candidate for any level
of Bikeshedding Standard; see Section 2 of RFC 5741.
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) 2021 The 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 Informational [Page 1]
RFB 7 CDS Format August 2021
Table of Contents
1. Introduction ..................................................2
1.1. Notational Conventions ..................................2
2. Format Definition .............................................3
3. Notable Uses ..................................................4
3.1. /etc/passwd .............................................4
3.2. /etc/shadow .............................................4
3.3. /etc/group ..............................................5
4. Security Considerations .......................................5
5. Internationalization Considerations ...........................5
6. Privacy Considerations ........................................5
7. Interoperability Considerations ...............................6
8. Morality Considerations .......................................6
8.1. Likelihood of misuse by depraved or sick individuals ....6
8.2. Likelihood of misuse by misguided individuals ...........6
8.3. Likelihood of misuse by large, multi-national
corporations ............................................6
8.4. Availability of oversight facilities ....................7
8.5. Inter-SDO impact ........................................7
8.6. Care and concern for avian carriers .....................7
9. BANANA Considerations .........................................7
10. References ....................................................8
10.1. Normative References .....................................8
10.2. Informative References ...................................8
Appendix A. Warranty Exclusion Statement ...........................9
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction
UNIX systems have been since the 1960s storing user, group, and
password data in plain text files [PASSWD]. Unlike what many may
believe, a text file format is not necessarily any better than a
binary file format; it being readable in a text editor only means
that the reader has to parse the contents to understand them, instead
of having a piece of software do the parsing and present the data in
a more readable way, in which human parsing becomes negligible.
This file format, despite being rather uniform between UNIX variants,
has never been standardized, and never got a name. This document
aims to fix this issue, to prevent later interoperability issues,
in a similar spirit as for the CSV format [RFC4180], by defining it
as the Colon Delimited Shit format.
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Informational [Page 2]
RFB 7 CDS Format August 2021
2. Format Definition
While there are various specifications and implementations for the
Colon Delimited Shit format, there is no formal and unique
specification in existence, which can allow for varied interpretation
and small incompatibilities. This section documents the format in
its strictest sense, the one that was the most commonly observed on
various systems, including Linux and BSD, with the most restrictions:
1. Each record is located on a separate line, delimited by a line
feed (LF):
root:x:0:0:root:/root:/bin/bash LF
lucidiot:x:1000:1000:lucidiot:/home/lucidiot:/usr/bin/zsh LF
2. The last record in the file may or may not have an ending line
feed (LF):
root:x:0:0:root:/root:/bin/bash LF
lucidiot:x:1000:1000:lucidiot:/home/lucidiot:/usr/bin/zsh
3. Within each record, there MUST be one or more fields, separated
by colons (:). Each line SHOULD contain the same number of
fields throuhgout the file. Spaces are considered part of a
field and SHOULD NOT be ignored. A field MAY be empty. The last
field in the record MUST NOT be followed by a colon. A field
MUST NOT contain a colon.
root:x:0:0
4. Quotes SHOULD NOT be interpreted as delimiting a field like they
could in a CSV file, and there are no escape characters. For
example:
"root":x\::"a:b"
This record contains five fields:
- "root"
- x\
- [An empty field]
- "a
- b"
The ABNF grammar [RFC5234] appears as follows:
file = record *(LF record) [LF]
record = field *(COLON field)
field = <any character except COLON>
~lucidiot Informational [Page 3]
RFB 7 CDS Format August 2021
COLON = %x3A
LF = %x0A ;as per section 6.1 of [RFC2234]
3. Notable Uses
In modern UNIX systems, there are three common uses of the Colon
Delimited Shit format.
3.1. /etc/passwd
The /etc/passwd file holds the list of users on this machine, with
the following fields:
- Username
- Password (set to `x` if it is stored in /etc/shadow)
- User ID
- Primary group ID
- User name or comment field (also known as GECOS field)
- Home directory
- Login shell
You can usually refer to `man 5 passwd` on these systems to learn
about the specific format used by a particular system.
3.2. /etc/shadow
While /etc/passwd is readable by all users, the /etc/shadow file was
introduced to hold the encrypted passwords of the users and only be
accessible to root. The passwords used to not be encrypted at all in
very early UNIX systems, which could allow someone to steal all the
passwords on a machine at once. Setting the password to just `x` in
/etc/passwd instructs the authentication system to get a password
from /etc/shadow instead. The file usually holds the following
fields:
- Username
- Encrypted password
- Timestamp of the last password change
- Minimum password age
- Maximum password age
~lucidiot Informational [Page 4]
RFB 7 CDS Format August 2021
- Password warning period
- Password inactivity period
- Account expiration date
- A reserved field
You can usually refer to `man 5 shadow` on these systems to learn
about the specific format used by a particular system.
3.3. /etc/group
The /etc/group file defines the groups on a UNIX system. It usually
has the following fields:
- Group name
- Encrypted password, may be empty
- Group ID
- Comma-separated list of users in the group, usually empty as most
implementations will only care about the group ID from
/etc/passwd.
You can usually refer to `man 5 group` on these systems to learn
about the specific format used by a particular system.
4. Security Considerations
UNIX systems that still store unencrypted passwords in /etc/passwd
or /etc/shadow, or encrypted passwords in /etc/passwd, SHOULD
urgently be updated.
Care should be taken to ensure that commands such as getent(1) are
able to handle improper input from the files, as there is no escape
mechanism; are empty fields tolerated, or fields with spaces, or
fields with quotes, with backslashes, records with not enough or too
many fields, etc.
5. Internationalization Considerations
Although most Colon Delimited Shit used to be in ASCII, modern UNIX
systems now tolerate UTF-8 text [RFC3629], and using UTF-8 is
therefore RECOMMENDED to avoid internationalization issues.
6. Privacy Considerations
The Colon Delimited Shit format does not directly cause any privacy-
related concerns.
~lucidiot Informational [Page 5]
RFB 7 CDS Format August 2021
Sensitive information SHOULD NOT be kept in the GECOS field of
/etc/passwd, although such a problem is nowadays highly unexpected.
7. Interoperability Considerations
Interoperability concerns are left up to the Protocol Police
[RFC8962].
8. Morality Considerations
This section contains morality considerations consistent with the
demands of [RFC4041].
8.1. Likelihood of misuse by depraved or sick individuals
Being a text file, a Colon Delimited Shit file cannot be used to
distribute blue, smutty or plain disgusting images.
8.2. Likelihood of misuse by misguided individuals
In a situation when a regular Comma-Separated Values file would make
more sense, it is RECOMMENDED to prefer CSV over Comma Delimited Shit
so as to avoid any potential abuse due to incomprehensions with the
lack of escaping and quoting mechanisms. Those situations MAY be
described as "anywhere except in /etc/passwd, /etc/group and
/etc/shadow".
8.3. Likelihood of misuse by large, multi-national corporations
Colon Delimited Shit alone could be used as an argument to mention
how other, possibly proprietary formats are clearly superior. When
used as the UNIX authentication system, it could be used as an
argument for other, more complex systems such as LDAP, Active
Directory, Kerberos, etc. We believe that, since those changes can
only impact the multi-national corporations themselves, negative
consequences of a misuse by large, multi-national corporations can
be ignored.
8.4. Availability of oversight facilities
As the few files in UNIX systems that use the Colon Delimited Shit
format have been here for decades, and most UNIX system users will
take them for granted without thinking about changing them. Should
a major change occur, it is the responsibility of operating system
distribution maintainers to accept or reject changes based on their
own ethics and policies.
~lucidiot Informational [Page 6]
RFB 7 CDS Format August 2021
8.5. Inter-SDO impact
As the files that use Colon Delimited Shit in UNIX systems have been
here for decades, and had very little changes in their fields, and as
this RFB merely describes the format they use, we believe that there
is no impact for other standards development organizations.
8.6. Care and concern for avian carriers
Birbs are important. Users and implementors MUST NOT hurt a birb
while implementing or using the Colon Delimited Shit format.
9. BANANA Considerations
This document registers the "text/vnd.unix.cds" media type.
Type name: text
Subtype name: vnd.unix.cds
Required parameters: N/A
Optional parameters: charset
Encoding considerations: Prefer UTF-8.
See Section 5 of this document.
Security considerations: See Section 4 of this document.
Interoperability considerations: See Section 7 of this document.
Published specification: This document
Applications that use this media type: Most UNIX systems.
See Section 3 of this document.
Additional information:
Deprecated alias names for this type: N/A
Magic numbers: N/A
File extension(s): N/A
Macintosh file type code(s): TEXT
Person & email address to contact for further information: See
Author's Address section.
Intended usage: COMMON
Restrictions on usage: N/A
~lucidiot Informational [Page 7]
RFB 7 CDS Format August 2021
Author: See Author's Address section.
Change controller: See Author's Address section.
Provisional registration? (standards tree only): No
10. References
10.1. Normative References
[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>.
[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>.
[RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC2234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S.,
"Establishing the Protocol Police", RFC 8962,
DOI 10.17487/RFC8962, April 2021,
<https://www.rfc-editor.org/info/rfc8962>.
10.2. Informative References
[PASSWD] Garfinkel, S., Schwartz, A., Spafford, G., "Practical Unix
& Internet Security, 3rd Edition", "4.3. How Unix
Implements Passwords", ISBN 0-596-00323-4, February 2003,
<https://docstore.mik.ua/orelly/other/puis3rd/
0596003234_puis3-chp-4-sect-3.html>
~lucidiot Informational [Page 8]
RFB 7 CDS Format August 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
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 like to thank, in particular, ~m455 for prompting
the standardization of the Colon Delimited Shit format.
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 Informational [Page 9]

884
rfb/rfb8.txt Normal file
View File

@ -0,0 +1,884 @@
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]

766
rfb/rfc1.txt Normal file
View File

@ -0,0 +1,766 @@
Bikeshedding Working Group ~lucidiot, Ed.
Request for Comments: 1 The Bikeshedding Company
Category: Standards Track March 26, 2021
Tildepals Email Signatures for Bikeshedders
Abstract
Signatures are an important part of an e-mail, but are often abused,
misused or ignored. This document provides a standard format for the
e-mail signatures of Bikeshedders to prevent those issues and protect
the company's reputation.
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) 2021 The Bikeshedding Company and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Company's
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]
Bikeshed-Draft Tildepals Email Signatures February 2021
Table of Contents
1. Introduction ...................................................2
1.1. Notational Conventions ....................................3
2. Core Values of a Signature .....................................3
2.1. Identification ............................................3
2.2. Communication .............................................3
2.3. Synergy ...................................................3
2.4. Accountability ............................................3
2.5. Security ..................................................3
3. Format .........................................................3
3.1. Embedding .................................................4
4. Content Guidelines .............................................4
4.1. Sender's Identity .........................................4
4.2. Contact Information .......................................4
4.3. Atlantis Protection .......................................5
4.4. Company-Approved Advertisements ...........................5
5. Example ........................................................6
6. Enforcement ....................................................6
6.1. Recommended Actions Against Non-Conformance ...............6
7. Security Considerations ........................................7
8. Internationalization Considerations ............................7
9. Privacy Considerations .........................................7
10. IANA Considerations ............................................7
10.1. text/vnd.bikeshed.signature media type ...................7
10.2. Creation of Company-Approved Advertisements Registry .....8
10.3. Creation of E-mail Signature Protocol Abbreviations
Registry .................................................9
11. References ....................................................10
11.1. Normative References ....................................10
11.2. Informative References ..................................11
Appendix A. Warranty Exclusion Statement ..........................13
Acknowledgements ..................................................13
Author's Address ..................................................13
1. Introduction
This Request for Comments (RFC) provides a standard format for email
signatures of collaborators and partners of the Bikeshedding Company
that ensures the Core Values of the Bikeshedding Company are properly
displayed and relevant information is shared.
All collaborators of the Bikeshedding Company MUST update their
signature to follow this RFC.
~lucidiot Standards Track [Page 2]
Bikeshed-Draft Tildepals Email Signatures February 2021
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 SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Core Values of a Signature
2.1. Identification
A signature's primary goal is to identify the author of an email;
therefore the first portion of a signature should be the author's
first and last name.
2.2. Communication
When the message portion of an email is extracted from its email
context, the sender's contact information is lost as it was part of
the email headers. Adding contact information helps prevent this
issue, and also allows reaching out to the sender via other means of
communication such as a phone call.
2.3. Synergy
By making communication easier, a signature enhances the synergy
between correspondents and boosts productivity.
2.4. Accountability
Signatures can make people accountable for their actions as their
name is right below what they write.
2.5. Security
By following standard practices used by large organizations such as
the IETF, a signature can bring security to the company, for example
against the people of Atlantis [NOTADRAFT].
3. Format
Signatures SHOULD be encoded in plain text using the UTF-8 text
encoding [RFC3629]. All lines in a signature text MUST NOT exceed 72
characters in length.
The first line of a signature MUST be the separator string "-- ",
trailing space included. Email client implementors MAY recognize
this line as the signature separator and display it in special
formatting, or exclude it from quoted replies.
~lucidiot Standards Track [Page 3]
Bikeshed-Draft Tildepals Email Signatures February 2021
Signatures SHOULD be excluded from a message when quoting it in an
email reply, unless including the signature in the quotation brings
to the context of the reply.
3.1. Embedding
When a signature is embedded in another text format, it MUST use the
encoding of its parent text format instead of UTF-8.
When a signature is embedded in an HTML email, it SHOULD be wrapped
in HTML <pre> and tags if its proper display requires a monospaced
font.
Use of the multipart/related media type to add the signature aside
from the email in its original media type, instead of an HTML media
type, is optional.
4. Content Guidelines
A standard signature SHOULD hold the following sections, in this
order:
1. The sender's identity
2. The sender's contact information
3. Security measures against eel-bearing Atlanteans
Other sections MAY be added, as long as they follow the Core Values
of signatures. Sections MAY be separated by blank lines to enhance
readability.
4.1. Sender's Identity
The first line after the separator MUST hold the first and last name,
or the nickname, of the sender. If the sender's identity should be
hidden behind a generic name, for example for a customer support
service with a generic email address, the line MAY be omitted.
The next line SHOULD be the role of the sender, followed by a comma,
and followed by the company related to the role. This can be
repeated for as many times as required, if multiple job titles are
relevant.
4.2. Contact Information
The contact information section MUST start with the sender's email
address. If multiple addresses are relevant, each address MUST be
put on a separate line.
~lucidiot Standards Track [Page 4]
Bikeshed-Draft Tildepals Email Signatures February 2021
If the sender is reachable via other means of communication, they MAY
be added as subsequent lines. Each line MUST start with the protocol
name, followed by a colon and a space, and end with the relevant
contact information for this protocol.
The protocol name MUST be registered in the E-mail Signature Protocol
Abbreviations IANA registry.
4.3. Atlantis Protection
To ensure protection of the Bikeshedding Company against economic
issues caused by eel-bearing Atlanteans, a signature MUST hold the
string "Don't allow eel bearing Atlanteans into your country;
economic ruin follows close behind", as required by IETF standards
[NOTADRAFT].
When a signature is embedded in a parent media type that does not
support encoding the 'b' character, the string "My hovercraft is full
of eels" MUST be used instead.
Other strings from the IANA Registry of important strings, suitable
for use as idle signalling transmissions (ROISSFUAIST) MAY be used,
unless they hinder readability.
4.4. Company-Approved Advertisements
The Marketing Division of the Bikeshed Company MAY, at its
discretion, enact Advertisement Directives via a memo sent in a
company-wide e-mail. Those directives SHOULD state a list of
currently accepted Bikeshedding Company advertisements that CAN be
inserted by Bikeshedders in another section of their signature.
Advertisements for companies other than the Bikeshedding Company, or
that are not approved in the Marketing Division's Advertisement
Directives, MUST NOT be inserted in a signature.
When and only when the Marketing Division's Advertisement Directives
explicitly state that an advertisement is REQUIRED, it is so.
~lucidiot Standards Track [Page 5]
Bikeshed-Draft Tildepals Email Signatures February 2021
5. Example
This document's author's signature could be formatted like so:
--
~lucidiot
Co-Founder, The Bikeshedding Company
Chairman, International Transport Safety Bureau
lucidiot@brainshit.fr
erwan.rct@wanadoo.fr
MSN: lucidiot@protonmail.com
HTTP: http://tilde.town/~lucidiot/
Don't allow eel bearing Atlanteans into your country; economic
ruin follows close behind.
Figure 1 : Example Signature
6. Enforcement
Unless where technical limitations may prevent it, emails from the
Bikeshedding Company MUST include a signature conforming with this
document.
Recipients MAY reject any email from the Bikeshedding Company that
does not include a signature or that includes a signature that does
not conform with this document. Recipients SHOULD inform the
sender of their rejection by means of an email.
In cases of repeated non-conformance, recipients SHOULD send an email
to the Human Resources division of the Bikeshedding Company to inform
them of the issue and allow them to take action.
6.1. Recommended Actions Against Non-Conformance
The following actions are RECOMMENDED, by order of severity:
- Sending a reminder of the existence of this document.
- Scheduling a training session with slides and a lot of
buzzwords.
- Making a formal write-up for non-conformance to this document.
- Requiring approbation from the Human Resources division for each
email sent by the perpetrator until the non-conformance ceases.
- Publicly blaming the perpetrator's actions for any and all
issues within the Bikeshedding Company.
- Trout-slapping.
~lucidiot Standards Track [Page 6]
Bikeshed-Draft Tildepals Email Signatures February 2021
- Firing the perpetrator.
7. Security Considerations
Use of HTML in emails is known to cause security problems due to
the many technologies it can bring. This document requires
plain-text signatures to avoid those security problems.
Signatures, as human-written and human-read text, are however still
vulnerable to social engineering attacks and Information Technology
executives should consider hiring overpriced consulting services to
help them in training their collaborators against them.
8. Internationalization Considerations
It is well-known that most text encodings were designed without
non-English languages and non-Latin alphabets in mind. This document
requires the UTF-8 text encoding [RFC3629], as it already supports
most languages and alphabets and can be extended by updates to the
Unicode specification as needed.
Signatures embedded in messages of a different encoding may however
have encoding issues. It is however believed that the existing
issues with text encoding in email and in general will help prevent
users from trying to run into these issues.
9. Privacy Considerations
Until the email is sent, the sender remains in full control of their
signature, and may choose to change the signature's contents to
adapt to a particular context on a case-by-case basis.
However, by reproducing a signature, an attacker can make themselves
appear as someone else, as users might rely on the signature more
than email headers. This can be solved both by proper training from
overpriced consultants and from using technologies such as S/MIME
[RFC8551].
10. IANA Considerations
10.1. text/vnd.bikeshed.signature media type
This document registers the "text/vnd.bikeshed.signature" media type.
Type name: text
Subtype name: vnd.bikeshed.signature
Required parameters: n/a
Optional parameters: charset
~lucidiot Standards Track [Page 7]
Bikeshed-Draft Tildepals Email Signatures February 2021
Encoding considerations: Prefer UTF-8. See Section 3 of this RFC.
Security considerations: See Section 7 of this RFC.
Interoperability considerations: TBD
Published specification: RFC 1
Applications that use this media type: n/a
Additional information:
Magic numbers: 2d 2d 20 0a
See Section 3 of this RFC.
File extension(s): n/a
Macintosh file type code(s): n/a
Fragment identifier considerations: n/a
Person & email address to contact for further information: See
Author's Address section.
Intended usage: Limited Use
Use of this format SHOULD be restricted to bikeshedding
activities.
Restrictions on usage: Bikeshedding
Author: See Author's Address section.
Change controller: See Author's Address section.
10.2. Creation of Company-Approved Advertisements Registry
This document creates a new IANA registry entitled "Company-Approved
Advertisements".
The policy for future assignments to this registry is Private Use
[RFC8126]. This registry has one field: the advertisement.
The Marketing Division of the Bikeshedding Company is the sole
maintainer of this registry, and SHOULD notify the Bikeshedders of
any change by sending a full copy of the registry contents along with
its Advertisement Directives via e-mail on the tildepals mailing
list.
This registry has no initial values.
~lucidiot Standards Track [Page 8]
Bikeshed-Draft Tildepals Email Signatures February 2021
10.3. Creation of E-mail Signature Protocol Abbreviations Registry
This document creates a new IANA registry entitled "E-mail Signature
Protocol Abbreviations".
The policy for future assignments to this registry is Expert Review
[RFC8126]. This registry has three fields: the abbreviation, the
protocol's full name, and a reference to the protocol's specification
or official description.
The abbreviation field SHOULD be unique. The Designated Expert MUST
ensure that the abbreviation unmistakably identifies the protocol and
matches the expected abbreviation for most users of the protocol.
Multiple protocols MAY share the same abbreviation if and only if its
userbase sees all of the protocols as being the same. Multiple
abbreviations MAY be associated to the same protocol.
Bikeshedders can request the assignation of a new abbreviation by
contacting the Designated Expert over the tildepals mailing list.
The Designated Expert MAY consult the community via a "call for
comments" before assigning an abbreviation, and SHOULD notify the
Bikeshedders of any updates to the registry, by sending an e-mail to
the tildepals mailing list.
The references field is OPTIONAL. The Designated Expert SHOULD
ensure that the referenced documents meet the "specification
required" rule, or are the most official source of information on the
protocol.
If the protocol is proprietary and it is generally referred to as its
main, or only, implementation, and the protocol's specification or
description cannot be found, the references MAY point to the most
official sources of information on the implementation.
~lucidiot Standards Track [Page 9]
Bikeshed-Draft Tildepals Email Signatures February 2021
The initial values for this registry are specified below:
Abbreviation Protocol References
------------ ------------------------------------------- ----------
HTTP Hypertext Transfer Protocol [RFC7230]
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
Gopher Internet Gopher Protocol [RFC1436]
Gemini Project Gemini [GEMINI]
MSN Microsoft Notification Protocol [MSNP]
IRC Internet Relay Chat [RFC1459]
[RFC2810]
[RFC2811]
[RFC2812]
[RFC2813]
[RFC7194]
Discord Discord [DISCORD]
Fedi ActivityPub [APUB]
XMPP Extensible Messaging and Presence Protocol [RFC6120]
[RFC6121]
[RFC7622]
[RFC3923]
11. References
11.1. Normative References
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
~lucidiot Standards Track [Page 10]
Bikeshed-Draft Tildepals Email Signatures February 2021
[RFC8551] Schaad, J., Ramsdell, B. and Turner, S.,
"Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 4.0 Message Specification", RFC 8551,
DOI 10.17487/RFC8551, April 2019,
<https://www.rfc-editor.org/info/rfc8551>.
11.2. Informative References
[APUB] Lemmer Webber, C., Tallon, J., Shepherd, E., Guy, A.,
Prodromou, E., "ActivityPub", W3C Recommendation,
January 2018, <https://www.w3.org/TR/activitypub/>.
[DISCORD] Discord, "Discord", May 2015, <https://discord.com>.
[GEMINI] Solderpunk, "Project Gemini", Speculative specification,
v0.14.3, November 2020, <gemini://
gemini.circumlunar.space/docs/specification.gmi>
[MSNP] Mintz, M., Sayers, A., "MSN Messenger Protocol",
December 2003, <http://www.hypothetic.org/docs/msn/>
[NOTADRAFT] Kumari, W., "Just because it's an ID doesn't mean
anything... at all...", Work In Progress,
draft-wkumari-not-a-draft-10, July 2020.
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., Alberti, B., "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, DOI 10.17847/RFC1436, March 1993,
<https://www.rfc-editor.org/info/rfc1436>.
[RFC1459] Oikarinen, J., Reed, D., "Internet Relay Chat Protocol",
RFC 1459, DOI 10.17847/RFC1459, May 1993,
<https://www.rfc-editor.org/info/rfc1459>.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
DOI 10.17847/RFC2810, April 2000,
<https://www.rfc-editor.org/info/rfc2810>.
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, DOI 10.17847/RFC2811, April 2000,
<https://www.rfc-editor.org/info/rfc2811>.
[RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol",
RFC 2812, DOI 10.17847/RFC2812, April 2000,
<https://www.rfc-editor.org/info/rfc2812>.
[RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol",
RFC 2813, DOI 10.17847/RFC2813, April 2000,
<https://www.rfc-editor.org/info/rfc2813>.
~lucidiot Standards Track [Page 11]
Bikeshed-Draft Tildepals Email Signatures February 2021
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object
Encryption for the Extensible Messaging and Presence
Protocol (XMPP)", RFC 3923, DOI 10.17847/RFC3923,
October 2004, <https://www.rfc-editor.org/info/rfc3923>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17847/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, DOI 10.17847/RFC6121, March 2011,
<https://www.rfc-editor.org/info/rfc6121>.
[RFC7194] Hartmann, R., "Default Port for Internet Relay Chat
(IRC) via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194,
August 2014, <https://www.rfc-editor.org/info/rfc7194>.
[RFC7230] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., Reschke, J., "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234,
DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Reschke, J., "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622,
DOI 10.17847/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
~lucidiot Standards Track [Page 12]
Bikeshed-Draft Tildepals Email Signatures February 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN 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
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.
Author's Address
~lucidiot (editor)
The Bikeshedding Company
m455.casa
72.137.16.55
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Standards Track [Page 13]

129
tildepals/state-2021-07.txt Normal file
View File

@ -0,0 +1,129 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| JULY 2021 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
================================ ISSUES ================================
Framalistes reports that proper service cannot be ensured for users
subscribed from emails provided by SFR, a French ISP (sfr.fr,
club-internet.fr, neuf.fr, 9online.fr, etc.), and you should switch to
another email provider. This does not currently affect any of us.
============================ MESSAGE STATS =============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 329
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
================================= HELP =================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe. The list's archives are only accessible to subscribers after
logging in to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

132
tildepals/state-2021-08.txt Normal file
View File

@ -0,0 +1,132 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| JULY 2021 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
================================ ISSUES ================================
Users subscribed from email addresses provided by SFR, a French ISP, no
longer have any issues. The public callout made by Framasoft encouraged
SFR to actually do something.
There are no known ongoing issues.
============================ MESSAGE STATS =============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 367
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
================================= HELP =================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe. The list's archives are only accessible to subscribers after
logging in to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

131
tildepals/state-2021-09.txt Normal file
View File

@ -0,0 +1,131 @@
 __________________________
/\ \
\_| STATE OF THE TILDEPALS |
| SEPTEMBER 2021 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
================================ ISSUES ================================
There are no known issues.
============================ MESSAGE STATS =============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 414
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
================================= HELP =================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to
all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

132
tildepals/state-2021-10.txt Normal file
View File

@ -0,0 +1,132 @@
 __________________________
/\ \
\_| STATE OF THE TILDEPALS |
| SEPTEMBER 2021 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
================================ ISSUES ================================
There are no known issues.
============================ MESSAGE STATS =============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 427
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
- September 13
================================= HELP =================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to
all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

133
tildepals/state-2021-11.txt Normal file
View File

@ -0,0 +1,133 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| NOVEMBER 2021 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
================================ ISSUES ================================
There are no known issues.
============================ MESSAGE STATS =============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 427
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
- September 13
- October 30
================================= HELP =================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to
all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

134
tildepals/state-2021-12.txt Normal file
View File

@ -0,0 +1,134 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| DECEMBER 2021 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
=============================== ISSUES ================================
There are no known issues.
=========================== MESSAGE STATS =============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 508
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
- September 13
- October 30
- November 51
================================= HELP =================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to
all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

135
tildepals/state-2022-01.txt Normal file
View File

@ -0,0 +1,135 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| JANUARY 2022 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
=============================== ISSUES ================================
There are no known issues.
============================ MESSAGE STATS ============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 508
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
- September 13
- October 30
- November 51
- December 37
================================= HELP ================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to
all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

137
tildepals/state-2022-02.txt Normal file
View File

@ -0,0 +1,137 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| FEBRUARY 2022 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
=============================== ISSUES ================================
There are no known issues.
============================ MESSAGE STATS ============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 508
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
- September 13
- October 30
- November 51
- December 37
2022 20
- January 20
================================= HELP ================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.

138
tildepals/state-2022-03.txt Normal file
View File

@ -0,0 +1,138 @@
__________________________
/\ \
\_| STATE OF THE TILDEPALS |
| MARCH 2022 |
| _____________________|_
\_/_______________________/
=========================== CURRENT MEMBERS ===========================
[REDACTED]
=============================== ISSUES ================================
There are no known issues.
============================ MESSAGE STATS ============================
Year, month Messages
-------------- --------
2020 198
- September 5
- October 43
- November 112
- December 38
2021 508
- January 46
- February 61
- March 50
- April 67
- May 39
- June 66
- July 38
- August 47
- September 13
- October 30
- November 51
- December 37
2022 88
- January 20
- February 66
================================= HELP ================================
## GENERAL INFO
Tildepals is hosted on Framalistes, a Sympa instance hosted by
Framasoft, a large French non-profit that encourages contributions to
and usage of FOSS.
This list is configured to be private. Non-subscribers can only tell
that the list exists, that lucidiot is its owner, and that they can
subscribe.
The list's archives are only accessible to subscribers after logging in
to the web UI.
It is possible to send messages to the list without being subscribed to
it, but they will stay in a moderation queue and require approval to be
distributed.
The maximal message size is 5MiB, which leaves ±3.75MiB for attachments.
## SUBSCRIBING
With a web browser: https://framalistes.org/sympa/subscribe/tildepals
With an email: Send an email to sympa@framalistes.org with "subscribe
tildepals" as the subject.
lucidiot then gets an email telling him to confirm your subscription.
## UNSUBSCRIBING
With a web browser: https://framalistes.org/sympa/sigrequest/tildepals
With an email: Send an email to sympa@framalistes.org with "unsubscribe
tildepals" as the subject.
## CONTACT OWNERS
Send an email to tildepals-request@framalistes.org and the mailing list
owners will be notified. lucidiot is currently the only owner and the
only moderator, but this might change in the future; this address always
sends to all owners.
## FIRST WEB UI LOGIN
You can (un)subscribe to the list with just an email address and a name,
but to perform other actions such as accessing the archives or editing
your profile, you will need to get a password for your account.
You can request a temporary password, which will be sent to you by
email, here: https://framalistes.org/sympa/firstpasswd
## WEB ARCHIVES
You can browse the list's web archives, including the messages that may
have been posted before you subscribed, by visting this page:
https://framalistes.org/sympa/arc/tildepals
You will need to login to Sympa; if you do not yet have a password, see
the above section.
If you want to reply to a message you found in the archives but do not
have in your account, you can click the Re-send button on the web UI to
have it sent again; this is preferred over just saying "hey I am
replying to this thing" in your emails.
## SUBSCRIPTION POLICY
Subscription requests from members of m455.casa are approved
unconditionally.
Other requests will only be approved after a notice is sent to the
mailing list and enough members confirm that they either trust the
newcomer or agree to their subscription.
## MODERATION POLICY
Messages pending moderation that are identified to be from subscribers
just using the wrong email addresses will be approved after they have
been made fun of via a message sent by the moderator to the mailing list.
Other messages pending moderation will be reviewed on a case-by-case
basis, with total subjectivity, and their rejection might not result in
a notification to the sender, because nobody from outside the list
should be sending to the list anyway.
If you received a message from this list that you found to be
potentially offending or abusive, or if you want to report any concerns
to the moderators, please email tildepals-request@framalistes.org. This
list aims to preserve the same spirit of safety that the m455.casa IRC
server tries to bring.