Groupe de Travail Réseau | J. Oikarinen
Requête pour commentaires: 1459 | D. Reed
| Mai 1993

# Protocole de discussions relayées par internet (IRC)

### Statut de ce mémo

Ce mémo défini un protocole expérimental pour la communauté internet. Des discussions et suggestions d'améliorations sont attendues. Veuillez vous référer à la version courante de "IAB Official Protocol Standards" pour connaître l'état de standardisation et le statut de ce protocole. La distribution de ce mémo n'est pas limitée.

### Résumé

Le protocole IRC a été développé au cours des 4 dernières années. Il a été initialement implémenté pour permettre aux utilisateurs d'un BBS pour discuter entre eux. Maintenant, il est utilisé sur un réseau mondial de serveurs et de clients, et a du mal à gérer sa croissance. Au cours des deux dernières années, le nombre moyen d'utilisateurs connectés au réseau IRC principal a été multiplié par 10.

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 (Internet Relay Chat) a été conçu pendant de nombreuses années pour l'usage de conférences en mode texte. Ce document décrit le protocole IRC actuel.

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

Le serveur est la colonne vertébrale de l'IRC. Il fournit un point auquel peuvent les clients peuvent se connecter pour parler entre eux, et un point auquel les autres serveurs peuvent se connecter, formant un réseau IRC. La seule configuration de réseau autorisée est celle d'un arbre [voir Fig. 1] où chaque serveur agit comme un noeud central pour la partie du réseau qu'il voit.

                             [ 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

Un client est un truc qui se connecte à un serveur et qui n'est pas un autre serveur. Chaque client est différencié des autres clients par un pseudonyme unique ayant une longueur maximale de neuf (9) caractères. Voir les règles de grammaire du protocole pour ce qui est autorisé et ce qui ne l'est pas dans un pseudonyme. En plus de leur pseudonyme, tous les serveurs doivent connaître les informations suivantes sur tous les clients : le vrai nom de l'hôte sur lequel le client est exécuté, le nom de l'utilisateur du client sur cet hôte, et le serveur auquel le client est connecté.

### 1.2.1 Opérateurs

Pour permettre de maintenir un niveau d'ordre raisonnable dans un réseau IRC, une catégorie de clients spéciale (les opérateurs) est autorisée à exécuter des fonctions de maintenance générale sur le réseau. Bien que les pouvoirs donnés aux opérateurs peuvent être considérés comme 'dangereux', ils sont néanmoins indispensables. Les opérateurs doivent être capable de faire certaines tâches de base, telles que la déconnexion de la reconnection aux serveurs, ce qui est nécessaire pour prévenir les problèmes à long terme de mauvais routage réseau. Etant donné cette nécessité, le protocole décrit ici n'autorise que les opérateurs à effectuer ces fonctions. Voir les section 4.1.7 (SQUIT) et 4.3.5 (CONNECT).

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

Un canal est groupe nommé d'un ou plusieurs clients qui recevront tous les messages adressés à ce canal. Les canaux sont créés implicitement quand le premier client y accède, et le canal disparaît lorsque le dernier client le quitte. Tant qu'un canal existe, tous les clients peuvent y accéder en utilisant le nom du canal.

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 opérateurs de canaux (aussi appelés "chanop") sur un canal donné, sont considérés comme étant propriétaires du "canal". A ce titre, les opérateurs de canaux sont dotés de certains pouvoirs qui leur permettent de garder le contrôle et une forme sanité à leur canal. En tant que propriétaire d'un canal, un opérateur de canal n'est pas tenu d'avoir de raisons pour agir, bien que si leur action sont généralement antisociales ou abusives, il pourrait être raisonable de demander a un opérateur IRC d'intervenir, ou pour les utilisateur de simplement quitter et aller ailleurs pour former leur propre canal.

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

Le protocole décrit ici vaut aussi bien pour les connections des serveurs que pour celles des clients. Néanmoins, il y a plus de restrictions sur les connections des clients (qui sont considérés comme plus douteuses) que les connections des serveurs.

## 2.2 Les jeux de caractères

Aucun jeu de caractères n'est imposé. Le protocole est basé sur un jeu de caractère de huit (8) bits, qui forment un octet ; cependant, certains codes sont utilisés en tant que codes de contrôle, et agissent comme délimiteurs de messages.

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

Les serveurs et les clients s'envoient chacun des messages qui peuvent ou non générer une réponse. Si le message contient une commande valide, comme il est décrit dans les sections suivantes, le client devrait s'attendre à une réponse comme spécifié, mais il n'est pas conseillé d'attendre éternellement une réponse. La communication de client à serveur, et de serveur à serveur est essentiellement de nature asynchrone.

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

Les messages du protocole doivent être extrait du flux continu d'octets. La solution actuelle consiste à désigner deux caractères donnés, CR et LF, comme séparateurs de messages. Les messages vides sont ignorés en silence, ce qui permet l'usage d'une suite de CR-LF entre les messages sans problèmes supplémentaires.

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

La plupart des messages envoyés aux serveurs génère une réponse. Les réponses les plus courantes sont des réponses numériques, aussi bien pour les messages d'erreurs que pour les réponses normales. La réponse numérique est envoyé comme un message contenant le préfixe de l'expéditeur, le nombre de trois chiffres, et le destinataire de la réponse. Une réponse numérique ne peut pas émaner d'un client, et tout message de ce style reçu par un serveur doit être ignoré silencieusement. Hormis cela, une réponse numérique est un message comme un autre, si ce n'est que le mot-clé est composé de trois chiffres, plutôt que d'une suite de lettre. Une liste des réponses possible est fournie à la section 6.

# 3. Concepts IRC

Cette section décrit les concepts sous-jacents à l'organisation du protocole IRC et comment les implémentations actuelles délivrent les différentes classes de messages.

                              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

La communication sur une base un à un n'a lieu que par les clients, étant donné que la plupart du trafic serveur/serveur n'est pas causé par les serveurs qui se parlent entre eux. Afin de fournir un moyen sécurisé pour les clients de parler entre eux, il est nécessaire que tous les serveurs, pour atteindre un client, soient capables d'envoyer un message dans une seule direction sur l'arbre des connections. Le chemin d'un message remis est le plus court entre deux points sur l'arbre.

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

Le but principal d'IRC est de fournir un forum qui permette de réaliser des conférences de façon simple et efficace (conversation un à plusieurs). L'IRC offre plusieurs moyens d'accomplir cela, chacun avec des buts différents.

### 3.2.1 A une liste

Le moyen le moins efficace d'avoir une conversation un à plusieurs consiste, pour chaque client, à parler à une 'liste' d'utilisateurs. La façon dont cela à lieu est triviale : chaque client donne une liste de destinataires auxquels le message doit être délivré, et le serveur découpe le message et en distribue une copie à chacun des destinataires. Ce n'est pas aussi efficace que l'utilisation d'un groupe puisque la liste de destinataire est décomposée et la distribution a lieu sans vérifier que le message soit envoyé en double sur un même chemin.

### 3.2.2 A un groupe (canal)

Sur IRC, un canal a un rôle équivalent à celui d'un groupe de multi-diffusion ; leur existence est dynamique (ils vont et viennent au fur et à mesure que les gens accèdent et quittent les canaux) et la conversation qui a lieu sur un canal n'est envoyé qu'aux serveurs qui ont des utilisateurs sur ce canal. Cette action est alors répétée par chaque combinaison client/serveur jusqu'à ce que le message original est atteint tous les membres d'un 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

Afin de fournir aux opérateurs IRC un mécanisme pour envoyer des messages à un grand nombre d'utilisateurs apparentés, on fournit des masques de serveurs et d'hôtes. Ces messages sont envoyés à ceux des serveurs et des hôtes dont l'adresse correspond au masque. Ces messages ne sont envoyés qu'aux endroits où il y a des utilisateurs, de façon similaire a celle des canaux.

## 3.3 Un à tous

Les messages un à tous peuvent être décrit comme des messages de type diffusion, envoyés à tous les clients, les serveurs, ou les deux. Sur un grand réseau d'utilisateurs et de serveurs, un simple message peut générer beaucoup de trafic, puisqu'il est envoyé à travers le réseau pour atteindre toutes les destinations.

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

Il n'y a pas de classe de message qui, à partir d'un simple message, résulte en un message envoyé à tous les autres clients.

### 3.3.2 Client à serveur

La plupart des commandes qui résultent en un changement d'état (tels que l'appartenance à un canal, le mode d'un canal, le statut d'un utilisateur, etc.) doivent être, par défaut, envoyés à tous les serveurs, et cet envoi ne peut pas être altéré par le client.

### 3.3.3 Serveur à serveur

Bien que la plupart des messages entre les serveurs soient distribués à 'tous' les autres serveurs, cela n'est nécessaire que pour les messages qui affectent soit un utilisateur, soit un canal, soit un serveur. Etant donné que cela constitue l'essentiel des éléments de l'IRC, la quasi-totalité des messages issus d'un serveur est diffusée à tous les autres serveurs connectés.

## 4. Détails des messages

Les pages suivantes décrivent les messages reconnus par les serveurs IRC et les clients. Toutes les commandes décrites dans cette section doivent être implémentées par tous les serveurs utilisant ce protocole.

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

Les commandes décrites dans cette section sont utilisées pour établir une connection avec un serveur IRC, aussi bien par un client que par un serveur, ainsi qu'une déconnexion correcte.

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

Commande : PASS
Paramètres : <mot de passe>

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

Exemple:
PASS motdepasssecretici

### 4.1.2 Message NICK

Commande : NICK
Paramètres : <pseudonyme> [ <compteur de distance> ]

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

Exemples:

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

### 4.1.3 Message USER

Commande: USER
Paramètres: <nom d'utilisateur> <hôte> <nom de serveur> <nom réel>

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

Exemples:

`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

Commande: SERVER
Paramètres: <nom de serveur> <compteur de distance> <info>

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

Exemples :

`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

Commande: OPER
Paramètres: <utilisateur> <mot de passe>

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

Exemple:

`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

Commande: QUIT
Paramètres: [<Message de départ >]

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.

Exemples:

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

### 4.1.7 Message SQUIT

Commande: SQUIT
Paramètres: <serveur> <commentaire>

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

Exemples:

`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

Ce groupe de messages s'intéresse à la manipulation de canaux, à leurs propriétés (mode des canaux), et à leur contenu (typiquement des clients). En implémentant ces commandes, la résolution de conflits entre les clients est inévitable, par exemple lorsque deux clients à deux extrémités du réseau envoient des commandes incompatibles. Il est aussi nécessaire aux serveurs de garder l'historique d'un pseudonyme de façon à ce quand un paramètre <pseudo> est donné, le serveur puisse vérifier dans l'historique si le pseudo n'a pas changé récemment.

### 4.2.1 Le message JOIN

Commande: JOIN
Paramètres: <canal>{,<canal>} [<clé>{,<clé>}]

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

Exemples:

`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

Commande: PART
Paramètres: <canal>{,< canal >}

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

Exemples:

`PART #twilight_zone` ; quitte le canal "#twilight_zone"

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

### 4.2.3 Message MODE

Commande: 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

Paramètres: <canal> {[+|-]|o|p|s|i|t|n|b|v} [<limite>] [<utilisateur>] [<masque de bannissement >]

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

Paramètres: <pseudonyme> {[+|-]|i|w|s|o}

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

Exemples:

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

Commande: TOPIC
Paramètres: <canal> [<sujet>]

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

Exemples:

`: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

Commande: NAMES
Paramètres: [<canal>{,<canal>}]

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

Exemples:

`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

Commande: LIST
Paramètres: [<canal>{,<canal>} [<serveur>]]

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

Exemples:

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

### 4.2.7 Message INVITE

Commande: INVITE
Paramètres: <pseudonyme> <canal>

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

Exemples:

`: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

Commande: KICK
Paramètres: <canal> <utilisateur> [<commentaire>]

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

Exemples:

`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

Le groupe de requêtes de commande des serveurs servent à obtenir des informations au sujet de tout serveur connecté au réseau. Tous les serveurs connectés doivent répondre à ces requêtes et répondre correctement. Toute réponse invalide (ou l'absence de réponse) doit être considéré comme un signe de serveur cassé, et il doit se déconnecter / se désactiver au plus tôt, jusqu'à ce que le problème soit résolu.

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

Commande: VERSION
Paramètres: [<serveur>]

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

Exemples:

`: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

Commande: STATS
Paramètres: [<requête> [<serveur>]]

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

Exemples:

`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

Commande: LINKS
Paramètres: [[<serveur distant>] <masque de serveur >]

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

Exemples:

`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

Commande: TIME
Paramètres: [<serveur>]

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

Exemples:

`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

Commande: CONNECT
Paramètres: <serveur destination > [<port> [<serveur distant>]]

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

Exemples:

`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

Commande: TRACE
Paramètres: [<serveur>]

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

Si le message TRACE est destiné à un autre serveur, tous les serveurs intermédiaires doivent retourner une réponse RPL_TRACELINK pour indiquer que le TRACE est passé par lui et où il va ensuite.

               RPL_TRACELINK

Une réponse TRACE doit être une des réponses numériques suivantes :

               RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
               RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
               RPL_TRACEUSER                   RPL_TRACESERVER
               RPL_TRACESERVICE                RPL_TRACENEWTYPE
               RPL_TRACECLASS

Exemples:

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

### 4.3.7 Commande ADMIN

Commande: ADMIN
Paramètres: [<serveur>]

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

Exemples:

`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

Commande: INFO
Paramètres: [<serveur>]

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

Exemples:

`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

Le but principal du protocole IRC est de fournir une base afin que des clients puissent communiquer entre eux. PRIVMSG et NOTICE sont les seuls messages disponibles qui réalisent effectivement la l'acheminement d'un message textuel d'un client à un autre - le reste le rend juste possible et assure que cela se passe de façon fiable et structurée.

### 4.4.1 Messages privés

Commande: PRIVMSG
Paramètres: <destinataire>{,<destinataire>} <texte à envoyer >

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

Exemples:

`: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

Commande: NOTICE
Paramètres: <pseudonyme> <texte>

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

Les requêtes utilisateurs sont un groupe de commandes dont le but principal est la recherche d'informations sur un utilisateur particulier, ou sur un groupe d'utilisateurs. Lorsqu'on utilise des jokers avec ces commandes, elles ne renvoient les informations que sur les utilisateurs qui vous sont 'visibles'. La visibilité d'un utilisateur est déterminée par la combinaison du mode de cet utilisateur, et des canaux sur lesquels tous les deux êtes.

### 4.5.1 Requête WHO

Commande: WHO
Paramètres: [<nom> [<o>]]

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

Exemples:

`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

Commande: WHOIS
Paramètres: [<serveur>] <masque de pseudo>[,<masque de pseudo>[,...]]

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

Exemples:

`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

Commande: WHOWAS
Paramètres: <pseudonyme> [<compte> [<serveur>]]

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

Exemples:

`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

Les messages de cette catégorie ne font partie d'aucune des catégories ci-dessus, mais font néanmoins partie intégrante du protocole, et sont indispensables.

### 4.6.1 Message KILL

Commande: KILL
Paramètres: <pseudonyme> <commentaire>

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

Exemple:

`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

Commande: PING
Paramètres: <serveur1> [<serveur2>]

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

Exemples:

`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

Commande: PONG
Paramètres: <démon> [<démon2>]

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

Exemples:

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

### 4.6.4 Message ERROR

Commande: ERROR
Paramètres: < message d'erreur>

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.

Exemples:

`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

Cette section décrit les messages optionnels. Ils ne sont pas requis dans les implémentations des serveurs décrits ici. En l'absence de l'option, un message d'erreur doit être généré, ou une erreur commande inconnue. Si le message est destiné à un autre serveur, il doit est transmis (traitement de base obligatoire). Les nombres alloués pour cela sont listé avec les messages ci-dessous.

## 5.1 AWAY

Commande: AWAY
Paramètres: [message]

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

Exemples:

`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

Commande: REHASH
Paramètres: Aucun

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

Exemples:

`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

Commande: RESTART
Paramètres: Aucun

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

Exemples:

`RESTART` ; pas de paramètres

## 5.4 Message SUMMON

Commande: SUMMON
Paramètres: <utilisateur> [<serveur>]

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

Exemples:

`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

Commande: USERS
Paramètres: [<serveur>]

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

Réponse de désactivation :

               ERR_USERSDISABLED

Exemples:

`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

Commande: WALLOPS
Paramètres: Texte à envoyer à tous les opérateurs actuellement connectés.

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

Exemples:

`: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

Commande: USERHOST
Paramètres: <pseudonyme>{<espace ><pseudonyme>}

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

Exemples:

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

## 5.8 Message ISON

Commande: ISON
Paramètres: <pseudonyme>{<espace><pseudonyme>}

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

Exemples:

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

# 6. Réponses

Ce qui suit est une liste de réponses numériques générées à la suite des commandes spécifiées ci-dessus. Chaque réponse numérique est donnée avec son numéro, son nom, et sa chaîne de réponse (en anglais).

## 6.1 Réponses d'erreur

401 ERR_NOSUCHNICK
  "<pseudonyme> :No such nick/channel"

Utilisé pour indiquer que le pseudonyme passé en paramètre à la commande n'est pas actuellement utilisé.

402 ERR_NOSUCHSERVER
  "<nom de serveur> :No such server"

Utilisé pour indiquer que le nom du serveur donné n'existe pas actuellement.

403 ERR_NOSUCHCHANNEL
  "<nom de canal> :No such channel"

Utilisé pour indiquer que le nom de canal donné est invalide.

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

Envoyé à un utilisateur qui (a) soit n'est pas dans un canal en mode +n ou (b) n'est pas opérateur (ou mode +v) sur un canal en mode +m ; et essaie d'envoyer un PRIVMSG à ce canal.

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

Envoyé à un utilisateur quand il a atteint le nombre maximal de canaux qu'il est autorisé à accéder simultanément, et qu'il essaie d'en rejoindre un autre.

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

Renvoyé par WHOWAS pour indiquer qu'il n'y a pas d'information dans l'historique concernant ce pseudonyme.

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

Renvoyé à un client qui essaie d'envoyer un PRIVMSG/NOTICE utilisant le format de destination utilisateur@hôte pour lequel utilisateur@hôte a plusieurs occurrences.

409 ERR_NOORIGIN
  ":No origin specified"

Message PING ou PONG sans le paramètre origine qui est obligatoire puisque ces commandes doivent marcher sans préfixe.

411 ERR_NORECIPIENT
  ":No recipient given (<commande>)"

Pas de destinataire.

412 ERR_NOTEXTTOSEND
  ":No text to send"

Pas de texte à envoyer.

413 ERR_NOTOPLEVEL
  "<masque> :No toplevel domain specified"

Domaine principal non spécifié.

414 ERR_WILDTOPLEVEL
  "<masque> :Wildcard in toplevel domain"

Joker dans le domaine principal

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"

Renvoyé à un client enregistré pour indiquer que la commande envoyée est inconnue du serveur.

422 ERR_NOMOTD
  ":MOTD File is missing"

Le fichier MOTD du serveur n'a pas pu être ouvert.

423 ERR_NOADMININFO
  "<serveur> :No administrative info available"

Renvoyé par un serveur en réponse à un message ADMIN quand il y a une erreur lors de la recherche des informations appropriées.

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

Message d'erreur générique utilisé pour rapporter un échec d'opération de fichier durant le traitement d'un message.

431 ERR_NONICKNAMEGIVEN
  ":No nickname given"

Renvoyé quand un paramètre pseudonyme attendu pour une commande n'est pas fourni.

432 ERR_ERRONEUSNICKNAME
  "<pseudo> :Erroneus nickname"

Renvoyé après la réception d'un message NICK qui contient des caractères qui ne font pas partie du jeu autorisé. Voir les sections 1 et 2.2 pour les détails des pseudonymes valides.

433 ERR_NICKNAMEINUSE
  "<nick> :Nickname is already in use"

Renvoyé quand le traitement d'un message NICK résulte en une tentative de changer de pseudonyme en un déjà existant.

436 ERR_NICKCOLLISION
  "<nick> :Nickname collision KILL"

Renvoyé par un serveur à un client lorsqu'il détecte une collision de pseudonymes (enregistrement d'un pseudonyme qui existe déjà sur un autre serveur).

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

Renvoyé par un serveur pour indiquer que l'utilisateur donné n'est pas dans le canal spécifié.

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

Renvoyé par le serveur quand un client essaie une commande affectant un canal dont il ne fait pas partie.

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

Renvoyé quand un client essaie d'inviter un utilisateur sur un canal où il est déjà.

444 ERR_NOLOGIN
  "<utilisateur> :User not logged in"

Renvoyé par un SUMMON si la commande n'a pas pu être accomplie, car l'utilisateur n'est pas connecté.

445 ERR_SUMMONDISABLED
  ":SUMMON has been disabled"

Renvoyé en réponse à une commande SUMMON si le SUMMON est désactivé. Tout serveur qui ne gère pas les SUMMON doit retourner cette valeur.

446 ERR_USERSDISABLED
  ":USERS has been disabled"

Retourné en réponse à une commande USERS si la commande est désactivée. Tout serveur qui ne gère pas les USERS doit retourner cette valeur.

451 ERR_NOTREGISTERED
  ":You have not registered"

Retourné par le serveur pour indiquer à un client qu'il doit être enregistré avant que ses commandes soient traitées.

461 ERR_NEEDMOREPARAMS
  "<commande> :Not enough parameters"

Renvoyé par un serveur après de nombreuses commandes, afin d'indiquer que le client n'a pas fourni assez de paramètres.

462 ERR_ALREADYREGISTRED
  ":You may not reregister"

Retourné par le serveur à tout lien qui tente de changer le détail de leurs informations enregistrées (tels que mot de passe et détail utilisateur du second message USER)

463 ERR_NOPERMFORHOST
  ":Your host isn't among the privileged"

Renvoyé à un client qui essaie de s'enregistrer sur un serveur qui n'accepte pas les connections depuis cet hôte.

464 ERR_PASSWDMISMATCH
  ":Password incorrect"

Retourné pour indiquer l'échec d'une tentative d'enregistrement d'une connection dû à un mot de passe incorrect ou manquant.

465 ERR_YOUREBANNEDCREEP
  ":You are banned from this server"

Retourné après une tentative de connection et d'enregistrement sur un serveur configuré explicitement pour vous dénier les connections.

467 ERR_KEYSET
  "<canal> :Channel key already set"

Clé de canal déjà définie.

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

Impossible de joindre le canal (+l)

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

Mode inconnu.

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

Impossible de joindre le canal (+i).

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

Impossible de joindre le canal (+b).

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

Impossible de joindre le canal (+k).

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

Toute commande qui requiert le privilège d'opérateur pour opérer doit retourner cette erreur pour indiquer son échec.

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

Toute commande qui requiert les privilèges 'chanop' (telles que les messages MODE) doit retourner ce message à un client qui l'utilise sans être chanop sur le canal spécifié.

483 ERR_CANTKILLSERVER
  ":You cant kill a server!"

Toute tentative d'utiliser la commande KILL sur un serveur doit être refusée et cette erreur renvoyée directement au client.

491 ERR_NOOPERHOST
  ":No O-lines for your host"

Si un client envoie un message OPER et que le serveur n'a pas été configuré pour autoriser les connection d'opérateurs de cet hôte, cette erreur doit être retournée.

501 ERR_UMODEUNKNOWNFLAG
  ":Unknown MODE flag"

Renvoyé par un serveur pour indiquer que le message MODE a été envoyé avec un pseudonyme et que le mode spécifié n'a pas été identifié.

502 ERR_USERSDONTMATCH
  ":Cant change mode for other users"

Erreur envoyé à tout utilisateur qui essaie de voir ou de modifier le mode utilisateur d'un autre client.

## 6.2 Réponses aux commandes.

300 RPL_NONE

Numéro de réponse bidon. Inutilisé.

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

Format de réponse utilisé par USERHOST pour lister les réponses à la liste des requêtes. La chaîne de réponse est composée ainsi :
<réponse> ::= <pseudo>['*'] '=' <'+'|'-'><hôte>
Le '*' indique si le client est enregistré comme opérateur. Les caractères '-' ou '+' indiquent respectivement si le client a défini un message AWAY ou non.

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

Format de réponse utilisé par ISON pour lister les réponses à la liste de requête.

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"

Ces trois réponses sont utilisées avec la commande AWAY (si elle est autorisée). RPL_AWAY est envoyé à tout client qui envoie un PRIVMSG à un client absent. RPL_AWAY n'est envoyé que par le serveur sur lequel le client est connecté. Les réponses RPL_UNAWAY et RPL_NOWAWAY sont envoyées quand un client retire et défini un message 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>}"

Les réponses 311 à 313 et 317 à 319 sont toutes générées en réponses à un message WHOIS. S'il y a assez de paramètres, le serveur répondant doit soit formuler une réponse parmi les numéros ci-dessus (si le pseudo recherché a été trouvé) ou renvoyer un message d'erreur. Le '*' dans RPL_WHOISUSER est là en tant que littéral et non en tant que joker. Pour chaque jeu de réponses, seul RPL_WHOISCHANNELS peut apparaître plusieurs fois (pour les longues listes de nom de canaux). Les caractères '@' et '+' à côté du nom de canal indique si un client est opérateur de canal, ou si on l'a autorisé à parler dans un canal modéré. La réponse RPL_ENDOFWHOIS est utilisée pour marquer la fin de la réponse WHOIS.

314 RPL_WHOWASUSER
  "<pseudo> <utilisateur> <hôte> * :<vrai nom>"
369 RPL_ENDOFWHOWAS
  "<pseudo> :End of WHOWAS"

Lorsqu'il répond à un message WHOWAS, un serveur doit utiliser RPL_WHOWASUSER, RPL_WHOISSERVER ou ERR_WASNOSUCHNICK pour chacun des pseudonymes de la liste fournie. A la fin de toutes les réponses, il doit y avoir un RPL_ENDOFWHOWAS (même s'il n'y a eu qu'une réponse, et que c'était une erreur).

321 RPL_LISTSTART
  "Channel :Users Name"
322 RPL_LIST
  "<canal> <# visible> :<sujet>"
323 RPL_LISTEND
  ":End of /LIST"

Les réponses RPL_LISTSTART, RPL_LIST, RPL_LISTEND marquent le début, les réponses proprement dites, et la fin du traitement d'une commande LIST. S'il n'y a aucun canal disponible, seules les réponses de début et de fin sont envoyées.

324 RPL_CHANNELMODEIS
  "<canal> <mode> <paramètres de mode >"
331 RPL_NOTOPIC
  "<canal> :No topic is set"
332 RPL_TOPIC
  "<canal> :<sujet>"

Lors de l'envoi d'un message TOPIC pour déterminer le sujet d'un canal, une de ces deux réponses est envoyée. Si le sujet est défini, RPL_TOPIC est renvoyée, sinon c'est RPL_NOTOPIC.

341 RPL_INVITING
  "<canal> <pseudo>"

Renvoyé pas un serveur pour indiquer que le message INVITE a été enregistré, et est en cours de transmission au client final.

342 RPL_SUMMONING
  "<utilisateur> :Summoning user to IRC"

Renvoyé par un serveur en réponse à un message SUMMON pour indiquer qu'il appelle cet utilisateur.

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

Réponse du serveur indiquant les détails de sa version. <version> est la version actuelle du programme utilisé (comprenant le numéro de mise à jour) et <debuglevel> est utilisé pour indiquer si le serveur fonctionne en mode débugage.
Le champ <commentaire> peut contenir n'importe quel commentaire au sujet de la version, ou des détails supplémentaires sur la version.

352 RPL_WHOREPLY
  "<canal> <utilisateur> <hôte> <serveur> <pseudo> <H|G>[*][@|+] :<compteur de distance> <vrai nom>"
315 RPL_ENDOFWHO
  "<nom> :End of /WHO list"

La paire RPL_WHOREPLY et RPL_ENDOFWHO est utilisée en réponse à un message WHO. Le RPL_WHOREPLY n'est envoyé que s'il y a une correspondance à la requête WHO. S'il y a une liste de paramètre fournie avec le message WHO, un RPL_ENDOFWHO doit être envoyé après le traitement de chaque élément de la liste, <nom> étant l'élément.

353 RPL_NAMREPLY
  "<canal> :[[@|+]<pseudo> [[@|+]<pseudo> [...]]]"
366 RPL_ENDOFNAMES
  "<canal> :End of /NAMES list"

En réponse à un message NAMES, une paire consistant de RPL_NAMREPLY et RPL_ENDOFNAMES est renvoyée par le serveur au client. S'il n'y a pas de canal résultant de la requête, seul RPL_ENDOFNAMES est retourné. L'exception à cela est lorsqu'un message NAMES est envoyé sans paramètre et que tous les canaux et contenus visibles sont renvoyés en une suite de message RPL_NAMEREPLY avec un RPL_ENDOFNAMES indiquant la fin.

364 RPL_LINKS
  "<masque> <serveur> :<compteur de distance> <info serveur >"
365 RPL_ENDOFLINKS
  "<mask> :End of /LINKS list"

En réponse à un message LINKS, un serveur doit répondre en utilisant le nombre RPL_LINKS, et indiquer la fin de la liste avec une réponse RPL_ENDOFLINKS.

367 RPL_BANLIST
  "<canal> <identification de bannissement>"
368 RPL_ENDOFBANLIST
  "<canal> :End of channel ban list"

Quand il liste les bannissements actifs pour un canal donné, un serveur doit renvoyer la liste en utilisant les messages RPL_BANLIST et RPL_ENDOFBANLIST. Un RPL_BANLIST différent doit être utilisé pour chaque identification de bannissement. Après avoir listé les identifications de bannissement (s'il y en a), un RPL_ENDOFBANLIST doit être renvoyé.

371 RPL_INFO
  ":<chaîne>"
374 RPL_ENDOFINFO
  ":End of /INFO list"

Un serveur répondant à un message INFO doit envoyer toute sa série d'info en une suite de réponses RPL_INFO, avec un RPL_ENDOFINFO pour indiquer la fin des réponses.

375 RPL_MOTDSTART
  ":- <serveur> Message of the day - "
372 RPL_MOTD
  ":- <texte>"
376 RPL_ENDOFMOTD
  ":End of /MOTD command"

Lorsqu'il répond à un message MOTD et que le fichier MOTD est trouvé, le fichier est affiché ligne par ligne, chaque ligne ne devant pas dépasser 80 caractères, en utilisant des réponses au format RPL_MOTD. Celles-ci doivent être encadrées par un RPL_MOTDSTART (avant les RPL_MOTDs) et un RPL_ENDOFMOTD (après).

381 RPL_YOUREOPER
  ":You are now an IRC operator"

RPL_YOUREOPER est renvoyé à un client qui vient d'émettre un message OPER et a obtenu le statut d'opérateur.

382 RPL_REHASHING
  "<fichier de configuration> :Rehashing"

Si l'option REHASH est activée et qu'un opérateur envoie un message REHASH, un RPL_REHASHING est renvoyé à l'opérateur.

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

Lorsqu'il répond à un message TIME, un serveur doit répondre en utilisant le format RPL_TIME ci-dessus. La chaîne montrant l'heure ne doit que contenir le jour et l'heure correcte. Il n'y a pas d'obligation supplémentaire.

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"

Si le message USERS est géré par un serveur, les réponses RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS et RPL_NOUSERS sont utilisées. RPL_USERSSTART doit être envoyé en premier, suivi par soit une séquence de RPL_USERS ou un unique RPL_NOUSER. Enfin, viens un RPL_ENDOFUSERS.

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

Les RPL_TRACE* sont tous renvoyés par le serveur en réponse à un message TRACE. Le nombre de messages retournés dépend de la nature du message TRACE, et s'il a été envoyé par un opérateur ou non. Il n'y a pas d'ordre définissant lequel doit être le premier. Les réponses RPL_TRACEUNKNOWN, RPL_TRACECONNECTING et RPL_TRACEHANDSHAKE sont toutes utilisées pour des connections qui n'ont pas été complètement établies, et sont soit inconnues, soit sont toujours en cours de connection, soit sont dans la phase terminale de la 'poignée de main du serveur'. RPL_TRACELINK est envoyé par tout serveur qui traite un message TRACE et doit le transmettre à un autre serveur. La liste de RPL_TRACELINK envoyé en réponse à une commande TRACE traversant le réseau IRC devrait refléter la connectivité actuelle des serveurs le long du chemin. RPL_TRACENEWTYPE est utilisé pour toute connection qui n'entre pas dans les autres catégories, mais qui est néanmoins affichée.

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

Pour répondre à une requête au sujet du mode du client, RPL_UMODEIS est renvoyé.

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"

Lors du traitement d'un message LUSERS, le serveur envoie un lot de réponses parmi RPL_LUSERCLIENT, RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS et RPL_LUSERME. Lorsqu'il répond, un serveur doit envoyer RPL_LUSERCLIENT et RPL_LUSERME. Les autres réponses ne sont renvoyées que si le nombre trouvé n'est pas nul.

256 RPL_ADMINME
  "<serveur> :Administrative info"
257 RPL_ADMINLOC1
  ":<info admin >"
258 RPL_ADMINLOC2
  ":<info admin>"
259 RPL_ADMINEMAIL
  ":<info admin>"

Lorsqu'il répond à un message ADMIN, un serveur doit renvoyer les réponses RLP_ADMINME à RPL_ADMINEMAIL et fournir un texte de message avec chacune. Pour RPL_ADMINLOC1, une description de la ville et de l'état dans lequel le serveur est, suivi des détails de l'université et du département (RPL_ADMINLOC2), et finalement le contact administratif pour ce serveur (avec obligatoirement une adresse email) dans RPL_ADMINEMAIL.

## 6.3 Nombres réservés.

Ces nombres ne sont pas décrits si dessus par ce qu'ils tombent dans l'une des catégories suivantes :

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

Les clients et serveurs sont tous deux soumis au même niveau d'authentification. Dans les deux cas, une vérification de l'adresse IP à l'hôte (avec vérification inverse sur cela) est effectuée pour toutes les connections au serveur. Les deux connections sont alors sujet à une vérification de mot de passe (s'il y a un mot de passe défini pour cette connection). Ces vérifications sont possibles pour toutes les connections, bien que la vérification d'un mot de passe n'est généralement utilisée que pour les 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

La seule implémentation actuelle de ce protocole est le serveur IRC version 2.8. Les versions précédentes peuvent implémenter certaines ou toutes les commandes décrites dans ce document en utilisant les messages NOTICE à la place des réponses numériques. Malheureusement, à causes des problèmes de compatibilité ascensionnelle, les implémentations de certaines parties de ce document diffèrent de ce qui est spécifié. Une différence notable est :
* La présence de tout LF ou CR dans n'importe ou dans le message marque sa fin (au lieu de la séquence préconisée CR-LF) ;

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é.

IRC a été implémenté sur TCP car TCP fourni un protocole réseau fiable qui est approprié à cette échelle de discussions. L'utilisation d'IP multicast est une alternative, mais n'est pas très répandue à l'heure actuelle.

### 8.1.1 Support des sockets Unix

Etant donné que les domaines de sockets Unix permettent les opérations listen/connect, les implémentations actuelles peuvent être configurées pour écouter et accepter aussi bien les clients que les serveurs sur un domaine de socket Unix. On reconnaît les sockets à un nom d'hôte commençant par un '/'.

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

Afin de fournir des E/S réseaux 'non-tamponnées' utiles aux clients et aux serveurs, à chaque connection est associée son propre 'tampon d'entrée' dans lequel les résultats de lectures et traitements les plus récents sont conservés. Une taille de tampon de 512 octets et utilisée afin de contenir un message complet, bien qu'il en contienne habituellement plusieurs. Le tampon privé est traité après toute opération de lecture à la recherche de messages valides. Lors du traitement de messages multiples en provenance d'un client, on doit prendre soin au cas où un des messages causerait le départ du client.

## 8.3 Distribution de message

Il est courant de trouver des liens réseaux saturés ou des hôtes à qui vous envoyer des données et qui sont incapables d'en faire autant. Bien qu'Unix gère typiquement cela à travers la fenêtre TCP et ses tampons internes, le serveur a généralement de grandes quantités de données à envoyer (spécialement lorsqu'une nouvelle connection serveur/serveur est crée) et les petits tampons fournis dans le noyau ne sont pas suffisant à la queue de sortie. Pour alléger ce problème, une "queue d'envoi" est utilisée comme une queue FIFO pour les données à envoyer. Une "queue d'envoi" typique peut croître jusqu'à 200ko sur un gros réseau IRC, avec des connections réseau lentes quand un nouveau serveur se connecte.

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

Pour détecter quand une connection est morte ou ne répond plus, le serveur doit envoyer un PING à toute les connections dont il n'a pas eu de réponse depuis un temps donné.

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

Lors de la connection à un serveur IRC, on envoie au client le MOTD (s'il est présent) ainsi que le nombre actuel d'utilisateur et de serveurs (comme pour la commande LUSER). Le serveur doit également envoyer un message non équivoque au client, qui stipule son nom, sa version, ainsi que tout autre message d'introduction qui lui semble approprié.

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

Le processus d'établissement d'une connection serveur à serveur est plein de dangers, car il y a de nombreux domaines où un problème peut survenir { - the least of which are race conditions.}

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

L'ordre des informations d'état échangées entre les serveurs est essentiel. L'ordre requis est le suivant :

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

Lorsqu'une connection client se ferme, un message QUIT est généré de la part du client par le serveur sur lequel le client était connecté. Aucun autre message ne doit être généré ou utilisé.

## 8.8 Terminaison des connections serveur/serveur.

Si une connection serveur/serveur est fermée, soit par un SQUIT généré à distance, soit par une cause 'naturelle', le reste du réseau IRC doit le prendre en compte, et c'est au serveur qui détecte la fermeture de faire circuler l'information. Le serveur envoie une liste de SQUIT (un par serveur au-delà de la connection coupée) et une liste de QUIT (un par client au-delà de la connection coupée).

## 8.9 Suivi des changements de pseudonymes

Tous les serveurs IRC doivent garder un historique des changements récents de pseudonymes. Cela est nécessaire pour offrir au serveur la possibilité de garder le contact quand une commande concerne un utilisateur changeant de pseudo. Les commandes qui doivent vérifier un changement de pseudo sont :

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

Aucune autre commande ne doit vérifier un changement de pseudo.

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

Dans un gros réseau de serveurs IRC interconnectés, il est assez facile, pour un simple client connecté, d'émettre un flux continu de messages qui résultent non seulement en l'inondation du réseau, mais aussi en la dégradation de la qualité de service fournie aux autres clients. Au lieu de demander à chaque 'victime' de gérer sa propre protection, la protection contre les inondations est incluse dans le serveur et est appliquée à tous les clients, à l'exception des services. L'algorithme actuel est le suivant :

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

Ce qui, en essence, signifie qu'un client ne peut envoyer plus d'un message toutes les deux secondes sans être affecté.

## 8.11 Boucles non bloquantes

Dans un environnement temps réel, il est essentiel qu'un processus serveur attende aussi peu que possible, de manière à ce que tous les clients soient servis justement. Evidement, cela nécessite des ES non bloquantes sur toutes les opérations de lecture/écriture du réseau. Pour les connections de serveur normales, ce n'est pas compliqué, mais il y a des opérations gérées qui peuvent causer un blocage du serveur (telles que les lectures disque). Quand c'est possible, de telles activités doivent être exécutée avec un délai d'attente maximal court.

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

L'utilisation des librairies de résolution standards de Berkeley et autres entraîne de gros délais, dans les cas où les réponses n'arrivent pas. Afin d'éviter cela, un jeu de routines DNS indépendantes ont été écrites, où les opérations DNS ont été écrites avec des E/S non bloquantes et testées depuis la boucle d'E/S principale du serveur.

### 8.11.2 Recherche du nom d'utilisateur (IDENT)

Bien qu'il y ait de nombreuses libraires IDENT à utiliser et inclure dans d'autres programmes, elles posent des problèmes puisqu'elles opèrent de façon synchrone, et résultent en de nombreuses attentes. Encore une fois, la solution a été d'écrire un jeu de routines qui coopèrent avec le reste du serveur, et utilisent des E/S non bloquantes.

## 8.12 Fichier de configuration

Afin de fournir une façon flexible de configurer et de lancer le serveur, il est recommandé qu'un fichier de configuration soit utilisé, qu'il contienne les instructions du serveur suivantes :

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

Lors de la spécification des noms d'hôtes, les noms de domaines et la notation 'point' (127.0.0.1) doivent être tous les deux gérées. Il doit être possible de préciser un mot de passe à utiliser/accepter pour toutes les connections entrantes et sortantes (bien que les connections sortantes soient toutes à destination de serveurs).

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

Un serveur doit utiliser une sorte de 'liste de contrôle d'accès' (soit dans le fichier de configuration ou ailleurs) qu'il lit au démarrage et utilise pour décider quels hôtes les clients peuvent utiliser pour se connecter.

'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

En raison des pouvoirs qui leur sont accordés , le don des privilèges d'opérateurs à une personne turbulente peut avoir des conséquences désastreuses sur le bien-être du réseau IRC en général. C'est pourquoi l'acquisition de ces pouvoirs ne doit pas être facile. La configuration actuelle nécessite deux mots de passes, bien que l'un d'entre eux soit généralement facile à trouver. L'enregistrement des mots de passe d'opérateur dans le fichier de configuration est préférable à leur codage en dur, et ils doivent être sauvegardé dans un format codé (par exemple en utilisant crypt(3) d'Unix) afin de rendre les vols plus difficiles.

### 8.12.3 Autorisation des connections de serveurs

L'interconnexion de serveurs n'est pas une chose triviale : une mauvaise connection peut avoir un gros impact sur l'utilité d'IRC. C'est pourquoi chaque serveur doit avoir une liste des serveurs sur lesquels il peut se connecter, et de ceux qui peuvent se connecter à lui. En aucune manière un serveur ne doit accepter arbitrairement une connection d'hôte en tant en serveur. En plus de la liste des serveurs qui peuvent et qui ne peuvent pas se connecter, le fichier de configuration doit aussi contenir le mot de passe et les autres caractéristiques de ce lien.

### 8.12.4 Admin

Pour fournir des réponses valides et précises à la commande ADMIN (voir section 4.3.7), le serveur doit trouver tous les détails appropriés dans le fichier de configuration.

## 8.13 Appartenance à un canal.

Le serveur actuel autorise tout utilisateur enregistré localement à accéder jusqu'à 10 canaux différents. Il n'y a pas de limites imposées aux utilisateurs non-locaux, si bien que le serveur reste (raisonnablement) cohérent avec les autres serveurs pour ce qui est de l'appartenance à un canal.

# 9. Problèmes actuels

Il y a nombre de problèmes reconnus avec ce protocole, chacun d'entre eux espérant être résolu dans un futur proche lors de sa réécriture. Actuellement, le travail est en cours pour trouver des solutions convenables à ces problèmes.

## 9.1 Localisation

Il est largement reconnu que ce protocole ne gère pas correctement les localisations lorsqu'il est utilisé dans une grande arène. Le problème principal vient de la nécessité qu'ont tous les serveurs de connaître tous les autres serveurs et utilisateurs, et que leurs informations soient mises à jour dès que possible. Il est aussi nécessaire de garder un faible nombre de serveurs, de façon à ce que le chemin entre deux points reste aussi faible que possible, et que l'arbre de distribution contienne des branches aussi grosses que possible.

## 9.2 Identifiants

Le protocole IRC courant a trois types d'identifiants : le pseudonyme, le nom de canal, et le nom de serveur. Chacun de ses trois types a son propre domaine, et aucun doublon n'est autorisé dans ce domaine. Actuellement, il est possible pour un utilisateur de prendre l'identifiant pour n'importe laquelle des trois, ce qui résulte en une collision. Il est largement reconnu que cela nécessite des modifications, et le plan actuel prévoit des noms uniques pour les canaux et les pseudo n'entrent pas en collision, ainsi qu'une solution autorisant un arbre cyclique.

### 9.2.1 Pseudonymes

L'idée de pseudonymes sur IRC est très pratique pour les utilisateurs qui parlent hors des canaux, mais il y a un nombre fini des pseudonymes, et il n'est pas rare de voir plusieurs personne vouloir utiliser le même pseudo. Si un pseudonyme est choisi par deux personnes qui utilisent ce protocole, soit l'une des deux ne réussi pas à l'obtenir, soit toutes les deux sont déconnectées par l'utilisation de KILL (4.6.1).

### 9.2.2 Canaux

La couche de canaux actuelle nécessite que tous les serveurs connaissent tous les canaux, leurs membres, et leurs propriétés. En plus ne pas bien gérer la localisation la question de la confidentialité est aussi concernée. La collision de canaux est gérée de façon inclusive (les deux personnes qui créent le canal sont considérés comme en étant membre) plutôt que de façon exclusive telle que celle utilisée pour résoudre les collisions de pseudonymes.

### 9.2.3 Serveurs

Bien que le nombre de serveurs soit habituellement petit comparé au nombre d'utilisateurs et de canaux, ils doivent aussi être connus globalement, soit chacun séparément, soit caché derrière un masque.

## 9.3 Algorithmes

A certains endroits du code du serveur, il n'a pas été possible d'éviter des algorithmes N^2, comme par exemple dans la vérification de la liste des canaux d'un ensemble de clients.

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é

La sécurité est traitée dans les sections 4.1, 4.1.1, 4.1.3, 5.5, et 7.

# 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

Traduit de l'anglais par JM "Nirgal" Vourgère