Groupe de travail Réseau	C. Kalt	
Request for Comments : 2812	avril 2000	
RFC mise à jour : 1459		
Catégorie : Information	Traduction Claude Brière de L’Isle	

Relais pour la causette Internet : protocole client

Statut de ce mémoire
Le présent mémoire fournit des informations pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.
(La présente traduction incorpore les errata 384, 385, 386, 991, 2306, 2821, 2822, 2991, 3001, 3246, et 3255)

Notice de copyright 
Copyright (C) The Internet Society (2000). Tous droits réservés.

Note de l’IESG :
Le protocole IRC lui-même permet plusieurs possibilités de transférer des données entre clients, et tout comme les autres mécanismes de transfert du style de la messagerie électronique, le receveur des données doit faire attention à la façon dont les données sont traitées. Pour plus d’informations sur les problèmes de sécurité posés par le protocole IRC, voir, par exemple http://www.irchelp.org/irchelp/security/ .

Résumé
Le protocole de relais de causette de l’Internet (IRC, Internet Relay Chat) est à utiliser avec la conférence fondée sur le texte, le plus simple client étant toute prise programmable capable de se connecter au serveur.

Le présent document définit le protocole client, et suppose que le lecteur est familiarisé avec l’architecture IRC [RFC2810].

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRA" NE DEVRA PAS", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la [RFC2119].

Table des matières
1. Étiquettes	2
1.1 Serveurs	2
1.2 Clients	2
1.3 Canaux	3
2. Spécification du client IRC	3
2.1 Généralités	3
2.2 Codes de caractères	3
2.3 Messages	3
2.4 Réponses numériques	5
2.5 Expressions de caractères génériques	5
3. Détails du message	5
3.1 Enregistrement de connexion	5
3.2 Opérations du canal	9
3.3 Envoi des messages	12
3.4 Commandes d’interrogations de serveur	13
3.5 Interrogations et commandes de service	17
3.6 Interrogations fondées sur l’utilisateur	18
3.7 Messages divers	19
4. Caractéristiques facultatives	21
4.1 Away	21
4.2 Message Rehash	21
4.3 Message Die	22
4.4 Message Restart	22
4.5 Message Summon	22
4.6 Commande Users	23
4.7 Message Operwall	23
4.8 Message Userhost	23
4.9 Message Ison	24
5. Réponses	24
5.1 Réponses aux commandes	24
5.2 Réponses d’erreur	28
5.3 Numéros réservés	31
6. Mises en œuvre actuelles	31
7. Problèmes rencontrés	31
7.1 Pseudonymes	31
7.2 Limitation des caractères génériques	31
7.3 Considérations pour la sécurité	31
8. Prise en charge et disponibilité actuelle	31
9. Remerciements	32
10. Références	32
11. Adresse de l’auteur	32
12. Déclaration complète de droits de reproduction	32

1.	Étiquettes

Cette section définit les identifiants utilisés pour les divers composants du protocole IRC.

1.1	Serveurs
Les serveurs sont identifiés de façon univoque par leur nom, qui a une longueur maximum de soixante trois (63) caractères. Voir les règles de grammaire du protocole (paragraphe 2.3.1) pour savoir ce qui peut être ou non utilisé dans un nom de serveur.

1.2	Clients
Pour chaque client, tous les serveurs DOIVENT avoir les informations suivantes : un identifiant univoque à l’échelle du réseau (dont le format dépend du type de client) et le serveur qui a introduit le client.

1.2.1	Utilisateurs
Chaque utilisateur se distingue des autres utilisateurs par un pseudonyme univoque qui a une longueur maximum de neuf (9) caractères. Voir dans les règles de grammaire du protocole (paragraphe 2.3.1) ce qui peut ou non être utilisé dans un pseudonyme.

Bien que la longueur maximum soit limitée à neuf caractères, les clients DEVRAIENT accepter de plus longues chaînes car elles pourraient être utilisées dans de futures évolutions du protocole.

1.2.1.1	Opérateurs
Pour permettre de conserver un minimum d’ordre raisonnable au sein du réseau IRC, une classe spéciale d’utilisateurs (les opérateurs) est autorisée à effectuer les fonctions générales de maintenance sur le réseau. Bien que les pouvoirs accordés à un opérateur puissent être considérés comme 'dangereux', ils sont néanmoins souvent nécessaires. Les opérateurs DEVRAIENT être capables d’effectuer des tâches de base sur le réseau telles que de déconnecter et reconnecter les serveurs en tant que de besoin. En reconnaissance de ce besoin, le protocole qu’on expose ici ne s’occupe des opérateurs qu’à l’égard de leur capacité à effectuer de telles fonctions. Voir les paragraphes 3.1.8 (SQUIT) et 3.4.7 (CONNECT).

Un pouvoir plus controversé des opérateurs est la capacité de retirer "de force" un utilisateur du réseau connecté, c’est-à-dire que les opérateurs sont capables de fermer la connexion entre tout client et serveur. La justification de cela est très délicate car son abus est à la fois destructeur et fâcheux, et son bénéfice proche d’inexistant. Pour les détails sur ce type d’action, voir au paragraphe 3.7.1 (KILL).

1.2.2	Services
Chaque service se distingue des autres services par un nom de service composé d’un pseudonyme et d’un nom de serveur. Comme pour les utilisateurs, le pseudonyme a une longueur maximum de neuf (9) caractères. Voir dans les règles de grammaire du protocole (paragraphe2.3.1) ce qui peut ou non être utilisé dans un pseudonyme.

1.3	Canaux
Les noms de canal sont des chaînes (commençant par un caractère '&', '#', '+' ou '!') d’une longueur allant jusqu’à cinquante (50) caractères. À part l’exigence que le premier caractère soit '&', '#', '+' ou '!', la seule restriction à un nom de canal est qu’il NE DEVRA PAS contenir d’espace (' '), de contrôle G (^G ou ASCII 7) ni de virgule (','). L’espace est utilisée comme séparateur de paramètre et la virgule est utilisée comme séparateur d’élément de liste par le protocole. Un caractère deux-points (':') peut aussi être utilisé comme délimiteur pour le gabarit de canal. Les noms de canal sont insensibles à la casse.

Voir dans les règles de grammaire du protocole (paragraphe 2.3.1) la syntaxe exacte d’un nom de canal.

Chaque préfixe caractérise un type différent de canal. La définition du type de canal n’est pas pertinente pour le protocole client-serveur et sort donc du domaine d’application du présent document. Les précisions figurent dans la [RFC2811] "Relais pour la causette Internet : gestion de canal".

2.	Spécification du client IRC
2.1	Généralités
Le protocole décrit ici est à utiliser pour les seules connexions de client à serveur lorsque le client s’enregistre comme utilisateur.

2.2	Codes de caractères
Aucun jeu de caractères spécifique n’est spécifié. Le protocole se fonde sur un jeu de codes qui sont composés de huit (8) bits, constituant un octet. Chaque message peut être composé d’un nombre quelconque de ces octets ; cependant, certaines valeurs d’octet sont utilisées pour des codes de contrôle, qui agissent comme des délimiteurs de message.

Indépendamment d’être un protocole à 8 bits, les délimiteurs et les mots-clés sont tels que le protocole est principalement utilisable à partir de terminaux US-ASCII et d’une connexion telnet.

À cause de l’origine scandinave de l’IRC, les caractères {}|^ sont considérés respectivement comme l’équivalent en minuscules des caractères []\~. Ceci est d’une importance critique pour la détermination de l’équivalence de deux pseudonymes ou de deux noms de canal.

2.3	Messages
Serveurs et clients s’envoient chacun des messages, qui peuvent ou non générer une réponse. Si le message contient une commande valide, comme décrit dans les paragraphes suivants, le client devrait s’attendre à la réponse spécifiée mais il ne lui est pas conseillé d’attendre indéfiniment cette réponse ; la communication de client à serveur et de serveur à serveur est essentiellement asynchrone par nature.

Chaque message IRC peut consister en jusqu’à trois parties principales : le préfixe (FACULTATIF), la commande, et les paramètres de commande (maximum de quinze (15)). Le préfixe, la commande, et tous les paramètres sont chacun séparés par un caractère ASCII espace (0x20).

La présence d’un préfixe est indiquée par un seul caractère ASCII deux-points (':', 0x3a) en tête, qui DOIT être le premier caractère du message lui-même. Il DOIT n’y avoir AUCUN trou (espace) entre le deux-points et le préfixe. Le préfixe est utilisé par les serveurs pour indiquer la vraie origine du message. Si le préfixe manque dans le message, il est supposé avoir été généré sur la connexion d’où il a été reçu. Les clients NE DEVRAIENT PAS utiliser un préfixe lors de l’envoi d’un message ; si ils en utilisent un, le seul préfixe valide est le pseudonyme enregistré associé au client.

La commande DOIT être une commande IRC valide ou un nombre de trois (3) chiffres représentés en texte ASCII.

Les messages IRC sont toujours des lignes de caractères terminées par une paire retour chariot-saut à la ligne (CR-LF, Carriage Return - Line Feed) et ces messages NE DEVRONT PAS excéder 512 caractères, en comptant tous les caractères y compris le CR-LF de queue. Donc, 510 caractères maximum sont alloués pour la commande et ses paramètres. Il n’y a aucune disposition pour la continuation des lignes du message. Voir à la section 6 des précisions sur les mises en œuvre actuelles.

2.3.1	Format de message en BNF augmenté
Les messages du protocole doivent être extraits du flux d’octets contigu. La solution actuelle est de désigner deux caractères, CR et LF, comme séparateurs de message. Les messages vides sont ignorés en silence, ce qui permet d’utiliser la séquence CR-LF entre les messages sans problème supplémentaire.

Le message extrait est analysé dans ses composants <préfixe>, <commande> et liste de paramètres (<params>).

La représentation en BNF augmenté en est :
message	=  [ ":" préfixe ESPACE ] commande [ params ] crlf
préfixe	=  nom_de_serveur / ( pseudonyme [ [ "!" utilisateur ] "@" hôte ] )
commande	=  1*lettre / 3chiffre
params	=  *14( ESPACE milieu ) [ ESPACE ":" en_queue ] =/ 14( ESPACE milieu ) [ ESPACE [ ":" ] en_queue ]
nospcrlfcl	=  %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF 	; tout octet sauf NUL, CR, LF, " " et ":"
milieu	=  nospcrlfcl *( ":" / nospcrlfcl )
en_queue	=  *( ":" / " " / nospcrlfcl )
ESPACE	=  %x20 	; caractère espace
crlf	=  %x0D %x0A	; "retour chariot" "saut à la ligne"

Notes :
1) Après l’extraction de la liste des paramètres, tous les paramètres sont égaux qu’ils correspondent à <milieu> ou à <en_queue>. <en_queue> est juste un tour syntaxique pour permettre une ESPACE au sein du paramètre.

2) Le caractère NUL (%x00) n’est pas un caractère spécial dams la trame de message, et pourrait bien se trouver à l’intérieur d’un paramètre, mais cela causerait une complexité supplémentaire dans le traitement normal de chaîne C. Donc, NUL n’est pas admis au sein des messages.

La plupart des messages du protocole spécifient de la sémantique et de la syntaxe supplémentaire pour les chaînes de paramètre extraites en fonction de leur position dans la liste. Par exemple, de nombreuses commandes de serveur vont supposer que le premier paramètre après la commande est la liste des cibles, ce qui peut être décrit par :

cible	=  pseudonyme / serveur
msgcible	=  msgto *( "," msgto )
msgto	=  canal / ( utilisateur [ "%" hôte ] "@" nom_serveur )
msgto	=/ ( utilisateur "%" hôte ) / chiffre
msgto	=/ pseudonyme / ( pseudonyme "!" utilisateur "@" hôte )
canal	=  ( "#" / "+" / ( "!" canalid ) / "&" ) canalchaîne [ ":" canalchaîne ]
nom_serveur	=  nom_hôte
hôte	=  nom_hôte / adrhôte
nom_hôte	=  petitnom *( "." petitnom )
petitnom	=  ( lettre / chiffre ) [ *( lettre / chiffre / "-" ) *( lettre / chiffre ) ]	; comme spécifié dans la [RFC1123]
adrhôte	=  ip4adr / ip6adr
ip4adr	=  1*3chiffre "." 1*3chiffre "." 1*3chiffre "." 1*3chiffre
ip6adr	=  1*chiffrehex 7( ":" 1*chiffrehex )
ip6adr	=/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4adr
pseudonyme	=  ( lettre / special ) *8( lettre / chiffre / special / "-" )
gabaritcible	=  ( "$" / "#" ) gabarit 	; voir des précisions sur les gabarits admis au paragraphe 3.3.1
canalchaîne	=  %x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
canalchaîne	=/ %x2D-39 / %x3B-FF	; tout octet sauf NUL, BELL, CR, LF, " ", "," et ":"
canalid	= 5( %x41-5A / chiffre )	; 5( A-Z / 0-9 )

Les autres règles de syntaxe de paramètres sont :
utilisateur	=  1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
	; tout octet sauf NUL, CR, LF, " " et "@"
clé	=  1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
	; tout caractère US_ASCII de 7 bits, sauf NUL, CR, LF, FF, h/v TAB, et " "
lettre	=  %x41-5A / %x61-7A	; A-Z / a-z
chiffre	=  %x30-39	; 0 à 9
chiffrehex	=  chiffre / "A" / "B" / "C" / "D" / "E" / "F"
special	=  %x5B-60 / %x7B-7D ; "[", "]", "\", "`", "_", "^", "{", "|", "}"

Notes :
1)	La syntaxe de <adrhôte> n’est donnée ici que dans le but d’indiquer le format à suivre pour les adresses IP. Cela reflète le fait que les seules mises en œuvre disponibles de ce protocole utilisent TCP/IP comme protocole réseau sous-jacent mais cela n’est pas destiné à empêcher l’utilisation d’autres protocoles.
2)	<nom_hôte> a une longueur maximum de 63 caractères. C’est une limitation du protocole car les noms d’hôte Internet (en particulier) peuvent être plus longs. Une telle restriction est nécessaire parce que les messages IRC sont limités à 512 caractères. Les clients qui se connectent à partir d’un hôte dont le nom fait plus de 63 caractères sont enregistrés en utilisant l’adresse (numérique) de l’hôte au lieu du nom de l’hôte.
3)	Certains paramètres utilisés dans les paragraphes suivants de ce document ne sont pas définis ici car il n’y a rien de spécifique à leur sujet en dehors du nom qui est utilisé par convention. Ces paramètres suivent la syntaxe générale définie pour <params>.

2.4	Réponses numériques
La plupart des messages envoyés au serveur génèrent une réponse d’une certaine forme. La réponse la plus courante est la réponse numérique, utilisée à la fois pour les erreurs et pour les réponses normales. La réponse numérique DOIT être envoyée comme un message consistant en le préfixe de l’envoyeur, le numéro à trois chiffres, et la cible de la réponse. Une réponse numérique n’est pas admise si elle a un client pour origine. Sous tous les autres points de vue, une réponse numérique est tout comme un message normal, sauf que le mot clé est constitué de numéros de trois chiffres plutôt que d’une chaîne de lettres. Une liste des différentes réponses est fournie à la Section 5 (Réponses).

2.5	Expressions de caractères génériques
Lorsque les caractères génériques sont autorisés dans une chaîne, on les appelle un "gabarit".

Pour les besoins de la correspondance de chaînes, le protocole permet l’utilisation de caractères spéciaux : '?' (%x3F) pour correspondre à un seul et unique caractère, et '*' (%x2A) pour correspondre à un nombre quelconque de caractères. Ces deux caractères peuvent être esquivés en utilisant le caractère '\' (%x5C).

La syntaxe ABNF pour cela est :
gabarit	=  *( nowild / noesc wildone / noesc wildmany )
wildone	 =  %x3F
wildmany	=  %x2A
nowild	=  %x01-29 / %x2B-3E / %x40-FF 	; tout octet sauf NUL, "*", "?"
noesc	=  %x01-5B / %x5D-FF 	; tout octet sauf NUL et "\"
matchone	=  %x01-FF 	; correspond à wildone
matchmany	=  *matchone 	; correspond à wildmany

Exemples :
a?c	; correspond à toute chaîne de 3 caractères commençant par "a" et se terminant par "c"
a*c	; correspond à toute chaîne d’au moins 2 caractères commençant par "a" et se terminant par "c"

3.	Détails du message

Les pages qui suivent contiennent la description de chacun des message reconnus par le serveur et client IRC. Toutes les commandes décrites dans cette section DOIVENT être mises en œuvre par tout serveur conforme au présent protocole.

Lorsque la réponse ERR_NOSUCHSERVER est retournée, cela signifie que la cible du message n’a pas pu être trouvée. Le serveur NE DOIT PAS envoyer d’autres réponses après cette erreur pour cette commande.

Le serveur auquel un client est connecté est obligé d’analyser le message complet, et de retourner toute erreur appropriée.

Si plusieurs paramètres sont présentés, la validité de chacun d’eux DOIT alors être vérifiée et les réponses appropriées DOIVENT être renvoyées au client. Dans le cas de messages incorrects qui utilisent des listes de paramètres avec des virgules comme séparateur d’élément, une réponse DOIT être envoyée pour chaque élément.

3.1	Enregistrement de connexion
Les commandes décrites ici sont utilisées pour enregistrer comme utilisateur une connexion avec un serveur IRC ainsi que pour se déconnecter correctement.

Une commande "PASS" n’est pas exigée pour qu’une connexion client soit enregistrée, mais elle DOIT précéder la dernière de la combinaison de NICK/USER (pour une connexion d’utilisateur) ou de la commande SERVICE (pour une connexion de service). L’ordre RECOMMANDÉ pour l’enregistrement d’un client est le suivant :

1. Message Pass
2. Message Nick	2. Message Service
3. Message User

En cas de réussite, le client va recevoir un message RPL_WELCOME (pour un utilisateurs) ou RPL_YOURESERVICE (pour un service) qui indique que la connexion est maintenant enregistrée et connue de tout le réseau IRC. Le message de réponse DOIT contenir l’identifiant complet du client avec lequel il s’est enregistré.

3.1.1	Message de mot de passe
Commande : PASS
Paramètres : <mot de passe>

La commande PASS est utilisée pour établir un 'mot de passe de connexion'. Le mot de passe est facultatif et DOIT être réglé avant toute tentative d’enregistrer la connexion. Actuellement, cela exige que l’utilisateur envoie une commande PASS avant d’envoyer la combinaison NICK/USER.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_ALREADYREGISTRED

Exemple :
PASS secretpasswordhere

3.1.2	Message Nick
Commande : NICK
Paramètres : <pseudonyme>

La commande NICK est utilisée pour donner à l’utilisateur un pseudonyme ou changer celui qui existe.

Réponses numériques :
ERR_NONICKNAMEGIVEN	ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE	ERR_NICKCOLLISION
ERR_UNAVAILRESOURCE	ERR_RESTRICTED

Exemples :
NICK Wiz 	; Introduit un nouveau pseudonyme "Wiz" si la session n’est pas encore enregistrée, ou l’utilisateur change son pseudonyme en "Wiz"

:WiZ!jto@tolsun.oulu.fi NICK Kilroy	; Le serveur dit que WiZ a changé son pseudonyme en Kilroy.

3.1.3	Message User
Commande : USER
Paramètres : <utilisateur> <mode> <non utilisé> <nom réel>

La commande USER est utilisée au commencement de la connexion pour spécifier le nom d’utilisateur, le nom d’hôte et le nom réel d’un nouvel utilisateur.

Le paramètre <mode> devrait être un numéro, et il peut être utilisé pour régler automatiquement les modes d’utilisateur lors de l’enregistrement auprès du serveur. Ce paramètre est un gabarit binaire, avec seulement 2 bits qui ont une signification : si le bit 2 est établi (à 1), le mode d’utilisateur 'w' sera établi et si le bit 3 est établi, le mode d’utilisateur 'i' sera établi. (Voir au paragraphe 3.1.5 "Message Mode d’utilisateur").

Le <nom réel> peut contenir des caractères espace.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_ALREADYREGISTRED

Exemple :
USER guest 0 * :Ronnie Reagan	; L’usager s’enregistre lui-même avec un nom d’utilisateur de "guest" et un nom réel de "Ronnie Reagan".

USER guest 8 * :Ronnie Reagan 	; L’usager s’enregistre avec un nom d’utilisateur de "guest" et le nom réel "Ronnie Reagan", et demande que ce soit invisible.

3.1.4	Message Oper
Commande : OPER
Paramètres : <nom> <mot de passe>

Un utilisateur normal utilise la commande OPER pour obtenir les privilèges d’opérateur. La combinaison de <nom> et de <mot de passe> est EXIGÉE pour obtenir les privilèges d’opérateur. En cas de succès, l’utilisateur recevra un message MODE (voir au paragraphe 3.1.5) indiquant les nouveaux modes d’utilisateur.

Réponses numériques :
ERR_NEEDMOREPARAMS	RPL_YOUREOPER
ERR_NOOPERHOST	ERR_PASSWDMISMATCH

Exemple :
OPER foo bar	; tentative de s’enregistrer comme opérateur en utilisant un nom d’utilisateur de "foo" et "bar" comme mot de passe.

3.1.5	Message Mode d’utilisateur
Commande : MODE
Paramètres : <pseudonyme> *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )

Les modes d’utilisateur sont normalement des changements qui affectent la façon dont le client est vu par les autres ou quels messages supplémentaires sont envoyés au client.

Une commande MODE d’utilisateur DOIT n’être acceptée que si l’envoyeur du message et le pseudonyme donné comme paramètre sont le même. Si aucun autre paramètre n’est donné, le serveur va alors retourner les réglages actuels pour le pseudonyme.

Les modes disponibles sont les suivants :
a – l’utilisateur est marqué comme absent ;
i – l’utilisateur est marqué comme invisible ;
w – l’utilisateur reçoit un avertissement ;
r – apporte des restrictions à la connexion de l’utilisateur ;
o – fanion d’opérateur ;
O – fanion d’opérateur local ;
s – marque un utilisateur pour la réception de notices du serveur.

Des modes supplémentaires pourraient devenir disponibles ultérieurement.

Le fanion 'a' NE DEVRA PAS être modifié par l’utilisateur en utilisant la commande MODE. L’utilisation de la commande AWAY est EXIGÉE.

Si un utilisateur tente de se changer lui-même en opérateur en utilisant le fanion "+o" ou "+O", la tentative DEVRAIT être ignorée car les utilisateurs pourraient outrepasser les mécanismes d’authentification de la commande OPER. Il n’y a pas cependant de restriction sur le fait que quiconque se défasse lui-même du statut d’opérateur (en utilisant "-o" ou "-O").

D’un autre côté, si un utilisateur tente de supprimer lui-même toutes les restrictions qui l’affectent en utilisant le fanion "-r", la tentative DEVRAIT être ignorée. Il n’y a cependant pas de restriction à ce que quiconque se défasse de ses privilèges (en utilisant "+r"). Ce fanion est normalement établi par le serveur au moment de la connexion pour des raisons administratives. Bien que les restrictions imposées soient au choix de la mise en œuvre, un utilisateur restreint ne sera normalement pas autorisé à changer de pseudonyme, ni à faire usage du statut d’opérateur du canal sur les canaux.

Le fanion 's' est obsolète mais PEUT encore être utilisé.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_USERSDONTMATCH
ERR_UMODEUNKNOWNFLAG	RPL_UMODEIS

Exemples :
MODE WiZ –w	; Commande de WiZ pour arrêter la réception des messages WALLOPS.
MODE Angel +i	; Commande de Angel pour se rendre invisible.
MODE WiZ –o	; WiZ se “déoppe“ (se retire le statut d’opérateur).

3.1.6	Message Service
Commande : SERVICE
Paramètres : <pseudonyme> <réservé> <distribution> <type> <réservé> <info>

La commande SERVICE est utilisée pour enregistrer un nouveau service. Les paramètres de la commande spécifient pour un nouveau service le pseudonyme du service, sa distribution, son type et ses informations.

Le paramètre <distribution> est utilisé pour spécifier la visibilité d’un service. Le service peut n’être connu que des serveurs qui ont un nom qui correspond à la distribution. Pour qu’un serveur correspondant ait connaissance du service, le chemin réseau entre ce serveur et le serveur sur lequel le service est connecté DOIT être composé de serveurs dont les noms correspondent tous au gabarit.

Le paramètre <type> est actuellement réservé pour une utilisation future.

Réponses numériques :
ERR_ALREADYREGISTRED	ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE	RPL_YOURHOST
RPL_MYINFO

Exemple :
SERVICE dict * *.fr 0 0 :French Dictionary	; Service s’enregistrant sous le nom de "dict". Ce service ne sera disponible que sur les serveurs dont le nom correspond à "*.fr".

3.1.7	Message Quit
Commande : QUIT
Paramètres : [ <Quit Message> ]

Une session client se termine par un message quit. Le serveur en accuse réception par l’envoi au client d’un message ERROR.

Réponse numérique : Aucune

Exemples :
QUIT :Parti déjeuner	; format de message préféré.
:syrk!kalt@millennium.stealth.net QUIT :Parti déjeuner	; l’usager syrk a quitté IRC pour aller déjeuner.

3.1.8	Message Squit
Commande : SQUIT
Paramètres : <serveur> <commentaire>

La commande SQUIT n’est disponible qu’aux opérateurs. Elle est utilisée pour déconnecter les liaisons de serveur. Les serveurs peuvent aussi générer des messages SQUIT dans des conditions d’erreur. Un message SQUIT peut aussi cibler une connexion de serveur distant. Dans ce cas, le message SQUIT va simplement être envoyé au serveur distant sans affecter les serveurs situés entre l’opérateur et le serveur distant.

Le <commentaire> DEVRAIT être fourni par tous les opérateurs qui exécutent une commande SQUIT pour un serveur distant. Le serveur auquel il est ordonné de déconnecter son homologue génère un message WALLOPS avec un <commentaire> inclus, de sorte que les autres utilisateurs puissent être informés de la raison de cette action.

Réponses numériques :
ERR_NOPRIVILEGES	ERR_NOSUCHSERVER	ERR_NEEDMOREPARAMS

Exemples :
SQUIT tolsun.oulu.fi :mauvaise liaison ?  	; Commande au serveur tolson.oulu.fi de terminer sa  connexion, avec le commentaire "mauvaise liaison".
:Trillian SQUIT cm22.eng.umd.edu :Serveur hors de contrôle	; Commande de Trillian de déconnecter du réseau "cm22.eng.umd.edu" avec le commentaire "Serveur hors de contrôle".

3.2	Opérations du canal
Ce groupe de messages concerne la manipulation des canaux, de leurs propriétés (les modes de canal) et leur contenu (en fait les utilisateurs). Pour cette raison, ces messages NE DEVRONT PAS être disponibles aux services.

Tous ces messages sont des demandes qui seront accordées ou non par le serveur. Le serveur DOIT envoyer une réponse qui informe l’utilisateur de la satisfaction de la demande, de son refus, ou génère une erreur. Lorsque le serveur satisfait la demande, le message est normalement renvoyé (éventuellement reformaté) à l’utilisateur avec le préfixe réglé à l’utilisateur lui-même.

Les règles qui gouvernent la façon dont sont gérés les canaux sont mises en application par les serveurs. Ces règles sortent du domaine d’application du présent document. Des précisions sont fournies dans la [RRC2811] "Relais de la causette Internet : gestion de canal".

3.2.1	Message Join
Commande : JOIN
Paramètres : ( <canal> *( "," <canal> ) [ <clé> *( "," <clé> ) ] ) / "0"

La commande JOIN est utilisée par un utilisateur pour demander à commencer d’écouter sur le canal spécifié. Les serveurs DOIVENT être  capables d’analyser les arguments sous la forme d’une liste de cibles, mais NE DEVRAIENT PAS utiliser les listes lors de l’envoi de messages JOIN aux clients.

Une fois qu’un utilisateur s’est joint à un canal, il reçoit des informations sur toutes les commandes que reçoit son serveur et qui affectent le canal. Cela inclut les commandes JOIN, MODE, KICK, PART, QUIT et bien sûr PRIVMSG/NOTICE. Cela permet aux membres du canal d’être informés des autres membres du canal, ainsi que des modes du canal.

Si une commande JOIN réussit, l’utilisateur reçoit un message JOIN en confirmation et on lui envoie ensuite les sujets (topic) du canal (en utilisant RPL_TOPIC) et la liste des utilisateurs qui sont sur le canal (avec RPL_NAMREPLY) qui DOIT inclure l’utilisateur qui vient de s’y joindre.

Noter que ce message accepte un argument ("0") particulier, qui est une demande spéciale de quitter tous les canaux dont l’utilisateur est actuellement membre. Le serveur va traiter ce message comme si l’utilisateur avait envoyé une commande PART (voir au paragraphe 3.2.2) pour chaque canal dont il est membre.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN	ERR_BADCHANNELKEY
ERR_CHANNELISFULL	ERR_BADCHANMASK
ERR_NOSUCHCHANNEL	ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS	ERR_UNAVAILRESOURCE
RPL_TOPIC

Exemples :
JOIN #foobar	; Commande pour se joindre au canal #foobar.
JOIN &foo fubar	; Commande pour se joindre au canal &foo en utilisant la clé "fubar".
JOIN #foo,&bar fubar	; Commande pour se joindre au canal #foo avec la clé "fubar" et &bar sans clé.
JOIN #foo,#bar fubar,foobar	; Commande pour se joindre au canal #foo avec la clé "fubar", et au canal #bar avec la clé "foobar".
JOIN #foo,#bar	; Commande pour se joindre aux canaux #foo et #bar.
JOIN 0	; Quitter tous les canaux actuellement rejoins.
:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone	; message JOIN de WiZ sur le canal #Twilight_zone

3.2.2	Message Part
Commande : PART
Paramètres : <canal> *( "," <canal> ) [ <Message Part> ]

La commande PART cause l’envoi par l’utilisateur du message à retirer de la liste des membres actifs pour tous les canaux figurant sur la liste de la chaîne de paramètres. Si un "Message Part" est donné, il sera envoyé à la place du message par défaut, le pseudonyme. Cette demande est toujours accordée par le serveur.

Les serveurs DOIVENT être capables d’analyser les arguments sous la forme d’une liste de cibles, mais ils NE DEVRAIENT PAS utiliser les listes lors de l’envoi de messages PART aux clients.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL

Exemples :
PART #twilight_zone 	; Commande de quitter le canal "#twilight_zone"
PART #oz-ops,&group5 	; Commande de quitter les deux canaux "&group5" et "#oz-ops".
:WiZ!jto@tolsun.oulu.fi PART #playzone :I lost	; L’usager WiZ quitte le canal "#playzone" avec le message "I lost".

3.2.3	Message Mode de canal
Commande : MODE
Paramètres : <canal> *( ( "-" / "+" ) *<modes> *<modeparams> )

La commande MODE est fournie de façon à ce que les utilisateurs puissent interroger et changer les caractéristiques d’un canal. Pour des précisions sur les modes disponibles et leur utilisation, voir la [RFC2811] "Relais de causette Internet : gestion de canal". Noter qu’il y a une limite maximum de trois (3) changements par commande pour les modes qui prennent un paramètre.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_KEYSET
ERR_NOCHANMODES	ERR_CHANOPRIVSNEEDED
ERR_USERNOTINCHANNEL	ERR_UNKNOWNMODE
RPL_CHANNELMODEIS	ERR_NOSUCHCHANNEL
RPL_BANLIST	RPL_ENDOFBANLIST
RPL_EXCEPTLIST	RPL_ENDOFEXCEPTLIST
RPL_INVITELIST	RPL_ENDOFINVITELIST
RPL_UNIQOPIS

Les exemples qui suivent sont données pour aider à comprendre la syntaxe de la commande MODE, mais se réfèrent aux modes définis dans la [RFC2811] "Relais de causette Internet : gestion de canal".

Exemples :
MODE #Finnish +imI *!*@*.fi	; Commande pour rendre modéré le canal #Finnish et 'seulement sur invitation' avec des utilisateurs ayant un nom d’hôte correspondant à *.fi invités automatiquement.
MODE #Finnish +o Kilroy	; Commande pour donner les privilèges 'chanop' à Kilroy sur le canal #Finnish.
MODE #Finnish +v Wiz	; Commande pour permettre à WiZ de parler sur #Finnish.
MODE #Fins –s	; Commande pour retirer le fanion 'secret' du canal #Fins.
MODE #42 +k oulu	; Commande pour régler la clé de canal à "oulu".
MODE #42 -k oulu	; Commande pour retirer la clé de canal "oulu" sur le canal "#42".
MODE #eu-opers +l 10	; Commande pour régler à 10 la limite du nombre d’utilisateurs sur le canal "#eu-opers".
:WiZ!jto@tolsun.oulu.fi MODE #eu-opers –l	; L’utilisateur "WiZ" retire la limite du nombre d’utilisateurs sur le canal "#eu-opers".
MODE &oulu +b	; Commande pour faire la liste des gabarits d’interdiction réglés pour le canal "&oulu".
MODE &oulu +b *!*@*	; Commande pour empêcher tous les utilisateurs de se joindre à "&oulu".
MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu	; Commande pour empêcher tout utilisateur avec un nom d’hôte correspondant à *.edu de se joindre, sauf si il correspond à *.bu.edu
MODE #bu +be *!*@*.edu *!*@*.bu.edu	; Commentaire pour empêcher tout utilisateur avec un nom d’hôte correspondant à *.edu de se joindre, sauf si il correspond à *.bu.edu
MODE #meditation e	; Commande pour faire la liste des gabarits d’exception réglés pour le canal "#meditation".
MODE #meditation I	; Commande pour faire la liste des gabarits d’invitations établis pour le canal "#meditation".
MODE !12345ircd O	; Commande pour demander qui est le créateur de canal pour "!12345ircd".

3.2.4	Message Topic
Commande : TOPIC
Paramètres : <canal> [ <sujet> ]
La commande TOPIC est utilisée pour changer/ouvrir le sujet d’un canal. Le sujet pour le canal <canal> est retourné si il n’y a pas de <sujet> donné. Si le paramètre <sujet> est présent, le sujet de ce canal sera changé, si cette action est permise à l’utilisateur qui la demande. Si le paramètre <sujet> est une chaîne vide, le sujet de ce canal sera supprimé.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_NOTONCHANNEL
RPL_NOTOPIC	RPL_TOPIC
ERR_CHANOPRIVSNEEDED	ERR_NOCHANMODES
ERR_NOSUCHCHANNEL

Exemples :
:WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic	; L’utilisateur Wiz établit le sujet.
TOPIC #test :another topic	; Commande pour régler le sujet sur #test à "another topic".TOPIC #test : 	; Commande pour supprimer le sujet sur #test.
TOPIC #test 	; Commande pour vérifier le sujet sur #test.

3.2.5	Message Names
Commande : NAMES
Paramètres : [ <canal> *( "," <canal> ) [ <cible> ] ]

En utilisant la commande NAMES, un utilisateur peut faire la liste de tous les pseudonymes qui lui sont visibles. Pour des précision sur ce qui est visible et ce qui ne l’est pas, voir la [RFC2811] "Relais de causette Internet : gestion de canal". Le paramètre <canal> spécifie sur quel ou quels canaux retourner des informations. Il n’y a pas de réponse d’erreur pour de mauvais noms de canal.

Si aucun paramètre <canal> n’est donné, il est retourné une liste de tous les canaux et de leurs occupants. À la fin de cette liste, une liste des utilisateurs qui sont visibles mais soit ne sont sur aucun canal, soit sont sur un canal qui n’est pas visible, sont énumérés comme étant sur le `canal' "*".

Si le paramètre <cible>  est spécifié, la demande est transmise au serveur qui va générer la réponse.

Les caractères génériques (wildcards) sont autorisés dans le paramètre <cible> .

Réponses numériques :
ERR_TOOMANYMATCHES 	ERR_NOSUCHSERVER
RPL_NAMREPLY 	RPL_ENDOFNAMES

Exemples :
NAMES #twilight_zone,#42	; Commande pour faire la liste des utilisateurs visibles sur #twilight_zone et #42
NAMES 	; Commande pour faire la liste de tous les canaux et utilisateurs visibles.

3.2.6	Message List
Commande : LIST
Paramètres : [ <canal> *( "," <canal> ) [ <cible> ] ]

La commande list est utilisée pour faire la liste des canaux et de leur sujet. Si le paramètre <canal> est utilisé, seul l’état de ces canaux est affiché.

Si le paramètre <cible> est spécifié, la demande est transmise au serveur qui va générer la réponse.

Les caractères génériques sont admis dans le paramètre <cible>.

Réponses numériques :
ERR_TOOMANYMATCHES	ERR_NOSUCHSERVER
RPL_LIST 	RPL_LISTEND

Exemples :
LIST 	; Commande pour faire la liste de tous les canaux.
LIST #twilight_zone,#42 	; Commande pour faire la liste des canaux #twilight_zone et #42

3.2.7	Message Invite
Commande : INVITE
Paramètres : <pseudonyme> <canal>

La commande INVITE est utilisée pour inviter un utilisateur sur un canal. Le paramètre <pseudonyme> est le pseudonyme de la personne à inviter sur le canal cible <canal>. Il n’y a pas d’exigence que le canal sur lequel l’utilisateur cible est invité doive exister ou soit un canal valide. Cependant, si le canal existe, seuls les membres du canal sont autorisés à inviter d’autres utilisateurs. Lorsque le canal a le fanion Seulement_sur_invitation établi, seuls les opérateurs de canal peuvent produire une commande INVITE.

Seuls l’utilisateur invitant et l’utilisateur invité vont recevoir la notification de l’invitation. Les autres membres du canal ne sont pas notifiés. (C’est différent des changements de MODE, et est à l’occasion une source de trouble pour les utilisateurs.)

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_NOSUCHNICK
ERR_NOTONCHANNEL	ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING	RPL_AWAY

Exemples :
:Angel!wings@irc.org INVITE Wiz #Dust	; Message à WiZ quand il a été invité par l’utilisateur Angel sur le canal #Dust
INVITE Wiz #Twilight_Zone 	; Commande pour inviter WiZ à #Twilight_zone

3.2.8	Commande Kick
Commande : KICK
Paramètres : <canal> *( "," <canal> ) <utilisateur> *( "," <utilisateur> ) [<commentaire>]

La commande KICK peut être utilisée pour demander le retrait forcé d’un utilisateur d’un canal. Elle cause le départ de force de <utilisateur> de <canal>. Pour que le message soit syntaxiquement correct, il DOIT y avoir un paramètre canal et plusieurs paramètres utilisateur, ou autant de paramètres canal qu’il y a de paramètres utilisateur. Si un "commentaire" est donné, il sera envoyé à la place du message par défaut qui est le pseudonyme de l’utilisateur produisant le KICK.

Le serveur NE DOIT PAS envoyer de message KICK avec plusieurs canaux ou utilisateurs aux clients. Cela est nécessaire pour conserver la rétro compatibilité avec les vieux logiciels client.

Réponses numériques :
ERR_NEEDMOREPARAMS	ERR_NOSUCHCHANNEL
ERR_BADCHANMASK 	ERR_CHANOPRIVSNEEDED
ERR_USERNOTINCHANNEL 	ERR_NOTONCHANNEL

Exemples :
KICK &Melbourne Matthew	; Commande pour sortie Matthew de &Melbourne
KICK #Finnish John :Speaking English 	; Commande pour sortir John de #Finnish avec "Speaking English" comme cause (commentaire).
:WiZ!jto@tolsun.oulu.fi KICK #Finnish John 	; Message KICK sur le canal #Finnish de la part de WiZ pour retirer John du canal

3.3	Envoi des messages
Le principal objet du protocole IRC est de fournir une base aux clients pour communiquer les uns avec les autres. PRIVMSG, NOTICE et SQUERY (décrits au paragraphe 3.5 sur les interrogations et commandes de service) sont les seuls messages disponibles qui effectuent réellement la livraison d’un message de texte d’un client à un autre - le reste le rend juste possible et essaye d’assurer que cela se produit de façon fiable et structurée.

3.3.1	Messages Private
Commande : PRIVMSG
Paramètres : <msgtarget> <texte à envoyer>

PRIVMSG est utilisé pour envoyer des messages privés entre les utilisateurs, ainsi que pour envoyer des messages aux canaux. <msgtarget> est normalement le pseudonyme du receveur du message, ou un nom de canal.

Le paramètre <msgtarget> peut aussi être un gabarit d’hôte (#<gabarit>) ou un gabarit de serveur ($<gabarit>). Dans les deux cas, le serveur va seulement envoyer le PRIVMSG à ceux dont le serveur ou hôte correspond au gabarit. Le gabarit DOIT contenir au moins 1 (un) "." et pas de caractère générique suivant le dernier ".". Cette exigence existe pour empêcher les gens d’envoyer des messages à "#*" ou "$*", qui seraient diffusés à tous les utilisateurs. Les caractères génériques sont les caractères '*' et '?'. Cette extension de la commande PRIVMSG n’est disponible qu’aux opérateurs.

Réponses numériques :
ERR_NORECIPIENT 	ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN 	ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL 	ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAY

Exemples :
:Angel!wings@irc.org PRIVMSG Wiz :As tu reçu ce message ?	; Message de Angel à Wiz.
PRIVMSG Angel :oui, je l’ai reçu ! 	; Commande pour envoyer un message à Angel.
PRIVMSG jto@tolsun.oulu.fi :Hello ! 	; Commande pour envoyer un message à un utilisateur sur le serveur tolsun.oulu.fi avec le nom d’utilisateur de "jto".
PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Es-tu un grenouille ? 	; Message à un utilisateur sur le serveur irc.stealth.net avec le nom d’utilisateur de "kalt", et connecté à partir de l’hôte millennium.stealth.net.
PRIVMSG kalt%millennium.stealth.net :Aimes tu le fromage ?	; Message à un utilisateur sur le serveur local avec le nom d’utilisateur "kalt", et connecté de l’hôte millennium.stealth.net.
PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello ! 	; Message à l’utilisateur avec le pseudonyme Wiz qui est connecté à partir de l’hôte tolsun.oulu.fi et a le nom d’utilisateur "jto".
PRIVMSG $*.fi :Le serveur tolsun.oulu.fi redémarre. 	; Message à tous ceux dont le nom correspond à *.fi sur un serveur.
PRIVMSG #*.edu :NSFNet subit des travaux, s’attendre à des interruptions 	; Message à tous les utilisateurs qui viennent d’un hôte dont le nom correspond avec *.edu.

3.3.2	Notice
Commande : NOTICE
Paramètres : <msgtarget> <texte>

La commande NOTICE est utilisée de la même façon que PRIVMSG. La différence entre NOTICE et PRIVMSG est que les réponses automatiques NE DOIVENT PAS être envoyées en réponse à un message NOTICE. Cette règle s’applique aussi aux serveurs – ils NE DOIVENT PAS renvoyer de réponse d’erreur au client à réception d’une notice. L’objet de cette règle est d’éviter des boucles entre clients qui envoient automatiquement quelque chose en réponse à ce qu’ils reçoivent.

Cette commande est disponible aussi bien aux services qu’aux utilisateurs.

Elle est normalement utilisée par les services, et les automates (clients avec un AI ou autre programme interactif qui contrôle leurs actions).

Voir au paragraphe précédent PRIVMSG les détails sur les réponses et les exemples.

3.4	Commandes d’interrogations de serveur
Le groupe de commandes d’interrogation de serveur a été conçu pour retourner des informations sur tout serveur qui est connecté au réseau.

Dans ces interrogations, où un paramètre apparaît comme <cible>, les gabarits de caractères génériques sont normalement valides. Pour chaque paramètre, cependant, seule une interrogation et ensemble de réponses est à générer. Dans la plupart des cas, si un pseudonyme est donné, il va signifier le serveur auquel l’utilisateur est connecté.

Ces messages n’ont normalement que peu de valeur pour les services, il est donc RECOMMANDÉ d’interdire aux services de les utiliser.

3.4.1	Message Motd
Commande : MOTD
Paramètres : [ <cible> ]

La commande MOTD est utilisée pour obtenir le "Mot d’ordre du jour" d’un certain serveur, ou du serveur actuel si <cible> est omis.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
RPL_MOTDSTART	RPL_MOTD
RPL_ENDOFMOTD	ERR_NOMOTD

3.4.2	Message Lusers
Commande : LUSERS
Paramètres : [ <gabarit> [ <cible> ] ]

La commande LUSERS est utilisée pour obtenir des statistiques sur la taille du réseau IRC. Si aucun paramètre n’est donné, la réponse sera sur l’ensemble du réseau. Si un <gabarit> est spécifié, la réponse ne concernera alors que la partie du réseau formée par les serveurs qui correspondent au gabarit. Enfin, si le paramètre <cible> est spécifié, la demande sera transmise au serveur qui va générer la réponse.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
RPL_LUSERCLIENT	RPL_LUSEROP
RPL_LUSERUNKOWN	RPL_LUSERCHANNELS
RPL_LUSERME	ERR_NOSUCHSERVER

3.4.3	Message Version
Commande : VERSION
Paramètres : [ <cible> ]

La commande VERSION est utilisée pour demander la version du programme de serveur. Un paramètre facultatif <cible> est utilisé pour demander la version du programme de serveur auquel un client n’est pas directement connecté.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
ERR_NOSUCHSERVER	RPL_VERSION

Exemple :
VERSION tolsun.oulu.fi	; Commande pour vérifier la version du serveur "tolsun.oulu.fi".

3.4.4	Message Stats
Commande : STATS
Paramètres : [ <interrogation> [ <cible> ] ]

La commande stats est utilisée pour demander les statistiques d’un certain serveur. Si le paramètre <interrogation> est omis, seule la fin de la réponse stats est renvoyée.

Une interrogation peut être formulée pour toute lettre seule qui est seulement vérifiée par le serveur de destination et est autrement passée aux serveurs intermédiaires, ignorée et non altérée.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Sauf pour ceux qui figurent ci-dessous, la liste des interrogations valides dépend de la mise en œuvre. Les interrogations standard figurant ci-dessous DEVRAIENT être prises en charge par le serveur :
l – retourne une liste des connexions du serveur, montrant depuis combien de temps chaque connexion a été établie et le trafic sur cette connexion en koctets et les messages pour chaque direction ;
m – retourne le compte d’usage pour chaque commande prise en charge par le serveur ; les commandes pour lesquelles le compte d’usage est zéro PEUVENT être omises ;
o – retourne une liste des utilisateurs privilégiés et des opérateurs configurés ;
u – retourne une chaîne montrant depuis combien de temps le serveur est en fonction.

Il est aussi RECOMMANDÉ que la configuration d’accès du client et du serveur soit publiée de cette façon.

Réponses numériques :
ERR_NOSUCHSERVER
RPL_STATSLINKINFO	RPL_STATSUPTIME
RPL_STATSCOMMANDS	RPL_STATSOLINE
RPL_ENDOFSTATS

Exemple :
STATS m 	; Commande pour vérifier l’usage de la commande pour le serveur auquel on est connecté.

3.4.5	Message Links
Commande : LINKS
Paramètres : [ [ <serveur distant> ] <gabarit de serveur> ]

Avec LINKS, un utilisateur peut faire la liste de tous les noms de serveur qui sont connus du serveur qui répond à l’interrogation. La liste de serveurs retournée DOIT correspondre au gabarit, ou si un gabarit n’est pas donné, la liste complète est retournée.

Si <serveur distant> est donné en plus de <gabarit de serveur>, la commande LINKS est transmise au premier serveur trouvé qui correspond à ce nom (s’il en est) et ce serveur est alors obligé de répondre à l’interrogation.

Réponses numériques :
ERR_NOSUCHSERVER
RPL_LINKS	RPL_ENDOFLINKS

Exemples :
LINKS *.au 	; Commande pour faire la liste de tous les serveurs qui ont un nom correspondant à *.au;
LINKS *.edu *.bu.edu 	; Commande pour faire la liste des serveurs correspondant à *.bu.edu telle que vue par le premier serveur correspondant à *.edu.

3.4.6	Message Time
Commande : TIME
Paramètres : [ <cible> ]

La commande time est utilisée pour demander l’heure locale au serveur spécifié. Si le paramètre <cible> n’est pas fourni, le serveur qui reçoit la commande doit répondre à l’interrogation.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
ERR_NOSUCHSERVER 	RPL_TIME

Exemple :
TIME tolsun.oulu.fi 	; vérifie l’heure sur le serveur "tolson.oulu.fi"

3.4.7	Message Connect
Commande : CONNECT
Paramètres : <serveur cible> <accès> [ <serveur distant> ]

La commande CONNECT peut être utilisée pour demander à un serveur d’essayer d’établir immédiatement une nouvelle connexion avec un autre serveur. CONNECT est une commande privilégiée et DEVRAIT n’être disponible qu’aux opérateurs IRC. Si un <serveur distant> est donné et si son gabarit ne correspond pas au nom du serveur qui analyse, la tentative de CONNECT est envoyée à la première correspondance de serveur distant. Autrement, la tentative de CONNECT est faite par le serveur qui traite la demande.

Le serveur qui reçoit une commande CONNECT distante DEVRAIT générer un message WALLOPS décrivant la source et la cible de la demande.

Réponses numériques :
ERR_NOSUCHSERVER	ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMS

Exemple :
CONNECT tolsun.oulu.fi 6667	; Commande pour tenter de connecter le serveur local à tolsun.oulu.fi sur l’accès 6667.

3.4.8	Message Trace
Commande : TRACE
Paramètres : [ <cible> ]

La commande TRACE est utilisée pour trouver le chemin vers un serveur spécifique et des informations sur ses homologues. Chaque serveur qui traite cette commande DOIT en faire rapport à son envoyeur. Les réponses provenant des liaisons traversées forment une chaîne, qui montre le chemin vers la destination. Après avoir renvoyé cette réponse, l’interrogation DOIT être envoyée au prochain serveur jusqu’à ce que soit atteint le serveur <cible> désigné.

La commande TRACE est utilisée pour trouver le chemin vers un serveur spécifique. Chaque serveur qui traite ce message DOIT le dire à l’envoyeur par l’envoi d’une réponse qui indique qu’il est une liaison traversée, formant une chaîne de réponses. Après le renvoi de cette réponse, il DOIT alors envoyer le message TRACE au prochain serveur jusqu’à ce que le serveur spécifié soit atteint. Si le paramètre <cible> est omis, il est RECOMMANDÉ que la commande TRACE envoie un message à l’envoyeur pour lui dire à quels serveurs le serveur local a une connexion directe.

Si la destination donnée par <cible> est un serveur réel, il est EXIGÉ du serveur de destination qu’il fasse rapport de tous les serveurs, services et opérateurs qui lui sont connectés ; si la commande a été produite par un opérateur, le serveur PEUT aussi faire rapport de tous les utilisateurs qui lui sont connecté. Si la destination donnée par <cible> est un pseudonyme, seule une réponse pour ce pseudonyme est alors donnée. Si le paramètre <cible> est omis, il est RECOMMANDÉ que la commande TRACE soit analysée comme ciblée sur le serveur de traitement.

Les caractères génériques sont autorisés dans le paramètre <cible> .

Réponses numériques :
ERR_NOSUCHSERVER

Si le message TRACE est destiné à un autre serveur, tous les serveurs intermédiaires doivent retourner une réponse RPL_TRACELINK pour indiquer que TRACE est passé à travers eux et où il allait ensuite.

RPL_TRACELINK

Une réponse TRACE peut être composée d’un nombre quelconque des réponses numériques suivantes.
RPL_TRACECONNECTING	RPL_TRACEHANDSHAKE
RPL_TRACEUNKNOWN	RPL_TRACEOPERATOR
RPL_TRACEUSER	RPL_TRACESERVER
RPL_TRACESERVICE	RPL_TRACENEWTYPE
RPL_TRACECLASS 	RPL_TRACELOG
RPL_TRACEEND

Exemple :
TRACE *.oulu.fi 	; TRACE vers un serveur correspondant à *.oulu.fi

3.4.9	Commande Admin
Commande : ADMIN
Paramètres : [ <cible> ]

La commande admin est utilisée pour trouver des informations sur l’administrateur du serveur désigné, ou du serveur actuel si le paramètre <cible> est omis. Chaque serveur DOIT avoir la capacité de transmettre les messages ADMIN aux autres serveurs.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
ERR_NOSUCHSERVER
RPL_ADMINME	RPL_ADMINLOC1
RPL_ADMINLOC2	RPL_ADMINEMAIL

Exemples :
ADMIN tolsun.oulu.fi	; demande une réponse ADMIN de la part de tolsun.oulu.fi
ADMIN syrk	; demande ADMIN pour le serveur auquel l’utilisateur syrk est connecté.

3.4.10	Commande Info
Commande : INFO
Paramètres : [ <cible> ]

La commande INFO est EXIGÉE pour retourner des informations qui décrivent le serveur : sa version, quand il a été compilé, le niveau de correction, quand il a été démarré, et toutes les autres informations diverses qui peuvent être considérées comme pertinentes.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
ERR_NOSUCHSERVER
RPL_INFO 	RPL_ENDOFINFO

Exemples :
INFO csd.bu.edu 	; demande une réponse INFO de la part de csd.bu.edu
INFO Angel	; demande des informations de la part du serveur auquel Angel est connecté.

3.5	Interrogations et commandes de service
Le groupe de commandes d’interrogation de service a été conçu pour retourner des informations sur tout service qui est connecté au réseau.

3.5.1	Message Servlist
Commande : SERVLIST
Paramètres : [ <gabarit> [ <type> ] ]

La commande SERVLIST est utilisée pour faire la liste des services actuellement connectés au réseau et visibles à l’utilisateur qui produit la commande. Les paramètres facultatifs peuvent être utilisés pour restreindre le résultat de l’interrogation (aux noms de services qui correspondent, et aux types de service).

Réponses numériques :
RPL_SERVLIST	RPL_SERVLISTEND

3.5.2	Squery
Commande : SQUERY
Paramètres : <nom de service> <texte>

La commande SQUERY est utilisée de la même façon que PRIVMSG. La seule différence est que le receveur DOIT être un service. C’est la seule façon qu’a un message de texte d’être livré à un service.

Voir à PRIVMSG (paragraphe 3.3.1) des précisions sur les réponses et des exemples.

Exemples :
SQUERY irchelp :HELP privmsg 	 Message au service avec le pseudonyme irchelp.
SQUERY dict@irc.fr :fr2en blaireau 	 Message au service avec le nom dict@irc.fr.

3.6	Interrogations fondées sur l’utilisateur
Les interrogations d’utilisateur sont un groupe de commandes qui concernent principalement la découverte de précisions sur un utilisateur ou groupe d’utilisateurs particulier. Lorsque on utilise des caractères génériques avec l’une de ces commandes, si elles correspondent, elles vont retourner des informations seulement sur les utilisateurs qui sont 'visibles'. La visibilité d’un utilisateur est déterminée comme une combinaison du mode de l’utilisateur et de l’ensemble commun de canaux sur lesquels sont à la fois l’utilisateur et l’interrogateur.

Bien que les services NE DEVRAIENT PAS utiliser cette classe de messages, ils en ont l’autorisation.

3.6.1	Interrogation Who
Commande : WHO
Paramètres : [ <gabarit> [ "o" ] ]

La commande WHO est utilisée par un client pour générer une interrogation qui retourne une liste d’informations qui 'correspondent' au paramètre <gabarit> donné par le client. En l’absence du paramètre <gabarit>, elle fait la liste de tous les utilisateurs visibles (utilisateurs qui ne sont pas invisibles (mode d’utilisateur +i) et qui n’ont pas de canaux communs avec le client demandeur). On peut obtenir le même résultat en utilisant un <gabarit> de "0" ou de tout caractère générique qui va finir par correspondre à chaque utilisateur visible.

Le <gabarit> passé à WHO est confronté à l’hôte, serveur nom réel et pseudonyme des utilisateurs si les canaux <gabarit> ne peuvent pas être trouvés.

Si le paramètre "o" est passé, seuls les opérateurs sont retournés, conformément au <gabarit> fourni.

Réponses numériques :
ERR_NOSUCHSERVER
RPL_WHOREPLY	RPL_ENDOFWHO

Exemples :
WHO *.fi	; Commande pour faire la liste de tous les utilisateurs qui correspondent pour "*.fi".
WHO jto* o	; Commande pour faire la liste de tous les utilisateurs qui ont une correspondance avec "jto*" si ils sont opérateurs.

3.6.2	Interrogation Whois
Commande : WHOIS
Paramètres : [ <cible> ] <gabarit> *( "," <gabarit> )

Cette commande est utilisée pour demander des informations sur un utilisateur particulier. Le serveur va répondre à cette commande avec plusieurs messages numériques qui indiquent les différents statuts de chaque utilisateur qui correspond au gabarit (si le demandeur a le droit de les voir). Si aucun caractère générique n’est présent dans le <gabarit>, toute information autorisée au demandeur sur ce pseudonyme sera présentée.

Si le paramètre <cible> est spécifié, l’interrogation est envoyée à un serveur spécifique. Elle est utile si on veut savoir depuis combien de temps l’utilisateur en question a été inactif, car seul le serveur local (c’est-à-dire, le serveur auquel l’utilisateur est directement connecté) connaît ces informations, alors que tout le reste est connu de tous.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
ERR_NOSUCHSERVER	ERR_NONICKNAMEGIVEN
RPL_WHOISUSER	RPL_WHOISCHANNELS
RPL_WHOISCHANNELS	RPL_WHOISSERVER
RPL_AWAY	RPL_WHOISOPERATOR
RPL_WHOISIDLE	ERR_NOSUCHNICK
RPL_ENDOFWHOIS

Exemples :
WHOIS wiz	; retourne les informations d’utilisateur disponibles sur le pseudonyme WiZ.
WHOIS eff.org trillian	; demande au serveur eff.org les informations d’utilisateur sur trillian.

3.6.3	Interrogation Whowas
Commande : WHOWAS
Paramètres : <pseudonyme> *( "," <pseudonyme> ) [ <compte> [ <cible> ] ]

Whowas demande des informations sur un pseudonyme qui n’existe plus. Cela peut être dû à un changement de pseudonyme où au départ de l’utilisateur de l’IRC. En réponse à cette interrogation, le serveur cherche dans son historique des pseudonymes, examinant tous les alias qui sont lexicalement les mêmes (pas de correspondance avec caractère générique ici). L’historique est remonté, pour retourner d’abord les entrées les plus récentes. Si il y a plusieurs entrées, jusqu’à <compte> réponses seront retournées (ou toutes si aucun paramètre <compte> n’est donné). Si un nombre non positif est passé pour <compte>, une recherche complète est alors effectuée.

Les caractères génériques sont autorisés dans le paramètre <cible>.

Réponses numériques :
ERR_NONICKNAMEGIVEN	ERR_WASNOSUCHNICK
RPL_WHOWASUSER	RPL_WHOISSERVER
RPL_ENDOFWHOWAS

Exemples :
WHOWAS Wiz	; retourne toutes les information de l’historique des pseudos sur le pseudonyme "WiZ";
WHOWAS Mermaid 9	; retourne au plus, les neuf plus récentes entrées de l’historique des pseudonymes sur  "Mermaid";
WHOWAS Trillian 1 *.edu	; retourne l’historique le plus récent pour "Trillian" à partir du premier serveur trouvé pour correspondre à "*.edu".

3.7	Messages divers
Les messages de cette catégorie ne rentrent dans aucune des catégories précédentes mais font néanmoins partie du protocole et sont EXIGÉS.

3.7.1	Message Kill
Commande : KILL
Paramètres : <pseudonyme> <commentaire>

La commande KILL est utilisée pour causer la clôture d’une connexion client-serveur par le serveur qui a cette connexion. Les serveurs génèrent des messages KILL en cas de collision de pseudonyme. Elle PEUT aussi être disponible aux utilisateurs qui ont le statut d’opérateur.

Les clients qui ont des algorithmes de reconnexion automatique rendent effectivement cette commande inutile car la déconnexion n’est que brève. Elle casse cependant le flux des données et peut être utilisée pour arrêter de grosses quantités de données en 'arrosage' de la part d’utilisateurs abusifs ou par accident. Les utilisateurs abusifs ne s’en soucient d’habitude guère car ils vont se reconnecter promptement et reprendre leur comportement abusif. Pour empêcher l’abus de cette commande, tout utilisateur peut choisir de recevoir les messages KILL générés pour d’autres pour 'garder un œil' sur les trublions potentiels.

Dans un domaine où il est EXIGÉ que les pseudonymes soient uniques au monde en tout temps, les messages KILL sont envoyés chaque fois que des 'dupliqués' sont détectés (c’est une tentative pour enregistrer deux utilisateurs avec le même pseudonyme) dans l’espoir que les deux vont disparaître et qu’un seul réapparaîtra.

Lorsque un client est retiré par suite d’un message KILL, le serveur DEVRAIT ajouter le pseudonyme à la liste des pseudonymes indisponibles pour tenter d’éviter que des clients réutilisent immédiatement ce nom ce qui est généralement un schéma de comportement abusif menant souvent à des "boucles de KILL" inutiles. Voir dans la [RFC2813] "Protocole du serveur IRC" plus d’informations sur cette procédure.

Le commentaire donné DOIT refléter la raison réelle du KILL. Pour les KILL générés par le serveur, c’est généralement constitué de détails concernant l’origine des deux pseudonymes en conflit. Pour ceux des utilisateurs, il leur appartient de fournir une raison adéquate pour satisfaire ceux qui la voient. Pour empêcher/décourager la génération de KILL frauduleux pour cacher l’identité de l’envoyeur de KILL, le commentaire montre aussi un 'chemin de kill' qui est mis à jour par chaque serveur au travers duquel il passe, chacun ajoutant son nom au chemin.

Réponses numériques :
ERR_NOPRIVILEGES	ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK 	ERR_CANTKILLSERVER

Note :	Il est RECOMMANDÉ que seuls les opérateurs soient autorisés à éliminer d’autres utilisateurs avec la commande KILL. Cette commande a été l’objet de nombreuses controverses pendant des années, et lors de la rédaction de la présente recommandation, il a été aussi largement reconnu que même les opérateurs ne devraient pas être autorisés à éliminer des utilisateurs sur des serveurs distants.

3.7.2	Message Ping
Commande : PING
Paramètres : <serveur1> [ <serveur2> ]

La commande PING est utilisée pour vérifier la présence d’un client ou serveur actif à l’autre bout de la connexion. Les serveurs envoient un message PING à intervalles réguliers si aucune autre activité n’est détectée en provenance d’une connexion. Si une connexion ne répond pas à un message PING dans un certain délai, cette connexion est close. Un message PING PEUT être envoyé même si la connexion est active.

Lorsque un message PING est reçu, le message PONG approprié DOIT être envoyé comme réponse au <serveur1> (le serveur qui a envoyé le message PING) aussitôt que possible. Si le paramètre <serveur2> est spécifié, il représente la cible du ping, et le message lui est transmis.

Réponses numériques :
ERR_NOORIGIN	ERR_NOSUCHSERVER

Exemples :
PING tolsun.oulu.fi 	; Commande d’envoi d’un message PING au serveur.
PING WiZ tolsun.oulu.fi 	; Commande de WiZ d’envoi d’un message PING au serveur "tolsun.oulu.fi".
PING :irc.funet.fi 	; Message Ping envoyé par le serveur "irc.funet.fi".

3.7.3	Message Pong
Commande : PONG
Paramètres : <serveur> [ <serveur2> ]

Le message PONG est une réponse au message Ping. Si le paramètre <serveur2> est donné, ce message DOIT être transmis à la cible désignée. Le paramètre <serveur> est le nom de l’entité qui a répondu au message PING et généré ce message.

Réponses numériques :
ERR_NOORIGIN	ERR_NOSUCHSERVER

Exemple :
PONG csd.bu.edu tolsun.oulu.fi 	; Message PONG provenant de csd.bu.edu à tolsun.oulu.fi

3.7.4	Erreur
Commande : ERROR
Paramètres : <message d’erreur>

La commande ERROR est à utiliser par les serveurs lorsque ils font rapport d’une erreur sérieuse ou fatale à leurs homologues. Elle peut aussi être envoyée d’un serveur à un autre mais NE DOIT être acceptée d’aucun client normal inconnu.

Seul un message ERROR DEVRAIT être utilisé pour rapporter des erreurs qui surviennent sur une liaison de serveur à serveur. Un message ERROR est envoyé au serveur à l’autre extrémité (qui en fait rapport aux utilisateurs et journaux d’événements locaux appropriés) et aux utilisateurs et journaux d’événements locaux appropriés. Il n’est pas à passer par un serveur à d’autres serveurs si il est reçu d’un serveur.

Le message ERROR est aussi utilisé avant de mettre un terme à une connexion de client.

Lorsque un serveur envoie à ses opérateurs un message ERROR reçu, le message DEVRAIT être encapsulé dans un message NOTICE, ce qui indique que le client n’était pas responsable de l’erreur.

Réponse numérique : aucune.

Exemples :
ERROR :Server *.fi existe déjà	 ; message ERROR à l’autre serveur qui a causé cette erreur.
NOTICE WiZ :ERROR de csd.bu.edu -- Serveur *.fi existe déjà	; même message ERROR que ci-dessus mais envoyé à l’utilisateur WiZ sur l’autre serveur.

4.	Caractéristiques facultatives

La présente section décrit des messages FACULTATIFS. Ils ne sont pas obligés dans une mise en œuvre de serveur conforme au protocole décrit ici. En l’absence de la caractéristique, un message de réponse d’erreur ou une erreur Commande inconnue DOIT être généré. Si le message est destiné à un autre serveur pour répondre, il DOIT alors être transmis (une analyse élémentaire est EXIGÉE). Les valeurs numériques pour cela sont données ci-dessous avec les messages.

Dans cette section, seuls les messages USERHOST et ISON sont disponibles aux services.

4.1	Away
Commande : AWAY
Paramètres : [ <texte> ]

Avec une commande AWAY, les clients peuvent établir une chaîne de réponse automatique pour toute commande PRIVMSG dirigée sur eux (pas sur les canaux sur lesquels ils sont). Le serveur envoie une réponse automatique au client qui envoie la commande PRIVMSG. Le seul serveur qui répond est celui auquel est connecté le client envoyeur.

La commande AWAY est utilisée soit avec un paramètre, pour établir un message AWAY, soit sans paramètre, pour retirer le message AWAY.

À cause de son coût élevé (en mémoire et en bande passante) le message AWAY DEVRAIT n’être utilisé que pour la communication client-serveur. Un serveur PEUT choisir d’ignorer en silence les messages AWAY reçus des autres serveurs. Pour mettre à jour l’état ‘away’ d’un client parmi des serveurs, le mode d’utilisateur 'a' DEVRAIT plutôt être utilisé (voir au paragraphe 3.1.5).

Réponses numériques :
RPL_UNAWAY	RPL_NOWAWAY

Exemple :
AWAY :Parti déjeuner. Retour dans 5	; Commande pour régler le message away à "Parti déjeuner. Retour dans 5".

4.2	Message Rehash
Commande : REHASH
Paramètres : None

La commande rehash est une commande administrative qui peut être utilisée par un opérateur pour forcer le serveur à relire et retraiter son fichier de configuration.

Réponses numériques :
RPL_REHASHING	ERR_NOPRIVILEGES

Exemple :
REHASH	; message d’utilisateur avec statut d’opérateur demandant au serveur de relire son fichier de configuration.

4.3	Message Die
Commande : DIE
Paramètres : Aucun

Un opérateur peut utiliser la commande DIE pour fermer le serveur. Ce message est facultatif car il peut être vu comme un risque qu’ell permette à des personnes quelconques de se connecter comme opérateur sur un serveur et d’exécuter cette commande.

La commande DIE DOIT toujours être entièrement traitée par le serveur auquel est connecté le client envoyeur et NE DOIT PAS être passée aux autres serveurs connectés.

Réponse numérique : ERR_NOPRIVILEGES

Exemple :
DIE	; aucun paramètre n’est exigé.

4.4	Message Restart
Commande : RESTART
Paramètres : Aucun

Un opérateur peut utiliser la commande restart pour forcer le serveur à redémarrer. Ce message est facultatif car il peut être vu comme le risque de permettre à des personnes arbitraires de se connecter comme un opérateur à un serveur et d’exécuter cette commande, causant (au moins) une interruption de service.

La commande RESTART DOIT toujours être entièrement traités par le serveur auquel est connecté le client envoyeur et NE DOIT PAS être passée aux autres serveurs connectés.

Réponses numériques : ERR_NOPRIVILEGES

Exemple :
RESTART	; aucun paramètre n’est exigé.

4.5	Message Summon
Commande : SUMMON
Paramètres : <utilisateur> [ <cible> [ <canal> ] ]

La commande SUMMON (convoquer) peut être utilisée pour donner aux utilisateurs qui sont sur un hôte qui fonctionne avec un serveur IRC un message leur demandant de se joindre à IRC. Ce message n’est envoyé que si le serveur cible (a) a la capacité SUMMON, (b) si l’utilisateur est connecté, et (c) si le processus de serveur peut écrire au tty (ou similaire) de l’utilisateur.

Si aucun paramètre<serveur> n’est donné, il essaye de convoquer l’<utilisateur> à partir du serveur auquel le client est connecté qui est supposé être la cible.

Si summon n’est pas activé dans un serveur, il DOIT retourner le numéro ERR_SUMMONDISABLED.

Réponses numériques :
ERR_NORECIPIENT	ERR_FILEERROR
ERR_NOLOGIN	ERR_NOSUCHSERVER
ERR_SUMMONDISABLED	RPL_SUMMONING

Exemples :
SUMMON jto	; convoque l’utilisateur jto sur l’hôte du serveur.
SUMMON jto tolsun.oulu.fi	; convoque l’utilisateur jto sur l’hôte sur lequel fonctionne un serveur nommé "tolsun.oulu.fi".

4.6	Commande Users
Commande : USERS
Paramètres : [ <cible> ]

La commande USERS retourne une liste d’utilisateurs enregistrés auprès du serveur sous un format similaire aux commandes UNIX who(1), rusers(1) et finger(1). Si elle est désactivée, le numéro correct DOIT être retourné pour l’indiquer.

À cause des implications d’une telle commande pour la sécurité, elle DEVRAIT être désactivée par défaut dans les mises en œuvre de serveur. L’activer DEVRAIT exiger de recompiler le serveur ou quelque changement équivalent plutôt que de simplement basculer une option et redémarrer le serveur. La procédure pour activer cette commande DEVRAIT aussi inclure des longs commentaires appropriés.

Réponses numériques :
ERR_NOSUCHSERVER	ERR_FILEERROR
RPL_USERSSTART 	RPL_USERS
RPL_NOUSERS  	RPL_ENDOFUSERS
ERR_USERSDISABLED

Réponse désactivée : ERR_USERSDISABLED

Exemple :
USERS eff.org 	; demande une liste des utilisateurs enregistrés auprès du serveur eff.org

4.7	Message Operwall
Commande : WALLOPS
Paramètres : <texte à envoyer>

La commande WALLOPS est utilisée pour envoyer un message à tous les utilisateurs actuellement connectés qui ont réglé le mode d’utilisateur 'w' pour eux-mêmes (voir au paragraphe 3.1.5 "Modes d’utilisateur").

Après avoir mis en œuvre WALLOPS comme commande d’utilisateur, il a été trouvé qu’il en était souvent fait un usage abusif comme moyen d’envoyer un message à un grand nombre de gens. À cause de cela, il est RECOMMANDÉ que la mise en œuvre de WALLOPS ne permette et reconnaisse que les serveurs comme générateurs de WALLOPS.

Réponse numérique : ERR_NEEDMOREPARAMS

Exemple :
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' de Joshua 	; message WALLOPS de csd.bu.edu annonçant un message CONNECT reçu de Joshua et traité.

4.8	Message Userhost
Commande : USERHOST
Paramètres : <pseudonyme> *( ESPACE <pseudonyme> )

La commande USERHOST prend une liste de jusqu’à cinq pseudonymes, chacun séparé par un caractère espace, et retourne une liste d’informations sur chaque pseudonyme trouvé. La liste retournée a chaque réponse séparée par une espace.

Réponses numériques :
RPL_USERHOST 	ERR_NEEDMOREPARAMS

Exemple :
USERHOST Wiz Michael syrk	; demande USERHOST d’informations sur les pseudonymes "Wiz", "Michael", et "syrk"
:ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net	; Réponse pour l’utilisateur syrk.

4.9	Message Ison
Commande : ISON
Paramètres : <pseudonyme> *( ESPACE <pseudonyme> )

La commande ISON a été mise en œuvre pour fournir un moyen rapide et efficace pour obtenir une réponse à la question de savoir si un certain pseudonyme est actuellement sur IRC. ISON ne prend qu’un (1) type de paramètre : une liste de pseudonymes séparés par une espace. Pour chaque pseudonyme présent dans la liste, le serveur l’ajoute à sa chaîne de réponse. Donc, la chaîne de réponse peut retourner une chaîne vide (aucun des pseudonymes cités n’est présent) une copie exacte de la chaîne de paramètres (tous sont présents) ou tout autre sous-ensemble de l’assortiment de pseudonymes donnés dans le paramètre. La seule limite au nombre de pseudonymes qui peuvent être vérifiés est que la longueur combinée NE DOIT PAS être si grande qu’elle oblige le serveur à la découper afin qu’elle tienne en 512 caractères.

ISON n’est traité que par le serveur local pour le client qui envoie la commande et n’est donc pas passé aux autres serveurs pour d’autres traitements.

Réponses numériques :
RPL_ISON 	ERR_NEEDMOREPARAMS

Exemple :
ISON phone trillMessage ian WiZ jarlek Avalon Angel Monstah syrk 	; Exemple de demande ISON pour 7 pseudonymes.

5.	Réponses

Voici la liste des réponses numériques qui sont générées en réponse aux commandes données précédemment. Chaque réponse numérique est donnée avec son numéro, son nom et sa chaîne de réponse.

5.1	Réponses aux commandes
Les numéros dans la gamme de 001 à 099 sont utilisés seulement pour la connexion client-serveur et ne devraient jamais voyager entre les serveurs. Les réponses générées dans la réponse aux commandes se trouvent dans la gamme de 200 à 399.

001	RPL_WELCOME 	"Bienvenue sur le relais de causette Internet <pseudonyme>!<utilisateur>@<hôte>"
002	RPL_YOURHOST 	"Votre hôte est <nom de serveur>, version en cours <ver>"
003	RPL_CREATED 	"Ce serveur a été créé <date>"
004	RPL_MYINFO 	"<nom de serveur> <version> <mode d’utilisateur disponible> <mode de canal disponible>"
-	Le serveur envoie les réponses 001 à 004 à un utilisateur lors d’un enregistrement réussi.

005	RPL_BOUNCE	"Essayer le serveur <nom de serveur>, accès <numéro d’accès>"
-	Envoyé par le serveur à un utilisateur pour suggérer un serveur de remplacement. C’est souvent utilisé lorsque la connexion est refusée parce que le serveur est déjà plein.

302	RPL_USERHOST	":*1<réponse> *( " " <réponse> )"
-	Format de réponse utilisé par USERHOST pour énumérer les réponses à la liste d’interrogations. La chaîne de réponse est composée comme suit :
réponse = pseudonyme [ "*" ] "=" ( "+" / "-" ) nom d’hôte
Le '*' indique si le client est enregistré comme opérateur. Le caractère '-' ou '+' représente si le client établit un message AWAY ou non.

303	RPL_ISON	":*1<pseudonyme> *( " " <pseudonyme> )"
-	Format de réponse utilisé par ISON pour faire la liste des réponses à la liste d’interrogations.

301	RPL_AWAY	"<pseudonyme> :<message away>"
305	RPL_UNAWAY	":Vous n’êtes plus marqué comme étant parti"
306	RPL_NOWAWAY	":Vous avez été marqué comme étant parti"
-	Ces réponses sont utilisées avec la commande AWAY (si elle est permise). RPL_AWAY est envoyé à tout client qui envoie un PRIVMSG à un client qui est parti. RPL_AWAY n’est envoyé que par le serveur auquel le client est connecté. Les réponses RPL_UNAWAY et RPL_NOWAWAY sont envoyées lorsque le client retire et crée un message AWAY.

311	RPL_WHOISUSER	"<pseudonyme> <utilisateur> <hôte> * :<nom réel>"
312	RPL_WHOISSERVER	"<pseudonyme> <serveur> :<info de serveur>"
313	RPL_WHOISOPERATOR	"<pseudonyme> :est un opérateur  IRC"
317	RPL_WHOISIDLE	"<pseudonyme> <entier> :secondes de repos"
318	RPL_ENDOFWHOIS	"<pseudonyme> :Fin de liste WHOIS"
319	RPL_WHOISCHANNELS	"<pseudonyme> :*( ( "@" / "+" ) <canal> " " )"
-	Les réponses 311 - 313, 317 - 319 sont toutes des réponses générées en réponse à un message WHOIS. Étant donné qu’il y a assez de paramètres présents, le serveur qui répond DOIT soit formuler une réponse parmi les numéros ci-dessus (si le pseudonyme objet de l’interrogation est trouvé) soit retourner une réponse d’erreur. Le '*' dans RPL_WHOISUSER est là comme caractère littéral et non comme caractère générique. Pour chaque réponse donnée, seul RPL_WHOISCHANNELS peut apparaître plus d’une fois (pour de longues listes de noms de canal). Les caractères '@' et '+' après le nom de canal indiquent si un client est un opérateur de canal ou si il a reçu la permission de parler sur un canal à modérateur. La réponse RPL_ENDOFWHOIS est utilisée pour marquer la fin du traitement d’un message WHOIS.

314	RPL_WHOWASUSER	"<pseudonyme> <utilisateur> <hôte> * :<nom réel>"
369	RPL_ENDOFWHOWAS	"<pseudonyme> :Fin de WHOWAS"
-	Quand il répond à un message WHOWAS, un serveur DOIT utiliser les réponses RPL_WHOWASUSER, RPL_WHOISSERVER ou ERR_WASNOSUCHNICK pour chaque pseudonyme de la liste présentée. À la fin de tous les lots de réponses, il doit y avoir RPL_ENDOFWHOWAS (même si il n’y a qu’une seule réponse et qu’elle est erronée).

321	RPL_LISTSTART	Obsolète. Non utilisé.
322	RPL_LIST	"<canal> <# visible> :<sujet>"
323	RPL_LISTEND	":Fin de LIST"
-	Les réponses RPL_LIST, RPL_LISTEND marquent les réponses réelles avec des données et terminent la réponse du serveur à une commande LIST. Si il n’y a pas de canal disponible pour le retour, seule la fin de la réponse DOIT être envoyée.

325	RPL_UNIQOPIS	"<canal> <pseudonyme>"
324	RPL_CHANNELMODEIS	"<canal> <mode> <mode params>"
331	RPL_NOTOPIC	"<canal> :Aucun sujet n’est établi"
332	RPL_TOPIC	"<canal> :<sujet>"
-	Lors de l’envoi d’un message TOPIC pour déterminer le sujet d’un canal, une des deux réponses est envoyée. Si le sujet est établi, RPL_TOPIC est renvoyé, autrement, c’est RPL_NOTOPIC.

341	RPL_INVITING	"<pseudonyme> <canal>"
-	Retourné par le serveur pour indiquer que le message INVITE tenté a réussi et est passé vers le client final.

342	RPL_SUMMONING	"<utilisateur> :Convoque l’utilisateur sur IRC"
-	Retourné par un serveur qui répond à un message SUMMON pour indiquer qu’il convoque cet utilisateur.

346	RPL_INVITELIST	"<canal> <gabarit d’invite>"
347	RPL_ENDOFINVITELIST	"<canal> :Fin de liste d’invite de canal"
-	Lorsque il fait la liste des 'gabarits d’invitation' pour un certain canal, un serveur est obligé de renvoyer la liste en utilisant les messages RPL_INVITELIST et RPL_ENDOFINVITELIST. Un RPL_INVITELIST distinct est envoyé pour chaque gabarit actif. Après que la liste des gabarits a été faite (ou si il n’en est aucun de présent) un  RPL_ENDOFINVITELIST DOIT être envoyé.

348	RPL_EXCEPTLIST	"<canal> <gabarit d’exception>"
349	RPL_ENDOFEXCEPTLIST	"<canal> :Fin de liste d’exception de canal"
-	Lorsque il fait la liste des 'gabarits d’exception' pour un certain canal, un serveur est obligé de renvoyer la liste en utilisant les messages RPL_EXCEPTLIST et RPL_ENDOFEXCEPTLIST. Un RPL_EXCEPTLIST distinct est envoyé pour chaque gabarit actif. Après que la liste des gabarits a été établie (ou si il n’en est aucun de présent) un message RPL_ENDOFEXCEPTLIST DOIT être envoyé.

351	RPL_VERSION	"<version>.<niveau débogage> <serveur> :<commentaires>"
-	Réponse du serveur montrant les détails de sa version. La <version> est celle du logiciel utilisé (y compris toute révision de niveau de débogage) et le <niveau débogage> est utilisé pour indiquer si le serveur fonctionne en "mode débogage".
Le champ "commentaires" peut contenir des commentaires sur la version ou des précisions sur la version.

352	RPL_WHOREPLY 	"<canal> <utilisateur> <hôte> <serveur> <pseudonyme> ( "H" / "G" > ["*"] [ ( "@" / "+" ) ] :<compte de bonds> <nom réel>"
315	RPL_ENDOFWHO	"<nom> :Fin de liste WHO"
-	La paire RPL_WHOREPLY et RPL_ENDOFWHO est utilisée pour répondre à un message WHO. Le message RPL_WHOREPLY n’est envoyé que si il y a une correspondance appropriée à l’interrogation WHO. Si il y a une liste de paramètres fournis avec un message WHO, une RPL_ENDOFWHO DOIT être envoyée après le traitement de chaque élément de la liste avec <nom> comme élément. 

353	RPL_NAMREPLY	"( "=" / "*" / "@" ) <canal> :[ "@" / "+" ] <pseudonyme> *( " " [ "@" / "+" ] <pseudonyme> )"
-	"@" est utilisé pour les canaux secrets, "*" pour les canaux privés, et "=" pour les autres (canaux publics).

366	RPL_ENDOFNAMES	"<canal> :Fin de la liste NAMES"
-	Pour répondre à un message NAMES, une paire de réponses RPL_NAMREPLY et RPL_ENDOFNAMES est renvoyée par le serveur au client. Si il ne se trouve pas de canal comme dans l’interrogation, seul RPL_ENDOFNAMES est alors retourné. La seule exception à cela est lorsque un message NAMES est envoyé sans paramètre et que tous les canaux et contenus visibles sont renvoyés dans une série de messages RPL_NAMEREPLY avec RPL_ENDOFNAMES pour marquer la fin.

364	RPL_LINKS	"<gabarit> <serveur> :<compte de bonds> <informations de serveur>"
365	RPL_ENDOFLINKS	"<gabarit> :Fin de la liste LINKS"
-	En répondant au message LINKS, un serveur DOIT renvoyer les réponses en utilisant le numéro RPL_LINKS et marquer la fin de la liste en utilisant une réponse RPL_ENDOFLINKS.

367	RPL_BANLIST	"<canal> <gabarit d’interdiction>"
368	RPL_ENDOFBANLIST	"<canal> :Fin de liste de gabarit d’interdiction de canal"
-	Lorsque on fait la liste des “interdictions” actives pour un certain canal, un serveur est obligé de renvoyer la liste en utilisant les messages RPL_BANLIST et RPL_ENDOFBANLIST. Un RPL_BANLIST distinct est envoyé pour chaque gabarit d’interdiction actif. Après que la liste des gabarits d’interdiction a été faite (ou si il n’en est aucun de présent) un message RPL_ENDOFBANLIST DOIT être envoyé.

371	RPL_INFO	":<chaîne>"
374	RPL_ENDOFINFO	":Fin de liste INFO"
-	Un serveur qui répond à un message INFO est obligé d’envoyer toutes ses 'info' dans une série de messages RPL_INFO avec une réponse RPL_ENDOFINFO pour indiquer la fin des réponses.

375	RPL_MOTDSTART	":- <serveur> Mot d’ordre du jour - "
372	RPL_MOTD	":- <texte>"
376	RPL_ENDOFMOTD	":Fin de la commande MOTD"
-	Lors de la réponse au message MOTD quand le fichier MOTD est trouvé, le fichier est affiché ligne par ligne, chaque ligne ne dépassant pas 80 caractères, en utilisant le format RPL_MOTD des réponses. Celles-ci DOIVENT être entourées par un RPL_MOTDSTART (avant les RPL_MOTD) et un RPL_ENDOFMOTD (après).

381	RPL_YOUREOPER	":Vous êtes maintenant un opérateur IRC"
-	RPL_YOUREOPER est renvoyé à un client qui vient de réussir à produire avec succès un message OPER et à obtenir le statut d’opérateur.

382	RPL_REHASHING	"<fichier de configuration> :Recompilation"
-	Si l’option REHASH est utilisée et si un opérateur envoie un message REHASH, un RPL_REHASHING est renvoyée à l’opérateur.

383	RPL_YOURESERVICE	"Vous êtes le service <nom du service>"
-	Envoyé par le serveur à un service après réussite de l’enregistrement.

391	RPL_TIME	"<serveur> :<chaîne indiquant l’heure locale du serveur>"
-	En répondant au message TIME, un serveur DOIT envoyer la réponse en utilisant le format RPL_TIME ci-dessus. La chaîne qui donne l’heure doit seulement contenir le jour et l’heure corrects. Il n’y a pas d’autre exigence pour la chaîne d’horodatage.

392	RPL_USERSSTART	":Identifiant d’utilisateur   Terminal  Hôte"
393	RPL_USERS	":<nom d’utilisateur> <ligne tty> <nom d’hôte>"
394	RPL_ENDOFUSERS	":Fin d’utilisateurs"
395	RPL_NOUSERS	":Personne d’enregistré"
-	Si le message USERS est traité par un serveur, les réponses RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS et RPL_NOUSERS sont utilisées. RPL_USERSSTART DOIT être envoyé en premier, suivi par une séquence de RPL_USERS ou d’un seul RPL_NOUSER. À la fin se trouve le RPL_ENDOFUSERS.

200	RPL_TRACELINK	"Liaison <version & niveau débogage> <destination> <prochain serveur> V<version du protocole> <durée d’activité de la liaison en secondes> <sendq aval> <sendq amont>"
201	RPL_TRACECONNECTING	"Essayer. <classe> <serveur>"
202	RPL_TRACEHANDSHAKE	"H.S. <classe> <serveur>"
203	RPL_TRACEUNKNOWN	"???? <classe> [<adresse IP du client en forme séparée par des points>]"
204	RPL_TRACEOPERATOR	"Opérateur <classe> <pseudonyme>"
205	RPL_TRACEUSER	"Utilisateur <classe> <pseudonyme>"
206	RPL_TRACESERVER	"Serveur <classe> <int>S <int>C <serveur> <pseudonyme!utilisateur|*!*>@<hôte|serveur> V<protocole version>"
207	RPL_TRACESERVICE	"Service <classe> <nom> <type> <type actif>"
208	RPL_TRACENEWTYPE	"<nouveau type> 0 <nom du client>"
209	RPL_TRACECLASS	"Classe <classe> <compte>"
210	RPL_TRACERECONNECT	Non utilisé.
261	RPL_TRACELOG	"Fichier <fichier de journalisation> <niveau de débogage>"
262	RPL_TRACEEND	"<nom de serveur> <version & niveau de débogage> :Fin de TRACE"
-	Les RPL_TRACE* sont toutes retournées par le serveur en réponse au message TRACE. Combien sont retournées dépend du message TRACE et de si elles sont envoyées par un opérateur ou non. Il n’y a pas d’ordre prédéfini pour celle qui vient en premier. Les réponses RPL_TRACEUNKNOWN, RPL_TRACECONNECTING et RPL_TRACEHANDSHAKE sont toutes utilisées pour des connexions qui n’ont pas été pleinement établies et sont inconnues, ou toujours en attente de connexion ou en cours d’achèvement de la "prise de contact de serveur". RPL_TRACELINK est renvoyé par tout serveur qui traite un message TRACE et doit le passer à un autre serveur. La liste des RPL_TRACELINK envoyés en réponse à une commande TRACE traversant le réseau IRC devrait refléter la connexité réelle des serveurs eux-mêmes le long de ce chemin.
RPL_TRACENEWTYPE est à utiliser pour toute connexion qui ne rentre pas dans les autres catégories mais est quand même affichée. RPL_TRACEEND est envoyé pour indiquer la fin de la liste.

211	RPL_STATSLINKINFO	"<nom de liaison> <sendq> <messages envoyés> <k octets envoyés> <messages reçus> <k octets reçus> <durée d’ouverture>"
-	Rapporte les statistiques sur une connexion. <nom de liaison> identifie la connexion, <sendq> est la quantité de données en file d’attente pour être envoyées, <messages envoyés> le nombre de messages envoyés, et <k octets envoyés> la quantité de données envoyées, en k octets. <messages reçus> et <k octets reçus> sont l’équivalent de <messages envoyés> et <k octets reçus> pour les données reçues, respectivement, <durée d’ouverture> indique depuis combien de temps la connexion est ouverte, en secondes.

212	RPL_STATSCOMMANDS	"<commande> <compte> <compte d’octets> <compte distant>"
-	Rapporte les statistiques de l’utilisation des commandes.

219	RPL_ENDOFSTATS	"<lettre statistique> :Fin de rapport de STATS"
242	RPL_STATSUPTIME	":Serveur actif %d jours %d:%02d:%02d"
-	Rapports le temps d’activité du serveur.

243	RPL_STATSOLINE	"O <gabarit d’hôte> * <nom>"
-	Rapporte les hôtes admis à partir desquels l’utilisateur peut devenir opérateur IRC.

221	RPL_UMODEIS	"<chaîne de mode d’utilisateur>"
-	Pour répondre à une interrogation sur le mode du client, RPL_UMODEIS est renvoyé.

234	RPL_SERVLIST	"<nom> <serveur> <gabarit> <type> <compte de bonds> <info>"
235	RPL_SERVLISTEND	"<gabarit> <type> :Fin de liste de services"
-	Lorsque il fait la liste des services en réponse à un message SERVLIST, un serveur est obligé de renvoyer la liste en utilisant les messages RPL_SERVLIST et RPL_SERVLISTEND. Un RPL_SERVLIST distinct est envoyé pour chaque service. Après que la liste des services a été faite (ou si aucun n’est présent) un RPL_SERVLISTEND DOIT être envoyé.

251	RPL_LUSERCLIENT	":Il y a <entier> utilisateurs et <entier> services sur <entier> serveurs"
252	RPL_LUSEROP	"<entier> :opérateur(s) en ligne"
253	RPL_LUSERUNKNOWN	"<entier> :connexion(s) inconnues"
254	RPL_LUSERCHANNELS	"<entier> :canaux formés"
255	RPL_LUSERME	":J’ai <entier> clients et <entier> serveurs"
-	En traitant un message LUSERS, le serveur envoie un ensemble de réponses à partir de RPL_LUSERCLIENT, RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS et RPL_LUSERME. Lorsque il répond, un serveur DOIT renvoyer RPL_LUSERCLIENT et RPL_LUSERME. Les autres réponses ne sont renvoyées que si un compte différent de zéro est trouvé pour elles.

256	RPL_ADMINME	"<serveur> :Informations administratives"
257	RPL_ADMINLOC1	":<Informations administratives>"
258	RPL_ADMINLOC2	":<Informations administratives>"
259	RPL_ADMINEMAIL	":<Informations administratives>"
-	Lorsque il répond à un message ADMIN, un serveur est supposé utiliser les réponses RPL_ADMINME à RPL_ADMINEMAIL et fournir un message textuel avec chacune d’elles. Pour RPL_ADMINLOC1 une description de la ville province et pays dans lequel se trouve le serveur est attendue, suivie par les détails de l’institution (RPL_ADMINLOC2) et finalement le contact administratif pour le serveur (une adresse de messagerie électronique est EXIGÉE ici) dans RPL_ADMINEMAIL.

263	RPL_TRYAGAIN	"<commande> :Prière d’attendre un peu avant de recommencer."
-	Lorsque un serveur abandonne une commande sans la traiter, il DOIT utiliser la réponse RPL_TRYAGAIN pour informer le client qui l’a générée.

5.2	Réponses d’erreur
Les réponses d’erreur se trouvent dans la gamme de 400 à 599.

401	ERR_NOSUCHNICK	"<pseudonyme> :Pas de tel pseudonyme/canal"
-	Utilisé pour indiquer que le paramètre de pseudonyme fourni pour une commande est actuellement non utilisé.

402	ERR_NOSUCHSERVER	"<nom de serveur> :Pas de tel serveur"
-	Utilisé pour indiquer que le nom de serveur donné n’existe pas actuellement.

403	ERR_NOSUCHCHANNEL	²"<nom de canal> :Pas de tel canal"
-	Utilisé pour indiquer que le nom de canal donné est invalide.

404	ERR_CANNOTSENDTOCHAN	"<nom de canal> :Pas possible d’envoyer au canal"
-	Envoyé à un utilisateur qui n’est (a) pas sur un canal qui est en mode +n ou (b) pas un chanop (ou mode +v) sur un canal qui a le mode +m établi ou dont l’utilisateur est interdit et qui essaye d’envoyer un message PRIVMSG à ce canal.

405	ERR_TOOMANYCHANNELS	"<nom de canal> :Vous vous êtes joint à trop de canaux"
-	Envoyé à un utilisateur lorsque il s’est joint au nombre maximum admis de canaux et qu’il essaye de se joindre à un autre canal.

406	ERR_WASNOSUCHNICK	"<pseudonyme> :Il n’y a pas ce pseudonyme"
-	Retourné par WHOWAS pour indiquer qu’il n’y a pas d’informations d’historique pour ce pseudonyme.

407	ERR_TOOMANYTARGETS	"<cible> :<code d’erreur> receveurs. <message d’interruption>"
-	Retourné à un client qui tente d’envoyer un PRIVMSG/NOTICE en utilisant le format de destination utilisateur@hôte et pour un utilisateur@hôte qui a plusieurs occurrences.
-	Retourné à un client qui essaye d’envoyer un PRIVMSG/NOTICE à un trop grand nombre de receveurs.
-	Retourné à un client qui tente de se JOINDRE à un canal sûr en utilisant le petit nom alors qu’il y a plus d’un de ces canaux.

408	ERR_NOSUCHSERVICE	"<nom de service> :Un tel service n’existe pas"
-	Retournée à un client qui tente d’envoyer un SQUERY à un service qui n’existe pas.

409	ERR_NOORIGIN	":Pas d’origine spécifiée"
-	Message PING or PONG auquel manque le paramètre d’origine.

411	ERR_NORECIPIENT	":Pas de receveur donné (<commande>)"
412	ERR_NOTEXTTOSEND	":Pas de texte à envoyer"
413	ERR_NOTOPLEVEL	"<gabarit> :Pas de domaine de niveau supérieur spécifié"
414	ERR_WILDTOPLEVEL	"<gabarit> :Caractère générique dans le domaine de niveau supérieur"
415	ERR_BADMASK	"<gabarit> :Mauvais gabarit de serveur/hôte"
-	Les erreurs 412 - 415 sont retournées par PRIVMSG pour indiquer que le message n’a pas été livré pour une certaine raison. ERR_NOTOPLEVEL et ERR_WILDTOPLEVEL sont des erreurs qui sont retournées lorsque est tenté un usage invalide de "PRIVMSG $<serveur>" ou "PRIVMSG #<hôte>".

416	ERR_TOOMANYMATCHES	"<canal> :Résultat trop long (essayer en local)"
-	Retourné par un serveur en réponse à un message LIST ou NAMES pour indiquer que le résultat contient trop d’éléments pour être retourné au client.

421	ERR_UNKNOWNCOMMAND	"<commande> :Commande inconnue"
-	Retourné à un client enregistré pour indiquer que la commande envoyée est inconnue du serveur.

422	ERR_NOMOTD	":Il manque le fichier MOTD"
-	Le fichier MOTD du serveur n’a pas pu être ouvert par le serveur.

423	ERR_NOADMININFO	"<serveur> :Pas d’informations administratives disponibles"
-	Retourné par un serveur en réponse à un message ADMIN lorsque il ne réussit pas à trouver les informations appropriées.

424	ERR_FILEERROR	":Erreur de fichier en faisant <file op> sur <file>"
-	Message d’erreur générique utilisé pour rapporter l’échec d’une opération de fichier durant le traitement d’un message.

431	ERR_NONICKNAMEGIVEN	":Aucun pseudonyme n’est donné"
-	Retourné quand un paramètre pseudonyme attendu pour une commande n’est pas trouvé.

432	ERR_ERRONEUSNICKNAME	"<pseudonyme> :Pseudonyme erroné"
-	Retourné à la réception d’un message NICK qui contient des caractères qui ne rentrent pas dans le jeu défini. Voir au paragraphe 2.3.1 les détails sur les pseudonymes valides.

433	ERR_NICKNAMEINUSE	"<pseudonyme> :Pseudonyme déjà utilisé"
-	Retourné lorsque le traitement d’un message NICK résulte en une tentative de changer le pseudonyme en un pseudonyme existant actuellement.

436	ERR_NICKCOLLISION	"<pseudonyme> :Collision de pseudonymes KILL de <utilisateur>@<hôte>"
-	Retourné par un serveur à un client quand il détecte une collision de pseudonymes (enregistrement d’un NICK qui existe déjà par un autre serveur).

437	ERR_UNAVAILRESOURCE	"<pseudonyme/canal> :Le pseudonyme/canal est temporairement indisponible"
-	Retourné par un serveur à un utilisateur qui essaye de se joindre à un canal actuellement bloqué par le mécanisme de délai de canal.
-	Retourné par un serveur à un utilisateur qui essaye de changer de pseudonyme lorsque le pseudonyme désiré est bloqué par le mécanisme de délai de pseudonyme.

441	ERR_USERNOTINCHANNEL	"<pseudonyme> <canal> :Ils ne sont pas sur ce canal"
-	Retourné par le serveur pour indiquer que l’utilisateur cible de la commande n’est pas sur le canal désigné.

442	ERR_NOTONCHANNEL	"<canal> :Vous n’êtes pas sur ce canal"
-	Retourné par le serveur chaque fois qu’un client essaye d’effectuer une commande affectant un canal dont il n’est pas membre.

443	ERR_USERONCHANNEL	"<utilisateur> <canal> :est déjà sur le canal"
-	Retourné quand un client essaye d’inviter un utilisateur sur un canal sur lequel il est déjà.

444	ERR_NOLOGIN	"<utilisateur> :Utilisateur non enregistré"
-	Retourné par le convoquant après une commande SUMMON pour laquelle un utilisateur a été incapable de se conformer car ils ne sont pas enregistrés.

445	ERR_SUMMONDISABLED	":SUMMON a été désactivé"
-	Retourné en réponse à la commande SUMMON. DOIT être retournée par tout serveur qui ne la met pas en œuvre.

446	ERR_USERSDISABLED	":USERS a été désactivé"
-	Retourné en réponse à la commande USERS. DOIT être retournée par tout serveur qui ne la met pas en œuvre.

451	ERR_NOTREGISTERED	":Vous n’avez pas été enregistré"
-	Retourné par le serveur pour indiquer que le client DOIT être enregistré avant que le serveur lui permette d’être analysé en détail.

461	ERR_NEEDMOREPARAMS	"<commande> :Pas assez de paramètres"
-	Retourné par le serveur sur de nombreuses commandes pour indiquer au client qu’il n’a pas fourni assez de paramètres.

462	ERR_ALREADYREGISTRED	":Commande non autorisée (déjà enregistrée)"
-	Retourné par le serveur à toute liaison qui essaye de changer une partie des détails enregistrés (comme un mot de passe ou des détails d’utilisateur à partir du second message USER).

463	ERR_NOPERMFORHOST	":Votre hôte n'est pas parmi les privilégiés"
-	Retourné à un client qui tente de s’enregistrer auprès d’un serveur qui n’a pas été réglé pour permettre des connexions à partir de l’hôte duquel la connexion est tentée.

464	ERR_PASSWDMISMATCH	":Mot de passe incorrect"
-	Retourné pour indiquer l’échec d’une tentative d’enregistrement d’une connexion pour laquelle un mot de passe est exigé et qui n’a pas été donné ou est incorrect.

465	ERR_YOUREBANNEDCREEP	":Vous êtes interdit sur ce serveur"
-	Retourné après une tentative de connexion et d’enregistrement auprès d’un serveur qui a été réglé pour refuser explicitement les connexions avec le demandeur.

466	ERR_YOUWILLBEBANNED
-	Envoyé par un serveur à un utilisateur pour l’informer que l’accès au serveur va bientôt lui être refusé.

467	ERR_KEYSET	"<canal> :Clé de canal déjà établie"
471	ERR_CHANNELISFULL	"<canal> :Le canal ne peut être joint (+l)"
472	ERR_UNKNOWNMODE	"<char> :est un caractère de mode inconnu pour <canal>"
473	ERR_INVITEONLYCHAN	"<canal> :Le canal ne peut être joint (+i)"
474	ERR_BANNEDFROMCHAN	"<canal> :Le canal ne peut être joint (+b)"
475	ERR_BADCHANNELKEY	"<canal> :Le canal ne peut être joint (+k)"
476	ERR_BADCHANMASK	"<canal> :Mauvais gabarit de canal"
477	ERR_NOCHANMODES	"<canal> :Le canal n’accepte pas ces modes"
478	ERR_BANLISTFULL	"<canal> <char> :La liste de canaux est pleine"
481	ERR_NOPRIVILEGES	":Permission refusée – Vous n’êtes pas un opérateur IRC"
-	Toute commande exigeant les privilèges d’opérateur pour fonctionner DOIT retourner ces erreurs pour indiquer l’échec de la tentative.

482	ERR_CHANOPRIVSNEEDED	"<canal> :Vous n’êtes pas un opérateur du canal"
-	Toute commande qui exige les privilèges 'chanop' (comme les messages MODE) DOIT retourner cette erreur si le client qui fait cette tentative n’est pas opérateur de canal sur le canal spécifié.

483	ERR_CANTKILLSERVER	":Vous ne pouvez pas tuer un serveur!"
-	Toute tentative d’utiliser la commande KILL sur un serveur doit être refusée et cette erreur retournée directement au client.

484	ERR_RESTRICTED	":Votre connexion est soumise à des restrictions !"
-	Envoyé par le serveur à un utilisateur au moment de la connexion pour indiquer la nature restreinte de la connexion (mode d’utilisateur "+r").

485	ERR_UNIQOPPRIVSNEEDED	":Vous n’êtes pas l’opérateur de canal d’origine"
-	Tout MODE exigeant les privilèges de "créateur de canal" DOIT retourner cette erreur si le client qui fait la tentative n’est pas opérateur de canal sur le canal spécifié.

491	ERR_NOOPERHOST	":Pas de O-lignes pour votre hôte"
-	Si un client envoie un message OPER et si le serveur n’a pas été configuré pour permettre les connexions à partir de l’hôte du client comme un opérateur, cette erreur DOIT être retournée.

501	ERR_UMODEUNKNOWNFLAG	":Fanion MODE inconnu"
-	Retourné par le serveur pour indiquer qu’un message MODE a été envoyé avec un paramètre pseudonyme et que le fanion mode envoyé n’a pas été reconnu.

502	ERR_USERSDONTMATCH	":On ne peut pas changer le mode pour d’autres utilisateurs"
-	Erreur envoyée à tout utilisateur qui essaye de voir ou changer le mode d’utilisateur pour un utilisateur autre que lui-même.

5.3	Numéros réservés
Ces numéros ne sont pas décrits plus haut car ils ne rentrent dans aucune des catégories suivantes :
1.	plus utilisé ;
2.	réservé pour une utilisation future prévue ;
3.	actuellement utilisé mais faisant partie d’une "caractéristique" générique du serveur IRC actuel.

231	RPL_SERVICEINFO	232	RPL_ENDOFSERVICES	233	RPL_SERVICE

300	RPL_NONE	316	RPL_WHOISCHANOP
361	RPL_KILLDONE	362	RPL_CLOSING	363	RPL_CLOSEEND
373	RPL_INFOSTART	384	RPL_MYPORTIS

213	RPL_STATSCLINE	214	RPL_STATSNLINE	215	RPL_STATSILINE
216	RPL_STATSKLINE	217	RPL_STATSQLINE	218	RPL_STATSYLINE
240	RPL_STATSVLINE	241	RPL_STATSLLINE	244	RPL_STATSHLINE
245	RPL_STATSSLINE	246	RPL_STATSPING	247	RPL_STATSBLINE	
250	RPL_STATSDLINE

492	ERR_NOSERVICEHOST

6.	Mises en œuvre actuelles

Le logiciel IRC, version 2.10 est la seule mise en œuvre complète du protocole IRC (client et serveur). À cause de la faible quantité de changements au protocole client depuis la publication de la [RFC1459], les mises en œuvre qui la suivent seront vraisemblablement conformes au présent protocole ou n’auront besoin que de peu de changements pour atteindre la conformité.

7.	Problèmes rencontrés

Un certain nombre de problèmes du protocole de client IRC ont été reconnus, et plus généralement avec le protocole de serveur IRC. Afin de préserver la rétro compatibilité avec les anciens clients, le présent protocole n’a presque pas évolué depuis la publication de la [RFC1459].

7.1	Pseudonymes
L’idée du pseudonyme sur IRC est très pratique pour les utilisateurs lorsque ils parlent ensemble en-dehors d’un canal, mais il n’y a qu’un espace fini de pseudonymes et étant donné ce qu’ils sont, il n’est pas rare que plusieurs personnes veuillent utiliser le même pseudonyme. Si un pseudonyme est choisi par deux personnes qui utilisent le présent protocole, l’une d’elles va échouer, ou toutes deux seront retirées par l’utilisation d’une commande KILL par le serveur (voir au paragraphe 3.7.1).

7.2	Limitation des caractères génériques
Il n’y a aucun moyen d’esquiver le caractère "\" (%x5C). Bien que ce ne soit généralement pas un problème, cela rend impossible de former un gabarit avec un caractère barre oblique inverse ("\") précédant un caractère générique.

7.3	Considérations pour la sécurité
Les questions de sécurité qui se rapportent au présent protocole sont exposées dans la [RFC2813] "Protocole de serveur IRC" car elles ne sont un problème que pour le côté serveur de la connexion.

8.	Prise en charge et disponibilité actuelle

Listes de diffusion de discussion en rapport avec IRC :
Discussion générale : ircd-utilisateurs@irc.org 
Développement de protocole : ircd-dev@irc.org 

Mises en œuvre de logiciels :
ftp://ftp.irc.org/irc/server  
ftp://ftp.funet.fi/pub/unix/irc  
ftp://coombs.anu.edu.au/pub/irc  

Groupe de nouvelles : alt.irc 

9.	Remerciements

Certaines parties du présent document ont été copiées de la [RFC1459] qui a été la première à documenter formellement le protocole IRC. Il a aussi bénéficié de nombreuses séances de révision et de commentaires. En particulier, les personnes suivantes ont fourni des contributions significatives à ce document : Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10.	Références

[RFC1123]	R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.

[RFC1459]	J. Oikarinen et D. Reed, "Protocole Internet de relais de débats", mai 1993. (Exp., MàJ par 2810-13)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2810]	C. Kalt, "Relais pour la causette Internet : architecture", avril 2000. (Information)

[RFC2811]	C. Kalt, "Relais pour la causette Internet : gestion de canal", avril 2000. (Information)

[RFC2813]	C. Kalt, "Relais pour la causette Internet : protocole serveur", avril 2000. (Information)

11.	Adresse de l’auteur

Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USAmél : kalt@stealth.net

12.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant la notice de droits d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement
Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.