|
|
|
|
Network Working Group C.Kalt
Request For Comments: 2811 Abril 2000
Actualizaciones: 1459 Traducción: Carlos García Argos
Categoría: Información
Charla Basada en Internet: Mantenimiento de canales
Estado de este memorándum
Este memo da información para la comunidad Internet. No especifica un
estándar de Internet. La distribución de este memorándum es
ilimitada.
Aviso de Copyright
Copyright (C) The Internet Society 2000. Todos los derechos
reservados.
Resumen
Una de las características más importantes del IRC es que permite
agrupar a varios usuarios en foros, llamados canales, proporcionando
una forma de comunicación simultánea entre varios usuarios.
Inicialmente existía un sólo tipo de canales, pero con los años, han
aparecido nuevos tipos, bien como solución a una necesidad o para
experimentación.
Este documento especifica cómo los servidores manejan los canales,
sus características y propiedades.
Índice
1. Introducción .................................................. 3
2. Características de los canales ................................ 3
2.1. Espacio de Nombres ........................................ 3
2.2. Enfoque de los canales .................................... 4
2.3. Propiedades de canal ...................................... 5
2.4. Miembros de canal privilegiados ........................... 5
2.4.1. Operadores de canal ................................... 5
2.4.2. Creador de canal ...................................... 5
3. Tiempo de vida de un canal .................................... 6
3.1. Canales estándar .......................................... 6
3.2. Canales seguros ........................................... 7
4. Modos de canales .............................................. 8
4.1. Estatus de miembros ....................................... 8
4.1.1. Estatus de "creador de canal" ......................... 9
4.1.2. Estatus de operador de canal .......................... 9
Kalt Información [Pág. 1]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
4.1.3. Privilegio de voz ..................................... 9
4.2. Modos de canal ............................................ 9
4.2.1. Modo anónimo .......................................... 9
4.2.2. Modo de sólo invitados ................................10
4.2.3. Modo de canal moderado ................................10
4.2.4. Modo de no mensajes exteriores ........................10
4.2.5. Modo de canal callado .................................10
4.2.6. Canales privados y secretos ...........................11
4.2.7. Modo de reop de servidor ..............................11
4.2.8. Tópico ................................................12
4.2.9. Límite de usuarios ....................................12
4.2.10. Clave de canal .......................................12
4.3. Control de acceso al canal ................................12
4.3.1. Prohibición de entrada al canal y excepciones .........13
4.3.2. Invitación de canal ...................................13
5. Implementaciones actuales .....................................13
5.1. Seguimiento de canales recientes ..........................14
5.2. Canales seguros ...........................................14
5.2.1. Identificador de canal ................................14
5.2.2. Retardo de canal ......................................15
5.2.3. Ventana de abusos .....................................15
5.2.4. Preservando la salud del espacio de nombres ...........16
5.2.5. Mecanismo de reop .....................................16
6. Problemas actuales ............................................17
6.1. Etiquetas .................................................17
6.1.1. Retardo de canal ......................................18
6.1.2. Canales seguros .......................................18
6.2. Retardos de propagación de los modos ......................18
6.3. Colisiones y modos de canales .............................18
6.4. Consumo de recursos .......................................19
7. Consideraciones sobre seguridad ...............................20
7.1. Control de acceso .........................................20
7.2. Privacidad de los canales .................................20
7.3. Anonimato .................................................20
8. Soporte y disponibilidad actual ...............................21
9. Reconocimientos ...............................................21
10. Referencias ..................................................21
11. Dirección del autor ..........................................22
12. Dirección del traductor ......................................22
Kalt Información [Pág. 2]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
1. Introducción
Este documento describe con detalle cómo los servidores de IRC
mantienen los canales y resultará muy util a aquellas personas que
tratan de implementar un servidor de IRC.
Aunque los conceptos que se definen en este documento son una parte
importante del IRC, no son esenciales para implementar clientes. La
tendencia parece ser la implementación de clientes más complejos e
"inteligentes" que aprovechan el funcionamiento interno de los
canales, para dar una interfaz más amigable, pero clientes más sim
ples pueden implementarse sin leer este documento.
Muchos de los conceptos que aquí se presentan se diseñaron teniendo
en cuenta la arquitectura del IRC [ARQUITECTURA-IRC] y tienen sentido
mayoritariamente dentro de este contexto. Sin embargo, muchos otros
conceptos pueden aplicarse a otras arquitecturas para proporcionar
foros en un sistema de conferencias.
Por último, es de resaltar que los usuarios del IRC pueden encontrar
algunas de las secciones de este documento interesantes, sobre todo
las secciones 2 (Características de los canales) y 4 (Modos de
canales).
2. Características de los canales
Un canal es un grupo, que se designa con un nombre, de uno o más
usuarios que recibirán todos los mensajes dirigidos a ese canal. Un
canal se caracteriza por su nombre, sus propiedades y sus miembros.
2.1. Espacio de Nombres
Los nombres de canales son cadenas de caracteres (que comienzan con
'&', '#', '+' o '!') de longitud máxima 50 caracteres. Los nombres de
canales no son sensibles a las mayúsculas.
Aparte del requerimiento que el primer carácter sea '&', '#', '+' o
Kalt Información [Pág. 3]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
'!' (llamado "prefijo del canal"), la única restricción en un nombre
de canal es que no contenga espacios en blanco (' '), un control G
('^G' o ASCII 7), una coma (',' que el protocolo usa como separador
de ítemes). Además, los dos puntos (':') se usan como delimitador
para la máscara del canal. La sintaxis exacta para el nombre de
canales se define en "Protocolo de Servidor de IRC" [SERVIDOR-IRC].
El uso de prefijos diferentes genera cuatro espacios de nombres dis
tintos para los nombres de canales. Esto es importante por las lim
itaciones del protocolo en cuanto a nombres de canales. Ver la
sección 6.1 (Etiquetas) para más detalles sobre estas limitaciones.
2.2. Enfoque de los canales
Una entidad de canal la conocen uno o más servidores en la red de
IRC. Un usuario sólo puede ser miembro de un canal que conozca el
servidor de la red al que está directamente conectado. La lista de
servidores que conocen la existencia de un canal en particular DEBE
ser una parte contigua de la red de IRC, para que los mensajes
dirigidos al canal se envíen a todos sus miembros.
Los canales con el carácter '&' como prefijo son locales al servidor
donde se crean.
Los otros canales son conocidos por uno o más servidores conectados a
la red, dependiendo de la máscara de canal:
Si no hay máscara de canal, es conocido por todos los servidores de
la red.
Si hay máscara de canal, el canal sólo es conocido por los servi
dores que tienen un usuario local en el canal y a sus vecinos si la
máscara coincide con los servidores local y vecino. Dado que los
demás servidores no tienen conocimiento del canal, el área formada
por los servidores cuyo nombre coincida con la máscara debe ser
contigua para que todos los servidores puedan conocer el canal. Las
máscaras de canal se usan más adecuadamente en conjunción con
enmascaramiento de host del servidor [SERVIDOR-IRC].
Kalt Información [Pág. 4]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
2.3. Propiedades de canal
Cada canal tiene sus propiedades, definidas por los modos de canal.
Los modos del canal pueden ser modificados por los usuarios del
canal. Esto significa que todos los modos del canal están desactiva
dos, con la salvedad del modo 't' que está activado.
2.4. Miembros de canal privilegiados
Para que los miembros del canal puedan tener cierto control sobre el
canal y un poco de cordura, hay algunos miembros de canal con privi
legios. Sólo estos miembros pueden efectuar las siguientes acciones
en el canal:
INVITE - Invitar a un cliente a un canal sólo para invitados
(modo +i)
KICK - Expulsar a un cliente del canal
MODE - Cambiar modos de canal y privilegios de los miembros
PRIVMSG - Enviar mensajes al canal (modos +n, +m, +v)
TOPIC - Cambiar el tópico en un canal con el modo +t activo
2.4.1. Operadores de canal
Los operadores de canal (también conocidos como "chop" o "chanop", en
inglés y "op" en español, N. del T.) de un canal dado, se consideran
como 'poseedores' de ese canal. Esta posesión se comparte entre los
operadores del canal.
Los operadores de canal se identifican por el símbolo '@' al lado de
su nick siempre que se le asocie con el canal (por ejemplo, respues
tas a los comandos NAMES, WHO y WHOIS).
Dado que los canales con el prefijo '+' no soportan los modos de
canal, ningún miembro puede poseer el estatus de operador.
2.4.2. Creador de canal
Kalt Información [Pág. 5]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
Un usuario que crea un canal con el carácter '!' como prefijo se
identifica como el 'creador del canal'. En la creación de dicho
canal, a este usuario también se le da el estatus de operador.
Como reconocimiento a este estatus, los creadores de canal pueden
cambiar algunos modos de canal que los operadores de canal no pueden.
Un creador de canal puede distinguirse de un operador de canal ejecu
tando el comando MODE apropiado. Vea el "Protocolo de Cliente de IRC"
[CLIENTE-IRC] para más información al respecto.
3. Tiempo de vida de un canal
En lo referente al tiempo de vida de un canal, hay dos grupos de
canales típicos: los canales estándar cuyo prefijo es '#', '&' o '+'
y los "canales seguros" cuyo prefijo es '!'.
3.1. Canales estándar
Estos canales se crean implícitamente al entrar el primer usuario en
él y deja de existir cuando el último usuario lo abandona. Mientras
el canal exista, cualquier cliente puede referirse al canal usando su
nombre.
El usuario creador de un canal automáticamente obtiene el estatus de
operador de canal, con la excepción de los canales cuyo prefijo es
'+', ver sección 4 (Modos de canales). Ver la sección 2.4.1 (Oper
adores de canal) para más detalles sobre el tema.
Para evitar que se creen canales duplicados (normalmente cuando la
red de IRC se separa debido a la desconexión entre dos servidores),
los nombres de canal NO DEBERÍAN poder ser usados por un usuario si
un operador de canal (ver sección 2.4.1, Operadores de Canal) ha
dejado el canal debido a una separación de la red. Si esto ocurre, la
red está inaccesible temporalmente. El tiempo que un canal permanece
inaccesible debe ajustarse en base a la red de IRC. Es importante
advertir que esto evita que un usuario local cree un canal del mismo
Kalt Información [Pág. 6]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
nombre, pero no que un usuario remoto recree el canal. Esto último
ocurre generalmente cuando la red vuelve a unirse. Obviamente, este
mecanismo sólo tiene sentido con canales cuyo nombre empieza con '#',
pero PUEDE usarse para canales que empiezan con '+'. Este mecanismo
se conoce comúnmente como "Retardo de canal".
3.2. Canales seguros
Al contrario que el resto de los canales, los "canales seguros" no se
crean implícitamente. Un usuario que desee crear un canal de este
tipo, DEBE hacer una petición de su creación enviando al servidor un
comando JOIN especial en el cual el identificador del canal (entonces
desconocido) se reemplaza por el carácter '!'. El proceso de creación
de este tipo de canales está estrictamente controlado. El usuario
sólo escoje parte del nombre del canal (que se denomina el "nombre
abreviado" del canal), el servidor automáticamente antepone al nombre
dado por el usuario un identificador que consta de 5 caracteres. El
nombre de canal que resulta de la combinación de los dos elementos es
único haciendo que el canal esté a salvo de abusos basados en separa
ciones de la red.
El usuario que crea un canal de este tipo automáticamente es "creador
de canal". Ver la sección 2.4.2 (Creador de canal) para más detalles.
Un servidor NO DEBE permitir la creación de un canal nuevo si ya
existe un canal con el mismo nombre abreviado o si existía reciente
mente Y alguno de sus miembros dejó el canal a causa de una sepa
ración de la red.
Al contrario que el mecanismo descrito en la sección 5.2.2 (Retardo
de canal), en este caso, el canal no se vuelve inaccesible: estos
canales pueden existir después que el último usuario deje el canal.
Sólo el usuario que creó el canal es "creador de canal", los usuarios
que entran a un canal vacío existente no son "creadores de canal" ni
"operadores de canal" automáticamente.
Para asegurar la unicidad de los nombres de canal, el identificador
de canal creado por el servidor DEBE seguir reglas específicas. Para
más detalles, ver la sección 5.2.1 (Identificador de canal).
Kalt Información [Pág. 7]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
4. Modos de canales
Los modos disponibles para los canales son los siguientes:
O - dar estatus de "creador de canal"
o - dar/quitar privilegio de operador de canal
v - dar/quitar privilegio de voz
a - cambiar el estado de canal anónimo
i - cambiar el modo de sólo invitados
m - cambiar el modo de canal moderado
n - cambiar el modo de no recibir mensajes desde clientes fuera
del canal
q - cambiar el modo de canal callado
p - cambiar el modo de canal privado
s - cambiar el modo de canal secreto
r - cambiar el modo de reop del canal
t - cambiar el modo que permite cambiar el tópico sólo a los
operadores de canal
k - poner/quitar la clave del canal
l - poner/quitar el límite de usuarios del canal
b - poner/quitar una máscara de ban para mantener usuarios fuera
del canal
e - poner/quitar una máscara de excepción para reemplazar una
máscara de ban
I - poner/quitar una máscara de invitación para reemplazar el
modo de sólo invitados automáticamente
A menos que se especifique lo contrario, todos estos modos pueden ser
cambiados por los "operadores de canal" por medio del comando MODE
descrito en "Protocolo de Cliente IRC" [CLIENTE-IRC].
4.1. Estatus de miembros
Los modos en esta categoría pueden tomar el apodo de un miembro de
canal como argumento y modificar los privilegios de ese usuario.
Kalt Información [Pág. 8]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
4.1.1. Estatus de "creador de canal"
El modo 'O' se usa únicamente con "canales seguros" y NO DEBE ser
modificado por los usuarios. Los servidores lo usan para dar al
usuario que creó el canal estatus de "creador del canal".
4.1.2. Estatus de operador de canal
El modo 'o' se usa para modificar el estatus de operador de un miem
bro de canal.
4.1.3. Privilegio de voz
El modo 'v' se usa para dar y quitar privilegio de voz sobre un miem
bro del canal. Los usuarios con este privilegio pueden hablar en un
canal moderado (ver sección 4.2.3, Modo de canal moderado).
4.2. Modos de canal
Los modos que se definen aquí se usan para definir propiedades que
afectan la forma de operar de los canales.
4.2.1. Modo anónimo
El modo 'a' define un canal anónimo. Esto significa que cuando un
usuario envía un mensaje al canal, al enviarlo el servidor a los
demás usuarios, el mensaje DEBE enmascararse. Para enmascarar el men
saje, se cambia su origen a "anonymous!anonymous@anonymous"
("anónimo!anónimo@anónimo"). Por esta razón, los servidores DEBEN
prohibir el uso del nick "anonymous" ("anónimo"). Además, los servi
dores NO DEBEN enviar mensajes de QUIT de los usuarios que abandonan
estos canales a los demás miembros, sino generar un mensaje de PART
en su lugar.
En los canales con el prefijo '&', este modo PUEDE cambiarlo uno de
los operadores de canal, pero en los canales con el prefijo '!', sólo
Kalt Información [Pág. 9]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
puede activarla (y NO DEBERÁ desactivarse) el "creador del canal".
Este modo NO DEBE estar disponible para otro tipo de canales.
Las respuestas a WHOIS, WHO y NAMES NO DEBEN revelar la presencia de
otros usuarios en canales en los que el modo anónimo está activado.
4.2.2. Modo de sólo invitados
Cuando el modo 'i' está activado en un canal, sólo se admiten nuevos
miembros si su máscara cumple la Lista de Invitados (ver sección
4.3.2) o han sido invitados por un operador de canal. Este modo
también restringe el uso del comando INVITE (ver "Protocolo de
Cliente IRC" [CLIENTE-IRC]) a los operadores de canal.
4.2.3. Modo de canal moderado
El modo de canal 'm' se usa para controlar quién puede hablar en un
canal. Cuando se activa, sólo los operadores de canal y los miembros
que tienen el privilegio de voz pueden enviar mensajes al canal.
Este modo sólo afecta a los usuarios.
4.2.4. Modo de no mensajes exteriores
Cuando el modo 'n' está activado, sólo los miembros del canal PUEDEN
enviar mensajes al canal.
Este modo sólo afecta a los usuarios.
4.2.5. Modo de canal callado
El modo 'q' sólo es para uso de los servidores. Cuando está activado,
restringe el tipo de datos que se envía a los usuarios sobre las
operaciones del canal: no se envían mensajes de otros usuarios
entrando al canal, saliendo y cambios de nick. Desde el punto de
vista de un usuario, el canal sólo tiene un miembro.
Kalt Información [Pág. 10]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
Esto se usa normalmente para crear canales locales especiales a los
que el servidor envía noticias relacionadas con sus operaciones. Esto
se usó como una forma más eficiente y flexible de reemplazar el modo
's' definida en el RFC 1459 [IRC].
4.2.6. Canales privados y secretos
El modo de canal 'p' se usa para marcar un canal como "privado" y el
modo 's' para marcarlo como "secreto". Las dos propiedades son simi
lares y ocultan la existencia del canal a los demás usuarios.
Esto implica que no hay forma de obtener el nombre del canal desde el
servidor si no se es miembro de él. En otras palabras, estos canales
DEBEN omitirse de las respuestas a los comandos como WHOIS.
Cuando un canal es "secreto", además de la restricción anterior, el
servidor actuará como si el canal no existiese para peticiones como
los comandos TOPIC, LIST y NAMES. Advierta que hay una excepción a
esta regla: los servidores responderán correctamente al comando MODE.
Por último, los canales secretos no se cuentan en la respuesta al
comando LUSERS (ver "Protocolo de Cliente IRC" [CLIENTE-IRC]) cuando
se especifica el parámetro <máscara>.
Los modos 'p' y 's' NO DEBEN activarse a la vez. Si un mensaje MODE
desde un servidor activa el modo 'p' y el modo 's' está activado pre
viamente, el cambio se ignora de forma silenciosa. Esto sólo debería
ocurrir durante una fase de recuperación de separación de red (men
cionado en el documento "Protocolo de Servidor de IRC" [SERVIDOR-
IRC]).
4.2.7. Modo de reop de servidor
El modo de canal 'r' sólo está disponible para canales cuyo nombre
empieza por '!' y sólo PUEDE cambiarlo el "creador del canal".
Este modo se usa para evitar que el canal no tenga operadores durante
mucho tiempo. Cuando está activo, en un canal que haya perdido todos
sus operadores de canal por más tiempo que el periodo de "retardo de
Kalt Información [Pág. 11]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
reop" activa un mecanismo en los servidores para reopear (coloquial:
volver a dar privilegio de operador de canal) alguno o a todos los
miembros del canal. Este mecanismo se describe en más detalle en la
sección 5.2.4 (Mecanismo de reop de canal).
4.2.8. Tópico
El modo 't' se usa para restringir el uso del comando TOPIC a los
operadores del canal.
4.2.9. Límite de usuarios
Se puede poner un límite de usuarios en un canal usando el modo de
canal 'l'. Cuando se alcance este límite, los servidores DEBEN pro
hibir que sus usuarios locales entren al canal.
El valor del límite DEBE hacerse disponible a los miembros del canal
sólo en la respuesta enviada por el servidor al comando MODE.
4.2.10. Clave de canal
Cuando se pone una clave al canal (usando el modo 'k'), los servi
dores DEBEN rechazar las peticiones de sus usuarios locales de entrar
al canal a menos que proporcionen la clave.
La clave sólo DEBE ser visible por los miembros del canal en la
respuesta enviada por el servidor al comando MODE.
4.3. Control de acceso al canal
La última categoría de modos se usa para controlar los accesos al
canal, y tienen como argumento una máscara.
Para reducir el tamaño de la base de datos global para los modos de
control de acceso de los canales, los servidores PUEDEN poner un tope
Kalt Información [Pág. 12]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
al número de estos modos para un canal en particular. Si se impone
este tipo de restricción, sólo DEBE afectar a las peticiones de los
usuarios. El límite DEBERÍA ser homogéneo en base a la red de IRC.
4.3.1. Prohibición de entrada al canal y excepciones
Cuando un usuario pide entrar a un canal, su servidor local chequea
la dirección del usuario y comprueba si cumple alguna de las máscaras
de prohibición del canal. Si es así, se rechaza la petición a menos
que la dirección también cumpla alguna de las máscaras de excepción
del canal.
Los servidores NO DEBEN permitir que un miembro de canal baneado (al
que se le ha prohibido la entrada, de ahora en adelante, "baneado",
"banear" y "ban") hable en el canal a menos que sea un operador de
canal o tenga privilegio de voz. (Ver sección 4.1.3: "Privilegio de
Voz").
Un usuario baneado de un canal que reciba una invitación de un oper
ador de canal puede entrar al canal.
4.3.2. Invitación de canal
Para los canales que tengan el modo de sólo invitados activado (ver
sección 4.2.2, "Modo de sólo invitados"), los usuarios cuya dirección
coincida con la máscara de invitación del canal pueden entrar sin
invitación.
5. Implementaciones actuales
La única implementación en este momento de estas reglas como parte
del protocolo IRC es el servidor de IRC, versión 2.10.
El resto de esta sección trata de los apartados que son de mayor
importancia al implementar un servidor pero algunas partes pueden ser
también interesantes para los programadores de clientes.
Kalt Información [Pág. 13]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
5.1. Seguimiento de canales recientes
Este mecanismo se conoce normalmente como "Retardo de Canal" y gen
eralmente sólo afecta a canales cuyo nombre comienza con '#' (Ver
sección 3.1, "Canales Estándar").
Cuando hay una separación de la red, los servidores DEBERÍAN hacer un
seguimiento de los canales que han perdido un operador de canal como
conscuencia de la separación. Estos canales están entonces en un
estado especial que dura un periodo de tiempo concreto. En este
estado, los canales no pueden dejar de existir. Si todos los miembros
del canal lo abandonan, el canal se hace inaccesible: los clientes
locales al servidor no pueden entrar al canal mientras permanezca
vacío.
Una vez que un canal se hace inaccesible, volverá a ser accesible
bien porque ha entrado un usuario remoto (muy probablemente porque la
red se ha vuelto a unir) o porque el periodo del retardo de canal ha
caducado (en cuyo caso el canal deja de existir y puede volver a
crearse).
El tiempo que debería retrasarse la desaparición del canal DEBERÍA
calcularse considerando muchos factores entre los que se encuentra el
tamaño (en términos de usuarios) de la red de IRC y la duración
habitual de las separaciones. DEBERÍA ser uniforme en todos los
servidores de la red de IRC.
5.2. Canales seguros
Este documento introduce la noción de "canales seguros". Estos
canales tienen un nombre precedido por el carácter '!' y se hace un
gran esfuerzo por evitar las colisiones en este espacio de nombres.
Las colisiones no son imposibles, sin embargo, son muy improbables.
5.2.1. Identificador de canal
El identificador del canal es una función del tiempo. La hora actual
(como se define bajo UNIX por el número de segundos transcurridos
Kalt Información [Pág. 14]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
desde el 1 de Enero de 1970 a las 00:00:00 GMT) se convierte a una
cadena de 5 caracteres usando la siguiente base: "ABCDEFGHI
JKLMNOPQRSTUVWXYZ1234567890" (cada carácter tiene un valor decimal
comenzando desde 0 para 'A' hasta 35 para '0').
Por tanto, el identificador de canal tiene una periodicidad de 36^5
segundos (unos 700 días).
5.2.2. Retardo de canal
Estos canales DEBEN someterse al mecanismo del "retardo de canal"
descrito en la sección 5.1. Sin embargo, este mecanismo se modifica
ligeramente para adaptarse mejor.
Los servidores DEBEN mantener un seguimiento de los canales que pier
den miembros como resultado de una separación de la red, ya sean
operadores de canal o no.
Sin embargo, estos canales NO se hacen inaccesibles nunca, siempre es
posible entrar a ellos incluso cuando están vacíos.
5.2.3. Ventana de abusos
Debido a que la periodicidad es muy alta, puede haber ataques en un
(nombre de) canal específico, una vez cada mucho tiempo. Sin embargo,
con suerte y paciencia, es posible que un usuario genere una colisión
en los canales. Para evitarlo, los servidores DEBEN "mirar al futuro"
y mantener una lista de los nombres de canales cuyo identificador
vaya a usarse (en los días siguientes por ejemplo). Dicha lista
deberá ser pequeña, no una preocupación para los servidores y usarse
para evitar las colisiones de canales impidiendo la re-creación de
los canales de la lista en un periodo de tiempo mayor que el retardo
de canal.
En ocasiones, un servidor PUEDE extender este procedimiento para pro
hibir sólo la creación de canales con el mismo nombre abreviado
(ignorando el identificador de canal).
Kalt Información [Pág. 15]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
5.2.4. Preservando la salud del espacio de nombres
La combinación de los mecanismos descritos en las secciones 5.2.2 y
5.2.3 hace bastante complicado que un usuario genere una colisión de
canal. Sin embargo, otro tipo de abuso consiste en crear muchos
canales con el mismo nombre abreviado pero con identificadores dis
tintos. Para evitar esto, los servidores DEBEN prohibir la creación
de un canal nuevo que tenga el mismo nombre abreviado que un canal
que ya exista.
5.2.5. Mecanismo de reop
Cuando un canal ha permanecido sin operadores de canal por más tiempo
que el "retardo de reop" y tiene el modo 'r' activado (ver sección
4.2.7, "Modo de reop de servidor"), los servidores de IRC son los
responsables de dar el estatus de operador de canal a uno de sus
miembros aleatoriamente.
La lógica exacta usada por este mecanismo en la implementación actual
se describe más abajo. Los servidores PUEDEN usar una lógica dis
tinta, pero se RECOMIENDA encarecidamente que todos los servidores de
una red de IRC usen la misma lógica para mantener la coherencia y la
justicia. Por la misma razón, el "retardo de reop" DEBERÍA ser uni
forme en todos los servidores de una red de IRC. De la misma forma
que para el "retardo de canal", el valor del "retardo de reop"
DEBERÍA ponerse en función de muchos factores entre los cuales se
encuentra el tamaño de la red de IRC y la duración habitual de las
separaciones de la red.
a) el mecanismo de reop se dispara después de un tiempo aleatorio
tras haber pasado el periodo del "retardo de reop". Esto debería
evitar que el mecanismo se dispare en dos servidores distintos a la
vez (para un mismo canal).
b) si el canal es pequeño (5 usuarios o menos) y el "retardo de
canal" para ese canal ha pasado,
Entonces reopear a todos los miembros del canal si al menos uno
de ellos es local al servidor.
Kalt Información [Pág. 16]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
c) si el canal es pequeño (5 usuarios o menos) y el "retardo de
canal" para ese canal ha pasado y el "retardo de reop" también ha
pasado,
Entonces reopear a todos los miembros del canal.
d) para otros casos, reopear como mucho uno de los miembros del
canal, basándose en algún método interno al servidor. Si un servi
dor no reopea a un miembro, el método debería ser tal que otro
servidor probablemente lo haga. El método DEBERÍA ser el mismo para
todos los servidores de la red. Una buena heurística podría ser
simplemente reopear al azar. (La implementación actual intenta
escojer un miembro local al servidor que no haya estado inactivo
durante mucho tiempo, posponiendo la acción para dejar a los demás
servidores que encuentren algún miembro que no haya estado inactivo
durante demasiado tiempo. Esto es complicado debido al hecho que
los servidores sólo conocen el tiempo de inactividad de sus usuar
ios locales).
6. Problemas actuales
Hay algunos problemas reconocidos en la forma en que se manejan los
canales de IRC. Algunos pueden atribuirse directamente a las reglas
definidas en este documento, mientras que otros son resultado del
propio "Protocolo de Servidor de IRC" [SERVIDOR-IRC]. Aunque está
derivado del RFC 1459 [IRC], este documento introduce algunas
novedades en un intento de solucionar algunos de los problemas cono
cidos.
6.1. Etiquetas
Este documento describe algunas de las muchas etiquetas usadas en el
protocolo IRC. Aunque hay varios espacios de nombre distintos (basa
dos en el prefijo del nombre de canal), no se permiten duplicados en
cada uno de ellos. Es posible que usuarios en servidores distintos
escojan una etiqueta que pueda resultar en colisiones (con la
excepción de los canales que sólo conoce el servidor en el que están
alojados).
Kalt Información [Pág. 17]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
6.1.1. Retardo de canal
El mecanismo de retardo de canal descrito en la sección 5.1
(Seguimiento de canales recientes) usado para canales con el prefijo
'#' es un intento simple de prevenir colisiones. La experiencia ha
mostrado que, bajo circunstancias normales, es muy eficiente; sin
embargo, tiene limitaciones que hacen que no sea la solución más ade
cuada al problema que aquí se trata.
6.1.2. Canales seguros
Los "canales seguros" descritos en la sección 3.2 son una forma más
adecuada de prevenir las colisiones ya que evita que los usuarios
tengan un control total sobre la etiqueta que escojen. La desventaja
obvia de estas etiquetas es que no son muy intuitivas. Sin embargo,
es bastante trivial la mejora de esto para un programa cliente.
6.2. Retardos de propagación de los modos
Debido a los retrasos que se producen en la red y porque se REQUIERE
que cada servidor verifique la validez de los cambios de modo (por
ejemplo, el usuario existe y tiene los privilegios adecuados), no es
infrecuente que un comando MODE sólo afecte a parte de la red, a
menudo creando discrepancias entre servidores sobre el estado de la
red.
Aunque esto puede parecer sencillo de arreglar (con hacer que única
mente el servidor de origen chequee la validez de los cambios de
modo), se decidió no hacerlo por varias razones. Una de las preocupa
ciones es que los servidores no pueden fiarse unos de otros y que un
mal comportamiento de un servidor puede detectarse fácilmente. Esta
forma de hacerlo también evita los efectos de onda en canales que
están desincronizados cuando se realizan cambios de modo desde difer
entes partes.
6.3. Colisiones y modos de canales
Kalt Información [Pág. 18]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
El documento "Charla Basada en Internet: Protocolo de Servidor"
[SERVIDOR-IRC] describe la forma de intercambiar la información de
los canales entre dos servidores al conectarse entre ellos. Las coli
siones de canales (ya sean legítimas o no) se tratan como eventos
inclusivos, lo que significa que el canal resultante tiene como miem
bros a todos los usuarios que eran miembros del canal en cada servi
dor previo a la conexión.
De forma similar, cada servidor envía los modos del canal al otro.
Por tanto, cada servidor recibe también estos modos de canal. Hay
tres tipos de modos de canal: banderas, máscaras y datos. Los dos
primeros tipos son sencillos de manejar ya que están o bien activados
o desactivados. Si un modo está activado en un servidor, DEBE acti
varse en el otro servidor como resultado de la conexión.
Dado que los tópicos no se envían como parte del intercambio, no rep
resentan ningún problema. Sin embargo, los modos 'l' y 'k' sí se
intercambian, y si estaban activados en ambos servidores antes de la
conexión, no hay ningún mecanismo que sirva para decidir cual de los
dos valores tiene preferencia. Se deja a los usuarios arreglar la
posible discrepancia resultante.
6.4. Consumo de recursos
El modo basado en máscaras definido en la sección 4.3 hace que los
servidores (y la red) de IRC sean vulnerables a un simple abuso del
sistema: un único operador de canal puede activar tantas máscaras
como sea posible en un canal en particular. Esto puede causar fácil
mente un desperdicio de memoria del servidor, además de ancho de
banda (ya que la información se propaga a los demás servidores). Por
esta razón, se RECOMIENDA que se ponga un límite al número de estas
máscaras por canal como se menciona en la sección 4.3.
Además, PUEDEN usarse mecanismos más complejos para evitar tener
máscaras redundantes activas para un mismo canal.
Kalt Información [Pág. 19]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
7. Consideraciones sobre seguridad
7.1. Control de acceso
Una de las formas de controlar el acceso a un canal es usar máscaras
basadas en el nombre de usuario y el nombre de host de las conexiones
de los usuarios. Este mecanismo sólo es eficiente y seguro si los
servidores de IRC tienen una forma precisa de autenticar las conex
iones de los usuarios, y si los usuarios no pueden saltársela fácil
mente. Aunque en teoría es posible implementar un sistema muy
estricto de autenticación, la mayoría de las redes de IRC (especial
mente las redes públicas) no disponen de él y dan pocas garantías de
la veracidad del nombre de usuario y de host de una conexión de
cliente en particular.
Otra forma de controlar el acceso es el uso de una clave de canal,
pero dado que se envía en forma de texto plano, es vulnerable a
ataques por parte de terceros.
7.2. Privacidad de los canales
Dado que las colisiones de canales se tratan como eventos inclusivos
(ver sección 6.3), los usuarios pueden entrar a un canal superando
los controles de acceso. Este método se ha usado desde hace tiempo
para "tomar" canales obteniendo de forma "ilegítima" el estatus de
operador de canal. El mismo método puede usarse para obtener la lista
exacta de los miembros de un canal, además de recibir de vez en
cuando algunos de los mensajes enviados al canal.
7.3. Anonimato
El modo de canal anónimo (ver sección 4.2.1) se puede usar para ocul
tar a los usuarios en ese canal "anónimo" presentando todos los men
sajes al canal como si viniesen desde un pseudo usuario cuyo apodo es
"anónimo". Esto se hace a nivel de cliente-servidor, y no se propor
ciona ningún anonimato en el nivel de servidor-servidor.
Kalt Información [Pág. 20]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
Debería ser obvio para el lector que el nivel de anonimato que se
ofrece es bastante pobre e inseguro, y que los clientes DEBERÍAN
mostrar avisos visibles a los usuarios que entren a estos canales.
8. Soporte y disponibilidad actual
Listas de correo para discusiones sobre IRC:
Discusión general: ircd-users@irc.org
Desarrollo del protocolo: ircd-dev@irc.org
Implementaciones del software:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Grupo de noticias: alt.irc
9. Reconocimientos
Partes de este documento se han copiado del RFC 1459 [IRC] que docu
mentó formalmente por primera vez el protocolo IRC. También se ha
visto beneficiada por varias rondas de revisiones y comentarios. En
particular, las siguientes personas han hecho contribuciones signi
ficativas a este documento:
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
Ruokonen, Magnus Tjernstrom, Stefan Zehl.
10. Referencias
[PALABRAS CLAVE] Bradner, S., "Key words for use in RFCs to Indi
cate Requirement Levels", BCP 14, RFC 2119, March 1997.
[IRC] Oikarinen, J. and D. Reed (Trad. Carlos García
Kalt Información [Pág. 21]
RFC 2811 Charla Basada en Internet: Canales Abril 2000
Argos), "Protocolo de Charla Basado en Internet", RFC 1459, May 1993.
[ARQUITECTURA-IRC] Kalt, C., "Charla Basada en Internet: Arquitec
tura", RFC 2812, Abril de 2000
[CLIENTE-IRC] Kalt, C., "Charla Basada en Internet:Protocolo del
Cliente", RFC 2812, Abril de 2000.
[SERVIDOR-IRC] Kalt, C., "Charla Basada en Internet: Protocolo de
Servidor", RFC 2813, Abril de 2000.
[CANALES-IRC] Kalt, C., "Charla Basada en Internet: Manten
imiento de canales", RFC 2811, Abril de 2000.
11. Dirección del autor
Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
Estados Unidos
Correo Electrónico: kalt@stealth.net
12. Dirección del traductor
Carlos García Argos
C/Antonio Trueba, 14 4-8-2
29017 Málaga
España
Correo Electrónico: cgasoft@yahoo.com
Kalt Información [Pág. 22]