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

Table des matieres
1. Introduction
  1.1 Serveurs
  1.2 Clients
    1.2.1 Operateurs
  1.3 Canaux
    1.3.1 Operateurs de canaux
2. Specification IRC
  2.1 Apercu
  2.2 Les jeux de caracteres
  2.3 Messages
    2.3.1 Le format de message en 'pseudo' BNF
  2.4 Reponses numeriques
3. Concepts IRC
  3.1 Communication un a un
  3.2 Un a 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 a tous
    3.3.1 Client a client
    3.3.2 Client a serveur
    3.3.3 Serveur a serveur
4. Details 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 Operations 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 prives
    4.4.2 NOTICE
  4.5 Requêtes basees 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. Reponses
  6.1 Reponses d'erreur
  6.2 Reponses aux commandes
  6.3 Nombres reserves
7. Authentification des clients et serveurs
8. Implementations actuelles
  8.1 Protocole Reseau: 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 a client
  8.6 Etablissement d'une connection serveur/serveur
    8.6.1 Echange des informations d'etat des serveurs a 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 Operateurs
    8.12.3 Autorisation des connections de serveurs
    8.12.4 Admin
  8.13 Appartenance a un canal.
9. Problemes 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 disponibilite
11. Considerations de securite
12. Adresses des auteurs 1. Introduction
Le protocole IRC (Internet Relay Chat) a ete concu pendant de nombreuses annees pour l'usage de conferences en mode texte. Ce document decrit le protocole IRC actuel.

Le protocole IRC a ete developpe sur des systemes utilisant le protocole reseau TCP/IP, bien qu'il n'y ait pas de raison que cela reste la seule sphere dans laquelle il opere.

L'IRC, en lui-même, est un systeme de teleconference qui (grâce a l'utilisation d'un modele client/serveur) et se prête a une execution sur de nombreuses machines, de facon distribuee. Une configuration type comprend un processus unique (le serveur) qui fourni un point d'acces 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 vertebrale de l'IRC. Il fournit un point auquel les clients peuvent se connecter pour parler entre eux, et un point auquel les autres serveurs peuvent se connecter, formant un reseau IRC. La seule configuration de reseau autorisee est celle d'un arbre [voir Fig. 1] où chaque serveur agit comme un noeud central pour la partie du reseau 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.1 Operateurs
Pour permettre de maintenir un niveau d'ordre raisonnable dans un reseau IRC, une categorie de clients speciale (les operateurs) est autorisee a executer des fonctions de maintenance generale sur le reseau. Bien que les pouvoirs donnes aux operateurs peuvent être consideres comme 'dangereux', ils sont neanmoins indispensables. Les operateurs doivent être capable de faire certaines tâches de base, telles que la deconnexion de la reconnection aux serveurs, ce qui est necessaire pour prevenir les problemes a long terme de mauvais routage reseau. Etant donne cette necessite, le protocole decrit ici n'autorise que les operateurs a effectuer ces fonctions. Voir les section 4.1.7 (SQUIT) et 4.3.5 (CONNECT).

Un pouvoir plus controverse des operateurs est la possibilite de retirer par la force un utilisateur connecte au reseau, c'est a dire que les operateurs peuvent clore une connection entre un client et un serveur. La justification a cela est delicate puisque son abus est a la fois destructif et ennuyant. Pour plus de details concernant ce type d'actions, voir la section 4.6.1 (KILL).

1.3 Les canaux
Un canal est un groupe nomme d'un ou plusieurs clients qui recevront tous les messages adresses a ce canal. Les canaux sont crees implicitement quand le premier client y accede, et le canal disparaît lorsque le dernier client le quitte. Tant qu'un canal existe, tous les clients peuvent y acceder en utilisant le nom du canal.

Les noms de canaux sont des chaînes de caracteres (commencant par un caractere '&' ou '#') d'une longueur maximale de 200 caracteres. En dehors du fait que le premier caractere 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 utilisee comme separateur de liste dans le protocole).

Il y a deux types de canaux autorises par ce protocole. L'un est un canal distribue, qui est connu de tous les serveurs connectes au reseau. Ces canaux commencent par un '#'. L'autre type de canal, reconnaissable a leur nom qui commence par un '&', est marque comme n'etant accessible qu'aux clients du serveur où le canal existe. En plus de ces deux types, il existe differents modes de canaux, permettant de modifier leur comportement individuel. Voir la section 4.2.3 (commande MODE) pour avoir plus de details a ce sujet.

Pour creer un nouveau canal, ou pour faire partie d'un canal existant, un utilisateur doit acceder au canal. Si le canal n'existe pas avant l'acces, le canal est cree et l'utilisateur createur devient operateur de canal. Si le canal existait deja au moment de l'acces, l'autorisation ou non d'acces depend du mode du canal. Par exemple, si le canal est en "invites uniquement" (+i), vous ne pourrez joindre le canal que si vous êtes invites. Le protocole specifie qu'un utilisateur peux être membre de plusieurs canaux a la fois, mais une limite de dix (10) canaux est recommandee comme etant amplement suffisante aussi bien pour les utilisateurs novices que pour les experts. Voir la section 8.13 pour plus d'informations a ce sujet.

Si le reseau IRC devient disjoint en raison d'une division entre deux serveurs, le canal, de chaque côte, est compose de ceux des clients qui sont connectes aux serveurs du côte respectif de la division, et disparaissent d'un des côtes de la division. Lorsque la division est soignee, les serveurs se reconnectant se communiquent entre eux qui, d'apres eux, est dans chaque canal, et le mode de ce canal. Si le canal existe des deux cotes, les acces et les modes sont interpretes de facon inclusive pour que les deux côtes de la nouvelle connection soient d'accord sur quels clients sont dans quels canaux et quels modes ont les canaux. 1.3.1 Les operateurs de canaux
Les operateurs de canaux (aussi appeles "chanop") sur un canal donne, sont consideres comme etant proprietaires du "canal". A ce titre, les operateurs de canaux sont dotes de certains pouvoirs qui leur permettent de garder le contrôle et une forme sanite a leur canal. En tant que proprietaire d'un canal, un operateur de canal n'est pas tenu d'avoir de raisons pour agir, bien que si leur action sont generalement antisociales ou abusives, il pourrait être raisonable de demander a un operateur IRC d'intervenir, ou pour les utilisateur de simplement quitter et aller ailleurs pour former leur propre canal.

Les commandes reservees aux operateurs de canaux sont :
KICK - Ejecte un client d'un canal
MODE - Change le mode d'un canal
INVITE - Invite un client dans un canal a acces sur invitation (mode +i)
TOPIC - Change le titre du canal, dans un canal en mode +t

Un operateur de canal est identifie par un symbole '@' devant son pseudonyme a chaque fois qu'il est utilise en association avec le canal (c'est a dire lors des reponses aux commandes NAMES, WHO et WHOIS) 2. La specification IRC
2.1 Apercu
Le protocole decrit ici vaut aussi bien pour les connections des serveurs que pour celles des clients. Neanmoins, il y a plus de restrictions sur les connections des clients (qui sont consideres comme plus douteuses) que les connections des serveurs. 2.2 Les jeux de caracteres
Aucun jeu de caracteres n'est impose. Le protocole est base sur un jeu de caractere de huit (8) bits, qui forment un octet ; cependant, certains codes sont utilises en tant que codes de contrôle, et agissent comme delimiteurs de messages.

Independamment du fait qu'il s'agisse d'un protocole 8 bits, les delimiteurs et les mots-cles sont tels que le protocole est utilisable d'un terminal USASCII et d'une connection telnet.

Etant donnee l'origine scandinave de l'IRC, les caracteres {}| sont consideres comme etant respectivement les equivalent en minuscules des caracteres []\. Ceci est particulierement important pour determiner l'equivalence de deux pseudonymes. 2.3 Messages
Les serveurs et les clients s'envoient chacun des messages qui peuvent ou non generer une reponse. Si le message contient une commande valide, comme il est decrit dans les sections suivantes, le client devrait s'attendre a une reponse comme specifie, mais il n'est pas conseille d'attendre eternellement une reponse. La communication de client a serveur, et de serveur a serveur est essentiellement de nature asynchrone.

Chaque message IRC peut contenir jusqu'a trois parties : le prefixe (optionnel), la commande, et les parametre de la commande (il peut y en avoir jusqu'a 15). Le prefixe, la commande, et tous les parametres sont separes par un (ou plusieurs) caractere(s) ASCII espace (0x20).

La presence d'un prefixe est indiquee par un simple caractere ASCII deux-points (':', 0x3b), qui doit être le premier caractere du message. Il ne doit pas y avoir de trou (d'espace blanc) entre les deux-points et le prefixe. Le prefixe est utilise pour indiquer la veritable origine du message. S'il n'y a pas de prefixe, le message est considere comme ayant pour origine la connection de laquelle il est issu. Les clients ne doivent pas utiliser de prefixe lorsqu'ils envoient un message d'eux-mêmes. S'il utilise un prefixe, le seul valable est le pseudonyme associe au client. Si la source identifiee par le prefixe n'est pas trouvee dans la base de donnee interne du serveur, ou si la source est enregistree avec une liaison differente de celle avec laquelle le message est arrive, 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 representes en texte ASCII.

Les messages IRC sont toujours des lignes de caracteres termines par une paire CR-LF (retour chariot - saut de ligne), et ces messages ne doivent pas depasser 512 caracteres de long, en comptant tous les caracteres y compris le CR-LF final. C'est-a-dire, qu'il y a un maximum de 510 caracteres pour la commande et ses parametres. Il n'y a pas de systeme permettant une ligne de continuation de message. Voir la section 7 pour les implementations 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 a designer deux caracteres donnes, CR et LF, comme separateurs de messages. Les messages vides sont ignores en silence, ce qui permet l'usage d'une suite de CR-LF entre les messages sans problemes supplementaires.

Le message extrait est decompose en un <prefixe>, <commande> et liste de parametres correspondant soit au composant <milieu> ou <fin>.

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

<milieu> ::= <Toute sequence non vide d'octets a l'exclusion de ESPACE, NUL, CR, LF, le premier d'entre eux etant different de ':'>
<fin> ::= <Toute suite, eventuellement vide, d'octets, a l'exception de NUL, CR et LF >
<crlf> ::= CR LF

NOTES:
1) <espace> est constitue uniquement de caractere(s) ESPACE (0x20). Notez particulierement que la TABULATION et tout autre caractere de contrôle sont consideres comme ESPACE-NON-BLANC.

2) Apres avoir extrait la liste de parametre, tous les parametres sont egaux, et correspondent soit a <milieu> soit a <fin>. <Fin> est une simple astuce syntaxique pour autoriser ESPACE dans le parametre.

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

4) Le caractere NUL n'est pas special dans la construction du message, et pourrait a priori être a l'interieur d'un message, mais cela complexifierait la gestion ordinaire des chaînes en C. C'est pourquoi NUL n'est pas autorise dans les messages.

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

6) L'utilisation d'un prefixe etendu ([ '!' <utilisateur> ] [ '@' <hôte> ]) ne doit pas être utilise dans la communication entre serveurs, et est destine uniquement a la communication serveur vers client, dans le but de fournir au client des informations utiles a propos de l'origine du message sans necessiter de requêtes supplementaires.

La plupart des messages du protocole specifient une semantique additionnelle, et la syntaxe pour les chaînes de parametres extraites est dictee par leur position dans la liste. Par exemple, de nombreuses commandes de serveurs vont considerer que le premier parametre apres la commande est la liste de destinataires, ce qui peut être decrit avec :
<destinataire> ::= <a> [ "," < destinataire > ]
<a> ::= <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 details sur les noms d'hôte autorises
<pseudo> ::= <lettre> { <lettre> | <nombre> | <special> }
<masque> ::= ('#' | '$') <chaîne canal>
<chaîne canal> ::= <n'importe quel code 8bits excepte ESPACE, BELL, NUL, CR, LF et virgule (,)>

Les autres parametres sont :
<utilisateur> ::= <non blanc> { < non blanc > }
<lettre> ::= 'a' ... 'z' | 'A' ... 'Z'
<nombre> ::= '0' ... '9'
<special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'

< non blanc > ::= < n'importe quel code 8bits excepte ESPACE (0x20), NUL(0x0), CR(0xd), et LF(0xa) >
2.4 Reponses numeriques
La plupart des messages envoyes aux serveurs genere une reponse. Les reponses les plus courantes sont des reponses numeriques, aussi bien pour les messages d'erreurs que pour les reponses normales. La reponse numerique est envoye comme un message contenant le prefixe de l'expediteur, le nombre de trois chiffres, et le destinataire de la reponse. Une reponse numerique ne peut pas emaner d'un client, et tout message de ce style recu par un serveur doit être ignore silencieusement. Hormis cela, une reponse numerique est un message comme un autre, si ce n'est que le mot-cle est compose de trois chiffres, plutôt que d'une suite de lettre. Une liste des reponses possible est fournie a la section 6. 3. Concepts IRC
Cette section decrit les concepts sous-jacents a l'organisation du protocole IRC et comment les implementations actuelles delivrent les differentes 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 reseau IRC ]

Les exemples suivants se referent tous a 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 autorise a 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.

Les exemples suivants se referent tous a 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 etaient des messages prives entre les deux clients en dehors du canal.

Exemple 6 :

Les clients 1, 2 et 3 sont dans un canal. Tous les messages adresses a un canal sont envoyes a tous les clients, et a ceux des serveurs qui serraient traverse par le message s'il etait un message prive entre deux clients. Si le client 1 envoie un message, il est envoye au client 2, et par le serveur B, au client 3.<

Pour certains messages, il est necessaire de les diffuser a tous les serveurs, de facon a ce que les informations de statut de chaque serveur soient raisonnablement identiques entre tous les serveurs. 3.3.1 Client a client
Il n'y a pas de classe de message qui, a partir d'un simple message, resulte en un message envoye a tous les autres clients. 3.3.2 Client a serveur
La plupart des commandes qui resultent en un changement d'etat (tels que l'appartenance a un canal, le mode d'un canal, le statut d'un utilisateur, etc.) doivent être, par defaut, envoyes a tous les serveurs, et cet envoi ne peut pas être altere par le client. 3.3.3 Serveur a serveur
Bien que la plupart des messages entre les serveurs soient distribues a 'tous' les autres serveurs, cela n'est necessaire que pour les messages qui affectent soit un utilisateur, soit un canal, soit un serveur. Etant donne que cela constitue l'essentiel des elements de l'IRC, la quasi-totalite des messages issus d'un serveur est diffusee a tous les autres serveurs connectes. 4. Details des messages
Les pages suivantes decrivent les messages reconnus par les serveurs IRC et les clients. Toutes les commandes decrites dans cette section doivent être implementees par tous les serveurs utilisant ce protocole.

Si la reponse est ERR_NOSUCHSERVER est recue, cela signifie que le parametre <serveur> n'a pas ete trouve. Le serveur ne doit alors plus envoyer d'autres reponses pour cette commande.

Le serveur auquel un client est connecte doit traiter le message complet, et retourner les messages d'erreur appropries. Si le serveur rencontre une erreur fatale en decomposant un message, une erreur doit être envoye au client et la decomposition interrompue. Peut être considere comme une erreur fatale une commande incorrecte, une destination inconnue du serveur (noms de serveur, pseudo, et noms de canaux entrent dans cette categorie), un nombre de parametres insuffisant, ou un niveau de privilege insuffisant.

Si un jeu de parametres complet est present, la validite de chacun d'entre eux doit être verifiee, et les reponses appropriees envoyees au client. Dans le cas de messages dont la liste de parametres utilise une virgule comme separateur, une reponse doit être envoyee a chaque element.

Dans les exemples suivants, certains messages apparaissent au format complet :
:Nom COMMANDE parametre liste

Ces exemples representent un message de "Nom" dans le transfert entre serveurs, où il est essentiel d'inclure le nom de l'expediteur originel du message, de facon a ce que les serveurs distants puissent renvoyer un message le long d'un chemin valide. 4.1 Etablissement de connection
Les commandes decrites dans cette section sont utilisees pour etablir une connection avec un serveur IRC, aussi bien par un client que par un serveur, ainsi qu'une deconnexion correcte.

Une commande "PASS" n'est pas necessaire pour etablir une connection, mais elle doit preceder la combinaison suivante des messages NICK/USER. Il est fortement recommande que toutes les connections de serveurs utilisent un mot de passe afin de donner un niveau de securite satisfaisant aux connections. L'ordre des commandes recommande 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
Parametres : <mot de passe>

La commande PASS est utilisee pour definir le 'mot de passe de connection'. Le mot de passe peut et doit être defini 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 a 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 derniere est utilisee pour la verification, et elle ne peut plus changer une fois la connection etablie.

Reponses numeriques :

ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

Le message NICK est utilise pour donner un pseudonyme a un utilisateur, ou pour changer le pseudonyme precedent. Le parametre <compteur de distance> n'est utilise que par les serveurs, et sert a indiquer quelle est la distance entre un utilisateur et son serveur local. Une connection locale a un compter de distance de zero. Si un client fourni un compteur de distance, il doit être ignore.

Si un message NICK arrive a un serveur qui connaît deja un autre client de pseudo identique, une collision de pseudonymes a lieu. Le resultat 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 donnees de tous les autres serveurs. Si le message NICK a l'origine de la collision de pseudonymes est un changement de pseudonyme, alors le pseudo originel (l'ancien) doit aussi être retire.

Si le serveur recoit un NICK identique d'un client auquel il est connecte directement, il peut envoyer un ERR_NICKCOLLISION au client local, ignorer la commande NICK, et ne pas generer de KILLs.

Reponses numeriques :

      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.

Le message USER est utilise au debut d'une connection pour specifier le nom d'utilisateur, le nom d'hôte, le nom de serveur, et le veritable nom d'un nouvel utilisateur. Il est aussi utilise lors de la communication entre les serveurs pour indiquer l'arrive d'un nouvel utilisateur sur IRC, puisque c'est seulement apres avoir envoye et le USER et le NICK qu'un utilisateur devient enregistre.

Entre serveurs, USER doit être prefixe du pseudonyme du client. Notez que le nom d'hôte et le nom de serveur sont generalement ignores par le serveur IRC quand la commande USER vient directement d'un client (pour des raisons de securite), mais sont utilises dans la communication de serveur a serveur. Cela signifie que NICK doit toujours être envoye a un serveur distant quand un nouvel utilisateur est ajoute au reste du reseau, avant que le USER correspondant soit envoye.

Notez aussi que le parametre 'vrai nom' doit être le dernier parametre, car il peut contenir des espaces, et il doit être prefixe par deux points (':') de facon a ê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 recommande d'utiliser un "serveur d'identite". Si l'hôte dont l'utilisateur se connecte a un serveur de ce type active, le nom d'utilisateur est defini par la reponse de ce "serveur d'identite".

Reponses numeriques :

      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 a qui appartient la commande USER.

Le message SERVER est utilise pour dire a un serveur que l'autre bout de la connection est un autre serveur. Ce message est aussi utilise pour transmettre les donnees du serveur a tout le reseau. Quand un nouveau serveur se connecte au reseau, les informations le concernant sont diffusees a tout le reseau. <Compteur de distance> est utilise pour donner a chaque serveur des informations sur leurs distances aux differents serveurs. Avec la liste complete des serveurs, il serrait possible de construire une carte complete de l'arbre des serveurs, mais les masques d'hôtes l'empêchent.

Le message SERVER doit être accepte uniquement (a) soit d'une connection qui n'est pas encore enregistree 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 dela de ce serveur.

La plupart des erreurs qui ont lieu a la reception d'une commande SERVER resulte en la coupure de la connection avec l'hôte destinataire (serveur destinataire). Les reponses d'erreur sont generalement envoyees en utilisant la commande "ERROR" plutôt qu'une reponse numerique, car la commande ERROR a plusieurs proprietes qui la rendent utile dans ce cas.

Si un message SERVER est traite et tente d'introduire un serveur deja connu du serveur receveur, la connection avec ce serveur doit être coupe (en suivant les procedures correctes), car une route dupliquee s'est formee avec un serveur, et la nature acyclique de l'arbre IRC rompue.

Reponses numeriques :

         ERR_ALREADYREGISTRED

SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
; Le nouveau serveur test.oulu.fi se presente 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 a 5 noeuds de nous.

Le message OPER est utilise par un utilisateur normal pour obtenir le privilege d'operateur. La combinaison de <utilisateur> et <mot de passe> est necessaire pour obtenir le privilege Operateur.

Si le client envoyant la commande OPER fourni un mot de passe correct pour l'utilisateur donne, le serveur informe le reste du reseau du nouvel operateur en envoyant un "MODE +o" pour le pseudonyme.

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

Reponses numeriques :

       ERR_NEEDMOREPARAMS              RPL_YOUREOPER
       ERR_NOOPERHOST                  ERR_PASSWDMISMATCH

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

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 depart> est fourni, il sera transmi au lieu du message par defaut, le pseudonyme.

Lorsqu'une division reseau a lieu (deconnexion de deux serveurs), le message de depart est compose du nom des deux serveurs en cause, separes par un espace. Le premier nom est celui du serveur toujours connecte, et le second, celui qui est desormais inaccessible.

Si pour une autre raison, une connection d'un client est fermee sans que le client ait envoye de message QUIT (par exemple, le programme client se termine, et une fin de fichier est envoyee sure la socket), le serveur doit remplir le message QUIT avec un message refletant la nature de l'evenement a la cause de cette deconnexion.

Reponses numeriques:

        Aucune.

QUIT :Parti dejeuner ; Format de message prefere.

Le message SQUIT est necessaire pour signaler le depart ou la mort de serveurs. Si un serveur souhaite rompre une connection a un autre serveur, il doit envoyer un message SQUIT a ce serveur, en utilisant le nom de ce serveur comme parametre <serveur>, ce qui clos la connection avec le serveur quittant le reseau.

Cette commande est aussi accessible aux operateurs pour garder un reseau de serveurs IRC connectes proprement. Les operateurs peuvent egalement emettre un message SQUIT pour une connection distante d'un serveur. Dans ce cas, le message SQUIT doit être traite par tous les serveurs entre l'operateur et le serveur distant, tout en mettant a jour la vue du reseau de chaque serveur comme decrit plus loin.

Le <commentaire> doit être present pour tout operateur qui execute un SQUIT sur un serveur distant (qui n'est pas connecte au serveur sur lequel ils sont actuellement). Le <commentaire> est egalement 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 coupee doivent envoyer un message SQUIT (a tous les serveurs auxquels ils sont connectes) pour tous les serveurs qui sont situes au-dela de ce lien.

De même, un message QUIT doit être envoye aux autres serveur du reste du reseau de la part de tous les clients au-dela de ce lien. De plus, tous les membres d'un canal qui perdent un membre a cause d'une division reseau doivent recevoir un message QUIT.

Si une connection a un serveur est terminee prematurement, (par exemple si le serveur a l'extremite de la liaison meurt), le serveur qui detecte cette deconnexion doit informer le reste du reseau que cette connection est fermee, et remplir le champ <commentaire> de facon appropriee.

Reponses numeriques :

          ERR_NOPRIVILEGES                ERR_NOSUCHSERVER

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

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

La commande JOIN est utilisee par un client pour commencer a ecouter un canal specifique. L'acces a un canal est autorise ou non uniquement par le serveur auquel le client est connecte ; 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 invite si le canal est en mode "sur invitation seulement"
2. Le pseudo/nom d'utilisateur/nom d'hôte ne doit pas correspondre a un bannissement actif.
3. La bonne cle (mot de passe) doit être fournie si elle est definie.

Ceci est discute plus en details dans la description de la commande MODE (voir la section 4.2.3 pour plus de details).

Une fois qu'un utilisateur a acces a un canal, ils recoivent des notifications sur toutes les commandes que leur serveur recoit qui affectent le canal. Cela inclut MODE, KICK, PART, QUIT, et bien sûr PRIVMSG/NOTICE. La commande JOIN doit être diffusee a tous les serveurs du reseau 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 succes, on envoie a 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.

Reponses numeriques :

    ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
    ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
    ERR_CHANNELISFULL               ERR_BADCHANMASK
    ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
    RPL_TOPIC

JOIN #foobar ; accede au canal #foobar.

JOIN &foo fubar ; accede au canal &foo en utilisant la cle "fubar".

JOIN #foo,&bar fubar ; accede au canal #foo en utilisant la cle "fubar", et &bar en n'utilisant pas de cle.

JOIN #foo,#bar fubar,foobar ; accede au canal #foo en utilisant la cle "fubar", et au canal #bar en utilisant la cle "foobar".

JOIN #foo,#bar ; accede au canaux #foo and #bar.

:WiZ JOIN #Twilight_zone ; Message JOIN de WiZ

Le message PART provoque le retrait du client expediteur de la liste des utilisateurs actifs pour tous les canaux liste dans la chaîne de parametre.

Reponses numeriques:

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

La commande MODE est une commande a utilisation duale sur IRC. Elle permet aussi bien de changer les modes des utilisateurs que ceux des canaux. La raison a ce choix est qu'un jour les pseudonymes deviendront obsoletes et la propriete equivalente sera le canal.

Lors du traitement des messages MODE, il est recommande de commencer par decomposer le message en entier, puis de realiser les modifications resultantes.

4.2.3.1 Les modes des canaux

La commande MODE permet aux operateurs de canaux de changer les caracteristiques de 'leur' canal. Les serveurs doivent aussi pouvoir changer les modes du canal, de facon a pouvoir creer des operateurs.

Les modes disponibles pour les canaux sont les suivants :
o - donne/retire les privileges d'operateur de canal
p - drapeau de canal prive
s - drapeau de canal secret
i - drapeau de canal accessible uniquement sur invitation
t - drapeau de sujet de canal modifiable uniquement par les operateurs
n - pas de messages dans un canal provenant de clients a l'exterieur du canal
m - canal modere
l - definit le nombre maximal de personnes dans un canal
b - defini un masque de bannissement pour interdire l'acces a des utilisateurs
v - donne/retire la possibilite de parler dans un canal modere
k - defini la cle du canal (mot de passe)

Lors de l'utilisation des options 'o' et 'b', le nombre de parametres est restreint a 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 facon dont le client est vu par les autres, ou quels types de messages sont recus. Une commande MODE n'est acceptee que si l'expediteur du message et le pseudonyme donne en parametres 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 recoit les WALLOPs ;
o - drapeau d'operateur.

D'autres modes seront disponible plus tard.

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

Reponses numeriques :

    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 modere et 'uniquement sur invitation'.
MODE #Finnish +o Kilroy ; Donne le privilege de 'chanop' a Kilroy sur le canal #Finnish.
MODE #Finnish +v Wiz ; Autorise WiZ a parler sur #Finnish.
MODE #Fins -s ; Annule le drapeau 'secret' du canal #Fins.
MODE #42 +k oulu ; Defini la cle comme "oulu".
MODE #eu-opers +l 10 ; Defini le nombre maximal d'utilisateur dans le canal a 10.
MODE &oulu +b ; Liste les masques de bannissements du canal.
MODE &oulu +b *!*@* ; Interdit a quiconque de venir sur le canal.
MODE &oulu +b *!*@*.edu ; Interdit a tout utilisateur dont le nom d'hôte correspond a *.edu d'acceder au canal.

Utilisation des modes d'utilisateur :
:MODE WiZ -w ; supprime la reception 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'operateur). Le contraire de ca ("MODE WiZ +o") ne doit pas être autorise car cela court-circuiterait la commande OPER.

Le message TOPIC est utilise pour modifier ou voir le sujet d'un canal. Le sujet du canal <canal> est renvoye s'il n'y a pas de <sujet> fourni en parametre. Si le parametre <sujet> est present, le sujet du canal changera si le mode du canal le permet.

Reponses numeriques :

     ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
     RPL_NOTOPIC                     RPL_TOPIC
     ERR_CHANOPRIVSNEEDED

:Wiz TOPIC #test :New topic ;L'utilisateur Wiz defini le sujet.
TOPIC #test :another topic ;Change le sujet du canal #test en "another topic".
TOPIC #test ; Verifie le sujet de #test.

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 prives (+p), ni secrets (+s), ou ceux sur lesquels il est actuellement. Le parametre <canal> specifie 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 parametre <canal> n'est pas donne, la liste de tous les canaux et de leurs occupants est renvoyee. A la fin de cette liste, sont listes les utilisateurs qui sont visibles, mais qui n'appartiennent a aucun canal. Ils sont listes comme appartenant au canal `channel' "*".

Reponses numeriques:

      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.

Le message liste est utilise pour lister les canaux et leur sujet. Si le parametre <canal> est utilise, seul le statut de ces canaux est affiche. Les canaux prives sont listes (sans leur sujet) comme canal "Prv" a moins que le client qui fasse la requête soit effectivement sur le canal. De même, les canaux secrets ne sont pas liste du tout, a moins que le client soit un membre du canal en question.

Reponses numeriques :

     ERR_NOSUCHSERVER                RPL_LISTSTART
     RPL_LIST                        RPL_LISTEND

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

Le message INVITE est utilise pour inviter des utilisateurs dans un canal. Le parametre <pseudonyme> est le pseudonyme de la personne a inviter dans le canal destination <canal>. Il n'est pas necessaire que le canal dans lequel la personne est invitee 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 operateur sur le canal designe.

Reponses numeriques :

    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

La commande KICK est utilisee pour retirer par la force un utilisateur d'un canal (PART force).

Seul un operateur de canal peut kicker un autre utilisateur hors d'un canal. Tout serveur qui recoit un message KICK verifie si le message est valide (c'est-a-dire si l'expediteur est bien un operateur du canal) avant d'ôter la victime du canal.

Reponses numeriques :

    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 specifiant "Speaking English" comme raison (commentaire).
:WiZ KICK #Finnish John ; Message KICK de WiZ pour retirer John du canal #Finnish

NOTE:

Il est possible d'etendre les parametres 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 a obtenir des informations au sujet de tout serveur connecte au reseau. Tous les serveurs connectes doivent repondre a ces requêtes et repondre correctement. Toute reponse invalide (ou l'absence de reponse) doit être considere comme un signe de serveur casse, et il doit se deconnecter / se desactiver au plus tôt, jusqu'a ce que le probleme soit resolu.

Dans ces requêtes, lorsqu'il y a un parametre "<serveur>", cela designe generalement un pseudonyme, un serveur, ou un joker quelconque. Par contre, chaque parametre ne doit generer qu'une seule requête et un jeu de reponses. 4.3.1 Message VERSION
Commande: VERSION
Parametres: [<serveur>]

Le message VERSION est utilise pour determiner la version du programme serveur. Un parametre optionnel <serveur> est utilise pour obtenir la version d'un programme serveur sur lequel un client n'est pas connecte directement.

Reponses numeriques :

     ERR_NOSUCHSERVER                RPL_VERSION

:Wiz VERSION *.se ; message de Wiz pour verifier la version d'un serveur correspondant a "*.se"
VERSION tolsun.oulu.fi ; verifie la version du serveur "tolsun.oulu.fi".

Le message STATS est utilise pour obtenir les statistiques d'un serveur. Si le parametre <serveur> est omis, seule la fin de la reponse STATS est renvoyee. L'implementation de cette requête depend enormement du serveur qui repond. Neanmoins, le serveur doit être capable de fournir les informations decrites dans les requêtes ci-dessous (ou equivalent).

Une requête peut être lancee par une unique lettre, qui est verifiee uniquement par le serveur destination (si le parametre <serveur> est present). Elle est transmise aux serveurs intermediaires, ignoree et inalteree. Les requêtes suivantes sont celles trouvees dans les implementations courantes d'IRC, et fournissent une grande partie des informations de configuration du serveur. Bien qu'elles ne soient pas necessairement gerees de la même facon par d'autres versions, tous les serveurs devraient être capable de fournir une reponse valide a la requête STATS, qui soit compatible avec les formats de reponse actuellement utilisees et le but de ces requêtes.

Les requêtes actuellement gerees sont :
c - renvoie la liste des serveurs qui peuvent se connecter, ou dont les connections sont acceptees ;
h - renvoie la liste des serveurs qui sont forces 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 gerees 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 operateur ;
y - montre les lignes Y (Classe) du fichier de configuration du serveur ;
u - renvoie une chaîne decrivant depuis combien de temps le serveur fonctionne.

Reponses numeriques :

     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 ; verifie l'utilisation des commandes pour le serveur sur lequel vous êtes connecte.
:Wiz STATS c eff.org ; requête de WiZ pour information sur les ligne C/N du serveur eff.org

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 complete des serveurs est renvoyee.

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

Reponses numeriques :

     ERR_NOSUCHSERVER
     RPL_LINKS                       RPL_ENDOFLINKS

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

Le message TIME est utilise pour obtenir l'heure locale d'un serveur donne. En absence de parametre <serveur>, le serveur recevant le message doit repondre a la requête.

Reponses numeriques :

           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 a un serveur correspondant a "*.au"

Le message CONNECT est utilise pour forcer un serveur a essayer d'etablir immediatement une nouvelle connection a un autre serveur. CONNECT est une commande privilegiee et n'est accessible qu'aux operateurs IRC. Si un serveur distant est precise, alors ce serveur tente de se connecter au <serveur distant>, sur le <port> donne.

Reponses numeriques :

    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.

La commande TRACE est utilisee pour trouver une route vers un serveur donne. Chaque serveur qui traite ce message doit repondre a l'expediteur en indiquant qu'il est un lien sur le chemin d'acheminement, formant ainsi une chaîne de reponse similaire a celle obtenue par un "traceroute". Apres avoir renvoye sa reponse, il doit ensuite envoyer le message TRACE au serveur suivant, et ce jusqu'a ce que le serveur specifie soit atteint. Si le parametre <serveur> est omis, il est recommande que la commande trace envoie un message a l'expediteur lui disant a quels serveurs il est directement connecte.

Si la destination specifiee par <serveur> est en fait un serveur, alors le serveur destinataire doit lister tous les serveurs et les utilisateurs qui y sont connectes. Si la destination specifiee par <serveur> est en fait un pseudonyme, seule la reponse pour ce pseudonyme est donnee.

Reponses numeriques :

      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 a *.oulu.fi
:WiZ TRACE AngelDust ; TRACE de WiZ vers le pseudo AngelDust

Le message ADMIN est utilise pour trouver le nom de l'administrateur d'un serveur donne, ou du serveur courant si le parametre <serveur> est omis. Tout serveur doit posseder la possibilite de propager les messages ADMIN aux autres serveurs.

Reponses numeriques :

    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 trouve qui correspond a *.edu.

La commande INFO doit retourner une information qui decrit le serveur : sa version, quand il a ete compile, le numero de mise a jour, quand il a ete demarre, et toute autre information consideree comme pertinente.

Reponses numeriques :

    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 a destination du premier serveur trouve qui correspond a *.fi.
INFO Angel ; requête INFO a destination du serveur sur lequel est connecte Angel.

PRIVMSG est utilise pour envoyer un message prive entre des utilisateurs. <destinataire> est le pseudonyme du destinataire du message. <destinataire> peut aussi être une liste de nom ou de canaux, separes pas des virgules.

Le parametre <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 apres le dernier ".". Cette limitation a pour but d'empêcher les gens d'envoyer des messages a "#*" ou a "$*", ce qui provoquerait la diffusion a tous les utilisateurs ; l'experience montre qu'on en abuse plus qu'on en use intelligemment, de facon responsable. Les jokers sont les caracteres '*' et '?'. Ces extensions de PRIVMSG ne sont accessibles qu'aux operateurs. Reponses Numeriques:

    ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
    ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
    ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
    ERR_NOSUCHNICK
    RPL_AWAY

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

Le message NOTICE s'utilise de la même facon que PRIVMSG. La difference entre NOTICE et PRIVMSG est qu'aucune reponse automatique de doit être envoyee en reponse a un message NOTICE. Ceci est aussi valable pour les serveurs - ils ne doivent pas renvoyer de message d'erreur a la reception d'un message NOTICE. Le but de cette regle est d'eviter les boucles entre les clients qui enverraient automatiquement quelque chose en reponse a une requête. Cela est typiquement utilise par des automates (des clients qui ont une intelligence artificielle ou un autre programme interactif contrôlant leurs actions) qui repondent systematiquement aux reponses d'autres automates.

Voir PRIVMSG pour les details sur les reponses, et pour les exemples. 4.5 Requêtes basees 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 visibilite d'un utilisateur est determinee 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
Parametres: [<nom> [<o>]]

Le message WHO est utilise par un client pour generer une requête qui renvoie une liste d'informations qui correspondent au parametre <nom> donne par le client. Si le parametre nom est absent, tous les utilisateurs visibles sont listes (ceux qui ne sont pas invisibles (mode utilisateur +i) et qu'ont pas un canal en commun avec le client emettant la requête. Le même resultat peut être obtenu en utilisant le <nom> "0" ou tout joker correspond a toutes les entrees possibles.

Le <nom> passe en parametre est mis en correspondance avec les hôtes des utilisateurs, leurs veritables noms, et leurs pseudonymes si le canal <nom> n'est pas trouve.

Si le parametre "o" est passe, seuls les operateurs sont listes, et ce, en fonction du masque fourni.

Reponses numeriques :

    ERR_NOSUCHSERVER
    RPL_WHOREPLY                    RPL_ENDOFWHO

WHO *.fi ; Liste tous les utilisateurs qui correspondent a "*.fi".
WHO jto* o ; Liste tous les utilisateurs qui correspondent a "jto*", s'ils sont operateurs.

Ce message est utilise pour obtenir des informations sur un utilisateur donne. Le serveur repondra a ce message avec des messages numeriques indiquant les differents 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 acces au sujet de ce pseudo seront presentees. On peut separer la liste des pseudonymes avec une virgule (',').

La derniere version envoie une requête a un serveur specifique. C'est utile si vous voulez savoir depuis combien de temps l'utilisateur concerne a ete oisif, car seul le serveur local (celui auquel cet utilisateur est directement connecte) connaît cette information, alors que tout le reste est connu par tous les serveurs.

Reponses numeriques :

    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

WHOWAS permet de demander des informations concernant un utilisateur qui n'existe plus. Cela peut être dû a un changement de pseudonyme ou au fait que l'utilisateur ait quitte l'IRC. En reponse a cette requête, le serveur cherche un pseudo correspondant dans l'historique des pseudonymes (sans utiliser de jokers). L'historique est parcouru a l'envers, de facon a renvoyer l'entree la plus recente en premier. S'il y a plusieurs entrees, jusqu'a <compte> entrees seront retournees (ou toutes si le parametre <compte> n'est pas donne). Si le nombre passe n'est pas positif, une recherche complete a lieu.

Reponses numeriques :

     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 entrees les plus recentes dans l'historiques des pseudos pour "Mermaid";
WHOWAS Trillian 1 *.edu ; demande l'entree la plus recente pour "Trillian" au premier serveur trouve qui correspond a "*.edu".

Le message KILL est utilise pour provoquer la fermeture de la connection client/serveur par le serveur qui gere cette connection. KILL est aussi utilise par les serveurs qui rencontrent un doublon dans la liste des entrees de pseudonymes valides, afin de retirer les deux entrees. Elle est egalement accessible aux operateurs.

Les clients qui ont des reconnections automatiques rendent cette commande inefficace, car la deconnexion est breve. Cela permet tout de même d'interrompre un flux de donnees et est utile pour arrêter un flux abusif (trop important). Tout utilisateur peut demander a recevoir les messages KILL generes pour d'autres clients afin de garder un oeil sur les fauteurs de trouble eventuels.

Dans une arene où les pseudonymes doivent être globalement uniques, les messages KILL sont envoyes a chaque fois qu'un doublon est detecte (c'est-a-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 reapparaîtra.

Le commentaire doit refleter la veritable raison du KILL. Pour les messages issus de serveurs, cela est habituellement constitue des details concernant les origines des deux pseudonymes en conflit. Les utilisateurs, eux, sont libres de fournir une raison adequate, de facon a satisfaire ceux qui le voient. Afin de prevenir/d'eviter des KILL maquilles pour cacher l'identite de l'auteur d'être generes, le commentaire contient egalement un 'chemin de KILL' qui est mis a jour par tous les serveurs par lequel il passe, chacun ajoutant son nom au chemin.

Reponses numeriques :

    ERR_NOPRIVILEGES                ERR_NEEDMOREPARAMS
    ERR_NOSUCHNICK                  ERR_CANTKILLSERVER

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

NOTE:
Il est recommande que seuls les operateurs soient autorises a deconnecter d'autres utilisateurs avec un message KILL. Dans un monde parfait, même les operateurs ne devraient avoir besoin de cette commande, et les serveurs pourraient être laisses seul a resoudre ces problemes. 4.6.2 Message PING
Commande: PING
Parametres: <serveur1> [<serveur2>]

Le message PING est utilise pour tester la presence d'un client actif a l'autre bout de la connection. Un message PING est envoye regulierement si aucune activite n'est detectee sur une connection. Si la connection ne repond pas a la commande PING dans un certain delai, la connection est fermee.

Tout client qui recoit un message PING doit repondre au <serveur1> (serveur qui a envoye le message PING) aussi rapidement que possible, avec un message PONG approprie pour indiquer qu'il est toujours la et actif. Les serveurs ne doivent pas repondre aux commandes PING, mais se fier au PING dans l'autre sens pour indiquer que la connection est toujours active. Si le parametre <serveur2> est specifie, le message PING y est transmis.

Reponses numeriques :

    ERR_NOORIGIN                    ERR_NOSUCHSERVER

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

Le message PONG est la reponse a un message PING. Si le parametre <demon2> est donne, le message doit être transmis au demon donne. Le parametre <demon> est le nom du demon responsable du message PING genere.

Reponses numeriques :

    ERR_NOORIGIN                    ERR_NOSUCHSERVER

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

La commande ERROR est utilisee par les serveurs pour rapporter une erreur serieuse ou fatale a ses operateurs. Elle peut aussi être envoyee d'un serveur a un autre, mais ne doit pas être accepte de simples clients inconnus.

Un message ERROR ne doit être utilise que pour annoncer les erreurs qui ont lieu sur un lien serveur/serveur. Un message ERROR est envoye au serveur associe (qui le transmet a tous ses operateurs connectes) et a tous les operateurs connectes. Il ne doit pas être transmis aux autres serveurs s'il est recu d'un serveur.

Quand un serveur transmet un message ERROR a ses operateurs, le message doit être encapsule dans un message NOTICE, en indiquant que le client n'est pas responsable de l'erreur.

Reponses numeriques :

           Aucune.

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

Avec le message AWAY, les clients peuvent definir une chaîne de reponse automatique pour toute commande PRIVMSG qui leur est destinee (et non pas a un canal sur lequel ils sont). La reponse est envoyee directement par le serveur au client envoyant une commande PRIVMSG. Le seul serveur a repondre est celui sur lequel le client emetteur est situe.

Le message AWAY est utilise soit avec un parametre (pour definir un message AWAY) ou sans (pour retirer le message AWAY).

Reponses numeriques :

    RPL_UNAWAY                      RPL_NOWAWAY

AWAY :Parti dejeuner. De retour a 2 heures. ; defini le message d'absence en " Parti dejeuner. De retour a 2 heures.".
:WiZ AWAY ; supprime l'absence de WiZ.

Le massage REHASH est utilise par les operateurs pour forcer un serveur a relire et traiter son fichier de configuration.

Reponses numeriques :

     RPL_REHASHING                   ERR_NOPRIVILEGES

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

Le message RESTART n'est utilisable que par un operateur. Il sert a redemarrer le serveur. La gestion de ce message est optionnelle, car il est risque de permettre a des personnes se connectant comme operateur d'executer cette commande, qui cause une interruption de service (au moins).

La commande RESTART doit toujours être traitee par le serveur qui la recoit, et non passe a un autre serveur.

Reponses numeriques :

           ERR_NOPRIVILEGES

RESTART ; pas de parametres

La commande SUMMON peut être utilisee pour envoyer a des utilisateurs qui sont sur l'hôte sur lequel s'execute le serveur IRC un message leur demandant de joindre l'IRC. Ce message ne peut être envoye que si le serveur (a) a la commande SUMMON activee, et (b) si le processus serveur peut ecrire sur le tty (ou similaire) de l'utilisateur.

Si le parametre <serveur> n'est pas donne, cela essaie d'appeler l'<utilisateur> du serveur sur lequel le client est connecte.

Si le SUMMON est desactive sur un serveur, il doit renvoyer la reponse numerique ERR_SUMMONDISABLED et transmettre le message SUMMON.

Reponses numeriques :

    ERR_NORECIPIENT                 ERR_FILEERROR
    ERR_NOLOGIN                     ERR_NOSUCHSERVER
    RPL_SUMMONING

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

La commande USERS fonctionne de facon similaire a WHO(1), RUSERS(1) et FINGER(1). Certains peuvent desactiver cette commande sur leur serveur pour des raisons de securite. En cas de desactivation, cela doit être indique par le retour de reponse numerique appropriee.

Reponses numeriques :

    ERR_NOSUCHSERVER                ERR_FILEERROR
    RPL_USERSSTART                  RPL_USERS
    RPL_NOUSERS                     RPL_ENDOFUSERS
    ERR_USERSDISABLED

           ERR_USERSDISABLED

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

Envoie un message a tous les operateurs actuellement connectes. Apres avoir essaye de laisser acces a cette commande a tous les utilisateurs, il a ete constate qu'on en abusait comme un moyen d'envoyer des messages a plein de personnes (comme WALL). A cause de cela, il est recommande que l'implementations courante de WALLOPS ne reconnaisse que les serveurs comme emetteurs de WALLOPS.

Reponses numeriques :

      ERR_NEEDMOREPARAMS

:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; message WALLOPS de csd.bu.edu annoncant un message CONNECT recu et traite, issu de Joshua.

La commande USERHOST prends jusqu'a 5 pseudonymes, separes par des virgules, et revoie une liste d'informations pour chacun des pseudonymes qu'il a trouve. La liste des reponses contient chaque reponse separee par des espaces.

Reponses numeriques :

    RPL_USERHOST                    ERR_NEEDMOREPARAMS

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

La commande ISON a ete implementee pour fournir une maniere rapide et efficace de savoir si un pseudonyme donne est connecte a l'IRC. ISON prend un (1) parametre : une liste de pseudonymes separes par des espaces. Chaque pseudonyme present est ajoute a la chaîne de reponse du serveur. Ainsi, la chaîne de reponse peut être vide (aucun utilisateur est present), une copie exacte de la chaîne de caracteres passee en parametres (ils sont tous presents), ou un tout sous-ensemble du groupe de pseudonymes passe en parametre. La seule limite au nombre de pseudos qui peuvent être testes est la troncature des commandes a une longueur de 512 caracteres.

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

Reponses numeriques :

    RPL_ISON                ERR_NEEDMOREPARAMS

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

401 ERR_NOSUCHNICK

"<pseudonyme> :No such nick/channel"

402 ERR_NOSUCHSERVER

"<nom de serveur> :No such server"

403 ERR_NOSUCHCHANNEL

"<nom de canal> :No such channel"

404 ERR_CANNOTSENDTOCHAN

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

405 ERR_TOOMANYCHANNELS

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

406 ERR_WASNOSUCHNICK

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

407 ERR_TOOMANYTARGETS

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

409 ERR_NOORIGIN

":No origin specified"

411 ERR_NORECIPIENT

":No recipient given (<commande>)"

412 ERR_NOTEXTTOSEND

":No text to send"

413 ERR_NOTOPLEVEL

"<masque> :No toplevel domain specified"

414 ERR_WILDTOPLEVEL

"<masque> :Wildcard in toplevel domain"

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

421 ERR_UNKNOWNCOMMAND

"<commande> :Unknown command"

422 ERR_NOMOTD

":MOTD File is missing"

423 ERR_NOADMININFO

"<serveur> :No administrative info available"

424 ERR_FILEERROR

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

431 ERR_NONICKNAMEGIVEN

":No nickname given"

432 ERR_ERRONEUSNICKNAME

"<pseudo> :Erroneus nickname"

433 ERR_NICKNAMEINUSE

"<nick> :Nickname is already in use"

436 ERR_NICKCOLLISION

"<nick> :Nickname collision KILL"

441 ERR_USERNOTINCHANNEL

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

442 ERR_NOTONCHANNEL

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

443 ERR_USERONCHANNEL

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

444 ERR_NOLOGIN

"<utilisateur> :User not logged in"

445 ERR_SUMMONDISABLED

":SUMMON has been disabled"

446 ERR_USERSDISABLED

":USERS has been disabled"

451 ERR_NOTREGISTERED

":You have not registered"

461 ERR_NEEDMOREPARAMS

"<commande> :Not enough parameters"

462 ERR_ALREADYREGISTRED

":You may not reregister"

463 ERR_NOPERMFORHOST

":Your host isn't among the privileged"

464 ERR_PASSWDMISMATCH

":Password incorrect"

465 ERR_YOUREBANNEDCREEP

":You are banned from this server"

467 ERR_KEYSET

"<canal> :Channel key already set"

471 ERR_CHANNELISFULL

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

472 ERR_UNKNOWNMODE

"<caratere> :is unknown mode char to me"

473 ERR_INVITEONLYCHAN

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

474 ERR_BANNEDFROMCHAN

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

475 ERR_BADCHANNELKEY

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

481 ERR_NOPRIVILEGES

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

482 ERR_CHANOPRIVSNEEDED

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

483 ERR_CANTKILLSERVER

":You cant kill a server!"

491 ERR_NOOPERHOST

":No O-lines for your host"

501 ERR_UMODEUNKNOWNFLAG

":Unknown MODE flag"

502 ERR_USERSDONTMATCH

":Cant change mode for other users"

300 RPL_NONE

302 RPL_USERHOST

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

303 RPL_ISON

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

301 RPL_AWAY

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

305 RPL_UNAWAY

":You are no longer marked as being away"

306 RPL_NOWAWAY

":You have been marked as being away"

311 RPL_WHOISUSER

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

312 RPL_WHOISSERVER

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

313 RPL_WHOISOPERATOR

"<pseudo> :is an IRC operator"

317 RPL_WHOISIDLE

"<pseudo> <integer> :seconds idle"

318 RPL_ENDOFWHOIS

"<pseudo> :End of /WHOIS list"

319 RPL_WHOISCHANNELS

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

314 RPL_WHOWASUSER

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

369 RPL_ENDOFWHOWAS

"<pseudo> :End of WHOWAS"

321 RPL_LISTSTART

"Channel :Users Name"

322 RPL_LIST

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

323 RPL_LISTEND

":End of /LIST"

324 RPL_CHANNELMODEIS

"<canal> <mode> <parametres de mode >"

331 RPL_NOTOPIC

"<canal> :No topic is set"

332 RPL_TOPIC

"<canal> :<sujet>"

341 RPL_INVITING

"<canal> <pseudo>"

342 RPL_SUMMONING

"<utilisateur> :Summoning user to IRC"

351 RPL_VERSION

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

352 RPL_WHOREPLY

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

315 RPL_ENDOFWHO

"<nom> :End of /WHO list"

353 RPL_NAMREPLY

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

366 RPL_ENDOFNAMES

"<canal> :End of /NAMES list"

364 RPL_LINKS

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

365 RPL_ENDOFLINKS

"<mask> :End of /LINKS list"

367 RPL_BANLIST

"<canal> <identification de bannissement>"

368 RPL_ENDOFBANLIST

"<canal> :End of channel ban list"

371 RPL_INFO

":<chaîne>"

374 RPL_ENDOFINFO

":End of /INFO list"

375 RPL_MOTDSTART

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

372 RPL_MOTD

":- <texte>"

376 RPL_ENDOFMOTD

":End of /MOTD command"

381 RPL_YOUREOPER

":You are now an IRC operator"

382 RPL_REHASHING

"<fichier de configuration> :Rehashing"

391 RPL_TIME

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

392 RPL_USERSSTART

":UserID Terminal Hôte"

393 RPL_USERS

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

394 RPL_ENDOFUSERS

":End of users"

395 RPL_NOUSERS

":Nobody logged in"

200 RPL_TRACELINK

"Link <version & niveau de debugage > <destination> < serveur suivant>"

201 RPL_TRACECONNECTING

"Try. <classe> <serveur>"

202 RPL_TRACEHANDSHAKE

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

203 RPL_TRACEUNKNOWN

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

204 RPL_TRACEOPERATOR

"Oper <classe> <pseudo>"

205 RPL_TRACEUSER

"User <classe> <pseudo>"

206 RPL_TRACESERVER

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

208 RPL_TRACENEWTYPE

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

261 RPL_TRACELOG

"File <fichier log> <niveau de debugage>"

211 RPL_STATSLINKINFO

"<nom du lien> <sendq> < messages envoyes> <octets envoyes > <message recus> <octets recus> <temps de connection>"

212 RPL_STATSCOMMANDS

"<commande> <compteur>"

213 RPL_STATSCLINE

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

214 RPL_STATSNLINE

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

215 RPL_STATSILINE

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

216 RPL_STATSKLINE

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

218 RPL_STATSYLINE

"Y <classe> <frequence des PINGS > <frequence de connection > <sendq max>"

219 RPL_ENDOFSTATS

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

241 RPL_STATSLLINE

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

242 RPL_STATSUPTIME

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

243 RPL_STATSOLINE

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

244 RPL_STATSHLINE

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

221 RPL_UMODEIS

"<chaîne de mode utilisateur>"

251 RPL_LUSERCLIENT

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

252 RPL_LUSEROP

"<entier> :operator(s) online"

253 RPL_LUSERUNKNOWN

"<entier> :unknown connection(s)"

254 RPL_LUSERCHANNELS

"<entier> :channels formed"

255 RPL_LUSERME

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

256 RPL_ADMINME

"<serveur> :Administrative info"

257 RPL_ADMINLOC1

":<info admin >"

258 RPL_ADMINLOC2

":<info admin>"

259 RPL_ADMINEMAIL

":<info admin>"

Plus utilises ;
Reserves a une future utilisation ;
Utilises a l'heure actuelle, mais faisant partie des caracteristiques non generiques des serveurs IRC courants.

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

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

Etant donne qu'il n'est pas facile d'etablir avec fiabilite qui est a l autre bout d'une connection reseau, l'utilisation de mots de passe est fortement recommandee sur une connection inter-serveur, en plus des autres mesures telles que l'utilisation d'un serveur d'identite. 8. Implementations actuelles
La seule implementation actuelle de ce protocole est le serveur IRC version 2.8. Les versions precedentes peuvent implementer certaines ou toutes les commandes decrites dans ce document en utilisant les messages NOTICE a la place des reponses numeriques. Malheureusement, a causes des problemes de compatibilite ascensionnelle, les implementations de certaines parties de ce document different de ce qui est specifie. Une difference notable est :
     * La presence de tout LF ou CR dans n'importe ou dans le message marque sa fin (au lieu de la sequence preconisee CR-LF) ;

Le reste de cette section traite d'issues qui sont pour la plupart interessantes pour ceux qui veulent implementer un serveur, mais certaines s'appliquent aussi directement aux clients. 8.1 Protocole Reseau: TCP - Pourquoi il est le plus approprie.
IRC a ete implemente sur TCP car TCP fourni un protocole reseau fiable qui est approprie a cette echelle de discussions. L'utilisation d'IP multicast est une alternative, mais n'est pas tres repandue a l'heure actuelle. 8.1.1 Support des sockets Unix
Etant donne que les domaines de sockets Unix permettent les operations listen/connect, les implementations actuelles peuvent être configurees pour ecouter et accepter aussi bien les clients que les serveurs sur un domaine de socket Unix. On reconnaît les sockets a un nom d'hôte commencant par un '/'.

Lors de la communication des informations au sujet d'un domaine de socket Unix, le serveur doit remplacer le nom de chemin par le vrai nom d'hôte, a moins que le nom socket soit demande. 8.2 Traitement des commandes
Afin de fournir des E/S reseaux 'non-tamponnees' utiles aux clients et aux serveurs, a chaque connection est associee son propre 'tampon d'entree' dans lequel les resultats de lectures et traitements les plus recents sont conserves. Une taille de tampon de 512 octets et utilisee afin de contenir un message complet, bien qu'il en contienne habituellement plusieurs. Le tampon prive est traite apres toute operation de lecture a la recherche de messages valides. Lors du traitement de messages multiples en provenance d'un client, on doit prendre soin au cas où un des messages causerait le depart du client. 8.3 Distribution de message
Il est courant de trouver des liens reseaux satures ou des hôtes a qui vous envoyer des donnees et qui sont incapables d'en faire autant. Bien qu'Unix gere typiquement cela a travers la fenêtre TCP et ses tampons internes, le serveur a generalement de grandes quantites de donnees a envoyer (specialement lorsqu'une nouvelle connection serveur/serveur est cree) et les petits tampons fournis dans le noyau ne sont pas suffisant a la queue de sortie. Pour alleger ce probleme, une "queue d'envoi" est utilisee comme une queue FIFO pour les donnees a envoyer. Une "queue d'envoi" typique peut croître jusqu'a 200ko sur un gros reseau IRC, avec des connections reseau lentes quand un nouveau serveur se connecte.

Lorsqu'il traite ses connections, un serveur doit d'abord lire et traiter toutes les donnees entrantes, en memorisant les donnees qui seront emises. Quand toutes les entrees disponibles sont traitees, la queue d'envoi est expediee. Cela reduit le nombre d'appels systemes write() et aide TCP a faire des paquets plus gros. 8.4 La vie d'une connection
Pour detecter quand une connection est morte ou ne repond plus, le serveur doit envoyer un PING a toute les connections dont il n'a pas eu de reponse depuis un temps donne.

Si une connection ne repond pas a temps, elle est fermee en utilisant les procedures appropriees. Une connection est egalement lâchee si son sendq grossi au-dela du maximum autorise, car il vaut mieux fermer une connection lente que d'avoir le processus serveur bloque. 8.5 Etablissement d'une connection serveur a client
Lors de la connection a un serveur IRC, on envoie au client le MOTD (s'il est present) ainsi que le nombre actuel d'utilisateur et de serveurs (comme pour la commande LUSER). Le serveur doit egalement envoyer un message non equivoque au client, qui stipule son nom, sa version, ainsi que tout autre message d'introduction qui lui semble approprie.

Apres cela, le serveur doit envoyer le pseudo du nouvel utilisateur, et toute autre information aussi bien fournies par le client (commande USER) que celles trouvees par le serveur (serveurs DNS et IDENT). Le serveur doit envoyer ces informations a la premiere commande NICK suivi de USER. 8.6 Etablissement d'une connection serveur/serveur
Le processus d'etablissement d'une connection serveur a serveur est plein de dangers, car il y a de nombreux domaines où un probleme peut survenir { - the least of which are race conditions.}

Apres avoir recu une connection suivi d'une paire PASS/SERVER qui a ete reconnue valide, le serveur doit repondre avec ses propres informations PASS/SERVER pour cette connection, ainsi que toutes les informations d'etat qu'il connais comme decrit ci-dessous.

Quand le serveur initiant recoit la paire PASS/SERVER, lui aussi verifie que le serveur repondant est authentifie correctement avant d'accepter la connection comme etant ce serveur. 8.6.1 Echange des informations d'etat des serveurs a la connection
L'ordre des informations d'etat echangees entre les serveurs est essentiel. L'ordre requis est le suivant :

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

Les informations concernant les serveurs sont envoyees avec des messages SERVER supplementaires, les informations utilisateurs avec des messages NICK/USER/MODE/JOIN et celles des canaux avec des messages MODE.

NOTE : Les sujets des canaux ne sont PAS echanges ici, car la commande TOPIC ecrase toute information de sujet precedente, si bien que, au mieux, les deux côtes de la connection echangeraient les sujets.

En passant les informations d'etat concernant les serveurs en premier, toutes les collisions avec des serveurs qui existeraient deja ont lieu avant les collisions de pseudo dues a un second serveur introduisant un pseudonyme particulier. En raison de l'obligation de reseau IRC a n'exister que sur un graphe acyclique, il est possible que le reseau se soit deja reconnecte ailleurs, et l'endroit où la collision a lieu indique ou le reseau doit être divise. 8.7 Terminaison des connection serveur/client.
Lorsqu'une connection client se ferme, un message QUIT est genere de la part du client par le serveur sur lequel le client etait connecte. Aucun autre message ne doit être genere ou utilise. 8.8 Terminaison des connections serveur/serveur.
Si une connection serveur/serveur est fermee, soit par un SQUIT genere a distance, soit par une cause 'naturelle', le reste du reseau IRC doit le prendre en compte, et c'est au serveur qui detecte la fermeture de faire circuler l'information. Le serveur envoie une liste de SQUIT (un par serveur au-dela de la connection coupee) et une liste de QUIT (un par client au-dela de la connection coupee). 8.9 Suivi des changements de pseudonymes
Tous les serveurs IRC doivent garder un historique des changements recents de pseudonymes. Cela est necessaire pour offrir au serveur la possibilite de garder le contact quand une commande concerne un utilisateur changeant de pseudo. Les commandes qui doivent verifier un changement de pseudo sont :

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

Dans les cas ci-dessus, le serveur doit tout d'abord verifier l'existence du pseudonyme, puis verifier l'historique pour voir a qui appartient ce pseudo. Cela reduit les chances de problemes, mais ne les empêche pas completement, ce qui peu resulter au final de l'affectation du mauvais client. Lors du tracage des changements de pseudonymes pour une des commandes ci-dessus, il est recommande qu'un intervalle de temps soit donne, et que les entrees trop vielles soient ignorees.

Pour un historique parfait, un serveur devrait être capable de garder les pseudonymes de tous les clients qui ont decide d'un changement. La taille est limitee par d'autres facteurs (tels que la memoire, ...) 8.10 Contrôle d'inondation des clients
Dans un gros reseau de serveurs IRC interconnectes, il est assez facile, pour un simple client connecte, d'emettre un flux continu de messages qui resultent non seulement en l'inondation du reseau, mais aussi en la degradation de la qualite de service fournie aux autres clients. Au lieu de demander a chaque 'victime' de gerer sa propre protection, la protection contre les inondations est incluse dans le serveur et est appliquee a tous les clients, a l'exception des services. L'algorithme actuel est le suivant :

verifier si les 'messages de temps' des clients est inferieur au temps courant (et le mettre a l'heure courante le temps echeant) ;
lire toute donnee presentee par le client ;
tant que le compteur est inferieur a dix secondes par rapport a l'heure actuelle, traiter tout message actuel et penaliser le client de deux secondes par message ;

de quels hôtes accepter une connection en tant que client;
de quels hôtes accepter une connection en tant que serveur;
a quels hôtes se connecter (aussi bien activement que passivement) ;
informations sur l'emplacement du serveur (universite, ville/etat, entreprise par exemple) ;
quels sont les responsables du serveur, avec une adresse email où ils peuvent être contactes ;
noms d'hôtes et mots de passe pour les clients qui souhaitent obtenir l'acces restreint aux commandes d'operateur.

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

specification de quels serveurs un serveur peut introduire ;
jusqu'a quelle longueur une branche de serveur peut aller ;
heures durant lesquelles un client peut se connecter

Dans les versions actuelles du serveur, il n'y a pas verification de base de donnees, chaque serveur assumant qu'un serveur voisin est correct. Cela ouvre la porte a de gros problemes si un serveur qui se connecte est bugue ou essaie d'introduire des contradictions dans le reseau existant.

Actuellement, en raison du manque d'etiquettes internes et globales uniques, il existe une multitude de conditions pouvant causer une desynchronisation. Ces conditions resultent generalement du temps pris par un message pour traverser le reseau IRC. Mais, même en changeant pour des etiquettes uniques, il y a des problemes de synchronisation avec les commandes liees aux canaux. 10. Support actuel et disponibilite

Mailing lists pour les discussions liees a l'IRC :

Protocole futur : ircd-three-request@eff.org
Discussion generale: operlist-request@eff.org

Implementations logicielles

cs.bu.edu:/irc
nic.funet.fi:/pub/irc
coombs.anu.edu.au:/pub/irc


Newsgroup: alt.irc

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

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