]> arthur.barton.de Git - ngircd-alex.git/blobdiff - doc/Protocol.txt
Add doc/Contributing.txt to distribution archive
[ngircd-alex.git] / doc / Protocol.txt
index d5a3c9293db40a54ce8b5accfd5180bf2acf94ad..5093eea9f3ace44b40b5c6388f0395dcc66f4693 100644 (file)
 
                      ngIRCd - Next Generation IRC Server
 
-                      (c)2001,2002 by Alexander Barton,
+                        (c)2001-2008 Alexander Barton,
                     alex@barton.de, http://www.barton.de/
 
-                  ngIRCd ist freie Software und steht unter
-                       der GNU General Public License.
+               ngIRCd is free software and published under the
+                   terms of the GNU General Public License.
 
                               -- Protocol.txt --
 
 
-I. Kompatibilitaet
-~~~~~~~~~~~~~~~~~~
+I. Compatibility
+~~~~~~~~~~~~~~~~
 
-Der ngIRCd haelt sich an das IRC-Protokoll Version 2.10, wie es in den RFCs
-1459 und 2810-2813 beschrieben ist. Diese (und ggf. weitere fuer den ngIRCd
-relevante) RFCs sind in RFC.txt aufgefuehrt.
+The ngIRCd implements the Internet Relay Chat (IRC) protocol version 2.10
+as defined in RFC ("request for comment") 1459 and 2810-2813. These (and
+probably further relevant RFCs) are listed in doc/RFC.txt.
 
-Leider verhaelt sich aber schon der "Originalserver" nicht immer genau so,
-wie es in den RFCs beschrieben ist. Da der ngIRCd aber ein Ersatz fuer
-eben diesen Server sein soll, werden diese Abweichungen in der Regel vom
-ngIRCd emuliert um die Kompatibilitaet zu wahren.
+Unfortunately, even the "original" ircd doesn't follow these specifications
+in all details. But because the ngIRCd should be a fully compatible
+replacement for this server ("ircd") it tries to emulate these differences.
 
-Sollte dieses Verhalten nicht erwuenscht sein, so kann mit der configure-
-Option "--enable-strict-rfc" der ngIRCd so compiliert werden, dass er sich
-strikt an die entsprechenden RFCs haelt.
+If you don't like this behavior please ./configure the ngIRCd using the
+"--enable-strict-rfc" command line option. But keep in mind: not all IRC
+clients are compatible with a server configured that way, some can't even
+connect at all! Therefore this option usually isn't desired for "normal
+server operation".
 
-ACHTUNG: an einem so compilierten Server koennen sich andere Server und
-Clients, die sich nicht genau an das Protokoll halten, u.U. nicht mehr
-anmelden oder alle Funktionen nutzen! In der Regel ist diese Option daher
-nicht erwuenscht.
 
+II. The IRC+ Protocol
+~~~~~~~~~~~~~~~~~~~~~
 
-II. Erweiterungen des IRC-Protokolls
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Starting with version 0.5.0, the ngIRCd extends the original IRC protocol
+as defined in RFC 2810-2813. This enhanced protocol is named "IRC+". It is
+backwards compatible to the "plain" IRC protocol and will only be used by
+the ngIRCd if it detects that the peer supports it as well.
 
-Erkennt der ngIRCd, dass ein connectierter Server ebenfalls ein ngIRCd ist,
-so werden -- so es die Version auf der Gegenseite unterstuetzt (s.u.) --
-Erweiterungen zum IRC-Protokoll 2.10 verwendet. Diese Erweiterungen werden
-dabei nicht von Versionsnummern abhaengig verwendet, sondern anhand von
-Falgs, die die beiden ngIRCd-Server austauschen, aktiviert.
+The "PASS" command is used to detect the protocol and peer versions see
+RFC 2813 (section 4.1.1) and below.
 
-Die Protokoll- und Server-Erkennung wird mit dem "PASS"-Befehl durchgefuehrt
-(vgl. RFC 2813, Sektion 4.1.1):
 
+II.1 Register new server link
 
-II.1 neuen Server-Link registrieren
+     Command: PASS
+  Parameters: <password> <version> <flags> [<options>]
+     Used by: servers only (with these parameters)
 
-     Befehl: PASS
-  Parameter: <password> <version> <flags> [<options>]
-       Fuer: mit dieser Syntax nur Server
+<password> is the password for this new server link as defined in the server
+configuration which is sent to the peer or received from it.
 
-<password> enthaelt das Passwort fur den neu aufzubauenden Server-Link, wie er
-in der Konfigurationsdatei definiert wurde.
+<version> consists of two parts and is at least 4, at most 14 characters
+long: the first four bytes contain the IRC protocol version number, whereas
+the first two bytes represent the major version, the last two bytes the
+minor version (the string "0210" indicates version 2.10, e.g.).
 
-<version> setzt sich aus zwei Teilen zusammen und ist mindestens 4, maximal
-14 Zeichen lang: die ersten vier Bytes enthalten die Versionsnummer des IRC-
-Protokolls, wobei die ersten zwei Bytes die Major-, die letzten beiden die
-Minor-Revision angeben. "0210" steht also fuer Protokollversion 2.10.
-Die folgenden (optionalen!) 10 Bytes enthalten eine implementationsabhaengige
-Versionsnummer, der ngIRCd liefert hier immer "-ngIRCd" (Zur Identifikation
-des ngIRCd sollte dieser String jedoch NICHT verwendet werden, s.u.).
+The following optional(!) 10 bytes contain an implementation-dependent
+version number. Servers supporting the IRC+ protocol as defined in this
+document provide the string "-IRC+" here.
 
-<flags> setzt sich ebenfalls aus zwei Bestandteilen zusammen und ist maximal
-100 Bytes lang. Getrennt werden die beiden Teile mit dem Zeichen "|". Der
-erste Teil enthaelt den Namen der Implementation, der ngIRCd liefert hier z.B.
-"ngIRCd", der Originalserver "IRC". Anhand dieser "ID" kann zwischen Server-
-Implementationen unterschieden werden.
-Der zweite Teil (nach dem "|") ist implementationsabhaengig und wird vom ngIRCd
-nur ausgewertet, wenn die Gegenseite ebenfalls ein ngIRCd ist. In diesem Fall
-wird folgende Syntax erwartet: "<serverversion>[:<serverflags>]".
-<version> ist hier eine ASCII-Darstellung der Versionsnummer, <flags> zeigt die
-vom Server unterstuetzten Erweiterungen an (und kann die leere Menge sein).
+Example for <version>: "0210-IRC+".
 
-Mit dem optionalen Parameter <options> werden Server-Optionen bekannt gemacht,
-wie sie in RFC 2813, Sektion 4.1.1 definiert sind.
+<flags> consists of two parts separated with the character "|" and is at
+most 100 bytes long. The first part contains the name of the implementation
+(ngIRCd sets this to "ngircd", the original ircd to "IRC", e.g.). The second
+part is implementation-dependent and should only be parsed if the peer
+supports the IRC+ protocol as well. In this case the following syntax is
+used: "<serverversion>[:<serverflags>]".
 
-Folgende <serverflags> werden zur Zeit vom ngIRCd verwendet:
+<serverversion> is an ASCII representation of the clear-text server version
+number, <serverflags> indicates the supported IRC+ protocol extensions (and
+may be empty!).
 
-- o: IRC-Operatoren duerfen auch dann Channel- und Channel-User-Modes aendern,
-     wenn sie kein Channel-Operator im betroffenen Channel sind.
+The following <serverflags> are defined at the moment:
 
+- C: The server supports the CHANINFO command.
+
+- L: INVITE- and BAN-lists should be synchronized between servers: if the
+     peer understands this flag, it will send "MODE +I" and "MODE +b"
+     commands after the server link has been established.
+
+- H: The server supports the "enhanced server handshake", see section II.2
+     for a detailed description.
+
+- o: IRC operators are allowed to change channel- and channel-user-modes
+     even if they aren't channel-operator of the affected channel.
+
+- S: The server supports the SERVICE command (on this link).
+
+- Z: Compressed server links are supported by the server.
+
+Example for a complete <flags> string: "ngircd|0.7.5:CZ".
+
+The optional parameter <options> is used to propagate server options as
+defined in RFC 2813, section 4.1.1.
+
+
+II.2 Enhanced Server Handshake
+
+The "enhanced server handshake" is used when both servers support this IRC+
+extension, which is indicated by the 'H' flag in the <serverflags> sent with
+the PASS command, see section II.1.
+
+It basically means, that after exchanging the PASS and SERVER commands the
+server is not registered in the network (as usual), but that IRC numerics
+are exchanged until the numeric 376 (ENDOFMOTD) is received. Afterwards the
+peer is registered in the network as with the regular IRC protocol.
+
+A server implementing the enhanced server handshake (and indicating this
+using 'H' in the <serverflags>) MUST ignore all unknown numerics to it
+silently.
+
+In addition, such a server should at least send the numeric 005 (ISUPPORT)
+to its peer, containing the following information. Syntax: <key>=<value>,
+one token per IRC parameter. If the server has to send more than 12 token
+it must send separate ISUPPORT numerics (this is a limitation of the IRC
+protocol which allows at max 15 arguments per command).
+
+ - NICKLEN: Maximum nickname length. Default: 9.
+ - CASEMAPPING: Case mapping used for nick- and channel name comparing.
+   Default: "ascii", the chars [a-z] are lowercase of [A-Z].
+ - PREFIX: List of channel modes a person can get and the respective prefix
+   a channel or nickname will get in case the person has it. The order of the
+   modes goes from most powerful to least powerful. Default: "(ov)@+"
+ - CHANTYPES: Supported channel prefixes. Default: "#".
+ - CHANMODES: List of channel modes for 4 types, separated by comma (","):
+   Mode that adds or removes a nick or address to a list, mode that changes
+   a setting (both have always has a parameter), mode that changes a setting
+   and only has a parameter when set, and mode that changes a setting and
+   never has a parameter. For example "bI,k,l,imnPst".
+ - CHANLIMIT: Maximum number of channels allowed to join by channel prefix,
+   for example "#:10".
+
+Please see <http://www.irc.org/tech_docs/005.html> for details.
+
+The information exchanged using ISUPPORT can be used to detect configuration
+incompatibilities (different maximum nick name length, for example) and
+therefore to disconnect the peer prior to registering it in the network.
+
+
+II.3 Exchange channel-modes, topics, and persistent channels
+
+     Command: CHANINFO
+  Parameters: <channel> +<modes> [[<key> <limit>] <topic>]
+     Used by: servers only
+
+CHANINFO is used by servers to inform each other about a channel: its
+modes, channel key, user limits and its topic. The parameter combination
+<key> and <limit> is optional, as well as the <topic> parameter, so that
+there are three possible forms of this command:
+
+  CHANINFO <channel> +<modes>
+  CHANINFO <channel> +<modes> <topic>
+  CHANINFO <channel> +<modes> <key> <limit> <topic>
+
+If the channel already exists on the server receiving the CHANINFO command,
+it only adopts the <modes> (or the <topic>) if there are no modes (or topic)
+already set. It there are already values set the server ignores the
+corresponding parameter.
+
+If the channel doesn't exists at all it will be created.
+
+The parameter <key> must be ignored if a channel has no key (the parameter
+<modes> doesn't list the "k" channel mode). In this case <key> should
+contain "*" because the parameter <key> is required by the CHANINFO syntax
+and therefore can't be omitted. The parameter <limit> must be ignored when
+a channel has no user limit (the parameter <modes> doesn't list the "l"
+channel mode). In this case <limit> should be "0".
+
+
+II.4 Update webchat/proxy client information
+
+     Command: WEBIRC
+  Parameters: <password> <username> <hostname> <ip-address>
+     Used by: unregistered clients only
+
+The WEBIRC command is used by some Web-to-IRC gateways to set the correct
+user name and host name of users instead of their own. It must be the very
+first command sent to the server, even before USER and NICK commands!
+
+The <password> must be set in the server configuration file to prevent
+unauthorized clients to fake their identity; it is an arbitrary string.
 
--- 
-$Id: Protocol.txt,v 1.1 2002/09/02 21:04:27 alex Exp $