casa/bikeshed
casa
/
bikeshed
9
0
Fork 0
Code Issues Pull Requests Releases Activity
bikeshed/rfb/drafts/draft-signature-01.txt

532 lines
16 KiB
Plaintext
Raw 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.
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]
Reference in New Issue View Git Blame Copy Permalink