Network Working Group J. Oikarinen Request for Comments: 1459 D. Reed May 1993 Protocollo Internet Relay Chat Traduzione a cura di ComiSAT Brescia, Set. 2002 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. 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. Sunto 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. 1.1 Servers 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 ] : [ ecc. ] : [ Fig. 1. Formato di una rete di IRC servers ] Oikarinen & Reed [Page 4] RFC 1459 Internet Relay Chat Protocol May 1993 1.2 Clients 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). 1.3 Canali 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. 2.3 Messaggi 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: ::= [':' ] ::= | [ '!' ] [ '@' ] ::= { } | ::= ' ' { ' ' } ::= [ ':' | ] ::= ::= ::= CR LF Oikarinen & Reed [Page 8] RFC 1459 Internet Relay Chat Protocol May 1993 NOTE: 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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: Nessuna Esempi: 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 Esempi: 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 Esempi: 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 Esempi: PART #twilight_zone ; abbandono del canale "#twilight_zone" PART #oz-ops,&group5 ; abbandono dei canali "&group5" e "#oz-ops". 4.2.3 Messaggio Mode Comando: 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 Esempi: 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 Esempi: :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 Esempi: 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 Esempi: 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 Esempi: :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 Esempi: 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 Esempi: :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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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. RPL_TRACELINK 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: :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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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: Nessuna. Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: 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 Esempi: :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 Esempi: 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 Esempi: 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 6. RISPOSTE 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 delivered" - 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. 391 RPL_TIME 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 " \ \