| Groupe de Travail Reseau | J. Oikarinen |
| Requête pour commentaires: 1459 | D. Reed |
| Mai 1993 |
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.
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
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.
[ 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 ]
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).
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.
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)
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.
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.
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) >
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Serveurs: A, B, C, D, E Clients: 1, 2,3, 4
[ Fig. 2. Exemple d'un petit reseau IRC ]
Les exemples suivants se referent tous a la figure 2 ci-dessus.
Les exemples suivants se referent tous a la figure 2.
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.
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.
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
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_ALREADYREGISTREDExemple:
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:
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_ALREADYREGISTREDExemples:
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_ALREADYREGISTREDExemples :
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
; Le
serveur tolsun.oulu.fi est notre lien vers csd.bu.edu qui est a 5 noeuds de
nous.
Le message OPER est utilise par un utilisateur normal pour obtenir le privilege d'operateur. La combinaison de <utilisateur> et <mot de passe> est necessaire pour obtenir le privilege Operateur.
Si le client envoyant la commande OPER fourni un mot de passe correct pour l'utilisateur donne, le serveur informe le reste du reseau du nouvel operateur en envoyant un "MODE +o" pour le pseudonyme.
Le message OPER n'a lieu qu'entre un client et un serveur.
Reponses numeriques :
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH
Exemple:
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:
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_NOSUCHSERVERExemples:
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
;
message de Trillian pour deconnecter "cm22.eng.umd.edu" du reseau en raison
d'un "serveur incontrôlable".
La commande JOIN est utilisee par un client pour commencer a ecouter un canal
specifique. L'acces a un canal est autorise ou non uniquement par le serveur
auquel le client est connecte ; tous les autres serveurs ajoutent
automatiquement l'utilisateur au canal quand la demande vient d'un autre
serveur. Les conditions qui affectent ceci sont les suivantes :
1.
L'utilisateur doit être invite si le canal est en mode "sur invitation
seulement"
2. Le pseudo/nom d'utilisateur/nom d'hôte ne doit pas correspondre
a un bannissement actif.
3. La bonne cle (mot de passe) doit être fournie si
elle est definie.
Ceci est discute plus en details dans la description de la commande MODE (voir la section 4.2.3 pour plus de details).
Une fois qu'un utilisateur a acces a un canal, ils recoivent des notifications sur toutes les commandes que leur serveur recoit qui affectent le canal. Cela inclut MODE, KICK, PART, QUIT, et bien sûr PRIVMSG/NOTICE. La commande JOIN doit être diffusee a tous les serveurs du reseau pour qu'ils sachent où trouver qui est dans chaque canal. Cela permet une distribution optimale des messages PRIVMSG/NOTICE du canal.
Si un JOIN a lieu avec succes, on envoie a l'utilisateur le sujet du canal (en utilisant RPL_TOPIC) et la liste des utilisateurs du canal (en utilisant RPL_NAMREPLY), y compris lui-même.
Reponses numeriques :
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC
Exemples:
JOIN &foo fubar ; accede au canal &foo en utilisant la cle "fubar".
JOIN #foo,&bar fubar ; accede au canal #foo en utilisant la cle "fubar", et &bar en n'utilisant pas de cle.
JOIN #foo,#bar fubar,foobar ; accede au canal #foo en utilisant la cle "fubar", et au canal #bar en utilisant la cle "foobar".
JOIN #foo,#bar ; accede au canaux #foo and #bar.
:WiZ JOIN #Twilight_zone ; Message JOIN de WiZ
Le message PART provoque le retrait du client expediteur de la liste des utilisateurs actifs pour tous les canaux liste dans la chaîne de parametre.
Reponses numeriques:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL
Exemples:
PART #oz-ops,&group5 ; quitte les canaux "&group5" et "#oz-ops".
La commande MODE est une commande a utilisation duale sur IRC. Elle permet aussi bien de changer les modes des utilisateurs que ceux des canaux. La raison a ce choix est qu'un jour les pseudonymes deviendront obsoletes et la propriete equivalente sera le canal.
Lors du traitement des messages MODE, il est recommande de commencer par
decomposer le message en entier, puis de realiser les modifications
resultantes.
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'.
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:
Utilisation des modes d'utilisateur :
:MODE WiZ -w ; supprime
la reception des messages WALLOPS messages pour WiZ.
:Angel MODE Angel
+i ; Message d'Angel pour le rend invisible.
MODE WiZ -o ;
WiZ se 'deoppe' (retire son statut d'operateur). Le contraire de ca ("MODE WiZ
+o") ne doit pas être autorise car cela court-circuiterait la commande OPER.
Le message TOPIC est utilise pour modifier ou voir le sujet d'un canal. Le sujet du canal <canal> est renvoye s'il n'y a pas de <sujet> fourni en parametre. Si le parametre <sujet> est present, le sujet du canal changera si le mode du canal le permet.
Reponses numeriques :
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED
Exemples:
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_ENDOFNAMESExemples:
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:
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:
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>]
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.
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_VERSIONExemples:
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:
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:
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_TIMEExemples:
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: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_NOSUCHSERVERSi 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_TRACELINKUne 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:
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:
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:
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:
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.
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:
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:
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:
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.
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_NOSUCHSERVERExemples:
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_NOSUCHSERVERExemples:
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:
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_NOWAWAYExemples:
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_NOPRIVILEGESExemples:
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_NOPRIVILEGESExemples:
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:
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_USERSDISABLEDExemples:
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_NEEDMOREPARAMSExemples:
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_NEEDMOREPARAMSExemples:
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_NEEDMOREPARAMSExemples:
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>".
209 RPL_TRACECLASS 217 RPL_STATSQLINE
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
233 RPL_SERVICE 234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP 361 RPL_KILLDONE
362 RPL_CLOSING 363 RPL_CLOSEEND
373 RPL_INFOSTART 384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST
Une verification additionnelle de plus en plus commune est le nom d'utilisateur a l'origine de la connection. Trouver le nom d'utilisateur a l'origine d'une connection implique typiquement l'utilisation d'un serveur d'authentification tel que IDENT, comme il est decrit dans la RFC 1413.
Etant donne qu'il n'est pas facile d'etablir avec fiabilite qui est a l autre bout d'une connection reseau, l'utilisation de mots de passe est fortement recommandee sur une connection inter-serveur, en plus des autres mesures telles que l'utilisation d'un serveur d'identite.
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.
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.
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.
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.
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.
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.
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.
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, ...)
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 :
'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.
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.