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.

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.

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

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.

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.

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> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'

Les exemples suivants se referent tous a la figure 2 ci-dessus.

Exemple 1 :

Un message entre les clients 1et 2 n'est vu que par le serveur A, qui l'envoi directement au client 2.

Exemple 2 :

Un message entre les clients 1 et 3 est vu par les serveurs A & B, et par le client 3. Aucun autre client n'est autorise a voir le message.

Exemple 3 :

Un message entre les clients 2 et 4 n'est vu que par les serveurs A, C, C & D et par le client 4.

Les exemples suivants se referent tous a la figure 2.

Exemple 4 :

Pour tout canal qui contient un seul client, les messages du canal vont au serveur et nul par ailleurs.

Exemple 5 :

Il y a deux clients dans un canal. Tous les messages traversent le chemin comme s'ils etaient des messages prives entre les deux clients en dehors du canal.

Exemple 6 :

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

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

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.

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.

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

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

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

Notez aussi que le parametre 'vrai nom' doit être le dernier parametre, car il peut contenir des espaces, et il doit être prefixe par deux points (':') de facon a être reconnu comme tel.

Puisqu'il est facile pour un client de mentir sur son nom si on se base uniquement sur le message USER, il est recommande d'utiliser un "serveur d'identite". Si l'hôte dont l'utilisateur se connecte a un serveur de ce type active, le nom d'utilisateur est defini par la reponse de ce "serveur d'identite".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

QUIT :Parti dejeuner ; Format de message prefere.

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

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

Le <commentaire> doit être present pour tout operateur qui execute un SQUIT sur un serveur distant (qui n'est pas connecte au serveur sur lequel ils sont actuellement). Le <commentaire> est egalement rempli par les serveurs qui peuvent y placer un message d'erreur ou autre.

Les deux serveurs, de chaque côte de la connection qui va être coupee doivent envoyer un message SQUIT (a tous les serveurs auxquels ils sont connectes) pour tous les serveurs qui sont situes au-dela de ce lien.

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

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

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

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

La commande JOIN est utilisee par un client pour commencer a ecouter un canal specifique. L'acces a un canal est autorise ou non uniquement par le serveur auquel le client est connecte ; tous les autres serveurs ajoutent automatiquement l'utilisateur au canal quand la demande vient d'un autre serveur. Les conditions qui affectent ceci sont les suivantes :
1. L'utilisateur doit être invite si le canal est en mode "sur invitation seulement"
2. Le pseudo/nom d'utilisateur/nom d'hôte ne doit pas correspondre a un bannissement actif.
3. La bonne cle (mot de passe) doit être fournie si elle est definie.

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

Une fois qu'un utilisateur a acces a un canal, ils recoivent des notifications sur toutes les commandes que leur serveur recoit qui affectent le canal. Cela inclut MODE, KICK, PART, QUIT, et bien sûr PRIVMSG/NOTICE. La commande JOIN doit être diffusee a tous les serveurs du reseau pour qu'ils sachent où trouver qui est dans chaque canal. Cela permet une distribution optimale des messages PRIVMSG/NOTICE du canal.

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

JOIN #foobar ; accede au canal #foobar.

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

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

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

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

:WiZ JOIN #Twilight_zone ; Message JOIN de WiZ

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

PART #twilight_zone ; quitte le canal "#twilight_zone"

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

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

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)

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

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

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

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

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

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

Si le parametre <canal> n'est pas donne, la liste de tous les canaux et de leurs occupants est renvoyee. A la fin de cette liste, sont listes les utilisateurs qui sont visibles, mais qui n'appartiennent a aucun canal. Ils sont listes comme appartenant au canal `channel' "*".

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

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

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

Le message INVITE est utilise pour inviter des utilisateurs dans un canal. Le parametre <pseudonyme> est le pseudonyme de la personne a inviter dans le canal destination <canal>. Il n'est pas necessaire que le canal dans lequel la personne est invitee existe, ni même soit valide. Pour inviter une personne dans un canal en mode sur invitation (MODE +i), le client envoyant l'invitation doit être operateur sur le canal designe.

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

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

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

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

NOTE:

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.

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

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

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

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

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

Avec LINKS, un utilisateur peut obtenir la liste des serveurs connue d'un serveur. La liste des serveurs doit correspondre au masque, ou s'il n'y a pas de masque, la liste complete des serveurs est renvoyee.

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

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

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

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

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

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

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

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

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

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

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

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

INFO csd.bu.edu ; requête INFO pour csd.bu.edu
:Avalon INFO *.fi ; requête INFO d' Avalon a destination du premier serveur trouve qui correspond a *.fi.
INFO Angel ; requête INFO a destination du serveur sur lequel est connecte Angel.

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

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

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

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.

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

Ce message est utilise pour obtenir des informations sur un utilisateur donne. Le serveur repondra a ce message avec des messages numeriques indiquant les differents statuts de chacun des utilisateurs qui correspondent au <masque de pseudo> (si vous pouvez les voir). S'il n'y a pas de joker dans le <masque de pseudo>, toutes les informations auxquelles vous avez acces au sujet de ce pseudo seront presentees. On peut separer la liste des pseudonymes avec une virgule (',').

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

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

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

WHOWAS Wiz ; revoie toutes les informations dans l'historique des pseudos au sujet du pseudo "WiZ";
WHOWAS Mermaid 9 ; renvoie, au maximum, les neufs entrees les plus recentes dans l'historiques des pseudos pour "Mermaid";
WHOWAS Trillian 1 *.edu ; demande l'entree la plus recente pour "Trillian" au premier serveur trouve qui correspond a "*.edu".

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

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

Dans une arene où les pseudonymes doivent être globalement uniques, les messages KILL sont envoyes a chaque fois qu'un doublon est detecte (c'est-a-dire une tentative d'enregistrer deux utilisateurs avec le même pseudonyme) dans l'espoir qu'ils disparaîtront tous les deux, et qu'un seul reapparaîtra.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RESTART ; pas de parametres

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

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

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

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

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

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

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

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

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

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

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

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

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

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"

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

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

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.

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.

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

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

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

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

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.

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

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

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 :

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

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

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

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