| Groupe de Travail Réseau | J. Oikarinen |
| Requête pour commentaires: 1459 | D. Reed |
| Mai 1993 |
Le protocole IRC et un protocole en mode texte, dont le client le plus simple est n'importe quel programme de TCP capable de se connecter à un serveur.
1. Introduction
1.1 Serveurs
1.2 Clients
1.2.1 Opérateurs
1.3 Canaux
1.3.1 Opérateurs de canaux
2. Spécification IRC
2.1 Aperçu
2.2 Les jeux de caractères
2.3 Messages
2.3.1 Le format de message en 'pseudo' BNF
2.4 Réponses numériques
3. Concepts IRC
3.1 Communication un à un
3.2 Un à plusieurs
3.2.1 A une liste
3.2.2 A un groupe (canal)
3.2.3 A un masque d'hôte/de serveur
3.3 Un à tous
3.3.1 Client à client
3.3.2 Client à serveur
3.3.3 Serveur à serveur
4. Détails des messages
4.1 Etablissement de connection
4.1.1 Message PASSWORD
4.1.2 Message NICK
4.1.3 Message USER
4.1.4 Message SERVER
4.1.5 Message OPER
4.1.6 Message QUIT
4.1.7 Message SQUIT
4.2 Opérations sur les canaux
4.2.1 Message JOIN
4.2.2 Message PART
4.2.3 Message MODE
4.2.3.1 Les modes des canaux
4.2.3.2 Les modes des utilisateurs
4.2.4 Message TOPIC
4.2.5 Message NAMES
4.2.6 Message LIST
4.2.7 Message INVITE
4.2.8 Message KICK
4.3 Requêtes et commandes des serveurs
4.3.1 Message VERSION
4.3.2 Message STATS
4.3.3 Message LINKS
4.3.4 Message TIME
4.3.5 Message CONNECT
4.3.6 Message TRACE
4.3.7 Message ADMIN
4.3.8 Message INFO
4.4 Envoi de messages
4.4.1 Messages privés
4.4.2 NOTICE
4.5 Requêtes basées sur les utilisateurs
4.5.1 Message WHO
4.5.2 Message WHOIS
4.5.3 Message WHOWAS
4.6 Messages divers
4.6.1 Message KILL
4.6.2 Message PING
4.6.3 Message PONG
4.6.4 Message ERROR
5. Messages optionnels
5.1 Message AWAY
5.2 Commande REHASH
5.3 Commande RESTART
5.4 Message SUMMON
5.5 Message USER
5.6 Commande OPERWALL
5.7 Message USERHOST
5.8 Message ISON
6. Réponses
6.1 Réponses d'erreur
6.2 Réponses aux commandes
6.3 Nombres réservés
7. Authentification des clients et serveurs
8. Implémentations actuelles
8.1 Protocole Réseau: TCP
8.1.1 Support des sockets Unix
8.2 Traitement des commandes
8.3 Distribution de messages
8.4 La vie d'une connection
8.5 Etablissement d'une connection serveur à client
8.6 Etablissement d'une connection serveur/serveur
8.6.1 Echange des informations d'état des serveurs à la connection
8.7 Terminaison des connections serveur/client
8.8 Terminaison des connections serveur/serveur
8.9 Suivi des changements de pseudonymes
8.10 Contrôle d'inondation des clients
8.11 Recherches non bloquantes
8.11.1 Recherche du nom d'hôte (DNS)
8.11.2 Recherche du nom d'utilisateur (IDENT)
8.12 Fichier de configuration
8.12.1 Autorisation des connections de clients
8.12.2 Opérateurs
8.12.3 Autorisation des connections de serveurs
8.12.4 Admin
8.13 Appartenance à un canal.
9. Problèmes actuels
9.1 Localisation
9.2 Identifiants
9.2.1 Pseudonymes
9.2.2 Canaux
9.2.3 Serveurs
9.3 Algorithmes
10. Support actuel et disponibilité
11. Considérations de sécurité
12. Adresses des auteurs
Le protocole IRC a été développé sur des systèmes utilisant le protocole réseau TCP/IP, bien qu'il n'y ait pas de raison que cela reste la seule sphère dans laquelle il opère.
L'IRC, en lui-même, est un système de téléconférence qui (grâce à l'utilisation d'un modèle client/serveur) et se prête à une exécution sur de nombreuses machines, de façon distribuée. Une configuration type comprend un processus unique (le serveur) qui fourni un point d'accès pour les clients (ou d'autres serveurs), et qui traite l'acheminement / le multiplexage requis de messages, ainsi que d'autres fonctions.
[ Serveur 15 ] [ Serveur 13 ] [ Serveur 14]
/ \ /
/ \ /
[ Serveur 11 ] ------ [ Serveur 1 ] [ Serveur 12]
/ \ /
/ \ /
[ Serveur 2 ] [ Serveur 3 ]
/ \ \
/ \ \
[ Serveur 4 ] [ Serveur 5 ] [ Serveur 6 ]
/ | \ /
/ | \ /
/ | \____ /
/ | \ /
[ Serveur 7 ] [ Serveur 8 ] [ Serveur 9 ] [ Serveur 10 ]
:
[ etc. ]
:
[ Fig. 1. Format d'un réseau de serveur IRC ]
Un pouvoir plus controversé des opérateurs est la possibilité de retirer par la force un utilisateur connecté au réseau, c'est à dire que les opérateurs peuvent clore une connection entre un client et un serveur. La justification à cela est délicate puisque son abus est à la fois destructif et ennuyant. Pour plus de détails concernant ce type d'actions, voir la section 4.6.1 (KILL).
Les noms de canaux sont des chaînes de caractères (commençant par un caractère '&' ou '#') d'une longueur maximale de 200 caractères. En dehors du fait que le premier caractère doive être un '&' ou un '#', la seule restriction sur le nom d'un canal est qu'il ne peut pas contenir d'espace (' '), de contrôle G (^G ou ASCII 7), ou de virgule (',' qui est utilisée comme séparateur de liste dans le protocole).
Il y a deux types de canaux autorisés par ce protocole. L'un est un canal distribué, qui est connu de tous les serveurs connectés au réseau. Ces canaux commencent par un '#'. L'autre type de canal, reconnaissable à leur nom qui commence par un '&', est marqué comme n'étant accessible qu'aux clients du serveur où le canal existe. En plus de ces deux types, il existe différents modes de canaux, permettant de modifier leur comportement individuel. Voir la section 4.2.3 (commande MODE) pour avoir plus de détails à ce sujet.
Pour créer un nouveau canal, ou pour faire partie d'un canal existant, un utilisateur doit accéder au canal. Si le canal n'existe pas avant l'accès, le canal est créé et l'utilisateur créateur devient opérateur de canal. Si le canal existait déjà au moment de l'accès, l'autorisation ou non d'accès dépend du mode du canal. Par exemple, si le canal est en "invités uniquement" (+i), vous ne pourrez joindre le canal que si vous êtes invités. Le protocole spécifie qu'un utilisateur peux être membre de plusieurs canaux à la fois, mais une limite de dix (10) canaux est recommandée comme étant amplement suffisante aussi bien pour les utilisateurs novices que pour les experts. Voir la section 8.13 pour plus d'informations à ce sujet.
Si le réseau IRC devient disjoint en raison d'une division entre deux serveurs, le canal, de chaque côté, est composé de ceux des clients qui sont connectés aux serveurs du côté respectif de la division, et disparaissent d'un des côtés de la division. Lorsque la division est soignée, les serveurs se reconnectant se communiquent entre eux qui, d'après eux, est dans chaque canal, et le mode de ce canal. Si le canal existe des deux cotés, les accès et les modes sont interprétés de façon inclusive pour que les deux côtés de la nouvelle connection soient d'accord sur quels clients sont dans quels canaux et quels modes ont les canaux.
Les commandes réservées aux opérateurs de canaux sont
:
KICK - Ejecte un client d'un canal
MODE - Change le mode d'un
canal
INVITE - Invite un client dans un canal à accès sur
invitation (mode +i)
TOPIC - Change le titre du canal, dans un canal en mode
+t
Un opérateur de canal est identifié par un symbole '@' devant son pseudonyme à chaque fois qu'il est utilisé en association avec le canal (c'est à dire lors des réponses aux commandes NAMES, WHO et WHOIS)
Indépendamment du fait qu'il s'agisse d'un protocole 8 bits, les délimiteurs et les mots-clés sont tels que le protocole est utilisable d'un terminal USASCII et d'une connection telnet.
Etant donnée l'origine scandinave de l'IRC, les caractères {}| sont considérés comme étant respectivement les équivalent en minuscules des caractères []\. Ceci est particulièrement important pour déterminer l'équivalence de deux pseudonymes.
Chaque message IRC peut contenir jusqu'à trois parties : le préfixe (optionnel), la commande, et les paramètre de la commande (il peut y en avoir jusqu'à 15). Le préfixe, la commande, et tous les paramètres sont séparés par un (ou plusieurs) caractère(s) ASCII espace (0x20).
La présence d'un préfixe est indiquée par un simple caractère ASCII deux-points (':', 0x3b), qui doit être le premier caractère du message. Il ne doit pas y avoir de trou (d'espace blanc) entre les deux-points et le préfixe. Le préfixe est utilisé pour indiquer la véritable origine du message. S'il n'y a pas de préfixe, le message est considéré comme ayant pour origine la connection de laquelle il est issu. Les clients ne doivent pas utiliser de préfixe lorsqu'ils envoient un message d'eux-mêmes. S'il utilise un préfixe, le seul valable est le pseudonyme associé au client. Si la source identifiée par le préfixe n'est pas trouvée dans la base de donnée interne du serveur, ou si la source est enregistrée avec une liaison différente de celle avec laquelle le message est arrivé, le serveur doit ignorer le message en silence.
La commande doit soit être soit une commande IRC valide, soit un nombre de trois (3) chiffres représentés en texte ASCII.
Les messages IRC sont toujours des lignes de caractères terminés par une paire CR-LF (retour chariot - saut de ligne), et ces messages ne doivent pas dépasser 512 caractères de long, en comptant tous les caractères y compris le CR-LF final. C'est-à-dire, qu'il y a un maximum de 510 caractères pour la commande et ses paramètres. Il n'y a pas de système permettant une ligne de continuation de message. Voir la section 7 pour les implémentations actuelles.
Le message extrait est décomposé en un <préfixe>, <commande> et liste de paramètres correspondant soit au composant <milieu> ou <fin>.
La représentation BNF de ceci est :
<message> ::= [':'
<préfixe> <espace> ] <command> <params>
<crlf>
<préfixe> ::= <nom de serveur> |
<pseudo> [ '!' <utilisateur> ] [ '@' <hôte> ]
<command> ::= <lettre> { <lettre> } | <nombre>
<nombre> <nombre>
<espace> ::= ' ' { ' ' }
<params> ::= <espace> [ ':' <fin> | <milieu>
<params> ]
<milieu> ::= <Toute séquence non
vide d'octets à l'exclusion de ESPACE, NUL, CR, LF, le premier
d'entre eux étant différent de ':'>
<fin> ::=
<Toute suite, éventuellement vide, d'octets, à l'exception de
NUL, CR et LF >
<crlf> ::= CR LF
NOTES:
1) <espace> est constitué uniquement de
caractère(s) ESPACE (0x20). Notez particulièrement que la
TABULATION et tout autre caractère de contrôle sont
considérés comme ESPACE-NON-BLANC.
2) Après avoir extrait la liste de paramètre, tous les paramètres sont égaux, et correspondent soit à <milieu> soit à <fin>. <Fin> est une simple astuce syntaxique pour autoriser ESPACE dans le paramètre.
3) Le fait que CR et LF ne puissant pas apparaître dans la chaîne paramètre est une simple assertion. Cela pourrait changer dans le futur.
4) Le caractère NUL n'est pas spécial dans la construction du message, et pourrait a priori être à l'intérieur d'un message, mais cela complexifierait la gestion ordinaire des chaînes en C. C'est pourquoi NUL n'est pas autorisé dans les messages.
5) Le dernier paramètre peut être une chaîne vide.
6) L'utilisation d'un préfixe étendu ([ '!' <utilisateur> ] [ '@' <hôte> ]) ne doit pas être utilisé dans la communication entre serveurs, et est destiné uniquement à la communication serveur vers client, dans le but de fournir au client des informations utiles à propos de l'origine du message sans nécessiter de requêtes supplémentaires.
La plupart des messages du protocole spécifient une sémantique
additionnelle, et la syntaxe pour les chaînes de paramètres
extraites est dictée par leur position dans la liste. Par exemple, de
nombreuses commandes de serveurs vont considérer que le premier
paramètre après la commande est la liste de destinataires, ce qui
peut être décrit avec :
<destinataire> ::=
<à> [ "," < destinataire > ]
<à>
::= <canal> | < utilisateur > '@' <nom de serveur> |
<pseudo> | <masque>
<canal> ::= ('#' | '&')
<chaîne canal>
<nom de serveur> ::= <hôte>
<hôte> ::= voir RFC 952 [DNS:4] pour les détails sur les
noms d'hôte autorisés
<pseudo> ::= <lettre> {
<lettre> | <nombre> | <spécial> }
<masque>
::= ('#' | '$') <chaîne canal>
<chaîne canal> ::=
<n'importe quel code 8bits excepté ESPACE, BELL, NUL, CR, LF et
virgule (,)>
Les autres paramètres sont :
<utilisateur> ::= <non
blanc> { < non blanc > }
<lettre> ::= 'a' ... 'z' | 'A' ...
'Z'
<nombre> ::= '0' ... '9'
<spécial> ::= '-' | '['
| ']' | '\' | '`' | '^' | '{' | '}'
< non blanc > ::= < n'importe quel code 8bits excepté ESPACE
(0x20), NUL(0x0), CR(0xd), et LF(0xa) >
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Serveurs: A, B, C, D, E Clients: 1, 2,3, 4
[ Fig. 2. Exemple d'un petit réseau IRC ]
Les exemples suivants se réfèrent tous à la figure 2 ci-dessus.
Les exemples suivants se réfèrent tous à la figure 2.
Pour certains messages, il est nécessaire de les diffuser à tous les serveurs, de façon à ce que les informations de statut de chaque serveur soient raisonnablement identiques entre tous les serveurs.
Si la réponse est ERR_NOSUCHSERVER est reçue, cela signifie que le paramètre <serveur> n'a pas été trouvé. Le serveur ne doit alors plus envoyer d'autres réponses pour cette commande.
Le serveur auquel un client est connecté doit traiter le message complet, et retourner les messages d'erreur appropriés. Si le serveur rencontre une erreur fatale en décomposant un message, une erreur doit être envoyé au client et la décomposition interrompue. Peut être considéré comme une erreur fatale une commande incorrecte, une destination inconnue du serveur (noms de serveur, pseudo, et noms de canaux entrent dans cette catégorie), un nombre de paramètres insuffisant, ou un niveau de privilège insuffisant.
Si un jeu de paramètres complet est présent, la validité de chacun d'entre eux doit être vérifiée, et les réponses appropriées envoyées au client. Dans le cas de messages dont la liste de paramètres utilise une virgule comme séparateur, une réponse doit être envoyée à chaque élément.
Dans les exemples suivants, certains messages apparaissent au format complet
:
:Nom COMMANDE paramètre liste
Ces exemples représentent un message de "Nom" dans le transfert entre serveurs, où il est essentiel d'inclure le nom de l'expéditeur originel du message, de façon à ce que les serveurs distants puissent renvoyer un message le long d'un chemin valide.
Une commande "PASS" n'est pas nécessaire pour établir
une connection, mais elle doit précéder la combinaison suivante
des messages NICK/USER. Il est fortement recommandé que toutes les
connections de serveurs utilisent un mot de passe afin de donner un niveau de
sécurité satisfaisant aux connections. L'ordre des commandes
recommandé pour l'enregistrement d'un client est le suivant :
1.
Message PASS
2. Message NICK
3. Message USER
La commande PASS est utilisée pour définir le 'mot de passe de connection'. Le mot de passe peut et doit être défini avant toute tentative de connection. A l'heure actuelle, cela signifie que les clients doivent envoyer une commande PASS avant d'envoyer la combinaison NICK/USER, et que les serveurs doivent envoyer une commande PASS avant toute commande SERVER. Le mot de passe fourni doit correspondre à celui contenu dans les lignes C/N (pour les serveurs) ou dans les lignes I (pour les clients). Il est possible d'envoyer plusieurs commandes PASS avant de d'enregistrer la connection, mais seule la dernière est utilisée pour la vérification, et elle ne peut plus changer une fois la connection établie.
Réponses numériques :
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExemple:
Le message NICK est utilisé pour donner un pseudonyme à un utilisateur, ou pour changer le pseudonyme précédent. Le paramètre <compteur de distance> n'est utilisé que par les serveurs, et sert à indiquer quelle est la distance entre un utilisateur et son serveur local. Une connection locale a un compter de distance de zéro. Si un client fourni un compteur de distance, il doit être ignoré.
Si un message NICK arrive à un serveur qui connaît déjà un autre client de pseudo identique, une collision de pseudonymes a lieu. Le résultat d'une collision de pseudonymes est la suppression de toutes les instances du pseudonyme de la base du serveur, et l'envoi d'un message KILL afin de retirer le pseudonyme des bases de données de tous les autres serveurs. Si le message NICK à l'origine de la collision de pseudonymes est un changement de pseudonyme, alors le pseudo originel (l'ancien) doit aussi être retiré.
Si le serveur reçoit un NICK identique d'un client auquel il est connecté directement, il peut envoyer un ERR_NICKCOLLISION au client local, ignorer la commande NICK, et ne pas générer de KILLs.
Réponses numériques :
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION
Exemples:
Le message USER est utilisé au début d'une connection pour spécifier le nom d'utilisateur, le nom d'hôte, le nom de serveur, et le véritable nom d'un nouvel utilisateur. Il est aussi utilisé lors de la communication entre les serveurs pour indiquer l'arrivé d'un nouvel utilisateur sur IRC, puisque c'est seulement après avoir envoyé et le USER et le NICK qu'un utilisateur devient enregistré.
Entre serveurs, USER doit être préfixé du pseudonyme du client. Notez que le nom d'hôte et le nom de serveur sont généralement ignorés par le serveur IRC quand la commande USER vient directement d'un client (pour des raisons de sécurité), mais sont utilisés dans la communication de serveur à serveur. Cela signifie que NICK doit toujours être envoyé à un serveur distant quand un nouvel utilisateur est ajouté au reste du réseau, avant que le USER correspondant soit envoyé.
Notez aussi que le paramètre 'vrai nom' doit être le dernier paramètre, car il peut contenir des espaces, et il doit être préfixé par deux points (':') de façon à être reconnu comme tel.
Puisqu'il est facile pour un client de mentir sur son nom si on se base uniquement sur le message USER, il est recommandé d'utiliser un "serveur d'identité". Si l'hôte dont l'utilisateur se connecte a un serveur de ce type activé, le nom d'utilisateur est défini par la réponse de ce "serveur d'identité".
Réponses numériques :
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExemples:
Le message SERVER est utilisé pour dire à un serveur que l'autre bout de la connection est un autre serveur. Ce message est aussi utilisé pour transmettre les données du serveur à tout le réseau. Quand un nouveau serveur se connecte au réseau, les informations le concernant sont diffusées à tout le réseau. <Compteur de distance> est utilisé pour donner à chaque serveur des informations sur leurs distances aux différents serveurs. Avec la liste complète des serveurs, il serrait possible de construire une carte complète de l'arbre des serveurs, mais les masques d'hôtes l'empêchent.
Le message SERVER doit être accepté uniquement (a) soit d'une connection qui n'est pas encore enregistrée et qui essaie de s'enregistrer en tant que serveur, ou (b) d'une connection existante d'un autre serveur, pour introduire un nouveau serveur au delà de ce serveur.
La plupart des erreurs qui ont lieu à la réception d'une commande SERVER résulte en la coupure de la connection avec l'hôte destinataire (serveur destinataire). Les réponses d'erreur sont généralement envoyées en utilisant la commande "ERROR" plutôt qu'une réponse numérique, car la commande ERROR a plusieurs propriétés qui la rendent utile dans ce cas.
Si un message SERVER est traité et tente d'introduire un serveur déjà connu du serveur receveur, la connection avec ce serveur doit être coupé (en suivant les procédures correctes), car une route dupliquée s'est formée avec un serveur, et la nature acyclique de l'arbre IRC rompue.
Réponses numériques :
ERR_ALREADYREGISTREDExemples :
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
; Le
serveur tolsun.oulu.fi est notre lien vers csd.bu.edu qui est à 5
noeuds de nous.
Le message OPER est utilisé par un utilisateur normal pour obtenir le privilège d'opérateur. La combinaison de <utilisateur> et <mot de passe> est nécessaire pour obtenir le privilège Opérateur.
Si le client envoyant la commande OPER fourni un mot de passe correct pour l'utilisateur donné, le serveur informe le reste du réseau du nouvel opérateur en envoyant un "MODE +o" pour le pseudonyme.
Le message OPER n'a lieu qu'entre un client et un serveur.
Réponses numériques :
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH
Exemple:
Une session de client se termine par un message QUIT. Le serveur doit rompre la connection avec le client qui envoie un message QUIT. Si un <Message de départ> est fourni, il sera transmi au lieu du message par défaut, le pseudonyme.
Lorsqu'une division réseau a lieu (déconnexion de deux serveurs), le message de départ est composé du nom des deux serveurs en cause, séparés par un espace. Le premier nom est celui du serveur toujours connecté, et le second, celui qui est désormais inaccessible.
Si pour une autre raison, une connection d'un client est fermée sans que le client ait envoyé de message QUIT (par exemple, le programme client se termine, et une fin de fichier est envoyée sure la socket), le serveur doit remplir le message QUIT avec un message reflétant la nature de l'événement à la cause de cette déconnexion.
Réponses numériques:
Aucune.Exemples:
Le message SQUIT est nécessaire pour signaler le départ ou la mort de serveurs. Si un serveur souhaite rompre une connection à un autre serveur, il doit envoyer un message SQUIT à ce serveur, en utilisant le nom de ce serveur comme paramètre <serveur>, ce qui clos la connection avec le serveur quittant le réseau.
Cette commande est aussi accessible aux opérateurs pour garder un réseau de serveurs IRC connectés proprement. Les opérateurs peuvent également émettre un message SQUIT pour une connection distante d'un serveur. Dans ce cas, le message SQUIT doit être traité par tous les serveurs entre l'opérateur et le serveur distant, tout en mettant à jour la vue du réseau de chaque serveur comme décrit plus loin.
Le <commentaire> doit être présent pour tout opérateur qui exécute un SQUIT sur un serveur distant (qui n'est pas connecté au serveur sur lequel ils sont actuellement). Le <commentaire> est également rempli par les serveurs qui peuvent y placer un message d'erreur ou autre.
Les deux serveurs, de chaque côte de la connection qui va être coupée doivent envoyer un message SQUIT (à tous les serveurs auxquels ils sont connectés) pour tous les serveurs qui sont situés au-delà de ce lien.
De même, un message QUIT doit être envoyé aux autres serveur du reste du réseau de la part de tous les clients au-delà de ce lien. De plus, tous les membres d'un canal qui perdent un membre à cause d'une division réseau doivent recevoir un message QUIT.
Si une connection à un serveur est terminée prématurément, (par exemple si le serveur à l'extrémité de la liaison meurt), le serveur qui détecte cette déconnexion doit informer le reste du réseau que cette connection est fermée, et remplir le champ <commentaire> de façon appropriée.
Réponses numériques :
ERR_NOPRIVILEGES ERR_NOSUCHSERVERExemples:
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
;
message de Trillian pour déconnecter "cm22.eng.umd.edu" du
réseau en raison d'un "serveur incontrôlable".
La commande JOIN est utilisée par un client pour commencer à
écouter un canal spécifique. L'accès à un canal est
autorisé ou non uniquement par le serveur auquel le client est
connecté ; tous les autres serveurs ajoutent automatiquement
l'utilisateur au canal quand la demande vient d'un autre serveur. Les conditions
qui affectent ceci sont les suivantes :
1. L'utilisateur doit être
invité si le canal est en mode "sur invitation seulement"
2.
Le pseudo/nom d'utilisateur/nom d'hôte ne doit pas correspondre à
un bannissement actif.
3. La bonne clé (mot de passe) doit être
fournie si elle est définie.
Ceci est discuté plus en détails dans la description de la commande MODE (voir la section 4.2.3 pour plus de détails).
Une fois qu'un utilisateur a accès à un canal, ils reçoivent des notifications sur toutes les commandes que leur serveur reçoit qui affectent le canal. Cela inclut MODE, KICK, PART, QUIT, et bien sûr PRIVMSG/NOTICE. La commande JOIN doit être diffusée à tous les serveurs du réseau pour qu'ils sachent où trouver qui est dans chaque canal. Cela permet une distribution optimale des messages PRIVMSG/NOTICE du canal.
Si un JOIN a lieu avec succès, on envoie à l'utilisateur le sujet du canal (en utilisant RPL_TOPIC) et la liste des utilisateurs du canal (en utilisant RPL_NAMREPLY), y compris lui-même.
Réponses numériques :
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC
Exemples:
JOIN &foo fubar ; accède au canal &foo en utilisant la clé "fubar".
JOIN #foo,&bar fubar ; accède au canal #foo en utilisant la clé "fubar", et &bar en n'utilisant pas de clé.
JOIN #foo,#bar fubar,foobar ; accède au canal #foo en utilisant la clé "fubar", et au canal #bar en utilisant la clé "foobar".
JOIN #foo,#bar ; accède au canaux #foo and #bar.
:WiZ JOIN #Twilight_zone ; Message JOIN de WiZ
Le message PART provoque le retrait du client expéditeur de la liste des utilisateurs actifs pour tous les canaux listé dans la chaîne de paramètre.
Réponses numériques:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL
Exemples:
PART #oz-ops,&group5 ; quitte les canaux "&group5" et "#oz-ops".
La commande MODE est une commande à utilisation duale sur IRC. Elle permet aussi bien de changer les modes des utilisateurs que ceux des canaux. La raison à ce choix est qu'un jour les pseudonymes deviendront obsolètes et la propriété équivalente sera le canal.
Lors du traitement des messages MODE, il est recommandé de commencer
par décomposer le message en entier, puis de réaliser les
modifications résultantes.
La commande MODE permet aux opérateurs de canaux de changer les caractéristiques de 'leur' canal. Les serveurs doivent aussi pouvoir changer les modes du canal, de façon à pouvoir créer des opérateurs.
Les modes disponibles pour les canaux sont les suivants :
o - donne/retire
les privilèges d'opérateur de canal
p - drapeau de canal
privé
s - drapeau de canal secret
i - drapeau de canal accessible
uniquement sur invitation
t - drapeau de sujet de canal modifiable uniquement
par les opérateurs
n - pas de messages dans un canal provenant de
clients à l'extérieur du canal
m - canal
modéré
l - définit le nombre maximal de personnes dans
un canal
b - défini un masque de bannissement pour interdire
l'accès à des utilisateurs
v - donne/retire la
possibilité de parler dans un canal modéré
k -
défini la clé du canal (mot de passe)
Lors de l'utilisation des options 'o' et 'b', le nombre de paramètres est restreint à trois par commande, et ce pour n'importe quelle combinaison de 'o' et de 'b'.
Les modes utilisateurs sont typiquement des modifications qui affectent la façon dont le client est vu par les autres, ou quels types de messages sont reçus. Une commande MODE n'est acceptée que si l'expéditeur du message et le pseudonyme donné en paramètres sont les même.
Les modes disponibles sont :
i - marque un utilisateur comme invisible
;
s - marque un utilisateur comme recevant les notifications du serveur
;
w - l'utilisateur reçoit les WALLOPs ;
o - drapeau
d'opérateur.
D'autres modes seront disponible plus tard.
Si un utilisateur tente de devenir opérateur en utilisant le drapeau "+o", la tentative doit être ignorée. Par contre, il n'y a pas de restriction à ce que quelqu'un se 'deoppe' (en utilisant "+o").
Réponses numériques :
ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_KEYSET
RPL_BANLIST RPL_ENDOFBANLIST
ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
ERR_USERSDONTMATCH RPL_UMODEIS
ERR_UMODEUNKNOWNFLAG
Exemples:
Utilisation des modes d'utilisateur :
:MODE WiZ -w ; supprime
la réception des messages WALLOPS messages pour WiZ.
:Angel MODE
Angel +i ; Message d'Angel pour le rend invisible.
MODE WiZ
-o ; WiZ se 'deoppe' (retire son statut d'opérateur). Le contraire
de ca ("MODE WiZ +o") ne doit pas être autorisé car
cela court-circuiterait la commande OPER.
Le message TOPIC est utilisé pour modifier ou voir le sujet d'un canal. Le sujet du canal <canal> est renvoyé s'il n'y a pas de <sujet> fourni en paramètre. Si le paramètre <sujet> est présent, le sujet du canal changera si le mode du canal le permet.
Réponses numériques :
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED
Exemples:
En utilisant la commande NAMES, un utilisateur peut obtenir la liste des pseudonymes visibles sur n'importe quel canal qu'il peut voir. Les noms de canaux qu'il peut voir sont ceux qui ne sont ni privés (+p), ni secrets (+s), ou ceux sur lesquels il est actuellement. Le paramètre <canal> spécifie quels sont les canaux dont l'information est voulue, s'ils sont valides. Il n'y a pas de message d'erreur pour les noms de canaux invalides.
Si le paramètre <canal> n'est pas donné, la liste de tous les canaux et de leurs occupants est renvoyée. A la fin de cette liste, sont listés les utilisateurs qui sont visibles, mais qui n'appartiennent à aucun canal. Ils sont listés comme appartenant au canal `channel' "*".
Réponses numériques:
RPL_NAMREPLY RPL_ENDOFNAMESExemples:
Le message liste est utilisé pour lister les canaux et leur sujet. Si le paramètre <canal> est utilisé, seul le statut de ces canaux est affiché. Les canaux privés sont listés (sans leur sujet) comme canal "Prv" à moins que le client qui fasse la requête soit effectivement sur le canal. De même, les canaux secrets ne sont pas listé du tout, à moins que le client soit un membre du canal en question.
Réponses numériques :
ERR_NOSUCHSERVER RPL_LISTSTART
RPL_LIST RPL_LISTEND
Exemples:
Le message INVITE est utilisé pour inviter des utilisateurs dans un canal. Le paramètre <pseudonyme> est le pseudonyme de la personne à inviter dans le canal destination <canal>. Il n'est pas nécessaire que le canal dans lequel la personne est invitée existe, ni même soit valide. Pour inviter une personne dans un canal en mode sur invitation (MODE +i), le client envoyant l'invitation doit être opérateur sur le canal désigné.
Réponses numériques :
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAY
Exemples:
La commande KICK est utilisée pour retirer par la force un utilisateur d'un canal (PART forcé).
Seul un opérateur de canal peut kicker un autre utilisateur hors d'un canal. Tout serveur qui reçoit un message KICK vérifie si le message est valide (c'est-à-dire si l'expéditeur est bien un opérateur du canal) avant d'ôter la victime du canal.
Réponses numériques :
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK