RFC 1459 explicado linea por linea

Lei el RFC 1459 completo por primera vez en 2001, en una impresion de 65 paginas que hice en el laboratorio de la universidad. Lo lei con un rotulador amarillo en la mano, subrayando cada seccion que no entendia. Termine con el documento entero amarillo. Lo relei cuatro veces mas a lo largo de los anos. Cada vez entendi algo nuevo. Es un documento deceptivamente simple: parece corto, parece claro, y sin embargo las decisiones de diseno que contiene definieron treinta anos de comunicacion en Internet.

Contexto historico: 1993

El RFC 1459 fue publicado en mayo de 1993 por Jarkko Oikarinen (el creador de IRC) y Darren Reed. Pero el protocolo que describe existia desde 1988 — el RFC solo lo formalizo. IRC ya llevaba cinco anos funcionando y evolucionando cuando alguien finalmente se sento a documentar como funcionaba.

Esto es importante porque explica muchas de las peculiaridades del protocolo. IRC no fue disenado sobre papel y luego implementado. Fue implementado primero, usado extensivamente, modificado ad-hoc, y documentado despues. Las inconsistencias del RFC reflejan las decisiones pragmaticas que Oikarinen tomo durante el desarrollo: lo que funcionaba se quedaba, lo que no se cambiaba sobre la marcha.

En 1993, la World Wide Web tenia dos anos. Mosaic, el primer navegador grafico popular, se lanzo ese mismo ano. La mayoria del trafico de Internet era email, Usenet, FTP, y IRC. IRC era el unico sistema de comunicacion en tiempo real a escala — no habia nada comparable.

El formato de un mensaje IRC

Todo mensaje IRC sigue el mismo formato. Una linea de texto terminada en \r\n (CRLF), con un maximo de 512 bytes incluyendo el CRLF. Este limite de 512 bytes es una de las decisiones mas influyentes del RFC — y una de las mas problematicas.

# Formato general (RFC 1459, seccion 2.3.1):
[:prefix] command [params] [:trailing]

# Ejemplos reales:
:nick!user@host PRIVMSG #canal :Hola a todos
:servidor 001 nick :Welcome to the IRC Network
PING :servidor.irc.com
PONG :servidor.irc.com
:nick!user@host JOIN #canal
:nick!user@host PART #canal :Hasta luego
:nick!user@host QUIT :Connection closed
:nick!user@host MODE #canal +o otronick

# Desglose:
# :prefix    → Origen del mensaje (nick!user@host o servidor)
# command    → Comando IRC (PRIVMSG, JOIN, MODE...)
# params     → Parametros separados por espacios
# :trailing  → Ultimo parametro (puede contener espacios)

El prefijo con dos puntos (:) indica el origen. Si el mensaje viene de un servidor, el prefix es el nombre del servidor. Si viene de un usuario, es nick!user@host. Los clientes no envian prefix — el servidor lo anade. Si un cliente envia un prefix, el servidor lo ignora o lo reemplaza.

El trailing parameter (ultimo parametro con :) es la unica parte del mensaje que puede contener espacios. Por eso los mensajes de texto siempre van al final: PRIVMSG #canal :este texto tiene espacios. Sin los dos puntos, el parser cortaria en el primer espacio.

El limite de 512 bytes incluye el prefijo, el comando, los parametros, y el CRLF. Para un PRIVMSG tipico, despues de restar el prefijo (que puede ser largo: :nick_largo!usuario@host.muy.largo.del.isp.com), el espacio real para texto ronda los 400 caracteres. Este limite fue razonable en 1988 cuando los mensajes eran cortos. Hoy, con UTF-8 donde un emoji ocupa 4 bytes, es restrictivo. IRCv3 propone message-tags como extension, pero el limite base persiste.

Secuencia de conexion

Conectarse a un servidor IRC requiere exactamente dos comandos: NICK y USER. El servidor responde con un burst de mensajes numericos.

# Secuencia de conexion (cliente -> servidor):
NICK marco
USER marco 0 * :Marco Pellegrini

# Respuesta del servidor (simplificada):
:irc.server.com 001 marco :Welcome to the IRC Network marco!marco@tu.host
:irc.server.com 002 marco :Your host is irc.server.com, running version X
:irc.server.com 003 marco :This server was created Mon Jan 15 2025
:irc.server.com 004 marco irc.server.com ircd-version usermodes chanmodes
:irc.server.com 005 marco CHANTYPES=#& PREFIX=(ov)@+ ... :are supported
:irc.server.com 251 marco :There are 150 users and 30 services on 3 servers
:irc.server.com 252 marco 5 :operator(s) online
:irc.server.com 254 marco 80 :channels formed
:irc.server.com 255 marco :I have 50 clients and 2 servers
:irc.server.com 375 marco :- irc.server.com Message of the Day -
:irc.server.com 372 marco :- Bienvenido a nuestra red IRC
:irc.server.com 376 marco :End of /MOTD command

# El numeric 001 (RPL_WELCOME) indica conexion exitosa
# El numeric 005 (RPL_ISUPPORT) lista las extensiones del servidor
# 375-376 es el MOTD (Message of the Day)

El numeric 005 (RPL_ISUPPORT) no esta en el RFC 1459 original — fue anadido despues. Pero es esencial en la practica porque lista que extensiones soporta el servidor: tipos de canales, modos disponibles, limites de longitud, soporte de UTF-8. Un cliente moderno parsea el 005 para adaptarse a las capacidades del servidor.

Si el nick solicitado ya esta en uso, el servidor responde con 433 ERR_NICKNAMEINUSE en vez de 001. El cliente debe intentar con otro nick o abortar. Esta logica de "primer nick disponible" es la razon por la que NickServ existe — sin un servicio de registro, los nicks son efimeros.

Los comandos fundamentales

El RFC 1459 define 30+ comandos. Los fundamentales para el uso diario:

# === Mensajes ===
PRIVMSG #canal :texto          → Mensaje a un canal
PRIVMSG nick :texto            → Mensaje privado
NOTICE nick :texto             → Aviso (no genera auto-reply)

# === Canales ===
JOIN #canal                    → Entrar a un canal
JOIN #canal clave              → Entrar con clave
PART #canal :razon             → Salir de un canal
TOPIC #canal :nuevo topic      → Cambiar el topic
NAMES #canal                   → Listar usuarios del canal
LIST                           → Listar todos los canales

# === Modos ===
MODE #canal +o nick            → Dar op a nick
MODE #canal +v nick            → Dar voice a nick
MODE #canal +b *!*@host        → Banear un patron
MODE nick +i                   → Modo invisible (usuario)

# === Administracion ===
KICK #canal nick :razon        → Expulsar a nick
INVITE nick #canal             → Invitar a nick
WHOIS nick                     → Informacion sobre nick
WHO #canal                     → Lista detallada del canal

# === Conexion ===
PING :token                    → Keepalive (servidor -> cliente)
PONG :token                    → Respuesta a PING
QUIT :razon                    → Desconectarse

La diferencia entre PRIVMSG y NOTICE es sutil pero importante en la practica. El RFC dice que NOTICE no debe generar respuesta automatica. Esto evita loops infinitos entre bots: si un bot A envia un PRIVMSG a un bot B, y B responde con un PRIVMSG, y A responde a ese, tienes un loop. Si B responde con NOTICE, A (si sigue el RFC) no responde, y el loop se rompe.

La realidad es que muchos clientes y bots ignoran esta regla. Pero los bien escritos la respetan. Si escribes un bot, responde siempre con NOTICE a menos que haya una razon especifica para usar PRIVMSG.

Modos de usuario y canal

Los modos son flags que modifican el comportamiento de un usuario o un canal. Se aplican con el comando MODE.

# Modos de usuario (RFC 1459):
+i  invisible  → No apareces en WHO/NAMES para gente fuera de tus canales
+s  server     → Recibes avisos del servidor (WALLOPS)
+w  wallops    → Recibes WALLOPS de opers
+o  operator   → Eres operador de red (via /OPER)

# Modos de canal (RFC 1459):
+o nick  → Operador de canal (@)
+v nick  → Voice (+) puede hablar en canales +m
+t       → Solo ops pueden cambiar el topic
+n       → No se permiten mensajes externos (PRIVMSG al canal desde fuera)
+m       → Moderado: solo ops y voice pueden hablar
+i       → Invitacion requerida para entrar
+k clave → Canal con clave
+l N     → Limite de usuarios
+b mask  → Ban
+s       → Secreto: no aparece en LIST
+p       → Privado: similar a secreto

# Combinaciones comunes:
MODE #canal +nt              → Topic protegido, no mensajes externos
MODE #canal +mk clave        → Moderado con clave
MODE #canal +l 50            → Limite de 50 usuarios
MODE #canal +b *!*@*.proxy   → Banear todos los proxies de un patron
MODE #canal -b *!*@host      → Quitar ban

Los modos del RFC 1459 son los basicos. Cada IRCd ha anadido modos propios: +R (solo registrados), +S (solo SSL/TLS), +C (no colores), +f (anti-flood). Estos modos extras no estan en ningun RFC — son extensiones propietarias de cada implementacion. El numeric 005 lista que modos soporta el servidor.

Codigos de respuesta numerica

Los codigos numericos de 3 digitos son la forma en que el servidor comunica resultados al cliente. El RFC 1459 define decenas. Los mas comunes:

# Respuestas informativas (001-099):
001  RPL_WELCOME          → Conexion exitosa
002  RPL_YOURHOST         → Info del servidor
003  RPL_CREATED          → Fecha de creacion
004  RPL_MYINFO           → Modos soportados
005  RPL_ISUPPORT         → Extensiones (no original RFC)

# Respuestas a comandos (200-399):
301  RPL_AWAY             → El usuario esta away
311  RPL_WHOISUSER        → Respuesta a WHOIS
332  RPL_TOPIC            → Topic del canal
353  RPL_NAMREPLY         → Lista de nicks en un canal
366  RPL_ENDOFNAMES       → Fin de la lista de nicks
372  RPL_MOTD             → Linea del MOTD
375  RPL_MOTDSTART        → Inicio del MOTD
376  RPL_ENDOFMOTD        → Fin del MOTD

# Errores (400-599):
401  ERR_NOSUCHNICK       → Nick no encontrado
403  ERR_NOSUCHCHANNEL    → Canal no existe
404  ERR_CANNOTSENDTOCHAN → No puedes enviar al canal
421  ERR_UNKNOWNCOMMAND   → Comando no reconocido
432  ERR_ERRONEUSNICKNAME → Nick invalido
433  ERR_NICKNAMEINUSE    → Nick en uso
461  ERR_NEEDMOREPARAMS   → Faltan parametros
473  ERR_INVITEONLYCHAN   → Canal solo por invitacion
474  ERR_BANNEDFROMCHAN   → Estas baneado
475  ERR_BADCHANNELKEY    → Clave incorrecta
482  ERR_CHANOPRIVSNEEDED → No eres op

Los codigos numericos son la razon por la que los clientes IRC saben como reaccionar a eventos del servidor. Cuando un cliente intenta unirse a un canal y recibe un 474, sabe que esta baneado. Cuando recibe un 473, sabe que necesita invitacion. El cliente muestra el mensaje apropiado al usuario sin tener que parsear texto libre.

Topologia de red

El RFC 1459 describe IRC como una red de servidores en forma de spanning tree. Cada servidor se conecta a uno o mas servidores, pero no puede haber ciclos. El resultado es un arbol donde los mensajes fluyen por una sola ruta entre cualquier par de nodos.

#           hub-central
#          /     |     \\
#    leaf-1   leaf-2   leaf-3
#                |       \\
#           leaf-2a    leaf-3a

# Cada servidor conoce:
# - Sus usuarios locales directamente
# - Los usuarios remotos via mensajes de los servidores vecinos

# Un PRIVMSG de leaf-1 a un usuario en leaf-3a:
# leaf-1 -> hub-central -> leaf-3 -> leaf-3a
# 3 hops

Esta topologia tiene una implicacion directa: si un enlace se rompe, la red se divide. Los usuarios de un lado del corte no ven a los del otro. Esto es el famoso netsplit. El RFC lo reconoce como una limitacion inherente del diseno, sin proponer solucion — porque no la hay dentro del modelo de spanning tree.

Cuando el enlace se restaura, ambos lados deben reconciliar su estado. Usuarios que cambiaron de nick, canales que se crearon, modos que se modificaron — todo debe sincronizarse. Este proceso de netjoin es complejo y es donde mas bugs historicos han ocurrido en los IRCds.

Lo que el RFC no contemplo

El RFC 1459 no menciona:

• Registro de nicks: No existe el concepto de propiedad de un nick. NickServ fue inventado despues, fuera del protocolo.
• Registro de canales: Mismo problema. ChanServ fue una solucion ad-hoc.
• Cifrado: No hay mencion de SSL/TLS. El protocolo es texto plano. El soporte de TLS fue anadido decadas despues.
• Unicode: El RFC asume caracteres de 8 bits. No hay especificacion de encoding. Por eso IRC tiene problemas historicos con caracteres no-ASCII.
• Mensajes offline: Si no estas conectado, los mensajes se pierden. MemoServ fue un parche.
• Autenticacion fuerte: PASS es la unica autenticacion del RFC, y es en texto plano. SASL vino mucho despues via IRCv3.
• Historial de mensajes: IRC no tiene memoria. Lo que no viste en tiempo real, no existe. Los bouncers y el chathistory de IRCv3 intentan resolver esto.

Cada una de estas ausencias genero una solucion externa: servicios (NickServ, ChanServ), bouncers (ZNC), extensiones de protocolo (IRCv3), y convenciones no documentadas. IRC en 2025 es el RFC 1459 mas treinta anos de parches. Funciona. Pero la complejidad accidental es enorme.

El RFC 2812, publicado en 2000, intento actualizar el RFC 1459 con correcciones y clarificaciones. Pero su adopcion fue parcial — cada IRCd implemento lo que le convenia. Hoy, el trabajo real de estandarizacion ocurre en el IRCv3 Working Group, que define extensiones de forma incremental sin reescribir el protocolo base.