diff --git a/banana/ads.txt b/banana/ads.txt new file mode 100644 index 0000000..8d67968 --- /dev/null +++ b/banana/ads.txt @@ -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. \ No newline at end of file diff --git a/banana/media-types/text/vnd.bikeshed.signature.txt b/banana/media-types/text/vnd.bikeshed.signature.txt new file mode 100644 index 0000000..7c3462f --- /dev/null +++ b/banana/media-types/text/vnd.bikeshed.signature.txt @@ -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. \ No newline at end of file diff --git a/banana/media-types/text/vnd.unix.cds.txt b/banana/media-types/text/vnd.unix.cds.txt new file mode 100644 index 0000000..bc740b4 --- /dev/null +++ b/banana/media-types/text/vnd.unix.cds.txt @@ -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. \ No newline at end of file diff --git a/banana/report-2021-07.txt b/banana/report-2021-07.txt new file mode 100644 index 0000000..81883f2 --- /dev/null +++ b/banana/report-2021-07.txt @@ -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, +. + +[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. + + +[CDF]: Microsoft, "CDF Reference for Active Channels", August 2017, +. + +[CDF-W3C]: Ellerman, C., "Channel Definition Format (CDF)", W3C Note +NOTE-CDFsubmit, March 1997, . + +[DISCORD]: Discord, "Discord", May 2015, . + +[GEMINI]: Solderpunk, "Project Gemini", Speculative specification, +v0.14.3, November 2020, +. + +[HINA]: kohgushi, "Asahina-Antenna meta data format version 2.2 +(HINA/2.2)", Revision 0.13, July 2002, +. + +[MSNP]: Mintz, M., Sayers, A., "MSN Messenger Protocol", December 2003, +. + +[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, +. + +[RFC1459]: Oikarinen, J., Reed, D., "Internet Relay Chat Protocol", +RFC 1459, DOI 10.17847/RFC1459, May 1993, +. + +[RFC2810]: Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, +DOI 10.17847/RFC2810, April 2000, +. + +[RFC2811]: Kalt, C., "Internet Relay Chat: Channel Management", +RFC 2811, DOI 10.17847/RFC2811, April 2000, +. + +[RFC2812]: Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, +DOI 10.17847/RFC2812, April 2000, +. + +[RFC2813]: Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, +DOI 10.17847/RFC2813, April 2000, +. + +[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, +. + +[RFC4287]: Nottingham, M., Sayre, R., "The Atom Syndication Format", +RFC 4287, DOI 10.17487/RFC4287, December 2005, +. + +[RFC6120]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Core", RFC 6120, DOI 10.17847/RFC6120, +March 2011, . + +[RFC6121]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17847/RFC6121, +March 2011, . + +[RFC7194]: Hartmann, R., "Default Port for Internet Relay Chat (IRC) +via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194, August 2014, +. + +[RFC7230]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, +June 2014, . + +[RFC7231]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, +June 2014, . + +[RFC7232]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, +June 2014, . + +[RFC7233]: Fielding, R., Lafon, Y., Reschke, J., "Hypertext Transfer +Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, +June 2014, . + +[RFC7234]: Fielding, R., Nottingham, M., Reschke, J., "Hypertext +Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, +June 2014, . + +[RFC7235]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, +. + +[RFC7622]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Address Format", RFC 7622, DOI 10.17847/RFC7622, September 2015, +. + +[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, . + +[RSS2]: RSS Advisory Board, "RSS 2.0 Specification", Version 2.0.11, +March 2009, . + +[JSONFEED]: Simmons, B. and M. Reece, "JSON Feed Version 1.1", +August 2020, . + +[TWTXT]: buckket, "twtxt Documentation", September 2017, +. diff --git a/banana/report-2021-08.txt b/banana/report-2021-08.txt new file mode 100644 index 0000000..61d4761 --- /dev/null +++ b/banana/report-2021-08.txt @@ -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, +. + +[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. + + +[CDF]: Microsoft, "CDF Reference for Active Channels", August 2017, +. + +[CDF-W3C]: Ellerman, C., "Channel Definition Format (CDF)", W3C Note +NOTE-CDFsubmit, March 1997, . + +[DISCORD]: Discord, "Discord", May 2015, . + +[GEMINI]: Solderpunk, "Project Gemini", Speculative specification, +v0.14.3, November 2020, +. + +[HINA]: kohgushi, "Asahina-Antenna meta data format version 2.2 +(HINA/2.2)", Revision 0.13, July 2002, +. + +[MSNP]: Mintz, M., Sayers, A., "MSN Messenger Protocol", December 2003, +. + +[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, +. + +[RFC1459]: Oikarinen, J., Reed, D., "Internet Relay Chat Protocol", +RFC 1459, DOI 10.17847/RFC1459, May 1993, +. + +[RFC2810]: Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, +DOI 10.17847/RFC2810, April 2000, +. + +[RFC2811]: Kalt, C., "Internet Relay Chat: Channel Management", +RFC 2811, DOI 10.17847/RFC2811, April 2000, +. + +[RFC2812]: Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, +DOI 10.17847/RFC2812, April 2000, +. + +[RFC2813]: Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, +DOI 10.17847/RFC2813, April 2000, +. + +[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, +. + +[RFC4287]: Nottingham, M., Sayre, R., "The Atom Syndication Format", +RFC 4287, DOI 10.17487/RFC4287, December 2005, +. + +[RFC6120]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Core", RFC 6120, DOI 10.17847/RFC6120, +March 2011, . + +[RFC6121]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17847/RFC6121, +March 2011, . + +[RFC7194]: Hartmann, R., "Default Port for Internet Relay Chat (IRC) +via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194, August 2014, +. + +[RFC7230]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, +June 2014, . + +[RFC7231]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, +June 2014, . + +[RFC7232]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, +June 2014, . + +[RFC7233]: Fielding, R., Lafon, Y., Reschke, J., "Hypertext Transfer +Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, +June 2014, . + +[RFC7234]: Fielding, R., Nottingham, M., Reschke, J., "Hypertext +Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, +June 2014, . + +[RFC7235]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, +. + +[RFC7622]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Address Format", RFC 7622, DOI 10.17847/RFC7622, September 2015, +. + +[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, . + +[RSS2]: RSS Advisory Board, "RSS 2.0 Specification", Version 2.0.11, +March 2009, . + +[JSONFEED]: Simmons, B. and M. Reece, "JSON Feed Version 1.1", +August 2020, . + +[TWTXT]: buckket, "twtxt Documentation", September 2017, +. diff --git a/banana/report-changelog.txt b/banana/report-changelog.txt new file mode 100644 index 0000000..ab8c7b6 --- /dev/null +++ b/banana/report-changelog.txt @@ -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. \ No newline at end of file diff --git a/banana/signature-abbrevs.txt b/banana/signature-abbrevs.txt new file mode 100644 index 0000000..93a5c36 --- /dev/null +++ b/banana/signature-abbrevs.txt @@ -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, +. + +[CDF]: Microsoft, "CDF Reference for Active Channels", August 2017, +. + +[CDF-W3C]: Ellerman, C., "Channel Definition Format (CDF)", W3C Note +NOTE-CDFsubmit, March 1997, . + +[DISCORD]: Discord, "Discord", May 2015, . + +[GEMINI]: Solderpunk, "Project Gemini", Speculative specification, +v0.14.3, November 2020, +. + +[MSNP]: Mintz, M., Sayers, A., "MSN Messenger Protocol", December 2003, +. + +[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, +. + +[RFC1459]: Oikarinen, J., Reed, D., "Internet Relay Chat Protocol", +RFC 1459, DOI 10.17847/RFC1459, May 1993, +. + +[RFC2810]: Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, +DOI 10.17847/RFC2810, April 2000, +. + +[RFC2811]: Kalt, C., "Internet Relay Chat: Channel Management", +RFC 2811, DOI 10.17847/RFC2811, April 2000, +. + +[RFC2812]: Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, +DOI 10.17847/RFC2812, April 2000, +. + +[RFC2813]: Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, +DOI 10.17847/RFC2813, April 2000, +. + +[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, +. + +[RFC4287]: Nottingham, M., Sayre, R., "The Atom Syndication Format", +RFC 4287, DOI 10.17487/RFC4287, December 2005, +. + +[RFC6120]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Core", RFC 6120, DOI 10.17847/RFC6120, +March 2011, . + +[RFC6121]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17847/RFC6121, +March 2011, . + +[RFC7194]: Hartmann, R., "Default Port for Internet Relay Chat (IRC) +via TLS/SSL", RFC 7194, DOI 10.17847/RFC7194, August 2014, +. + +[RFC7230]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, +June 2014, . + +[RFC7231]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, +June 2014, . + +[RFC7232]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, +June 2014, . + +[RFC7233]: Fielding, R., Lafon, Y., Reschke, J., "Hypertext Transfer +Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, +June 2014, . + +[RFC7234]: Fielding, R., Nottingham, M., Reschke, J., "Hypertext +Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, +June 2014, . + +[RFC7235]: Fielding, R., Reschke, J., "Hypertext Transfer Protocol +(HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, +. + +[RFC7622]: Saint-Andre, P., "Extensible Messaging and Presence Protocol +(XMPP): Address Format", RFC 7622, DOI 10.17847/RFC7622, September 2015, +. + +[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, . + +[RSS2]: RSS Advisory Board, "RSS 2.0 Specification", Version 2.0.11, +March 2009, . + +[JSONFEED]: Simmons, B. and M. Reece, "JSON Feed Version 1.1", +August 2020, . + +[TWTXT]: buckket, "twtxt Documentation", September 2017, +. diff --git a/banana/unit-prefixes.txt b/banana/unit-prefixes.txt new file mode 100644 index 0000000..49e3c63 --- /dev/null +++ b/banana/unit-prefixes.txt @@ -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. \ No newline at end of file diff --git a/banana/weeds.txt b/banana/weeds.txt new file mode 100644 index 0000000..81bfafb --- /dev/null +++ b/banana/weeds.txt @@ -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 \ No newline at end of file diff --git a/rfb/drafts/draft-cds-00.txt b/rfb/drafts/draft-cds-00.txt new file mode 100644 index 0000000..eb45ee6 --- /dev/null +++ b/rfb/drafts/draft-cds-00.txt @@ -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 = + + + +~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, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + + [RFC4041] Farrel, A., "Requirements for Morality Sections in Routing + Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005, + . + + [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- + Separated Values (CSV) Files", RFC 4180, + DOI 10.17487/RFC4180, October 2005, + . + + [RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC2234, January 2008, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +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, + + +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] \ No newline at end of file diff --git a/rfb/drafts/draft-git-00.txt b/rfb/drafts/draft-git-00.txt new file mode 100644 index 0000000..82b86ab --- /dev/null +++ b/rfb/drafts/draft-git-00.txt @@ -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 . + +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---.txt`, + where is the arbitrary name given to the draft in kebab-case, + is the draft number with two digits, and is the + date in [RFC3339] format. For example, this standard in its draft + form could have been archived as `draft-git-00-2022-07-16.txt`. + + + +~lucidiot 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--.txt`, + with each placeholder having the same signification as above. + + Should a Bikeshed-Draft require an attachment of some sort that is + in a file separate of the draft, including a LICENSE or README.md + file as required by other sections of this standard, then the draft + and all of its attachments SHOULD be placed in a sub-directory + following the same naming pattern, as `rfb/drafts/ + draft--[-]/draft--[-].txt`. + +3.2. Requests for Bikeshedding + + All Requests for Bikeshedding SHOULD be placed under the `rfb/` path + and be stored in plain-text UTF-8 format. Each Request for + Bikeshedding MUST use a naming convention of `rfb.txt`, + where is the number of that RFB with no leading zeros. + + Requests for Bikeshedding MUST be archived by the Requests for + Bikeshedding Editor at the time of their publication. + + Should a Request for Bikeshedding require an attachment of some sort + that is in a file separate from the Request for Bikeshedding's text, + including a LICENSE or README.md file as required by other sections + of this standard, then the Request for Bikeshedding and all of its + attachments SHOULD be placed in a sub-directory following the same + naming pattern, `rfb/rfb/rfb.txt`. + + The older, non-updated versions of Requests for Bikeshedding that + predate the standardization of their naming in [RFB2], then-called + Requests for Comments, MAY be archived as `rfc` instead. + Their updated versions as RFBs MUST however also be archived. + +3.3. Bikeshedding Assigned Numbers Assignation and Normalization + Authority + + All assignations, registries and all other kinds of data managed by + the Bikeshedding Assigned Numbers Assignation and Normalization + Authority (BANANA) MUST be archived in the Public Archive, in their + current state of application. Any update to their contents MUST be + reflected by an update of the Public Archive. Archiving the updated + reports sent to the mailing list by the BANANA is OPTIONAL. + + All archived documents of the Bikeshedding Assigned Numbers + Assignation and Normalization Authority MUST be kept under the + `banana/` subdirectory. The naming conventions and other + structures under this subdirectory are left up to the Archivists and + the Bikeshedding Assigned Numbers Assignation and Normalization + Authority Management and Administration Nominee (BANANA-MAN). + + + + + +~lucidiot 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, + . + + [COMMONMARK] MacFarlane, J., "CommonMark Spec", Version 0.30, + June 2021, . + + [OPEN-DEF] Open Definition, "Open Definition 2.1", November 2015, + . + + [OSI-DEF] Open Source Initiative, "The Open Source Definition", + Version 1.9, March 2007, . + + [RFB1] ~lucidiot, "Tildepals Email Signatures for + Bikeshedders", RFB 1, March 2021. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the + Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, + July 2002, . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, + November 2003, + . + + [RFC4041] Farrel, A., "Requirements for Morality Sections in + Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041, + April 2005, . + + [RFC4180] Shafranovich, Y., "Common Format and MIME Type for + Comma-Separated Values (CSV) Files", RFC 4180, + DOI 10.17487/RFC4180, October 2005, + . + + [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key + Words for Use in RFCs to Indicate Requirement Levels", + RFC 6919, DOI 10.17487/RFC6919, April 1 2013, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + . + + +~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, + . + + [RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S., + "Establishing the Protocol Police", RFC 8962, + DOI 10.17487/RFC8962, April 1 2021, + . + + [SQLITE] SQLite, "Database File Format", + . + + [HTML] Web Hypertext Application Technology Working Group, + "HTML Living Standard", + . + + [W3C-XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, + "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C + REC-xml, October 2000, . + +11.2. Informative References + + [CASA-GIT] Tildegit, "Commonhealth of Casakhstan", April 2021, + . + + [RFC1149] Waitzman, D., "Standard for the transmission of IP + datagrams on avian carriers", RFC 1149, + DOI 10.17487/RFC1149, April 1 1990, + . + + [RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of + Service", RFC 2549, DOI 10.17487/RFC2549, April 1 1999, + . + +Appendix A. Warranty Exclusion Statement + + This document and the information contained herein is provided on an + "AS IS" basis and M455.CASA DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + 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] \ No newline at end of file diff --git a/rfb/drafts/draft-hina-00.txt b/rfb/drafts/draft-hina-00.txt new file mode 100644 index 0000000..591bc6f --- /dev/null +++ b/rfb/drafts/draft-hina-00.txt @@ -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 = + CHAR = + UPALPHA = + LOALPHA = + ALPHA = UPALPHA | LOALPHA + DIGIT = + WORD = 1*(ALPHA|DIGIT) + + CTL = + CR = + LF = + SP = + HT = + <"> = + + CRLF = CR LF + + TEXT = + TOKEN = + + 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 = + + 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 = + + The original Japanese specification defined result-code as follows: + + result-code = + +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, . + + [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, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + DOI 10.17487/RFC2396, August 1998, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [STATUS] "Hypertext Transfer Protocol (HTTP) Status Code Registry", + Internet Assigned Numbers Authority, + . + +11.2. Informative References + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", RFC 822, DOI 10.17487/RFC0822, + August 1982, . + + [RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version + 2.0.11, March 2009, + . + + [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, . + + + + + + + +~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] diff --git a/rfb/drafts/draft-hina-01.txt b/rfb/drafts/draft-hina-01.txt new file mode 100644 index 0000000..63c0b95 --- /dev/null +++ b/rfb/drafts/draft-hina-01.txt @@ -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 = + CHAR = + UPALPHA = + LOALPHA = + ALPHA = UPALPHA | LOALPHA + DIGIT = + WORD = 1*(ALPHA|DIGIT) + + CTL = + CR = + LF = + SP = + HT = + <"> = + + CRLF = CR LF + + TEXT = + TOKEN = + + 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 = + + 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 = + + The original Japanese specification defined result-code as follows: + + result-code = + +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, . + + [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, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + DOI 10.17487/RFC2396, August 1998, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [STATUS] "Hypertext Transfer Protocol (HTTP) Status Code Registry", + Internet Assigned Numbers Authority, + . + +11.2. Informative References + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", RFC 822, DOI 10.17487/RFC0822, + August 1982, . + + [RSS2] RSS Advisory Board, "RSS 2.0 Specification", Version + 2.0.11, March 2009, + . + + [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, . + + + + + + + +~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] diff --git a/rfb/drafts/draft-ietf-compat-00.txt b/rfb/drafts/draft-ietf-compat-00.txt new file mode 100644 index 0000000..5708a33 --- /dev/null +++ b/rfb/drafts/draft-ietf-compat-00.txt @@ -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, + . + + [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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S., + "Establishing the Protocol Police", RFC 8962, + DOI 10.17487/RFC8962, April 2021, + . + + +~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, . + +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] diff --git a/rfb/drafts/draft-lirs-00.txt b/rfb/drafts/draft-lirs-00.txt new file mode 100644 index 0000000..85d180a --- /dev/null +++ b/rfb/drafts/draft-lirs-00.txt @@ -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 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] diff --git a/rfb/drafts/draft-signature-01.txt b/rfb/drafts/draft-signature-01.txt new file mode 100644 index 0000000..f95dece --- /dev/null +++ b/rfb/drafts/draft-signature-01.txt @@ -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] diff --git a/rfb/drafts/draft-signature-02.txt b/rfb/drafts/draft-signature-02.txt new file mode 100644 index 0000000..4bf0a8a --- /dev/null +++ b/rfb/drafts/draft-signature-02.txt @@ -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] diff --git a/rfb/drafts/draft-vax-00.txt b/rfb/drafts/draft-vax-00.txt new file mode 100644 index 0000000..eb2e084 --- /dev/null +++ b/rfb/drafts/draft-vax-00.txt @@ -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] \ No newline at end of file diff --git a/rfb/drafts/draft-vax-01.txt b/rfb/drafts/draft-vax-01.txt new file mode 100644 index 0000000..6e8047a --- /dev/null +++ b/rfb/drafts/draft-vax-01.txt @@ -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] \ No newline at end of file diff --git a/rfb/drafts/draft-weed-00.txt b/rfb/drafts/draft-weed-00.txt new file mode 100644 index 0000000..c53818b --- /dev/null +++ b/rfb/drafts/draft-weed-00.txt @@ -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] diff --git a/rfb/drafts/draft-weed-01.txt b/rfb/drafts/draft-weed-01.txt new file mode 100644 index 0000000..ecac67d --- /dev/null +++ b/rfb/drafts/draft-weed-01.txt @@ -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] diff --git a/rfb/rfb1.txt b/rfb/rfb1.txt new file mode 100644 index 0000000..989b44d --- /dev/null +++ b/rfb/rfb1.txt @@ -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] diff --git a/rfb/rfb2.txt b/rfb/rfb2.txt new file mode 100644 index 0000000..69653f6 --- /dev/null +++ b/rfb/rfb2.txt @@ -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] diff --git a/rfb/rfb3.txt b/rfb/rfb3.txt new file mode 100644 index 0000000..42da469 --- /dev/null +++ b/rfb/rfb3.txt @@ -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] diff --git a/rfb/rfb4.txt b/rfb/rfb4.txt new file mode 100644 index 0000000..ad3980a --- /dev/null +++ b/rfb/rfb4.txt @@ -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] diff --git a/rfb/rfb5.txt b/rfb/rfb5.txt new file mode 100644 index 0000000..d097710 --- /dev/null +++ b/rfb/rfb5.txt @@ -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] diff --git a/rfb/rfb6.txt b/rfb/rfb6.txt new file mode 100644 index 0000000..9a6abab --- /dev/null +++ b/rfb/rfb6.txt @@ -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] \ No newline at end of file diff --git a/rfb/rfb7.txt b/rfb/rfb7.txt new file mode 100644 index 0000000..25cf2b8 --- /dev/null +++ b/rfb/rfb7.txt @@ -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] \ No newline at end of file diff --git a/rfb/rfb8.txt b/rfb/rfb8.txt new file mode 100644 index 0000000..f12b67f --- /dev/null +++ b/rfb/rfb8.txt @@ -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] \ No newline at end of file diff --git a/rfb/rfc1.txt b/rfb/rfc1.txt new file mode 100644 index 0000000..4e881f9 --- /dev/null +++ b/rfb/rfc1.txt @@ -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] diff --git a/tildepals/state-2021-07.txt b/tildepals/state-2021-07.txt new file mode 100644 index 0000000..f4bc089 --- /dev/null +++ b/tildepals/state-2021-07.txt @@ -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. diff --git a/tildepals/state-2021-08.txt b/tildepals/state-2021-08.txt new file mode 100644 index 0000000..f8d0e67 --- /dev/null +++ b/tildepals/state-2021-08.txt @@ -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. diff --git a/tildepals/state-2021-09.txt b/tildepals/state-2021-09.txt new file mode 100644 index 0000000..c7bbf10 --- /dev/null +++ b/tildepals/state-2021-09.txt @@ -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. diff --git a/tildepals/state-2021-10.txt b/tildepals/state-2021-10.txt new file mode 100644 index 0000000..22bac95 --- /dev/null +++ b/tildepals/state-2021-10.txt @@ -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. diff --git a/tildepals/state-2021-11.txt b/tildepals/state-2021-11.txt new file mode 100644 index 0000000..4f57539 --- /dev/null +++ b/tildepals/state-2021-11.txt @@ -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. diff --git a/tildepals/state-2021-12.txt b/tildepals/state-2021-12.txt new file mode 100644 index 0000000..1883996 --- /dev/null +++ b/tildepals/state-2021-12.txt @@ -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. diff --git a/tildepals/state-2022-01.txt b/tildepals/state-2022-01.txt new file mode 100644 index 0000000..0850033 --- /dev/null +++ b/tildepals/state-2022-01.txt @@ -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. diff --git a/tildepals/state-2022-02.txt b/tildepals/state-2022-02.txt new file mode 100644 index 0000000..3b350f2 --- /dev/null +++ b/tildepals/state-2022-02.txt @@ -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. diff --git a/tildepals/state-2022-03.txt b/tildepals/state-2022-03.txt new file mode 100644 index 0000000..b543f91 --- /dev/null +++ b/tildepals/state-2022-03.txt @@ -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.