RFC IRC : Liste des messages IRC

4. Détails des messages

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

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

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

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

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

4.1 Etablissement de connection

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

4.1.1 Message PASS

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

Réponses numériques :

ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

4.1.2 Message NICK

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

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

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

Réponses numériques :

           ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
           ERR_NICKNAMEINUSE               ERR_NICKCOLLISION

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

4.1.3 Message USER

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

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

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

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

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

4.1.4 Message SERVER

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

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

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

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

Réponses numériques :

           ERR_ALREADYREGISTRED

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

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

4.1.5 Message OPER

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

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

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              RPL_YOUREOPER
           ERR_NOOPERHOST                  ERR_PASSWDMISMATCH

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

4.1.6 Message QUIT

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

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

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

Réponses numériques:

           Aucune.

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

4.1.7 Message SQUIT

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

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

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

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

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

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

Réponses numériques :

           ERR_NOPRIVILEGES                ERR_NOSUCHSERVER

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

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

4.2 Opérations sur les canaux

4.2.1 Le message JOIN

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

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

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

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
           ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
           ERR_CHANNELISFULL               ERR_BADCHANMASK
           ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
           RPL_TOPIC

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

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

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

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

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

:WiZ JOIN #Twilight_zone ; Message JOIN de WiZ

4.2.2 Message PART

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

Réponses numériques:

           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
           ERR_NOTONCHANNEL

PART #twilight_zone ; quitte le canal "#twilight_zone"

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

4.2.3 Message MODE

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

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

4.2.3.1 Les modes des canaux

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

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

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

4.2.3.2 Modes des utilisateurs

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

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

D'autres modes seront disponible plus tard.

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              RPL_CHANNELMODEIS
           ERR_CHANOPRIVSNEEDED            ERR_NOSUCHNICK
           ERR_NOTONCHANNEL                ERR_KEYSET
           RPL_BANLIST                     RPL_ENDOFBANLIST
           ERR_UNKNOWNMODE                 ERR_NOSUCHCHANNEL

           ERR_USERSDONTMATCH              RPL_UMODEIS
           ERR_UMODEUNKNOWNFLAG

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

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

4.2.4 Le message TOPIC

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
           RPL_NOTOPIC                     RPL_TOPIC
           ERR_CHANOPRIVSNEEDED

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

4.2.5 Message NAMES

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

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

Réponses numériques:

           RPL_NAMREPLY                    RPL_ENDOFNAMES

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

4.2.6 Message LIST

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

Réponses numériques :

           ERR_NOSUCHSERVER                RPL_LISTSTART
           RPL_LIST                        RPL_LISTEND

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

4.2.7 Message INVITE

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_NOSUCHNICK
           ERR_NOTONCHANNEL                ERR_USERONCHANNEL
           ERR_CHANOPRIVSNEEDED
           RPL_INVITING                    RPL_AWAY

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

4.2.8 Commande KICK

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

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

Réponses numériques :

           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
           ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
           ERR_NOTONCHANNEL

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

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

4.3 Requêtes et commandes des serveurs

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

4.3.1 Message VERSION

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

Réponses numériques :

           ERR_NOSUCHSERVER                RPL_VERSION

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

4.3.2 Message STATS

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

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

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

Réponses numériques :

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

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

4.3.3 Message LINKS

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

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

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_LINKS                       RPL_ENDOFLINKS

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

4.3.4 Message TIME

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

Réponses numériques :

           ERR_NOSUCHSERVER                RPL_TIME

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

4.3.5 Message CONNECT

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

Réponses numériques :

           ERR_NOSUCHSERVER                ERR_NOPRIVILEGES
           ERR_NEEDMOREPARAMS

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

4.3.6 Message TRACE

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

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

Réponses numériques :

           ERR_NOSUCHSERVER

           RPL_TRACELINK

           RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
           RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
           RPL_TRACEUSER                   RPL_TRACESERVER
           RPL_TRACESERVICE                RPL_TRACENEWTYPE
           RPL_TRACECLASS

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

4.3.7 Commande ADMIN

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

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_ADMINME                     RPL_ADMINLOC1
           RPL_ADMINLOC2                   RPL_ADMINEMAIL

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

4.3.8 Commande INFO

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

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_INFO                        RPL_ENDOFINFO

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

4.4 Envoi de messages

4.4.1 Messages privés

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

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

           ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
           ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
           ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
           ERR_NOSUCHNICK
           RPL_AWAY

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

4.4.2 Notice

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

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

4.5 Requêtes basées sur les utilisateurs

4.5.1 Requête WHO

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

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

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

Réponses numériques :

           ERR_NOSUCHSERVER
           RPL_WHOREPLY                    RPL_ENDOFWHO

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

4.5.2 Requête WHOIS

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

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

Réponses numériques :

           ERR_NOSUCHSERVER                ERR_NONICKNAMEGIVEN
           RPL_WHOISUSER                   RPL_WHOISCHANNELS
           RPL_WHOISCHANNELS               RPL_WHOISSERVER
           RPL_AWAY                        RPL_WHOISOPERATOR
           RPL_WHOISIDLE                   ERR_NOSUCHNICK
           RPL_ENDOFWHOIS

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

4.5.3 WHOWAS

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

Réponses numériques :

           ERR_NONICKNAMEGIVEN             ERR_WASNOSUCHNICK
           RPL_WHOWASUSER                  RPL_WHOISSERVER
           RPL_ENDOFWHOWAS

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

4.6 Messages divers

4.6.1 Message KILL

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

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

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

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

Réponses numériques :

           ERR_NOPRIVILEGES                ERR_NEEDMOREPARAMS
           ERR_NOSUCHNICK                  ERR_CANTKILLSERVER

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

4.6.2 Message PING

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

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

Réponses numériques :

           ERR_NOORIGIN                    ERR_NOSUCHSERVER

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

4.6.3 Message PONG

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

Réponses numériques :

           ERR_NOORIGIN                    ERR_NOSUCHSERVER

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

4.6.4 Message ERROR

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

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

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

Réponses numériques :

           Aucune.

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