GnomixLand :: Manuali, immagini, fotografie e tanto altro a portata di un click

GnomixLand

Network Working Group J. Oikarinen
Request for Comments: 1459 D. Reed
May 1993

Traduzione a cura di ComiSAT
Brescia, Set 2002
(http://www.comisat.it)

Protocollo Internet Relay Chat

Stato di questa memoria

Questa memo definisce un Protocollo Sperimentale per la comunita’ di
Internet. Sono richieste discussioni e suggerimenti per il miglioramento.
Per la posizione e lo stato di standardizzazione di questo protocollo si
faccia riferimento all’edizione corrente dello “IAB Official Protocol
Standards”. La distribuzione di questo documento non e’ soggetta a
limitazioni.

Il protocollo IRC e’ stato sviluppato negli ultimi 4 anni da quando
fu implementato per la prima volta come mezzo in grado di permettere
agli utenti di una BBS di chattare tra loro. Oggi esso supporta una rete
mondiale di client e server, che sta sempre crescendo per far fronte alle
nuove esigenze. Negli ultimi 2 anni la media degli utenti connessi alla rete
IRC principale e’ cresciuta con fattore 1:10.

Il protocollo IRC e’ un protocollo basato su testo, nel quale il client piu’
semplice puo’ essere qualsiasi programma capace di connettersi al server.

Tavola dei contenuti

1. INTRODUZIONE ............................................... 4
1.1 Servers ................................................ 4
1.2 Clients ................................................ 5
1.2.1 Operatori .......................................... 5
1.3 Canali .................................................. 5
1.3.1 Operatori di canale .................................. 6
2. SPECIFICHE IRC .............................................. 7
2.1 Generalita’ ............................................. 7
2.2 Codici dei caratteri .................................... 7
2.3 Messaggi ................................................ 7
2.3.1 Formato dei messaggi in 'pseudo' BNF .............. 8
2.4 Risposte numeriche ...................................... 10
3. CONCETTI IRC ................................................ 10
3.1 Comunicazione uno-a-uno ................................. 10
3.2 Uno-a-molti ............................................. 11
3.2.1 Ad una lista ....................................... 11
3.2.2 Ad un gruppo (canale) .............................. 11
3.2.3 Ad un host/server mask ............................. 12
3.3 Uno-a-tutti ............................................. 12

Oikarinen & Reed [Page 1]

RFC 1459 Internet Relay Chat Protocol May 1993

3.3.1 Client a client ...................................... 12
3.3.2 Clients a server ..................................... 12
3.3.3 Server a server ...................................... 12
4. DETTAGLI DEI MESSAGGI ......................................... 13
4.1 Registrazione della connessione ................. ......... 13
4.1.1 Messaggio Password ................................... 14
4.1.2 Messaggio Nickname ................................... 14
4.1.3 Messaggio User ....................................... 15
4.1.4 Messaggio Server ..................................... 16
4.1.5 Messaggio Oper ....................................... 17
4.1.6 Messaggio Quit ....................................... 17
4.1.7 Messaggio Server quit ................................ 18
4.2 Operazioni di canale ...................................... 19
4.2.1 Messaggio Join ....................................... 19
4.2.2 Messaggio Part ....................................... 20
4.2.3 Messaggio Mode ....................................... 21
4.2.3.1 Modi di canale .................................. 21
4.2.3.2 Modi dell’utente ................................ 22
4.2.4 Messaggio Topic ...................................... 23
4.2.5 Messaggio Names ...................................... 24
4.2.6 Messaggio List ....................................... 24
4.2.7 Messaggio Invite ..................................... 25
4.2.8 Messaggio Kick ....................................... 25
4.3 Richieste e comandi al server ............................. 26
4.3.1 Messaggio Version .................................... 26
4.3.2 Messaggio Stats ...................................... 27
4.3.3 Messaggio Links ...................................... 28
4.3.4 Messaggio Time ....................................... 29
4.3.5 Messaggio Connect .................................... 29
4.3.6 Messaggio Trace ...................................... 30
4.3.7 Messaggio Admin ...................................... 31
4.3.8 Messaggio Info ....................................... 31
4.4 Invio di messaggi ......................................... 32
4.4.1 Messaggi privati ..................................... 32
4.4.2 Messaggi di avviso ................................... 33
4.5 Richieste basate sull’utente .............................. 33
4.5.1 Richiesta Who ........................................ 33
4.5.2 Richiesta Whois ...................................... 34
4.5.3 Messaggio Whowas ..................................... 35
4.6 Messaggi vari ............................................. 35
4.6.1 Messaggio Kill ....................................... 36
4.6.2 Messaggio Ping ....................................... 37
4.6.3 Messaggio Pong ....................................... 37
4.6.4 Messaggio Error ...................................... 38
5. MESSAGGI OPZIONALI ............................................ 38
5.1 Messaggio Away ............................................ 38
5.2 Comando Rehash ............................................ 39
5.3 Comando Restart ........................................... 39

Oikarinen & Reed [Page 2]

RFC 1459 Internet Relay Chat Protocol May 1993

5.4 Messaggio Summon........................................... 40
5.5 Messaggio Users ........................................... 40
5.6 Comando Operwall .......................................... 41
5.7 Messaggio Userhost ........................................ 42
5.8 Messaggio Ison ............................................ 42
6. RISPOSTE ...................................................... 43
6.1 Risposte d’errore ......................................... 43
6.2 Risposte di comando ....................................... 48
6.3 Risposte numeriche riservate .............................. 56
7. AUTENTICAZIONE CLIENT E SERVER ................................ 56
8. IMPLEMENTAZIONE CORRENTE ...................................... 56
8.1 Protocollo di rete: TCP ................................... 57
8.1.1 Supporto per sockets Unix ............................ 57
8.2 Analisi dei comandi ....................................... 57
8.3 Recapito dei messaggi ..................................... 57
8.4 Connessione 'Liveness' .................................... 58
8.5 Stabilire una connessione client-server ................... 58
8.6 Stabilire una connessione server-server ................... 58
8.6.1 Scambio di informazioni di stato durante la connessione 59
8.7 Chiusura di connessioni client-server ..................... 59
8.8 Chiusura di connessioni server-server ..................... 59
8.9 Tracciare i cambi di nickname ............................. 60
8.10 Controllo del flood di clients ........................... 60
8.11 Consultazioni non-blocking ............................... 61
8.11.1 Consultazioni hostname (DNS) ........................ 61
8.11.2 Consultazioni username (Ident) ...................... 61
8.12 File di configurazione ................................... 61
8.12.1 Permettere ai clients di connettersi ................ 62
8.12.2 Operatori ........................................... 62
8.12.3 Permettere ai servers di connettersi ................ 62
8.12.4 Administrivia ....................................... 63
8.13 Appartenenza ai canali ................................... 63
9. PROBLEMI ATTUALI ............................................. 63
9.1 Scalabilita’ .............................................. 63
9.2 Etichette ................................................. 63
9.2.1 Nicknames ............................................ 63
9.2.2 Canali ............................................... 64
9.2.3 Servers .............................................. 64
9.3 Algoritmi ................................................. 64
10. ATTUALE SUPPORTO E DISPONIBILITA’ ............................ 64
11. CONSIDERAZIONI SULLA SICUREZZA ............................... 65
12. INDIRIZZI DEGLI AUTORI ....................................... 65

Oikarinen & Reed [Page 3]

RFC 1459 Internet Relay Chat Protocol May 1993

1. INTRODUZIONE

Il protocollo IRC (Internet Relay Chat) e’ stato disegnato, in diversi anni,
per costituire un sistema di conferenza basata su testo. Questo documento
descrive il protocollo IRC corrente.

Il protocollo IRC e’ stato sviluppato su sistemi che utilizzano il protocollo
di rete TCP/IP, sebbene non vi siano requisiti per i quali questa sia l’unica
sfera in cui il protocollo possa operare.

IRC in se’ e’ un sistema di teleconferenza il quale (attraverso l’uso del
modello client-server) ben si adatta a girare su macchine e modelli diversi.
Una tipica configurazione prevede un singolo processo (il server) che
costituisce un punto di connessione centrale per i client (o altri server),
che effettua la distribuzione/multiplexing dei messaggi richiesti e altre
funzioni.

Il server costituisce la spina dorsale di IRC, fornendo un punto di
connessione attraverso il quale i client possono parlare l’uno con l’altro,
nonche’ un punto di connessione per altri server, determinando cosi’ una rete
IRC. La sola configurazione di rete ammessa per gli IRC server e’ quella ad
albero [vedere Fig. 1], nella quale ciascun server funge da nodo centrale per
il resto della rete che vede.

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

[ Fig. 1. Formato di una rete di IRC servers ]

Oikarinen & Reed [Page 4]

RFC 1459 Internet Relay Chat Protocol May 1993

Un client e’ tutto cio’ che si connette ad un server e che non e’ un server a
sua volta. Ogni client si distingue da un altro mediante un nickname univoco
di lunghezza massima nove (9) caratteri. Si vedano le regole grammaticali del
protocollo per cio’ che puo’ e non puo’ essere usato in un nickname. In
aggiunta al nickname, tutti i server devono avere le seguenti informazioni su
ogni client: il nome reale dell’host su cui il client sta girando, lo
username del client su quell’host, ed il server al quale il client e’
connesso.

1.2.1 Operatori

Per mantenere un ragionevole ordine in una rete IRC, ad una speciale
categoria di clients (operatori) e’ permesso di effettuare funzioni di
mantenimento generale della rete. Sebbene il potere dato ad un operatore
possa essere considerato ‘pericoloso’, essi sono tuttavia necessari. Gli
operatori dovrebbero essere in grado di compiere operazioni di base sulla
rete come la disconnessione e riconnessione di server per ovviare a
prolungati malfunzionamenti di routing. A tale proposito, il protocollo
discusso nel presente da’ il permesso agli operatori di effettuare solo
alcune funzioni.
Vedere le sezioni 4.1.7 (SQUIT) e 4.3.5 (CONNECT).

Un piu’ controverso potere dato agli operatori e’ la possibilita’ di
rimuovere dalla rete un utente ‘con la forza’, ad esempio gli operatori sono
in grado di chiudere la connessione tra client e server. La giustificazione a
questo e’ materia delicata, dal momento che un suo abuso e’ sia distruttivo
che irritante. Per maggiori dettagli su questo genere di azione vedere la
sezione 4.6.1 (KILL).

Un canale e’ un gruppo di uno o piu’ client avente un nome, il quale
ricevera’ tutti I messaggi indirizzati a quel canale. Il canale viene creato
implicitamente quando il primo client vi si unisce, e cessa di esistere
quando l’ultimo client lo abbandona. Durante la sua esistenza, ciascun client
si puo’ riferire al canale usandone il nome.

I nomi dei canali sono stringhe (che iniziano con un carattere ‘&’ oppure
‘#’) di lunghezza massima 200 caratteri. Oltre l’obbligo che il primo
carattere sia una ‘&’ oppure un ‘#’, l’unica restrizione alla sua
nomenclatura e’ l’impossibilita’ di avere caratteri spazio (‘ ‘), control G
(^G oppure ASCII 7), e virgole (‘,’ le quali sono usate dal protocollo come
separatori degli elementi di una lista).

Vi sono due tipi di canali ammessi da questo protocollo. Uno e’ un canale
distribuito conosciuto da tutti i server connessi alla rete.

Oikarinen & Reed [Page 5]

RFC 1459 Internet Relay Chat Protocol May 1993

Tali canali sono marcati dal primo carattere del nome, ovvero una ‘#’. Il
secondo tipo sono canali in cui solamente i client connessi al server ove il
canale esiste si possono a lui unire. Questi sono contrassegnati dal primo
carattere ‘&’. Esistono inoltre diversi modi di canale mediante i quali e’
possibile alterare le caratteristiche di un singolo canale. Vedere la sezione
4.2.3 (comando MODE) per maggiori dettagli.

Per creare un nuovo canale o prendere parte ad un canale esistente, un utente
deve UNIRSI (JOIN) al canale. Se il canale, al momento della richiesta join,
non esiste esso viene creato, e l’utente che l’ha creato diventa operatore di
quel canale. Se il canale invece era gia’ esistente, il fatto che la
richiesta di JOIN al canale venga accettata o no dipende dagli attuali modi
del canale. Ad esempio, se un canale e’ a solo-invito (+i) e’ possibile
prenderne parte solo se si e’ invitati. Il protocollo prevede che un utente
possa unirsi a svariati canali contemporaneamente, seppure un limite di dieci
(10) canali e’ raccomandato sia per utenti esperti che novizi. Vedere la
sezione 8.13 per maggiori informazioni a proposito.

Se la rete IRC si spezza a causa di un split tra due servers, il canale su
ciascun lato dello split sara’ composto dai soli clients connessi ai servers
sul rispettivo lato dello split, e possibilmente cesseranno di esistere
dall’altra parte. Quando il problema viene ripristinato, i server che si
riconnettono si comunicano a vicenda chi vedono sul canale nonche’ i modi del
canale stesso. Se il canale esiste su entrambi i lati i JOINs e i MODEs sono
interpretati in maniera inclusiva di modo che entrambe le parti della nuova
connessione siano d’accordo su quali siano i clients nel canale e l’assetto
mode dello stesso.

1.3.1 Operatori di canale

Gli operatori di canale (“chop” o “chanop”) su un dato canale sono
considerati come i ‘proprietari’ di quel canale. In riconoscimento a questo
stato, gli operatori di canale sono dotati di alcuni poteri che li abilitano
a controllare e in un certo senso curare il loro canale. Come proprietari del
canale, agli operatori del canale non sono richieste motivazioni per le loro
azioni, tuttavia qualora queste siano antisociali o in qualche modo abusive,
e’ ragionevole chiedere l’intervento di un operatore IRC, oppure lasciare il
canale e andare in un altro, oppure formarne uno proprio.

I comandi che possono essere usati esclusivamente dagli operatori di canale
sono:

KICK - Butta fuori un client dal canale
MODE - Modifica i modi del canale
INVITE - Invita un client se il canale e’ a solo-invito (+i)
TOPIC - Cambia il topic del canale quando questo e’ con mode +t

Oikarinen & Reed [Page 6]

RFC 1459 Internet Relay Chat Protocol May 1993

Un operatore di canale viene identificato dal simbolo ‘@’ a seguito del suo
nickname ogni volta che esso e’ associato al canale (ad esempio in risposta
ai comandi NAMES, WHO o WHOIS).

2. SPECIFICHE IRC

2.1 Generalita’

Il protocollo qui descritto puo’ essere usato sia nelle connessioni server-
server che nelle client-server. Vi sono tuttavia maggiori restrizioni nelle
connessioni client (considerate poco attendibili) che i quelle server.

2.2 Codici dei caratteri

Non e’ specificato nessun set di caratteri particolare. Il protocollo si basa
su un set di codici composto da otto (8) bit, formando un ottetto. Ciascun
messaggio puo’ essere composto da un qualsiasi numero di questi ottetti; ad
ogni modo il valore di qualche ottetto viene usato come codici di controllo
che funzionano come delimitatori di messaggio.

Noncurante di essere un protocollo a 8-bit, i delimitatori e le parole chiave
sono tali da rendere il protocollo maggiormente utilizzabile nelle
connessioni tramite terminale USASCII e telnet.

Avendo IRC origini scandinave, i caratteri {}| sono considerati l’equivalente
minuscolo dei caratteri, rispettivamente, []. Questo e’ argomento critico
quando dev’essere determinata l’equivalenza tra due nicknames.

Servers e clients si inviano l’un l’altro messaggi, i quali possono generare
una risposta oppure no. Se il messaggio contiene un comando valido, come
descritto nelle sezioni che seguono, il client dovrebbe aspettare una
risposta come specificato, ma non e’ consigliato che la aspetti all’infinito;
la comunicazione client-server e server-server e’ essenzialmente asincrona
per natura.

Ciascun messaggio IRC puo’ essere costituito da 3 parti principali: il
prefisso (facoltativo), il comando e i parametri di comando (i quali possono
essere un massimo di 15). Il prefisso, il comando e tutti i parametri sono
separati da uno (o piu’) caratteri spazio ASCII (0x20).

La presenza del prefisso e’ indicata da un singolo carattere ASCII di testa
(‘:’, 0x3b), che dev’essere il primo carattere del messaggio stesso. Non vi
devono essere vuoti (spazi) tra i due punti ed il prefisso. Il prefisso e’
usato dai servers per indicare la vera origine del messaggio.

Oikarinen & Reed [Page 7]

RFC 1459 Internet Relay Chat Protocol May 1993

Se il prefisso manca, si ipotizza che il messaggio e’ stato originato dalla
connessione dalla quale esso e’ stato ricevuto. I clients non dovrebbero
usare prefissi quando inviano un messaggio da loro stessi; se lo fanno,
l’unico prefisso valido e’ il nickname registrato associato al client. Se
l’origine identificata dal prefisso non puo’ essere trovata nel database
interno del server, o se questa e’ registrata da un collegamento diverso da
quello mediante il quale il messaggio e’ arrivato, il server deve ignorare
tacitamente il messaggio.

Il comando deve essere un comando IRC valido, oppure in numero di tre (3)
cifre rappresentato in testo ASCII.

I messaggi IRC sono sempre linee di caratteri che terminano con una coppia
CR-LF (Carriage Return - Line Feed –> Ritorno a capo), e tali messaggi non
possono eccedere i 512 caratteri in lunghezza, in cui si considerano tutti i
caratteri incluso il CR-LF. In questo modo rimangono 510 caratteri per il
comando ed i suoi parametri. Non vi sono misure per la continuazione delle
linee del messaggio. Vedere la sezione 7 per maggiori dettagli sulle
implementazioni attuali.

2.3.1 Formato dei messaggi in 'pseudo' BNF

I messaggi del protocollo devono essere estratti dal flusso contiguo degli
ottetti. La soluzione corrente consiste nel designare due caratteri, CR e LF,
come separatori di messaggio. I messaggi nulli vengono tacitamente ignorati e
questo permette l’uso della sequenza CR-LF tra i messaggi senza ulteriori
problemi.

Il messaggio estratto viene analizzato nelle sue componenti ,
e lista di parametri collegati tra loro dalle componenti
o

La rappresentazione BNF a questo e’ la seguente:

::= [':' ]
::= | [ '!' ] [ '@' ]
::= { } |
::= ' ' { ' ' }
::= [ ':' | ]

Oikarinen & Reed [Page 8]

RFC 1459 Internet Relay Chat Protocol May 1993

1) consiste solamente nel carattere(i) SPAZIO (0x20).
Da notare con rilievo che le TABULAZIONI e tutti i caratteri di
controllo NON sono considerate SPAZI vuoti.

2) Una volta estratta la lista di parametri, tutti i parametri sono
equivalenti, indipendentemente dalla marcatura o . e’
solamente un trucco sintattico per permettere SPAZI nei parametri.

3) Il fatto che i CR e LF non possano apparire nelle stringhe dei parametri
e’ solo dipendente dalla modalita’ di delimitazione dei messaggi. Questo
potrebbe cambiare in futuro.

4) Il carattere NUL non ha significato speciale nella delimitazione dei
messaggi, e fondamentalmente potrebbe essere inserito in un parametro,
tuttavia questo potrebbe causare ulteriori complessita’ nella normale
gestione delle stringhe in C. Per tale motivo il suo inserimento nei
messaggi non e’ consentito.

5) L’ultimo parametro puo’ essere una stringa vuota.

6) L’uso di prefissi estesi (['!' ] ['@' ]) non deve essere
usato nelle connessioni server-server ed e’ stato progettato solo per la
comunicazione server-client in modo da fornire ai clients maggiori
informazioni utili sulla provenienza di un messaggio senza che debba
fare ulteriori richieste.

La maggior parte dei messaggi del protocollo specifica semantica e sintassi
addizionali per le stringhe dei parametri estratti, dovute dalla loro
posizione nella lista. Per esempio, molti comandi dei server assumono che il
primo parametro dopo il comando e' una lista di obbiettivi, che puo’ essere
cosi’ descritta:

::= [ "," < obiettivo > ]
::= | '@' | |
::= ('#' | '&')
::=
::= si veda l’RFC 952 [DNS:4] per dettagli sugli hostnames
consentiti
::= { | | }
::= ('#' | '$')
::=

Altri parametri sintattici sono:

::= { }
::= 'a' ... 'z' | 'A' ... 'Z'
::= '0' ... '9'
::= '-' | '[' | ']' | '' | '`' | '^' | '{' | '}'

Oikarinen & Reed [Page 9]

RFC 1459 Internet Relay Chat Protocol May 1993

2.4 Risposte numeriche

La maggior parte dei messaggi inviati al server genera una risposta di
qualche genere. Le risposte piu’ comuni sono quelle numeriche, usate sia per
errori che per normali risposte. Le risposte numeriche devono essere inviate
come un messaggio costituito dal prefisso del mittente, le tre cifre
numeriche, e la destinazione della risposta. Una risposta numerica non puo’
essere originata da un client; qualsiasi messaggio del genere verra’
tacitamente ignorato dal server. In ogni altro aspetto, una risposta numerica
e’ in tutto e per tutto simile ad un normale messaggio, se si esclude il
fatto che la parola-chiave sono le tre cifre numeriche e non una stringa di
lettere. Una lista delle svariate risposte e’ riportata nella sezione 6.

3. CONCETTI DI IRC

Questa sezione si occupa di descrivere gli attuali concetti
dell’organizzazione del protocollo di IRC e di come le attuali
implementazioni inoltrino le diverse categorie dei messaggi.

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

Servers: A, B, C, D, E Clients: 1, 2, 3, 4

[ Fig. 2. Esempio di una piccola rete IRC ]

3.1 Comunicazione uno-a-uno

La comunicazione su base uno-a-uno e’ generalmente effettuata dai clients,
dal momento che la maggior parte del traffico server-server non e’ il
risultato dell’esclusivo dialogo reciproco tra i servers. Per fornire ai
client una strada sicura al loro reciproco dialogo e’ necessario che ciascun
server sia in grado di inviare un messaggio nell’unica direzione esatta a
raggiungere un qualsiasi client lungo la struttura ad albero della rete. Il
percorso del messaggio determinato e’ quello piu’ breve tra qualsiasi due
punti dell’albero stesso.

Gli esempi che seguono fanno tutti riferimento alla Figura 2 sopra.

Oikarinen & Reed [Page 10]

RFC 1459 Internet Relay Chat Protocol May 1993

Esempio 1:
Un messaggio tra i clients 1 e 2 e’ visto solamente dal server A, che lo
invia direttamente al client 2.

Esempio 2:
Un messaggio tra I clients 1 e 3 e’ visto dai servers A & B, e il client 3.
Nessun altro client o server vede il messaggio.

Esempio 3:
Un messaggio tra I clients 2 e 4 e’ visto dai servers A, B, C & D, e
solamente dal client 4.

3.2 Uno-a-molti

L’obiettivo primario di IRC e’ fornire un forum nel quale sia possibile fare
conferenza in maniera facile ed efficiente (conversazione uno a molti). IRC
mette a disposizione diverse strade a questo proposito, ognuna col proprio
obiettivo.

3.2.1 Ad una lista

Il metodo meno efficiente di una conversazione uno-a-molti e’ un client che
parla ad una ‘lista’ di utenti. Come questo avviene si spiega da solo: il
client fornisce una lista di destinazioni alla quale il messaggio dev’essere
recapitato ed il server invia copie separate dello stesso a ciascuna
destinazione data. Questo metodo non e’ efficiente come quello ad-un-gruppo
poiche’ la lista di destinazioni viene spezzata (N.d.T. – dal server per
determinare ogni singola destinazione) e non viene fatto alcun controllo di
invio di messaggi doppi lungo ciascun percorso.

3.2.2 Ad un gruppo (canale)

In IRC il canale ha un ruolo equivalente a quello del gruppo multicast; la
loro esistenza e’ dinamica (viene e va a seconda che gli utenti si uniscano o
abbandonino il canale) e la conversazione in corso su un canale e’ inviata
solamente ai servers che stanno sostenendo gli utenti sul quel canale. Se vi
sono piu’ utenti dello stesso canale sullo stesso server, il messaggio viene
inviato al server una sola volta, e spedito poi a ciascun client del canale.
Quest’operazione e’ poi ripetuta per ciascuna combinazione client-server fino
a che il messaggio originale non abbia raggiunto ciascun membro del canale.

Gli esempi che seguono sono tutti riferiti alla Figura 2.

Esempio 4:
Un qualsiasi canale con 1 solo client presente. I messaggi al canale vanno
al server e da nessun’altra parte.

Oikarinen & Reed [Page 11]

RFC 1459 Internet Relay Chat Protocol May 1993

Esempio 5:
Due clients su un canale. Tutti i messaggi seguono un percorso come se
fossero messaggi privati tra i due clients esterni al canale.

Esempio 6:
Client 1, 2 e 3 su un canale. Tutti i messaggi al canale sono inviati a
tutti i clients e solo a quei servers che devono essere attraversati dal
messaggio se questo e’ privato verso un singolo client. Se il client 1
invia un messaggio, questo raggiunge il client 2 e, via server B, al
client 3.

3.2.3 Ad uno schema host/server

Per permettere agli operatori IRC di inviare messaggi ad un grande numero di
utenti, sono previsti messaggi con schema host e server. Tali messaggi
vengono spediti a quegli utenti le cui informazioni host o server
corrispondono a quelle dello schema. I messaggi vengono trasmessi solamente
alle posizioni in cui si trovano gli utenti, in maniera simile al modo usato
per i canali.

3.3 Uno-a-tutti

Il tipo di messaggio uno-a-tutti e’ meglio descrivibile come un messaggio
broadcast, inviato a tutti i clients o servers o entrambi. In un’estesa rete
di clients e servers, un singolo messaggio puo’ produrre un notevole traffico
per far si’ che possa raggiungere tutte le destinazioni desiderate.

Per taluni messaggi non vi e’ altra possibilita’ che inviarli a tutti i
servers in modo che le informazioni di stato di ciascun server siano
ragionevolmente coerenti tra loro.

3.3.1 Client-a-client

Non vi sono tipologie di messaggio per cui un singolo messaggio venga inviato
a tutti gli altri client.

3.3.2 Client-a-server

La maggior parte dei comandi che risultano in uno scambio di informazioni di
stato (come membri del canale, modi del canale, stato dell’utente, ecc.)
dev’essere inviata per default a tutti i servers, e tale operazione non puo’
essere modificata dal client.

3.3.3 Server-a-server

Benche’ la maggior parte dei messaggi tra i servers e’ distribuita a tutti
gli ‘altri’ servers, questo e’ richiesto solamente per quei messaggi che
incidono su un utente, un canale od un server. Dal momento che questi sono

Oikarinen & Reed [Page 12]

RFC 1459 Internet Relay Chat Protocol May 1993

gli elementi fondamentali di IRC, quasi tutti i messaggi originati da un
server vengono inoltrati a tutti gli altri servers connessi.

4. DETTAGLI DEI MESSAGGI

Nelle pagine che seguono viene descritto ciascun messaggio riconosciuto da un
client e server IRC. Tutti i comandi descritti in questa sezione devono
essere implementati su ogni server per questo protocollo.

Dove si riporta una risposta ERR_NOSUCHSERVER significa che il parametro
non puo’ essere trovato. Oltre a questa, il server non deve tornare
alcun’altra risposta per quel comando.

Al server al quale un client e’ connesso viene richiesto di analizzare
l’intero messaggio e di ritornare ogni errore appropriato. Se il server,
durante tale analisi, incontra un errore fatale dev’essere tornato un errore
al client e interrotta l’analisi. Errore fatale puo’ essere considerato un
comando non corretto, una destinazione in qualche modo sconosciuta al server
(nome del canale, nick o server rientrano in questa categoria), parametri
insufficienti o privilegi non corretti.

Se viene presentato un intero set di parametri, ciascuno di essi dev’essere
verificato per validita’, e dev’essere tornata una risposta appropriata al
client. Nel caso di messaggi che utilizzano liste di parametri i cui elementi
sono separati da virgole, dev’essere inviata una risposta per ciascun
elemento.

Negli esempi che seguono alcuni messaggi utilizzano il formato pieno:

:Nome COMANDO lista di parametri

Tali esempi rappresentano un messaggio inviato da “Nome” in transito tra
servers, dove e’ essenziale includere il nome del mittente originale del
messaggio in modo che i servers remoti possano tornare una risposta lungo il
percorso corretto.

4.1 Registrazione della connessione

I messaggi qui descritti vengono usati per registrare una connessione con un
server IRC e per effettuare una corretta disconnessione, sia come utente che
come server.

Un comando “PASS” non e’ necessario affinche’ la connessione di un client o
di un server sia registrata ma, se ci fosse, deve precedere il messaggio del
server o l’ultima combinazione NICK/USER. E’ fortemente raccomandato che
tutte le connessioni server abbiano una password, in modo da aumentare il
livello di sicurezza delle attuali connessioni. L’ordine raccomandato per la
registrazione di un client e’ quello che segue:

Oikarinen & Reed [Page 13]

RFC 1459 Internet Relay Chat Protocol May 1993

1. Messaggio Pass
2. Messaggio Nick
3. Messaggio User

4.1.1 Messaggio Password

Comando: PASS
Parametri:

Il comando PASS e’ usato per impostare una ‘password di connessione’. La
password puo’ e deve essere settata prima che sia fatto qualsiasi tentativo
di connessione. Attualmente questo implica che i clients inviino un comando
PASS prima dell’invio della combinazione NICK/USER, mentre i servers *devono*
inviare un comando PASS prima di qualsiasi comando SERVER. La password
fornita deve corrispondere all’unica presente nelle linee C/N (per i servers)
o I (per i clients) E’ possibile inviare comandi PASS multipli prima della
registrazione seppure solamente l’ultimo e’ quello usato per la verifica, e
non puo’ essere modificato una volta registrati.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

PASS passwordsegreta

4.1.2 Messaggio Nick

Comando: NICK
Parametri: [ ]

Il messaggio NICK e’ usato per dare all’utente un nickname o per modificare
quello esistente. Il parametro viene usato solamente dai servers
per indicare quanto e’ lontano un nick dal suo server principale. Una
connessione locale ha un hopcount di 0. Se fornito da un client dev’essere
ignorato.

Se un messaggio NICK arriva ad un server che e’ gia’ a conoscenza di un
identico nickname per un altro client, si verifica una collisione di
nickname. Il risultato e’ la rimozione di tutte le istanze del nickname dal
database del server, e l’invio di un comando KILL per rimuovere il nickname
dai database di tutti gli altri servers. Se il messaggio NICK che determina
la collisione e’ un cambio di nickname, il nick originale (vecchio)
dev’essere rimosso.

Se il server riceve un identico NICK da un client a lui direttamente
connesso, puo’ tornare un ERR_NICKCOLLISION al client locale, droppare il
comando NICK e non generare alcun kill.

Oikarinen & Reed [Page 14]

RFC 1459 Internet Relay Chat Protocol May 1993

Risposte numeriche:

ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION

NICK Wiz ; Presenta il nuovo nick "Wiz".

:WiZ NICK Kilroy ; WiZ cambia il suo nickname in Kilroy.

4.1.3 Messaggio User

Comando: USER
Parametri:

Il messaggio USER viene usato all’inizio della connessione per specificare il
nome utente, il nome macchina, il nome server ed il nome reale del nuovo
utente. E’ anche usato nelle comunicazioni tra servers per indicare l’arrivo
su IRC di un nuovo utente, poiche’ solamente dopo che i comandi USER e NICK
sono stati ricevuti da un client un utente diviene registrato.

Tra servers USER dev’essere preceduto dal NICKname del client. Si noti che il
nome macchina e il nome server sono generalmente ignorati dal server IRC
qualora il comando USER provenga da un client a lui direttamente connesso
(per motivi di sicurezza), ma vengono invece usati nelle comunicazioni server
a server. Questo significa che un NICK dev’essere sempre inviato ad un server
remoto quando un nuovo utente viene presentato al resto della rete prima che
sia inviato lo USER.

Si noti inoltre che il parametro nome reale dev’essere l’ultimo parametro
poiche’ puo’ contenere caratteri spazio, e dev’essere preceduto da un ‘due
punti’ (‘:’) per assicurarsi che sia riconosciuto.

Dal momento che per un client e’ facile mentire sul suo nome utente mediante
il semplice uso del messaggio USER, e’ raccomandato l’uso di un “Identify
Server”. Se l’host dal quale l’utente si connette ha un server abilitato a
questo proposito, il nome utente impostato e’ quello in risposta
dall’”Identify Server”.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

USER guest tolmoon tolsun :Ronnie Reagan

Oikarinen & Reed [Page 15]

RFC 1459 Internet Relay Chat Protocol May 1993

; L’utente si registra col nome utente
"guest" ed il nome reale "Ronnie Reagan".

:testnick USER guest tolmoon tolsun :Ronnie Reagan
; messaggio tra servers per il nickname al
quale appartiene il comando USER.

4.1.4 Messaggio Server

Comando: SERVER
Parametri:

Il messaggio server e’ usato per dire ad un server che l’altro capo di una
nuova connessione e’ un server. Questo messaggio e’ anche usato per passare i
dati di un server all’intera rete. Quando un nuovo server si connette alla
rete, le informazioni su di lui vengono distribuite all’intera rete.
viene utilizzato per dare a tutti i servers informazioni interne
sulle distanze di tutti i servers. Con un elenco completo di servers sarebbe
possibile ricostruire una mappa dell’intero albero di server, tuttavia schemi
di hosts impediscono che questo sia fatto.

Il messaggio SERVER dev’essere accettato solamente da (a) una connessione non
ancora registrata che sta tentando di registrarsi come server, oppure (b) una
connessione esistente ad un altro server, nel qual caso il messaggio SERVER
presenta un nuovo server a lui dietro.

La maggior parte degli errori che si verificano con il ricevimento di un
comando SERVER determinano la chiusura della connessione dall’host di
destinazione (target SERVER). Le risposte d’errore sono normalmente inviate
tramite il comando “ERROR” piuttosto che l’uso delle numeriche, poiche’ il
comando ERROR ha diverse funzioni utili che lo rendono in questo caso piu’
indicato.

Se un messaggio SERVER viene analizzato e tenta di presentare un server gia’
conosciuto al server ricevente, la connessione da cui proviene il messaggio
dev’essere cessata (secondo le corrette procedure), poiche’ si viene a
formato un duplicato di percorso ad un server e la natura aciclica
dell’albero di IRC si spezzerebbe.

Risposte numeriche:

ERR_ALREADYREGISTRED

Oikarinen & Reed [Page 16]

RFC 1459 Internet Relay Chat Protocol May 1993

SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
; Il nuovo server test.oulu.fi si presenta e
tenta di registrarsi. Il nome tra [] e’ il nome
della macchina su cui gira test.oulu.fi

:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
; Il server tolsun.oulu.fi e’ il nostro
collegamento per csd.bu.edu che si trova
distante 5 hops.

4.1.5 Messaggio Oper

Comando: OPER
Parametri:

Il messaggio OPER e’ usato da un normale utente per ottenere i privilegi di
operatore. La combinazione di e e’ necessaria.

Se il client che invia il comando OPER fornisce la corretta password per il
relativo utente, il server informa il resto della rete del nuovo operatore
emettendo un “MODE +o” per il nickname del client.

Il messaggio OPER e’ esclusivamente client-server.

Risposte numeriche:

ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH

OPER foo bar ; Tentativo di registrazione come operatore
mediante l’uso di “foo” come utente e “bar”
come password.

4.1.6 Messaggio Quit

Comando: QUIT
Parametri: []

Una sessione client viene chiusa con un messaggio quit. Il server deve
chiudere la connessione al client che invia un messaggio QUIT. Se un
“Messaggio di uscita” viene specificato, questo sara’ inviato al posto del
messaggio di default, il nickname.

Quando avviene uno split (disconnessione di due server), il messaggio quit

Oikarinen & Reed [Page 17]

RFC 1459 Internet Relay Chat Protocol May 1993

E’ composto dai nomi dei due server interessati, separati da uno spazio. Il
primo nome e’ quello del server ancora connesso e il secondo e’ quello del
server che si e’ disconnesso.

Se per qualche ragione una connessione client e’ chiusa senza che il client
invii un comando QUIT (ad esempio il client si blocca e avviene un EOF sul
socket) al server e’ richiesto di riempire il messaggio di uscita con un
messaggio che rifletta in qualche modo la natura dell’evento che ha causato
quanto successo.

Risposte numeriche:

QUIT : Vado a pranzo ; Formato del messaggio preferito

4.1.7 Messaggio SQUIT

Comando: SQUIT
Parametri:

Il messaggio SQUIT e’ necessario per informare dell’uscita di un server. Se
un server desidera interrompere la connessione con un altro server deve
mandare un messaggio SQUIT all’altro server, usando il nome dell’altro server
come parametro server, il quale chiudera’ la connessione con il server
uscente.

Questo comando e’ anche disponibile agli operatori per aiutare a mantenere
connessi in maniera ordinata una rete di servers IRC. Gli operatori possono
inoltre usare un messaggio SQUIT per una connessione ad un server remoto. In
questo caso, lo SQUIT dev’essere analizzato da ciascun server presente tra
l’operatore ed il server remoto, aggiornando la vista della rete mantenuta da
ogni server, come spiegato in seguito.

Il dovrebbe essere disposto da tutti gli operatori che eseguono
uno SQUIR per un server remoto (che non e’ connesso al server su cui sono
loro attualmente) in modo che gli altri operatori siano informati sulle
ragioni di questa operazione. Il e’ anche fornito dai servers che
possono mettervi un errore o messaggi analoghi.

Ad entrambi i servers che si trovano su ciascun lato della connessione che
viene chiusa e’ richiesto di inviare un messaggio SQUIT (a tutte le altre
loro connessioni server) per tutti i server che sono dietro quella
connessione.

Oikarinen & Reed [Page 18]

RFC 1459 Internet Relay Chat Protocol May 1993

In maniera simile, un messaggio QUIT dev’essere inviato a tutti gli altri
servers connessi al resto della rete negli interessi di tutti i clients
dietro quella connessione. Oltre a questo, a tutti i membri di un canale che
ha perso un membro a causa dello split dev’essere inviato un messaggio QUIT.

Se una connessione server termina prematuramente (ad esempio il server
sull’altro lato del collegamento cessa di esistere) il server che rileva
questa disconnessione deve informare il resto della rete che la connessione
e’ chiusa e riempire il campo commento con qualcosa di appropriato.

Risposte numeriche:

ERR_NOPRIVILEGES ERR_NOSUCHSERVER

SQUIT tolsun.oulu.fi :Bad Link ?
; il collegamento server tolson.oulu.fi
e’ terminato a causa di "Bad Link".

:Trillian SQUIT cm22.eng.umd.edu :Server out of control
; messaggio da Trillian per disconnettere
"cm22.eng.umd.edu" dalla rete
perche’ "Server out of control".

4.2 Operazioni sul canale

Questo gruppo di messaggi riguarda la manipolazione sui canali, le loro
proprieta’ (modi di canale) ed i loro contenuti (normalmente clients). Per la
loro implementazione sono inevitabili un certo numero di condizioni quando
clients sugli opposti della rete invino comandi che potrebbero andare in
conflitto. E’ inoltre necessario che i servers mantengano una cronologia dei
nickname per assicurare che laddove viene dato un parametro il server
verifichi la sua cronologia in caso sia stato cambiato recentemente.

4.2.1 Messaggio Join

Comando: JOIN
Parametri: {,} [{,}]

The JOIN command is used by client to start listening a specific
channel. Whether or not a client is allowed to join a channel is
checked only by the server the client is connected to; all other
servers automatically add the user to the channel when it is received
from other servers. The conditions which affect this are as follows:

Il comando JOIN e’ utilizzato da un client per unirsi ad uno specifico canale.
Il fatto che al client sia concesso l’unione al canale o meno e’ una verifica
eseguita dal server al quale il client e’ connesso; tutti gli altri servers
aggiungono automaticamente l’utente al canale quando questo e’ notificato
da altri servers. Le condizioni vincolanti sono le seguenti:

1. l’utente dev’essere invitato se il canale e’ a solo-invito;

Oikarinen & Reed [Page 19]

RFC 1459 Internet Relay Chat Protocol May 1993

2. il nick/nome utente/nome macchina dell’utente non deve
corrispondere ad un ban attivo;

3. dev’essere data la chiave corretta (password) se impostata.

Maggiori dettagli in proposito sono discussi nel comando MODE (vedere la
sezione 4.2.3 per maggiori informazioni).

Una volta che un utente si e’ unito ad un canale riceve notizia di tutti i
comandi che il suo server riceve riguardo il canale. Questo include MODE,
KICK, PART, QUIT e, chiaramente, PRIVMSG/NOTICE. Il comando JOIN necessita
che sia notificato a tutti i servers di modo che ciascuno di essi sappia dove
reperire gli utenti che sono su un canale. Questo permette una distribuzione
ottimale dei messaggi PRIVMSG/NOTICE al canale.

Se un JOIN ha successo all’utente viene inviato il topic (argomento) del
canale (per mezzo di RPL_TOPIC) e l’elenco degli utenti che sono su quel
canale (per mezzo di RPL_NAMEREPLY), il quale include anche l’utente stesso.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC

JOIN #foobar ; unione al canale #foobar.

JOIN &foo fubar ; unione al canale &foo usando la chiave
"fubar".

JOIN #foo,&bar fubar ; unione al canale #foo usando la chiave
"fubar" ed al canale &bar senza usare chiave.

JOIN #foo,#bar fubar,foobar ; unione al canale #foo usando la chiave
"fubar" ed al canale #bar usando la chiave
"foobar".

JOIN #foo,#bar ; unione ai canali #foo e #bar.

:WiZ JOIN #Twilight_zone ; Messaggio JOIN da WiZ

4.2.2 Messaggio Part

Comando: PART
Parametri: {,}

Oikarinen & Reed [Page 20]

RFC 1459 Internet Relay Chat Protocol May 1993

Il messaggio PART determina la rimozione del client mittente dalla lista
degli utenti attivi per tutti i canali dati nella stringa di parametro.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL

PART #twilight_zone ; abbandono del canale "#twilight_zone"

PART #oz-ops,&group5 ; abbandono dei canali "&group5" e
"#oz-ops".

4.2.3 Messaggio Mode

Il comando MODE e’ un comando con doppia funzione in IRC. Esso permette sia
agli utenti che ai canali di modificare i loro modi. La ragione di questa
scelta e’ che un giorno i nicknames saranno obsoleti e il loro equivalente
saranno i canali.

Quando vengono analizzati messaggi MODE e’ raccomandato che sia prima
analizzato l’intero messaggio e poi che avvengano i cambiamenti che risultano
da esso.

4.2.3.1 Modi di canale

Parametri: {[+|-]|o|p|s|i|t|n|b|v} [] []
[]

Il comando MODE esiste in modo che gli operatori di canale possano modificare
le caratteristiche del ‘loro’ canale. E’ anche richiesto che siano in grado
di farlo i servers in modo che gli operatori di canale possano essere creati.

I vari modi di canale disponibili sono i seguenti (N.d.T. – alcuni di questi
flags sono cambiati nelle implementazioni attuali):

o – da’/toglie i privilegi di operatore di canale;
p – flag di canale privato;
s – flag di canale segreto;
i – flag di canale a solo-invito;
t – flag di canale il cui topic e’ impostabile esclusivamente dagli
operatori di canale;
n – nessun messaggio al canale da clients esterni;
m – canale moderato;
l – imposta il numero massimo di utenti sul canale;

Oikarinen & Reed [Page 21]

RFC 1459 Internet Relay Chat Protocol May 1993

b – imposta uno schema di ban per tener fuori degli utenti;
v – da’/toglie la parola in un canale moderato;
k – imposta una chiave di canale (password).

Quando si utilizzano le opzioni ‘o’ e ‘b’ e’ imposta una restrizione di 3 per
Mode (N.d.T. – ogni combinazione puo’ contenere max 3 elementi).

4.2.3.2 Modi dell’utente

Parametri: {[+|-]|i|w|s|o}

I MODE dell’utente sono normalmente delle impostazioni che riguardano come il
client e’ visto dagli altri o quali messaggi ‘extra’ invia. Un comando MODE
utente puo’ essere accettato solo se il mittente del messaggio ed il nickname
dato come parametro sono gli stessi.

I modi disponibili sono i seguenti (N.d.T. - anche qui alcuni di questi flags
sono cambiati nelle implementazioni attuali):

i – imposta invisibile un utente;
s – abilita un utente a ricevere informazioni dal server;
w – l’utente riceve i wallops;
o – flag dell’operatore.

Modi aggiuntivi potranno essere disponibili in futuro.

Se un utente cerca di rendersi operatore mediante l’uso del flag ‘+o’ il
tentativo dovrebbe essere ignorato. Non vi sono tuttavia restrizione
affinche’ chiunque si ‘deoppi’ (usando “-o”).

Risposte numeriche:

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

Uso dei mode di canale:

MODE #Finnish +im ; Rende #Finnish un canale moderato e a solo-
invito.

MODE #Finnish +o Kilroy ; Da’ I privilegi di 'chanop' a Kilroy sul

Oikarinen & Reed [Page 22]

RFC 1459 Internet Relay Chat Protocol May 1993

canale #Finnish.

MODE #Finnish +v Wiz ; Consente a Wiz di parlare #Finnish.

MODE #Fins -s ; Rimuove il flag ‘segreto’ dal canale #Fins.

MODE #42 +k oulu ; Imposta come chiave di canale "oulu".

MODE #eu-opers +l 10 ; Imposta 10 come numero massimo di utenti del
canale.

MODE &oulu +b ; elenca gli schemi di ban del canale.

MODE &oulu +b *!*@* ; impedisce l’unione a tutti gli utenti.

MODE &oulu +b *!*@*.edu ; impedisce l’unione a qualsiasi utente il cui
nome macchina corrisponda allo schema *.edu.

Uso dei mode dell’utente:

:MODE WiZ -w ; toglie l’abilitazione a ricevere messaggi
WALLOPS a WiZ.

:Angel MODE Angel +i ; Messaggio da Angel per rendersi invisibile.

MODE WiZ -o ; WiZ si ‘deoppa’ (si rimuove lo stato di
operatore). L’inverso a quest’azione (“MODE WiZ
+o”) non e’ permessa agli utenti poiche’
bypasserebbero il comando OPER.

4.2.4 Messaggio Topic

Comando: TOPIC
Parametri: []

Il messaggio TOPIC e’ usato per modificare o vedere il topic (argomento) di
un canale. Il topic del canale viene ritornato qualora non sia
passato alcun parametro . Se l’ e’ presente il topic di
quel canale verra’ modificato, se i modi del canale consentono tale azione.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED

Oikarinen & Reed [Page 23]

RFC 1459 Internet Relay Chat Protocol May 1993

:Wiz TOPIC #test :New topic ; L’utente Wiz imposta il topic.

TOPIC #test :another topic ; imposta il topic su #test come
"another topic".

TOPIC #test ; visualizza il topic di #test.

4.2.5 Messaggio Names

Comando: NAMES
Parametri: [{,}]

Usando il comando NAMES un utente puo’ listare tutti i nicknames a lui
visibili su ciascun canale che puo’ vedere. I canali che puo’ vedere sono
quelli non privati (+p) o segreti (+s) oppure quelli su cui e’ in quel
momento. Il parametro specifica quale canale(i) deve tornare
informazioni se valido. Non vi sono risposte d’errore per nomi errati di
canale.

Se non viene dato alcun parametro viene tornata una lista di tutti i
canali e dei relativi membri. Alla fine di tale lista viene riportato
l’elenco degli utenti che sono visibili ma non sono su alcun canale o sono su
un canale non visibile, i quali sono contrassegnati come se fossero sul
‘canale’ “*”.

Risposte numeriche:

RPL_NAMREPLY RPL_ENDOFNAMES

NAMES #twilight_zone,#42
; elenco degli utenti visibili sui canali
#twilight_zone e #42 se i canali sono
visibili al mittente del messaggio.

NAMES ; list all visible channels and users

4.2.6 Messaggio List

Comando: LIST
Parametri: [{,} []]

Il messaggio list viene usato per elencare i canali ed i loro topic. Se viene
usato il parametro verra’ visualizzato solamente lo stato di quel
canale. I canali privati sono elencati (senza topic) come canali “Prv” a meno
che il client che genera la richiesta non ne faccia parte. Allo stesso modo,
i canali segreti non sono listati a meno che il client non sia membro del

Oikarinen & Reed [Page 24]

RFC 1459 Internet Relay Chat Protocol May 1993

canale in questione.

Risposte numeriche:

ERR_NOSUCHSERVER RPL_LISTSTART
RPL_LIST RPL_LISTEND

LIST ; Elenca tutti i canali.

LIST #twilight_zone,#42 ; Elenca i canali #twilight_zone e #42

4.2.7 Messaggio Invite

Comando: INVITE
Parametri:

Il messaggio INVITE e’ usato per invitare un utente su un canale. Il
parametro e’ il nickname della persona da invitare sul canale
. Non vi e’ la necessita’ che il canale sul quale si invita l’utente
esista o sia un canale valido. Per invitare un utente su un canale a solo-
invito (MODE +i) il client mittente dev’essere riconosciuto come operatore di
canale per il canale dato.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAY

:Angel INVITE Wiz #Dust
; L’utente Angel invita WiZ sul canale
#Dust

INVITE Wiz #Twilight_Zone
; Comando per invitare WiZ su #Twilight_zone

4.2.8 Comando Kick

Comando: KICK
Parametri: []

Il comando KICK puo’ essere usato per rimuovere forzatamente un utente da un
canale. Esso ‘lo calcia fuori’ dal canale (PART forzato).

Oikarinen & Reed [Page 25]

RFC 1459 Internet Relay Chat Protocol May 1993

Solo un operatore di canale puo’ kickare un altro utente. Ciascun server che
riceve un messaggio KICK verifica che sia valido (ad esempio che il mittente
sia al momento un operatore di canale) prima di rimuovere la vittima dal
canale.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL

ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_NOTONCHANNEL

KICK &Melbourne Matthew
; Calcia fuori Matthew da &Melbourne

KICK #Finnish John :Speaking English
; Calcia fuori John da #Finnish dando
"Speaking English" come motivazione
(commento).

:WiZ KICK #Finnish John
; Messaggio KICK da WiZ per rimuovere John
dal canale #Finnish

NOTA:
E’ possibile estendere i parametri del comando KICK come segue:

4.3 Comandi e richieste al server

Il gruppo di comandi di richiesta al server e’ stato progettato per tornare
informazioni su qualsiasi server connesso alla rete. Tutti i servers connessi
devono rispondere a queste richieste e farlo in maniera corretta. Qualsiasi
risposta non valida (o mancante) dev’essere considerata un segnale di server
malfunzionante e questo dev’essere disconnesso/disabilitato il prima
possibile fino a che la situazione non si e’ risistemata.

In queste richieste dove un parametro compare come “”, significa
solitamente che puo’ essere un nickname od un server oppure un nome jolly di
qualche tipo. Per ciascun parametro, comunque, solamente una richiesta ed un
set di risposte viene generato.

4.3.1 Messaggio Version

Comando: VERSION
Parametri: []

Oikarinen & Reed [Page 26]

RFC 1459 Internet Relay Chat Protocol May 1993

Il messaggio VERSION e’ usato per richiedere la versione del programma del
server. Un parametro facoltativo viene usato per richiedere la
versione del programma del server qualora un client non vi sia direttamente
collegato.

Risposte numeriche:

ERR_NOSUCHSERVER RPL_VERSION

:Wiz VERSION *.se ; messaggio da Wiz per richiedere la versione
di un server che corrisponda a "*.se"

VERSION tolsun.oulu.fi ; verifica la versione del server
"tolsun.oulu.fi".

4.3.2 Messaggio Stats

Comando: STATS
Parametri: [ []]

Il messaggio stats e’ usato per richiedere le statistiche di un determinato
server. Se il parametro e’ omesso viene tornata solamente la fine
della risposta statistiche. L’implementazione di questo comando dipende
altamente dal server che risponde, nonostante il server debba essere in grado
di fornire informazioni come descritto di seguito (o in modo analogo).

Una richiesta puo’ essere data da una qualsiasi lettera la quale e’ solamente
verificata dal server di destinazione (se data come parametro )
poiche’ viene trasmessa dai servers intermedi, ignorata e inalterata. Le
richieste riportate a seguire sono quelle trovate nella corrente
implementazione di IRC e ricoprono una grande porzione delle informazioni di
base del server. Sebbene queste possono non essere supportate nello stesso
modo in versioni diverse, tutti i servers devono essere in grado di fornire
una risposta valida ad una richiesta STATS che consiste in una risposta nel
formato attualmente in uso che assolva il quesito.

Le richieste attualmente supportate sono:

c - ritorna una lista di servers al quale il server si puo’
connettere o dai quali permette connessioni;
h - ritorna una lista di servers che sono forzatamente elementi
periferici dell’albero della rete o che possono fungere da hubs;
i - ritorna una lista di hosts per i quali il server permette ad un
client di connettervisi;
k - ritorna una lista di combinazioni username/hostname bannati per
quel server;
l – ritorna una lista di connessioni del server,

Oikarinen & Reed [Page 27]

RFC 1459 Internet Relay Chat Protocol May 1993

riportando da quanto tempo e’ stata stabilita ciascuna
connessione, il traffico in bytes su ciascuna di esse ed i
messaggi per ciascuna direzione;
m - ritorna una lista di comandi supportati dal server e il numero di
utilizzi per ciascuno di essi qualora questo non sia zero;
o - ritorna una lista di hosts dai quali un normale client puo’
diventare operatore;
y - mostra la linea Y (classe) del file di configurazione del server;
u – ritorna una stringa indicante da quanto tempo il server e’
connesso.

(N.d.T. – le richieste stats attualmente supportate sono: a, c, d, h, i, k,
l, m, o, r, t, u, y, z)

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_STATSCLINE RPL_STATSNLINE
RPL_STATSILINE RPL_STATSKLINE
RPL_STATSQLINE RPL_STATSLLINE
RPL_STATSLINKINFO RPL_STATSUPTIME
RPL_STATSCOMMANDS RPL_STATSOLINE
RPL_STATSHLINE RPL_ENDOFSTATS

STATS m ; ritorna l’uso dei comandi sul server al quale
si e’ connessi.

:Wiz STATS c eff.org ; richiesta da Wiz di informazioni C/N line sul
server eff.org.

4.3.3 Messaggio Links

Comando: LINKS
Parametri: [[] ]

Con LINKS un utente puo’ listare tutti i servers conosciuti al server che
risponde alla richiesta. L’elenco di servers tornato deve corrispondere con
lo schema e, se questo non e’ specificato, viene tornata la lista completa.

Se viene dato in aggiunta a , il comando
LINKS e’ inoltrato al primo server trovato che corrisponda a quel nome (se
esiste) e quel server deve quindi rispondere alla richiesta.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKS

Oikarinen & Reed [Page 28]

RFC 1459 Internet Relay Chat Protocol May 1993

LINKS *.au ; elenca tutti i servers il cui nome corrisponda
allo schema *.au;

:WiZ LINKS *.bu.edu *.edu
; messaggio LINKS da WiZ al primo server che
corrisponda a *.edu per un elenco di server che
corrispondono a *.bu.edu.

4.3.4 Messaggio Time

Comando: TIME
Parametri: []

Il messaggio time e’ usato per richiedere l’ora locale al server specificato.
Se il parametro server non e’ dato rispondera’ alla richiesta il server che
gestisce il comando.

Risposte numeriche:

ERR_NOSUCHSERVER RPL_TIME

TIME tolsun.oulu.fi ; verifica l’ora sul server
"tolson.oulu.fi".

Angel TIME *.au ; l’utente Angel verifica l’ora su un server
che corrisponda allo schema "*.au".

4.3.5 Messaggio Connect

Comando: CONNECT
Parametri: [ []]

Il comando CONNECT puo’ essere usato per forzare un server a provare di
stabilire una nuova connessione con un altro server immediatamente. CONNECT
e’ un comando privilegiato ed e’ disponibile solamente agli operatori IRC. Se
viene specificato un server remoto il tentativo CONNECT e’ fatto da quel
server al mediante la .

Risposte numeriche:

ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMS

CONNECT tolsun.oulu.fi
; Tentativo di connettere un server a
tolsun.oulu.fi

Oikarinen & Reed [Page 29]

RFC 1459 Internet Relay Chat Protocol May 1993

:WiZ CONNECT eff.org 6667 csd.bu.edu
; Tentativo di CONNECT da WiZ per connettere i
servers eff.org e csd.bu.edu sulla porta 6667.

4.3.6 Messaggio Trace

Comando: TRACE
Parametri: []

Il comando TRACE e’ usato per trovare il percorso ad un determinato server.
Ogni server che processa questo messaggio deve informare il server mittente
su se stesso inviando una risposta che indichi che e’ un collegamento di
passaggio, creando cosi’ una catena di risposte analoga a quella ottenuta
usando “traceroute”. Dopo aver inviato tale risposta, deve poi spedire il
messaggio TRACE al server successivo fino a che non sia stato raggiunto il
server di destinazione. Se il parametro viene omesso, e’
raccomandato che il comando TRACE invii un messaggio al mittente indicando a
quali servers il server corrente e’ direttamente connesso.

Se la destinazione data da “” e’ un server corrente, al server di
destinazione e’ richiesto di riportare tutti i servers e gli utenti che gli
sono connessi, anche se la visione degli utenti presenti e’ riservata ai soli
operatori. Se la destinazione data da e’ un nickname, viene data una
sola risposta per quel nickname.

Risposte numeriche:

ERR_NOSUCHSERVER

Se il messaggio TRACE e’ destinato ad un altro server, tutti i server
intermedi devono ritornare una risposta RPL_TRACELINK per indicare che il
TRACE e’ passato di li’ e quale sia il suo prossimo passaggio.

Una risposta TRACE puo’ essere composta da qualsiasi numero delle seguenti
risposte numeriche.

RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
RPL_TRACEUSER RPL_TRACESERVER
RPL_TRACESERVICE RPL_TRACENEWTYPE
RPL_TRACECLASS

TRACE *.oulu.fi ; TRACE ad un server che corrisponda a *.oulu.fi

Oikarinen & Reed [Page 30]

RFC 1459 Internet Relay Chat Protocol May 1993

:WiZ TRACE AngelDust ; TRACE richiesto da WiZ al nick AngelDust

4.3.7 Comando Admin

Comando: ADMIN
Parametri: []

Il messaggio ADMIN e’ usato per trovare il nome dell’amministratore di un
dato server, o del server corrente se il parametro e’ omesso.
Ciascun server deve avere la capacita’ di inoltrare messaggi ADMIN agli altri
servers.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_ADMINME RPL_ADMINLOC1
RPL_ADMINLOC2 RPL_ADMINEMAIL

ADMIN tolsun.oulu.fi ; richiesta di una risposta ADMIN da
tolsun.oulu.fi

:WiZ ADMIN *.edu ; richiesta ADMIN da WiZ per il primo server
che corrisponda allo schema *.edu.

4.3.8 Info command

Comando: INFO
Parametri: []

Il comando INFO e’ richiesto per avere informazioni sul server: la versione,
quando e’ stato compilato, il livello di aggiornamento, quando e’ stato
avviato, e qualsiasi altra informazione che possa essere considerata
rilevante.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_INFO RPL_ENDOFINFO

INFO csd.bu.edu ; richiesta di risposta INFO da csd.bu.edu

:Avalon INFO *.fi ; richiesta INFO da Avalon per il primo
server che corrisponda a *.fi.

Oikarinen & Reed [Page 31]

RFC 1459 Internet Relay Chat Protocol May 1993

INFO Angel ; richiesta INFO al server al quale Angel e’
connesso.

4.4 Invio di messaggi

Lo scopo principale del protocollo IRC e’ fornire una base per la reciproca
comunicazione tra clients. PRIVMSG e NOTICE sono gli unici messaggi
disponibili che al momento si occupano di recapitare un messaggio di testo
da un client ad un altro – il resto e’ cio’ che lo rende possibile e che
tenta di garantire che questo avvenga in maniera affidabile e strutturata.

4.4.1 Messaggio Private

Comando: PRIVMSG
Parametri: {,}

PRIVMSG e’ usato per inviare messaggi privati tra due utenti. e’
il nickname del destinatario del messaggio. puo’ anche essere una
lista di nomi o canali separati da virgole.

Il parametro puo’ anche essere uno schema di macchine (#mask) o
uno schema di server ($mask). In entrambi i casi il server inviera’ il
PRIVMSG solamente a coloro che hanno un server o un host che corrisponde allo
schema. Lo schema deve avere almeno 1 (un) “.” e nessun jolly dopo l’ultimo
“.”. Questo requisito esiste per evitare l’invio di messaggi a “#*” o “$*”,
che comporterebbe l’inoltro a tutti gli utenti; per esperienza, questo e’
abusato piu’ che responsabilmente e propriamente usato. I jolly sono i
caratteri ‘*’ e ‘?’. Tale estensione del comando PRIVMSG e’ disponibile
solamente agli operatori.

Risposte numeriche:

ERR_NORECIPIENT ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAY

:Angel PRIVMSG Wiz :Hello are you receiving this message ?
; Messaggio da Angel a Wiz.

PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br
; Messaggio ad Angel.

PRIVMSG jto@tolsun.oulu.fi :Hello !
; Messaggio ad un client con username "jto"

Oikarinen & Reed [Page 32]

RFC 1459 Internet Relay Chat Protocol May 1993

sul server un.oulu.fi.

PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
; Messaggio a chiunque sia su un server che
corrisponda a *.fi.

PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
; Messaggio a tutti gli utenti che provengono da
un host il cui nome corrisponda allo schema
*.edu.

4.4.2 Messaggio Notice

Comando: NOTICE
Parametri:

Il messaggio NOTICE e’ usato in maniera analoga al PRIVMSG. La differenza tra
NOTICE e PRIVMSG e’ che le risposte automatiche non devono essere inviate
come risposta ad un messaggio NOTICE. Questa regola si applica anche per i
servers – essi non devono inviare nessuna risposta di errore al client al
ricevimento di un notice. Il motivo di questa regola e’ evitare loops tra un
client che automaticamente invia qualcosa in risposta a qualcosa che ha
ricevuto. Questo e’ infatti generalmente usato dagli automi (clients che
dispongono di un programma interattivo i di AI che controlla le loro azioni –
N.d.T. – i ro-bots) che inviano sempre delle risposte, per paura che essi
finiscano in un loop con un altro automa.

Vedere PRIVMSG per maggiori dettagli sulle risposte e per gli esempi.

4.5 Richieste basate sull’utente

Le richieste sull’utente sono un gruppo di comandi che concerne
fondamentalmente la ricerca di dettagli su un particolare utente o gruppo di
utenti. Quando si utilizzano jolly con un qualsiasi comando di questi, se
corrisponde, verranno ritornate informazioni sugli utenti ‘visibili’ al
richiedente. La visibilita’ di un utente e’ determinata da una combinazione
dei modi dell’utente e il comune set di canale su cui si trovano utente e
richiedente.

4.5.1 Richiesta Who

Comando: WHO
Parametri: [ []]

Il messaggio WHO e’ usato da un client per generare una richiesta che torni
un elenco di informazioni che ‘corrispondano’ al parametro dato dal
client. In assenza del parametro , tutti i visibili (utenti che non
sono invisibili (modo utente +i) e coloro che non si trovano su canali ove e’
il client richiedente) sono elencati. Lo stesso risultato puo’ essere
raggiunto usando un di “0” o qualsiasi jolly che ritornera’ ogni

Oikarinen & Reed [Page 33]

RFC 1459 Internet Relay Chat Protocol May 1993

voce possibile.

Il passato da WHO e’ confrontato con la macchina, il server, il nome
reale e il nickname degli utenti se il canale non viene trovato.

Se viene passato il parametro “o” vengono tornati solamente gli operatori che
corrispondono allo schema di nomi fornito.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_WHOREPLY RPL_ENDOFWHO

WHO *.fi ; Elenca tutti gli utenti che corrispondono a
"*.fi".

WHO jto* o ; Elenca tutti gli utenti che corrispondono a
"jto*" se questi sono operatori.

4.5.2 Richiesta Whois

Comando: WHOIS
Parametri: [] [,[,...]]

Questo messaggio e’ utilizzato per richiedere informazioni su un particolare
utente. Il server rispondera’ a questo messaggio con diversi messaggi
numerici che indicano stati differenti per ciascun utente che corrisponde
allo schema di nick (se il richiedente li vede). Se nello
non vi sono jolly viene fornita qualsiasi informazione sul nick visibile al
richiedente. Puo’ essere data una lista di nickname con elementi separati da
virgole (‘,’).

L’ultima versione invia la richiesta ad uno specificato server. E’ utile se
si vuole sapere da quanto tempo l’utente in questione e’ inattivo dato che il
server locale (ad esempio il server sul quale l’utente e’ direttamente
connesso) e’ l’unico in grado di sapere tale informazione, mentre qualsiasi
altro dato e’ globalmente conosciuto.

Risposte numeriche:

ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
RPL_WHOISUSER RPL_WHOISCHANNELS
RPL_WHOISCHANNELS RPL_WHOISSERVER
RPL_AWAY RPL_WHOISOPERATOR
RPL_WHOISIDLE ERR_NOSUCHNICK
RPL_ENDOFWHOIS

Oikarinen & Reed [Page 34]

RFC 1459 Internet Relay Chat Protocol May 1993

WHOIS wiz ; ritorna le informazioni utente disponibili
per il nick WiZ

WHOIS eff.org trillian ; domanda al server eff.org le informazioni
sull’utente trillian

4.5.3 Richiesta Whowas

Comando: WHOWAS
Parametri: [ []]

Whowas richiede informazioni su un nickname non piu’ esistente. Questo puo’
avvenire perche’ un nickname e’ stato modificato oppure perche’ l’utente ha
abbandonato IRC. Come risposta a questa richiesta il server ricerca nella sua
cronologia dei nicknames qualsiasi nick lessicalmente uguale (non si possono
usare carattere jolly, in questo caso). La cronologia viene sfogliata a
ritroso, ritornando quindi la prima voce piu’ recente. Se vi sono voci
multiple verranno ritornate tante risposte quante (oppure tutte se
non e’ il parametro non e’ specificato). Se viene passato un numero
non positivo come viene fatta una ricerca completa.

Risposte numeriche:

ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
RPL_WHOWASUSER RPL_WHOISSERVER
RPL_ENDOFWHOWAS

WHOWAS Wiz ; ritorna tutte le informazioni presenti
nella cronologia dei nick per il nick "WiZ";

WHOWAS Mermaid 9 ; ritorna le 9 voci piu’ recenti nella
cronologia dei nick per "Mermaid";

WHOWAS Trillian 1 *.edu ; ritorna la voce piu’ recente per
"Trillian" nella cronologia del primo server
che corrisponde allo schema "*.edu".

4.6 Messaggi vari

I messaggi di questa categoria non rientrano in nessuna delle categorie
precedenti ma ad ogni modo fanno parte e sono richiesti dal protocollo.

Oikarinen & Reed [Page 35]

RFC 1459 Internet Relay Chat Protocol May 1993

4.6.1 Messaggio Kill

Comando: KILL
Parametri:

Il messaggio KILL e’ usato per cessare una connessione client-server dal
server che detiene l’attuale connessione. KILL e’ usato dai servers quando
questi incontrano una voce doppia nella lista dei nicknames validi ed e’
usato per rimuovere entrambe le voci. E’ anche disponibile agli operatori.

I clients che dispongono di algoritmi di riconnessione automatica fanno
effettivamente perdere di significato questo comando, dal momento che la
disconnessione avviene solo per un attimo. Esso spezza tuttavia il flusso di
dati e puo’ essere usato per bloccare grandi quantita’ di abusi; qualsiasi
utente puo’ richiedere di ricevere i messaggi KILL generati da altri per
tenere ‘sott’occhio’ su eventuali possibili problematiche.

In un’arena ove e’ richiesto che i nicknames siano sempre universalmente
univoci, i messaggi KILL sono inviati qualora dei ‘duplicati’ vengano
rilevati (che puo’ essere un tentativo di registrare due utenti con lo stesso
nickname) nella speranza che entrambi scompaiano e sono 1 riappaia.

Il commento dato deve riflettere la corrente motivazione del KILL. Per i
KILLs generati da un server esso e’ normalmente costituito dai dettagli
riguardanti l’origine dei due nicknames in conflitto. Per gli utenti invece
e’ lasciato a loro fornire un’adeguata motivazione che soddisfi chi li vede.
Per prevenire/scoraggiare la generazione di falsi KILLs che nascondono
l’identita’ del KILLer, il commento mostra anche un ‘percorso del kill’ che
viene aggiornato da ciascun server da cui passa, mediante l’aggiunta del
proprio nome al percorso.

Risposte numeriche:

ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK ERR_CANTKILLSERVER

KILL David (csd.bu.edu <- tolsun.oulu.fi)
; Collisione di nickname tra csd.bu.edu
e tolson.oulu.fi

NOTA:
E’ raccomandato che solamente gli operatori siano in grado di generare kill
verso altri utenti. In un mondo ideale gli operatori non dovrebbero nemmeno
averne la necessita’ e l’assoluzione di questo compito verrebbe lasciata ai
servers.

Oikarinen & Reed [Page 36]

RFC 1459 Internet Relay Chat Protocol May 1993

4.6.2 Messaggio Ping

Comando: PING
Parametri: []

Il messaggio PING e’ usato per rilevare la presenza di un client attivo
all’altro lato della connessione. Un messaggio PING viene inviato ad
intervalli regolari se non e’ rilevata alcun altra attivita’ proveniente
dalla connessione. Se una connessione non risponde ad un comando PING entro
un tempo determinato questa viene terminata.

Qualsiasi client che riceve un messaggio PING deve rispondere al
(server mittente del messaggio PING) il prima possibile con un messaggio PONG
appropriato per indicare che c’e’ ed e’ connesso. I servers non dovrebbero
rispondere ai comandi PING ma contare sui PINGs provenienti dall’altro capo
della connessione che indicano che la connessione e’ attiva. Se viene
specificato il parametro il messaggio PING viene a lui inoltrato.

Risposte numeriche:

ERR_NOORIGIN ERR_NOSUCHSERVER

PING tolsun.oulu.fi ; un server invia un messaggio PING ad un
altro server per indicare che e’ ancora
connesso.

PING WiZ ; Messaggio PING inviato a WiZ.

4.6.3 Messaggio Pong

Comando: PONG
Parametri: []

Il messaggio PONG e’ la risposta di un messaggio ping. Se il parametro
e’ dato questo messaggio dev’essere inoltrato al daemon dato. Il
parametro e’ il nome del daemon che ha risposto al messaggio PING e
che ha generato questo messaggio.

Risposte numeriche:

ERR_NOORIGIN ERR_NOSUCHSERVER

PONG csd.bu.edu tolsun.oulu.fi
; Messaggio PONG da csd.bu.edu a
tolsun.oulu.fi

Oikarinen & Reed [Page 37]

RFC 1459 Internet Relay Chat Protocol May 1993

4.6.4 Messaggio Error

Comando: ERROR
Parametri:

Il comando ERROR e’ utilizzato dai servers per riportare ai suoi operatori un
errore serio o fatale. Puo’ anche essere inviato da un server ad un altro ma
non dev’essere accettato da un qualsiasi normale client sconosciuto.

Un messaggio ERROR e’ usato per riportare errori che avvengono solamente in
un collegamento server-a-server. Un messaggio ERROR e’ inviato da un server
all’altro capo della connessione (che lo invia a tutti i suoi operatori
connessi) e a tutti gli operatori al momento collegati. Esso non dev’essere
passato ad altri server da un server se questi lo ha ricevuto da un server.

Quando un server invia ai suoi operatori un messaggio ERROR ricevuto, il
messaggio dovrebbe essere incapsulato dentro un messaggio NOTICE, indicando
che il client non e’ responsabile per l’errore.

Risposte numeriche:

ERROR :Server *.fi already exists
; Messaggio ERROR all’altro server che ha
causato questo errore.

NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
; Stesso messaggio ERROR come sopra ma
inviato all’utente WiZ sull’altro server.

5. MESSAGGI OPZIONALI

Questa sezione illustra i messaggi OPZIONALI. Questi non sono richiesti in
una implementazione server del protocollo qui descritto. In assenza di option
un messaggio di risposta d’errore dev’essere generato o un errore di comando
sconosciuto. Se il messaggio e’ destinato ad un altro server questo
dev’essere passato avanti (e’ richiesta solo un’analisi elementare). Le
risposte numeriche stabilite per questi messaggi sono riportate di seguito
con gli stessi.

5.1 Messaggio Away

Comando: AWAY
Parametri: [messaggio]

Oikarinen & Reed [Page 38]

RFC 1459 Internet Relay Chat Protocol May 1993

Con il messaggio AWAY I clients possono impostare una stringa di risposta
automatica per ogni comando PRIVMSG diretto a loro (e non al canale su si
trovano). Tale risposta viene inviata dal server al client mittente del
comando PRIVMSG. Il solo server che risponde e’ quello al quale il client
mittente e’ connesso.

Il messaggio AWAY e’ usato o con un parametro (per impostare un messaggio di
AWAY) oppure senza (per rimuovere il messaggio AWAY).

Risposte numeriche:

RPL_UNAWAY RPL_NOWAWAY

AWAY :Gone to lunch. Back in 5
; imposta il messaggio di away come "Gone to
lunch. Back in 5".

:WiZ AWAY ; toglie WiZ dallo stato di away.

5.2 Messaggio Rehash

Comando: REHASH
Parametri: Nessuno

Il messaggio rehash puo’ essere usato dall’operatore per forzare il server a
ri-leggere e processare il suo file di configurazione.

Risposte numeriche:

RPL_REHASHING ERR_NOPRIVILEGES

REHASH ; messaggio da un client con stato di operatore
al server per richiedere la rilettura del suo
file di configurazione.

5.3 Messaggio Restart

Comando: RESTART
Parametri: Nessuno

Il messaggio restart puo’ essere usato esclusivamente da un operatore per
forzare il riavvio del server. Questo messaggio e’ facoltativo dal momento
che puo’ essere visto come un rischio permettere arbitrariamente ad una
persona di connettersi ad un server come operatore ed eseguire questo
comando, dato che si causerebbe (come minimo) una interruzione del servizio.

Oikarinen & Reed [Page 39]

RFC 1459 Internet Relay Chat Protocol May 1993

Il comando RESTART deve sempre essere processato a pieno dal server al quale
il client mittente e’ connesso e non deve essere passato ad altri servers
connessi.

Risposte numeriche:

ERR_NOPRIVILEGES

RESTART ; nessun parametro richiesto.

5.4 Messaggio Summon

Comando: SUMMON
Parametri: []

Il comando SUMMON puo’ essere usato per dare agli utenti, che si trovano su
un host ove gira un server IRC, un messaggio che gli richiede cortesemente di
unirsi ad IRC. Tale messaggio viene inviato solamente se il server in oggetto
(a) ha abilitato il SUMMON, (b) l’utente vi e’ loggato e (c) il server che
processa il messaggio puo’ scrivere sul tty dell’utente (o qualcosa di
simile).

Se non viene dato alcun parametro esso tenta di convocare l’
dal server al quale il client e’ connesso, che viene supposto come quello di
destinazione.

Se il summon non e’ abilitato su un server, dev’essere ritornata la risposta
numerica ERR_SUMMONDISABLED e passare il messaggio summon oltre.

Risposte numeriche:

ERR_NORECIPIENT ERR_FILEERROR
ERR_NOLOGIN ERR_NOSUCHSERVER
RPL_SUMMONING

SUMMON jto ; convoca l’utente jto sulla macchina del
server.

SUMMON jto tolsun.oulu.fi
; convoca l’utente jto sulla macchina ove e’
attivo il server "tolsun.oulu.fi".

5.5 Comando Users

Comando: USERS
Parametri: []

Oikarinen & Reed [Page 40]

RFC 1459 Internet Relay Chat Protocol May 1993

Il comando USERS ritorna una lista di utenti loggati sul server, in maniera
simile al formato di who, rusers e finger. Qualcuno puo’ aver disabilitato
questo comando, sul proprio server, per motivi di sicurezza. Se disabilitato,
dev’essere ritornata la relativa risposta numerica.

Risposte numeriche:

ERR_NOSUCHSERVER ERR_FILEERROR
RPL_USERSSTART RPL_USERS
RPL_NOUSERS RPL_ENDOFUSERS
ERR_USERSDISABLED

Risposta se disabilitato:

ERR_USERSDISABLED

USERS eff.org ; richiede la lista degli utenti loggati su
eff.org.

:John USERS tolsun.oulu.fi
; richiesta di John della lista di utenti
loggati sul server tolsun.oulu.fi.

5.6 Messaggio Operwall

Comando: WALLOPS
Parametri: Text to be sent to all operators currently online

Invia un messaggio a tutti gli operatori attualmente online. Dopo aver
implementato il WALLOPS come un comando disponibile all’utente si e’ visto
che esso e’ stato spesso e volentieri usato in maniera impropria per inviare
un messaggio ad un elevato numero di persone (in modo simile al WALL). Per
questo motivo e’ raccomandato che l’attuale implementazione di WALLOPS sia da
esempio affinche’ siano solamente i servers gli unici autorizzati ad inviare
dei WALLOPS.

Risposte numeriche:

ERR_NEEDMOREPARAMS

:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua
; Messaggio WALLOPS da csd.bu.edu per
notificare che il messaggio CONNECT e’ stato
ricevuto e attuato da Joshua.

Oikarinen & Reed [Page 41]

RFC 1459 Internet Relay Chat Protocol May 1993

5.7 Messaggio Userhost

Comando: USERHOST
Parametri: {}

Il comando USERHOST prende una lista di massimo 5 nicknames, ciascuno
separato da un carattere spazio, e ritorna un elenco di informazioni su
ognuno di essi. La lista tornata ha ciascuna una risposta separata da uno
spazio.

Risposte numeriche:

RPL_USERHOST ERR_NEEDMOREPARAMS

USERHOST Wiz Michael Marty p
;Richiesta USERHOST per avere informazioni
sui nick "Wiz", "Michael", "Marty" e "p".

5.8 Messaggio Ison

Comando: ISON
Parametri: {}

Il comando ISON e’ stato implementato per fornire una rapida ed efficiente
risposta che informi se un dato utente e’ al momento collegato a IRC. ISON
necessita di un (1) solo parametro: un elenco di nick separati da spazi. Per
ciascun nickname della lista il server aggiunge una voce alla sua stringa di
risposta. La stringa di risposta puo’ quindi essere vuota (nessuno dei nick
indicati e’ presente), un’esatta copia della stringa di parametro (tutti i
nick sono presenti) o qualsiasi altro sottoinsieme dell’insieme di nick
forniti col parametro. L’unica restrizione sul numero di nick che possono
essere verificati e’ che la lunghezza totale della stringa non puo’ essere
troppo grande altrimenti il server la tronca a 512 caratteri.

ISON e’ processato solamente dal server locale del client mittente e non
viene passato ad altri server per ulteriori processi.

Risposte numeriche:

RPL_ISON ERR_NEEDMOREPARAMS

ISON phone trillian WiZ jarlek Avalon Angel Monstah
; Esempio di richiesta ISON per 7 nick.

Oikarinen & Reed [Page 42]

RFC 1459 Internet Relay Chat Protocol May 1993

Cio’ che segue e’ un elenco delle risposte numeriche che possono essere
generate come replica ai comandi visti in precedenza. Ciascuna di esse viene
riportata con il relativo numero, nome e stringa di risposta.

6.1 Risposte di errore

401 ERR_NOSUCHNICK
" :No such nick/channel"

- Usata per indicare che il parametro nickname fornito col
comando non e’ attualmente in uso.

402 ERR_NOSUCHSERVER
" :No such server"

- Usata per indicare che il nome server dato attualmente non
esiste.

403 ERR_NOSUCHCHANNEL
" :No such channel"

- Usata per indicare che il nome del canale dato non e’ valido.

404 ERR_CANNOTSENDTOCHAN
" :Cannot send to channel"

- Inviata ad un utente che (a) non e’ su un canale con mode +n
oppure (b) non e’ chanop (o mode +v) su un canale impostato
come +m e sta tentando di inviare un messaggio PRIVMSG al
canale.

405 ERR_TOOMANYCHANNELS
" :You have joined too many
channels"
- Inviata ad un utente quando questi si e’ unito al numero
massimo o consentito di canali e prova ad unirsi ad un altro
canale.

406 ERR_WASNOSUCHNICK
" :There was no such nickname"

- In risposta all’WHOWAS per indicare che non vi sono
informazioni per quel nickname.

407 ERR_TOOMANYTARGETS
" :Duplicate recipients. No message

Oikarinen & Reed [Page 43]

RFC 1459 Internet Relay Chat Protocol May 1993

- In risposta ad un client che sta cercando di inviare un
PRIVMSG/NOTICE usando il formato user@host per un user@host
che ha diverse istanze.

409 ERR_NOORIGIN
":No origin specified"

- Messaggio PING o PONG mancante del parametro del mittente,
richiesto poiche’ tali comandi devono lavorare senza validi
prefissi.

411 ERR_NORECIPIENT
":No recipient given ()"

412 ERR_NOTEXTTOSEND
":No text to send"

413 ERR_NOTOPLEVEL
" :No toplevel domain specified"

414 ERR_WILDTOPLEVEL
" :Wildcard in toplevel domain"

- 412 - 414 sono tornati da un PRIVMSG per indicare che il
messaggio non e’ stato recapitato per qualche motivo.
ERR_NOTOPLEVEL e ERR_WILDTOPLEVEL sono errori tornati quando
avviene un uso non valido di "PRIVMSG $" o
"PRIVMSG #".

421 ERR_UNKNOWNCOMMAND
" :Unknown command"

- Ritornata ad un client registrato per indicare che il comando
inviato non e’ conosciuto dal server.

422 ERR_NOMOTD
":MOTD File is missing"

- Il file MOTD del server non puo’ essere aperto.

423 ERR_NOADMININFO
" :No administrative info available"

- Tornata da un server in risposta ad un messaggio ADMIN quando
si verifica un errore nel reperimento delle informazioni.

424 ERR_FILEERROR
":File error doing on "

Oikarinen & Reed [Page 44]

RFC 1459 Internet Relay Chat Protocol May 1993

- Messaggio di errore generico usato per riportare un errore di
operazione su file durante la processione di un messaggio.

431 ERR_NONICKNAMEGIVEN
":No nickname given"

- Ritornata quando un parametro nickname non e’ stato trovato.

432 ERR_ERRONEUSNICKNAME
" :Erroneus nickname"

- Ritornata a seguito di un messaggio nick contenente caratteri
non rientranti in alcun set definito. Vedere la sezione 4.1.2
per dettagli sui nickname validi.

433 ERR_NICKNAMEINUSE
" :Nickname is already in use"

- Tornata a seguito di un tentativo di modificare il proprio
nick con uno esistente, a seguito del messaggio NICK.

436 ERR_NICKCOLLISION
" :Nickname collision KILL"

- Ritornata da un server ad un client quando di verifica una
collisione di nickname (registrazione di un NICK con uno gia’
esistente su un altro server).

441 ERR_USERNOTINCHANNEL
" :They aren't on that channel"

- Ritornata dal server per indicare che l’utente oggetto del
comando non e’ sul canale dato.

442 ERR_NOTONCHANNEL
" :You're not on that channel"

- Ritornata dal server ogni volta che un client invia un comando
che si riferisce ad un canale di cui non e’ membro.

443 ERR_USERONCHANNEL
" :is already on channel"

- Ritornata quando un client tenta di invitare un utente su un
canale ove e’ gia’ presente.

Oikarinen & Reed [Page 45]

RFC 1459 Internet Relay Chat Protocol May 1993

444 ERR_NOLOGIN
" :User not logged in"

- Tornata a seguito di un comando SUMMON per un utente non in
grado di essere portato a buon fine poiche’ non loggato.

445 ERR_SUMMONDISABLED
":SUMMON has been disabled"

- Ritornata in risposta ad un comando SUMMON. Deve essere
tornata da ogni server sul quale esso non e’ implementato.

446 ERR_USERSDISABLED
":USERS has been disabled"

- Ritornata in risposta ad un comando USERS. Deve essere
tornata da ogni server sul quale esso non e’ implementato.

451 ERR_NOTREGISTERED
":You have not registered"

- Ritornata dal server per indicare che il client dev’essere
registrato prima che il server acconsenta di essere
analizzato nel dettaglio.

461 ERR_NEEDMOREPARAMS
" :Not enough parameters"

- Ritornata dal server a seguito di numerosi comandi per
indicare che il client non ha fornito sufficienti parametri.

462 ERR_ALREADYREGISTRED
":You may not reregister"

- Ritornata dal server a qualsiasi collegamento che tenta di
modificare le impostazioni di registrazione (come password o
dettagli sull’utente da un secondo messaggio USER).

463 ERR_NOPERMFORHOST
":Your host isn't among the privileged"

- Ritornata ad un client che cerca di registrarsi ad un server
che non consente connessioni dall’host che tenta la
connessione.

Oikarinen & Reed [Page 46]

RFC 1459 Internet Relay Chat Protocol May 1993

464 ERR_PASSWDMISMATCH
":Password incorrect"

- Ritornata per indicare un tentativo fallito di registrazione
di una connessione per la quale la password richiesta non e’
stata fornita oppure in modo errato.

465 ERR_YOUREBANNEDCREEP
":You are banned from this server"

- Ritornata dopo un tentativo di connessione e registrazione ad
un server sul quale la tua connessione e’ stata esplicitamente
proibita.

467 ERR_KEYSET
" :Channel key already set"

471 ERR_CHANNELISFULL
" :Cannot join channel (+l)"

472 ERR_UNKNOWNMODE
" :is unknown mode char to me"

473 ERR_INVITEONLYCHAN
" :Cannot join channel (+i)"

474 ERR_BANNEDFROMCHAN
" :Cannot join channel (+b)"

475 ERR_BADCHANNELKEY
" :Cannot join channel (+k)"

481 ERR_NOPRIVILEGES
":Permission Denied- You're not an IRC operator"

- Ogni comando che richiede i privilegi di operatore per operare
deve tornare questo errore per indicare che il tentativo non
ha avuto successo.

482 ERR_CHANOPRIVSNEEDED
" :You're not channel operator"

- Ogni comando che richiede i privilegi ‘chanop’ (come i
messaggi MODE) devono tornare questo errore se il client che
tenta il comando non e’ chanop del canale specificato.

483 ERR_CANTKILLSERVER
":You cant kill a server!"

- Ogni tentativo di utilizzo del comando KILL su un server
dev’essere rifiutato e ritornato direttamente al client questo
errore.

Oikarinen & Reed [Page 47]

RFC 1459 Internet Relay Chat Protocol May 1993

491 ERR_NOOPERHOST
":No O-lines for your host"

- Se un client invia un messaggio OPER ed il server non e’ stato
impostato per ricevere connessioni come operatore dall’host
del client dev’essere tornato questo errore.

501 ERR_UMODEUNKNOWNFLAG
":Unknown MODE flag"

- Ritornata dal server per indicare che il messaggio MODE e’
stato inviato con un flag non riconosciuto.

502 ERR_USERSDONTMATCH
":Cant change mode for other users"

- Errore inviato a qualsiasi utente che cerca di vedere o
modificare i modi utente di un altro utente.

6.2 Risposte ai comandi.

300 RPL_NONE
Numero di risposta interna. Non usata.

302 RPL_USERHOST
":[{}]"

- Formato di risposta usato da USERHOST per elencare risposte ad
una lista di richieste. La stringa di risposta e’ formata come
segue:

::= ['*'] '=' <'+'|'-'>

L’*’ indica se il client e’ stato registrato come operatore. I
caratteri ‘-‘ o ‘+’ indicano se il client ha impostato o meno
un messaggio di away.

303 RPL_ISON
":[ {}]"

- Formato di risposta usato da ISON per elencare risposte ad una
lista di richieste.

301 RPL_AWAY
" :"

Oikarinen & Reed [Page 48]

RFC 1459 Internet Relay Chat Protocol May 1993

305 RPL_UNAWAY
":You are no longer marked as being away"

306 RPL_NOWAWAY
":You have been marked as being away"

- Queste risposte sono usate col comando AWAY (se permesso).
RPL_AWAY e’ inviato a qualsiasi client che invia un PRIVMSG ad
un client in stato di away. RPL_AWAY e’ inviato solamente dal
server al quale il client e’ connesso. Le risposte RPL_UNAWAY
e RPL_NOAWAY sono inviate quando il client rimuove e imposta
il messaggio di AWAY.

311 RPL_WHOISUSER
" * :"

312 RPL_WHOISSERVER
" :"

313 RPL_WHOISOPERATOR
" :is an IRC operator"

317 RPL_WHOISIDLE
" :seconds idle"

318 RPL_ENDOFWHOIS
" :End of /WHOIS list"

319 RPL_WHOISCHANNELS
" :{[@|+]}"

- Le risposte 311 – 313 – 317 – 319 sono tutte generate in
risposta ad un messaggio WHOIS. Assunto che vi siano
sufficienti parametri, il server che risponde deve o formulare
una risposta tra quelle riportate sopra (se il nick richiesto
e’ stato trovato) o ritornare una risposta d’errore. L’*’ in
RPL_WHOISUSER e’ in questo caso un carattere e non un jolly.
Per ciascun set di risposte solo la RPL_WHOISCHANNLES puo’
comparire piu’ di una volta (per grandi liste di nomi di
canale). I caratteri ‘@’ e ‘+’ che seguono il nome del canale
indicato se un client e’ un operatore di canale o se ha la
parola su un canale moderato. La risposta RPL_ENDOFWHOIS viene
usata per marcare la fine del processo del messaggio WHOIS.

314 RPL_WHOWASUSER
" * :"

369 RPL_ENDOFWHOWAS
" :End of WHOWAS"

- Quando risponde ad un messaggio WHOWAS un server deve usare le
risposte RPL_WHOWASUSER, RPL_WHOISSERVER o ERR_WASNOSUCHNICK

Oikarinen & Reed [Page 49]

RFC 1459 Internet Relay Chat Protocol May 1993

presentato nella lista. Al termina di tutte le risposte,
dev’essere data una RPL_ENDOFWHOWAS (anche se vi era una sola
ed errata risposta).

321 RPL_LISTSTART
"Channel :Users Name"

322 RPL_LIST
" <# visible> :"

323 RPL_LISTEND
":End of /LIST"

- Le risposte RPL_LISTSTART, RPL_LIST e RPL_LISTEND segnano
l’inizio, le attuali risposte con dati e la fine della
risposta del server ad un comando LIST. Se non vi sono canali
disponibili da tornare, verra’ inviata solamente la risposta
di inizio e di fine.

324 RPL_CHANNELMODEIS
" "

331 RPL_NOTOPIC
" :No topic is set"

332 RPL_TOPIC
" :"

- Quando si invia un messaggio TOPIC per determinare il topic di
un canale, viene tornata una risposta tra due. Se il topic e’
impostato viene tornata RPL_TOPIC, altrimenti la RPL_NOTOPIC.

341 RPL_INVITING
" "

- Tornata dal server per indicare che il tentativo del messaggio
INVITE ha avuto successo ed e’ stato passato al client finale.

342 RPL_SUMMONING
" :Summoning user to IRC"

- Ritornata dal server in risposta ad un messaggio SUMMON per
indicare che l’utente sta per essere convocato.

351 RPL_VERSION
". :"

- Risposta dal server per mostrare la sua versione. La
e’ la versione del software in uso (inclusi tutte le revisioni

Oikarinen & Reed [Page 50]

RFC 1459 Internet Relay Chat Protocol May 1993

di aggiornamento) e il e’ usato per indicare se
il server sta girando in “debug mode”.

Il campo “comments” puo’ contenere qualsiasi commento sulla
versione o ulteriori dettagli sulla stessa.

352 RPL_WHOREPLY
"
[*][@|+] : "

315 RPL_ENDOFWHO
" :End of /WHO list"

- Le risposte RPL_WHOREPLY e RPL_ENDOFWHO sono usate in risposta
ad un messaggio WHO. La RPL_WHOREPLY e’ la sola inviata se vie
e’ un’appropriato riscontro alla richiesta WHO. Se con il
messaggio WHO viene fornita una lista di parametri, una volta
che ciascuna voce della lista viene processata, ovvero ciascun
, sara’ ritornata una risposta RPL_ENDOFWHO.

353 RPL_NAMREPLY
" :[[@|+] [[@|+] [...]]]"

366 RPL_ENDOFNAMES
" :End of /NAMES list"

- Per rispondere ad un messaggio NAMES il server invia al client
una coppia di risposte quali RPL_NAMREPLY e RPL_ENDOFNAMES. Se
nessun canale fornito con la richiesta viene trovato sara’
tornata solamente la RPL_ENDOFNAMES. Unica eccezione quando il
messaggio NAMES viene inviato senza parametri poiche’ tutti i
canali visibili ed i loro membri sono tornati tra le risposte
RPL_NAMREPLY e RPL_ENDOFNAMES.

364 RPL_LINKS
" : "

365 RPL_ENDOFLINKS
" :End of /LINKS list"

- In risposta al messaggio LINKS un server deve inviare una
risposta usando la numerica RPL_LINKS e contrassegnare la fine
dell’elenco con la risposta RPL_ENDOFLINKS.

367 RPL_BANLIST
" "

368 RPL_ENDOFBANLIST

Oikarinen & Reed [Page 51]

RFC 1459 Internet Relay Chat Protocol May 1993

" :End of channel ban list"

- Quando elenca i ‘bans’ attivi su un dato canale il server deve
ritornare la lista usando i messaggi RPL_BANLIST e
RPL_ENDOFBANLIST. Una RPL_BANLIST viene inviata per ciascun
ban attivo. Dopo che tutti i bans sono stati listati (o se non
ve ne sono) deve essere tornata una RPL_ENDOFBANLIST.

371 RPL_INFO
":"

374 RPL_ENDOFINFO
":End of /INFO list"

- Ad un server che risponde ad un messaggio INFO e’ richiesto di
inviare tutti i suoi ‘info’ in una serie di messaggi RPL_INFO
con un RPL_ENDOFINFO alla fine delle risposte.

375 RPL_MOTDSTART
":- Message of the day - "

372 RPL_MOTD
":- "

376 RPL_ENDOFMOTD
":End of /MOTD command"

- Quando si ha risposta ad un messaggio MOTD e il file MOTD e’
presente, il file viene visualizzato linea per linea, ciascuna
delle quali non supera gli 80 caratteri, usando come risposta
il formato RPL_MOTD. Questa dovrebbe essere compresa tra una
RPL_MOTDSTART (prima delle RPL_MOTD) e una RPL_ENDOFMOTD
(dopo).

381 RPL_YOUREOPER
":You are now an IRC operator"

- RPL_YOUREOPER viene tornata ad un client che ha appena inviato
con successo un messaggio OPER e guadagnato lo status di
operatore.

382 RPL_REHASHING
" :Rehashing"

- Se l’opzione REHASH viene usata e un operatore invia un
messaggio REHASH, una RPL_REHASHING e’ tornata all’operatore.

Oikarinen & Reed [Page 52]

RFC 1459 Internet Relay Chat Protocol May 1993

- Quando risponde ad un messaggio TIME un server deve inviare
una risposta usando il formato RPL_TIME riportato sopra. La
stringa che visualizza l’orario deve contenere solamente l’ora
e il giorno corretti. Non vi sono ulteriori requisiti per
questa stringa.

392 RPL_USERSSTART
":UserID Terminal Host"

393 RPL_USERS
":%-8s %-9s %-8s"

394 RPL_ENDOFUSERS
":End of users"

395 RPL_NOUSERS
":Nobody logged in"

- Se un messaggio USERS viene gestito da un server vengono
utilizzate le risposte RPL_USERSTART, RPL_USERS,
RPL_ENDOFUSERS e RPL_NOUSERS. RPL_USERSSTART dev’essere
inviata per prima, seguita da una sequenza di RPL_USERS oppure
da una singola RPL_NOUSERS. Alla fine vi sara’ una
RPL_ENDOFUSERS.

200 RPL_TRACELINK
"Link
"

201 RPL_TRACECONNECTING
"Try. "

202 RPL_TRACEHANDSHAKE
"H.S. "

203 RPL_TRACEUNKNOWN
"???? []"

204 RPL_TRACEOPERATOR
"Oper "

205 RPL_TRACEUSER
"User "

206 RPL_TRACESERVER
"Serv S C
@"

208 RPL_TRACENEWTYPE
" 0 "

261 RPL_TRACELOG
"File "

- Le RPL_TRACE* sono tutte tornate dal server come replica di un

Oikarinen & Reed [Page 53]

RFC 1459 Internet Relay Chat Protocol May 1993

di un messaggio TRACE. La quantita’ di risposte tornate
dipende dal messaggio TRACE e dal fatto che sia stato inviato
da un operatore oppure no. Non vi e’ un ordine predefinito
secondo il quale ne dev’essere inviata una per prima. Le
risposte RPL_TRACEUNKNOWN, RPL_TRACECONNECTING e
RPL_TRACEHANDSHAKE sono tutte usate per connessioni non
pienamente stabilite e che sono o sconosciute, o che stanno
cercando di connettersi oppure che sono in procinto di
completare il ‘server handshake’. RRPL_TRACELINK viene inviata
da un qualsiasi server che tratta un messaggio TRACE e deve
passarlo ad un altro server. La lista di RPL_TRACELINK inviata
a seguito di un comando TRACE che attraversa la rete IRC
dovrebbe rispecchiare l’attuale connettivita’ dei servers
stessi lungo il percorso. RPL_TRACENEWTYPE e’ usata per le
connessioni che non rientrano in altre categorie ma che devono
essere ad ogni modo visualizzata.

211 RPL_STATSLINKINFO
"

212 RPL_STATSCOMMANDS
" "

213 RPL_STATSCLINE
"C * "

214 RPL_STATSNLINE
"N * "

215 RPL_STATSILINE
"I * "

216 RPL_STATSKLINE
"K * "

218 RPL_STATSYLINE
"Y "

219 RPL_ENDOFSTATS
" :End of /STATS report"

241 RPL_STATSLLINE
"L * "

242 RPL_STATSUPTIME
":Server Up %d days %d:%02d:%02d"

243 RPL_STATSOLINE
"O * "

244 RPL_STATSHLINE
"H * "

Oikarinen & Reed [Page 54]

RFC 1459 Internet Relay Chat Protocol May 1993

221 RPL_UMODEIS
""

- Viene tornata per rispondere ad una richiesta circa i
modi di un utente.

251 RPL_LUSERCLIENT
":There are users and
invisible on servers"

252 RPL_LUSEROP
" :operator(s) online"

253 RPL_LUSERUNKNOWN
" :unknown connection(s)"

254 RPL_LUSERCHANNELS
" :channels formed"

255 RPL_LUSERME
":I have clients and
servers"

- Durante il processo di un messaggio LUSERS il server
invia un set di risposte da RPL_LUSERCLIENT,
RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS e
RPL_LUSERME. Quando risponde, un server deve tornare
RPL_LUSERCLIENT e RPL_LUSERME. Le altre r