[IRC-Dev CVS] [CVS] Module ircdh: Change committed
Brought to you by:
zolty
Menu
▾
▴
[IRC-Dev CVS] [CVS] Module ircdh: Change committed
|
From: Toni G. <zo...@us...> - 2003-02-13 19:29:31
|
CVSROOT : /cvsroot/irc-dev
Module : ircdh
Commit time: 2003-02-13 19:29:29 UTC
Added files:
doc/es/readme.www doc/es/rfc1459.orig doc/es/rfc1459.unet
Log message:
Documentacion:
{en|es}/readme.www Documento con las direcciones.
{en|es}/rfc1459.orig Documento del RFC original de IRC con su
respectiva traduccion al castellano.
es/rfc1459.unet Documento del RFC modificado traducido al castellano.
---------------------- diff included ----------------------
Index: ircdh/doc/es/readme.www
diff -u /dev/null ircdh/doc/es/readme.www:1.1
--- /dev/null Thu Feb 13 11:29:29 2003
+++ ircdh/doc/es/readme.www Thu Feb 13 11:29:19 2003
@@ -0,0 +1,23 @@
+Además, y de forma actualizada, se puede encontrar información en las
+siguientes páginas webs:
+
+* Web de IRC-Dev:
+ http://www.irc-dev.net
+
+* Documentos de IRC-Dev:
+ http://www.irc-dev.net/ircd/docs.php
+
+* Noticias de actualización y repositorio de parches:
+ http://www.irc-dev.net/ircd/
+
+* Acceso al repositorio CVS:
+ http://cvs.irc-dev.net/cvs/
+
+* Interfaz HTTP dek repositorio CVS:
+ http://cvs.irc-dev.net/cgi-bin/viewcvs.cgi/irc-dev/ircdh
+
+* Pagina del proyecto en Sourceforge:
+ http://sourceforge.net/projects/irc-dev
+
+* Información sobre aumentar los descriptores de fichero por proceso:
+ linux: http://www.linux.org.za/oskar/patches/kernel/filehandle/
Index: ircdh/doc/es/rfc1459.orig
diff -u /dev/null ircdh/doc/es/rfc1459.orig:1.1
--- /dev/null Thu Feb 13 11:29:30 2003
+++ ircdh/doc/es/rfc1459.orig Thu Feb 13 11:29:19 2003
@@ -0,0 +1,3712 @@
+
+
+
+Network Working Group J. Oikarinen
+RFC: 1459 D. Reed
+ Mayo 1993
+ Traducción al castellano: Octubre 1999
+ Carlos García Argos (cg...@ya...)
+
+
+
+ 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.
+
+ Respuest...
[truncated message content] |
