767 lines
26 KiB
Plaintext
767 lines
26 KiB
Plaintext
|
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]
|