Il a ete initialement implemente pour permettre aux utilisateurs d'un BBS pour discuter entre eux. Maintenant, il est utilise sur un reseau mondial de serveurs et de clients,

Protocole de discussions relayees par internet (IRC)

Statut de ce memo

Ce memo defini un protocole experimental pour la communaute internet. Des discussions et suggestions d'ameliorations sont attendues. Veuillez vous referer a la version courante de "IAB Official Protocol Standards" pour connaître l'etat de standardisation et le statut de ce protocole. La distribution de ce memo n'est pas limitee.

Resume

Le protocole IRC a ete developpe au cours des 4 dernieres annees. Il a ete initialement implemente pour permettre aux utilisateurs d'un BBS pour discuter entre eux. Maintenant, il est utilise sur un reseau mondial de serveurs et de clients, et a du mal a gerer sa croissance. Au cours des deux dernieres annees, le nombre moyen d'utilisateurs connectes au reseau IRC principal a ete multiplie par 10.

Le protocole IRC et un protocole en mode texte, dont le client le plus simple est n'importe quel programme de TCP capable de se connecter 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 peuvent 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 Clients

Un client est un truc qui se connecte a un serveur et qui n'est pas un autre serveur. Chaque client est differencie des autres clients par un pseudonyme unique ayant une longueur maximale de neuf (9) caracteres. Voir les regles de grammaire du protocole pour ce qui est autorise et ce qui ne l'est pas dans un pseudonyme. En plus de leur pseudonyme, tous les serveurs doivent connaître les informations suivantes sur tous les clients : le vrai nom de l'hôte sur lequel le client est execute, le nom de l'utilisateur du client sur cet hôte, et le serveur auquel le client est connecte.

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

3.1 Communication un a un

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

Les exemples suivants se 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.

3.2 Un a plusieurs

Le but principal d'IRC est de fournir un forum qui permette de realiser des conferences de facon simple et efficace (conversation un a plusieurs). L'IRC offre plusieurs moyens d'accomplir cela, chacun avec des buts differents.

3.2.1 A une liste

Le moyen le moins efficace d'avoir une conversation un a plusieurs consiste, pour chaque client, a parler a une 'liste' d'utilisateurs. La facon dont cela a lieu est triviale : chaque client donne une liste de destinataires auxquels le message doit être delivre, et le serveur decoupe le message et en distribue une copie a chacun des destinataires. Ce n'est pas aussi efficace que l'utilisation d'un groupe puisque la liste de destinataire est decomposee et la distribution a lieu sans verifier que le message soit envoye en double sur un même chemin.

3.2.2 A un groupe (canal)

Sur IRC, un canal a un rôle equivalent a celui d'un groupe de multi-diffusion ; leur existence est dynamique (ils vont et viennent au fur et a mesure que les gens accedent et quittent les canaux) et la conversation qui a lieu sur un canal n'est envoye qu'aux serveurs qui ont des utilisateurs sur ce canal. Cette action est alors repetee par chaque combinaison client/serveur jusqu'a ce que le message original est atteint tous les membres d'un canal.

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

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

Afin de fournir aux operateurs IRC un mecanisme pour envoyer des messages a un grand nombre d'utilisateurs apparentes, on fournit des masques de serveurs et d'hôtes. Ces messages sont envoyes a ceux des serveurs et des hôtes dont l'adresse correspond au masque. Ces messages ne sont envoyes qu'aux endroits où il y a des utilisateurs, de facon similaire a celle des canaux.

3.3 Un a tous

Les messages un a tous peuvent être decrit comme des messages de type diffusion, envoyes a tous les clients, les serveurs, ou les deux. Sur un grand reseau d'utilisateurs et de serveurs, un simple message peut generer beaucoup de trafic, puisqu'il est envoye a travers le reseau pour atteindre toutes les destinations.

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
Exemple:
PASS motdepasssecretici

4.1.2 Message NICK

Commande : NICK
Parametres : <pseudonyme> [ <compteur de distance> ]

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

4.1.3 Message USER

Commande: USER
Parametres: <nom d'utilisateur> <hôte> <nom de serveur> <nom reel>

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

4.1.4 Message SERVER

Commande: SERVER
Parametres: <nom de serveur> <compteur de distance> <info>

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

4.1.5 Message OPER

Commande: OPER
Parametres: <utilisateur> <mot de passe>

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

4.1.6 Message QUIT

Commande: QUIT
Parametres: [<Message de depart >]

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

4.1.7 Message SQUIT

Commande: SQUIT
Parametres: <serveur> <commentaire>

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

4.2 Operations sur les canaux

Ce groupe de messages s'interesse a la manipulation de canaux, a leurs proprietes (mode des canaux), et a leur contenu (typiquement des clients). En implementant ces commandes, la resolution de conflits entre les clients est inevitable, par exemple lorsque deux clients a deux extremites du reseau envoient des commandes incompatibles. Il est aussi necessaire aux serveurs de garder l'historique d'un pseudonyme de facon a ce quand un parametre <pseudo> est donne, le serveur puisse verifier dans l'historique si le pseudo n'a pas change recemment.

4.2.1 Le message JOIN

Commande: JOIN
Parametres: <canal>{,<canal>} [<cle>{,<cle>}]

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

4.2.2 Message PART

Commande: PART
Parametres: <canal>{,< canal >}

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

4.2.3 Message MODE

Commande: MODE

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

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

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

Parametres: <pseudonyme> {[+|-]|i|w|s|o}

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

4.2.4 Le message TOPIC

Commande: TOPIC
Parametres: <canal> [<sujet>]

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

4.2.5 Message NAMES

Commande: NAMES
Parametres: [<canal>{,<canal>}]

En utilisant la commande NAMES, un utilisateur peut obtenir la liste des pseudonymes visibles sur n'importe quel canal qu'il peut voir. Les noms de canaux qu'il peut voir sont ceux qui ne sont ni 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
Exemples:

4.2.6 Message LIST

Commande: LIST
Parametres: [<canal>{,<canal>} [<serveur>]]

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

4.2.7 Message INVITE

Commande: INVITE
Parametres: <pseudonyme> <canal>

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

4.2.8 Commande KICK

Commande: KICK
Parametres: <canal> <utilisateur> [<commentaire>]

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

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

4.3.2 Message STATS

Commande: STATS
Parametres: [<requête> [<serveur>]]

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

4.3.3 Message LINKS

Commande: LINKS
Parametres: [[<serveur distant>] <masque de serveur >]

Avec LINKS, un utilisateur peut obtenir la liste des serveurs connue d'un serveur. La liste des serveurs doit correspondre au masque, ou s'il n'y a pas de masque, la liste 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
Exemples:

4.3.4 Message TIME

Commande: TIME
Parametres: [<serveur>]

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

4.3.5 Message CONNECT

Commande: CONNECT
Parametres: <serveur destination > [<port> [<serveur distant>]]

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

4.3.6 Message TRACE

Commande: TRACE
Parametres: [<serveur>]

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
Si le message TRACE est destine a un autre serveur, tous les serveurs intermediaires doivent retourner une reponse RPL_TRACELINK pour indiquer que le TRACE est passe par lui et où il va ensuite.
           RPL_TRACELINK
Une reponse TRACE doit être une des reponses numeriques suivantes :
           RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
           RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
           RPL_TRACEUSER                   RPL_TRACESERVER
           RPL_TRACESERVICE                RPL_TRACENEWTYPE
           RPL_TRACECLASS
Exemples:

4.3.7 Commande ADMIN

Commande: ADMIN
Parametres: [<serveur>]

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

4.3.8 Commande INFO

Commande: INFO
Parametres: [<serveur>]

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

4.4 Envoi de messages

Le but principal du protocole IRC est de fournir une base afin que des clients puissent communiquer entre eux. PRIVMSG et NOTICE sont les seuls messages disponibles qui realisent effectivement la l'acheminement d'un message textuel d'un client a un autre - le reste le rend juste possible et assure que cela se passe de facon fiable et structuree.

4.4.1 Messages prives

Commande: PRIVMSG
Parametres: <destinataire>{,<destinataire>} <texte a envoyer >

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

4.4.2 Notice

Commande: NOTICE
Parametres: <pseudonyme> <texte>

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

4.5.2 Requête WHOIS

Commande: WHOIS
Parametres: [<serveur>] <masque de pseudo>[,<masque de pseudo>[,...]]

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

4.5.3 WHOWAS

Commande: WHOWAS
Parametres: <pseudonyme> [<compte> [<serveur>]]

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

4.6 Messages divers

Les messages de cette categorie ne font partie d'aucune des categories ci-dessus, mais font neanmoins partie integrante du protocole, et sont indispensables.

4.6.1 Message KILL

Commande: KILL
Parametres: <pseudonyme> <commentaire>

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

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

4.6.3 Message PONG

Commande: PONG
Parametres: <demon> [<demon2>]

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

4.6.4 Message ERROR

Commande: ERROR
Parametres: < message d'erreur>

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

5. Messages optionnels

Cette section decrit les messages optionnels. Ils ne sont pas requis dans les implementations des serveurs decrits ici. En l'absence de l'option, un message d'erreur doit être genere, ou une erreur commande inconnue. Si le message est destine a un autre serveur, il doit est transmis (traitement de base obligatoire). Les nombres alloues pour cela sont liste avec les messages ci-dessous.

5.1 AWAY

Commande: AWAY
Parametres: [message]

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

5.2 Message REHASH

Commande: REHASH
Parametres: Aucun

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

5.3 Message RESTART

Commande: RESTART
Parametres: Aucun

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

5.4 Message SUMMON

Commande: SUMMON
Parametres: <utilisateur> [<serveur>]

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

5.5 Commande USERS

Commande: USERS
Parametres: [<serveur>]

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
Reponse de desactivation :
           ERR_USERSDISABLED
Exemples:

5.6 Message WALLOPS

Commande: WALLOPS
Parametres: Texte a envoyer a tous les operateurs actuellement connectes.

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

5.7 Message USERHOST

Commande: USERHOST
Parametres: <pseudonyme>{<espace ><pseudonyme>}

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

5.8 Message ISON

Commande: ISON
Parametres: <pseudonyme>{<espace><pseudonyme>}

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

6. Reponses

Ce qui suit est une liste de reponses numeriques generees a la suite des commandes specifiees ci-dessus. Chaque reponse numerique est donnee avec son numero, son nom, et sa chaîne de reponse (en anglais).

6.1 Reponses d'erreur

401 ERR_NOSUCHNICK
"<pseudonyme> :No such nick/channel"
Utilise pour indiquer que le pseudonyme passe en parametre a la commande n'est pas actuellement utilise.
402 ERR_NOSUCHSERVER
"<nom de serveur> :No such server"
Utilise pour indiquer que le nom du serveur donne n'existe pas actuellement.
403 ERR_NOSUCHCHANNEL
"<nom de canal> :No such channel"
Utilise pour indiquer que le nom de canal donne est invalide.
404 ERR_CANNOTSENDTOCHAN
"<nom de canal> :Cannot send to channel"
Envoye a un utilisateur qui (a) soit n'est pas dans un canal en mode +n ou (b) n'est pas operateur (ou mode +v) sur un canal en mode +m ; et essaie d'envoyer un PRIVMSG a ce canal.
405 ERR_TOOMANYCHANNELS
"<nom de canal> :You have joined too many channels"
Envoye a un utilisateur quand il a atteint le nombre maximal de canaux qu'il est autorise a acceder simultanement, et qu'il essaie d'en rejoindre un autre.
406 ERR_WASNOSUCHNICK
"<nom de canal> :There was no such nickname"
Renvoye par WHOWAS pour indiquer qu'il n'y a pas d'information dans l'historique concernant ce pseudonyme.
407 ERR_TOOMANYTARGETS
"<destination> :Duplicate recipients. No message delivered"
Renvoye a un client qui essaie d'envoyer un PRIVMSG/NOTICE utilisant le format de destination utilisateur@hôte pour lequel utilisateur@hôte a plusieurs occurrences.
409 ERR_NOORIGIN
":No origin specified"
Message PING ou PONG sans le parametre origine qui est obligatoire puisque ces commandes doivent marcher sans prefixe.
411 ERR_NORECIPIENT
":No recipient given (<commande>)"
Pas de destinataire.
412 ERR_NOTEXTTOSEND
":No text to send"
Pas de texte a envoyer.
413 ERR_NOTOPLEVEL
"<masque> :No toplevel domain specified"
Domaine principal non specifie.
414 ERR_WILDTOPLEVEL
"<masque> :Wildcard in toplevel domain"
Joker dans le domaine principal

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"
Renvoye a un client enregistre pour indiquer que la commande envoyee est inconnue du serveur.
422 ERR_NOMOTD
":MOTD File is missing"
Le fichier MOTD du serveur n'a pas pu être ouvert.
423 ERR_NOADMININFO
"<serveur> :No administrative info available"
Renvoye par un serveur en reponse a un message ADMIN quand il y a une erreur lors de la recherche des informations appropriees.
424 ERR_FILEERROR
":File error doing <fichier op> on <fichier>"
Message d'erreur generique utilise pour rapporter un echec d'operation de fichier durant le traitement d'un message.
431 ERR_NONICKNAMEGIVEN
":No nickname given"
Renvoye quand un parametre pseudonyme attendu pour une commande n'est pas fourni.
432 ERR_ERRONEUSNICKNAME
"<pseudo> :Erroneus nickname"
Renvoye apres la reception d'un message NICK qui contient des caracteres qui ne font pas partie du jeu autorise. Voir les sections 1 et 2.2 pour les details des pseudonymes valides.
433 ERR_NICKNAMEINUSE
"<nick> :Nickname is already in use"
Renvoye quand le traitement d'un message NICK resulte en une tentative de changer de pseudonyme en un deja existant.
436 ERR_NICKCOLLISION
"<nick> :Nickname collision KILL"
Renvoye par un serveur a un client lorsqu'il detecte une collision de pseudonymes (enregistrement d'un pseudonyme qui existe deja sur un autre serveur).
441 ERR_USERNOTINCHANNEL
"<pseudo> <canal> :They aren't on that channel"
Renvoye par un serveur pour indiquer que l'utilisateur donne n'est pas dans le canal specifie.
442 ERR_NOTONCHANNEL
"<canal> :You're not on that channel"
Renvoye par le serveur quand un client essaie une commande affectant un canal dont il ne fait pas partie.
443 ERR_USERONCHANNEL
"<utilisateur> <channel> :is already on channel"
Renvoye quand un client essaie d'inviter un utilisateur sur un canal où il est deja.
444 ERR_NOLOGIN
"<utilisateur> :User not logged in"
Renvoye par un SUMMON si la commande n'a pas pu être accomplie, car l'utilisateur n'est pas connecte.
445 ERR_SUMMONDISABLED
":SUMMON has been disabled"
Renvoye en reponse a une commande SUMMON si le SUMMON est desactive. Tout serveur qui ne gere pas les SUMMON doit retourner cette valeur.
446 ERR_USERSDISABLED
":USERS has been disabled"
Retourne en reponse a une commande USERS si la commande est desactivee. Tout serveur qui ne gere pas les USERS doit retourner cette valeur.
451 ERR_NOTREGISTERED
":You have not registered"
Retourne par le serveur pour indiquer a un client qu'il doit être enregistre avant que ses commandes soient traitees.
461 ERR_NEEDMOREPARAMS
"<commande> :Not enough parameters"
Renvoye par un serveur apres de nombreuses commandes, afin d'indiquer que le client n'a pas fourni assez de parametres.
462 ERR_ALREADYREGISTRED
":You may not reregister"
Retourne par le serveur a tout lien qui tente de changer le detail de leurs informations enregistrees (tels que mot de passe et detail utilisateur du second message USER)
463 ERR_NOPERMFORHOST
":Your host isn't among the privileged"
Renvoye a un client qui essaie de s'enregistrer sur un serveur qui n'accepte pas les connections depuis cet hôte.
464 ERR_PASSWDMISMATCH
":Password incorrect"
Retourne pour indiquer l'echec d'une tentative d'enregistrement d'une connection dû a un mot de passe incorrect ou manquant.
465 ERR_YOUREBANNEDCREEP
":You are banned from this server"
Retourne apres une tentative de connection et d'enregistrement sur un serveur configure explicitement pour vous denier les connections.
467 ERR_KEYSET
"<canal> :Channel key already set"
Cle de canal deja definie.
471 ERR_CHANNELISFULL
"<canal> :Cannot join channel (+l)"
Impossible de joindre le canal (+l)
472 ERR_UNKNOWNMODE
"<caratere> :is unknown mode char to me"
Mode inconnu.
473 ERR_INVITEONLYCHAN
"<canal> :Cannot join channel (+i)"
Impossible de joindre le canal (+i).
474 ERR_BANNEDFROMCHAN
"<canal> :Cannot join channel (+b)"
Impossible de joindre le canal (+b).
475 ERR_BADCHANNELKEY
"<canal> :Cannot join channel (+k)"
Impossible de joindre le canal (+k).
481 ERR_NOPRIVILEGES
":Permission Denied- You're not an IRC operator"
Toute commande qui requiert le privilege d'operateur pour operer doit retourner cette erreur pour indiquer son echec.
482 ERR_CHANOPRIVSNEEDED
"<canal> :You're not channel operator"
Toute commande qui requiert les privileges 'chanop' (telles que les messages MODE) doit retourner ce message a un client qui l'utilise sans être chanop sur le canal specifie.
483 ERR_CANTKILLSERVER
":You cant kill a server!"
Toute tentative d'utiliser la commande KILL sur un serveur doit être refusee et cette erreur renvoyee directement au client.
491 ERR_NOOPERHOST
":No O-lines for your host"
Si un client envoie un message OPER et que le serveur n'a pas ete configure pour autoriser les connection d'operateurs de cet hôte, cette erreur doit être retournee.
501 ERR_UMODEUNKNOWNFLAG
":Unknown MODE flag"
Renvoye par un serveur pour indiquer que le message MODE a ete envoye avec un pseudonyme et que le mode specifie n'a pas ete identifie.
502 ERR_USERSDONTMATCH
":Cant change mode for other users"
Erreur envoye a tout utilisateur qui essaie de voir ou de modifier le mode utilisateur d'un autre client.

6.2 Reponses aux commandes.

300 RPL_NONE
Numero de reponse bidon. Inutilise.
302 RPL_USERHOST
":[<reponse>{<espace><reponse>}]"
Format de reponse utilise par USERHOST pour lister les reponses a la liste des requêtes. La chaîne de reponse est composee ainsi :
<reponse> ::= <pseudo>['*'] '=' <'+'|'-'><hôte>
Le '*' indique si le client est enregistre comme operateur. Les caracteres '-' ou '+' indiquent respectivement si le client a defini un message AWAY ou non.
303 RPL_ISON
":[<pseudo> {<espace><pseudo>}]"
Format de reponse utilise par ISON pour lister les reponses a la liste de requête.
301 RPL_AWAY
"<pseudo> :< message d'absence>"
305 RPL_UNAWAY
":You are no longer marked as being away"
306 RPL_NOWAWAY
":You have been marked as being away"
Ces trois reponses sont utilisees avec la commande AWAY (si elle est autorisee). RPL_AWAY est envoye a tout client qui envoie un PRIVMSG a un client absent. RPL_AWAY n'est envoye que par le serveur sur lequel le client est connecte. Les reponses RPL_UNAWAY et RPL_NOWAWAY sont envoyees quand un client retire et defini un message AWAY.
311 RPL_WHOISUSER
"<pseudo> <utilisateur> <hôte> * :<vrai nom>"
312 RPL_WHOISSERVER
"<pseudo> <serveur> :<info serveur >"
313 RPL_WHOISOPERATOR
"<pseudo> :is an IRC operator"
317 RPL_WHOISIDLE
"<pseudo> <integer> :seconds idle"
318 RPL_ENDOFWHOIS
"<pseudo> :End of /WHOIS list"
319 RPL_WHOISCHANNELS
"<pseudo> :{[@|+]<canal><espace>}"
Les reponses 311 a 313 et 317 a 319 sont toutes generees en reponses a un message WHOIS. S'il y a assez de parametres, le serveur repondant doit soit formuler une reponse parmi les numeros ci-dessus (si le pseudo recherche a ete trouve) ou renvoyer un message d'erreur. Le '*' dans RPL_WHOISUSER est la en tant que litteral et non en tant que joker. Pour chaque jeu de reponses, seul RPL_WHOISCHANNELS peut apparaître plusieurs fois (pour les longues listes de nom de canaux). Les caracteres '@' et '+' a côte du nom de canal indique si un client est operateur de canal, ou si on l'a autorise a parler dans un canal modere. La reponse RPL_ENDOFWHOIS est utilisee pour marquer la fin de la reponse WHOIS.
314 RPL_WHOWASUSER
"<pseudo> <utilisateur> <hôte> * :<vrai nom>"
369 RPL_ENDOFWHOWAS
"<pseudo> :End of WHOWAS"
Lorsqu'il repond a un message WHOWAS, un serveur doit utiliser RPL_WHOWASUSER, RPL_WHOISSERVER ou ERR_WASNOSUCHNICK pour chacun des pseudonymes de la liste fournie. A la fin de toutes les reponses, il doit y avoir un RPL_ENDOFWHOWAS (même s'il n'y a eu qu'une reponse, et que c'etait une erreur).
321 RPL_LISTSTART
"Channel :Users Name"
322 RPL_LIST
"<canal> <# visible> :<sujet>"
323 RPL_LISTEND
":End of /LIST"
Les reponses RPL_LISTSTART, RPL_LIST, RPL_LISTEND marquent le debut, les reponses proprement dites, et la fin du traitement d'une commande LIST. S'il n'y a aucun canal disponible, seules les reponses de debut et de fin sont envoyees.
324 RPL_CHANNELMODEIS
"<canal> <mode> <parametres de mode >"
331 RPL_NOTOPIC
"<canal> :No topic is set"
332 RPL_TOPIC
"<canal> :<sujet>"
Lors de l'envoi d'un message TOPIC pour determiner le sujet d'un canal, une de ces deux reponses est envoyee. Si le sujet est defini, RPL_TOPIC est renvoyee, sinon c'est RPL_NOTOPIC.
341 RPL_INVITING
"<canal> <pseudo>"
Renvoye pas un serveur pour indiquer que le message INVITE a ete enregistre, et est en cours de transmission au client final.
342 RPL_SUMMONING
"<utilisateur> :Summoning user to IRC"
Renvoye par un serveur en reponse a un message SUMMON pour indiquer qu'il appelle cet utilisateur.
351 RPL_VERSION
"<version>.<debuglevel> <serveur> :<commentaires>"
Reponse du serveur indiquant les details de sa version. <version> est la version actuelle du programme utilise (comprenant le numero de mise a jour) et <debuglevel> est utilise pour indiquer si le serveur fonctionne en mode debugage.
Le champ <commentaire> peut contenir n'importe quel commentaire au sujet de la version, ou des details supplementaires sur la version.
352 RPL_WHOREPLY
"<canal> <utilisateur> <hôte> <serveur> <pseudo> <H|G>[*][@|+] :<compteur de distance> <vrai nom>"
315 RPL_ENDOFWHO
"<nom> :End of /WHO list"
La paire RPL_WHOREPLY et RPL_ENDOFWHO est utilisee en reponse a un message WHO. Le RPL_WHOREPLY n'est envoye que s'il y a une correspondance a la requête WHO. S'il y a une liste de parametre fournie avec le message WHO, un RPL_ENDOFWHO doit être envoye apres le traitement de chaque element de la liste, <nom> etant l'element.
353 RPL_NAMREPLY
"<canal> :[[@|+]<pseudo> [[@|+]<pseudo> [...]]]"
366 RPL_ENDOFNAMES
"<canal> :End of /NAMES list"
En reponse a un message NAMES, une paire consistant de RPL_NAMREPLY et RPL_ENDOFNAMES est renvoyee par le serveur au client. S'il n'y a pas de canal resultant de la requête, seul RPL_ENDOFNAMES est retourne. L'exception a cela est lorsqu'un message NAMES est envoye sans parametre et que tous les canaux et contenus visibles sont renvoyes en une suite de message RPL_NAMEREPLY avec un RPL_ENDOFNAMES indiquant la fin.
364 RPL_LINKS
"<masque> <serveur> :<compteur de distance> <info serveur >"
365 RPL_ENDOFLINKS
"<mask> :End of /LINKS list"
En reponse a un message LINKS, un serveur doit repondre en utilisant le nombre RPL_LINKS, et indiquer la fin de la liste avec une reponse RPL_ENDOFLINKS.
367 RPL_BANLIST
"<canal> <identification de bannissement>"
368 RPL_ENDOFBANLIST
"<canal> :End of channel ban list"
Quand il liste les bannissements actifs pour un canal donne, un serveur doit renvoyer la liste en utilisant les messages RPL_BANLIST et RPL_ENDOFBANLIST. Un RPL_BANLIST different doit être utilise pour chaque identification de bannissement. Apres avoir liste les identifications de bannissement (s'il y en a), un RPL_ENDOFBANLIST doit être renvoye.
371 RPL_INFO
":<chaîne>"
374 RPL_ENDOFINFO
":End of /INFO list"
Un serveur repondant a un message INFO doit envoyer toute sa serie d'info en une suite de reponses RPL_INFO, avec un RPL_ENDOFINFO pour indiquer la fin des reponses.
375 RPL_MOTDSTART
":- <serveur> Message of the day - "
372 RPL_MOTD
":- <texte>"
376 RPL_ENDOFMOTD
":End of /MOTD command"
Lorsqu'il repond a un message MOTD et que le fichier MOTD est trouve, le fichier est affiche ligne par ligne, chaque ligne ne devant pas depasser 80 caracteres, en utilisant des reponses au format RPL_MOTD. Celles-ci doivent être encadrees par un RPL_MOTDSTART (avant les RPL_MOTDs) et un RPL_ENDOFMOTD (apres).
381 RPL_YOUREOPER
":You are now an IRC operator"
RPL_YOUREOPER est renvoye a un client qui vient d'emettre un message OPER et a obtenu le statut d'operateur.
382 RPL_REHASHING
"<fichier de configuration> :Rehashing"
Si l'option REHASH est activee et qu'un operateur envoie un message REHASH, un RPL_REHASHING est renvoye a l'operateur.
391 RPL_TIME
"<serveur> :<chaîne indiquant l'heure locale du serveur >"
Lorsqu'il repond a un message TIME, un serveur doit repondre en utilisant le format RPL_TIME ci-dessus. La chaîne montrant l'heure ne doit que contenir le jour et l'heure correcte. Il n'y a pas d'obligation supplementaire.
392 RPL_USERSSTART
":UserID Terminal Hôte"
393 RPL_USERS
":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS
":End of users"
395 RPL_NOUSERS
":Nobody logged in"
Si le message USERS est gere par un serveur, les reponses RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS et RPL_NOUSERS sont utilisees. RPL_USERSSTART doit être envoye en premier, suivi par soit une sequence de RPL_USERS ou un unique RPL_NOUSER. Enfin, viens un RPL_ENDOFUSERS.
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>"
Les RPL_TRACE* sont tous renvoyes par le serveur en reponse a un message TRACE. Le nombre de messages retournes depend de la nature du message TRACE, et s'il a ete envoye par un operateur ou non. Il n'y a pas d'ordre definissant lequel doit être le premier. Les reponses RPL_TRACEUNKNOWN, RPL_TRACECONNECTING et RPL_TRACEHANDSHAKE sont toutes utilisees pour des connections qui n'ont pas ete completement etablies, et sont soit inconnues, soit sont toujours en cours de connection, soit sont dans la phase terminale de la 'poignee de main du serveur'. RPL_TRACELINK est envoye par tout serveur qui traite un message TRACE et doit le transmettre a un autre serveur. La liste de RPL_TRACELINK envoye en reponse a une commande TRACE traversant le reseau IRC devrait refleter la connectivite actuelle des serveurs le long du chemin. RPL_TRACENEWTYPE est utilise pour toute connection qui n'entre pas dans les autres categories, mais qui est neanmoins affichee.
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>"
Pour repondre a une requête au sujet du mode du client, RPL_UMODEIS est renvoye.
251 RPL_LUSERCLIENT
":There are <entier> users and <entier> invisible on <entier> servers"
252 RPL_LUSEROP
"<entier> :operator(s) online"
253 RPL_LUSERUNKNOWN
"<entier> :unknown connection(s)"
254 RPL_LUSERCHANNELS
"<entier> :channels formed"
255 RPL_LUSERME
":I have <entier> clients and <integer> servers"
Lors du traitement d'un message LUSERS, le serveur envoie un lot de reponses parmi RPL_LUSERCLIENT, RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS et RPL_LUSERME. Lorsqu'il repond, un serveur doit envoyer RPL_LUSERCLIENT et RPL_LUSERME. Les autres reponses ne sont renvoyees que si le nombre trouve n'est pas nul.
256 RPL_ADMINME
"<serveur> :Administrative info"
257 RPL_ADMINLOC1
":<info admin >"
258 RPL_ADMINLOC2
":<info admin>"
259 RPL_ADMINEMAIL
":<info admin>"
Lorsqu'il repond a un message ADMIN, un serveur doit renvoyer les reponses RLP_ADMINME a RPL_ADMINEMAIL et fournir un texte de message avec chacune. Pour RPL_ADMINLOC1, une description de la ville et de l'etat dans lequel le serveur est, suivi des details de l'universite et du departement (RPL_ADMINLOC2), et finalement le contact administratif pour ce serveur (avec obligatoirement une adresse email) dans RPL_ADMINEMAIL.

6.3 Nombres reserves.

Ces nombres ne sont pas decrits si dessus par ce qu'ils tombent dans l'une des categories suivantes :
  1. Plus utilises ;
  2. Reserves a une future utilisation ;
  3. 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

7. Authentification des clients et serveurs

Les clients et serveurs sont tous deux soumis au même niveau d'authentification. Dans les deux cas, une verification de l'adresse IP a l'hôte (avec verification inverse sur cela) est effectuee pour toutes les connections au serveur. Les deux connections sont alors sujet a une verification de mot de passe (s'il y a un mot de passe defini pour cette connection). Ces verifications sont possibles pour toutes les connections, bien que la verification d'un mot de passe n'est generalement utilisee que pour les serveurs.

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 :

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 : Aucune autre commande ne doit verifier un changement de pseudo.

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 : Ce qui, en essence, signifie qu'un client ne peut envoyer plus d'un message toutes les deux secondes sans être affecte.

8.11 Boucles non bloquantes

Dans un environnement temps reel, il est essentiel qu'un processus serveur attende aussi peu que possible, de maniere a ce que tous les clients soient servis justement. Evidement, cela necessite des ES non bloquantes sur toutes les operations de lecture/ecriture du reseau. Pour les connections de serveur normales, ce n'est pas complique, mais il y a des operations gerees qui peuvent causer un blocage du serveur (telles que les lectures disque). Quand c'est possible, de telles activites doivent être executee avec un delai d'attente maximal court.

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

L'utilisation des librairies de resolution standards de Berkeley et autres entraîne de gros delais, dans les cas où les reponses n'arrivent pas. Afin d'eviter cela, un jeu de routines DNS independantes ont ete ecrites, où les operations DNS ont ete ecrites avec des E/S non bloquantes et testees depuis la boucle d'E/S principale du serveur.

8.11.2 Recherche du nom d'utilisateur (IDENT)

Bien qu'il y ait de nombreuses libraires IDENT a utiliser et inclure dans d'autres programmes, elles posent des problemes puisqu'elles operent de facon synchrone, et resultent en de nombreuses attentes. Encore une fois, la solution a ete d'ecrire un jeu de routines qui cooperent avec le reste du serveur, et utilisent des E/S non bloquantes.

8.12 Fichier de configuration

Afin de fournir une facon flexible de configurer et de lancer le serveur, il est recommande qu'un fichier de configuration soit utilise, qu'il contienne les instructions du serveur suivantes : Lors de la specification des noms d'hôtes, les noms de domaines et la notation 'point' (127.0.0.1) doivent être tous les deux gerees. Il doit être possible de preciser un mot de passe a utiliser/accepter pour toutes les connections entrantes et sortantes (bien que les connections sortantes soient toutes a destination de serveurs).

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 :

8.12.1 Autorisation des connections de clients

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

'Accepter' et 'interdire' doivent tout les deux être implementes pour fournir le niveau de flexibilite requis par le contrôle d'acces des hôtes.

8.12.2 Operateurs

En raison des pouvoirs qui leur sont accordes , le don des privileges d'operateurs a une personne turbulente peut avoir des consequences desastreuses sur le bien-être du reseau IRC en general. C'est pourquoi l'acquisition de ces pouvoirs ne doit pas être facile. La configuration actuelle necessite deux mots de passes, bien que l'un d'entre eux soit generalement facile a trouver. L'enregistrement des mots de passe d'operateur dans le fichier de configuration est preferable a leur codage en dur, et ils doivent être sauvegarde dans un format code (par exemple en utilisant crypt(3) d'Unix) afin de rendre les vols plus difficiles.

8.12.3 Autorisation des connections de serveurs

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

8.12.4 Admin

Pour fournir des reponses valides et precises a la commande ADMIN (voir section 4.3.7), le serveur doit trouver tous les details appropries dans le fichier de configuration.

8.13 Appartenance a un canal.

Le serveur actuel autorise tout utilisateur enregistre localement a acceder jusqu'a 10 canaux differents. Il n'y a pas de limites imposees aux utilisateurs non-locaux, si bien que le serveur reste (raisonnablement) coherent avec les autres serveurs pour ce qui est de l'appartenance a un canal.

9. Problemes actuels

Il y a nombre de problemes reconnus avec ce protocole, chacun d'entre eux esperant être resolu dans un futur proche lors de sa reecriture. Actuellement, le travail est en cours pour trouver des solutions convenables a ces problemes.

9.1 Localisation

Il est largement reconnu que ce protocole ne gere pas correctement les localisations lorsqu'il est utilise dans une grande arene. Le probleme principal vient de la necessite qu'ont tous les serveurs de connaître tous les autres serveurs et utilisateurs, et que leurs informations soient mises a jour des que possible. Il est aussi necessaire de garder un faible nombre de serveurs, de facon a ce que le chemin entre deux points reste aussi faible que possible, et que l'arbre de distribution contienne des branches aussi grosses que possible.

9.2 Identifiants

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

9.2.1 Pseudonymes

L'idee de pseudonymes sur IRC est tres pratique pour les utilisateurs qui parlent hors des canaux, mais il y a un nombre fini des pseudonymes, et il n'est pas rare de voir plusieurs personne vouloir utiliser le même pseudo. Si un pseudonyme est choisi par deux personnes qui utilisent ce protocole, soit l'une des deux ne reussi pas a l'obtenir, soit toutes les deux sont deconnectees par l'utilisation de KILL (4.6.1).

9.2.2 Canaux

La couche de canaux actuelle necessite que tous les serveurs connaissent tous les canaux, leurs membres, et leurs proprietes. En plus ne pas bien gerer la localisation la question de la confidentialite est aussi concernee. La collision de canaux est geree de facon inclusive (les deux personnes qui creent le canal sont consideres comme en etant membre) plutôt que de facon exclusive telle que celle utilisee pour resoudre les collisions de pseudonymes.

9.2.3 Serveurs

Bien que le nombre de serveurs soit habituellement petit compare au nombre d'utilisateurs et de canaux, ils doivent aussi être connus globalement, soit chacun separement, soit cache derriere un masque.

9.3 Algorithmes

A certains endroits du code du serveur, il n'a pas ete possible d'eviter des algorithmes N^2, comme par exemple dans la verification de la liste des canaux d'un ensemble de clients.

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