RFC IRC : La spécification IRC
2.1 AperçuLe protocole décrit ici vaut aussi bien pour
les connections des serveurs que pour celles des clients. Néanmoins, il y a plus
de restrictions sur les connections des clients (qui sont considérés comme plus
douteuses) que les connections des serveurs.
2.2 Les jeux de caractèresAucun jeu de caractères n'est
imposé. Le protocole est basé sur un jeu de caractère 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 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.
2.3 MessagesLes serveurs et les clients s'envoient
chacun des messages qui peuvent ou non générer une réponse. Si le message
contient une commande valide, comme il est décrit dans les sections suivantes,
le client devrait s'attendre à une réponse comme spécifié, mais il n'est pas
conseillé d'attendre éternellement une réponse. La communication de client à
serveur, et de serveur à serveur est essentiellement de nature asynchrone.
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.
2.3.1 Le format de message en 'pseudo' BNFLes messages
du protocole doivent être extrait du flux continu d'octets. La solution actuelle
consiste à désigner deux caractères donnés, CR et LF, comme séparateurs de
messages. Les messages vides sont ignorés en silence, ce qui permet l'usage
d'une suite de CR-LF entre les messages sans problèmes supplémentaires.
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) >
2.4 Réponses numériquesLa plupart des messages envoyés
aux serveurs génère une réponse. Les réponses les plus courantes sont des
réponses numériques, aussi bien pour les messages d'erreurs que pour les
réponses normales. La réponse numérique est envoyé comme un message contenant le
préfixe de l'expéditeur, le nombre de trois chiffres, et le destinataire de la
réponse. Une réponse numérique ne peut pas émaner d'un client, et tout message
de ce style reçu par un serveur doit être ignoré silencieusement. Hormis cela,
une réponse numérique est un message comme un autre, si ce n'est que le mot-clé
est composé de trois chiffres, plutôt que d'une suite de lettre. Une liste des
réponses possible est fournie à la section 6.
|