Protocollo Internet Relay Chat
Questo documento definisce un Protocollo Sperimentale per la comunità di Internet. Suggerimenti e commenti sono richiesti per il miglioramento. Per piacere consulta l’edizione corrente di “IAB Official Protocol Standards” per la posizione di normalizzazione e lo stato di questo protocollo. La distribuzione di questo documento è illimitata.
Astratto
Il protocollo IRC è stato sviluppato negli ultimi 4 anni da quando è stato incluso come un mezzo per gli utenti sulle BBS che comunicano attraverso esse. Ora IRC supporta una rete world-wide di servers e clients, e il suo sviluppo si sta velocizzando. Negli ultimi 2 anni, il numero di utenti connessi alla grande rete di IRC è salita a dismisura.
Il protocollo IRC è un protocollo basato sul testo, con il client più semplice essendo ogni programma capace di connettersi ad un server.
Tavola dei contenuti
Introduzione
1.1 Servers
1.2 Clients
1.2.1 Operatori
1.3 Canali
1.3.1 Operatori di canale
Lo specifico di IRC
2.1 Vista dall’alto
2.2 Codici di carattere
2.3 Messaggi
2.3.1 Formato dei messaggi in pseudo BNF
2.4 Risposte numeriche
Concetti di IRC
3.1 Comunicazione uno a uno
3.2 Uno a tanti
3.2.1 A una lista
3.2.2 A un gruppo
3.2.3 A un host/server mask
3.3 Uno a tutti
3.3.1 Client a client
3.3.2 Clients a server
3.3.3 Server a server
Dettagli dei messaggi
4.1 Registrazione di connessione
4.1.1 Comando Password
4.1.2 Comando Nick
4.1.3 Comando User
4.1.4 Comando Server
4.1.5 Comando Operator
4.1.6 Comando Quit
4.1.7 Comando Server Quit
4.2 Operazioni del canale
4.2.1 Comando Join
4.2.2 Comando Part
4.2.3 Comando Mode
4.2.3.1 Modalità del canale
4.2.3.2 Modalità dell’utente
4.2.4 Comando Topic
4.2.5 Comando Names
4.2.6 Comando List
4.2.7 Comando Invite
4.2.8 Comando Kick
4.3 Domande e comandi del server
4.3.1 Comando Version
4.3.2 Comando Stats
4.3.3 Comando Links
4.3.4 Comando Time
4.3.5 Comando Connect
4.3.6 Comando Trace
4.3.7 Comando Admin
4.3.8 Comando Info
4.4 Mandare messaggi
4.4.1 Messaggi privati
4.4.2 Messaggi notice
4.5 Richieste utente
4.5.1 Richiesta Who
4.5.2 Richiesta WhoIs
4.5.3 Richiesta WhoWas
4.6 Comandi vari
4.6.1 Comando Kill
4.6.2 Comando Ping
4.6.3 Comando Pong
4.6.4 Comando Error
1. Introduzione
Il protocollo IRC (Internet Relay Chat) è stato progettato da un po’ di anni a questa parte per forninre una conferenza a base di testo. Questo documento descrive il protocollo IRC corrente.
Il protocollo IRC è stato sviluppato su sistemi che usano il protocollo di rete TCP/IP, sebbene non ci sono prove che questo rimanga la sola sfera nel quale opera.
IRC stesso è un sistema di teleconferenza, che (tramite l’uso del modello client-server) è molto adatto per esser eseguito su più macchine in modo distribuito. Un setup tipico richiede a un singolo processo (il server) di formare un punto centrale per i clients (o altri servers) per connettersi, eseguire il messaggio inviato/multiplexing richiesto e altre funzioni.
1.1 Servers
Il server forma la spina dorsale di IRC, provvedendo a un punto con il quale i clients possono connttersi per parlare con altri, e un punto per altri server per connettersi, e formare una rete IRC. La sola configurazione di rete permessa per i servers IRC è un albero aperto [vedi Fig. 1] dove ogni server agisce come un nodo centrale per il resto della rete che esso 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 della rete di servers IRC ]
1.2 Clients
Un client è qualcosa che si connette a un server che non è un altro server. Ogni client si distingue da altri clients da un unico nickname che ha una lunghezza massima di nove (9) caratteri. Vedi le regole grammaticali del protocollo per cosa può essere e non può essere usato in un nickname. In aggiunta al nickname, tutti i server devono avere la seguente informazione su tutti i clients: il nome reale dell’host che il server sta eseguendo, l’username del client di quell’host, e il server sul quale il client è connesso.
1.2.1 Operatori
Per permettere una ragionevole quantità di ordine da tenere nella rete IRC, una classe speciale di clients (operatori) è autorizzata a eseguire delle funzioni di manutenzione generale sulla rete. Sebbene i poteri garantiti da un operatore possono essere considerati così “pericolosi”, essi sono necessari. Gli operatore potrebbero essere capaci di fare alcuni compiti basici di rete come disconnettere e riconenttere servers per necessità di pervenire i malfunzionamenti della rete. In riconoscimento di questo bisogno, il protocollo discusso qui permette agli operatori di eseguire tali funzioni. Vedi le sezioni 4.1.7 (SQUIT) e 4.3.5 (CONNECT).
Un potere più polemico degli operatori è l’abilità di rimuovere un utente dalla rete connessa, cioè gli operatori sono capaci di chiudere la connessione tra ogni client e server. La giustificazione per questo è delicata dal momento che il suo abuso è sia distruttivo che annoiante. Per maggiori dettagli su questo tipo di azione, vedi la sezione 4.6.1 (KILL).
1.3 Canali
Un canale è un gruppo di uno o più clients con un nome che riceveranno tutti i messaggi indirizzati a quel canale. Il canale è creato implicitamente quando il primo client entra in esso, e il canale cessa di esistere quando l’ultimo client lo lascia. Mentre il canale esiste, ogni client può parlare al canale usando il nome del canale.
I nomi dei canale sono stringhe (che iniziano con il carattere “&” o “#”) di lunghezza massima di 200 caratteri. Separatamente al requisito che il primo carattere deve essere “&” o “#”, la sola restrizione sul nome di un canale è che non deve contenere spazi(“ “), un control G (^G o ASCII 7), o una virgola (“,” che è usata come separatore di lista nel protocollo).
Ci sono due tipi di canali permessi da questo protocollo. Uno è un canale distribuito che è conosciuto a tutti i servers che sono connessi alla rete. Questi canali sono contrassegnati dal primo carattere potendo entrarci un solo client sul server. Questi sono distinti da la carattere “&” all’inizio. In cima a questi due tipi, ci sono le varie modalità del canale che esistono per alterare le caratteristiche di ogni canale. Vedi la sezione 4.2.3 (comando MODE) per maggiori dettagli.
Per creare un nuovo canale o diventare parte del canale esistente, un utente deve entrare nel canale. Se il canale non esiste prima di entrare, il canale è creato e l’utente creatore diventa operatore di canale. Se il canale esiste già, la tua richiesta di entrare nel canale dipende dalle modalità del canale. Per esempio, se il canale è a soli inviti (+i), tu puoi solo entrare se sei invitato. Come parte del protocollo, un utente può prendere parte a vari canali in una volta, ma è raccomandato un limite di dieci (10) canali sia per utenti esperti sia per i nuovi. Vedi la sezione 8.13 per maggiori informazioni.
Se la rete IRC diventa disunita a causa di split tra due server, il canale da una parte è composto di soli clients che sono connessi al server di una rispettiva parte dello split, con la possibilità di cessare di esistere su un lato dello split. Quando lo split è risolto, i server connessi annunciano agli altri che pensano che sia in ogni canale e le modalità del canale. Se il canale esiste in entrambi i lati, le entrate e le modalità sono interpretate in una maniera esclusiva cosicché entrambi i lati della nuova connessione concorderanno su quali clients sono nel canale e quali modalità ha il canale.
1.3.1 Operatori del canale
L’operatore del canale (chiamato anche “chop” o “chanop”) su un canale è considerato il proprietario del canale. In riconoscimento di questo stato, gli operatori del canale sono muniti di alcuni poteri che gli permettono di tenere il controllo del canale. Come proprietario del canale, un operatore di canale non deve dare ragioni per le sue azioni, ma se le sue azioni sono generalmente antisociali o addirittura abusive, si può chiedere l’aiuto di un operatore IRC di intervenire.
I comandi che possono essere usati solo da un operatore di canali sono:
KICK – Caccia qualcuno dal canale
MODE – Cambia le modalità del canale
INVITE - Invita un client su un anale a soli inviti (modalità +i)
TOPIC - Cambia il topic del canale se con una modalità +t
Un operatore è riconoscibile dal simbolo “@” davanti al suo nickname.
Lo specifico di IRC
2.1 Vista dall’alto
Il protocollo come descritto all’interno è per uso sia per le connessioni server-to-server sia client-to-server. Ci sono, comunque, più restrinzione sulle connessioni del clients (che non sono considerati di fiducia) delle connessioni sul server.
2.2 Codici di carattere
Nessun tipo di carattere specifico è specificato. Il protocollo è basato su una serie di caratteri che sono composti di otto (8) bits, formando un ottetto. Ogni messaggio può essere composto di ogni numero di questi ottetti; comunque, alcuni valori degli ottetti sono usati per controllare i codici che agiscono come delimitatori di messaggi.
Riguardo al protocollo a 8 bit, i delimitatori e le parole chiave sono tali che il protocollo è usato maggiormente dal terminale USASCII e una connessione telnet.
Siccome IRC ha origine scandinava, i caratteri {}| sono considerati essere minuscoli ed equivalgono ai caratteri []\, rispettivamente. Questo è un problema nel momento in cui si determina l’equivalenza di due nicknames.
2.3 Messaggi
I servers e i clients si mandano dei messaggi che possono o no generare una risposta. Se il messaggio contiene un comando valido, come descritto nella sezione seguente, il client prevederebbe una risposta come specificato ma non sempre si riceve una risposta; la comunicazione clientserver e serverserver è essenzialmente non sincronizzate in natura.
Ogni messaggio IRC è composto da tre parti fondamentali: il prefisso (opzionale), il comando, e i parametri del comando (che possono essere massimo 15). Il prefisso, il comando, e tutti i parametri sono separati da uno (o più) carattere/i di spazio ASCII (0x20).
La presenza di un prefisso è indicata con un singolo carattere di due punti (“:”, 0x3b), che deve essere il primo carattere del messaggio stesso. Non ci deve essere distanza (spazi vuoti) tra i due punti e il prefisso. Il prefisso è usato dai servers per indicare la vera origine del messaggio. Se il prefisso è omesso dal messaggio, è sottinteso che è stato originato dalla connessione che è stata ricevuta. I clients non dovrebbero usare il prefisso quando mandano un messaggio da loro stessi; se usano un prefisso, il solo prefisso valido è il nickname registrato associato con il client. Se la sorgente identificata dal prefisso non può essere trovata dal database interno del server, o se l’origine è registrata da un differente collegamento da dove il messaggio è arrivato, il server deve ignorare il messaggio silenziosamente.
Il comando deve essere un comando valido IRC o un numero a tre (3) cifre rappresentato nel testo ASCII.
I messaggi IRC sono sempre linee di caratteri che terminano con un CR-LF (Carriage Return – Line Feed, Invio – A capo), e questi messaggi non dovranno superare 512 caratteri di lunghezza, includendo CR-LF. Così, ci sono massimo 510 caratteri consentiti per il comando e i suoi parametri. Non c’è nessuna condizione per la continuazione delle linee del messaggio. Vedi la sezione 7 per maggiori dettagli sulle implementazioni correnti.
Formato dei messaggi in pseudo BNF
I messaggi di protocollo devono essere estratti dai gruppi di ottetti. La soluzione corrente è designare due caratteri, CR e LF, come separatori di messaggi. I messaggi vuoti sono ignorati silenziosamente, e questo permette la sequenza di CR-LF tra i messaggi senza grossi problemi.
Il messaggio estratto è diviso nei componenti < prefisso>, < comando> e una lista di comandi elencati o dal componente < medio> o dal < trailing>.
La rappresentazione BNF per questo è:
< messaggio> ::= [':' < prefisso> < SPAZIO> ] < comando> < parametri> < crlf>
< prefisso> ::= < nomeserver> | < nick> [ '!' < utente> ] [ '@' < host> ]
< comando> ::= < lettera> { < lettera> } | < numero> < numero> < numero>
< SPAZIO> ::= ' ' { ' ' }
< parametri> ::= < SPAZIO> [ ':' < trailing> | < medio> < parametri> ]
< medio> ::= < Ogni sequenza non vuota di ottetti non includendo SPAZIO o NUL o CR o LF, il primo dei quali non deve essere “:”>
< trailing> ::= < Ogni, possibilmente vuoto, sequenza di ottetti escludendo NUL o CR o LF>
< crlf> ::= CR LF
NOTE:
1) < SPAZIO> consiste solo di un carattere SPAZIO (0x20). Si noti soprattutto che la TABULAZIONE, e tutti gli altri caratteri di controllo non sono considerati spazi bianchi.
2) Dopo aver estratto la lista di parametro, tutti i parametri sono uguali, sia con < medio> o < trailing>. < Trailing> è solo un trucco sintattico per permettere lo SPAZIO nel parametro.
3) Il fatto che CR e LF non possono apparire nelle stringhe del parametro è giusto un artificio dell’ossatura del messaggio. Questo potrebbe cambiare in seguito.
4) Il carattere NUL non è speciale nell’ossatura del messaggio, e potrebbe finire nel parametro, ma così potrebbe causare molte complicazioni nella normale gestione della stringa C. Comunque NUL non è ammesso nei messaggi.
L’ultimo parametro può essere una stringa vuota.
6) L’uso dei prefissi estesi (['!' < utente> ] ['@' < host> ]) non deve essere usata nelle comunicazioni serverserver.
La maggior parte dei messaggi del protocollo specificano semantica addizionale e sintassi per le stringhe di parametro estratte dettate dalla loro posizione nella lista. Per esempio, molti comandi del server capiscono che il primo parametro dopo il comando è la lista di obbiettivi, che possono essere descritti con:
< obbiettivo> ::= < a> [ "," < obbiettivo> ]
< a> ::= < canale> | < utente> '@' < nomeserver> | < nick> | < mask>
< canale> ::= ('#' | '&') < stringadicarattere>
< nomeserver> ::= < host>
< host> ::= vedi RFC 952 [DNS:4] per dettagli sugli hostnames permessi
< nick> ::= < lettera> { < lettera> | < numero> | < speciale> }
< mask> ::= ('#' | '$') < stringadicarattere>
< stringadicarattere> ::= < ogni codice 8bit tranne SPAZIO, BELL, NUL, CR, LF e virgola (“,”)>
Altre sintassi di parametro sono:
< utente> ::= < nonbianco> { < nonbianco> }
< lettera> ::= 'a' ... 'z' | 'A' ... 'Z'
< numero> ::= '0' ... '9'
< speciale> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
2.4 Risposte numeriche
La maggior parte dei messaggi mandati al server generano una risposta di una specie. La risposta più comune è la risposta numerica, usata sia per gli errori sia per le risposte normali. La risposta numerica deve essere mandata come un messaggi che consiste del prefisso del mittente, le tre cifre numeriche, e l’obbiettivo della risposta. Una risposta numerica non può essere originata da un client; ogni tale messaggio ricevuto da un server è silenziosamente eliminato. In tutti gli altri casi, una risposta numerica è solo come un messaggio normale, tranne la parola chiave è formata da 3 cifre numeriche piuttosto che una stringa di lettere. Una lista di differenti risposte è elencata nella sezione 6.
3. Concetti di IRC
La sezione è dedicata a descrivere gli attuali concetti tra l’organizzazione del protocollo IRC e di come le implementazioni correnti mandano diverse classi di messaggi.
1--\
A D---4
2- \ /
B----C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
[ Fig. 2. Semplice rete IRC ]
3.1 Comunicazione uno a uno
La comunicazione su base uno a uno è spesso solo usata dai clients, dal momento che la maggior parte del traffico serverserver non è un risultato di servers che parlano solo ad altri. Per permettere ai clients di parlare ad altri, è necessario che tutti i servers siano capaci di mandare un messaggio in esattamente una direzione lungo l’albero dei server per far reagire ogni client. Il percorso di un messaggio che è stato mandato è il percorso più breve tra i due punti della rete.
I seguenti esempi si riferiscono tutti alla Figura 2.
Esempio 1:
Un messaggio tra i clients 1 e 2 è solo visto dal server A, che lo manda diritto al client 2.
Esempio 2:
Un messaggio tra i clients 1 e 3 è visto dai servers A e B, e dal client 3. Nessun altro client o server può vedere il messaggio.
Esempio 3:
Un messaggio tra i clients 2 e 4 è visto dai server A, B, C e D e solo dal client 4.
3.2 Uno a tanti
Il grande scopo di IRC è creare un forum che permette semplici e efficienti conferenze (cioè confermazioni da uno a tanti). IRC offre vari modi per farlo, ognuno seguendo il loro scopo.
3.2.1 A una lista
Lo stile meno efficiente della conversazione uno a tanti è quando i clients parlano a una lista di utenti. Come avviene è facile da spiegare: il client dà una lista di destinazioni al quale il messaggio deve essere inviato, poi il server lo ferma e smista una copia separata del messaggio ad ogni destinazione. Questo non è efficiente come usare un gruppo poiché la lista di destinazione è interrotta e lo smistamento mandato senza controllare duplicati che sono mandati.
3.2.2 A un gruooi (canale)
In IRC il canale ha un ruolo equivalente a quello del gruppo multicast; la sua esistenza è dinamica (viene e va a seconda che la gente entri o esca dal canale) e l’attuale conversazione ai canali è solo mandata ai server che supportano gli utenti su un canale. Se ci sono molti utenti su unserver nello stesso canale, il messaggio di testo è mandato solo una volta a quel server e poi mandato ad ogni client sul canale. Questa azione è poi ripetuta per ogni combinazione client-server affinché il messaggio originale è mandato a ogni membro del canale.
Gli esempi seguenti sono riferiti alla Figura 2.
Esempio 4:
Ogni canale con 1 client all’interno. I messaggi al canale vanno al server e poi da nessun altra parte.
Esempio 5:
2 clients nel canale. Tutti i messaggi attraversano un percorse come se fossero messaggi privati tra due clients fuori dal canale.
Esempio 6:
3 clients nel canale. Tutti i messaggi nel canale sono mandati a tutti i clients e solo quei server che devono essere attraversati dal messaggio se erano messaggi privati a un singolo client. Se il client 1 manda un messaggio, va al client 2 e poi tramite il server B al client 3.
A un host/maschera di server
Per permettere agli operatori di IRC alcuni meccanismi per mandare i messaggi a un grande numero di utenti, i messaggi a un host o maschera di server sono permessi. Questi messaggi sono mandati agli utenti i quali host compaiono nella maschera. I messaggi sono solo mandati alle locazioni dove ci sono gli utenti, in un modo simile a quelli dei canali.
3.3 Uno a tutti
Il tipo di messaggio uno a tutti è più noto come messaggi broadcast, mandato a tutti i clients o servers o entrambi. Su una grande rete di utenti e servers, un singolo messaggio può finire nel gran traffico nella rete rendendo difficile l’arrivo alle destinazioni desiderate.
3.3.1 Client a client
Non ci sono classi di messaggi che, da un singolo messaggio, risultano in un messaggio che è stato mandato a tutti gli altri client.
3.3.2 Client a server
La maggior parte dei comandi che risultano in un cambio di informazioni di stato (come appartenenza al canale, modalità del canale, stato dell’utente, ecc.) devono essere mandati a tutti i servers, e questa distribuzione può non essere cambiata dal client.
3.3.3 Server a server
Mentre la maggior parte dei messaggi tra servers è distribuita a tutti gli altri servers, questo è solo richiesto per ogni messaggio che riguarda un utente, canale o server. Poiché questi sono articoli di base trovati in IRC, quasi tutti i messaggi originati da un server sono trasmessi a tutti gli altri servers connessi.
4. Dettagli dei messaggi
Nelle pagine seguenti ci sono le descrizioni di ogni messaggio riconosciuto dal server IRC e dal client. Tutti i comandi descritti in questa sezione devono essere aggiunti da ogni server per questo protocollo.
Dove la risposta ERR_NOSUCHSERVER è mostrata, vuol dire che il parametro del server non potrebbe essere trovato. Il server non deve mandare ogni altra risposta dopo questo per questo o quel comando.
Il server al quale il client è connesso deve far apparire il messaggio completo, riportando ogni errore. Se il server incontra un fatal error mentre fa apparire il messaggio, un errore deve essere mandato al client e l’apparizione terminata. Un fatal error può essere considerato essere un comando non corretto, una destinazione sconosciuta al server (i nomi di server, nick o canale appartengono a questa categoria), non abbastanza parametri o privilegi incorretti.
Se un settaggio intero di parametri è presente, ognuno deve essere controllato per la validità e i responsi appropriati mandati al client. Nel caso dei messaggi che usano delle liste di parametri usando la virgola come un separatore di voci, una risposta deve essere mandata per ogni voce.
Nell’esempio seguente, alcuni messaggi usano il formato completo:
:Nome COMANDO lista di parametri
Tale esempio rappresenta un messaggio da “Nome” nel transito tra i servers, dove è essenziale includere il nome del mittente originale così i servers remoti possono mandare una risposta lungo il percorso corrente.
4.1 Registrazione di connessione
I comandi descritti qui sono usati per registrare una connessione con un server IRC oppure come disconnettersi correttamente.
Un comando “PASS” non è richiesto per ciascuna connessione client o servers per essere registrata, ma deve precedere il messaggio del server o la combinazione NICK/USER. È raccomandato che tutti le connessioni del server hanno una password per dare un livello di sicurezza alle attuali connessioni. L’ordine raccomandato per un client è il seguente:
1. Messaggio di password
2. Messaggio di nick
3. Messaggio di utente
4.1.1 Comando Password
Comando: PASS
Parametri: < password
Il comando PASS è usato per settare una “connessione con password”. La password può e deve essere settata prima ogni tentativo di registrare la connessione fatta. Correntemente questo necessita che i clients mandino un comando PASS prima di mandare una combinazione NICK/USER e i servers devono mandare un comando PASS prima ogni comando SERVER. La password fornita deve mostrare il solo contenuto nelle linee C/N (per i servers) o le linee I (per i clients). È possibile mandare molti comandi PASS prima di registrarsi ma solo l’ultimo mandato è usato per la verifica e non può essere cambiato una volta registrato. Risposte numeriche:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
Esempio:
PASS passworsegreta
4.1.2 Comando Nick
Comando: NICK
Parametri: < nickname> [ < hopcount> ]
Il messaggio NICK è usato per dare all’utente un nickname o cambiare il precedente. Il parametro < hopcount> è usato solo per indicare quanto è lontano il nick dal server di partenza. Una connessione locale ha un hopcount di 0. Se dato da un client, può essere ignorato.
Se un messaggio NICK arriva a un server che già conosce un nickname identico per un altro client, accade una collisione di nickname. Come risultato di una collisione di nickname, tutti gli esempi di nickname sono rimossi dal database del server, e un comando KILL è dato per rimuovere il nickname da tutti i database del server. Se il messaggio NICK che causa la collisione era un cambio di nick, il nick originale (vecchio) deve essere rimosso subito.
Se il server riceve un identico NICK da un client che è connesso direttamente, può dare un ERR_NICKC
Transfer interrupted!
il comando NICK, e non generare nessun kill.
Risposte numeriche:
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION
Esempio:
NICK Wiz ; Introduce un nuovo nick “Wiz”.
:WiZ NICK Kilroy ; WiZ cambia il suo nick a Kilroy.
4.1.3 Comando User
Comando: USER
Parametri: < nomeutente> < nomehost> < nomeserver> < nomereale>
Il comando USER è usato all’inizio della connessione per specificare il nome utente, il nome host, il nome del server e il nome reale di un nuovo utente. È ance usato nella comunicazione tra i servers per indicare che un nuovo utente sta entrando in IRC, poiché solo dopo sia USER che NICK che sono stati ricevuti da un client fanno sì che un utente diventa registrato.
Tra i servers USER deve essere prefissato con il NICKname del client. Nota che il nome dell’host e il nome del server sono normalmente ignorati dal server IRC quando il comando USER viene da una connessione diretta (per ragioni di sicurezza), ma sono usati nella comunicazione serverserver. Questi significa che un NICK deve sempre essere mandato a un server remoto quando un nuovo utente si sta inserendo al resto della rete prima che USER sia mandato.
Deve essere notato che il comando nome reale deve essere l’ultimo parametro, perché può contenere spazi e deve essere prefissato con due punti (“:”) per essere sicuri che è riconosciuto come tale.
Poiché è facile per un client mentire riguardo al suo nome utente contando solo sul comando USER, l’usto di un “Server d’Identificazione” è raccomandato. Se l’host al quale l’utente si collega ha un tale server abilitato il nome utente è settato come è mostrato nella risposta del “Server d’Identificazione”.
Risposte numeriche:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
Esempi:
USER guest tolmoon tolsun :Ronnie Reagan
; Un utente si sta registrando con un nome utente di “guest” e un nome reale di “Ronnie Reagan”.
:testnick USER guest tolmoon tolsun :Ronnie Reagan
; il messaggio tra i servers con il nickname per il quale il comando USER appartiene.
4.1.4 Comando Server
Comando: SERVER
Parametri: < nomeserver> < hopcount> < info>
Il comando server è usato per connettersi ad un server. Questo comando è anche usato per trasmettere dati di server lungo l’intera rete. Quando un nuovo server è connesso ad una rete, l’informazione su di esso verrà trasmessa all’intera rete. < hopcount> è usato per dare a tutti i servers alcune informazioni interne su come sono tutti i servers. Con una lista di tutti i servers, sarebbe possibile costruire una mappa dell'intero albero dei servers, ma le hostmasks non permetto che questo venga fatto.
Il comando SERVER deve solo essere accettato da ciascuna (a) connessione che è tuttavia registrata e sta provando di registrarsi come un server, o (b) una connessione esistente a un altro server, nel quale caso il messaggio SERVER sta introducendo un nuovo server dietro quel server.
La maggior parte degli errori che avvengono con la ricezione di un comando SERVER fanno sì che la connessione venga terminata dall’host di destinazione (SERVER obbiettivo). Risposte d’errore sono spesso mandate con il comando “ERROR” più che un numerico poiché il comando ERROR ha molte proprietà che lo rendono più facile da usare.
Se un comando SERVER è comparso e cerca di introdurre un server che è già conosciuto al server ricevente, la connessione deve essere chiusa (seguendo le corrette procedure), poiché viene assegnato un doppio itinerario a un server e il ciclo naturale dell’albero IRC si rompe.
Risposte numeriche:
ERR_ALREADYREGISTRED
Esempio:
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
; Il nuovo server test.oulu.fi si sta inserendo e cerca di registrarsi. Il nome nelle parentesi [] è il nome host per chi vuole accedere al server.
4.1.5 Comando Operator
Comando: OPER
Parametri: < utente> < password>
Il comando OPER è usato da un utente normale per ottenere i privilegi da operatore. La combinazione di < user> e < password> è richiesta per dare i privilegi da operatore.
Se il client che manda il comando OPER manda anche la password corretta per l’utente dato, il server informa il resto della rete del nuovo operatore per l’assegnamento di un “MODE +o” al nickname del client.
Il comando OPER è solo clientserver.
Risposte numeriche:
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH
Esempio:
OPER foo bar ; Cerca di registrarsi come un operatore usando un nome utente “foo” e “bar” come password.
4.1.6 Comando Quit
Comando: QUIT
Parametri: [< messaggio di Quit >]
Una sessione di un client è terminata con un comando QUIT. Se un “messaggio di Quit” è dato, questo verrà mandato al posto del messaggio standard, il nick.
Quando accadono dei netsplits (disconnessione di due servers), il messaggio di quit è composto dai nomi dei due servers interessati, separati da uno spazio. Il primo nome è quello del server che è ancora connesso e il secondo nome è quello del server che è stato disconnesso.
Se, per alcune ragioni, una connessione client è chiusa senza che il client usi il comando QUIT (es: il client muore e accade un EOF sul socket), il server è obbligato a far apparire nel messaggi di quit delle spiegazioni riguardanti quello che è successo.
Risposte numeriche:
Nessuna.
Esempi:
QUIT :Gone to have lunch ; Modo preferito del messaggio.
4.1.7 Comando Server Quit
Comando: SQUIT
Parametri: < server> < commento>
Il comando SQUIT è necessario per parlare dei quit e dei server morti. Se un server desidera interrompere la connessione verso un altro server deve mandare un comando SQUIT a un altro server, usando il nome dell’altro server come parametro di server, che poi chiuderà la sua connessione con il server che si disconnette.
Questo comando è anche possibile agli operatore per aiutare a tenere la rete di servers IRC connessi in un modo ordinato. Gli operatori potrebbero anche eseguire un comando SQUIT per una connessione ad un server remoto. In questo caso, l’SQUIT deve essere mostrato da ogni server tra l’operatore e il server remoto, aggiornando la vista della rete tenuta da ogni server come spiegato sopra.
Il < commento> potrebbe essere aggiunto da ogni operatore che esegue uno SQUIT per un server remoto (che non è connesso al server che sono collegati correntemente) cosìcche gli altri operatori sono avvisati per la ragione di questa azione. Il < commento> è anche compilato dai servers che possono trovare un errore o un messaggio simile.
Entrambi i servers che sono su ciascuna parte della connessione che sta per essere chiusa sono obbligati a diramare un comando SQUIT (a tutti gli altri server connessi) per tutti i servers che sono considerati essere dietro quel collegamento.
In maniera simile, un comando QUIT deve essere mandato agli altri servers connessi. In più, a tutti i componenti di un canale che perde un membro dovuto a uno split deve essere mandato un comando QUIT.
Se la connessione di un server è terminata prematuramente (es. il server alla fine del collegamento muore), il server che detiene questa disconnessione è obbligato a informare al resto della rete che la connessione è chiusa e compila il campo commento con qualcosa di appropriato.
Risposte numeriche:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
Esempio:
SQUIT tolsun.oulu.fi :Bad Link ? ; il collegamento al server tolson.oulu.fi è stata terminata per un “Bad Link” (cattivo collegamento).
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
; il messaggio da Trillian per disconnettere "cm22.eng.umd.edu" dalla rete perché il “Server out of control” (server fuori controllo).
4.2 Operazioni del canale
Il gruppo di messaggi riguardanti la manipolazione dei canali, le loro proprietà (modalità del canale), e il loro contenuto (tipicamente clients). Aggiungendo queste cose, un numero di condizioni di corsa sono inevitabili quando i clients all’altra parte della rete manda comandi che si scontreranno alla fine. È anche obbligatorio che i servers tengano una lista di nicknames per assicurare che dovunque venga dato un parametro < nick>, il server controlli la sua lista nel caso che è stato recentemente cambiato.
4.2.1 Comando Join
Comando: JOIN
Parametri: < canale>{,< canale>} [< chiave>{,< chiave>}]
Il comando JOIN è usato da un client per cominciare ad ascoltare un canale specifico. Se un client è autorizzato o no a entrare in un canale è controllato solo dal server sul quale il client è connesso; tutti gli altri servers automaticamente aggiungeranno l’utente al canale quando è ricevuto dagli altri servers. Le condizioni che permettono questo sono come seguono:
1. l’utente deve essere invitato se il canale è a soli inviti;
2. il nick/nomeutente/nomehost dell’utente non deve avere dei bans a carico;
3. la corretta chiave (password) deve essere data se è settata.
Questi sono discussi in maggiori dettagli sotto il comando MODE (vedi la sezione 4.2.3 per più dettagli).
Una volta che un utente entra in un canale, essi ricevono un avviso su tutti i comandi che i loro servers ricevono che usano il canale. Questo include MODE, KICK, PART, QUIT e certamente PRIVMSG/NOTICE. Il comando JOIN ha bisogno di essere trasmesso a tutti i servers cosicché ogni server sa dove trovare gli utenti che sono sul canale. Questo permette invii ottimali di messaggi PRIVMSG/NOTICE al canale.
Se un JOIN ha successo, l’utente è mandato al topic del canale (usando RPL_TOPIC) e la lista di utenti che sono sul canale (usando RPL_NAMREPLY), che devono includere l’utente che sta entrando.
Repliche numeriche:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC
Esempi:
JOIN #foobar ; entra nel canale #foobar.
JOIN &foo fubar ; entra nel canale &foo usando la chiave "fubar".
JOIN #foo,&bar fubar ; entra nel canale #foo usando la chiave "fubar" e in &bar non usando chiavi.
JOIN #foo,#bar fubar,foobar ; entra nel canale #foo usando la chiave “fubar e nel canale #bar usando la chiave “foobar”.
JOIN #foo,#bar ; entra nei canali #foo e #bar.
:WiZ JOIN #Twilight_zone ; comando JOIN da WiZ
4.2.2 Comando PART
Comando: PART
Parametri: < canale>{,< canale>}
Il comando PART permette al client di lasciare il canale.
Risposte numeriche:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL
Esempi:
PART #twilight_zone ; lascia il canale "#twilight_zone"
PART #oz-ops,&group5 ; lascia i canali "&group5" e "#oz-ops".
4.2.3 Comando Mode
Comando: MODE
Il comando MODE ha due scopi in IRC. Permette sia agli utenti che ai canali di avere di cambiare le loro modalità. Il fondamento logico per questa scelta è che un giorno i nicknames saranno obsoleti e la proprietà equivalente sarà il canale.
Quando compaiono messaggi di MODE, è raccomandato che l’intero messaggio compaia prima e poi i cambiamenti che succedono una volta che è comparso.
4.2.3.1 Modalità del canale
Parametri: < canale> {[+|-]|o|p|s|i|t|n|b|v} [< limite>] [< utente>] [< maschera ban>]
Il comando MODE è creato cosicché gli operatori di quel canale potranno cambiare le caratteristiche del loro canale. È anche necessario che quei servers siano capaci di cambiare le modalità del canale cosicché gli operatori di canale potranno farlo.
Le varie modalità a disposizione per i canali sono le seguenti:
o – dà/leva a un utente lo stato di operatore di canale;
p – canale privato;
s – canale segreto;
i – canale a soli inviti;
t – topic settabile da solo gli operatori del canale;
n – niente messaggi dagli utenti al di fuori del canale;
m – canale moderato;
l – canale a numero ristretto di utenti;
b – setta una maschera ban per tenere gli utenti fuori;
v – dà/leva l’abilità di parlare in un canale moderato;
k – setta una chiave per il canale (password).
4.2.3.2 Modalità dell’utente
Parametri: < nickname> {[+|-]|i|w|s|o}
Le modalità dell’utente sono tipicamente cambiate se un utente vuole essere visibile o se vuole ricevere messaggi “extra”. Un comando MODE per gli utenti può solo essere accettato solo se il mittente del messaggio e il nick dato sono uguali.
Le modalità a disposizione sono le seguenti:
i – setta un utente invisibile;
s – setta un utente abile a ricevere messaggi del server;
w – l’utente riceverà i wallops;
o – operatore.
Modalità addizionali saranno possibili in seguito.
Se un utente cerca di fare operatore se stesso usando la modalità “+o”, il comando verrà ignorato. Non ci sono restrizioni, comunque, su ciascuno che si “deopperà” (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 di modalità del canale:
MODE #Finnish +im ; rende il canale #Finnish moderato e a soli inviti.
MODE #Finnish +o Kilroy ; dà a Kilroy lo stato di operatore del canale.
MODE #Finnish +v Wiz ; permette a WiZ a parlare in #Finnish.
MODE #Fins –s ; rimuove la modalità “segreto” al canale #Fins.
MODE #42 +k oulu ; setta la chiave “oulu” al canale.
MODE #eu-opers +l 10 ; setta il limite di 10 utenti al canale.
MODE &oulu +b ; lista dei ban del canale.
MODE &oulu +b *!*@* ; non permette di entrare a nessun utente.
MODE &oulu +b HYPERLINK mailto:*!*@*.edu *!*@*.edu ; non permette di entrare agli utenti che hanno *.edu nell’host.
:MODE WiZ –w ; non fa ricevere a WiZ i wallops.
:Angel MODE Angel +i ; messaggio da Angel per diventare invisibile.
MODE WiZ –o ; WiZ si 'deoppa' (rimuove il suo stato si operatore). Il comando inverso di questo (“MODE WiZ +o”) non è permesso dagli utenti che vorrebbero saltare il comando OPER.
4.2.4 Comando TOPIC
Comando: TOPIC
Parametri: < canale> [< topic>]
Il comando TOPIC è usato per cambiare o visualizzare il topic di un canale. Il topic per il canale < canale> è mostrato se non è dato < topic>. Se il parametro < topic> è presente, il topic per quel canale sarà cambiato, se le modalità del canale permettano questa azione.
Risposte numeriche:
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED
Esempi:
:Wiz TOPIC #test :New topic ; l’utente Wiz setta il topic.
TOPIC #test :another topic ; setta il topic su #test.
TOPIC #test ; mostra il topic di #test.
4.2.5 Comando Names
Comando: NAMES
Parametri: [< canale>{,< canale>}]
Usando il comando NAMES, un utente puù avere una lista di nicknames che sono visibili. I nomi del canale che possono essere visti sono quelli che non sono privati (+p) o segreti (+s) o quelli che sono attualmente in uso. Il parametro < canale> specifica il canale di cui vogliamo avere delle informazioni. Non ci sono risposte di errore per nomi di canali non buoni.
Se nessun parametro < canale> è dato, una lista di tutti i canali e dei loro occupanti è mostrata.
Risposte numeriche:
RPL_NAMREPLY RPL_ENDOFNAMES
Esempi:
NAMES #twilight_zone,#42 ; lista gli utenti visibili su #twilight_zone e su #42 se i canali sono visibili.
NAMES ; lista tutti i canali visibili e i rispettivi utenti.
4.2.6 Comando List
Comando: LIST
Parametri: [< canale>{,< canale>} [< server>]]
Il comando list è usato per mostrare i canali e i rispettivi topics. Se è usato il parametro < canale>, è visualizzato solo lo stato di quel canale. I canali privati sono listati (senza i loro topics) come canali “Prv” a meno che il client che pone la domanda è attualmente su quel canale. Nello stesso modo, i canali segreti non sono listati a tutti a meno che il client è un membro del canale in questione.
Risposte numeriche:
ERR_NOSUCHSERVER RPL_LISTSTART
RPL_LIST RPL_LISTEND
Esempi:
LIST ; lista tutti i canali.
LIST #twilight_zone,#42 ; lista i canali #twilight_zone e #42
4.2.7 Comando Invite
Comando: INVITE
Parametri: < nickname> < canale>
Il comando INVITE è usato per invitare gli utenti in un canale. Il parametro < nickname> è il nickname della persona invitata al canale < canale>. Non ci sono obblighi che un utente possa invitare un canale in un canale non esistente o non valido. Per invitare un utente in un canale che è a soli inviti (MODE +i), il client che manda l’invito deve essere riconosciuto operatore del canale.
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: < canale> < utente> [< commento>]
Il comando KICK può essere usato per rimuovere un utente da un canale.
Solo l’operatore del canale può “kickare” un altro utente dal canale. Ogni server che riceve un messaggio KICK controlla che è valido (se per esempio il mittente è un operatore del canale) prima di rimuovere la vittima da quel canale.
Risposte numeriche:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_NOTONCHANNEL
Esempi:
KICK &Melbourne Matthew ; kicka Matthew da &Melbourne
KICK #Finnish John :Speaking English
; kicka John da #Finnish usando “Speaking English” come motivo (commento).
:WiZ KICK #Finnish John ; comando KICK da WiZ per rimuovere John dal canale #Finnish.
NOTA:
È possibile estendere i parametri del comando KICK come i seguenti:
< canale>{,< canale>} < utente>{,< utente>} [< commento>]
4.3 Domande e comandi del server
Il gruppo di comandi per interrogare il server è stato creato per mostrare delle informazioni su ogni server che è connesso alla rete. Tutti i servers connessi devono rispondere a queste domande e rispondere correttamente. Ogni risposta non valida deve essere considerata un segnale di un server rotto e deve essere disconnesso/disabilitato al più presto.
4.3.1 Comando Version
Comando: VERSION
Parametri: [< server>]
Il comando VERSION è usato per chiedere la versione del programma del server. Un parametro opzionale < server> è usato per interrogare la versione di un altro programma del server da cui il client non è direttamente connesso.
Risposte numeriche:
ERR_NOSUCHSERVER RPL_VERSION
Esempi:
:Wiz VERSION *.se ; comando da Wiz per verificare la versione di un server che finisce con “.se”.
VERSION tolsun.oulu.fi ; verifica la versione del server "tolsun.oulu.fi".
4.3.2 Comando Stats
Comando: STATS
Parametri: [< domanda> [< server>]]
Il comando STATS è usato per chiedere le statistiche di un determinato server. Se il parametro < server> è omesso, è mostrata solo la fine della risposta stats. L’aggiunta di questo comando dipende dal server che risponde, benché il server deve essere capace di fornire delle informazioni come descritto dalle domande fatte (o simili).
Una domanda può essere data da una singola lettera che è solo controllata dal server di destinazione (se dato come il parametro < server>) ed è mostrata dai server in mezzo, ignorata e non alterata. Le domande seguenti sono quelle trovate nell’implementazione IRC corrente e prevedono una grande porzione delle informazioni di setup per quel server. Sebbene quelle non potrebbero essere supportate allo stesso modo da altre versioni, tutti i servers sono capaci di fornire una valida risposta a una domanda STATS che comprendono un formato correntemente in uso e lo scopo della domanda.
Le domande correntemente supportate sono:
c – mostra una lista di servers dai quali il server può connettersi o permettono la forma di connessione;
h – mostra una lista di servers che sono forzati ad essere usati se cominciano o finiscono di essere usati come hubs;
i – mostra una lista di hosts dai quali il server permette a un client di connettersi;
k – mostra una lista di combinazioni nomehost/nomeutente bannati in quel server;
l – mostra una lista di connessioni del server, mostrando quanto è lunga ogni connessione che è stata stabilita ed il traffico su quella connessione in bytes e i messaggi per ogni direzione;
m – mostra una lista di comandi supportati dal server l’uso per ognuno di essi;
o – mostra una lista di hosts dai quali i normali utenti possono diventare operatori;
y – mostra le Y (Classe) lines dal file di configurazione del server;
u – mostra una stringa che mostra da quanto tempo il server è attivo.
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 ; mostra l’uso dei comandi per il server su cui sei connesso.
:Wiz STATS c eff.org ; richiesta da WiZ per l’informazione di C/N line per il server eff.og
4.3.3 Comando Links
Comando: LINKS
Parametri: [[< server remoto>] < maschera del server>]
Con LINKS, un utente può listare tutti i servers che sono conosciuti dal server a cui viene effettuata la richiesta. La lista risultante di servers deve mostrare la maschera, o se non è data la maschera, l’intera lista.
Se < server remoto> è dato in aggiunta a < maschera del server>, il comando LINKS è indirizzato al primo server trovato che mostra quel nome (se esiste), e quel server è poi obbligato a dare una risposta.
Risposte numeriche:
ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKS
Esempi:
LINKS *.au ; mostra tutti i server che hanno un nome che finisce con “.au”;
:WiZ LINKS *.bu.edu *.edu ; comando LINKS da WiZ al primo server che finisce con “.edu” per una lista di server che finiscono con “.bu.edu”.
Comando Time
Comando: TIME
Parametri: [< server>]
Il comando time è usato per chiedere l’orario locale dal server specificato. Se il parametro server non è dato, il server che riceve il comando deve dare la risposta.
Risposte numeriche:
ERR_NOSUCHSERVER RPL_TIME
Esempi:
TIME tolsun.oulu.fi ; controlla il tempo sul server "tolson.oulu.fi"
Angel TIME *.au ; l’utente Angel controlla il tempo su un server che termina con “.au”.
4.3.5 Comando Connect
Comando: CONNECT
Parametri: < server > [< porta> [< server remoto>]]
Il comando CONNECT può essere usato per forzare un server a provare una connessione con un altro server. CONNECT è un comando privilegiato e può essere usato solo dagli Operatori IRC. Se un server remoto è dato il tentativo CONNECT è cerca di collegarlo al server < server> e alla porta < porta>.
Risposte numeriche:
ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMS
Esempi:
CONNECT tolsun.oulu.fi ; Cerca di connettersi al server tolsun.oulu.fi.
:WiZ CONNECT eff.org 6667 csd.bu.edu
; tentativo di connessione da WiZ per far connettere i servers eff.org e csd.bu.edu sulla porta 6667.
4.3.6 Comando Trace
Comando: TRACE
Parametri: [< server>]
Il comando TRACE è usato per trovare la strada del server specificato. Ogni server che riceve questo messaggio deve rispondere al mittente con una risposta indicando quali servers attraversa, formando una catena di risposte simile a quella data quando si usa il comando “traceroute”. Dopo aver mandato questa risposta, esso deve mandare il comando TRACE al prossimo server fin quando non reagisce. Se il parametro < server> è omesso, è raccomandato che il comando TRACE mandano un messaggio al mittente dicendo a quali server ha diretta connessione il server corrente.
Se la destinazione data da "< server>" è un server attuale, il server destinazione è obbligatorio per riportare tutti i servers e gli utenti che sono connessi a questo, sebbene solo gli operatori sono autorizzati a vedere gli utenti presenti. Se la destinazione data da < server> è un nickname, solo una risposta per quel nick è data.
Risposte numeriche:
ERR_NOSUCHSERVER
Se il comando TRACE è destinato ad un altro server, tutti i servers in mezzo devono dare una risposta RPL_TRACELINK per indicare che il TRACE è passato attraverso questo e dove è andato dopo.
RPL_TRACELINK
Una risposta TRACE può essere composta da ogni numero delle seguenti delle 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 a un server che finisce con “.oulu.fi”
:WiZ TRACE AngelDust ; TRACE mandato da WiZ a un nick AngelDust
4.3.7 Comando Admin
Comando: ADMIN
Parametri: [< server>]
Il comando ADMIN è usato per trovare il nome dell’amministratore del server dato, o del server corrente se il parametro < server> è omesso. Ogni server deve avere l’abilità di indirizzare il comando ADMIN agli altri servers.
Risposte numeriche:
ERR_NOSUCHSERVER
RPL_ADMINME RPL_ADMINLOC1
RPL_ADMINLOC2 RPL_ADMINEMAIL
Esempi:
ADMIN tolsun.oulu.fi ; richiede una risposta ADMIN da tolsun.oulu.fi
:WiZ ADMIN *.edu ; richiesta ADMIN da WiZ per il primo server trovato che finisce con “.edu”.
4.3.8 Comando Info
Comando: INFO
Parametri: [< server>]
Il comando INFO è obbligatorio per mostrare le informazioni che descrivono il server: la sua versione, quando è stato compilato, il patchlevel, da quando è online, e ogni informazione varia che può essere considerata essere rilevante.
Risposte numeriche:
ERR_NOSUCHSERVER
RPL_INFO RPL_ENDOFINFO
Esempi:
INFO csd.bu.edu ; richiedi una risposta INFO da csd.bu.edu
:Avalon INFO *.fi ; la richiesta INFO da Avalon per il primo server trovato che finisce con “.fi”.
INFO Angel ; richiesta di informazione dal server che Angel è connesso.
4.4 Mandare i messaggi
Il grande scopo del protocollo IRC è provvedere una base per i clients per comunicare tra di loro. PRIVMSG e NOTICE sono i soli messaggi a disposizione che attualmente permettono di mandare messaggi di testo da un client a un altro.
4.4.1 Messaggi Privati
Comando: PRIVMSG
Parametri: < ricevitore>{,< ricevitore>} < testo da mandare>
PRIVMSG è usato per mandare messaggi privati tra gli utenti. < ricevitore> è il nickname del destinatario del messaggio. < ricevitore> può essere anche una lista di nomi o canali separati da una virgola.
Il parametro < ricevitore> può anche essere una maschera host (#mask) o una maschera di server ($sever). In entrambi i casi il server manderà il PRIVMSG a coloro i quali hanno un server o un’host che compare nella maschera. La maschera deve avere almeno 1 (un) “.” all’interno e non ci sono wildcards seguenti l’ultimo “.”. Questo requisito esiste per prevenire la gente di mandare messaggi a “#*” o “$*”, che li invieranno a tutti gli utenti. Le wildcards sono i caratteri “*” e “?”. Questa estensione al comando PRIVMSG è solo abilitata agli operatori. s.
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 a Angel.
PRIVMSG jto@tolsun.oulu.fi :Hello !
; Messaggio a un client sul server tolsun.oulu.fi con il nomeutente di “jto”.
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
; Messaggio a tutti su un server che ha un nome che finisce con “.fi”.
PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
; Messaggio a tutti gli utenti che vengono da un host che finiscono con “.edu”.
4.4.2 Notice
Comando: NOTICE
Parametri: < nickname> < testo>
Il comando NOTICE è usato come al PRIVMSG. La differenza tra NOTICE e PRIVMSG è che le risposte automatiche non devono essere mandate in risposta al comando NOTICE. Questa regola è applicata anche ai servers – non devono mandare nessun errore al clinet in ricezione della notice. L’oggetto di questa regola è per evitare ripetizioni tra un client che manda automaticamente qualcosa in risposta a qualcosa che ha ricevuto. Questo è tipicamente usato dagli automi che sono sempre visti per essere risposti per paura che finiscano in una ripetizione con un altro automa.
Vedi PRIVMSG per maggiori dettagli sulle risposte e sugli esempi.
4.5 Richieste utente
Le richieste dell’utente sono un gruppo di comandi che si preoccupano primariamente di trovare dettagli su un particolare utente o un gruppo di utenti. Quando si usano wildcards con ognuno di questi comandi, se vengono trovati risultati, verranno mostrate solo informazioni su utenti che sono “visibili” da te. La visibilità di un utente è determinata da una combinazioni di modalità dell’utente e il gruppo di canali comuni in cui siete entrambi.
4.5.1 Richiesta Who
Comando: WHO
Parametri: [< nome> [< o>]]
La richiesta WHO è usata da un cliente per generare una domanda dalla quale risponde una lista di informazioni che riguardano il parametro < nome>, tutti i visibili (gli utenti che non sono invisibili (modalità dell’utente +i) e chi non ha canale comune con il client che richiede) sono mostrati. Lo stesso risultato può essere ottenuto usando come < nome> “0” o ogni wildcard che finisce di mostrare ogni voce possibile.
Il < nome> scritto in WHO è cercato negli host degli utenti, del server, del vero nome e del nickname se il canale < nome> non può essere trovato.
Se il parametro “o” è aggiunto solo gli operatori sono mostrati secondo il nome della maschera inserita.
Risposte numeriche:
ERR_NOSUCHSERVER
RPL_WHOREPLY RPL_ENDOFWHO
Esempi:
WHO *.fi ; Lista tutti gli utenti che finiscono con “.fi”.
WHO jto* o ; Lista tutti gli utenti che cominciano con “jto” e sono operatori.
4.5.2 Richiesta WhoIs
Comando: WHOIS
Parametri: [< server>] < maschera del nick>[,< maschera del nick>[,...]]
Questa richiesta è usata per chiedere informazioni su un particolare utente. Il server risponderà a questo messaggio con vari messaggi numerici indicanti le differenti statistiche di ogni utente che contengono la maschera del nick (se vuoi vedere quella). Se non ci sono wildcards presenti nella < maschera del nick>, ogni informazione su quel nick che sei autorizzato a visualizzare è presentata. Una virgola (“,”) può essere messa per separare i nicknames della lista.
La versione più recente manda una richiesta a un server specifico. Questo è usato soprattutto se vuoi sapere da quanto tempo l’utente in questione è fermo come solo server locale (es. il server e l’utente sono connessi direttamente) conosce quell’informazione, mentre il resto è conosciuto globalmente.
Risposte numeriche:
ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
RPL_WHOISUSER RPL_WHOISCHANNELS
RPL_WHOISCHANNELS RPL_WHOISSERVER
RPL_AWAY RPL_WHOISOPERATOR
RPL_WHOISIDLE ERR_NOSUCHNICK
RPL_ENDOFWHOIS
Esempi:
WHOIS wiz ; mostra le possibili informazioni sul nick WiZ.
WHOIS eff.org trillian ; chiede al server eff.org delle informazioni su trillian.
4.5.3 WhoWas
Comando: WHOWAS
Parametri: < nickname> [< count> [< server>]]
WhoWas chiede informazioni sul nickname che non esiste più. Questo può essere dovuto a un cambio di nick o a una disconnessione dell’utente. In risposta a questa query, il server cerca nella lista dei suoi nicknames, guardando ogni nick che è lessicalmente lo stesso. La lista è esaminata partendo dalla fine, in modo tale di fornire le informazioni più recenti. Se ci sono più voci, verranno mostrate quante sono chieste nel parametro < count> (o tutte se il parametro non viene dato). Se viene inserito un numero non positivo nel parametro < count>, sarà fatta una ricerca completa.
Risposte numeriche:
ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
RPL_WHOWASUSER RPL_WHOISSERVER
RPL_ENDOFWHOWAS
Esempi:
WHOWAS Wiz ; mostra tutte le informazioni della lista sul nick “WiZ”.
WHOWAS Mermaid 9 ; mostra le ultime 9 voci della lista per il nick “Mermaid”.
WHOWAS Trillian 1 *.edu ; mostra la voce più recente per “Trillian” dal primo server trovato che finisce con “.edu”.
4.6 Comandi Vari
I comandi in questa sezione non possono essere inseriti in nessuna delle categorie precedenti ma ciò non vuol dire che non sono meno importanti per il protocollo.
4.6.1 Comando Kill
Comando KILL
Parametri: < nickname> < commento>
Il comando KILL è usato per causare una disconnessione client-server. KILL è usato dai servers quando incontrano una doppia voce nella lista di nicknames validi ed è usato per eliminarli entrambi. Anche gli operatori lo possono utilizzare.
I clients che hanno gli algoritmi di riconnessione automatica effettivamente rendono questo comando utilizzabile poiché la disconnesione è solo breve. Essa comunque ferma il flusso di dati e può essere usata per arrestare.
In una zona dove i nicknames devono essere obbligatoriamente unici allo stesso tempo, i comandi KILL sono mandati appena è rilevato un “duplicato” (che è una prova di registrare due utenti con lo stesso nickname) nella speranza che entrambi scompaiano e appaia solo 1.
Il commento dato deve riflettere la ragione per il KILL. Per i KILLs generati dal server il commento comprende spesso dettagli che concernono le origini dei nicknames in questione. Quando viene usato dai clients, è obbligatorio un commento per soddisfare chi vede il KILL. Per prevenire/scoraggiare KILLs falsi per nascondere il generatore del KILL, il commento mostra anche un “percorso del kill” che è aggiornato da ogni server in cui passa, ognuno aggiungendo il proprio nome al percorso.
Risposte numeriche:
ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK ERR_CANTKILLSERVER
Esempi:
KILL David (csd.bu.edu < - tolsun.oulu.fi)
; Collisione di nickname tra csd.bu.edu e tolson.oulu.fi
NOTA:
è raccomandato che solo gli operatori siano abilitati a killare gli altri utenti con il comando KILL. In un mondo ideale nessun operatore avrebbe bisogno di farlo e verrebbe usato solo dai servers.
4.6.2 Comando Ping
Comando: PING
Parametri: < server1> [< server2>]
Il comando PING è usato per testare la presenza di un client attivo all’altro capo della connessione. Un comando PING è mandato a intervalli regolari se nessun altra attività viene da una connessione. Se una connessione non risponde al comando PING dopo un certo periodo di tempo, quella connessione è chiusa.
Ogni client che riceve un comando PING deve rispondere a < server1> (server che ha mandato il comando PING) il più velocemente possibile con un appropriato comando PONG per indicare che è presente e vivo. I servers non dovrebbero rispondere ai comandi PING ma deve contare sui PINGs dall’altro capo della connessione per indicare che la connessione sia ancora viva. Se il parametro < server2> è specificato, il comando PING lo inoltrerà.
Risposte numeriche:
ERR_NOORIGIN ERR_NOSUCHSERVER
Esempi:
PING tolsun.oulu.fi ; il server che manda un comando PING a un altro server per indicare se è ancora vivo.
PING WiZ ; comando PING mandato al nick WiZ
4.6.3 Comando PONG
Comando: PONG
Parametri: < daemon> [< daemon2>]
Il comando PONG è una risposta al comando PING. Se il parametro < daemon2> è dato questo messaggio deve essere mandato al daemon dato. Il parametro < daemon> è il nome del daemon che ha mandato il comando PING.
Risposte numeriche:
ERR_NOORIGIN ERR_NOSUCHSERVER
Esempi:
PONG csd.bu.edu tolsun.oulu.fi ; comando PONG da csd.bu.edu a tolsun.oulu.fi
4.6.4 Comando Error
Comando: ERROR
Parametri: < messaggio d’errore >
Il comando ERROR è usato dal server quando si riporta un serio fatal error ai suoi operatori. Può anche essere mandato da un server ad un altro ma non deve essere accettato da ogni normale client sconosciuto.
Un comando ERROR è usato per riportare errori che avvengono solo con un collegamento serverserver. Un comando ERROR è mandato al server all’altro capo (che lo manda a tutti i suoi operatori connessi) e a tutti gli operatori correntemente connessi. Non passa in altri server se è ricevuto da un server.
Quando un server manda un comando ERROR ricevuto ai suoi operatori, il comando verrà inserito in un comando NOTICE, indicando che il client non è responsabile per l’errore.
Risposte numeriche:
Nessuna.
Esempi:
ERROR :Server *.fi already exists ; comando ERROR all’altro server che ha causato questo errore.
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
; Lo stesso comando ERROR come sopra ma mandato all’utente WiZ su un altro server.
