|
|
|
|
Protocolo IRC:
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:4] 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]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
:testnick USER guest tolmoon tolsun :Ronnie Reagan
;mensaje entre servidores con el
nick al que pertenece el comando
USER
4.1.4 Mensaje de Servidor
Comando: SERVER
Parámetros: <nombre de servidor> <contador de salto> <información>
El mensaje de servidor se usa para indicar a un servidor que el otro
lado de la conexión es un servidor. También se emplea para enviar
datos sobre servidores a través de toda la red. Cuando se conecta un
nuevo servidor a la red, debe enviarse información sobre él al resto
de la red. El <contador de salto> se usa para dar a los servidores
información interna sobre cómo de lejos están todos los servidores.
Con una lista completa de los servidores, sería posible construir un
mapa completo del árbol de servidores, pero las máscaras de host lo
evitan.
El mensaje SERVER sólo debe aceptarse desde (a) una conexión
pendiente de ser registrada y que se intenta registrar como servidor
o (b) una conexión existente a otro servidor, en cuyo caso el
mensaje SERVER introduce un nuevo servidor tras ese servidor.
La mayoría de los errores que ocurren al recibirse el comando SERVER
acaban en una finalizacion de la conexión por parte del host de
destino (servidor objetivo). Las respuestas de error se envían
normalmente usando el comando "ERROR" en lugar de una respuesta
numérica ya que el comando ERROR tiene propiedades que le hacen
útil en este caso.
Si un mensaje de SERVER se analiza e intenta introducir un servidor
que ya es conocido por el servidor destino, la conexión de la que
vino el mensaje debe cerrarse (siguiendo los procedimientos
adecuados), ya que se forma una ruta doble a un servidor y por tanto
la naturaleza acíclica del árbol de la red IRC.
Respuestas numéricas:
ERR_ALREADYREGISTRED
Ejemplo:
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Servidor experimental
; El nuevo servidor test.oulu.fi se
presenta e intenta registrarse. El
nombre entre corchetes es el nombre de
host que lleva test.oulu.fi.
Oikarinen & Reed [Pág. 16]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Servidor central
; Servidor tolsun.oulu.fi es el enlace
superior de csd.bu.edu, que está a 5
saltos.
4.1.5 Oper
Comando: OPER
Parámetros: <usuario> <password>
El comando OPER se usa para que un usuario normal obtenga
privilegios de Operador. La combinación <usuario> y <password> es
necesaria para conseguir los privilegios de Operador.
Si el cliente que envía el comando de OPER da un password correcto
para el usuario dado, el servidor informa al resto de la red del
nuevo Operador ejecutando un comando "MODE +O" para el nick del
cliente.
El mensaje OPER es exclusivamente cliente-servidor.
Respuestas numéricas:
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH
Ejemplo:
OPER foo bar ; Intenta registrarse como Operador
usando el nombre de usuario "foo" y
la clave "bar"
4.1.6 Mensaje de salida
Comando: QUIT
Parámetros: [<Mensaje de salida>]
Una sesión de un cliente se finaliza con un mensaje de salida. El
servidor debe cerrar la conexión con un cliente que envía un mensaje
de salida. Si se da un <Mensaje de salida>, éste se enviará en lugar
del mensaje por defecto, el nick.
Cuando hay netsplits (desconexión de dos servidores), el mensaje de
salida está formado por los nombres de los servidores involucrados,
separados por un espacio. El primer nombre es el servidor que aún
está conectado, el segundo el que ha desconectado.
Oikarinen & Reed [Pág. 17]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Si, por cualquier otra razón, se cierra la conexión con un cliente
sin que el cliente envíe el comando QUIT (ej: el cliente muere y hay
un EOF - End Of File - en el socket), el servidor debe rellenar el
mensaje de salida con un mensaje que refleje la naturaleza de la
causa que ha hecho que ocurra.
Respuestas numéricas:
Ninguna.
Ejemplos:
QUIT :Me voy a comer ; Formato de mensaje
4.1.7 Mensaje de salida del servidor
Comando: SQUIT
Parámetros: <servidor> <comentario>
El mensaje SQUIT se necesita para tratar los servidores que
desconectan. Si un servidor quiere terminar la conexión con otro
servidor, debe enviar un mensaje SQUIT al otro servidor, con el
nombre del otro servidor como parámetro, lo que cierra su conexión
con el servidor que desconecta.
Este comando está disponible a los Operadores para ayudar a mantener
una red de IRC conectada de forma ordenada. Los Operadores también
pueden ejecutar un comando SQUIT para una conexión remota entre
servidores. En este caso, el SQUIT debe analizarse por cada servidor
entre el Operador y el servidor remoto, actualizando el esquema de
la red mantenida por cada servidor de la forma que se explica más
abajo.
El <comentario> debe ser indicado por los Operadores que ejecuten un
SQUIT para un servidor remoto (esto es, uno que no está conectado al
servidor en el que se encuentre el Operador), de forma que los demás
Operadores sepan la causa de la desconexión. El <comentario> también
lo rellenan los servidores, pudiendo incluir mensajes de error.
Se requiere que los dos servidores a cada lado de la conexión que
finaliza envíen un mensaje SQUIT (a todas sus conexiones con otro
servidor), para que lo reciban todos los servidores detrás de ese
enlace.
De la misma forma, un mensaje QUIT debe enviarse a los demás
servidores conectados a la red en representación de todos los
clientes tras ese enlace. Además, todos los miembros de un canal que
pierdan un miembro debido al split deben recibir un mensaje de
QUIT.
Oikarinen & Reed [Pág. 18]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Si una conexión con un servidor finaliza prematuramente (ej: se cae
el servidor en el otro lado del enlace), el servidor que detecte la
desconexión debe informar al resto de la red que la conexión se ha
cerrado y rellenar el campo de comentario con algo apropiado.
Respuestas numéricas:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
Ejemplo:
SQUIT tolsun.oulu.fi :¿Enlace erróneo? ;El enlace del servidor
tolson.oulu.fi ha finalizado
por "Enlace erróneo"
:Trillian SQUIT cm22.eng.umd.edu : Servidor fuera de control
; Mensaje de servidor fuera de
control de Trillian para que
desconecte "cm22.eng.umd.edu" por
"Servidor fuera de control"
4.2 Operaciones en un canal
Este grupo de mensajes se refiere a la manipulación de canales, sus
propiedades (modos de canal) y sus contenidos (normalmente clientes).
Al implementarlos, son inevitables unas condiciones de "carrera",
cuando clientes en lados opuestos de una red envíen comandos que
acabarán colisionando. También se requiere que el servidor mantenga
un historial para verificar, cuando se de un parámetro <nick> si
éste ha cambiado.
4.2.1 Mensaje de entrada al canal (JOIN)
Comando: JOIN
Parámetros: <canal>{,<canal>} [<clave>{,<clave>}]
El comando JOIN lo usa el cliente para empezar a escuchar un canal
específico. El que se permita a un cliente entrar al canal o no lo
verifica solamente el servidor al que está conectado el cliente; los
demás servidores automáticamente añaden el usuario al canal cuando
reciben el mensaje de otros servidores. Las condiciones que debe
cumplir el cliente son:
1. el usuario debe ser invitado si el canal está en modo
sólo invitados;
2. el <nick>/<nombre de usuario>/<nombre de host> del usuario
no debe cumplir ninguno de los bans activos;
3. debe pasarse la clave correcta si está activa en el canal.
Oikarinen & Reed [Pág. 19]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Esto se discute con mayor detalle bajo el comando MODE (ver sevvión
4.2.3 para más información).
Una vez que el usuario ha entrado al canal, recibe anuncios sobre
todos los comandos que su servidor recibe que afecten al canal. Esto
incluye MODE, KICK, PART, QUIT y por supuesto PRIVMSG/NOTICE. El
comando JOIN debe enviarse a todos los servidores para que cada
servidor sepa dónde encontrar los usuarios de un canal. Esto permite
un envío óptimo de mensajes PRIVMSG/NOTICE al canal.
Si se consigue entrar al canal, se envía al usuario el "topic" del
canal (usando RPL_TOPIC) y la lista de usuarios que están en el
canal (usando RPL_NAMREPLY), que debe incluir el usuario recién
entrado.
Respuestas numéricas:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC
Ejemplos:
JOIN #foobar ; unirse al canal #foobar.
JOIN &foo fubar ; unirse al canal &foo usando como
clave "fubar".
JOIN #foo,&bar fubar ; unirse al canal #foo usando la
clave "fubar" y &bar sin clave.
JOIN #foo,#bar fubar,foobar ; unirse al canal #foo con la clave
"fubar" y el canal #bar clave
"foobar".
JOIN #foo,#bar ; unirse a los canales #foo and #bar
:WiZ JOIN #Twilight_zone ; mensaje JOIN de WiZ
4.2.2 Mensaje de salida del canal (PART)
Comando: PART
Parámetros: <canal>{,<canal>}
El mensaje de salida provoca el borrado de la lista de usuarios
activos de todos los canales dados en la lista de parámetros.
Oikarinen & Reed [Pág. 20]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Respuestas numéricas:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL
Ejemplos:
PART #twilight_zone ; abandonar el canal "#twilight_zone"
PART #oz-ops,&group5 ; abandonar canales "&group5" y
"#oz-ops".
4.2.3 Mensaje de modos
Comando: MODE
El comando MODE es un comando de doble propósito en el IRC. Permite
cambiar los modos tanto a los usuarios como a los canales. La razón
de ser de esta elección es que algún día los nicks serán obsoletos y
la propiedad equivalente será el canal.N. del T.:Realmente no sé qué
quieren decir aquí, ya que si uno no accede con un nick... ¿Cómo lo
hace?
Al analizar mensajes MODE, se recomienda analizar primero el mensaje
completo y pasar los cambios después.
4.2.3.1 Modos de canal
Parámetros: <canal> {[+|-]|o|p|s|i|t|n|b|v} [<límite>] [<usuario>]
[<máscara de ban>]
El comando MODE se proporciona para que los operadores de canal
puedan cambiar las características de su canal. Se necesita también
que los servidores puedan cambiar los modos de canal para poderse
crear operadores de canal.
Los modos disponibles para canales son:
o - dar/quitar privilegios de operador de canal
p - modo de canal privado
s - canal secreto
i - canal sólo invitados
t - sólo los operadores de canal pueden cambiar el topic
n - no se permiten mensajes al canal desde clientes de fuera
m - canal moderado
l - establecer un límite de usuarios en el canal
b - poner una máscara de ban para mantener usuarios fuera
v - dar/quitar voz en un canal moderado
k - poner clave al canal
Oikarinen & Reed [Pág. 21]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Al usar las opciones 'o' y 'b', hay una restricción de un total de 3
por comando MODE. Esto quiere decir que cualquier combinación de 'o'
y 'b' no debe exceder de 3 en número de parámetros.
4.2.3.2 Modos de usuario
Parámetros: <nick> {[+|-]|i|w|s|o}
Los modos de usuario son cambios que afectan a cómo ven los demás al
cliente o los mensajes "extra" que puede recibir. Un comando MODE
sólo se acepta si tanto el que lo envía como el nick dado como
parámetro coinciden.
Los modos disponibles son:
i - marca el usuario como invisible
s - marca al usuario para que reciba los mensajes del
servidor
w - el usuario recibe wallops (ver 5.6)
o - modo de Operador
Puede haber modos adicionales disponibles más adelante.
Si un usuario intenta hacerse operador usando la opción "+o", debe
ignorarse. En cambio, no hay restricción en que uno se "deopee" (con
"-o").
Respuestas numéricas:
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
Ejemplos:
Uso de los modos de canal:
MODE #Finnish +im ; El canal #Finnish es ahora moderado y
sólo para invitados
MODE #Finnish +o Kilroy ; Da privilegios de "chanop" a Kilroy
en el canal #Finnish.
MODE #Finnish +v Wiz ; Permite hablar a WiZ en #Finnish.
MODE #Fins -s ; El canal #Fins deja de ser "secreto"
Oikarinen & Reed [Pág. 22]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
MODE #42 +k oulu ; Poner como clave del canal "oulu"
MODE #eu-opers +l 10 ; Poner un límite de 10 usuarios en el
canal
MODE &oulu +b ; Lista de máscaras de ban del canal
MODE &oulu +b *!*@* ; Prohibe la entrada a todos los
usuarios
MODE &oulu +b *!*@*.edu ; Prohíbe la entrada a cualquier
usuario con máscara de host *.edu
Uso de los modos de usuario:
:MODE WiZ -w ; Desactiva la recepción de mensajes
WALLOPS para WiZ
:Angel MODE Angel +i ; Mensaje de Angel para hacerse
invisible
MODE WiZ -o ; WiZ "deopeándose" (quitar estatus de
operador. El inverso no debe permitirse
a los usuarios ya que se saltaría el
comando OPER.
4.2.4 Mensaje de tópico
Comando: TOPIC
Parámetros: <canal> [<tópico>]
El mensaje TOPIC se usa para cambiar o ver el tópico de un canal. El
tópico para el canal <canal> se devuelve si no se especifica. Si el
parámetro <tópico> está presente, se cambiará el tópico, si los
modos del canal lo permiten.
Respuestas numéricas:
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED
Ejemplos:
:Wiz TOPIC #test :Nuevo tópico ;El usuario WiZ pone un tópico
TOPIC #test :otro tópico ;Pone el tópico "otro tópico" en
#test
TOPIC #test ;Mirar el tópico de #test
Oikarinen & Reed [Pág. 23]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
4.2.5 Mensaje de nombres
Comando: NAMES
Parámetros: [<canal>{,<canal>}]
Con el comando NAMES, un usuario puede listar todos los nicks que
sean visibles en cualquier canal que puedan ver. Los nombres de
canal que pueden ver son los que no son privados (+p) o secretos
(+s), o aquellos en los que se encuentran. El parámetro <canal>
especifica el (los) canal(es) de los cuales hay que devolver la
información si es posible. No hay mensaje de error si el nombre del
canal es incorrecto.
Si no se especifica un parámetro <canal>, se da una lista de todos
los canales y sus ocupantes. Al final de la lista, aparecen los
usuarios que son visibles pero o bien no están en ningún canal o en
un canal visible, y se marcan como si estuviesen en el "canal" '*'.
Respuestas numéricas:
RPL_NAMREPLY RPL_ENDOFNAMES
Ejemplos:
NAMES #twilight_zone,#42 ;listar usuarios visibles en #42 y
#twilight_zone si puedes ver los
canales
NAMES ;listar todos los canales y usuarios
visibles
4.2.6 Mensaje de lista de canales
Comando: LIST
Parámetros: [<canal>{,<canal>} [<servidor>]]
El mensaje LIST se usa para listar los canales y sus tópicos. Si se
da el parámetro <canal>, solo se visualiza el estatus de ese canal.
Los canales privados se listan (sin el tópico) como canal "Prv" a no
ser que el cliente que genere la petición se encuentre en el canal.
De la misma forma, los canales secretos no se listan a menos que el
cliente sea miembro del canal en cuestión.
Respuestas numéricas:
ERR_NOSUCHSERVER RPL_LISTSTART
RPL_LIST RPL_LISTEND
Oikarinen & Reed [Pág. 24]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Ejemplos:
LIST ;Listar todos los canales
LIST #twilight_zone,#42 ;Listar canales #twilight_zone y #42
4.2.7 Mensaje de invitación a un canal
Comando: INVITE
Parámetros: <nick> <canal>
El mensaje INVITE se usa para invitar a otros usuarios a un canal.
El parámetro <nick> es el nick de la persona a invitar al canal
<canal>. No se requiere que el canal al que se invita al usuario
exista o sea un canal válido. Para invitar a alguien a un canal sólo
para invitados (+i), el cliente que envíe el mensaje INVITE debe ser
operador de canal en dicho canal.
Respuestas numéricas:
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAY
Ejemplos:
:Angel INVITE Wiz #Dust ;Angel invita a WiZ al canal #Dust
INVITE Wiz #Twilight_Zone ;Comando para invitar a WiZ al canal
#Twilight_zone
4.2.8 Comando de expulsión temporal
Comando: KICK
Parámetros: <canal> <usuario> [<comentario>]
El comando KICK se puede usar para eliminar a un usuario de la lista
de miembros de un canal. "Se le patea" del canal (PART forzado).
Sólo los operadores de canal pueden expulsar otro usuario de un
canal. Cada servidor que reciba un mensaje KICK comprueba que es
válido (esto es, el que lo envía es operador de canal) antes de
eliminar a la víctima del canal.
Respuestas numéricas:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_NOTONCHANNEL
Oikarinen & Reed [Pág. 25]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Ejemplos:
KICK &Melbourne Matthew ; Expulsar a Matthew de &Melbourne
KICK #Finnish John :Hablar en inglés
; Expulsar a John de #Finnish con el
comentario "Hablar en inglés como
motivo (comentario)
:WiZ KICK #Finnish John ; Mensaje KICK de WiZ para expulsar a
John del canal #Finnish
NOTA:
Se pueden extender los parámetros del comando KICK de la forma:
<canal>{,<canal>} <usuario>{,<usuario>} [<comentario>]
4.3 Peticiones y comandos del servidor
El grupo de de comandos de petición del servidor sirve para devolver
información de cualquier servidor conectado a la red. Todos los
servidores conectados deben responder correctamente a las peticiones.
Cualquier respuesta incorrecta (o ausencia de ella) debe
considerarse como un servidor caído y debe desconectarse o
deshabilitarse tan pronto como sea posible hasta que se solucione el
problema.
En estas peticiones, donde un parámetro aparece como "<servidor>",
normalmente significa que puede ser un nick, servidor o una máscara
de algún tipo. Para cada parámetro sólo se genera una petición y una
respuesta.
4.3.1 Mensaje de versión
Comando: VERSION
Parámetros: [<servidor>]
El mensaje VERSION se usa para preguntar por la versión del programa
que soporta el servidor. El parámetro opcional <servidor> se usa
para obtener la versión de un servidor al cual no está conectado el
cliente directamente.
Respuestas numéricas:
ERR_NOSUCHSERVER RPL_VERSION
Ejemplos:
:Wiz VERSION *.se ; mensaje de Wiz para comprobar la versión
de un servidor que tenga de máscara *.se
Oikarinen & Reed [Pág. 26]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
VERSION tolsun.oulu.fi ; comprobar la versión de "tolsun.oulu.fi".
4.3.2 Mensaje de estadísticas
Comando: STATS
Parámetros: [<petición> [<servidor>]]
El mensaje STATS se usa para obtener las estadísticas de un servidor
en concreto. Si se omite el parámetro <servidor>, sólo se devuelve
el final de la respuesta de estadísticas. La implementación de este
comando depende en gran medida del servidor que responde, pero el
servidor debe poder proporcionar la información de la forma descrita
por las peticiones especificados abajo (o algo similar).
Una petición puede ser una sola letra que sólo la comprueba el
servidor destino (si se da el parámetro <servidor>, en otro caso se
pasa por servidores intermedios, sin alterar e ignorado. Los tipos
de petición que siguen son los que están implementados actualmente y
proporcionan una gran parte de la información sobre la configuración
del servidor. Aunque puede no ser soportado de la misma forma por
todas las versiones, todos los servidores deberían dar una respuesta
válida a una petición de STATS.
Los tipos de petición soportados son:
c - devuelve una lista de los servidores a los que el
servidor puede conectar o desde los que permite
conexiones.
h - devuelve una lista de servidores que se tratan como
hojas y los que se tratan como concentradores (hubs).
i - devuelve una lista de hosts desde los que el servidor
permite a un cliente conectar.
k - devuelve una lista de combinaciones nombre de usuario/
nombre de host baneados del servidor.
l - devuelve una lista de las conexiones del servidor,
mostrando la duración de cada conexión establecida y el
tráfico sobre esa conexión en bytes y mensajes en cada
dirección.
m - devuelve la lista de comandos soportada por el servidor
y el contador de uso si no es cero.
o - devuelve la lista de hosts desde los cuales los clientes
normales pueden ser Operadores (O-lines).
y - mostrar las líneas Y (Clase) del archivo de
configuración del servidor.
u - devuelve una cadena mostrando cuánto tiempo lleva el
servidor activo.
Oikarinen & Reed [Pág. 27]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
Respuestas numéricas:
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
Ejemplos:
STATS m ; chequear los comandos del servidor
:Wiz STATS c eff.org ; petición de WiZ de información sobre las líneas
C/N del servidor eff.org
4.3.3 Mensaje de enlaces de servidores
Comando: LINKS
Parámetros: [[<servidor remoto>]<máscara de servidor>]
Con el mensaje LINKS, un usuario puede listar los servidores que
conoce el servidor que responda a la petición. La lista debe cumplir
la máscara, pero si no se proporciona dicha máscara, se devuelve la
lista completa.
Si se da el parámetro <servidor remoto> además de <máscara de
servidor>, el comando LINKS se envía al primer servidor que tenga
ese nombre (si lo hay), y ese servidor es el que responde a la
petición.
Respuestas numéricas:
ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKS
Ejemplos:
LINKS *.au ; lista los servidores cuyo nombre
contenga *.au
:WiZ LINKS *.bu.edu *.edu ; Mensaje LINKS de WiZ al primer
servidor *.edu para obtener la lista de
servidores *.bu.edu
N. del T.: el comentario del ejemplo no coincide con lo que dice en la
descripción del comando, desconozco la sintaxis correcta.
Oikarinen & Reed [Pág. 28]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
4.3.4 Mensaje de hora local del servidor
Comando: TIME
Parámetros: [<servidor>]
El mensaje de hora se usa para obtener la hora local del servidor
especificado. Si no se da el parámetro <servidor>, responderá el
servidor que recoja el comando.
Respuestas numéricas:
ERR_NOSUCHSERVER RPL_TIME
Ejemplos:
TIME tolsun.oulu.fi ; Preguntar por la hora en "tolson.oulu.fi"
Angel TIME *.au ; Angel pregunta la hora en un servidor de
"*.au"
4.3.5 Mensaje de conexión servidor-servidor
Comando: CONNECT
Parámetros: <servidor objetivo> [<puerto> [<servidor remoto>]]
El comando CONNECT se usa para obligar a un servidor a intentar
establecer una conexión con otro servidor. Este es un comando
privilegiado y sólo está disponible para Operadores de IRC. Si se da
el parámetro <servidor remoto>, la conexión la realiza ese servidor
al <servidor objetivo> en el <puerto> especificado.
Respuestas numéricas:
ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMS
Ejemplos:
CONNECT tols.oulu.fi ;Intento de conectar un servidor a tols.oulu.fi
:WiZ CONNECT eff.org 6667 csd.bu.edu
; Intento de CONNECT de WiZ para conectar los
servidores eff.org y csd.bu.edu en el puerto 6667
Oikarinen & Reed [Pág. 29]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
4.3.6 Mensaje de trazado de ruta
Comando: TRACE
Parámetros: [<servidor>]
El comando TRACE se usa para encontrar la ruta a un servidor
específico. Cada servidor que procese este mensaje debe decírselo al
que lo envía con una respuesta que indique que es un enlace,
formando una cadena de respuestas similar a la que se obtiene al
usar "traceroute". Tras enviar la respuesta, debe enviar el mensaje
TRACE al siguiente servidor hasta que se llegue al servidor
especificado. Si se omite el parámetro <servidor>, se recomienda que
el comando TRACE envíe un mensaje al que solicita el trazado
diciendo los servidores a los que el servidor actual tiene conexión
directa.
Si el destino especificado por <servidor> es un servidor, el
servidor de destino debe informar a todos los servidores y usuarios
que están conectados a él, aunque sólo los Operadores pueden ver los
usuarios. Si <servidor> es un nick, sólo se dará la respuesta para
ese nick.
Respuestas numéricas:
ERR_NOSUCHSERVER
Si el mensaje TRACE va destinado a otro servidor, todos los
servidores intermedios deben devolver una respuesta RPL_TRACELINK
para indicar que el mensaje pasó por él y donde fue a continuación.
RPL_TRACELINK
Una respuesta a TRACE puede estar compuesta por un número cualquiera
de las siguientes respuestas numéricas:
RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
RPL_TRACEUSER RPL_TRACESERVER
RPL_TRACESERVICE RPL_TRACENEWTYPE
RPL_TRACECLASS
Ejemplos:
TRACE *.oulu.fi ; TRACE al servidor *.oulu.fi
:WiZ TRACE AngelDust ; TRACE de WiZ al nick AngelDust
Oikarinen & Reed [Pág. 30]
RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993
4.3.7 Mensaje de nombre de administrador del servidor
Comando: ADMIN
Parámetros: [<servidor>]
El mensaje ADMIN se usa para obtener el nombre del administrador del
servidor dado, o del servidor al que se está conectado si se omite
el parámetro <servidor>. Cada servidor debe ser capaz de reenviar
los mensajes de ADMIN a otros servidores.
Respuestas numéricas:
ERR_NOSUCHSERVER
RPL_ADMINME RPL_ADMINLOC1
RPL_ADMINLOC2 RPL_ADMINEMAIL
Ejemplos:
ADMIN tolsun.oulu.fi ;pedir una respuesta ADMIN de tolsun.oulu.fi
:WiZ ADMIN *.edu ;petición de ADMIN desde WiZ al primer
&