IRC - Internet Relay Chat - (Pag.: 30 - 50)

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

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
servidor *.edu.

4.3.8 Mensaje de información sobre el servidor

Comando: INFO
Parámetros: [<servidor>]

El comando INFO se necesita para obtener información que describa el
servidor: su versión, cuándo se compiló, los parches aplicados,
cuándo se inició y otra información que pueda ser relevante.

Respuestas numéricas:

ERR_NOSUCHSERVER
RPL_INFO RPL_ENDOFINFO

Ejemplos:

INFO csd.bu.edu ;petición de INFO de csd.bu.edu

:Avalon INFO *.fi ;petición de INFO de Avalon sobre el primer
servidor *.fi.

INFO Angel ;pedir INFO del servidor al que Angel está
conectado

Oikarinen & Reed [Pág. 31]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

4.4 Enviando mensajes

El propósito principal del protocolo IRC es el de facilitar una base
de comunicación entre clientes. PRIVMSG y NOTICE son los únicos
comandos disponibles que envían mensajes de texto de un cliente a
otro - el resto simplemente lo hace posible e intenta asegurar que
ocurre de una forma fiable y estructurada.

4.4.1 Mensajes privados

Comando: PRIVMSG
Parámetros: <receptor>{,<receptor>} <texto>

PRIVMSG se usa para enviar mensajes privados entre usuarios.
<receptor> es el nick del que debe recibir el mensaje. Puede ser
también una lista de nicks o canales separados por comas.

El parámetro <receptor> también puede ser una máscara de host
(#mask) o de servidor ($mask). En ambos casos el servidor sólo
enviará los PRIVMSG a los que tengan un servidor o host que coincida
con la máscara. La máscara debe contener al menos un "." y ningún
comodín tras el último ".". Este requisito existe para evitar que se
envíen mensajes a "#*" o "$*", que lo mandaría a todos los usuarios;
la experiencia dice que se abusa de esto más que se usa de forma
responsable y apropiada. Los comodines son los caracteres "*" y "?".
Esta extensión del comando PRIVMSG sólo está disponible para los
Operadores de IRC.

Respuesas numéricas:

ERR_NORECIPIENT ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAY

Ejemplos:

:Angel PRIVMSG Wiz :Hola ¿recibes esto?
; Mensaje de Angel a Wiz.

PRIVMSG Angel :Sí que lo recibo ;Mensaje para Angel.

PRIVMSG jto@tolsun.oulu.fi :Hola
; Mensaje a un cliente en el servidor
tolsun.oulu.fi con nombre de usuario "jto"

PRIVMSG $*.fi :Servidor tolsun.oulu.fi reiniciando
; Mensaje a todos los conectados a un
servidor de máscara *.fi

Oikarinen & Reed [Pág. 32]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

PRIVMSG #*.edu :NSFNet está trabajando, se esperan interrupciones
; Mensaje a todos los usuarios que
tengan máscara de host *.edu

4.4.2. Mensajes de aviso

Comando: NOTICE
Parámetros: <nick> <texto>

El comando NOTICE se usa de forma similar a PRIVMSG. La diferencia
entre ambos es que no se pueden enviar respuestas automáticas a un
NOTICE. Esta regla se aplica también a los servidores (no pueden
enviar mensajes de error en respuesta a un NOTICE). El propósito de
esta regla es el de evitar bucles entre clientes que envían una
respuesta automática a algo que reciben. Esto es típico de los
autómatas (clientes con IA u otro programa interactivo que controla
sus acciones) que siempre tienden a responder de forma que acaban en
un buble con otro autómata.

Ver PRIVMSG para más detalles sobre respuestas y ejemplos.

4.5 Peticiones de usuario

Las peticiones de usuario son un grupoo de comandos relacionados con
la búsqueda de detalles sobre un usuario o grupo de usuarios en
concreto. Cuando se usen comodines, si alguno coincide, sólo se
devolverá la información sobre los usuarios que son "visibles" al
que la solicita. La visibilidad de un usuario viene determinada por
la combinación de los modos del usuario y la configuración de los
canales en los que se encuentren ambos.

4.5.1 Petición de "WHO"

Comando: WHO
Parámetros: [<nombre> [<o>]]

El mensaje WHO lo usa un cliente para generar una petición que
devuelva una lista de información que cumpla el parámetro <nombre>
dado por el cliente. En ausencia del parámetro <nombre>, todos los
usuarios visibles son listados. Se obtiene el mismo resultado al
usar como <nombre> "0" o cualquier comodín que cumpla cualquier
posible entrada.

El <nombre> que se pasa a WHO se compara con hosts de usuarios,
servidores, nombres reales y nicks si el canal <nombre> no se
encuentra.

Si se pasa el parámetro <o>, sólo se devuelven los Operadores cuya
máscara coincida con la suministrada en <nombre>.

Oikarinen & Reed [Pág. 33]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Respuestas numéricas:

ERR_NOSUCHSERVER
RPL_WHOREPLY RPL_ENDOFWHO

Ejemplos:

WHO *.fi ; Lista los usuarios con máscara "*.fi"

WHO jto* o ; Lista los Operadores con máscara "jto*"

4.5.2 Petición de "WHOIS"

Comando: WHOIS
Parámetros: [<servidor>] <máscara de nick>[,<máscara de nick>[,...]]

Este comando se usa para pedir información sobre un usuario en
particular. El servidor responderá al mensaje con varias respuestas
numéricas indicando diversos estados de cada usuario que cumpla con
la máscara de nick (si se es capaz de verlos). Si no hay comodines
en <máscara de nick>, se presentará cualquier información sobre ese
nick que sea capaz de ver. Se puede usar una lista de nick separados
por comas.

La última versión envía la petición a un servidor especifico. Esto
es útil cuando se quiere saber cuánto tiempo lleva inactivo el
usuario, ya que sólo el servidor al que el usuario está conectado
directamente conoce esta información, mientras que el resto se
conoce de forma global.

Respuestas numéricas:

ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
RPL_WHOISUSER RPL_WHOISCHANNELS
RPL_WHOISCHANNELS RPL_WHOISSERVER
RPL_AWAY RPL_WHOISOPERATOR
RPL_WHOISIDLE ERR_NOSUCHNICK
RPL_ENDOFWHOIS

Ejemplos:

WHOIS wiz ;devuelve la información disponible sobre WiZ

WHOIS eff.org trillian ;pide al servidor eff.org información sobre
trillian

Oikarinen & Reed [Pág. 34]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

4.5.3 Petición de "WHOWAS"

Comando: WHOWAS
Parámetros: <nick> [<contador> [<servidor>]]

WHOWAS pide información sobre un nick que ya no existe. Esto puede
ser bien por un cambio de nick o porque el usuario sale del IRC.
Como respuesta, el servidor busca en su historial de nicks un nick
que coincida con el dado (nada de comodines). La búsqueda es en
orden ascendente, devolviendo la entrada más reciente. Si hay más de
una entrada, se devolverán como mucho <contador> respuestas (o todas
si no hay <contador>). Si se da un número negativo a <contador>, se
realiza una búsqueda completa.

Respuesas numéricas:

ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
RPL_WHOWASUSER RPL_WHOISSERVER
RPL_ENDOFWHOWAS

Ejemplos:

WHOWAS Wiz ;devuelve toda la información en el
historial de nicks sobre "WiZ"

WHOWAS Mermaid 9 ;devuelve como mucho las 9 entradas más
recientes del nick "Mermaid"

WHOWAS Trillian 1 *.edu ;devuelve la entrada más reciente del nick
"Trillian" en el primer servidor que tenga
de máscara "*.edu".

4.6 Otros mensajes

Los mensajes de esta categoría no entran en ninguna de las otras,
pero de todas formas son parte y requisito del protocolo.

4.6.1 Mensaje de "KILL"

Comando: KILL
Parámetros: <nick> <comentario>

El comando KILL se usa para cerrar una conexión cliente-servidor,
mediante el servidor que sostiene la conexión.Lo usan los servidores
cuando encuentran una entrada duplicada en la lista de nicks válidos
y sirve para eliminar ambas entradas. También está disponible a los
Operadores de IRC.

Oikarinen & Reed [Pág. 35]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Este comando es inútil contra los clientes que tienen algoritmos de
reconexión automática ya que la desconexión es breve. Sin embargo,
se rompe el flujo de datos y puede usarse para parar "inundaciones"
de flujo de datos. Cualquier usuario puede elegir recibir los
mensajes de KILL que se generen para otros usuarios.

En una "arena", donde los nicks deben ser globalmente únicos todo el
tiempo, los mensajes de KILL se envían cuando se detectan
"duplicados" (intento de registrar dos usuarios con el mismo nick),
esperando que ambos desaparecerán y sólo uno reaparecerá.

El comentario debe reflejar el motivo del KILL. Para KILLs generados
por servidor normalmente se rellena con detalles relativos a los
orígenes de los dos nicks conflictivos. Para los usuarios se les
deja proveer una razón adecuada que satisfaga a los usuarios que lo
vean. Para prevenir KILLs falsos que oculten la identidad del
KILLeador, el comentario muestra también un "camino de kill",
rellenado por el servidor por el que pasa, cada uno añadiendo su
nombre al "camino".

Respuestas numéricas:

ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK ERR_CANTKILLSERVER

KILL David (csd.bu.edu <- tolsun.oulu.fi)
;Colisión de nicks entre csd.bu.edu y tolson.oulu.fi

NOTA:
Se recomienda que solo los Operadores puedan KILLear otros usuarios
con el comando KILL. En un mundo ideal ni siquiera los Operadores
necesitan hacerlo y se deja este trabajo a los servidores.

4.6.2 Mensaje de "PING"

Comando: PING
Parámetros: <servidor1> [<servidor2>]

El mensaje de PING se usa para comprobar la presencia de un cliente
activo al otro lado de la conexión. El servidor envía un mensaje de
PING a intervalos regulares si no se detecta actividad de una
conexión. Si una conexión no responde a un comando PING dentro de un
espacio de tiempo, se cierra la conexión.

Cualquier cliente que reciba un PING debe responder al <servidor1>
(servidor que envía el mensaje PING) tan pronto como le sea posible
con el mensaje PONG apropiado para indicar que está activo. Los
servidores no deben responder a PINGs pero se apoyan en los que

Oikarinen & Reed [Pág. 36]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

vienen del otro lado de la conexión para comprobar que la conexión
está viva. Si se especifica <servidor2>, el mensaje de ping se
reenvía allí.

Respuestas numéricas:

ERR_NOORIGIN ERR_NOSUCHSERVER

Ejemplos:

PING tolsun.oulu.fi ;servidor enviando un mensaje PING a otro
para indicar que sigue vivo.

PING WiZ ;mensaje PING enviado al nick WiZ

4.6.3 Mensaje de "PONG"

Comando: PONG
Parámetros: <demonio> [<demonio2>]

El mensaje de PONG es la respuesta al mensaje de PING. Si se pasa el
parámetro <demonio2>, el mensaje debe reenviarse al demonio
especificado. El parámetro <demonio> es el nombre del demonio que
responde al mensaje de PING y que genera este mensaje.

Respuestas numéricas:

ERR_NOORIGIN ERR_NOSUCHSERVER

Ejemplos:

PONG csd.bu.edu tolsun.oulu.fi ;mensaje PONG desde csd.bu.edu a
tolson.oulu.fi

4.6.4 Error

Comando: ERROR
Parámetros: <mensaje de error>

El comando ERROR lo usan los servidores para informar sobre errores
serios o fatales a sus Operadores. Puede enviarse también de un
servidor a otro, pero no debe aceptarse desde ningún cliente normal
que sea desconocido.

Un mensaje de ERROR informa únicamente de errores que ocurren en un
enlace servidor-servidor. Se envía al servidor del otro lado (que lo
envía a todos sus Operadores conectados) y a todos los Operadores
conectados. No debe enviarlo un servidor a otros servidores, si se
recibe de un servidor.

Oikarinen & Reed [Pág. 37]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Cuando un servidor envía un mensaje de ERROR que recibe a sus
Operadores, el mensaje debería incluirse en un mensaje de NOTICE,
indicando que el que el cliente no fue responsable del error.

Respuestas numéricas:

Ninguna

Ejemplos:

ERROR :El servidor *.fi ya existe ;mensaje de ERROR al servidor que
causó el error

NOTICE WiZ :ERROR desde csd.bu.edu -- El servidor *.fi ya existe
;Mismo mensaje que antes pero enviado
al usuario WiZ en el otro servidor

5. MENSAJES OPCIONALES

Esta sección describe mensajes OPCIONALES. No son requerimiento en
una implementación del protocolo descrito aquí para un servidor. En
ausencia de esta opción, debe generarse un mensaje de error o un
error de comando desconocido. Si el mensaje va destinado a otro
servidor, debe pasarse (se requiere análisis de elementos). Las
respuestas numéricas se listan en las secciones posteriores.

5.1 Mensaje de ausencia (AWAY)

Comando: AWAY
Parámetros: [mensaje]

Con el mensaje de AWAY, el cliente pueden establecer una cadena de
respuesta para cualquier comando PRIVMSG que se dirija a él (no a un
canal en el que se encuentren). La respuesta automática la envía el
servidor al cliente que envía el PRIVMSG. El servidor que responde
es aquel al que está conectado el cliente que lo envía.

El mensaje de AWAY se usa bien con un parámetro (para establecer un
mensaje de ausencia) o sin parámetros (para quitar el mensaje de
ausencia).

Respuestas numéricas:

RPL_UNAWAY RPL_NOWAWAY

Ejemplos:

AWAY :Vuelvo en 5 min ;Pone el mensaje de ausencia "Vuelvo en 5 min"

:WiZ AWAY ;quita el mensaje de ausencia de WiZ

Oikarinen & Reed [Pág. 38]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

5.2 Comando de reconfiguración del servidor

Comando: REHASH
Parámetros: Ninguno

El mensaje de REHASH lo puede usar un Operador para obligar al
servidor a que relea y procese su archivo de configuración.

Respuestas numéricas:

RPL_REHASHING ERR_NOPRIVILEGES

Ejemplos:

REHASH ;mensaje de un cliente con estatus de operador para
que el servidor relea su archivo de configuración

5.3 Comando de reinicio del servidor

Comando: RESTART
Parámetros: Ninguno

El mensaje de RESTART sólo lo puede usar un Operador para obligar a
un servidor a que reinicie. Este comando es opcional, ya que puede
verse como un riesgo el permitir que la gente conecte al servidor
como Operador y ejecute el comando, provocando (como poco) una
interrupción del servicio.

El comando de RESTART debe ser procesado siempre por el servidor al
que el cliente que lo envía está conectado y no pasado a otros
servidores.

Respuestas numéricas:

ERR_NOPRIVILEGES

Ejemplos:

RESTART ;no se requieren parámetros

5.4 Mensaje de invocación (SUMMON)

Comando: SUMMON
Parámetros: <usuario> [<servidor>]

El comando SUMMON puede usarse para enviar un mensaje a los usuarios
conectados a un host que tenga un servidor de IRC para que se unan
al IRC. Este mensaje sólo se envía si: (a) el servidor objetivo
tiene activada la invocación, (b) el usuario está conectado, y (c)
el servidor puede escribir a la consola (o similar) del usuario.

Oikarinen & Reed [Pág. 39]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

Si no se da un parámetro <servidor>, se intenta invocar al <usuario>
desde el servidor al que está conectado el cliente.

Si no está activada la invocación en un servidor, debe devolver la
respuesta ERR_SUMMONDISABLED y pasar el mensaje de invocación en
adelante.

Respuestas numéricas:

ERR_NORECIPIENT ERR_FILEERROR
ERR_NOLOGIN ERR_NOSUCHSERVER
RPL_SUMMONING

Ejemplos:

SUMMON jto ;invocar al usuario jto en el host del
servidor IRC

SUMMON jto tolsun.oulu.fi ;invocar al usuario jto en el host que
tiene un servidor IRC llamado
"tolsun.oulu.fi"

5.5 Mensaje de lista de usuarios

Comando: USERS
Parámetros: [<servidor>]

El comando USERS devuelve una lista de los usuarios conectados al
servidor de forma similar a who(1), rusers(1) y finger(1). Puede
deshabilitarse este comando por razones de seguridad. Si se hace,
debe devolverse la respuesta numérica adecuada para indicarlo.

Respuestas numéricas:

ERR_NOSUCHSERVER ERR_FILEERROR
RPL_USERSSTART RPL_USERS
RPL_NOUSERS RPL_ENDOFUSERS
ERR_USERSDISABLED

Respuesta de comando deshabilitado:

ERR_USERSDISABLED

Ejemplos:

USERS eff.org ;petición de la lista de usuarios conectados
al servidor eff.org

:John USERS tolsun.oulu.fi ;petición de John de la lista de usuarios
del servidor tolsun.oulu.fi

Oikarinen & Reed [Pág. 40]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

5.6 Comando de mensaje a los Operadores

Comando: WALLOPS
Parámetros: Mensaje para todos los Operadores conectados

Envía un mensaje a todos los Operadores de IRC conectados. Tras la
implementación de WALLOPS como un comando de usuario, se vió que se
usaba para enviar mensaje a mucha gente (de forma parecida a WALL).
Debido a esto, se recomienda que la implementación de WALLOPS se use
como ejemplo permitiendo y reconociendo únicamente a los servidores
la capacidad de enviar WALLOPS.

Respuestas numéricas:

ERR_NEEDMOREPARAMS

Ejemplos:

:csd.bu.edu WALLOPS :Conexión '*.uiuc.edu 6667' de Joshua
; WALLOPS de csd.bu.edu anunciando un
mensaje de conexión que recibió de Joshua

5.7 Comando USERHOST

Comando: USERHOST
Parámetros: <nick>{<espacio><nick>}

El comando USERHOST toma una lista de hasta 5 nicks, separados por
espacios y devuelve una lista con información sobre cada uno. La
lista tiene cada respuesta separada por un espacio.

Respuestas numéricas:

RPL_USERHOST ERR_NEEDMOREPARAMS

Ejemplos:

USERHOST Wiz Michael Marty p ;petición de USERHOST sobre los nicks
"Wiz", "Michael", "Marty" y "p"

5.8 Comando ISON

Comando: ISON
Parámetros: <nick>{<espacio><nick>}

El comando ISON se implementó para proporcionar una forma rápida y
eficiente de obtener una respuesta sobre si un nick dado estaba en
el IRC. Sólo toma como parámetro una lista de nicks separados por
espacios. El servidor añade cada nick a su cadena de respuesta. Por
tanto, la cadena de respuesta puede ser vacía (ninguno de los nicks
se encuentra en el IRC), una copia exacta de la cadena de parámetros

Oikarinen & Reed [Pág. 41]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

(todos se encuentran) o un subconjunto del conjunto de nicks
proporcionados. La única restricción en el número de nicks que
pueden comprobarse es la que viene dada por la longitud combinada,
que no debe exceder de 512 caracteres.

ISON sólo debe procesarlo el servidor al que está conectado el
cliente que envía el comando y por tanto no debe pasarse a los demás
servidores.

Respuestas numéricas:

RPL_ISON ERR_NEEDMOREPARAMS

Ejemplos:

ISON phone trillian WiZ jarlek Avalon Angel Monstah
;ejemplo de petición ISON de 7 nicks

6. RESPUESTAS

A continuación hay una lista de respuestas numéricas generadas en
contestación a los comandos dados arriba. Cada respuesta se da con
su número, nombre y cadena de respuesta.

6.1 Respuestas de error

401 ERR_NOSUCHNICK
"<nick> :No existe el nick/canal"

- Se usa para indicar que el parámetro <nick>
proporcionado a un comando no se ecuentra

402 ERR_NOSUCHSERVER
"<nombre de servidor> :No existe el servidor"

- Indica que el servidor cuyo nombre se proporciona no
existe

403 ERR_NOSUCHCHANNEL
"<nombre de canal> :No existe el canal"

- Indica que el nombre de canal no es válido

404 ERR_CANNOTSENDTOCHAN
"<nombre de canal> :No se puede enviar al canal"
- Se envía a un usuario que (a) no está en un canal que
tiene el modo +n o (b) no es un operador de canal (o
tiene el modo +v) en un canal +m

Oikarinen & Reed [Pág. 42]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

405 ERR_TOOMANYCHANNELS
"<nombre de canal> :Has entrado en demasiados \
canales"
- Se envía a un usuario que ha alcanzado el número
máximo de canales en los que se permite estar e
intenta entrar en otro

406 ERR_WASNOSUCHNICK
"<nick> :No se encuentra el nick"

- Devuelto por WHOWAS para indicar que no existe
información en el registro del nick

407 ERR_TOOMANYTARGETS
"<target> :Receptores duplicados. No se ha \
enviado el mensaje"

- Devuelto a un cliente que intenta enviar un mensaje
usando el formato de destino usuario@host cuando el
objetivo tiene varios destinos

409 ERR_NOORIGIN
":No se ha especificado el origen"

- Mensaje de PING o PONG al que no se ha indicado el
origen que se requiere ya que estos comandos deben
trabajar sin prefijos válidos

411 ERR_NORECIPIENT
":No se ha dado receptor (<comando>)"
412 ERR_NOTEXTTOSEND
":No hay texto que enviar"
413 ERR_NOTOPLEVEL
"<máscara> :No se ha especificado el dominio \
superior"
414 ERR_WILDTOPLEVEL
"<máscara> :Comodín en dominio superior"

- 412 - 414 los devuelve PRIVMSG para indicar que un
mensaje no se envió por alguna razón. ERR_NOTOPLEVEL
y ERR_WILDTOPLEVEL se devuelven al intentar un uso
incorrecto de "PRIVMSG $<servidor>" o "PRIVMSG #<host>"

421 ERR_UNKNOWNCOMMAND
"<comando> :Comando desconocido"

- Se devuelve a un cliente registrado para indicar que
el servidor desconoce el comando

Oikarinen & Reed [Pág. 43]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

422 ERR_NOMOTD
":Falta el archivo MOTD"

- El servidor no pudo abrir el archivo MOTD (Message Of
The Day, Mensaje del día)

423 ERR_NOADMININFO
"<servidor> :No hay infomación del administrador"

- Respuesta del servidor al comando ADMIN cuando hay un
error al encontrar la información

424 ERR_FILEERROR
":Error de fichero <operación de fichero> en <fichero>"
- Mensaje de error genérico para informar de una
operación de archivo fallida en el procesamiento de
un mensaje

431 ERR_NONICKNAMEGIVEN
":No se ha dado ningún nick"

- Devuelto cuando no se encuentra el parámetro <nick>
supuesto para un comando

432 ERR_ERRONEUSNICKNAME
"<nick> :Nick incorrecto"

- Devuelto cuando un mensaje NICK contiene caracteres
que no están incluidos en el conjunto de definición.
Ver sección x.x.x para más detalles sobre nicks
válidos.

433 ERR_NICKNAMEINUSE
"<nick> :El nick ya está en uso"

- Devuelto cuando un comando NICK pretende cambiar a un
nick ya existente

436 ERR_NICKCOLLISION
"<nick> :KILL por colisión de nicks"

- Devuelto por el servidor a un cliente cuando detecta
una colisión de nicks (de un NICK registrado que ya
existe en otro servidor)

441 ERR_USERNOTINCHANNEL
"<nick> <canal> :No están en el canal"

- Indica que el objetivo del comando no está en el
canal dado

Oikarinen & Reed [Pág. 44]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

442 ERR_NOTONCHANNEL
"<canal> :No estás en ese canal"

- Lo devuelve el servidor cuando un cliente intenta
ejecutar un comando de canal en el que no es miembro

443 ERR_USERONCHANNEL
"<usuario> <canal> :ya está en el canal"

- Devuelto cuando un cliente intenta invitar a un
usuario a un canal en el que ya se encuentra

463 ERR_NOPERMFORHOST
":¡Su host no está entre los privilegiados!"

- Devuelto cuando un cliente intenta registrarse en un
servidor que no admite conexiones desde el host del
cliente

444 ERR_NOLOGIN
"<usuario> :Usuario no conectado"

- Devuelto por el invocador después de un comando
SUMMON para un usuario que no está conectado

445 ERR_SUMMONDISABLED
":SUMMON está desactivado"

- Respuesta al comando SUMMON de un servidor que lo
tiene desactivado

446 ERR_USERSDISABLED
":USERS deshabilitado"

- Respuesta al comando USERS de un servidor que no lo
implementa

451 ERR_NOTREGISTERED
":No se ha registrado"

- Indicación del servidor de que el cliente debe
registrarse antes de que se le permita enviar
comandos

461 ERR_NEEDMOREPARAMS
"<comando> :No hay parámetros suficientes"

- Devuelto por muchos comandos para indicar que el
cliente no proporcionó suficientes parámetros

Oikarinen & Reed [Pág. 45]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

462 ERR_ALREADYREGISTRED
":No puede volver a registrarse"

- Devuelto por el servidor a un enlace que intenta
cambiar parte de los detalles de registro (como la
clave o detalles de usuario de un segundo mensaje
USER)

464 ERR_PASSWDMISMATCH
":Clave incorrecta"

- Indica un intento fallido de registrar una conexión
para la que se necesita clave y no se proporcionó o
es incorrecta

465 ERR_YOUREBANNEDCREEP
":Usted está baneado de este servidor"

- Devuelto tras un intento de conectar y registrarse
en un servidor configurado para denegar conexiones de
usted

467 ERR_KEYSET
"<canal> :La clave de canal ya está puesta"
471 ERR_CHANNELISFULL
"<canal> :No se puede unir al canal (+l)"
472 ERR_UNKNOWNMODE
"<carácter>:el modo es desconocido al servidor"
473 ERR_INVITEONLYCHAN
"<canal> :No se puede unir al canal (+i)"
474 ERR_BANNEDFROMCHAN
"<canal> :No se puede unir al canal (+b)"
475 ERR_BADCHANNELKEY
"<canal> :No se puede unir al canal (+k)"
481 ERR_NOPRIVILEGES
":Permiso denegado- No es Operador de IRC"

- Un comando que requiera privilegios de Operador debe
devolver este error para indicar que el intento falló

482 ERR_CHANOPRIVSNEEDED
"<canal> :No es operador de canal"

- Cualquier comando que requiera privilegios de
operador de canal (por ejemplo los mensajes MODE)
debe devolver este error si el cliente que lo ejecuta
no es operador de canal en el canal especificado

483 ERR_CANTKILLSERVER
":No se puede killear un servidor!"

Oikarinen & Reed [Pág. 46]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

- Cualquier intento de usar el comando KILL con un
servidor debe rechazarse y devolverse este error al
cliente

491 ERR_NOOPERHOST
":No hay O-lines para su host"

- Si un cliente envía un mensaje OPER y el servidor no
está configurado para permitir conexiones de Operador
desde el host del cliente, debe devolverse este error

501 ERR_UMODEUNKNOWNFLAG
":Modo desconocido"

- Devuelto por el servidor para indicar que un mensaje
MODE se envió con un parámetro de modo desconocido

502 ERR_USERSDONTMATCH
":No se pueden cambiar modos a otros usuarios"

- Error enviado a un usuario que intenta ver o cambiar
un modo de un usuario distinto de sí mismo

6.2 Respuestas a comandos

300 RPL_NONE
Número de respuesta falso. No se usa

302 RPL_USERHOST
":[<respuesta>{<espacio><respuesta>}]"

- Formato de respuesta usado por USERHOST para listar
las respuestas. La cadena de respuesta se compone de
la siguiente forma:

<respuesta>::=<nick>['*'] '=' <'+'|'-'><nombre de host>

El '*' indica si el cliente se ha registrado como
Operador. El '-' o '+' representan si el cliente está
o no "AWAY", respectivamente.

303 RPL_ISON
":[<nick> {<espacio><nick>}]"

- Formato de respuesta usado por ISON para listar su
respuesta

301 RPL_AWAY
"<nick> :<mensaje de away>"

Oikarinen & Reed [Pág. 47]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

305 RPL_UNAWAY
":Ya no se le marca como ausente"
306 RPL_NOWAWAY
":Está usted marcado como ausente"

- Estas respuestas se usan con el comando AWAY (si está
activado). RPL_AWAY se envía a cualquier cliente que
envía un PRIVMSG a otro cliente que esté ausente.
RPL_AWAY sólo lo envía el servidor al que está
conectado el cliente que envía el PRIVMSG. Las
respuestas RPL_UNAWAY y RPL_NOWAWAY se envían cuando
el cliente quita y pone el mensaje de ausencia.

311 RPL_WHOISUSER
"<nick> <usuario> <host> * :<nombre real>"
312 RPL_WHOISSERVER
"<nick> <servidor> :<información del servidor>"
313 RPL_WHOISOPERATOR
"<nick> :es Operador de IRC"
317 RPL_WHOISIDLE
"<nick> <entero> :segundos inactivo"
318 RPL_ENDOFWHOIS
"<nick> :Fin de la lista /WHOIS"
319 RPL_WHOISCHANNELS
"<nick> :{[@|+]<canal><espacio>}"

- Las respuestas 311 - 313, 317 - 319 se generan tras
un mensaje WHOIS. Supuesto que hay suficientes
parámetros, el servidor que contesta debe formular
una respuesta a partir de los números de arriba (si
se encuentra el nick) o devolver un error. El '*' en
RPL_WHOISUSER es un carácter literal y no un comodín.
Para cada conjunto de respuestas, únicamente
RPL_WHOISCHANNELS puede aparecer más de una vez
(listas de canales largas). Los caracteres '@' y '+'
al lado del nombre de canal indican si el cliente es
operador de canal o tiene permiso para hablar en un
canal moderado. La respuesta RPL_ENDOFWHOIS se usa
para marcar el final del procesamiento de un mensaje
WHOIS.

314 RPL_WHOWASUSER
"<nick> <usuario> <host> * :<nombre real>"
369 RPL_ENDOFWHOWAS
"<nick> :Fin de la lista /WHOWAS"

- Al responder a un mensaje de WHOWAS, un servidor debe
usar las respuestas RPL_WHOWASUSER, RPL_WHOISSERVER o
ERR_WASNOSUCHNICK para cada nick en la lista
presentada. Al final de los lotes de respuesa, debe

Oikarinen & Reed [Pág. 48]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

estar RPL_ENDOFWHOWAS (incluso si sólo hubo una
respuesta y esta fue un error).

321 RPL_LISTSTART
"Canal :Usuarios Nombre"
322 RPL_LIST
"<canal> <# visible> :<tópico>"
323 RPL_LISTEND
":Fin de /LIST"

- Las respuestas RPL_LISTSTART, RPL_LIST, RPL_LISTEND
marcan el principio, la respuesta en sí y el final de
la contestación del servidor al comando LIST. Si no
hay canales que devolver, sólo se envían las
respuestas de inicio y fin.

324 RPL_CHANNELMODEIS
"<canal> <modo> <parámetros de modo>"

331 RPL_NOTOPIC
"<canal> :No hay tópico establecido"
332 RPL_TOPIC
"<canal> :<tópico>"

- Cuando se envía un mensaje TOPIC para determinar el
tópico del canal, se envía una de las dos respuestas.
Si hay tópico establecido, se envía RPL_TOPIC, en
otro caso, RPL_NOTOPIC.

341 RPL_INVITING
"<canal> <nick>"

- Indica que el mensaje INVITE se ejecutó con éxito y
se está pasando al cliente destino.

342 RPL_SUMMONING
"<usuario> :Llamando usuario al IRC"

- Devuelto por un servidor respondiendo un mensaje
SUMMON para indicar que está invocando al usuario.

351 RPL_VERSION
"<versión>.<nivel de depuración> <servidor> :\
<comentarios>"

- Respuesta del servidor que muestra los detalles de su
versión. La <versión> es la del programa que se está
usando (incluidos las revisiones de los parches) y el

Oikarinen & Reed [Pág. 49]

RFC 1459 Protocolo de Charla Basada en Internet Mayo 1993

<nivel de depuración> indica si el servidor está en
"modo de depuración".

El campo <comentarios> puede contener comentarios
sobre la versión o detalles adicionales de versión.

352 RPL_WHOREPLY
"<canal> <usuario> <host> <servidor> <nick> \
<H|G>[*][@|+] :<contador de salto> <nombre real>"
315 RPL_ENDOFWHO
"<nombre> :Fin de la lista /WHO"

- RPL_WHOREPLY y RPL_ENDOFWHO se usan para contestar a
un mensaje WHO. RPL_WHOREPLY sólo se envía si hay una
entrada apropiada a la petición de WHO. Si hay una
lista de parámetros en el mensaje WHO, se debe enviar
un RPL_ENDOFWHO después de procesar cada elemento de
la lista, siendo <nombre> el elemento.

353 RPL_NAMREPLY
"<canal> :[[@|+]<nick> [[@|+]<nick> [...]]]"
366 RPL_ENDOFNAMES
"<canal> :Fin de la lista /NAMES"

- Para responder un mensaje NAMES, se envían al cliente
una pareja de mensajes RPL_NAMREPLY y RPL_ENDOFNAMES.
Si no se encuentra un canal como el de la petición,
sólo se envía RPL_ENDOFNAMES. Una excepción a esto es
si el mensaje NAMES se envía sin parámetros, en ese
caso, se devuelven todos los canales visibles y sus
contenidos en una serie de mensajes RPL_NAMEREPLY con
un RPL_ENDOFNAMES marcando el final.

364 RPL_LINKS
"<máscara> <servidor> :<contador de salto> \
<información del servidor>"
365 RPL_ENDOFLINKS
"<máscara> :Fin de la lista /LINKS"

- Al contestar un mensaje LINKS, el servidor debe
enviar respuestas usando RPL_LINKS y marcar el final
con RPL_ENDOFLINKS.

367 RPL_BANLIST
"<canal> <identificación de ban>"
368 RPL_ENDOFBANLIST
"<canal> :Fin de la lista de bans del canal"

- Cuando se listan los "bans" activos de un canal, el
servidor debe devolver la lista usando los mensajes

Oikarinen & Reed [Pág. 50]