La RFC 1459 a ete publiee en mai 1993 par Jarkko Oikarinen (le createur d'IRC) et Darren Reed. C'est le document qui a formalise le protocole IRC apres quatre ans d'existence (IRC date de 1988). J'ai lu cette RFC pour la premiere fois en 2000 quand j'ai voulu ecrire mon premier bot. Je l'ai relue des dizaines de fois depuis. C'est un document de 65 pages qui definit un protocole encore utilise, dans ses grandes lignes, 30 ans plus tard.
Contexte historique
IRC existait depuis 1988 sans specification formelle. Le protocole etait defini par le code source d'ircd (l'implementation de reference). Chaque developpeur qui forkait ircd ajoutait ses propres extensions, ce qui creait des incompatibilites entre reseaux. La RFC 1459 a ete une tentative de standardiser le protocole.
Le resultat est imparfait. La RFC 1459 decrit le protocole tel qu'il fonctionnait a l'epoque, pas tel qu'il devrait fonctionner idealement. Certaines decisions de design sont discutables (le format des messages est ambigu dans certains cas, la gestion des collisions de nicks est problematique). Mais le document a le merite d'exister et d'avoir donne un cadre commun.
La RFC 2812 (2000) a tente de corriger certains problemes, mais n'a jamais ete largement adoptee. En pratique, les IRCds modernes implementent un melange de RFC 1459, RFC 2812, et extensions proprietaires. Le projet IRCv3 tente de standardiser les extensions modernes.
Format des messages
# Format d'un message IRC (RFC 1459, section 2.3.1) :
# [:prefix] COMMAND [params] [:trailing]
# Exemples :
:nick!user@host PRIVMSG #canal :Bonjour tout le monde
:serveur.com 001 nick :Welcome to the IRC Network
PING :serveur.com
JOIN #canal
QUIT :A plus tard
# Decomposition :
# 1. Le prefix (optionnel, commence par ':')
# Identifie l'origine du message.
# Pour un message d'utilisateur : nick!user@host
# Pour un message du serveur : nom.du.serveur
#
# 2. La commande
# Soit un mot (PRIVMSG, JOIN, QUIT...)
# Soit un code numerique a 3 chiffres (001, 332, 433...)
#
# 3. Les parametres (separes par des espaces)
# Maximum 15 parametres
# Le dernier peut commencer par ':' pour contenir des espaces
# Contraintes :
# - Longueur maximale : 512 octets (inclus CR-LF)
# - Fin de ligne : \r\n (CR-LF)
# - Pas de null byte dans le message
# La limite de 512 octets est la plus contraignante.
# Avec un prefix long (nick!~username@very.long.hostname.com)
# il reste parfois moins de 400 caracteres pour le message.
# C'est pourquoi les messages IRC sont courts.Le format est simple mais les details comptent. La limite de 512 octets (incluant le prefix, la commande, les parametres, et CR-LF) est la contrainte la plus impactante du protocole. Elle force les messages courts et rend impossible l'envoi de contenus structures (fichiers, images, formatage riche) dans le protocole de base.
message-length), mais 512 reste la valeur de reference.Sequence de connexion
# Sequence client -> serveur :
# 1. Connexion TCP
# Le client ouvre une connexion TCP sur le port 6667
# (ou 6697 pour TLS)
# 2. Enregistrement
PASS motdepasse # Optionnel (mot de passe serveur)
NICK MonNick # Definir le nick
USER username 0 * :Real Name # Definir l'identite
# 3. Le serveur repond avec :
:serveur 001 MonNick :Welcome to the Network MonNick!user@host
:serveur 002 MonNick :Your host is serveur, running version X
:serveur 003 MonNick :This server was created ...
:serveur 004 MonNick serveur version modes_user modes_canal
:serveur 005 MonNick NETWORK=MonReseau CHANTYPES=#& ... :are supported
# 4. LUSERS (statistiques)
:serveur 251 MonNick :There are 150 users and 30 invisible on 3 servers
:serveur 252 MonNick 5 :operator(s) online
:serveur 254 MonNick 200 :channels formed
:serveur 255 MonNick :I have 80 clients and 2 servers
# 5. MOTD (Message of the Day)
:serveur 375 MonNick :- serveur Message of the Day -
:serveur 372 MonNick :- Bienvenue sur le serveur ...
:serveur 376 MonNick :End of /MOTD command.
# Le client est maintenant enregistre et peut
# envoyer des commandes (JOIN, PRIVMSG, etc.)
# SASL (extension IRCv3) ajoute une etape entre
# la connexion TCP et le NICK/USER :
CAP REQ :sasl
AUTHENTICATE PLAIN
AUTHENTICATE base64(nick\0nick\0password)
CAP ENDCommandes fondamentales
# JOIN — Rejoindre un canal :
JOIN #canal
JOIN #canal cle_si_+k
JOIN #canal1,#canal2 # Plusieurs canaux
JOIN 0 # Quitter TOUS les canaux (rarement utilise)
# PART — Quitter un canal :
PART #canal
PART #canal :Message de depart
# PRIVMSG — Envoyer un message :
PRIVMSG #canal :Message au canal
PRIVMSG nick :Message prive
# Malgre le nom, PRIVMSG est utilise pour TOUS les messages
# (publics et prives). Le nom est trompeur.
# NOTICE — Message sans reponse automatique :
NOTICE nick :Information
# La RFC interdit aux clients de repondre automatiquement
# a un NOTICE. C'est pour eviter les boucles entre bots.
# KICK — Expulser quelqu'un :
KICK #canal nick :Raison
# MODE — Changer les modes :
MODE #canal +o nick # Donner operateur
MODE #canal -o nick # Retirer operateur
MODE #canal +b *!*@host # Bannir
MODE nick +i # Se rendre invisible
# TOPIC — Changer le sujet :
TOPIC #canal :Nouveau sujet
TOPIC #canal # Lire le sujet actuel
# QUIT — Se deconnecter :
QUIT :Message de depart
# PING / PONG — Keepalive :
# Le serveur envoie periodiquement :
PING :serveur.com
# Le client DOIT repondre :
PONG :serveur.com
# Si le client ne repond pas, il est deconnecte
# (Ping timeout)Modes utilisateur et canal
# Modes utilisateur (RFC 1459) :
# +i invisible — n'apparait pas dans /WHO global
# +s server notices — recoit les notices du serveur
# +w wallops — recoit les messages wallops
# +o operator — est operateur IRC (IRCop)
# Modes de canal (RFC 1459) :
# +o nick — operateur de canal (@)
# +v nick — voice (+)
# +b mask — ban
# +i — invite only
# +k cle — mot de passe requis pour entrer
# +l N — limite d'utilisateurs
# +m — modere (seuls +o et +v parlent)
# +n — pas de messages externes
# +p — prive (n'apparait pas dans /LIST)
# +s — secret (invisible dans /LIST et /WHOIS)
# +t — seuls les ops changent le topic
# Extensions courantes (pas dans la RFC 1459) :
# +h nick — half-operator (%) [pas standard]
# +q nick — owner (~) ou quiet [depend de l'IRCd]
# +a nick — admin/protect (&) [depend de l'IRCd]
# +S — TLS seulement
# +r — enregistres seulement
# +R — regname seulement
# +f N:S — anti-flood
# +j N:T — throttle de joins
# Les modes varient enormement entre IRCds.
# Ce qui est +q sur UnrealIRCd (owner) est
# different de +q sur InspIRCd (quiet).
# Toujours verifier la documentation de votre IRCd.+q, +a, +h, ou +R. Chaque IRCd les implemente differemment. C'est un des problemes fondamentaux du protocole IRC.Codes numeriques
# Les reponses du serveur utilisent des codes a 3 chiffres.
# Quelques codes importants :
# Enregistrement :
001 RPL_WELCOME # Bienvenue
002 RPL_YOURHOST # Info serveur
003 RPL_CREATED # Date de creation
004 RPL_MYINFO # Modes supportes
005 RPL_ISUPPORT # Extensions supportees (pas RFC)
# Commandes :
301 RPL_AWAY # L'utilisateur est absent
311 RPL_WHOISUSER # Resultat WHOIS
332 RPL_TOPIC # Sujet du canal
353 RPL_NAMREPLY # Liste des nicks d'un canal
366 RPL_ENDOFNAMES # Fin de la liste
372 RPL_MOTD # Ligne du MOTD
375 RPL_MOTDSTART # Debut du MOTD
376 RPL_ENDOFMOTD # Fin du MOTD
# Erreurs :
401 ERR_NOSUCHNICK # Nick/canal inexistant
403 ERR_NOSUCHCHANNEL # Canal inexistant
404 ERR_CANNOTSENDTOCHAN # Pas le droit de parler
421 ERR_UNKNOWNCOMMAND # Commande inconnue
432 ERR_ERRONEUSNICKNAME # Nick invalide
433 ERR_NICKNAMEINUSE # Nick deja pris
442 ERR_NOTONCHANNEL # Pas dans le canal
461 ERR_NEEDMOREPARAMS # Parametres manquants
473 ERR_INVITEONLYCHAN # Canal sur invitation
474 ERR_BANNEDFROMCHAN # Banni du canal
475 ERR_BADCHANNELKEY # Mauvais mot de passe
# 433 (nick deja pris) est le code que tout client
# IRC doit gerer. Si votre nick est pris, le serveur
# envoie 433 et vous devez essayer un autre nick.Limites et evolutions
Les principales limites de la RFC 1459, et comment elles sont adressees aujourd'hui :
- 512 octets par message : Insuffisant pour le contenu moderne. IRCv3 propose
message-tagsqui ajoute des metadonnees sans compter dans la limite, et certains reseaux augmentent la limite. - Pas de timestamps : La RFC ne prevoit pas de timestamp sur les messages. IRCv3 ajoute
server-timequi permet au serveur d'ajouter un timestamp a chaque message. - Pas d'historique : IRC est ephemere par design. IRCv3 propose
chathistorypour recuperer les messages rates pendant une deconnexion. - Pas d'authentification : La RFC prevoit un password serveur (commande PASS) mais pas d'authentification utilisateur. SASL (IRCv3) comble ce manque.
- Collision de nicks : La RFC ne definit pas clairement comment resoudre les conflits de nick entre serveurs links. Les implementations modernes utilisent le timestamp (TS) pour determiner qui garde le nick.
- Pas d'Unicode : La RFC parle d'octets, pas d'encodage. En pratique, les reseaux modernes utilisent UTF-8, mais il n'y a pas de negociation d'encodage dans le protocole.
# Extensions IRCv3 qui corrigent les limites :
# server-time : timestamps sur les messages
@time=2024-01-25T14:30:00.000Z :nick!user@host PRIVMSG #canal :Message
# message-tags : metadonnees extensibles
@msgid=abc123;+reply=def456 :nick PRIVMSG #canal :Reponse
# SASL : authentification securisee
CAP REQ :sasl
# chathistory : historique des messages
CHATHISTORY LATEST #canal * 50
# La RFC 1459 n'est pas obsolete.
# Elle definit le coeur du protocole qui fonctionne
# toujours. Les extensions IRCv3 s'ajoutent par-dessus
# sans casser la compatibilite.Questions frequentes
Dois-je lire la RFC 1459 pour administrer un serveur IRC ?
Non. La documentation de votre IRCd (UnrealIRCd, InspIRCd) est beaucoup plus pertinente. Mais si vous developpez un client, un bot, ou un service IRC, la RFC est une lecture essentielle pour comprendre le protocole a sa base.
La RFC 1459 est-elle toujours la reference ?
Partiellement. Le format de base des messages, les commandes fondamentales, et la topologie reseau sont toujours conformes a la RFC. Mais les details (modes, numeriques, comportements specifiques) varient entre IRCds. Le document "Modern IRC" sur ircdocs.horse est une meilleure reference pour le protocole tel qu'il est implemente en 2025.
Pourquoi la RFC n'a-t-elle jamais ete mise a jour ?
La RFC 2812 etait censee la remplacer, mais elle n'a pas ete largement adoptee. Le probleme fondamental : les IRCds ont diverge avant qu'un standard ne soit etabli. Aujourd'hui, IRCv3 tente de standardiser par consensus entre les implementations, plutot que par RFC — une approche plus pragmatique.