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]
|
||
|
||
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]
|