casa/bikeshed
casa
/
bikeshed
9
0
Fork 0
Code Issues Pull Requests Releases Activity
bikeshed/rfb/rfb1.txt

767 lines
26 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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]
Reference in New Issue View Git Blame Copy Permalink