RFC 1459

From Base de connaissances eggdrops & TCL
Jump to: navigation, search

Protocole de discussions relayées par internet (IRC)


Résumé



Introduction

Le protocole IRC (Internet Relay Chat) a été conçu pendant de nombreuses années pour l'usage de conférences en mode texte. Ce document décrit le protocole IRC actuel.

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.


Serveurs

Le serveur est la colonne vertébrale de l'IRC. Il fournit un point auquel les clients peuvent se connecter pour parler entre eux, et un point auquel les autres serveurs peuvent se connecter, formant un réseau IRC. La seule configuration de réseau autorisée est celle d'un arbre [voir Fig. 1] où chaque serveur agit comme un noeud central pour la partie du réseau qu'il voit.

                         [ Serveur 15 ]  [ Serveur 13 ]  [ Serveur 14]
                                 /                \         /
                                /                  \       /
        [ Serveur 11 ] ------ [ Serveur 1 ]       [ Serveur 12]
                              /        \          /
                             /          \        /
                  [ Serveur 2 ]          [ Serveur 3 ]
                    /       \                      \
                   /         \                      \
           [ Serveur 4 ]    [ Serveur 5 ]         [ Serveur 6 ]
            /    |    \                           /
           /     |     \                         /
          /      |      \____                   /
         /       |           \                 /
[ Serveur 7 ] [ Serveur 8 ] [ Serveur 9 ]   [ Serveur 10 ]

                                  :
                               [ etc. ]
                                  :

Clients

Opérateurs

Les canaux

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



Si le réseau IRC devient disjoint en raison d'une division entre deux serveurs, le canal, de chaque côté, est composé des clients qui sont connectés aux serveurs du côté respectif de la division, et ils disparaissent de l'autre côté de la division. Lorsque la division est réparé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 côté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 connexion soient d'accord sur quels clients sont dans quels canaux et quels modes ont les canaux.

Les opérateurs de 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
  • TOPIC - Change le titre du canal, dans un canal en mode +t


La spécification IRC

Aperçu

Le protocole décrit ici vaut aussi bien pour les connexions des serveurs que pour celles des clients. Néanmoins, il y a plus de restrictions sur les connexions des clients (qui sont considérées comme plus douteuses) que sur les connexions des serveurs.

Les jeux de caractères

Aucun jeu de caractères n'est imposé. Le protocole est basé sur un jeu de caractères de huit (8) bits, qui forment un octet ; cependant, certains codes sont utilisés en tant que codes de contrôle, et agissent comme délimiteurs de messages.

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 US-ASCII et d'une connexion telnet.

Étant donnée l'origine scandinave de l'IRC, les caractères {}| sont considérés comme étant respectivement les équivalents en minuscules des caractères []\. Ceci est particulièrement important pour déterminer l'équivalence de deux pseudonymes.

Messages

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 connexion 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ées 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 ê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ées 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. Donc, il y a un maximum de 510 caractères autorisés 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. 2.3.1 Le format de message en 'pseudo' BNF


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> ::=3<espace> [ ':' <fin> | <milieu> <params> ]

<milieu> ::= < <fin> ::= < <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.

<<fin>. <Fin> est une simple astuce syntaxique pour autoriser ESPACE dans le paramètre.

3) Le fait que CR et LF ne puissent pas apparaître dans la chaîne paramètre est une simple assertion. Cela pourrait changer dans le futur.


5) Le dernier paramètre peut être une chaîne vide.

6) L'utilisation d'un préfixe étendu ([ '!' <utilisateur> ] [ '@' <

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) > 2.4 Réponses numériques


3. Concepts IRC


                         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 ]




Exemple 1 :

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

Exemple 2 :

Exemple 3 :

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



3.2.1 À une liste


3.2.2 À un groupe (canal)



Exemple 4 :

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

Exemple 5 :

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

Exemple 6 :


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









4. Détails des messages

Les pages suivantes décrivent les messages reconnus par les serveurs IRC et les clients. Toutes les commandes décrites dans cette section doivent être implémentées par tous les serveurs utilisant ce protocole.

Si la réponse 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ée au client et la décomposition interrompue. Peuvent être considérés comme 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.


Dans les exemples suivants, certains messages apparaissent au format complet :

Nom COMMANDE paramètre liste


4.1 Établissement de connexion

Les commandes décrites dans cette section sont utilisées pour établir une connexion avec un serveur IRC, aussi bien par un client que par un serveur, ainsi qu'une déconnexion correcte.

Une commande "PASS" n'est pas nécessaire pour établir une connexion, mais elle doit précéder la combinaison suivante des messages NICK/USER. Il est fortement recommandé que toutes les connexions de serveurs utilisent un mot de passe afin de donner un niveau de sécurité satisfaisant aux connexions. L'ordre des commandes recommandé pour l'enregistrement d'un client est le suivant : 1. Message PASS 2. Message NICK 3. Message USER 4.1.1 Message PASS

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


Réponses numériques :

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Exemple :

PASS motdepasssecretici

4.1.2 Message NICK

Commande : NICK Paramètres : <pseudonyme> [ <compteur de distance> ]

<


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

Réponses numériques :

         ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
          ERR_NICKNAMEINUSE               ERR_NICKCOLLISION

Exemples :

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

4.1.3 Message USER

Commande: USER Paramètres: <nom d'utilisateur> <hôte> <nom de serveur> <nom réel>

Le message USER est utilisé au début d'une connexion 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ée 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é.



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_ALREADYREGISTRED

Exemples:


4.1.4 Message SERVER

Commande: SERVER Paramètres: <nom de serveur> <compteur de distance> <info>

<




Réponses numériques : ERR_ALREADYREGISTRED

Exemples :

     SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
     ; Le nouveau serveur test.oulu.fi se présente et tente de s'enregistrer. Le nom d'hôte est test.oulu.fi.
     :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server


4.1.5 Message OPER

Commande: OPER Paramètres: <utilisateur> <mot de passe>

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

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

4.1.6 Message QUIT

Commande: QUIT Paramètres: [<Message de départ >]

Une session de client se termine par un message QUIT. Le serveur doit rompre la connexion avec le client qui envoie un message QUIT. Si un <Message de départ> est fourni, il sera transmis 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.


Réponses numériques :

          Aucune.

Exemples :

     QUIT :Parti déjeuner ; Format de message préféré. 

4.1.7 Message SQUIT

Commande: SQUIT Paramètres: <serveur> <commentaire>

<serveur>, ce qui clôt la connexion avec le serveur quittant le réseau.


Le <commentaire> doit être fourni par tous les opérateurs qui exécutent 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.



<commentaire> de façon appropriée.

Réponses numériques :

          ERR_NOPRIVILEGES                ERR_NOSUCHSERVER

Exemples:

     SQUIT tolsun.oulu.fi :Bad Link ?
     ; la liaison au serveur tolson.oulu.fi s'est terminée en raison d'un mauvais lien.
     :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". 

4.2 Opérations sur les canaux

<pseudo> est donné, le serveur puisse vérifier dans l'historique si le pseudo n'a pas changé récemment. 4.2.1 Message JOIN

Commande: JOIN Paramètres: <canal>{,<canal>} [<clé>{,<clé>}]


1. L'utilisateur doit être invité si le canal est en mode "sur invitation seulement"

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



Réponses numériques :

          ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
          ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
          ERR_CHANNELISFULL               ERR_BADCHANMASK
          ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
          RPL_TOPIC

Exemples :

     JOIN #foobar ; accède au canal #foobar.
     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 

4.2.2 Message PART

Commande: PART Paramètres: <canal>{,< canal >}

Le message PART provoque le retrait du client expéditeur de la liste des utilisateurs actifs pour tous les canaux listés dans la chaîne de paramètres.

Réponses numériques:

          ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
          ERR_NOTONCHANNEL

Exemples:

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

4.2.3 Message MODE

Commande: MODE


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. 4.2.3.1 Les modes des canaux

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


Les modes disponibles pour les canaux sont les suivants : o - donne/retire les privilèges d'opérateur de canal p - fanion de canal privé s - fanion de canal secret i - fanion de canal accessible uniquement sur invitation t - fanion de sujet de canal modifiable uniquement par les opérateurs

m - canal modéré l - définit le nombre maximal de personnes dans un canal

v - donne/retire la possibilité de parler dans un canal modéré k - définit la clé du canal (mot de passe)


4.2.3.2 Modes des utilisateurs

Paramètres: <pseudonyme> {[+|-]|i|w|s|o}

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ètre sont les mêmes.

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 - fanion d'opérateur.

D'autres modes seront disponibles plus tard.


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 de canal :
     MODE #Finnish +im ; Rend le canal #Finnish modéré et 'uniquement sur invitation'.


     MODE #Fins -s ; Annule le fanion 'secret' du canal #Fins.
     MODE #42 +k oulu ; Définit la clé comme "oulu".
     MODE &oulu +b ; Liste les masques de bannissement du canal.


     Utilisation des modes d'utilisateur :
     :MODE WiZ -w ; supprime la réception des messages WALLOPS pour WiZ.
     :Angel MODE = Angel +i ; Message d'Angel pour se rendre invisible.
     MODE WiZ -o ; WiZ se 'déoppe' (retire son statut d'opérateur). Le contraire ("MODE WiZ = +o") ne doit pas être autorisé car cela court-circuiterait la commande OPER.

4.2.4 Message TOPIC

Commande: TOPIC Paramètres: <canal> [<sujet>]

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:

     :Wiz TOPIC #test :New topic ; L'utilisateur Wiz définit le sujet.
     TOPIC #test :another topic ; Change le sujet du canal #test en "another topic".
     TOPIC #test ; Vérifie le sujet de #test. 

4.2.5 Message NAMES

Commande: NAMES Paramètres: [<canal>{,<canal>}]

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

Réponses numériques:

          RPL_NAMREPLY                    RPL_ENDOFNAMES

Exemples:

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

4.2.6 Message LIST

Commande: LIST Paramètres: [<canal>{,<canal>} [<serveur>]]

Le message LIST est utilisé pour lister les canaux et leur sujet. Si le paramètre <

Réponses numériques :

          ERR_NOSUCHSERVER                RPL_LISTSTART
          RPL_LIST                        RPL_LISTEND

Exemples :

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

4.2.7 Message INVITE

Commande: INVITE Paramètres: <pseudonyme> <canal>

Le message INVITE est utilisé pour inviter des utilisateurs dans un canal. Le paramètre <<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:

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

4.2.8 Commande KICK

Commande: KICK Paramètres: <canal> <utilisateur> [<commentaire>]

La commande KICK est utilisée pour retirer par la force un utilisateur d'un canal (PART forcé).


Réponses numériques :

          ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
          ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
          ERR_NOTONCHANNEL

Exemples:

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

NOTE:

Il est possible d'étendre les paramètres de la commande KICK ainsi : <canal>{,<canal>} <utilisateur>{,<utilisateur>} [<commentaire>] 4.3 Requêtes et commandes des serveurs


Dans ces requêtes, lorsqu'il y a un paramètre "<serveur>", cela désigne généralement un pseudonyme, un serveur, ou un joker quelconque. Par contre, chaque paramètre ne doit générer qu'une seule requête et un jeu de réponses. 4.3.1 Message VERSION

Commande: VERSION Paramètres: [<serveur>]

Le message VERSION est utilisé pour déterminer la version du programme serveur. Un paramètre optionnel <serveur> est utilisé pour obtenir la version d'un programme serveur sur lequel un client n'est pas connecté directement.

Réponses numériques :

          ERR_NOSUCHSERVER                RPL_VERSION

Exemples :


     VERSION tolsun.oulu.fi ; vérifie la version du serveur "tolsun.oulu.fi".

4.3.2 Message STATS

Commande: STATS Paramètres: [<requête> [<serveur>]]

Le message STATS est utilisé pour obtenir les statistiques d'un serveur. Si le paramètre <serveur> est omis, seule la fin de la réponse STATS est renvoyée. L'implémentation de cette requête dépend énormément du serveur qui répond. Néanmoins, le serveur doit être capable de fournir les informations décrites dans les requêtes ci-dessous (ou équivalent).

Une requête peut être lancée par une unique lettre, qui est vérifiée uniquement par le serveur destination (si le paramètre <

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

Réponses numériques :

          ERR_NOSUCHSERVER
          RPL_STATSCLINE                  RPL_STATSNLINE
          RPL_STATSILINE                  RPL_STATSKLINE
          RPL_STATSQLINE                  RPL_STATSLLINE
          RPL_STATSLINKINFO               RPL_STATSUPTIME
          RPL_STATSCOMMANDS               RPL_STATSOLINE
          RPL_STATSHLINE                  RPL_ENDOFSTATS

Exemples:

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

4.3.3 Message LINKS

Commande: LINKS Paramètres: [[<serveur distant>] <masque de serveur >]

Avec LINKS, un utilisateur peut obtenir la liste des serveurs connue d'un serveur. La liste des serveurs doit correspondre au masque, ou s'il n'y a pas de masque, la liste complète des serveurs est renvoyée.

Si le <serveur distant> est fourni, en plus du <

Réponses numériques :

          ERR_NOSUCHSERVER
          RPL_LINKS                       RPL_ENDOFLINKS

Exemples :



4.3.4 Message TIME

Commande: TIME Paramètres: [<serveur>]

Le message TIME est utilisé pour obtenir l'heure locale d'un serveur donné. En absence de paramètre <

Réponses numériques :

          ERR_NOSUCHSERVER                RPL_TIME

Exemples:

     TIME tolsun.oulu.fi ; demande l'heure du serveur "tolson.oulu.fi"


4.3.5 Message CONNECT

Commande: CONNECT Paramètres: <serveur destination > [<port> [<serveur distant>]]

<serveur distant>, sur le <port> donné.

Réponses numériques :

          ERR_NOSUCHSERVER                ERR_NOPRIVILEGES
          ERR_NEEDMOREPARAMS

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

Commande: TRACE Paramètres: [<serveur>]

<

Si la destination spécifiée par <serveur> est en fait un serveur, alors le serveur destinataire doit lister tous les serveurs et les utilisateurs qui y sont connectés. Si la destination spécifiée par <serveur> est en fait un pseudonyme, seule la réponse pour ce pseudonyme est donnée.

Réponses numériques :

          ERR_NOSUCHSERVER


          RPL_TRACELINK

Une réponse TRACE doit être une des réponses numériques suivantes :

          RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
          RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
          RPL_TRACEUSER                   RPL_TRACESERVER
          RPL_TRACESERVICE                RPL_TRACENEWTYPE
          RPL_TRACECLASS

Exemples:


     :WiZ TRACE AngelDust ; TRACE de WiZ vers le pseudo AngelDust 

4.3.7 Commande ADMIN

Commande: ADMIN Paramètres: [<serveur>]

Le message ADMIN est utilisé pour trouver le nom de l'administrateur d'un serveur donné, ou du serveur courant si le paramètre <serveur> est omis. Tout serveur doit posséder la possibilité de propager les messages ADMIN aux autres serveurs.

Réponses numériques :

          ERR_NOSUCHSERVER
          RPL_ADMINME                     RPL_ADMINLOC1
          RPL_ADMINLOC2                   RPL_ADMINEMAIL

Exemples:

     ADMIN tolsun.oulu.fi ; requête ADMIN de tolsun.oulu.fi


4.3.8 Commande INFO

Commande: INFO Paramètres: [<serveur>]


Réponses numériques :

          ERR_NOSUCHSERVER
          RPL_INFO                        RPL_ENDOFINFO

Exemples :

     INFO csd.bu.edu ; requête INFO pour csd.bu.edu


4.4 Envoi de messages


4.4.1 Messages privés

Commande : PRIVMSG Paramètres : <destinataire>{,<destinataire>} <

PRIVMSG est utilisé pour envoyer un message privé entre des utilisateurs. <destinataire> est le pseudonyme du destinataire du message. <destinataire> peut aussi être une liste de noms ou de canaux, séparés par des virgules.

Le paramètre <

Réponses numériques:

          ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
          ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
          ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
          ERR_NOSUCHNICK
          RPL_AWAY

Exemples :




4.4.2 Notice

Commande : NOTICE Paramètres : <pseudonyme> <texte>


Voir PRIVMSG pour les détails sur les réponses, et pour les exemples. 4.5 Requêtes basées sur les utilisateurs

Les requêtes utilisateurs sont un groupe de commandes dont le but principal est la recherche d'informations sur un utilisateur particulier, ou sur un groupe d'utilisateurs. Lorsqu'on utilise des jokers avec ces commandes, elles ne renvoient les informations que sur les utilisateurs qui vous sont 'visibles'. La visibilité d'un utilisateur est déterminée par la combinaison du mode de cet utilisateur, et des canaux sur lesquels tous les deux êtes. 4.5.1 Requête WHO

Commande: WHO Paramètres: [<nom> [<o>]]

Le message WHO est utilisé par un client pour générer une requête qui renvoie une liste d'informations qui correspondent au paramètre <nom> donné par le client. Si le paramètre nom est absent, tous les utilisateurs visibles (ceux qui ne sont pas invisibles (mode utilisateur +i) et qui n'ont pas de canal en commun avec le client émettant la requête) sont listés. Le même résultat peut être obtenu en utilisant le <

Le <nom> passé en paramètre est mis en correspondance avec les hôtes des utilisateurs, leurs véritables noms, et leurs pseudonymes si le canal <nom> n'est pas trouvé.

Si le paramètre "o" est passé, seuls les opérateurs sont listés, et ce, en fonction du masque fourni.

Réponses numériques :

          ERR_NOSUCHSERVER
          RPL_WHOREPLY                    RPL_ENDOFWHO

Exemples :



4.5.2 Requête WHOIS

Commande: WHOIS Paramètres: [<serveur>] <masque de pseudo>[,<masque de pseudo>[,...]]

<masque de pseudo> (si vous pouvez les voir). S'il n'y a pas de joker dans le <masque de pseudo>, toutes les informations auxquelles vous avez accès au sujet de ce pseudo seront présentées. On peut séparer la liste des pseudonymes avec une virgule (',').


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 ; renvoie les informations disponibles sur le pseudo WiZ
     WHOIS eff.org trillian ; demande au serveur eff.org les informations concernant trillian

4.5.3 WHOWAS

Commande: WHOWAS Paramètres: <pseudonyme> [<compte> [<serveur>]]

<compte> entrées seront retournées (ou toutes si le paramètre <compte> n'est pas donné). Si le nombre passé n'est pas positif, une recherche complète a lieu.

Réponses numériques :

          ERR_NONICKNAMEGIVEN             ERR_WASNOSUCHNICK
          RPL_WHOWASUSER                  RPL_WHOISSERVER
          RPL_ENDOFWHOWAS

Exemples :

     WHOWAS Wiz ; renvoie toutes les informations dans l'historique des pseudos au sujet du pseudo "WiZ";
     WHOWAS Mermaid 9 ; renvoie, au maximum, les neufs entrées les plus récentes dans l'historique des pseudos pour "Mermaid";


4.6 Messages divers

Les messages de cette catégorie ne font partie d'aucune des catégories ci-dessus, mais font néanmoins partie intégrante du protocole, et sont indispensables. 4.6.1 Message KILL

Commande: KILL Paramètres: <pseudonyme> <commentaire>

Le message KILL est utilisé pour provoquer la fermeture de la connexion client/serveur par le serveur qui gère cette connexion. KILL est aussi utilisé par les serveurs qui rencontrent un doublon dans la liste des entrées de pseudonymes valides, afin de retirer les deux entrées. Elle est également accessible aux opérateurs.




Réponses numériques :

          ERR_NOPRIVILEGES                ERR_NEEDMOREPARAMS
          ERR_NOSUCHNICK                  ERR_CANTKILLSERVER

Exemple:

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

NOTE:

4.6.2 Message PING

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


Tout client qui reçoit un message PING doit répondre au <<serveur2> est spécifié, le message PING lui est transmis.

Réponses numériques :

          ERR_NOORIGIN                  ERR_NOSUCHSERVER

Exemples:


     PING WiZ ; message PING envoyé au pseudo WiZ

4.6.3 Message PONG

Commande: PONG Paramètres: <démon> [<démon2>]

<démon2> est donné, le message doit être transmis au démon donné. Le paramètre <démon> est le nom du démon responsable du message PING généré.

Réponses numériques :

          ERR_NOORIGIN                    ERR_NOSUCHSERVER

Exemples :


4.6.4 Message ERROR

Commande: ERROR Paramètres: < message d'erreur>




Réponses numériques :

          Aucune.

Exemples :



5. Messages optionnels


5.1 AWAY

Commande: AWAY Paramètres: [message]


Le message AWAY est utilisé soit avec un paramètre (pour définir un message AWAY) ou sans (pour retirer le message AWAY).

Réponses numériques :

          RPL_UNAWAY                      RPL_NOWAWAY

Exemples:


     :WiZ AWAY ; supprime l'absence de WiZ.

5.2 Message REHASH

Commande: REHASH Paramètres: Aucun


Réponses numériques :

       RPL_REHASHING                   ERR_NOPRIVILEGES

Exemples :

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

5.3 Message RESTART

Commande : RESTART Paramètres : Aucun



Réponses numériques :

          ERR_NOPRIVILEGES

Exemples :

     RESTART ; pas de paramètres 

5.4 Message SUMMON

Commande : SUMMON Paramètres : <utilisateur> [<serveur>]


Si le paramètre <serveur> n'est pas donné, cela essaie d'appeler l'<utilisateur> du serveur sur lequel le client est connecté.

Si le SUMMON est désactivé sur un serveur, il doit renvoyer la réponse numérique ERR_SUMMONDISABLED et transmettre le message SUMMON.

Réponses numériques :

          ERR_NORECIPIENT                 ERR_FILEERROR
          ERR_NOLOGIN                     ERR_NOSUCHSERVER
          RPL_SUMMONING

Exemples :

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

5.5 Commande USERS

Commande: USERS Paramètres: [<serveur>]


Réponses numériques :

          ERR_NOSUCHSERVER                ERR_FILEERROR
          RPL_USERSSTART                  RPL_USERS
          RPL_NOUSERS                     RPL_ENDOFUSERS
          ERR_USERSDISABLED

Réponse de désactivation :

          ERR_USERSDISABLED

Exemples:

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

5.6 Message WALLOPS

Commande : WALLOPS



Réponses numériques :

          ERR_NEEDMOREPARAMS

Exemples :

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

5.7 Message USERHOST

Commande : USERHOST Paramètres : <pseudonyme>{<espace ><pseudonyme>}


Réponses numériques :

          RPL_USERHOST            ERR_NEEDMOREPARAMS

Exemples :

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

5.8 Message ISON

Commande : ISON Paramètres : <pseudonyme>{<espace><pseudonyme>}


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

Réponses numériques :

          RPL_ISON                ERR_NEEDMOREPARAMS

Exemples :

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

6. Réponses


6.1 Réponses d'erreur

401 ERR_NOSUCHNICK

   "<pseudonyme> :No such nick/channel" 


402 ERR_NOSUCHSERVER

   "<nom de serveur> :No such server" 

Utilisé pour indiquer que le nom du serveur donné n'existe pas actuellement.

403 ERR_NOSUCHCHANNEL

   "<nom de canal> :No such channel" 

Utilisé pour indiquer que le nom de canal donné est invalide.

404 ERR_CANNOTSENDTOCHAN

   "<nom de canal> :Cannot send to channel" 


405 ERR_TOOMANYCHANNELS

   "<nom de canal> :You have joined too many channels" 


406 ERR_WASNOSUCHNICK

   "<nom de canal> :There was no such nickname" 

Renvoyé par WHOWAS pour indiquer qu'il n'y a pas d'information dans l'historique concernant ce pseudonyme.

407 ERR_TOOMANYTARGETS

   "<destination> :Duplicate recipients. No message delivered" 


409 ERR_NOORIGIN

   ":No origin specified" 

Message PING ou PONG sans le paramètre origine qui est obligatoire puisque ces commandes doivent marcher sans préfixe.

411 ERR_NORECIPIENT

   ":No recipient given (<commande>)" 

Pas de destinataire.

412 ERR_NOTEXTTOSEND

   ":No text to send" 


413 ERR_NOTOPLEVEL

   "<masque> :No toplevel domain specified" 

Domaine principal non spécifié.

414 ERR_WILDTOPLEVEL

   "<masque> :Wildcard in toplevel domain" 

Joker dans le domaine principal

Les erreurs 412-414 sont renvoyées par PRIVMSG pour indiquer que le message n'a pas été délivré. ERR_NOTOPLEVEL et ERR_WILDTOPLEVEL sont les erreurs renvoyées lors d'une utilisation invalide de "PRIVMSG $<serveur>" ou de "PRIVMSG #<hôte>".

421 ERR_UNKNOWNCOMMAND

   "<commande> :Unknown command" 


422 ERR_NOMOTD

   ":MOTD File is missing" 

Le fichier MOTD du serveur n'a pas pu être ouvert.

423 ERR_NOADMININFO

   "<serveur> :No administrative info available" 


424 ERR_FILEERROR ":File error doing <opération> on <fichier>" Message d'erreur générique utilisé pour rapporter un échec d'opération de fichier durant le traitement d'un message.

431 ERR_NONICKNAMEGIVEN

   ":No nickname given" 

Renvoyé quand un paramètre pseudonyme attendu pour une commande n'est pas fourni.

432 ERR_ERRONEUSNICKNAME

   "<pseudo> :Erroneus nickname" 

Renvoyé après la réception d'un message NICK qui contient des caractères qui ne font pas partie du jeu autorisé. Voir les sections 1 et 2.2 pour les détails des pseudonymes valides.

433 ERR_NICKNAMEINUSE

   "<nick> :Nickname is already in use" 


436 ERR_NICKCOLLISION

   "<nick> :Nickname collision KILL" 


441 ERR_USERNOTINCHANNEL

   "<pseudo> <canal> :They aren't on that channel" 

Renvoyé par un serveur pour indiquer que l'utilisateur donné n'est pas dans le canal spécifié.

442 ERR_NOTONCHANNEL

   "<canal> :You're not on that channel" 

Renvoyé par le serveur quand un client essaie une commande affectant un canal dont il ne fait pas partie.

443 ERR_USERONCHANNEL

   "<utilisateur> <channel> :is already on channel" 


444 ERR_NOLOGIN

   "<utilisateur> :User not logged in" 

Renvoyé par un SUMMON si la commande n'a pas pu être accomplie, car l'utilisateur n'est pas connecté.

445 ERR_SUMMONDISABLED

   ":SUMMON has been disabled" 


446 ERR_USERSDISABLED

   ":USERS has been disabled" 


451 ERR_NOTREGISTERED

   ":You have not registered" 


461 ERR_NEEDMOREPARAMS

   "<commande> :Not enough parameters" 

Renvoyé par un serveur par de nombreuses commandes, afin d'indiquer que le client n'a pas fourni assez de paramètres.

462 ERR_ALREADYREGISTRED

   ":You may not reregister" 


463 ERR_NOPERMFORHOST

   ":Your host isn't among the privileged" 


464 ERR_PASSWDMISMATCH

   ":Password incorrect" 


465 ERR_YOUREBANNEDCREEP

   ":You are banned from this server" 

Retourné après une tentative de connexion et d'enregistrement sur un serveur configuré explicitement pour vous refuser les connexions.

467 ERR_KEYSET

   "<canal> :Channel key already set" 


471 ERR_CHANNELISFULL

   "<canal> :Cannot join channel (+l)" 

Impossible de joindre le canal (+l)

472 ERR_UNKNOWNMODE

   "<caractère> :is unknown mode char to me" 

Mode inconnu.

473 ERR_INVITEONLYCHAN

   "<canal> :Cannot join channel (+i)" 

Impossible de joindre le canal (+i).

474 ERR_BANNEDFROMCHAN

   "<canal> :Cannot join channel (+b)" 

Impossible de joindre le canal (+b).

475 ERR_BADCHANNELKEY

   "<canal> :Cannot join channel (+k)" 

Impossible de joindre le canal (+k).

481 ERR_NOPRIVILEGES

   ":Permission Denied- You're not an IRC operator" 

Toute commande qui requiert le privilège d'opérateur pour opérer doit retourner cette erreur pour indiquer son échec.

482 ERR_CHANOPRIVSNEEDED

   "<canal> :You're not channel operator" 


483 ERR_CANTKILLSERVER

   ":You cant kill a server!" 

Toute tentative d'utiliser la commande KILL sur un serveur doit être refusée et cette erreur renvoyée directement au client.

491 ERR_NOOPERHOST

   ":No O-lines for your host" 

Si un client envoie un message OPER et que le serveur n'a pas été configuré pour autoriser les connexions d'opérateurs de cet hôte, cette erreur doit être retournée.

501 ERR_UMODEUNKNOWNFLAG

   ":Unknown MODE flag" 

Renvoyé par un serveur pour indiquer que le message MODE a été envoyé avec un pseudonyme et que le mode spécifié n'a pas été identifié.

502 ERR_USERSDONTMATCH

   ":Cant change mode for other users" 


6.2 Réponses aux commandes

300 RPL_NONE

Numéro de réponse bidon. Inutilisé.

302 RPL_USERHOST

   ":[<réponse>{<espace><réponse>}]" 


<réponse> ::= <pseudo>['*'] '=3D' <'+'|'-'><hôte> Le '*' indique si le client est enregistré comme opérateur. Les caractères '-' ou '+' indiquent respectivement si le client a défini un message AWAY ou non.

303 RPL_ISON

   ":[<pseudo> {<espace><pseudo>}]" 


301 RPL_AWAY

   "<pseudo> :<message d'absence>" 

305 RPL_UNAWAY

   ":You are no longer marked as being away" 

306 RPL_NOWAWAY

   ":You have been marked as being away" 


311 RPL_WHOISUSER

   "<pseudo> <utilisateur> <hôte> * :<vrai nom>" 

312 RPL_WHOISSERVER

   "<pseudo> <serveur> :<info serveur>" 

313 RPL_WHOISOPERATOR

   "<pseudo> :is an IRC operator" 

317 RPL_WHOISIDLE

   "<pseudo> <integer> :seconds idle" 

318 RPL_ENDOFWHOIS

   "<pseudo> :End of /WHOIS list" 

319 RPL_WHOISCHANNELS

   "<pseudo> :{[@|+]<canal><espace>}" 


314 RPL_WHOWASUSER

   "<pseudo> <utilisateur> <hôte> * :<vrai nom>" 

369 RPL_ENDOFWHOWAS

   "<pseudo> :End of WHOWAS" 


321 RPL_LISTSTART

   "Channel :Users Name" 

322 RPL_LIST

   "<canal> <# visible> :<sujet>" 

323 RPL_LISTEND

   ":End of /LIST" 

Les réponses RPL_LISTSTART, RPL_LIST, RPL_LISTEND marquent le début, les réponses proprement dites, et la fin du traitement d'une commande LIST. S'il n'y a aucun canal disponible, seules les réponses de début et de fin sont envoyées.

324 RPL_CHANNELMODEIS

   "<canal> <mode> <paramètres de mode>"

331 RPL_NOTOPIC

   "<canal> :No topic is set" 

332 RPL_TOPIC

   "<canal> :<sujet>" 

Lors de l'envoi d'un message TOPIC pour déterminer le sujet d'un canal, une de ces deux réponses est envoyée. Si le sujet est défini, RPL_TOPIC est renvoyée, sinon c'est RPL_NOTOPIC.

341 RPL_INVITING

   "<canal> <pseudo>" 

Renvoyé par un serveur pour indiquer que le message INVITE a été enregistré, et est en cours de transmission au client final.

342 RPL_SUMMONING

   "<utilisateur> :Summoning user to IRC"


351 RPL_VERSION

   "<version>.<debuglevel> <serveur> :<commentaires>" 

Réponse du serveur indiquant les détails de sa version. <<debuglevel> est utilisé pour indiquer si le serveur fonctionne en mode débugage. Le champ <commentaire> peut contenir n'importe quel commentaire au sujet de la version, ou des détails supplémentaires sur la version.

352 RPL_WHOREPLY

   "<canal> <utilisateur> <hôte> <serveur> <pseudo> <H|G>[*][@|+] :<compteur de distance> <vrai nom>" 

315 RPL_ENDOFWHO

   "<nom> :End of /WHO list" 

<nom> étant l'élément.

353 RPL_NAMREPLY

   "<canal> :[[@|+]<pseudo> +]<pseudo> [...]" 

366 RPL_ENDOFNAMES

   "<canal> :End of /NAMES list" 


364 RPL_LINKS

   "<masque> <serveur> :<compteur de distance> <info serveur>" 

365 RPL_ENDOFLINKS

   "<mask> :End of /LINKS list" 


367 RPL_BANLIST

   "<canal> <identification de bannissement>" 

368 RPL_ENDOFBANLIST

   "<canal> :End of channel ban list"

Quand il liste les bannissements actifs pour un canal donné, un serveur doit renvoyer la liste en utilisant les messages RPL_BANLIST et RPL_ENDOFBANLIST. Un RPL_BANLIST différent doit être utilisé pour chaque identification de bannissement. Après avoir listé les identifications de bannissement (s'il y en a), un RPL_ENDOFBANLIST doit être renvoyé.

371 RPL_INFO

   ":<chaîne>" 

374 RPL_ENDOFINFO

   ":End of /INFO list" 


375 RPL_MOTDSTART

   ":- <serveur> Message of the day - " 

372 RPL_MOTD

   ":- <texte>" 

376 RPL_ENDOFMOTD

   ":End of /MOTD command" 


381 RPL_YOUREOPER

   ":You are now an IRC operator"


382 RPL_REHASHING

   "<fichier de configuration> :Rehashing" 


391 RPL_TIME

   "<serveur> :<chaîne indiquant l'heure locale du serveur>" 


392 RPL_USERSSTART

   ":UserID Terminal Hôte" 

393 RPL_USERS

   ":%-8s %-9s %-8s" 

394 RPL_ENDOFUSERS

   ":End of users" 

395 RPL_NOUSERS

   ":Nobody logged in" 

Si le message USERS est géré 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 soit une séquence de RPL_USERS soit un unique RPL_NOUSER. Enfin, vient un RPL_ENDOFUSERS.

200 RPL_TRACELINK

   "Link <version & niveau de débugage> <destination> <serveur suivant>" 

201 RPL_TRACECONNECTING

   "Try. <classe> <serveur>" 

202 RPL_TRACEHANDSHAKE

   "H.S. <classe> <serveur>" 

203 RPL_TRACEUNKNOWN

   "???? <classe> [<adresse IP du client au format utilisant des points>]" 

204 RPL_TRACEOPERATOR

   "Oper <classe> <pseudo>" 

205 RPL_TRACEUSER

   "User <classe> <pseudo>" 

206 RPL_TRACESERVER

   "Serv <classe> <int>S <int>C <serveur> <pseudo!utilisateur|*!*>@<hôte|serveur>" 

208 RPL_TRACENEWTYPE

   "<nouveau type> 0 <nom du client>" 

261 RPL_TRACELOG

   "File <fichier log> <niveau de débugage>" 


211 RPL_STATSLINKINFO

   "<nom du lien> <sendq> <messages envoyés> <octets envoyés> <message reçus> <octets reçus> <temps de connexion>" 

212 RPL_STATSCOMMANDS

   "<commande> <compteur>" 

213 RPL_STATSCLINE

   "C <hôte> * <nom> <port> <classe>" 

214 RPL_STATSNLINE

   "N <hôte> * <nom> <port> <classe>" 

215 RPL_STATSILINE

   "I <hôte> * <hôte> <port> <classe>" 

216 RPL_STATSKLINE

   "K <hôte> * <nom d'utilisateur> <port> <classe>" 

218 RPL_STATSYLINE

   "Y <classe> <fréquence des PINGS> <fréquence de connexion> <sendq max>" 

219 RPL_ENDOFSTATS

   "<lettre de stats> :End of /STATS report" 

241 RPL_STATSLLINE

   "L <masque d'hôte> * <nom de serveur> <profondeur maxi>" 

242 RPL_STATSUPTIME

   ":Server Up %d days %d:%02d:%02d" 

243 RPL_STATSOLINE

   "O <masque d'hôte> * <nom>" 

244 RPL_STATSHLINE

   "H <masque d'hôte> * <nom de serveur>" 

221 RPL_UMODEIS

   "<chaîne de mode utilisateur>" 


251 RPL_LUSERCLIENT

   ":There are <entier> users and <entier> invisible on <entier> servers" 

252 RPL_LUSEROP

   "<entier> :operator(s) online" 

253 RPL_LUSERUNKNOWN

   "<entier> :unknown connection(s)" 

254 RPL_LUSERCHANNELS

   "<entier> :channels formed" 

255 RPL_LUSERME

   ":I have <entier> clients and <integer> servers" 

Lors du traitement d'un message LUSERS, le serveur envoie un lot de réponses parmi RPL_LUSERCLIENT, RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS et RPL_LUSERME. Lorsqu'il répond, un serveur doit envoyer RPL_LUSERCLIENT et RPL_LUSERME. Les autres réponses ne sont renvoyées que si le nombre trouvé n'est pas nul.

256 RPL_ADMINME

   "<serveur> :Administrative info" 

257 RPL_ADMINLOC1

   ":<info admin>" 

258 RPL_ADMINLOC2

   ":<info admin>" 

259 RPL_ADMINEMAIL

   ":<info admin>" 


6.3 Nombres réservés.

Ces nombres ne sont pas décrits ci-dessus parce qu'ils tombent dans l'une des catégories suivantes :

  1. Plus utilisés ;


       209     RPL_TRACECLASS          217     RPL_STATSQLINE
       231     RPL_SERVICEINFO         232     RPL_ENDOFSERVICES
       233     RPL_SERVICE             234     RPL_SERVLIST
       235     RPL_SERVLISTEND
       316     RPL_WHOISCHANOP         361     RPL_KILLDONE
       362     RPL_CLOSING             363     RPL_CLOSEEND
       373     RPL_INFOSTART           384     RPL_MYPORTIS
       466     ERR_YOUWILLBEBANNED     476     ERR_BADCHANMASK
       492     ERR_NOSERVICEHOST

7. Authentification des clients et des serveurs




8. Implémentations actuelles


    * La présence de tout LF ou tout CR dans le message marque sa fin (au lieu de la séquence préconisée CR-LF) ;

Le reste de cette section traite de questions qui sont pour la plupart intéressantes pour ceux qui veulent mettre en œuvre un serveur, mais certaines s'appliquent aussi directement aux clients. 8.1 Protocole Réseau : pourquoi TCP est le plus approprié


8.1.1 Support des sockets Unix



8.2 Traitement des commandes


8.3 Distribution de message



8.4 La vie d'une connexion





8.6 Établissement d'une connexion serveur/serveur

{ - dont le moindre est une condition de compétition.}

Après avoir reçu une connexion suivie d'une paire PASS/SERVER qui a été reconnue valide, le serveur doit répondre avec ses propres informations PASS/SERVER pour cette connexion, ainsi que toutes les informations d'état qu'il connaît comme décrit ci-dessous.

Quand le serveur initiant reçoit la paire PASS/SERVER, lui aussi vérifie que le serveur répondant est authentifié correctement avant d'accepter la connexion comme étant ce serveur.


L'ordre des informations d'état échangées entre les serveurs est essentiel. L'ordre requis est le suivant :

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

Les informations concernant les serveurs sont envoyées avec des messages SERVER supplémentaires, les informations utilisateurs avec des messages NICK/USER/MODE/JOIN et celles des canaux avec des messages MODE.

NOTE : Les sujets des canaux NE SONT PAS échangés ici, car la commande TOPIC écrase toute information de sujet précédente, si bien que, au mieux, les deux côtés de la connexion échangeraient les sujets.


8.7 Terminaison des connexions serveur/client

Lorsqu'une connexion client se ferme, un message QUIT est généré de la part du client par le serveur sur lequel le client était connecté. Aucun autre message ne doit être généré ou utilisé. 8.8 Terminaison des connexions serveur/serveur


8.9 Suivi des changements de pseudonymes

Tous les serveurs IRC doivent garder un historique des changements récents de pseudonymes. Cela est nécessaire pour offrir au serveur la possibilité de garder le contact quand une commande concerne un utilisateur changeant de pseudo. Les commandes qui doivent vérifier un changement de pseudo sont :

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

Aucune autre commande ne doit vérifier un changement de pseudo.


Pour un historique parfait, un serveur devrait être capable de garder les pseudonymes de tous les clients qui ont décidé d'un changement. La taille est limitée par d'autres facteurs (tels que la mémoire, ...) 8.10 Contrôle d'inondation des clients



   * lire toute donnée présentée par le client ;


Ce qui, en essence, signifie qu'un client ne peut envoyer plus d'un message toutes les deux secondes sans être affecté. 8.11 Boucles non bloquantes


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

L'utilisation des librairies de résolution standard de Berkeley et autres entraîne de gros délais, dans les cas où les réponses n'arrivent pas. Afin d'éviter cela, un jeu de routines DNS indépendantes a été écrit, où les opérations DNS ont été écrites avec des E/S non bloquantes et testées depuis la boucle d'E/S principale du serveur. 8.11.2 Recherche du nom d'utilisateur (IDENT)


8.12 Fichier de configuration

Afin de fournir une façon flexible de configurer et de lancer le serveur, il est recommandé qu'un fichier de configuration soit utilisé, qu'il contienne les instructions du serveur suivantes :

   * de quels hôtes accepter une connexion en tant que client;
   * de quels hôtes accepter une connexion en tant que serveur;
   * informations sur l'emplacement du serveur (université, ville/état, entreprise par exemple) ;
   * quels sont les responsables du serveur, avec une adresse email où ils peuvent être contactés ;
   * noms d'hôtes et mots de passe pour les clients qui souhaitent obtenir l'accès restreint aux commandes d'opérateur.



   * spécification de quels serveurs un serveur peut introduire ;
   * heures durant lesquelles un client peut se connecter 

8.12.1 Autorisation des connexions de clients

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

'Accepter' et 'interdire' doivent tous deux être implémentés pour fournir le niveau de flexibilité requis par le contrôle d'accès des hôtes. 8.12.2 Opérateurs


8.12.3 Autorisation des connexions de serveurs


8.12.4 Admin



9. Problèmes actuels


9.1 Localisation


Identifiants

Pseudonymes

Canaux

La configuration actuelle des canaux nécessite que tous les serveurs connaissent tous les canaux, leurs membres, et leurs propriétés. En plus du dimensionnement inadapté, la confidentialité pose aussi problème. La collision de canaux est gérée de façon inclusive (les deux personnes qui créent le canal sont considérées comme en étant membres) plutôt que de façon exclusive telle que celle utilisée pour résoudre les collisions de pseudonymes.

Serveurs

Bien que le nombre de serveurs soit habituellement petit comparé au nombre d'utilisateurs et de canaux, ils doivent aussi être connus globalement, soit chacun séparément, soit caché derrière un masque.

Algorithmes

À certains endroits du code du serveur, il n'a pas été possible d'éviter des algorithmes N^2, comme par exemple dans la vérification de la liste des canaux d'un ensemble de clients.


Actuellement, en raison du manque d'étiquettes internes et globales uniques, il existe une multitude de conditions pouvant causer une désynchronisation. Ces conditions résultent généralement du temps pris par un message pour traverser le réseau IRC. Mais, même en changeant pour des étiquettes uniques, il y a des problèmes de synchronisation avec les commandes liées aux canaux.

Support actuel et disponibilité

    1. Protocole futur : ircd-three-request@eff.org
    2. Discussion générale: operlist-request@eff.org =
  1. Implémentations logicielles
    1. cs.bu.edu:/irc
    2. nic.funet.fi:/pub/irc
    3. coombs.anu.edu.au:/pub/irc
  2. Newsgroup: alt.irc

Considérations de sécurité

La sécurité est traitée dans les sections 4.1, 4.1.1, 4.1.3, 5.5, et 7.

Auteurs

  • Jarkko Oikarinen jto@tolsun.oulu.fi
  • Darren Reed avalon@coombs.anu.edu.au

Traduction

  • Traduit de l'anglais par JM "Nirgal" Vourgère
  • Correction Maryse Levavasseur