Statut de ce mémo

Résumé

Le protocole IRC et un protocole en mode texte, dont le client le plus simple est n'importe quel programme de TCP capable de se connecter à un serveur.

Table des matières

   1.  Introduction
      1.1  Serveurs
      1.2  Clients
         1.2.1 Opérateurs
      1.3 Canaux
      1.3.1 Opérateurs de canaux
   2. Spécification IRC
      2.1 Aperçu
      2.2 Les jeux de caractères
      2.3 Messages
         2.3.1 Le format de message en 'pseudo' BNF
      2.4 Réponses numériques
   3. Concepts IRC
      3.1 Communication un à un
      3.2 Un à plusieurs
         3.2.1 A une liste
         3.2.2 A un groupe (canal)
         3.2.3 A un masque d'hôte/de serveur
      3.3 Un à tous
         3.3.1 Client à client
         3.3.2 Client à serveur
         3.3.3 Serveur à serveur
   4. Détails des messages
      4.1 Etablissement de connection
         4.1.1 Message PASSWORD 
         4.1.2 Message NICK
         4.1.3 Message USER
         4.1.4 Message SERVER
         4.1.5 Message OPER
         4.1.6 Message QUIT
         4.1.7 Message SQUIT
      4.2 Opérations sur les canaux
         4.2.1 Message JOIN
         4.2.2 Message PART
         4.2.3 Message MODE
            4.2.3.1 Les modes des canaux
            4.2.3.2 Les modes des utilisateurs
         4.2.4 Message TOPIC
         4.2.5 Message NAMES
         4.2.6 Message LIST
         4.2.7 Message INVITE
         4.2.8 Message KICK
      4.3 Requêtes et commandes des serveurs
         4.3.1 Message VERSION
         4.3.2 Message STATS
         4.3.3 Message LINKS
         4.3.4 Message TIME
         4.3.5 Message CONNECT
         4.3.6 Message TRACE
         4.3.7 Message ADMIN
         4.3.8 Message INFO
      4.4 Envoi de messages
         4.4.1 Messages privés
         4.4.2 NOTICE
      4.5 Requêtes basées sur les utilisateurs
         4.5.1 Message WHO
         4.5.2 Message WHOIS
         4.5.3 Message WHOWAS
      4.6 Messages divers
         4.6.1 Message KILL 
         4.6.2 Message PING
         4.6.3 Message PONG
         4.6.4 Message ERROR
   5. Messages optionnels
      5.1 Message AWAY
      5.2 Commande REHASH
      5.3 Commande RESTART
      5.4 Message SUMMON
      5.5 Message USER
      5.6 Commande OPERWALL
      5.7 Message USERHOST
      5.8 Message ISON
   6. Réponses 
      6.1 Réponses d'erreur
      6.2 Réponses aux commandes
      6.3 Nombres réservés
   7. Authentification des clients et serveurs
   8. Implémentations actuelles
      8.1 Protocole Réseau: TCP
         8.1.1 Support des sockets Unix
      8.2 Traitement des commandes
      8.3 Distribution de messages
      8.4 La vie d'une connection
      8.5 Etablissement d'une connection serveur à client
      8.6 Etablissement d'une connection serveur/serveur
         8.6.1 Echange des informations d'état des serveurs à la connection
      8.7 Terminaison des connections serveur/client
      8.8 Terminaison des connections serveur/serveur
      8.9 Suivi des changements de pseudonymes
      8.10 Contrôle d'inondation des clients
      8.11 Recherches non bloquantes
         8.11.1 Recherche du nom d'hôte (DNS)
         8.11.2 Recherche du nom d'utilisateur (IDENT)
      8.12 Fichier de configuration
         8.12.1 Autorisation des connections de clients
         8.12.2 Opérateurs
         8.12.3 Autorisation des connections de serveurs
         8.12.4 Admin
      8.13 Appartenance à un canal.
   9. Problèmes actuels
      9.1 Localisation
      9.2 Identifiants
         9.2.1 Pseudonymes
         9.2.2 Canaux
         9.2.3 Serveurs
      9.3 Algorithmes
   10. Support actuel et disponibilité
   11. Considérations de sécurité
   12. Adresses des auteurs

1. Introduction

Le protocole IRC a été développé sur des systèmes utilisant le protocole réseau TCP/IP, bien qu'il n'y ait pas de raison que cela reste la seule sphère dans laquelle il opère.

L'IRC, en lui-même, est un système de téléconférence qui (grâce à l'utilisation d'un modèle client/serveur) et se prête à une exécution sur de nombreuses machines, de façon distribuée. Une configuration type comprend un processus unique (le serveur) qui fourni un point d'accès pour les clients (ou d'autres serveurs), et qui traite l'acheminement / le multiplexage requis de messages, ainsi que d'autres fonctions.

1.1 Serveurs

                         [ Serveur 15 ]  [ Serveur 13 ] [ Serveur 14]
                                 /                \         /
                                /                  \       /
        [ Serveur 11 ] ------ [ Serveur 1 ]       [ Serveur 12]
                              /        \          /
                             /          \        /
                  [ Serveur 2 ]          [ Serveur 3 ]
                    /       \                      \
                   /         \                      \
           [ Serveur 4 ]    [ Serveur 5 ]         [ Serveur 6 ]
            /    |    \                           /
           /     |     \                         /
          /      |      \____                   /
         /       |           \                 /
[ Serveur 7 ] [ Serveur 8 ] [ Serveur 9 ]   [ Serveur 10 ]

                                  :
                               [ etc. ]
                                  :
[ Fig. 1. Format d'un réseau de serveur IRC ]

1.2 Clients

1.2.1 Opérateurs

Un pouvoir plus controversé des opérateurs est la possibilité de retirer par la force un utilisateur connecté au réseau, c'est à dire que les opérateurs peuvent clore une connection entre un client et un serveur. La justification à cela est délicate puisque son abus est à la fois destructif et ennuyant. Pour plus de détails concernant ce type d'actions, voir la section 4.6.1 (KILL).

1.3 Les canaux

Les noms de canaux sont des chaînes de caractères (commençant par un caractère '&' ou '#') d'une longueur maximale de 200 caractères. En dehors du fait que le premier caractère doive être un '&' ou un '#', la seule restriction sur le nom d'un canal est qu'il ne peut pas contenir d'espace (' '), de contrôle G (^G ou ASCII 7), ou de virgule (',' qui est utilisée comme séparateur de liste dans le protocole).

Il y a deux types de canaux autorisés par ce protocole. L'un est un canal distribué, qui est connu de tous les serveurs connectés au réseau. Ces canaux commencent par un '#'. L'autre type de canal, reconnaissable à leur nom qui commence par un '&', est marqué comme n'étant accessible qu'aux clients du serveur où le canal existe. En plus de ces deux types, il existe différents modes de canaux, permettant de modifier leur comportement individuel. Voir la section 4.2.3 (commande MODE) pour avoir plus de détails à ce sujet.

Pour créer un nouveau canal, ou pour faire partie d'un canal existant, un utilisateur doit accéder au canal. Si le canal n'existe pas avant l'accès, le canal est créé et l'utilisateur créateur devient opérateur de canal. Si le canal existait déjà au moment de l'accès, l'autorisation ou non d'accès dépend du mode du canal. Par exemple, si le canal est en "invités uniquement" (+i), vous ne pourrez joindre le canal que si vous êtes invités. Le protocole spécifie qu'un utilisateur peux être membre de plusieurs canaux à la fois, mais une limite de dix (10) canaux est recommandée comme étant amplement suffisante aussi bien pour les utilisateurs novices que pour les experts. Voir la section 8.13 pour plus d'informations à ce sujet.

Si le réseau IRC devient disjoint en raison d'une division entre deux serveurs, le canal, de chaque côté, est composé de ceux des clients qui sont connectés aux serveurs du côté respectif de la division, et disparaissent d'un des côtés de la division. Lorsque la division est soignée, les serveurs se reconnectant se communiquent entre eux qui, d'après eux, est dans chaque canal, et le mode de ce canal. Si le canal existe des deux cotés, les accès et les modes sont interprétés de façon inclusive pour que les deux côtés de la nouvelle connection soient d'accord sur quels clients sont dans quels canaux et quels modes ont les canaux.

1.3.1 Les opérateurs de canaux

Les commandes réservées aux opérateurs de canaux sont :
KICK - Ejecte un client d'un canal
MODE - Change le mode d'un canal
INVITE - Invite un client dans un canal à accès sur invitation (mode +i)
TOPIC - Change le titre du canal, dans un canal en mode +t

Un opérateur de canal est identifié par un symbole '@' devant son pseudonyme à chaque fois qu'il est utilisé en association avec le canal (c'est à dire lors des réponses aux commandes NAMES, WHO et WHOIS)

2. La spécification IRC

2.1 Aperçu

2.2 Les jeux de caractères

Indépendamment du fait qu'il s'agisse d'un protocole 8 bits, les délimiteurs et les mots-clés sont tels que le protocole est utilisable d'un terminal USASCII et d'une connection telnet.

Etant donnée l'origine scandinave de l'IRC, les caractères {}| sont considérés comme étant respectivement les équivalent en minuscules des caractères []\. Ceci est particulièrement important pour déterminer l'équivalence de deux pseudonymes.

2.3 Messages

Chaque message IRC peut contenir jusqu'à trois parties : le préfixe (optionnel), la commande, et les paramètre de la commande (il peut y en avoir jusqu'à 15). Le préfixe, la commande, et tous les paramètres sont séparés par un (ou plusieurs) caractère(s) ASCII espace (0x20).

La présence d'un préfixe est indiquée par un simple caractère ASCII deux-points (':', 0x3b), qui doit être le premier caractère du message. Il ne doit pas y avoir de trou (d'espace blanc) entre les deux-points et le préfixe. Le préfixe est utilisé pour indiquer la véritable origine du message. S'il n'y a pas de préfixe, le message est considéré comme ayant pour origine la connection de laquelle il est issu. Les clients ne doivent pas utiliser de préfixe lorsqu'ils envoient un message d'eux-mêmes. S'il utilise un préfixe, le seul valable est le pseudonyme associé au client. Si la source identifiée par le préfixe n'est pas trouvée dans la base de donnée interne du serveur, ou si la source est enregistrée avec une liaison différente de celle avec laquelle le message est arrivé, le serveur doit ignorer le message en silence.

La commande doit soit être soit une commande IRC valide, soit un nombre de trois (3) chiffres représentés en texte ASCII.

Les messages IRC sont toujours des lignes de caractères terminés par une paire CR-LF (retour chariot - saut de ligne), et ces messages ne doivent pas dépasser 512 caractères de long, en comptant tous les caractères y compris le CR-LF final. C'est-à-dire, qu'il y a un maximum de 510 caractères pour la commande et ses paramètres. Il n'y a pas de système permettant une ligne de continuation de message. Voir la section 7 pour les implémentations actuelles.

2.3.1 Le format de message en 'pseudo' BNF

Le message extrait est décomposé en un <préfixe>, <commande> et liste de paramètres correspondant soit au composant <milieu> ou <fin>.

La représentation BNF de ceci est :
<message> ::= [':' <préfixe> <espace> ] <command> <params> <crlf>
<préfixe> ::= <nom de serveur> | <pseudo> [ '!' <utilisateur> ] [ '@' <hôte> ]
<command> ::= <lettre> { <lettre> } | <nombre> <nombre> <nombre>
<espace> ::= ' ' { ' ' }
<params> ::= <espace> [ ':' <fin> | <milieu> <params> ]

<milieu> ::= <Toute séquence non vide d'octets à l'exclusion de ESPACE, NUL, CR, LF, le premier d'entre eux étant différent de ':'>
<fin> ::= <Toute suite, éventuellement vide, d'octets, à l'exception de NUL, CR et LF >
<crlf> ::= CR LF

NOTES:
1) <espace> est constitué uniquement de caractère(s) ESPACE (0x20). Notez particulièrement que la TABULATION et tout autre caractère de contrôle sont considérés comme ESPACE-NON-BLANC.

2) Après avoir extrait la liste de paramètre, tous les paramètres sont égaux, et correspondent soit à <milieu> soit à <fin>. <Fin> est une simple astuce syntaxique pour autoriser ESPACE dans le paramètre.

3) Le fait que CR et LF ne puissant pas apparaître dans la chaîne paramètre est une simple assertion. Cela pourrait changer dans le futur.

4) Le caractère NUL n'est pas spécial dans la construction du message, et pourrait a priori être à l'intérieur d'un message, mais cela complexifierait la gestion ordinaire des chaînes en C. C'est pourquoi NUL n'est pas autorisé dans les messages.

5) Le dernier paramètre peut être une chaîne vide.

6) L'utilisation d'un préfixe étendu ([ '!' <utilisateur> ] [ '@' <hôte> ]) ne doit pas être utilisé dans la communication entre serveurs, et est destiné uniquement à la communication serveur vers client, dans le but de fournir au client des informations utiles à propos de l'origine du message sans nécessiter de requêtes supplémentaires.

La plupart des messages du protocole spécifient une sémantique additionnelle, et la syntaxe pour les chaînes de paramètres extraites est dictée par leur position dans la liste. Par exemple, de nombreuses commandes de serveurs vont considérer que le premier paramètre après la commande est la liste de destinataires, ce qui peut être décrit avec :
<destinataire> ::= <à> [ "," < destinataire > ]
<à> ::= <canal> | < utilisateur > '@' <nom de serveur> | <pseudo> | <masque>
<canal> ::= ('#' | '&') <chaîne canal>
<nom de serveur> ::= <hôte>
<hôte> ::= voir RFC 952 [DNS:4] pour les détails sur les noms d'hôte autorisés
<pseudo> ::= <lettre> { <lettre> | <nombre> | <spécial> }
<masque> ::= ('#' | '$') <chaîne canal>
<chaîne canal> ::= <n'importe quel code 8bits excepté ESPACE, BELL, NUL, CR, LF et virgule (,)>

Les autres paramètres sont :
<utilisateur> ::= <non blanc> { < non blanc > }
<lettre> ::= 'a' ... 'z' | 'A' ... 'Z'
<nombre> ::= '0' ... '9'
<spécial> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'

< non blanc > ::= < n'importe quel code 8bits excepté ESPACE (0x20), NUL(0x0), CR(0xd), et LF(0xa) >

2.4 Réponses numériques

3. Concepts IRC

                          1--\
                              A        D---4
                          2--/ \      /
                                B----C
                               /      \
                              3        E
   Serveurs: A, B, C, D, E         Clients: 1, 2,3, 4

                    [ Fig. 2. Exemple d'un petit réseau IRC ]

3.1 Communication un à un

Les exemples suivants se réfèrent tous à la figure 2 ci-dessus.

Exemple 1 :

Un message entre les clients 1et 2 n'est vu que par le serveur A, qui l'envoi directement au client 2.

Exemple 2 :

Un message entre les clients 1 et 3 est vu par les serveurs A & B, et par le client 3. Aucun autre client n'est autorisé à voir le message.

Exemple 3 :

Un message entre les clients 2 et 4 n'est vu que par les serveurs A, C, C & D et par le client 4.

3.2 Un à plusieurs

3.2.1 A une liste

3.2.2 A un groupe (canal)

Les exemples suivants se réfèrent tous à la figure 2.

Exemple 4 :

Pour tout canal qui contient un seul client, les messages du canal vont au serveur et nul par ailleurs.

Exemple 5 :

Il y a deux clients dans un canal. Tous les messages traversent le chemin comme s'ils étaient des messages privés entre les deux clients en dehors du canal.

Exemple 6 :

Les clients 1, 2 et 3 sont dans un canal. Tous les messages adressés à un canal sont envoyés à tous les clients, et à ceux des serveurs qui serraient traversé par le message s'il était un message privé entre deux clients. Si le client 1 envoie un message, il est envoyé au client 2, et par le serveur B, au client 3.<

3.2.3 A un masque d'hôte/de serveur

3.3 Un à tous

Pour certains messages, il est nécessaire de les diffuser à tous les serveurs, de façon à ce que les informations de statut de chaque serveur soient raisonnablement identiques entre tous les serveurs.

3.3.1 Client à client

3.3.2 Client à serveur

3.3.3 Serveur à serveur

4. Détails des messages

Si la réponse est ERR_NOSUCHSERVER est reçue, cela signifie que le paramètre <serveur> n'a pas été trouvé. Le serveur ne doit alors plus envoyer d'autres réponses pour cette commande.

Le serveur auquel un client est connecté doit traiter le message complet, et retourner les messages d'erreur appropriés. Si le serveur rencontre une erreur fatale en décomposant un message, une erreur doit être envoyé au client et la décomposition interrompue. Peut être considéré comme une erreur fatale une commande incorrecte, une destination inconnue du serveur (noms de serveur, pseudo, et noms de canaux entrent dans cette catégorie), un nombre de paramètres insuffisant, ou un niveau de privilège insuffisant.

Si un jeu de paramètres complet est présent, la validité de chacun d'entre eux doit être vérifiée, et les réponses appropriées envoyées au client. Dans le cas de messages dont la liste de paramètres utilise une virgule comme séparateur, une réponse doit être envoyée à chaque élément.

Dans les exemples suivants, certains messages apparaissent au format complet :
:Nom COMMANDE paramètre liste

Ces exemples représentent un message de "Nom" dans le transfert entre serveurs, où il est essentiel d'inclure le nom de l'expéditeur originel du message, de façon à ce que les serveurs distants puissent renvoyer un message le long d'un chemin valide.

4.1 Etablissement de connection

Une commande "PASS" n'est pas nécessaire pour établir une connection, mais elle doit précéder la combinaison suivante des messages NICK/USER. Il est fortement recommandé que toutes les connections de serveurs utilisent un mot de passe afin de donner un niveau de sécurité satisfaisant aux connections. L'ordre des commandes recommandé pour l'enregistrement d'un client est le suivant :
1. Message PASS
2. Message NICK
3. Message USER

4.1.1 Message PASS

La commande PASS est utilisée pour définir le 'mot de passe de connection'. Le mot de passe peut et doit être défini avant toute tentative de connection. A l'heure actuelle, cela signifie que les clients doivent envoyer une commande PASS avant d'envoyer la combinaison NICK/USER, et que les serveurs doivent envoyer une commande PASS avant toute commande SERVER. Le mot de passe fourni doit correspondre à celui contenu dans les lignes C/N (pour les serveurs) ou dans les lignes I (pour les clients). Il est possible d'envoyer plusieurs commandes PASS avant de d'enregistrer la connection, mais seule la dernière est utilisée pour la vérification, et elle ne peut plus changer une fois la connection établie.

Réponses numériques :

ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

4.1.2 Message NICK

Le message NICK est utilisé pour donner un pseudonyme à un utilisateur, ou pour changer le pseudonyme précédent. Le paramètre <compteur de distance> n'est utilisé que par les serveurs, et sert à indiquer quelle est la distance entre un utilisateur et son serveur local. Une connection locale a un compter de distance de zéro. Si un client fourni un compteur de distance, il doit être ignoré.

Si un message NICK arrive à un serveur qui connaît déjà un autre client de pseudo identique, une collision de pseudonymes a lieu. Le résultat d'une collision de pseudonymes est la suppression de toutes les instances du pseudonyme de la base du serveur, et l'envoi d'un message KILL afin de retirer le pseudonyme des bases de données de tous les autres serveurs. Si le message NICK à l'origine de la collision de pseudonymes est un changement de pseudonyme, alors le pseudo originel (l'ancien) doit aussi être retiré.

Si le serveur reçoit un NICK identique d'un client auquel il est connecté directement, il peut envoyer un ERR_NICKCOLLISION au client local, ignorer la commande NICK, et ne pas générer de KILLs.

Réponses numériques :

           ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
           ERR_NICKNAMEINUSE               ERR_NICKCOLLISION

NICK Wiz ; Ajout d'un nouveau pseudo "Wiz".
:WiZ NICK Kilroy ; WiZ change son pseudo en Kilroy.

4.1.3 Message USER

Le message USER est utilisé au début d'une connection pour spécifier le nom d'utilisateur, le nom d'hôte, le nom de serveur, et le véritable nom d'un nouvel utilisateur. Il est aussi utilisé lors de la communication entre les serveurs pour indiquer l'arrivé d'un nouvel utilisateur sur IRC, puisque c'est seulement après avoir envoyé et le USER et le NICK qu'un utilisateur devient enregistré.

Entre serveurs, USER doit être préfixé du pseudonyme du client. Notez que le nom d'hôte et le nom de serveur sont généralement ignorés par le serveur IRC quand la commande USER vient directement d'un client (pour des raisons de sécurité), mais sont utilisés dans la communication de serveur à serveur. Cela signifie que NICK doit toujours être envoyé à un serveur distant quand un nouvel utilisateur est ajouté au reste du réseau, avant que le USER correspondant soit envoyé.

Notez aussi que le paramètre 'vrai nom' doit être le dernier paramètre, car il peut contenir des espaces, et il doit être préfixé par deux points (':') de façon à être reconnu comme tel.

Puisqu'il est facile pour un client de mentir sur son nom si on se base uniquement sur le message USER, il est recommandé d'utiliser un "serveur d'identité". Si l'hôte dont l'utilisateur se connecte a un serveur de ce type activé, le nom d'utilisateur est défini par la réponse de ce "serveur d'identité".

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

USER guest tolmoon tolsun :Ronnie Reagan ; Utilisateur s'enregistrant avec un nom d'utilisateur de "guest" un vrai nom de "Ronnie Reagan". :testnick USER guest tolmoon tolsun :Ronnie Reagan ; message entre les serveurs contenant le pseudonyme à qui appartient la commande USER.

4.1.4 Message SERVER

Le message SERVER est utilisé pour dire à un serveur que l'autre bout de la connection est un autre serveur. Ce message est aussi utilisé pour transmettre les données du serveur à tout le réseau. Quand un nouveau serveur se connecte au réseau, les informations le concernant sont diffusées à tout le réseau. <Compteur de distance> est utilisé pour donner à chaque serveur des informations sur leurs distances aux différents serveurs. Avec la liste complète des serveurs, il serrait possible de construire une carte complète de l'arbre des serveurs, mais les masques d'hôtes l'empêchent.

Le message SERVER doit être accepté uniquement (a) soit d'une connection qui n'est pas encore enregistrée et qui essaie de s'enregistrer en tant que serveur, ou (b) d'une connection existante d'un autre serveur, pour introduire un nouveau serveur au delà de ce serveur.

La plupart des erreurs qui ont lieu à la réception d'une commande SERVER résulte en la coupure de la connection avec l'hôte destinataire (serveur destinataire). Les réponses d'erreur sont généralement envoyées en utilisant la commande "ERROR" plutôt qu'une réponse numérique, car la commande ERROR a plusieurs propriétés qui la rendent utile dans ce cas.

Si un message SERVER est traité et tente d'introduire un serveur déjà connu du serveur receveur, la connection avec ce serveur doit être coupé (en suivant les procédures correctes), car une route dupliquée s'est formée avec un serveur, et la nature acyclique de l'arbre IRC rompue.

Réponses numériques :

           ERR_ALREADYREGISTRED

SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
; Le nouveau serveur test.oulu.fi se présente et tente de s'enregistrer. Le nom d'hôte est test.oulu.fi.

:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
; Le serveur tolsun.oulu.fi est notre lien vers csd.bu.edu qui est à 5 noeuds de nous.

4.1.5 Message OPER

Le message OPER est utilisé par un utilisateur normal pour obtenir le privilège d'opérateur. La combinaison de <utilisateur> et <mot de passe> est nécessaire pour obtenir le privilège Opérateur.

Si le client envoyant la commande OPER fourni un mot de passe correct pour l'utilisateur donné, le serveur informe le reste du réseau du nouvel opérateur en envoyant un "MODE +o" pour le pseudonyme.

Le message OPER n'a lieu qu'entre un client et un serveur.

Réponses numériques :

           ERR_NEEDMOREPARAMS              RPL_YOUREOPER
           ERR_NOOPERHOST                  ERR_PASSWDMISMATCH

OPER foo bar
; Tentative d'enregistrement en tant qu'opérateur, de l'utilisateur "foo" utilisant "bar" comme mot de passe.

4.1.6 Message QUIT

Une session de client se termine par un message QUIT. Le serveur doit rompre la connection avec le client qui envoie un message QUIT. Si un <Message de départ> est fourni, il sera transmi au lieu du message par défaut, le pseudonyme.

Lorsqu'une division réseau a lieu (déconnexion de deux serveurs), le message de départ est composé du nom des deux serveurs en cause, séparés par un espace. Le premier nom est celui du serveur toujours connecté, et le second, celui qui est désormais inaccessible.

Si pour une autre raison, une connection d'un client est fermée sans que le client ait envoyé de message QUIT (par exemple, le programme client se termine, et une fin de fichier est envoyée sure la socket), le serveur doit remplir le message QUIT avec un message reflétant la nature de l'événement à la cause de cette déconnexion.

Réponses numériques:

           Aucune.

QUIT :Parti déjeuner ; Format de message préféré.

4.1.7 Message SQUIT

Le message SQUIT est nécessaire pour signaler le départ ou la mort de serveurs. Si un serveur souhaite rompre une connection à un autre serveur, il doit envoyer un message SQUIT à ce serveur, en utilisant le nom de ce serveur comme paramètre <serveur>, ce qui clos la connection avec le serveur quittant le réseau.

Cette commande est aussi accessible aux opérateurs pour garder un réseau de serveurs IRC connectés proprement. Les opérateurs peuvent également émettre un message SQUIT pour une connection distante d'un serveur. Dans ce cas, le message SQUIT doit être traité par tous les serveurs entre l'opérateur et le serveur distant, tout en mettant à jour la vue du réseau de chaque serveur comme décrit plus loin.

Le <commentaire> doit être présent pour tout opérateur qui exécute un SQUIT sur un serveur distant (qui n'est pas connecté au serveur sur lequel ils sont actuellement). Le <commentaire> est également rempli par les serveurs qui peuvent y placer un message d'erreur ou autre.

Les deux serveurs, de chaque côte de la connection qui va être coupée doivent envoyer un message SQUIT (à tous les serveurs auxquels ils sont connectés) pour tous les serveurs qui sont situés au-delà de ce lien.

De même, un message QUIT doit être envoyé aux autres serveur du reste du réseau de la part de tous les clients au-delà de ce lien. De plus, tous les membres d'un canal qui perdent un membre à cause d'une division réseau doivent recevoir un message QUIT.

Si une connection à un serveur est terminée prématurément, (par exemple si le serveur à l'extrémité de la liaison meurt), le serveur qui détecte cette déconnexion doit informer le reste du réseau que cette connection est fermée, et remplir le champ <commentaire> de façon appropriée.

Réponses numériques :

           ERR_NOPRIVILEGES                ERR_NOSUCHSERVER

SQUIT tolsun.oulu.fi :Bad Link ?
; la liaison au serveur tolson.oulu.fi s'est terminée en raison d'un mauvais lien.

:Trillian SQUIT cm22.eng.umd.edu :Server out of control
; message de Trillian pour déconnecter "cm22.eng.umd.edu" du réseau en raison d'un "serveur incontrôlable".

4.2 Opérations sur les canaux

4.2.1 Le message JOIN

La commande JOIN est utilisée par un client pour commencer à écouter un canal spécifique. L'accès à un canal est autorisé ou non uniquement par le serveur auquel le client est connecté ; tous les autres serveurs ajoutent automatiquement l'utilisateur au canal quand la demande vient d'un autre serveur. Les conditions qui affectent ceci sont les suivantes :
1. L'utilisateur doit être invité si le canal est en mode "sur invitation seulement"
2. Le pseudo/nom d'utilisateur/nom d'hôte ne doit pas correspondre à un bannissement actif.
3. La bonne clé (mot de passe) doit être fournie si elle est définie.

Ceci est discuté plus en détails dans la description de la commande MODE (voir la section 4.2.3 pour plus de détails).

Une fois qu'un utilisateur a accès à un canal, ils reçoivent des notifications sur toutes les commandes que leur serveur reçoit qui affectent le canal. Cela inclut MODE, KICK, PART, QUIT, et bien sûr PRIVMSG/NOTICE. La commande JOIN doit être diffusée à tous les serveurs du réseau pour qu'ils sachent où trouver qui est dans chaque canal. Cela permet une distribution optimale des messages PRIVMSG/NOTICE du canal.

Si un JOIN a lieu avec succès, on envoie à l'utilisateur le sujet du canal (en utilisant RPL_TOPIC) et la liste des utilisateurs du canal (en utilisant RPL_NAMREPLY), y compris lui-même.

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
           ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
           ERR_CHANNELISFULL               ERR_BADCHANMASK
           ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
           RPL_TOPIC

JOIN #foobar ; accède au canal #foobar.

JOIN &foo fubar ; accède au canal &foo en utilisant la clé "fubar".

JOIN #foo,&bar fubar ; accède au canal #foo en utilisant la clé "fubar", et &bar en n'utilisant pas de clé.

JOIN #foo,#bar fubar,foobar ; accède au canal #foo en utilisant la clé "fubar", et au canal #bar en utilisant la clé "foobar".

JOIN #foo,#bar ; accède au canaux #foo and #bar.

:WiZ JOIN #Twilight_zone ; Message JOIN de WiZ

4.2.2 Message PART

Le message PART provoque le retrait du client expéditeur de la liste des utilisateurs actifs pour tous les canaux listé dans la chaîne de paramètre.

Réponses numériques:

           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
           ERR_NOTONCHANNEL

PART #twilight_zone ; quitte le canal "#twilight_zone"

PART #oz-ops,&group5 ; quitte les canaux "&group5" et "#oz-ops".

4.2.3 Message MODE

La commande MODE est une commande à utilisation duale sur IRC. Elle permet aussi bien de changer les modes des utilisateurs que ceux des canaux. La raison à ce choix est qu'un jour les pseudonymes deviendront obsolètes et la propriété équivalente sera le canal.

Lors du traitement des messages MODE, il est recommandé de commencer par décomposer le message en entier, puis de réaliser les modifications résultantes.

4.2.3.1 Les modes des canaux

La commande MODE permet aux opérateurs de canaux de changer les caractéristiques de 'leur' canal. Les serveurs doivent aussi pouvoir changer les modes du canal, de façon à pouvoir créer des opérateurs.

Les modes disponibles pour les canaux sont les suivants :
o - donne/retire les privilèges d'opérateur de canal
p - drapeau de canal privé
s - drapeau de canal secret
i - drapeau de canal accessible uniquement sur invitation
t - drapeau de sujet de canal modifiable uniquement par les opérateurs
n - pas de messages dans un canal provenant de clients à l'extérieur du canal
m - canal modéré
l - définit le nombre maximal de personnes dans un canal
b - défini un masque de bannissement pour interdire l'accès à des utilisateurs
v - donne/retire la possibilité de parler dans un canal modéré
k - défini la clé du canal (mot de passe)

Lors de l'utilisation des options 'o' et 'b', le nombre de paramètres est restreint à trois par commande, et ce pour n'importe quelle combinaison de 'o' et de 'b'.

4.2.3.2 Modes des utilisateurs

Les modes utilisateurs sont typiquement des modifications qui affectent la façon dont le client est vu par les autres, ou quels types de messages sont reçus. Une commande MODE n'est acceptée que si l'expéditeur du message et le pseudonyme donné en paramètres sont les même.

Les modes disponibles sont :
i - marque un utilisateur comme invisible ;
s - marque un utilisateur comme recevant les notifications du serveur ;
w - l'utilisateur reçoit les WALLOPs ;
o - drapeau d'opérateur.

D'autres modes seront disponible plus tard.

Si un utilisateur tente de devenir opérateur en utilisant le drapeau "+o", la tentative doit être ignorée. Par contre, il n'y a pas de restriction à ce que quelqu'un se 'deoppe' (en utilisant "+o").

Réponses numériques :

           ERR_NEEDMOREPARAMS              RPL_CHANNELMODEIS
           ERR_CHANOPRIVSNEEDED            ERR_NOSUCHNICK
           ERR_NOTONCHANNEL                ERR_KEYSET
           RPL_BANLIST                     RPL_ENDOFBANLIST
           ERR_UNKNOWNMODE                 ERR_NOSUCHCHANNEL

           ERR_USERSDONTMATCH              RPL_UMODEIS
           ERR_UMODEUNKNOWNFLAG

Utilisation des modes de canal:
MODE #Finnish +im ; Rend le canal #Finnish modéré et 'uniquement sur invitation'.
MODE #Finnish +o Kilroy ; Donne le privilège de 'chanop' à Kilroy sur le canal #Finnish.
MODE #Finnish +v Wiz ; Autorise WiZ à parler sur #Finnish.
MODE #Fins -s ; Annule le drapeau 'secret' du canal #Fins.
MODE #42 +k oulu ; Défini la clé comme "oulu".
MODE #eu-opers +l 10 ; Défini le nombre maximal d'utilisateur dans le canal à 10.
MODE &oulu +b ; Liste les masques de bannissements du canal.
MODE &oulu +b *!*@* ; Interdit à quiconque de venir sur le canal.
MODE &oulu +b *!*@*.edu ; Interdit à tout utilisateur dont le nom d'hôte correspond à *.edu d'accéder au canal.

Utilisation des modes d'utilisateur :
:MODE WiZ -w ; supprime la réception des messages WALLOPS messages pour WiZ.
:Angel MODE Angel +i ; Message d'Angel pour le rend invisible.
MODE WiZ -o ; WiZ se 'deoppe' (retire son statut d'opérateur). Le contraire de ca ("MODE WiZ +o") ne doit pas être autorisé car cela court-circuiterait la commande OPER.

4.2.4 Le message TOPIC

Le message TOPIC est utilisé pour modifier ou voir le sujet d'un canal. Le sujet du canal <canal> est renvoyé s'il n'y a pas de <sujet> fourni en paramètre. Si le paramètre <sujet> est présent, le sujet du canal changera si le mode du canal le permet.

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
           RPL_NOTOPIC                     RPL_TOPIC
           ERR_CHANOPRIVSNEEDED

:Wiz TOPIC #test :New topic ;L'utilisateur Wiz défini le sujet.
TOPIC #test :another topic ;Change le sujet du canal #test en "another topic".
TOPIC #test ; Vérifie le sujet de #test.

4.2.5 Message NAMES

En utilisant la commande NAMES, un utilisateur peut obtenir la liste des pseudonymes visibles sur n'importe quel canal qu'il peut voir. Les noms de canaux qu'il peut voir sont ceux qui ne sont ni privés (+p), ni secrets (+s), ou ceux sur lesquels il est actuellement. Le paramètre <canal> spécifie quels sont les canaux dont l'information est voulue, s'ils sont valides. Il n'y a pas de message d'erreur pour les noms de canaux invalides.

Si le paramètre <canal> n'est pas donné, la liste de tous les canaux et de leurs occupants est renvoyée. A la fin de cette liste, sont listés les utilisateurs qui sont visibles, mais qui n'appartiennent à aucun canal. Ils sont listés comme appartenant au canal `channel' "*".

Réponses numériques:

           RPL_NAMREPLY                    RPL_ENDOFNAMES

NAMES #twilight_zone,#42 ; liste les utilisateurs visibles sur #twilight_zone et #42, si ces canaux vous sont visible.
NAMES ; liste tous les canaux, et tous les utilisateurs visibles.

4.2.6 Message LIST

Le message liste est utilisé pour lister les canaux et leur sujet. Si le paramètre <canal> est utilisé, seul le statut de ces canaux est affiché. Les canaux privés sont listés (sans leur sujet) comme canal "Prv" à moins que le client qui fasse la requête soit effectivement sur le canal. De même, les canaux secrets ne sont pas listé du tout, à moins que le client soit un membre du canal en question.

Réponses numériques :

           ERR_NOSUCHSERVER                RPL_LISTSTART
           RPL_LIST                        RPL_LISTEND

LIST ; Liste tous les canaux.
LIST #twilight_zone,#42 ; Liste les canaux #twilight_zone et #42

4.2.7 Message INVITE

Le message INVITE est utilisé pour inviter des utilisateurs dans un canal. Le paramètre <pseudonyme> est le pseudonyme de la personne à inviter dans le canal destination <canal>. Il n'est pas nécessaire que le canal dans lequel la personne est invitée existe, ni même soit valide. Pour inviter une personne dans un canal en mode sur invitation (MODE +i), le client envoyant l'invitation doit être opérateur sur le canal désigné.

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_NOSUCHNICK
           ERR_NOTONCHANNEL                ERR_USERONCHANNEL
           ERR_CHANOPRIVSNEEDED
           RPL_INVITING                    RPL_AWAY

:Angel INVITE Wiz #Dust ; L'utilisateur Angel invite WiZ sur le canal #Dust
INVITE Wiz #Twilight_Zone ; Commande pour inviter WiZ sur #Twilight_zone

4.2.8 Commande KICK

La commande KICK est utilisée pour retirer par la force un utilisateur d'un canal (PART forcé).

Seul un opérateur de canal peut kicker un autre utilisateur hors d'un canal. Tout serveur qui reçoit un message KICK vérifie si le message est valide (c'est-à-dire si l'expéditeur est bien un opérateur du canal) avant d'ôter la victime du canal.

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
           ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
           ERR_NOTONCHANNEL

KICK &Melbourne Matthew ; Kick Matthew de &Melbourne
KICK #Finnish John :Speaking English ; Kick John de #Finnish en spécifiant "Speaking English" comme raison (commentaire).
:WiZ KICK #Finnish John ; Message KICK de WiZ pour retirer John du canal #Finnish

NOTE:

Il est possible d'étendre les paramètres de la commande KICK ainsi :
<canal>{,<canal>} <utilisateur>{,<utilisateur>} [<commentaire>]

4.3 Requêtes et commandes des serveurs

Dans ces requêtes, lorsqu'il y a un paramètre "<serveur>", cela désigne généralement un pseudonyme, un serveur, ou un joker quelconque. Par contre, chaque paramètre ne doit générer qu'une seule requête et un jeu de réponses.

4.3.1 Message VERSION

Le message VERSION est utilisé pour déterminer la version du programme serveur. Un paramètre optionnel <serveur> est utilisé pour obtenir la version d'un programme serveur sur lequel un client n'est pas connecté directement.

Réponses numériques :

           ERR_NOSUCHSERVER                RPL_VERSION

:Wiz VERSION *.se ; message de Wiz pour vérifier la version d'un serveur correspondant à "*.se"
VERSION tolsun.oulu.fi ; vérifie la version du serveur "tolsun.oulu.fi".

4.3.2 Message STATS

Le message STATS est utilisé pour obtenir les statistiques d'un serveur. Si le paramètre <serveur> est omis, seule la fin de la réponse STATS est renvoyée. L'implémentation de cette requête dépend énormément du serveur qui répond. Néanmoins, le serveur doit être capable de fournir les informations décrites dans les requêtes ci-dessous (ou équivalent).

Une requête peut être lancée par une unique lettre, qui est vérifiée uniquement par le serveur destination (si le paramètre <serveur> est présent). Elle est transmise aux serveurs intermédiaires, ignorée et inaltérée. Les requêtes suivantes sont celles trouvées dans les implémentations courantes d'IRC, et fournissent une grande partie des informations de configuration du serveur. Bien qu'elles ne soient pas nécessairement gérées de la même façon par d'autres versions, tous les serveurs devraient être capable de fournir une réponse valide à la requête STATS, qui soit compatible avec les formats de réponse actuellement utilisées et le but de ces requêtes.

Les requêtes actuellement gérées sont :
c - renvoie la liste des serveurs qui peuvent se connecter, ou dont les connections sont acceptées ;
h - renvoie la liste des serveurs qui sont forcés de se comporter comme des feuilles(L) , ou comme des noeuds (H) sur l'arbre des connections ;
i - renvoie la liste des hôtes dont le serveur accepte les clients ;
k - retourne la liste des combinaisons de noms d'utilisateur / nom d'hôtes qui sont bannis de ce serveur.
l - renvoie la liste des connections d'un serveur, et montre, pour chacune d'entre elle, le trafic en octets et en messages, et ce, dans chaque direction ;
m - renvoie la liste des commandes gérées par le serveur, et le nombre d'utilisations de chacune d'entre elle, s'il n'est pas nul ;
o - renvoie la liste des hôtes depuis lesquels un client normal peut devenir opérateur ;
y - montre les lignes Y (Classe) du fichier de configuration du serveur ;
u - renvoie une chaîne décrivant depuis combien de temps le serveur fonctionne.

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_STATSCLINE                  RPL_STATSNLINE
           RPL_STATSILINE                  RPL_STATSKLINE
           RPL_STATSQLINE                  RPL_STATSLLINE
           RPL_STATSLINKINFO               RPL_STATSUPTIME
           RPL_STATSCOMMANDS               RPL_STATSOLINE
           RPL_STATSHLINE                  RPL_ENDOFSTATS

STATS m ; vérifie l'utilisation des commandes pour le serveur sur lequel vous êtes connecté.
:Wiz STATS c eff.org ; requête de WiZ pour information sur les ligne C/N du serveur eff.org

4.3.3 Message LINKS

Avec LINKS, un utilisateur peut obtenir la liste des serveurs connue d'un serveur. La liste des serveurs doit correspondre au masque, ou s'il n'y a pas de masque, la liste complète des serveurs est renvoyée.

Si le <serveur distant> est fourni, en plus du <masque de serveur>, la commande LINKS est transmise au premier serveur trouvé dont le nom correspond (s'il y en a), et ce serveur doit alors répondre à la requête.

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_LINKS                       RPL_ENDOFLINKS

LINKS *.au ; liste tous les serveurs dont le noms correspond à *.au;
:WiZ LINKS *.bu.edu *.edu ; message LINKS de WiZ au premier serveur correspondant à *.edu demandant la liste des serveurs correspondant à *.bu.edu.

4.3.4 Message TIME

Le message TIME est utilisé pour obtenir l'heure locale d'un serveur donné. En absence de paramètre <serveur>, le serveur recevant le message doit répondre à la requête.

Réponses numériques :

           ERR_NOSUCHSERVER                RPL_TIME

TIME tolsun.oulu.fi ; demande l'heure du serveur "tolson.oulu.fi"
Angel TIME *.au ; L'utilisateur Angel demande l'heure à un serveur correspondant à "*.au"

4.3.5 Message CONNECT

Le message CONNECT est utilisé pour forcer un serveur à essayer d'établir immédiatement une nouvelle connection à un autre serveur. CONNECT est une commande privilégiée et n'est accessible qu'aux opérateurs IRC. Si un serveur distant est précisé, alors ce serveur tente de se connecter au <serveur distant>, sur le <port> donné.

Réponses numériques :

           ERR_NOSUCHSERVER                ERR_NOPRIVILEGES
           ERR_NEEDMOREPARAMS

CONNECT tolsun.oulu.fi ; Essai de connection au serveur tolsun.oulu.fi
:WiZ CONNECT eff.org 6667 csd.bu.edu ; essai de CONNECT de WiZ pour lier eff.org et csd.bu.edu sur le port 6667.

4.3.6 Message TRACE

La commande TRACE est utilisée pour trouver une route vers un serveur donné. Chaque serveur qui traite ce message doit répondre à l'expéditeur en indiquant qu'il est un lien sur le chemin d'acheminement, formant ainsi une chaîne de réponse similaire à celle obtenue par un "traceroute". Après avoir renvoyé sa réponse, il doit ensuite envoyer le message TRACE au serveur suivant, et ce jusqu'à ce que le serveur spécifié soit atteint. Si le paramètre <serveur> est omis, il est recommandé que la commande trace envoie un message à l'expéditeur lui disant à quels serveurs il est directement connecté.

Si la destination spécifiée par <serveur> est en fait un serveur, alors le serveur destinataire doit lister tous les serveurs et les utilisateurs qui y sont connectés. Si la destination spécifiée par <serveur> est en fait un pseudonyme, seule la réponse pour ce pseudonyme est donnée.

Réponses numériques :

           ERR_NOSUCHSERVER

           RPL_TRACELINK

           RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
           RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
           RPL_TRACEUSER                   RPL_TRACESERVER
           RPL_TRACESERVICE                RPL_TRACENEWTYPE
           RPL_TRACECLASS

TRACE *.oulu.fi ; TRACE un serveur correspondant à *.oulu.fi
:WiZ TRACE AngelDust ; TRACE de WiZ vers le pseudo AngelDust

4.3.7 Commande ADMIN

Le message ADMIN est utilisé pour trouver le nom de l'administrateur d'un serveur donné, ou du serveur courant si le paramètre <serveur> est omis. Tout serveur doit posséder la possibilité de propager les messages ADMIN aux autres serveurs.

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_ADMINME                     RPL_ADMINLOC1
           RPL_ADMINLOC2                   RPL_ADMINEMAIL

ADMIN tolsun.oulu.fi ; requête ADMIN de tolsun.oulu.fi
:WiZ ADMIN *.edu ; requête ADMIN de WiZ pour le premier serveur trouvé qui correspond à *.edu.

4.3.8 Commande INFO

La commande INFO doit retourner une information qui décrit le serveur : sa version, quand il a été compilé, le numéro de mise à jour, quand il a été démarré, et toute autre information considérée comme pertinente.

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_INFO                        RPL_ENDOFINFO

INFO csd.bu.edu ; requête INFO pour csd.bu.edu
:Avalon INFO *.fi ; requête INFO d' Avalon à destination du premier serveur trouvé qui correspond à *.fi.
INFO Angel ; requête INFO à destination du serveur sur lequel est connecté Angel.

4.4 Envoi de messages

4.4.1 Messages privés

PRIVMSG est utilisé pour envoyer un message privé entre des utilisateurs. <destinataire> est le pseudonyme du destinataire du message. <destinataire> peut aussi être une liste de nom ou de canaux, séparés pas des virgules.

Le paramètre <destinataire> peut aussi être un masque d'hôte (masque #) ou un masque de serveur (masque $). Le masque doit contenir au moins un (1) ".", et aucun joker après le dernier ".". Cette limitation a pour but d'empêcher les gens d'envoyer des messages à "#*" ou à "$*", ce qui provoquerait la diffusion à tous les utilisateurs ; l'expérience montre qu'on en abuse plus qu'on en use intelligemment, de façon responsable. Les jokers sont les caractères '*' et '?'. Ces extensions de PRIVMSG ne sont accessibles qu'aux opérateurs. Réponses Numériques:

           ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
           ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
           ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
           ERR_NOSUCHNICK
           RPL_AWAY

:Angel PRIVMSG Wiz :Salut, est ce que tu reçois ce message ? ; Message d'Angel à Wiz.
PRIVMSG Angel :oui, je le reçois ! ; Message à Angel.
PRIVMSG jto@tolsun.oulu.fi :Hello ! ; Message à un client du serveur tolsun.oulu.fi dont le nom est "jto".
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. ; Message à tous sur les serveurs dont les noms correspondent à *.fi.
PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions ; Message à tous les utilisateurs qui viennent d'un hôte dont le nom correspond à *.edu.

4.4.2 Notice

Le message NOTICE s'utilise de la même façon que PRIVMSG. La différence entre NOTICE et PRIVMSG est qu'aucune réponse automatique de doit être envoyée en réponse à un message NOTICE. Ceci est aussi valable pour les serveurs - ils ne doivent pas renvoyer de message d'erreur à la réception d'un message NOTICE. Le but de cette règle est d'éviter les boucles entre les clients qui enverraient automatiquement quelque chose en réponse à une requête. Cela est typiquement utilisé par des automates (des clients qui ont une intelligence artificielle ou un autre programme interactif contrôlant leurs actions) qui répondent systématiquement aux réponses d'autres automates.

Voir PRIVMSG pour les détails sur les réponses, et pour les exemples.

4.5 Requêtes basées sur les utilisateurs

4.5.1 Requête WHO

Le message WHO est utilisé par un client pour générer une requête qui renvoie une liste d'informations qui correspondent au paramètre <nom> donné par le client. Si le paramètre nom est absent, tous les utilisateurs visibles sont listés (ceux qui ne sont pas invisibles (mode utilisateur +i) et qu'ont pas un canal en commun avec le client émettant la requête. Le même résultat peut être obtenu en utilisant le <nom> "0" ou tout joker correspond à toutes les entrées possibles.

Le <nom> passé en paramètre est mis en correspondance avec les hôtes des utilisateurs, leurs véritables noms, et leurs pseudonymes si le canal <nom> n'est pas trouvé.

Si le paramètre "o" est passé, seuls les opérateurs sont listés, et ce, en fonction du masque fourni.

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_WHOREPLY                    RPL_ENDOFWHO

WHO *.fi ; Liste tous les utilisateurs qui correspondent à "*.fi".
WHO jto* o ; Liste tous les utilisateurs qui correspondent à "jto*", s'ils sont opérateurs.

4.5.2 Requête WHOIS

Ce message est utilisé pour obtenir des informations sur un utilisateur donné. Le serveur répondra à ce message avec des messages numériques indiquant les différents statuts de chacun des utilisateurs qui correspondent au <masque de pseudo> (si vous pouvez les voir). S'il n'y a pas de joker dans le <masque de pseudo>, toutes les informations auxquelles vous avez accès au sujet de ce pseudo seront présentées. On peut séparer la liste des pseudonymes avec une virgule (',').

La dernière version envoie une requête à un serveur spécifique. C'est utile si vous voulez savoir depuis combien de temps l'utilisateur concerné a été oisif, car seul le serveur local (celui auquel cet utilisateur est directement connecté) connaît cette information, alors que tout le reste est connu par tous les serveurs.

Réponses numériques :

           ERR_NOSUCHSERVER                ERR_NONICKNAMEGIVEN
           RPL_WHOISUSER                   RPL_WHOISCHANNELS
           RPL_WHOISCHANNELS               RPL_WHOISSERVER
           RPL_AWAY                        RPL_WHOISOPERATOR
           RPL_WHOISIDLE                   ERR_NOSUCHNICK
           RPL_ENDOFWHOIS

WHOIS wiz ; revoie les informations disponibles sur le pseudo WiZ
WHOIS eff.org trillian ; demande au serveur eff.org les informations concernant trillian

4.5.3 WHOWAS

WHOWAS permet de demander des informations concernant un utilisateur qui n'existe plus. Cela peut être dû à un changement de pseudonyme ou au fait que l'utilisateur ait quitté l'IRC. En réponse à cette requête, le serveur cherche un pseudo correspondant dans l'historique des pseudonymes (sans utiliser de jokers). L'historique est parcouru à l'envers, de façon à renvoyer l'entrée la plus récente en premier. S'il y a plusieurs entrées, jusqu'à <compte> entrées seront retournées (ou toutes si le paramètre <compte> n'est pas donné). Si le nombre passé n'est pas positif, une recherche complète a lieu.

Réponses numériques :

           ERR_NONICKNAMEGIVEN             ERR_WASNOSUCHNICK
           RPL_WHOWASUSER                  RPL_WHOISSERVER
           RPL_ENDOFWHOWAS

WHOWAS Wiz ; revoie toutes les informations dans l'historique des pseudos au sujet du pseudo "WiZ";
WHOWAS Mermaid 9 ; renvoie, au maximum, les neufs entrées les plus récentes dans l'historiques des pseudos pour "Mermaid";
WHOWAS Trillian 1 *.edu ; demande l'entrée la plus récente pour "Trillian" au premier serveur trouvé qui correspond à "*.edu".

4.6 Messages divers

4.6.1 Message KILL

Le message KILL est utilisé pour provoquer la fermeture de la connection client/serveur par le serveur qui gère cette connection. KILL est aussi utilisé par les serveurs qui rencontrent un doublon dans la liste des entrées de pseudonymes valides, afin de retirer les deux entrées. Elle est également accessible aux opérateurs.

Les clients qui ont des reconnections automatiques rendent cette commande inefficace, car la déconnexion est brève. Cela permet tout de même d'interrompre un flux de données et est utile pour arrêter un flux abusif (trop important). Tout utilisateur peut demander à recevoir les messages KILL générés pour d'autres clients afin de garder un oeil sur les fauteurs de trouble éventuels.

Dans une arène où les pseudonymes doivent être globalement uniques, les messages KILL sont envoyés à chaque fois qu'un doublon est détecté (c'est-à-dire une tentative d'enregistrer deux utilisateurs avec le même pseudonyme) dans l'espoir qu'ils disparaîtront tous les deux, et qu'un seul réapparaîtra.

Le commentaire doit refléter la véritable raison du KILL. Pour les messages issus de serveurs, cela est habituellement constitué des détails concernant les origines des deux pseudonymes en conflit. Les utilisateurs, eux, sont libres de fournir une raison adéquate, de façon à satisfaire ceux qui le voient. Afin de prévenir/d'éviter des KILL maquillés pour cacher l'identité de l'auteur d'être générés, le commentaire contient également un 'chemin de KILL' qui est mis à jour par tous les serveurs par lequel il passe, chacun ajoutant son nom au chemin.

Réponses numériques :

           ERR_NOPRIVILEGES                ERR_NEEDMOREPARAMS
           ERR_NOSUCHNICK                  ERR_CANTKILLSERVER

KILL David (csd.bu.edu <- tolsun.oulu.fi) ; Collision de pseudonyme entre csd.bu.edu et tolson.oulu.fi

NOTE:
Il est recommandé que seuls les opérateurs soient autorisés à déconnecter d'autres utilisateurs avec un message KILL. Dans un monde parfait, même les opérateurs ne devraient avoir besoin de cette commande, et les serveurs pourraient être laissés seul à résoudre ces problèmes.

4.6.2 Message PING

Le message PING est utilisé pour tester la présence d'un client actif à l'autre bout de la connection. Un message PING est envoyé régulièrement si aucune activité n'est détectée sur une connection. Si la connection ne répond pas à la commande PING dans un certain délai, la connection est fermée.

Tout client qui reçoit un message PING doit répondre au <serveur1> (serveur qui a envoyé le message PING) aussi rapidement que possible, avec un message PONG approprié pour indiquer qu'il est toujours là et actif. Les serveurs ne doivent pas répondre aux commandes PING, mais se fier au PING dans l'autre sens pour indiquer que la connection est toujours active. Si le paramètre <serveur2> est spécifié, le message PING y est transmis.

Réponses numériques :

           ERR_NOORIGIN                    ERR_NOSUCHSERVER

PING tolsun.oulu.fi ; serveur envoyant un message PING à un autre serveur pour indiquer qu'il est toujours actif.
PING WiZ ; message PING envoyé au pseudo WiZ

4.6.3 Message PONG

Le message PONG est la réponse à un message PING. Si le paramètre <démon2> est donné, le message doit être transmis au démon donné. Le paramètre <démon> est le nom du démon responsable du message PING généré.

Réponses numériques :

           ERR_NOORIGIN                    ERR_NOSUCHSERVER

PONG csd.bu.edu tolsun.oulu.fi ; message PONG de csd.bu.edu à tolsun.oulu.fi

4.6.4 Message ERROR

La commande ERROR est utilisée par les serveurs pour rapporter une erreur sérieuse ou fatale à ses opérateurs. Elle peut aussi être envoyée d'un serveur à un autre, mais ne doit pas être accepté de simples clients inconnus.

Un message ERROR ne doit être utilisé que pour annoncer les erreurs qui ont lieu sur un lien serveur/serveur. Un message ERROR est envoyé au serveur associé (qui le transmet à tous ses opérateurs connectés) et à tous les opérateurs connectés. Il ne doit pas être transmis aux autres serveurs s'il est reçu d'un serveur.

Quand un serveur transmet un message ERROR à ses opérateurs, le message doit être encapsulé dans un message NOTICE, en indiquant que le client n'est pas responsable de l'erreur.

Réponses numériques :

           Aucune.

ERROR :Server *.fi already exists ; message ERROR à l'autre serveur qui a provoqué cette erreur.
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists ; Même message ERROR qu'au dessus, mais envoyé à l'utilisateur Wiz sur l'autre serveur.

5. Messages optionnels

5.1 AWAY

Avec le message AWAY, les clients peuvent définir une chaîne de réponse automatique pour toute commande PRIVMSG qui leur est destinée (et non pas à un canal sur lequel ils sont). La réponse est envoyée directement par le serveur au client envoyant une commande PRIVMSG. Le seul serveur à répondre est celui sur lequel le client émetteur est situé.

Le message AWAY est utilisé soit avec un paramètre (pour définir un message AWAY) ou sans (pour retirer le message AWAY).

Réponses numériques :

           RPL_UNAWAY                      RPL_NOWAWAY

AWAY :Parti déjeuner. De retour à 2 heures. ; défini le message d'absence en " Parti déjeuner. De retour à 2 heures.".
:WiZ AWAY ; supprime l'absence de WiZ.

5.2 Message REHASH

Le massage REHASH est utilisé par les opérateurs pour forcer un serveur à relire et traiter son fichier de configuration.

Réponses numériques :

        RPL_REHASHING                   ERR_NOPRIVILEGES

REHASH ; message d'un client ayant un statut d'opérateur au serveur, lui demandant de relire son fichier de configuration.

5.3 Message RESTART

Le message RESTART n'est utilisable que par un opérateur. Il sert à redémarrer le serveur. La gestion de ce message est optionnelle, car il est risqué de permettre à des personnes se connectant comme opérateur d'exécuter cette commande, qui cause une interruption de service (au moins).

La commande RESTART doit toujours être traitée par le serveur qui la reçoit, et non passé à un autre serveur.

Réponses numériques :

           ERR_NOPRIVILEGES

RESTART ; pas de paramètres

5.4 Message SUMMON

La commande SUMMON peut être utilisée pour envoyer à des utilisateurs qui sont sur l'hôte sur lequel s'exécute le serveur IRC un message leur demandant de joindre l'IRC. Ce message ne peut être envoyé que si le serveur (a) a la commande SUMMON activée, et (b) si le processus serveur peut écrire sur le tty (ou similaire) de l'utilisateur.

Si le paramètre <serveur> n'est pas donné, cela essaie d'appeler l'<utilisateur> du serveur sur lequel le client est connecté.

Si le SUMMON est désactivé sur un serveur, il doit renvoyer la réponse numérique ERR_SUMMONDISABLED et transmettre le message SUMMON.

Réponses numériques :

           ERR_NORECIPIENT                 ERR_FILEERROR
           ERR_NOLOGIN                     ERR_NOSUCHSERVER
           RPL_SUMMONING

SUMMON jto ; appelle l'utilisateur jto sur l'hôte du serveur
SUMMON jto tolsun.oulu.fi ; appelle l'utilisateur jto sur l'hôte sur lequel le serveur "tolsun.oulu.fi" est lancé.

5.5 Commande USERS

La commande USERS fonctionne de façon similaire à WHO(1), RUSERS(1) et FINGER(1). Certains peuvent désactiver cette commande sur leur serveur pour des raisons de sécurité. En cas de désactivation, cela doit être indiqué par le retour de réponse numérique appropriée.

Réponses numériques :

           ERR_NOSUCHSERVER                ERR_FILEERROR
           RPL_USERSSTART                  RPL_USERS
           RPL_NOUSERS                     RPL_ENDOFUSERS
           ERR_USERSDISABLED

           ERR_USERSDISABLED

USERS eff.org ; requiert la liste des utilisateurs connectés au serveur eff.org
:John USERS tolsun.oulu.fi ; requête de John pour obtenir la liste des utilisateur du serveur tolsun.oulu.fi

5.6 Message WALLOPS

Envoie un message à tous les opérateurs actuellement connectés. Après avoir essayé de laisser accès à cette commande à tous les utilisateurs, il a été constaté qu'on en abusait comme un moyen d'envoyer des messages à plein de personnes (comme WALL). A cause de cela, il est recommandé que l'implémentations courante de WALLOPS ne reconnaisse que les serveurs comme émetteurs de WALLOPS.

Réponses numériques :

           ERR_NEEDMOREPARAMS

:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; message WALLOPS de csd.bu.edu annonçant un message CONNECT reçu et traité, issu de Joshua.

5.7 Message USERHOST

La commande USERHOST prends jusqu'à 5 pseudonymes, séparés par des virgules, et revoie une liste d'informations pour chacun des pseudonymes qu'il a trouvé. La liste des réponses contient chaque réponse séparée par des espaces.

Réponses numériques :

           RPL_USERHOST                    ERR_NEEDMOREPARAMS

USERHOST Wiz Michael Marty p ;requête USERHOST pour information sur les pseudos "Wiz", "Michael", "Marty" et "p"

5.8 Message ISON

La commande ISON a été implémentée pour fournir une manière rapide et efficace de savoir si un pseudonyme donné est connecté à l'IRC. ISON prend un (1) paramètre : une liste de pseudonymes séparés par des espaces. Chaque pseudonyme présent est ajouté à la chaîne de réponse du serveur. Ainsi, la chaîne de réponse peut être vide (aucun utilisateur est présent), une copie exacte de la chaîne de caractères passée en paramètres (ils sont tous présents), ou un tout sous-ensemble du groupe de pseudonymes passé en paramètre. La seule limite au nombre de pseudos qui peuvent être testés est la troncature des commandes à une longueur de 512 caractères.

ISON n'est traitée que par le serveur local au client effectuant la requête, et n'est donc pas passé pour traitement aux autres serveurs

Réponses numériques :

           RPL_ISON                ERR_NEEDMOREPARAMS

ISON phone trillian WiZ jarlek Avalon Angel Monstah ; Exemple de requête ISON pour 7 pseudonymes

6. Réponses

6.1 Réponses d'erreur

401 ERR_NOSUCHNICK

"<pseudonyme> :No such nick/channel"

402 ERR_NOSUCHSERVER

"<nom de serveur> :No such server"

403 ERR_NOSUCHCHANNEL

"<nom de canal> :No such channel"

404 ERR_CANNOTSENDTOCHAN

"<nom de canal> :Cannot send to channel"

405 ERR_TOOMANYCHANNELS

"<nom de canal> :You have joined too many channels"

406 ERR_WASNOSUCHNICK

"<nom de canal> :There was no such nickname"

407 ERR_TOOMANYTARGETS

"<destination> :Duplicate recipients. No message delivered"

409 ERR_NOORIGIN

":No origin specified"

411 ERR_NORECIPIENT

":No recipient given (<commande>)"

412 ERR_NOTEXTTOSEND

":No text to send"

413 ERR_NOTOPLEVEL

"<masque> :No toplevel domain specified"

414 ERR_WILDTOPLEVEL

"<masque> :Wildcard in toplevel domain"

Les erreurs 412-414 sont renvoyées par PRIVMSG pour indiquer que le message n'a pas été délivré. ERR_NOTOPLEVEL et ERR_WILDTOPLEVEL sont les erreurs renvoyées lors d'une utilisation invalide de "PRIVMSG $<serveur>" ou de "PRIVMSG #<hôte>".

421 ERR_UNKNOWNCOMMAND

"<commande> :Unknown command"

422 ERR_NOMOTD

":MOTD File is missing"

423 ERR_NOADMININFO

"<serveur> :No administrative info available"

424 ERR_FILEERROR

":File error doing <fichier op> on <fichier>"

431 ERR_NONICKNAMEGIVEN

":No nickname given"

432 ERR_ERRONEUSNICKNAME

"<pseudo> :Erroneus nickname"

433 ERR_NICKNAMEINUSE

"<nick> :Nickname is already in use"

436 ERR_NICKCOLLISION

"<nick> :Nickname collision KILL"

441 ERR_USERNOTINCHANNEL

"<pseudo> <canal> :They aren't on that channel"

442 ERR_NOTONCHANNEL

"<canal> :You're not on that channel"

443 ERR_USERONCHANNEL

"<utilisateur> <channel> :is already on channel"

444 ERR_NOLOGIN

"<utilisateur> :User not logged in"

445 ERR_SUMMONDISABLED

":SUMMON has been disabled"

446 ERR_USERSDISABLED

":USERS has been disabled"

451 ERR_NOTREGISTERED

":You have not registered"

461 ERR_NEEDMOREPARAMS

"<commande> :Not enough parameters"

462 ERR_ALREADYREGISTRED

":You may not reregister"

463 ERR_NOPERMFORHOST

":Your host isn't among the privileged"

464 ERR_PASSWDMISMATCH

":Password incorrect"

465 ERR_YOUREBANNEDCREEP

":You are banned from this server"

467 ERR_KEYSET

"<canal> :Channel key already set"

471 ERR_CHANNELISFULL

"<canal> :Cannot join channel (+l)"

472 ERR_UNKNOWNMODE

"<caratère> :is unknown mode char to me"

473 ERR_INVITEONLYCHAN

"<canal> :Cannot join channel (+i)"

474 ERR_BANNEDFROMCHAN

"<canal> :Cannot join channel (+b)"

475 ERR_BADCHANNELKEY

"<canal> :Cannot join channel (+k)"

481 ERR_NOPRIVILEGES

":Permission Denied- You're not an IRC operator"

482 ERR_CHANOPRIVSNEEDED

"<canal> :You're not channel operator"

483 ERR_CANTKILLSERVER

":You cant kill a server!"

491 ERR_NOOPERHOST

":No O-lines for your host"

501 ERR_UMODEUNKNOWNFLAG

":Unknown MODE flag"

502 ERR_USERSDONTMATCH

":Cant change mode for other users"

6.2 Réponses aux commandes.

300 RPL_NONE

302 RPL_USERHOST

":[<réponse>{<espace><réponse>}]"

303 RPL_ISON

":[<pseudo> {<espace><pseudo>}]"

301 RPL_AWAY

"<pseudo> :< message d'absence>"

305 RPL_UNAWAY

":You are no longer marked as being away"

306 RPL_NOWAWAY

":You have been marked as being away"

311 RPL_WHOISUSER

"<pseudo> <utilisateur> <hôte> * :<vrai nom>"

312 RPL_WHOISSERVER

"<pseudo> <serveur> :<info serveur >"

313 RPL_WHOISOPERATOR

"<pseudo> :is an IRC operator"

317 RPL_WHOISIDLE

"<pseudo> <integer> :seconds idle"

318 RPL_ENDOFWHOIS

"<pseudo> :End of /WHOIS list"

319 RPL_WHOISCHANNELS

"<pseudo> :{[@|+]<canal><espace>}"

314 RPL_WHOWASUSER

"<pseudo> <utilisateur> <hôte> * :<vrai nom>"

369 RPL_ENDOFWHOWAS

"<pseudo> :End of WHOWAS"

321 RPL_LISTSTART

"Channel :Users Name"

322 RPL_LIST

"<canal> <# visible> :<sujet>"

323 RPL_LISTEND

":End of /LIST"

324 RPL_CHANNELMODEIS

"<canal> <mode> <paramètres de mode >"

331 RPL_NOTOPIC

"<canal> :No topic is set"

332 RPL_TOPIC

"<canal> :<sujet>"

341 RPL_INVITING

"<canal> <pseudo>"

342 RPL_SUMMONING

"<utilisateur> :Summoning user to IRC"

351 RPL_VERSION

"<version>.<debuglevel> <serveur> :<commentaires>"

352 RPL_WHOREPLY

"<canal> <utilisateur> <hôte> <serveur> <pseudo> <H|G>[*][@|+] :<compteur de distance> <vrai nom>"

315 RPL_ENDOFWHO

"<nom> :End of /WHO list"

353 RPL_NAMREPLY

"<canal> :[[@|+]<pseudo> [[@|+]<pseudo> [...]]]"

366 RPL_ENDOFNAMES

"<canal> :End of /NAMES list"

364 RPL_LINKS

"<masque> <serveur> :<compteur de distance> <info serveur >"

365 RPL_ENDOFLINKS

"<mask> :End of /LINKS list"

367 RPL_BANLIST

"<canal> <identification de bannissement>"

368 RPL_ENDOFBANLIST

"<canal> :End of channel ban list"

371 RPL_INFO

":<chaîne>"

374 RPL_ENDOFINFO

":End of /INFO list"

375 RPL_MOTDSTART

":- <serveur> Message of the day - "

372 RPL_MOTD

":- <texte>"

376 RPL_ENDOFMOTD

":End of /MOTD command"

381 RPL_YOUREOPER

":You are now an IRC operator"

382 RPL_REHASHING

"<fichier de configuration> :Rehashing"

391 RPL_TIME

"<serveur> :<chaîne indiquant l'heure locale du serveur >"

392 RPL_USERSSTART

":UserID Terminal Hôte"

393 RPL_USERS

":%-8s %-9s %-8s"

394 RPL_ENDOFUSERS

":End of users"

395 RPL_NOUSERS

":Nobody logged in"

200 RPL_TRACELINK

"Link <version & niveau de débugage > <destination> < serveur suivant>"

201 RPL_TRACECONNECTING

"Try. <classe> <serveur>"

202 RPL_TRACEHANDSHAKE

"H.S. <classe> <serveur>"

203 RPL_TRACEUNKNOWN

"???? <classe> [<adresse IP du client au format utilisant des points >]"

204 RPL_TRACEOPERATOR

"Oper <classe> <pseudo>"

205 RPL_TRACEUSER

"User <classe> <pseudo>"

206 RPL_TRACESERVER

"Serv <classe> <int>S <int>C <serveur> <pseudo!utilisateur|*!*>@<hôte|serveur>"

208 RPL_TRACENEWTYPE

"<nouveau type> 0 <nom du client>"

261 RPL_TRACELOG

"File <fichier log> <niveau de débugage>"

211 RPL_STATSLINKINFO

"<nom du lien> <sendq> < messages envoyés> <octets envoyés > <message reçus> <octets reçus> <temps de connection>"

212 RPL_STATSCOMMANDS

"<commande> <compteur>"

213 RPL_STATSCLINE

"C <hôte> * <nom> <port> <classe>"

214 RPL_STATSNLINE

"N <hôte> * <nom> <port> <classe>"

215 RPL_STATSILINE

"I <hôte> * <hôte> <port> <classe>"

216 RPL_STATSKLINE

"K <hôte> * <nom d'utilisateur> <port> <classe>"

218 RPL_STATSYLINE

"Y <classe> <fréquence des PINGS > <fréquence de connection > <sendq max>"

219 RPL_ENDOFSTATS

"<lettre de stats > :End of /STATS report"

241 RPL_STATSLLINE

"L <masque d'hôte> * <nom de serveur> <profondeur maxi>"

242 RPL_STATSUPTIME

":Server Up %d days %d:%02d:%02d"

243 RPL_STATSOLINE

"O <masque d'hôte> * <nom>"

244 RPL_STATSHLINE

"H <masque d'hôte> * <nom de serveur>"

221 RPL_UMODEIS

"<chaîne de mode utilisateur>"

251 RPL_LUSERCLIENT

":There are <entier> users and <entier> invisible on <entier> servers"

252 RPL_LUSEROP

"<entier> :operator(s) online"

253 RPL_LUSERUNKNOWN

"<entier> :unknown connection(s)"

254 RPL_LUSERCHANNELS

"<entier> :channels formed"

255 RPL_LUSERME

":I have <entier> clients and <integer> servers"

256 RPL_ADMINME

"<serveur> :Administrative info"

257 RPL_ADMINLOC1

":<info admin >"

258 RPL_ADMINLOC2

":<info admin>"

259 RPL_ADMINEMAIL

":<info admin>"

6.3 Nombres réservés.

1. Plus utilisés ;
2. Réservés à une future utilisation ;
3. Utilisés à l'heure actuelle, mais faisant partie des caractéristiques non génériques des serveurs IRC courants.

        209     RPL_TRACECLASS          217     RPL_STATSQLINE
        231     RPL_SERVICEINFO         232     RPL_ENDOFSERVICES
        233     RPL_SERVICE             234     RPL_SERVLIST
        235     RPL_SERVLISTEND
        316     RPL_WHOISCHANOP         361     RPL_KILLDONE
        362     RPL_CLOSING             363     RPL_CLOSEEND
        373     RPL_INFOSTART           384     RPL_MYPORTIS
        466     ERR_YOUWILLBEBANNED     476     ERR_BADCHANMASK
        492     ERR_NOSERVICEHOST

7. Authentification des clients et serveurs

Une vérification additionnelle de plus en plus commune est le nom d'utilisateur à l'origine de la connection. Trouver le nom d'utilisateur à l'origine d'une connection implique typiquement l'utilisation d'un serveur d'authentification tel que IDENT, comme il est décrit dans la RFC 1413.

Etant donné qu'il n'est pas facile d'établir avec fiabilité qui est à l autre bout d'une connection réseau, l'utilisation de mots de passe est fortement recommandée sur une connection inter-serveur, en plus des autres mesures telles que l'utilisation d'un serveur d'identité.

8. Implémentations actuelles

Le reste de cette section traite d'issues qui sont pour la plupart intéressantes pour ceux qui veulent implémenter un serveur, mais certaines s'appliquent aussi directement aux clients.

8.1 Protocole Réseau: TCP - Pourquoi il est le plus approprié.

8.1.1 Support des sockets Unix

Lors de la communication des informations au sujet d'un domaine de socket Unix, le serveur doit remplacer le nom de chemin par le vrai nom d'hôte, à moins que le nom socket soit demandé.

8.2 Traitement des commandes

8.3 Distribution de message

Lorsqu'il traite ses connections, un serveur doit d'abord lire et traiter toutes les données entrantes, en mémorisant les données qui seront émises. Quand toutes les entrées disponibles sont traitées, la queue d'envoi est expédiée. Cela réduit le nombre d'appels systèmes write() et aide TCP à faire des paquets plus gros.

8.4 La vie d'une connection

Si une connection ne répond pas à temps, elle est fermée en utilisant les procédures appropriées. Une connection est également lâchée si son sendq grossi au-delà du maximum autorisé, car il vaut mieux fermer une connection lente que d'avoir le processus serveur bloqué.

8.5 Etablissement d'une connection serveur à client

Après cela, le serveur doit envoyer le pseudo du nouvel utilisateur, et toute autre information aussi bien fournies par le client (commande USER) que celles trouvées par le serveur (serveurs DNS et IDENT). Le serveur doit envoyer ces informations à la première commande NICK suivi de USER.

8.6 Etablissement d'une connection serveur/serveur

Après avoir reçu une connection suivi d'une paire PASS/SERVER qui a été reconnue valide, le serveur doit répondre avec ses propres informations PASS/SERVER pour cette connection, ainsi que toutes les informations d'état qu'il connais comme décrit ci-dessous.

Quand le serveur initiant reçoit la paire PASS/SERVER, lui aussi vérifie que le serveur répondant est authentifié correctement avant d'accepter la connection comme étant ce serveur.

8.6.1 Echange des informations d'état des serveurs à la connection

• tous les autres serveurs connus ;
• toutes les informations utilisateurs connues ;
• toutes les informations de canaux connues.

Les informations concernant les serveurs sont envoyées avec des messages SERVER supplémentaires, les informations utilisateurs avec des messages NICK/USER/MODE/JOIN et celles des canaux avec des messages MODE.

NOTE : Les sujets des canaux ne sont PAS échangés ici, car la commande TOPIC écrase toute information de sujet précédente, si bien que, au mieux, les deux côtés de la connection échangeraient les sujets.

En passant les informations d'état concernant les serveurs en premier, toutes les collisions avec des serveurs qui existeraient déjà ont lieu avant les collisions de pseudo dues à un second serveur introduisant un pseudonyme particulier. En raison de l'obligation de réseau IRC à n'exister que sur un graphe acyclique, il est possible que le réseau se soit déjà reconnecté ailleurs, et l'endroit où la collision a lieu indique ou le réseau doit être divisé.

8.7 Terminaison des connection serveur/client.

8.8 Terminaison des connections serveur/serveur.

8.9 Suivi des changements de pseudonymes

• KILL (le pseudo se faisant tuer)
• MODE (+/- o,v)
• KICK (le pseudo se faisant exclure)

Dans les cas ci-dessus, le serveur doit tout d'abord vérifier l'existence du pseudonyme, puis vérifier l'historique pour voir à qui appartient ce pseudo. Cela réduit les chances de problèmes, mais ne les empêche pas complètement, ce qui peu résulter au final de l'affectation du mauvais client. Lors du traçage des changements de pseudonymes pour une des commandes ci-dessus, il est recommandé qu'un intervalle de temps soit donné, et que les entrées trop vielles soient ignorées.

Pour un historique parfait, un serveur devrait être capable de garder les pseudonymes de tous les clients qui ont décidé d'un changement. La taille est limitée par d'autres facteurs (tels que la mémoire, ...)

8.10 Contrôle d'inondation des clients

• vérifier si les 'messages de temps' des clients est inférieur au temps courant (et le mettre à l'heure courante le temps échéant) ;
• lire toute donnée présentée par le client ;
• tant que le compteur est inférieur à dix secondes par rapport à l'heure actuelle, traiter tout message actuel et pénaliser le client de deux secondes par message ;

8.11 Boucles non bloquantes

8.11.1 Recherche du nom d'hôte (DNS)

8.11.2 Recherche du nom d'utilisateur (IDENT)

8.12 Fichier de configuration

• de quels hôtes accepter une connection en tant que client;
• de quels hôtes accepter une connection en tant que serveur;
• à quels hôtes se connecter (aussi bien activement que passivement) ;
• informations sur l'emplacement du serveur (université, ville/état, entreprise par exemple) ;
• quels sont les responsables du serveur, avec une adresse email où ils peuvent être contactés ;
• noms d'hôtes et mots de passe pour les clients qui souhaitent obtenir l'accès restreint aux commandes d'opérateur.

La liste ci-dessus est le minimum obligatoire pour tout serveur qui souhaite se connecter à un autre serveur. Parmi les autres éléments utiles, on trouve :

• spécification de quels serveurs un serveur peut introduire ;
• jusqu'à quelle longueur une branche de serveur peut aller ;
• heures durant lesquelles un client peut se connecter

8.12.1 Autorisation des connections de clients

'Accepter' et 'interdire' doivent tout les deux être implémentés pour fournir le niveau de flexibilité requis par le contrôle d'accès des hôtes.

8.12.2 Opérateurs

8.12.3 Autorisation des connections de serveurs

8.12.4 Admin

8.13 Appartenance à un canal.

9. Problèmes actuels

9.1 Localisation

9.2 Identifiants

9.2.1 Pseudonymes

9.2.2 Canaux

9.2.3 Serveurs

9.3 Algorithmes

Dans les versions actuelles du serveur, il n'y a pas vérification de base de données, chaque serveur assumant qu'un serveur voisin est correct. Cela ouvre la porte à de gros problèmes si un serveur qui se connecte est bogué ou essaie d'introduire des contradictions dans le réseau existant.

Actuellement, en raison du manque d'étiquettes internes et globales uniques, il existe une multitude de conditions pouvant causer une désynchronisation. Ces conditions résultent généralement du temps pris par un message pour traverser le réseau IRC. Mais, même en changeant pour des étiquettes uniques, il y a des problèmes de synchronisation avec les commandes liées aux canaux.

10. Support actuel et disponibilité

• Mailing lists pour les discussions liées à l'IRC :
  • Protocole futur : ircd-three-request@eff.org
  • Discussion générale: operlist-request@eff.org
• Implémentations logicielles
  • cs.bu.edu:/irc
  • nic.funet.fi:/pub/irc
  • coombs.anu.edu.au:/pub/irc
    
• Newsgroup: alt.irc
  

11. Considérations de sécurité

12. Adresses des auteurs

Jarkko Oikarinen
Tuirantie 17 as 9
90500 OULU
FINLAND
Email: mailtojto@tolsun.oulu.fi

Darren Reed
4 Pateman Street
Watsonia, Victoria 3087
Australia
Email: mailto:avalon@coombs.anu.edu.au