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.