TeapotChat Administrator Council
Request For Comments: 3
Category: Standards Track
Status: Standard
Netizen Land - The Internet
Wael Karram
December 2023
This document describes the rules and regulations pertaining to official communications in administrative settings.
This document specifies a
standards track for the TeapotChat network, and requests
discussion and suggestions for improvement.
Distribution of this memo is limited strictly to authorized
network administrators within the teapot chat network or any
third party authorized by them.
Copyright (C) 2023 TeapotChat Administrator Council. All rights reserved.
Table of Contents
|
1. Introduction |
. . . . . . . . . . . . . . . . . . . . . . .
3
|
1.1. Overview |
. . . . . . . . . . . . . . . . . . . . .
3
|
1.2. Terminology |
. . . . . . . . . . . . . . . . . . . .
3
|
2. Preferred Communication Methods |
. . . . . . . . . . . . .
4
|
3. Communication Channel Types |
. . . . . . . . . . . . . . .
4
|
4. Penalties |
. . . . . . . . . . . . . . . . . . . . . . . .
5
|
5. Mode-Specific Regulations |
. . . . . . . . . . . . . . . .
5
The regulations and rules governing all official communications by the administrative teams of TeapotChat are detailed in the following lines.
Definition:
A Preferred Communication Method is a method for
communication to be preferably used when conduction official
communications for the Core Council or sub councils,
or on their behalf (including internal communications).
Definition:
The issue of synchronicity shall be judged by how
urgent the communication is, what is the reasonably expected
time for all the involved parties to see and react to it and
how much effort overall is involved - higher urgency and
lower effort lead to more synchronous modes of
communication. Note that modes can be mixed even for the
same issue.
This document inherits keywords from RFC 1 and 2, see
section 1.2 "Terminology". The keywords
denoting requirements, including optional requirements,
shall be interpreted as defined in IETF RFC 2119.
In all communications, it is
preferable to use plain-text UTF-8 or ASCII encoded text to
communicate the intended message, this allows for the
greatest degree of compatibility and accessibility of the
message.
In general the preferred protocols are email,
IRC, and XMPP. Each as detailed in their
respective IETF RFCs.
Specifically, any potentially long-winded discussion is best
kept to the topic’s corresponding mailing list as to
allow asynchronous discussion. This certainly applies to any
type of vote that isn’t minor - though an
exception is granted in that a core team member may post-hoc
update the mailing list with the result of the vote after
being conducted in a synchronous channel. Though in the case
that not all voting members can reply synchronously - it is
good practice to notify them asynchronously via email,
either directly or on the corresponding mailing list.
For potentially sensitive communications, XMPP is the
preferred communications channel, see section 6-
Mode Specific Regulations.
As indicated earlier there are
synchronous and asynchronous communication
channels. Preference is generally for IRC unless the
communication is either asynchronous and
long-winded/complicated/multifaceted, or in the case
that it is a sensitive communication which requires better
cryptographic security than TLS can afford.
Moreover, ALL council members of any level are
REQUIRED to connect over TLS/SSL/a secure
connection on IRC if they intend to communicate an
official network manner. An exception is granted in the case
of a local connection on a trusted server network.
Not adhering by these
regulations may cause penalties to be levied against the
party breaking these regulations.
In the case of RFC Proposal this is a legitimate
reason for a veto from a core council member.
In the case of lower councils, other council members can
under repeated violations request the issue be elevated to
the core members’ council and have them decide what is
fit to be done - possibly including member dismissal.
When using XMPP it is required to use OMEMO encryption (XEP 0384), in the case of IRC it is required to use a TLS/SSL encrypted channel (IETF RFCs 7194,8446), and in the case of email then PGP/GPG signing should be used with encryption wherever relevant using (IETF RFCs 3156,4880,2440).
Authors’ Addresses:
Wael Karram - wael@waelk.tech/wael@teapot.chat