IRC - Internet Relay Chat - (Pag.: 1 - 15)

**Dark[Byte]** Miér Mayo 26, 2010 2:52 am

Network Working Group J. Oikarinen
RFC: 1459 D. Reed
Mayo 1993
Traducción al castellano: Octubre 1999
Carlos García Argos (cgasoft@yahoo.com)

Protocolo de Charla Basado en Internet (Internet Relay Chat, IRC)

Prefacio

Este documento especifica un protocolo experimental para la
comunidad de Internet. Se piden comentarios y sugerencias para
mejoras. Se ruega referirse a la edición actual de los "Estándares
de Protocolo Oficiales del IAB" para el estado actual de la
estandarización y el protocolo. La distribución de este documento
es ilimitada.

Resumen

El Protocolo IRC se desarrolló durante los 4 últimos años desde que
se implementó por primera vez como un medio de comunicación
instantánea entre usuarios de BBS. Actualmente soporta una red
global de servidores y clientes, y se está extendiendo para
contrarrestar el crecimiento. Durante los 2 últimos años, la media
de usuarios conectados a la red de IRC se ha multiplicado por 10.

El protocolo IRC está basado en texto, siendo el cliente más simple
un programa capaz de conectarse a un servidor a través de un socket.

Índice

1. INTRODUCCIÓN ............................................... 4
1.1 Servidores.............................................. 4
1.2 Clientes ............................................... 5
1.2.1 Operadores ......................................... 5
1.3 Canales ................................................. 5
1.3.1 Operadores de canal .................................. 6
2. LA ESPECIFICACIÓN DEL IRC ................................... 7
2.1 Discusión ............................................... 7
2.2 Códigos de caracteres ................................... 7
2.3 Mensajes ................................................ 7
2.3.1 Formato de mensajes en pseudo BNF ................. 8
2.4 Respuestas numéricas..................................... 10
3. Conceptos sobre IRC ......................................... 10
3.1 Comunicación uno-a-uno .................................. 10
3.2 Uno-a-muchos ............................................ 11
3.2.1 A una lista ........................................ 11
3.2.2 A un grupo (canal) ................................. 11
3.2.3 A una máscara de host o servidor ................... 12
3.3 Uno a todos ............................................. 12

Oikarinen & Reed [Pág. 1]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

3.3.1 Cliente a cliente .................................. 12
3.3.2 Clientes a servidor ................................ 12
3.3.3 Servidor a servidor ................................ 12
4. DETALLES DE MENSAJES......................................... 13
4.1 Registro de conexión .................................... 13
4.1.1 Mensaje de clave ................................... 14
4.1.2 Mensaje de nick .................................... 14
4.1.3 Mensaje de usuario ................................. 15
4.1.4 Mensaje de servidor ................................ 16
4.1.5 Mensaje de Operador ................................ 17
4.1.6 Mensaje de salida .................................. 17
4.1.7 Mensaje de salida del servidor ..................... 18
4.2 Operaciones en un canal ................................. 19
4.2.1 Mensaje de entrada al canal (JOIN) ................. 19
4.2.2 Mensaje de salida del canal (PART) ................. 20
4.2.3 Mensaje de modos ................................... 21
4.2.3.1 Modos de canal ................................ 21
4.2.3.2 Modos de usuario .............................. 22
4.2.4 Mensaje de tópico .................................. 23
4.2.5 Mensaje de nombres ................................. 24
4.2.6 Mensaje de lista de canales ........................ 24
4.2.7 Mensaje de invitación a un canal ................... 25
4.2.8 Mensaje de expulsión temporal ...................... 25
4.3 Peticiones y comandos del servidor ...................... 26
4.3.1 Mensaje de versión ................................. 26
4.3.2 Mensaje de estadísticas ............................ 27
4.3.3 Mensaje de enlaces de servidores ................... 28
4.3.4 Mensaje de hora local del servidor ................. 29
4.3.5 Mensaje de conexión servidor-servidor .............. 29
4.3.6 Mensaje de trazado de ruta ......................... 30
4.3.7 Mensaje de nombre del administrador del servidor ... 31
4.3.8 Mensaje de información sobre el servidor ........... 31
4.4 Enviando mensajes ....................................... 32
4.4.1 Mensajes privados .................................. 32
4.4.2 Mensajes de aviso .................................. 33
4.5 Peticiones de usuario ................................... 33
4.5.1 Petición de "WHO" .................................. 33
4.5.2 Petición de "WHOIS" ................................ 34
4.5.3 Petición de "WHOWAS" ............................... 35
4.6 Otros mensajes .......................................... 35
4.6.1 Mensaje de "KILL" .................................. 35
4.6.2 Mensaje de "PING" .................................. 36
4.6.3 Mensaje de "PONG" .................................. 37
4.6.4 Mensajes de error .................................. 38
5. MENSAJES OPCIONALES ......................................... 38
5.1 Mensaje de ausencia (AWAY) .............................. 38
5.2 Comando de reconfiguración del servidor ................. 39
5.3 Comando de reinicio del servidor ........................ 39

Oikarinen & Reed [Pág. 2]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

5.4 Mensaje de invocación (SUMMON) .......................... 40
5.5 Mensaje de lista de usuarios ............................ 40
5.6 Comando de mensaje a los Operadores ..................... 41
5.7 Comando USERHOST ........................................ 41
5.8 Comando ISON ............................................ 41
6. RESPUESTAS .................................................. 42
6.1 Respuestas de error ..................................... 42
6.2 Respuestas a comandos ................................... 47
6.3 Respuestas reservadas ................................... 54
7. AUTENTICACIÓN DE CLIENTE Y SERVIDOR ......................... 54
8. DETALLES DE IMPLEMENTACIÓN .................................. 54
8.1 Protocolo de red: TCP ................................... 56
8.1.1 Soporte de sockets UNIX ............................ 56
8.2 Análisis de comandos .................................... 56
8.3 Envío de mensajes ....................................... 56
8.4 Vida de una conexión .................................... 57
8.5 Estableciendo una conexión cliente-servidor ............. 57
8.6 Estableciendo una conexión servidor-servidor ............ 57
8.6.1 Intercambio de información de estado al conectar ... 58
8.7 Finalización de conexiones cliente-servidor ............. 58
8.8 Finalización de conexiones servidor-servidor ............ 58
8.9 Seguimiento de cambios de nick .......................... 59
8.10 Control de flood de clientes ........................... 59
8.11 Búsquedas sin bloqueos ................................. 60
8.11.1 Resolución de nombre de host (DNS) ................ 60
8.11.2 Búsqueda de nombre de usuario (Ident) ............. 60
8.12 Archivo de configuración ............................... 60
8.12.1 Permitir la conexión de clientes .................. 61
8.12.2 Operadores ........................................ 61
8.12.3 Perimitir la conexión de servidores ............... 61
8.12.4 Administración .................................... 62
8.13 Miembros de canales .................................... 62
9. PROBLEMAS ACTUALES .......................................... 62
9.1 Escalabilidad ........................................... 62
9.2 Etiquetas ............................................... 62
9.2.1 Nicks .............................................. 62
9.2.2 Canales ............................................ 63
9.2.3 Servidores ......................................... 63
9.3 Algoritmos .............................................. 63
10. SOPORTE Y DISPONIBILIDAD ................................... 63
11. ASUNTOS DE SEGURIDAD ....................................... 63
12. DIRECCIONES DE LOS AUTORES ................................. 64

Oikarinen & Reed [Pág. 3]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

1. INTRODUCCIÓN

El protocolo IRC (Internet Relay Chat) se ha diseñado durante unos
años para usarse como conferencia basada en texto. Este documento
describe el protocolo IRC actual.

El protocolo IRC se ha desarrollado en sistemas que usan el
protocolo de red TCP/IP, aunque no es imperativo que esta sea la
única forma en que funcione.

El IRC es en sí mismo un sistema de teleconferencia que (a través
del modelo cliente-servidor) es adecuado para funcionar en muchas
máquinas en una forma distribuida. Una configuración típìca incluye
un único proceso (el servidor) que conforma un punto central para
que los clientes (u otros servidores) se conecten a él, realizando
los envíos y multiplexado de mensajes requeridos, así como otras
funciones.

1.1 Servidores

El servidor forma la espina dorsal del IRC, proporcionando un punto
al que los clientes pueden conectar para hablar unos con otros, y un
punto para que otros servidores se conecten a él, formando una red
IRC. La única configuración de red permitida para los servidores de
IRC es una con forma de árbol extendido [ver figura 1], donde cada
servidor hace de nodo central para el resto de la red que dicho
servidor "ve".

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

:
[ etc. ]
:

[ Figura. 1. Formato de una red de servidores de IRC ]

Oikarinen & Reed [Pág. 4]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

1.2 Clientes

Un cliente es cualquier cosa que se conecta a un servidor que no sea
otro servidor. Cada cliente se distingue de otros clientes por un
único nick de 9 caracteres de longitud máxima. Ver las reglas de
gramática de protocolo para ver lo que se puede y lo que no se puede
usar en un nick. Además del nick, todos los servidores deben tener
la siguiente información sobre todos los clientes: nombre real del
host desde el que conecta el cliente, el nombre de usuario del
cliente en ese host, y el servidor al que está conectado el cliente.

1.2.1 Operadores

Para mantener un cierto orden en la red de IRC, existe una clase de
clientes especial (Operadores) que realizan funciones generales de
mantenimiento en la red. Aunque los "poderes" concedidos a un
un Operador pueden considerarse "peligrosos", son necesarios. Los
Operadores deben ser capaces de realizar tareas básicas de red como
desconectar y reconectar servidores para prevenir un uso prolongado
de mal rutado de red. Como reconocimiento de esta necesidad, el
protocolo explicado aquí sólo permite a los Operadores realizar
dichas funciones. Ver secciones 4.1.7 (SQUIT) y 4.3.5 (CONNECT).

Un poder con mayor controversia es la posibilidad de que un Operador
elimine un usuario de la red por la "fuerza". Por ejemplo, los
Operadores son capaces de cerrar la conexión entre cualquier cliente
y servidor. La justificación de esto es delicada ya que su abuso es
a la vez destructivo y molesto. Para más detalles sobre esta acción
ver sección 4.6.1 (KILL).

1.3 Canales

Un canal es un grupo (con nombre) de uno o más clientes que reciben
mensajes dirigidos a ese canal. El canal se crea implícitamente al
unirse el primer cliente, y deja de existir cuando el último cliente
lo deja. Mientras el canal exista, cualquier cliente puede dirigirse
al canal usando el nombre de dicho canal.

Los nombres de canales son cadenas (que empiezan con '&' o '#') de
hasta 200 caracteres. Aparte del requisito de que el primer carácter
sea un '&' o un '#', la única restricción es que no puede contener
espacios en blanco (' '), control G (^G o ASCII 7), o una coma (',',
que se usa como separador de listas de parámetros).

Hay dos tipos de canales permitidos por el protocolo. Uno es un
canal distribuido que es conocido por todos los servidores de la
red. Estos canales se marcan con el primer carácter '#'. Otro tipo
de canales se caracteriza por ser sólo para clientes conectados al

Oikarinen & Reed [Pág. 5]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

servidor en el que se encuentra el canal. Se distinguen porque su
primer carácter es '&'. Por encima de estos tipos, hay modos de
canal que varían las características de los canales. Para más
detalles, ver la sección 4.2.3 (comando MODE).

Para crear un nuevo canal o formar parte de uno existente, un
usuario debe UNIRSE (JOIN) al canal. Si el canal no existe antes de
unirse, se crea y el creador del canal pasa a ser operador de canal.
Si el canal existe, la petición de unirse a él será aceptada o no en
función de los modos actuales del canal. Por ejemplo, si el canal es
sólo para invitados (+i), sólo podrá unirse si es invitado. Como
parte del protocolo, un usuario puede formar parte de varios canales
simultáneamente, pero se recomienda un límite de 10 canales como
suficiente para usuarios experimentados y novatos. Ver la sección
8.13 para más información.

Si la red de IRC se separa a causa de una ruptura de conexión entre
dos servidores, el canal en cada lado está compuesto por los
clientes que están conectados a los servidores a cada lado de la
ruptura. Cuando se rehace la conexión, los servidores que reconectan
anuncian al otro quién cree que está en cada canal y los modos de
dicho canal. Si el canal existe en ambas partes, las uniones (JOINs)
y modos (MODEs) se interpretan de forma inclusiva de forma que ambos
lados de la nueva conexión coincidan en los clientes que forman el
canal y los modos del mismo.

1.3.1 Operadores de canal

El operador de canal (también llamado "chop" o "chanop") se le
considera el "dueño" de dicho canal. Como reconocimiento a ese
estatus, los operadores de canal poseen ciertos "poderes" que les
permiten mantener el control y cierto orden en su canal. Como dueño
del canal, el operador de canal no tiene que dar justificaciones por
sus actos, aunque si sus acciones son antisociales o abusivas, puede
ser razonable pedirle a un Operador de IRC que intervenga, o por el
bien de los usuarios, irse y crear su propio canal.

Los comandos que sólo pueden usar los operadores de canal son:

KICK - Expulsar a un cliente del canal, de forma que puede
volver a entrar
MODE - Cambiar los modos del canal
INVITE - Invitar a un usuario a un canal
TOPIC - Cambiar el topic en un canal con modo +t

Un operador de canal se identifica por el símbolo '@' (arroba) que
precede a su nick, cuando se le asocia con un canal (respuestas a
los comandos NAMES, WHO y WHOIS).

Oikarinen & Reed [Pág. 6]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

2. LA ESPECIFICACIÓN DEL IRC

2.1 Discusión

El protocolo tal y como se describe aquí se usa tanto para
conexiones servidor-servidor como cliente-servidor. Hay, sin
embargo, más restricciones en las conexiones cliente (que se
consideran poco fiables) que en las conexiones de servidores.

2.2 Códigos de caracteres

No hay un conjunto de caracteres especificado. El protocolo está
basado en un conjunto de caracteres compuesto de 8 bits, formando un
octeto. Cada mensaje puede estar compuesto de cualquier número de
estos octetos; sin embargo, algunos valores de estos octetos se usan
para formar códigos de control que actúan como delimitadores de
mensajes.

A pesar de ser un protocolo de 8 bits, los delimitadores y palabras
clave son tales que el protocolo se puede usar desde un terminal
USASCII y una conexión telnet.

Debido al origen escandinavo del IRC, los caracteres {, } y | se
consideran las "minúsculas" de los caracteres [, ] y \,
respectivamente. Esto es crítico a la hora de determinar la
equivalencia de dos nicks.

2.3 Mensajes

Servidores y clientes se envían mensajes unos a otros que pueden
generar o no una respuesta. Si el mensaje contiene un comando válido
de una de las formas descritas en secciones posteriores, el cliente
debería esperar una respuesta como se especifica, pero no tiene
porqué esperar para siempre a esa respuesta; la comunicación
cliente-servidor y servidor-servidor es esencialmente asíncrona.

Cada mensaje de IRC puede consistir en 3 partes principales: el
prefijo (opcional), el comando y los parámetros del comando (hasta
un total de 15). El prefijo, comando y parámetros deben estar
separados entre sí por uno (o más) caracteres ASCII espacio en
blanco (0x20).

La presencia de un prefijo se indica con el carácter dos puntos
(':', 0x3b), que debe ser el primer carácter del propio mensaje. No
debe haber espacio en blanco entre los dos puntos y el mensaje. El
prefijo lo usan los servidores para indicar el verdadero origen del
mensaje. Si el prefijo no aparece en el mensaje, se supone que

Oikarinen & Reed [Pág. 7]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

proviene de la conexión desde la cual se recibió. Los clientes no
deberían usar prefijos al enviar mensajes; si usan un prefijo, el
único válido es el nick registrado asociado con el cliente. Si la
fuente identificada por el prefijo no se encuentra en la base de
datos interna del servidor o si la fuente está registrada desde un
enlace diferente a aquel desde el cual llegó el mensaje, el servidor
debe ignorar el mensaje de forma silenciosa.

El comando debe ser bien un comando de IRC válido o un número de 3
dígitos representado en texto ASCII.

Los mensajes de IRC siempre son líneas de caracteres acabadas en un
par CR-LF (Carriage Return-Line Feed = Retorno de Carro-Salto de
Línea), y los mensajes no deben exceder los 512 caracteres de
longitud, incluido el par CR-LF. Por tanto, hay un máximo de 510
caracteres permitidos para el comando y sus parámetros. No hay
provisiones para líneas de continuación de mensajes. Para más
detalles sobre la implementación ver la sección 7.

2.3.1 Formato de mensajes en 'pseudo' BNF

Los mensajes de protocolo deben extraerse de la cadena contigua de
octetos. La solución es asignar dos caracteres, CR y LF como
separadores de mensajes. Los mensajes vacíos se ignoran de forma
silenciosa, lo que permite el uso de la secuencia CR-LF entre
mensajes sin problemas.

El mensaje extraído se divide en las componentes <prefijo>,
<comando> y lista de parámetros formada por componentes <parámetro
intermedio> o <parámetro final>

La representación BNF para esto es:

<mensaje> ::= [':' <prefijo> <ESPACIO> ] <comando> <parámetro> <crlf>
<prefijo> ::= <nombre de servidor> | <nick> [ '!' <usuario> ] [ '@' <host> ]
<comando> ::= <letra> { <letra> } | <número> <número> <número>
<ESPACIO> ::= ' ' { ' ' }
<parámetro> ::= <ESPACIO> [ ':' <parámetro final> |
<parámetro intermedio> <parámetro> ]

<parámetro intermedio> ::= <Cualquier secuencia de octetos *no vacía*
que no incluya ESPACIO, NUL, CR o LF, el
primero del cual no puede ser ':'>
<parámetro final> ::= <Cualquier secuencia, posiblemente *vacía* que no
incluya NUL, CR o LF>

<crlf> ::= CR LF

Oikarinen & Reed [Pág. 8]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

NOTAS:

1) <ESPACIO> consiste únicamente de caracteres espacio (0x20).
Nótese especialmente que la TABULACIÓN y otros caracteres de
control no se consideran espacios en blanco.

2) Después de extraer la lista de parámetros, todos son iguales,
ya sean <parámetro intermedio> o <parámetro final>. Este último
es simplemente un truco sintáctico para permitir ESPACIO en un
parámetro.

3) La razón por la cual CR y LF no pueden aparecer en parámetros
es un artefacto de la estructura del mensaje. Esto podría
cambiar más adelante.

4) El carácter NUL no es especial en la estructuración del mensaje
y básicamente podría acabar en un parámetro, pero esto
causaría complejidades adicionales en el manejo normal de
cadenas de C. Por tanto, NUL no se permite en los mensajes.

5) El último parámetro debe ser una cadena vacía.

6) El uso del prefijo extendido (['!' <usuario> ] ['@' <host> ])
no debe usarse en comunicaciones servidor-servidor y sólo está
orientado a mensajes servidor-cliente para proporcionar a los
clientes información más útil sobre de quién proviene un
mensaje sin realizar peticiones adicionales.

La mayoría de los protocolos de mensajes especifican una semántica y
sintaxis adicionales para los parámetros, dictados por su posición
en la lista de parámetros. Por ejemplo, muchos comandos de
servidores supondrán que el primer parámetro después del comando es
la lista de objetivos, que puede describirse como:

<objetivo> ::= <a> [ "," <objetivo> ]
<a> ::= <canal> | <usuario> '@' <nombre de servidor> |
<nick> | <máscara>
<canal> ::= ('#' | '&') <cadena de caracteres>
<nombre de servidor> ::= <host>
<host> ::= ver RFC 952 [DNS] para detalles sobre nombres de
host válidos
<nick> ::= <letra> { <letra> | <número> | <especial> }
<máscara> ::= ('#' | '$') <cadena de caracteres>
<cadena de caracteres> ::= <cualquier código de 8 bits excepto
ESPACIO, BELL, NUL, CR, LF y coma (',')>

Otras sintaxis de parámetros son:

<usuario> ::= <NO-ESPACIO> { <NO-ESPACIO> }
<letra> ::= 'a' ... 'z' | 'A' ... 'Z'
<número> ::= '0' ... '9'
<especial> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'

Oikarinen & Reed [Pág. 9]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

<NO-ESPACIO> ::= <cualquier código de 8 bits excepto ESPACIO
(0x20), NUL (0x00), CR (0x0d) o LF (0x0a)>

2.4 Respuestas numéricas

La mayoría de los mensajes enviados al servidor generan una
respuesta de alguna clase. La respuesta más común es la numérica,
empleada tanto para repuestas de error como para las normales. La
respuesta numérica debe enviarse como un mensaje compuesto por el
prefijo del que lo envía, el número de 3 dígitos, y el objetivo de
la respuesta. No se permiten respuestas numéricas provenientes de un
cliente; cualquier mensaje de ese tipo recibido por el servidor se
descartan de forma silenciosa. Una respuesta numérica es como un
mensaje normal, salvo que la palabra clave se crea a partir de 3
dígitos numéricos en lugar de una cadena de letras. Hay una lista de
respuestas en la sección 6.

3. Conceptos sobre IRC.

Esta sección está dedicada a describir los conceptos actuales que
están tras la organización del protocolo IRC y cómo las actuales
implementaciones envían diferentes clases de mensajes.

1--\
A D---4
2--/ \ /
B----C
/ \
3 E

Servidores: A, B, C, D, E Clientes: 1, 2, 3, 4

[ Figura 2. Pequeña red IRC de ejemplo ]

3.1 Comunicación uno-a-uno

La comunicación uno-a-uno normalmente sólo la realizan los clientes,
ya que la mayoría del tráfico servidor-servidor no es resultado de
los servidores comunicándose únicamente entre ellos. Para
proporcionar una forma segura de comunicación entre clientes, es
necesario que todos los servidores sean capaces de enviar un mensaje
exactamente en una dirección a través del árbol de expansión para
que llegue a cualquier cliente. El camino de un mensaje es el más
corto entre dos puntos cualesquiera del árbol.

Los siguientes ejemplos se refieren todos a la Figura 2 de arriba.

Oikarinen & Reed [Pág. 10]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Ejemplo 1:
Un mensaje entre los clientes 1 y 2 sólo lo ve el servidor A, que
lo envía directamente al cliente 2.

Ejemplo 2:
Un mensaje entre los clientes 1 y 3 lo ven los servidores A y B.
Ningún otro servidor o cliente puede verlo.

Ejemplo 3:
Un mensaje entre los clientes 2 y 4 lo ven los servidores A, B, C
y D y el cliente 4.

3.2 Uno-a-muchos

El propósito principal del IRC es proporcionar un forum que permita
realizar conferencias de forma sencilla y eficiente. El IRC ofrece
varias maneras de conseguir esto, cada una con su propósito.

3.2.1 A una lista

La forma menos eficiente de comunicación uno-a-muchos se realiza a
través de clientes que se comunican con una "lista" de usuarios. La
forma en que esto se realiza es casi autoexplicatoria: el cliente da
una lista de destinos para un mensaje y el servidor divide la lista
y distribuye una copia separada del mensaje a cada destino. No es
tan eficiente como emplear un grupo ya que la lista de destino es
separada y el mensaje se envía sin asegurarse de que no se mandan
duplicados cada vez.

3.2.2 A un grupo (canal)

En el IRC el canal tiene un papel equivalente al de un foro. Su
existencia es dinámica (llendo y viniendo igual que la gente
entrando y saliendo de los canales), y la conversación se envía
únicamente a los servidores que tienen usuarios en el canal. Si hay
múltiples usuarios en un servidor en el mismo canal, el mensaje sólo
se envía una vez a ese servidor y desde él a cada cliente del canal.
Esto se repite para cada combinación cliente-servidor hasta que el
mensaje original se ha enviado a cada miembro del canal.

Los siguientes ejemplos se refieren a la Figura 2.

Ejemplo 4:
Un canal con un cliente en él. Los mensajes al canal van al
servidor y a ninguna parte más.

Ejemplo 5:
2 clientes en un canal. Todos los mensajes atraviesan un camino
igual que si fuesen mensajes privados entre dos clientes fuera de
un canal.

Oikarinen & Reed [Pág. 11]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Ejemplo 6:
Los clientes 1, 2 y 3 en un canal. Todos los mensajes se envían a
todos los clientes y sólo a los servidores que tienen que
recorrerse si fuese un mensaje privado a un único cliente. Si el
cliente 1 envía un mensaje, va al cliente 2 y, via el servidor B
al cliente 3.

3.2.3 A una máscara de host o servidor

Para proveer a los Operadores de IRC de mecanismos para enviar
mensajes a muchos usuarios relacionados, se proporcionan mensajes a
host y máscara de servidor. Estos mensajes se envían a usuarios cuya
información de host o servidor coincide con la de la máscara. Los
mensajes se envían únicamente a los sitios en los que están esos
usuarios, de forma similar a los canales.

3.3 Uno-a-todos

El tipo de mensaje uno-a-todos se describe como un mensaje de
emisión, enviado a todos los clientes, servidores o ambos. En una
red grande, un solo mensaje puede resultar en mucho tráfico a través
de la red en un intento de hacerlo llegar a todos los destinos.

Para algunos mensajes no hay otra opción que enviarla a todos los
servidores para que la información manejada por cada servidor sea
razonablemente consistente entre servidores.

3.3.1 Cliente-a-cliente

No existe una clase de mensaje que, a partir de un mensaje único,
resulte en que el mensaje se envíe a todos los demás clientes.

3.3.2 Cliente-a-servidor

La mayoría de los comandos que resultan en un cambio en la
información sobre el estado (miembros de canal, modos de canal,
estado de usuario, etc) deben ser enviados a todos los servidores, y
esta distribución no puede ser cambiada por el cliente.

3.3.3 Servidor-a-servidor.

Mientras la mayoría de los mensajes entre servidores se distribuyen
a todos "los demás" servidores, esto sólo es necesario para un
mensaje que afecte bien a un usuario, un canal o un servidor. Dado
que estos son partes necesarias del IRC, casi todos los mensajes
originados de un servidor se envían a todos los demás servidores
conectados.

Oikarinen & Reed [Pág. 12]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

4. DETALLES DE MENSAJES

En las páginas siguientes hay descripciones sobre cada mensaje que
reconocen el servidor y el cliente IRC. Todos los comandos descritos
en esta sección deben implementarse en cualquier servidor que siga
el protocolo.

Cuando se liste la respuesta ERR_NOSUCHSERVER (error, no existe el
servidor), significa que el parámetro <servidor> no se encontró. El
servidor no debe enviar ninguna otra respuesta para ese comando.

El servidor al que se conecta el cliente debe analizar el mensaje
completo, devolviendo los errores oportunos. Si el servidor
encuentra algún error fatal en el análisis de un mensaje, debe
enviarse un mensaje de error y finalizar el análisis. Un error fatal
puede ser un comando incorrecto, un destino que sea desconocido para
el servidor (en esta categoría entran servidores, nicks o canales),
parámetros que falten o privilegios incorrectos.

Si se presenta un conjunto completo de parámetros, cada uno debe
comprobarse que es válido y se enviarán las respuestas apropiadas al
cliente. En caso de mensajes que usan listas de parámetros separados
por comas tienen que enviarse respuestas para cada uno por separado.

En los ejemplos de abajo, algunos mensajes aparecen en formato
completo:

:Nombre COMANDO lista de parámetros

Estos ejemplos representan un mensaje, proveniente de "Nombre",
entre servidores, donde es fundamental incluir el nombre del emisor
original del mensaje para que los servidores remotos puedan enviar
una respuesta a través del camino correcto.

4.1 Registro de conexión

Los comandos descritos aquí se usan para registrar una conexión con
un servidor de IRC tanto si se trata de un usuario como si es otro
servidor, además de las desconexiones.

No se requiere un comando "PASS" (de password) para que se registre
cada conexión de un cliente o servidor, pero debe preceder el
mensaje del servidor o lo último de la combinación NICK/USUARIO. Se
recomienda encarecidamente que las conexiones de servidor tengan una
clave de acceso para dar un grado de seguridad a las conexiones. El
orden recomendado para el registro de un cliente es el siguiente:

1. Mensaje de Password
2. Mensaje de Nick
3. Mensaje de Usuario

Oikarinen & Reed [Pág. 13]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

4.1.1 Mensaje de Password

Comando: PASS
Parámetros: <password>

El comando PASS se usa para establecer una "clave de conexión". La
clave puede y debe establecerse antes de cualquier intento de
realizar la conexión. Esto requiere que los clientes envíen el
comando PASS antes de la combinación NICK/USUARIO, y los servidores
*deben* enviar el comando PASS antes de cualquier comando SERVER. La
clave debe coincidir con una de las líneas C/N (para servidores) o
las I (para clientes). Es posible enviar múltiples comandos PASS
antes del registro pero sólo la última que se envía se verifica y no
puede cambiarse una vez hecho el registro. Respuestas numéricas:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Ejemplo:

PASS clavesecretaaquí

4.1.2 Mensaje de Nick

Comando: NICK
Parámetros: <nick> [ <contadordesalto> ]

El mensaje de NICK se usa para darle al usuario un nick o cambiar el
anterior. El parámetro <contadordesalto> se usa únicamente por los
servidores para indicar cómo de lejos está el nick del servidor. Una
conexión local tiene un contador de salto igual a 0. Si lo envía un
cliente, se ignora.

Si llega un mensaje NICK a un servidor que ya tiene un nick idéntico
para otro cliente, ocurre una colisión de nick. Como resultado de
esto, se eliminan todas las referencias del nick de la base de datos
del servidor, y se ejecuta un comando KILL para eliminar el nick de
las bases de datos de los demás servidores. Si el mensaje NICK que
causó la colisión fue un cambio de nick, el nick original (antiguo)
también debe eliminarse.

Si el servidor recibe un nick idéntifo de un cliente que está
conectado directamente, puede enviar un mensaje ERR_NICKCOLLISION al
cliente local, ignorar el comando NICK y no ejecutar ningún comando
KILL.

Respuestas numéricas:

ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION

Oikarinen & Reed [Pág. 14]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Ejemplo:

NICK Wiz ; Introduciendo nuevo nick "Wiz".

:WiZ NICK Kilroy ; WiZ cambia su nick a Kilroy.

4.1.3 Mensaje de Usuario

Comando: USER
Parámetros: <nombre de usuario> <nombre de host>
<nombre de servidor> <nombre real>

El mensaje USER se usa al principio de cada conexión para indicar
el nombre de usuario, de host y servidor y el nombre real del nuevo
usuario. Se usa también en la comunicación entre servidores para
indicar que un nuevo usuario llega a la red de IRC, ya que sólo
tras recibirse los mensajes USER y NICK del cliente queda registrado
el usuario.

Entre servidores el nick del cliente debe preceder al mensaje de
USER. Nótese que el nombre de host y servidor normalmente se ignoran
por el servidor cuando el comando USER viene desde un cliente
conectado directamente (por razones de seguridad), pero se usan en
comunicaciones servidor a servidor. Esto quiere decir que un nick
debe enviarse siempre a un servidor remoto cuando entra un nuevo
usuario a la red antes de enviarse el mensaje USER.

El parámetro <nombre real> debe ser el último, ya que puede contener
espacios en blanco y debe ir precedido por dos puntos (":") para
asegurarse de que se reconoce como tal.

Dado que es fácil para un cliente mentir sobre el nombre de usuario
apoyado únicamente en el mensaje USER, se recomienda el empleo de un
"Servidor de Identidad". Si el host desde el que conecta un usuario
tiene ese servidor activado, el nombre de usuario es el que
proporciona dicho servidor.

Respuestas numéricas:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Ejemplos:

USER guest tolmoon tolsun :Ronnie Reagan
;El usuario se registra con nombre
de usuario "guest" y nombre real
"Ronnie Reagan".

Oikarinen & Reed [Pág. 15]