Internet Relay Chat: Protocollo Client
Stato di questo Memorandum

Questo memorandum fornisce informazioni per la comunità di Internet. Non specifica uno standard Internet di qualsiasi genere.
La distribuzione di questo memorandum è illimitata.

Notifica di Copyright

Copyright (C) The Internet Society (2000). Tutti i diritti riservati.

IESG Note

Il protocollo IRC permette parecchie possibilità di trasferimento dati attraverso clients e,come per altri metodi di trasferimento(tipo email),il destinatario deve stare attento a come questi dati sono trattati. Per maggiori informazioni sulla sicurezza vedi per esempio http://www.irchelp.org/irchelp/security/.

Riassunto

Il protocollo IRC (Internet Relay Chat) è utilizzato per metodi conferenza basati su testo;il più semplice client che può utilizzare qualsiasi programma di connessione per connettersi al server. Questo documento definisce il Protocollo Client e presume che il lettore abbia dimestichezza con l’architettura IRC [IRC-ARCH].

Sommario

1. Etichette
1.1 Servers
1.2 Clients
1.2.1 Utenti
1.2.1.1 Operatori
1.2.2 Servizi(Services)
1.3 Canali
2. Descrizione del Client IRC
2.1 Approfondimento
2.2 Carattere dei codici
2.3 Messaggi
2.3.1 Formato del messaggio in Augmented BNF
2.4 Risposte numeriche
2.5 Espressioni wildcards
3. Dettagli del messaggio
3.1 Registrazione della connessione
3.1.1 Messaggio Password
3.1.2 Messaggio Nick
3.1.3 Messaggio Utente
3.1.4 Messaggio Operatore
3.1.5 Messaggio modalità Utente
3.1.6 Messaggio Servizio
3.1.7 Quit
3.1.8 Squit
3.2 Operazioni Canale
3.2.1 Messaggio Join
3.2.2 Messaggio Part
3.2.3 Messaggio modalità Canale
3.2.4 Messaggio Topic
3.2.5 Messaggio Nomi
3.2.6 Messaggio List
3.2.7 Messaggio Invite
3.2.8 Comando Kick
3.3 Invio Messaggi
3.3.1 Messaggi Private
3.3.2 Notice
3.4 Domande e Comandi Server
3.4.1 Messaggio Motd
3.4.2 Messaggio Lusers
3.4.3 Messaggio Version
3.4.4 Messaggio Stats
3.4.5 Messaggio Links
3.4.6 Messaggio Time
3.4.7 Messaggio Connect
3.4.8 Messaggio Trace
3.4.9 Comando Admin
3.4.10 Comando Info
3.5 Domanda di Servizio e Comandi
3.5.1 Messaggio Servlist
3.5.2 Squery
3.6 Domande riguardanti l’Utente
3.6.1 Domanda Who
3.6.2 Domanda Whois
3.6.3 Whowas
3.7 Messaggi Miscellaneous
3.7.1 Messaggio Kill
3.7.2 Messaggio Ping
3.7.3 Messaggio Pong
3.7.4 Error
4. Configurazioni Facoltative
4.1 Away
4.2 Messaggio Rehash
4.3 Messaggio Die
4.4 Messaggio Restart
4.5 Messaggio Summon
4.6 Utenti
4.7 Messaggio Operwall
4.8 Messaggio Userhost
4.9 Messaggio Ison
5. Risposte
5.1 Risposte Comando
5.2 Risposte di Errore
5.3 Numerazioni Riservate
6. Esecuzioni
7. Problemi Attuali
7.1 Nicknames
7.2 Limitazioni di Wildcards
7.3 Considerazioni di Sicurezza
8. Supporto Attuale e Disponibilità
9. Ringraziamenti
10. Referenze
11. Indirizzo dell’Autore
12. Enunciato del Copyright Completo

1. Etichette (Flag)

Questa sezione definisce gli identificatori usati per i vari componenti del protocollo IRC

1.1 Servers

I server sono identificati unicamente dal loro nome il quale è formato al massimo da sessantatre (63) caratteri. Vedi il protocollo di regole grammaticali (sezione 2.3.1) per cosa può e cosa non può essere usato nel nome di un server.

1.2 Clients

Per ogni client tutti i server devono avere le seguenti informazioni: un unico identificatore per tutta la rete(in quale formato dipende dal tipo di client) ed il server attraverso il quale il client è
entrato in rete.

1.2.1 Utenti

Ogni utente è distinguibile dagli altri da un unico nickname il quale può avere una lunghezza massima di nove(9) caratteri. Vedi il protocollo di regole grammaticali(sezione 2.3.1) per cosa può e cosa non può essere usato nel nome di un nick.
Mentre la massima lunghezza è limitata a nove(9) caratteri,i client accettano stringhe anche più lunghe per poter essere usati nelle future evoluzioni del protocollo.

1.2.1.1 Operatori

Per permettere di mantenere un ragionevole assetto e ordine dentro la rete IRC,una speciale classe di utenti(operatori) è abilitata a svolgere generali operazioni di manutenzione sulla rete.
Sebbene le funzioni concesse ad un operatore possono essere considerate “pericolose”, essi sono nonostante tutto necessari. Gli operatori sarebbero abilitati a svolgere normali compiti di rete come disconnessione e riconnessione dei server se necessario.
In riconoscimento di questo bisogno,il protocollo qui discusso permette agli operatori di essere solamente abilitati a svolgere alcune funzioni. Vedi sezione 3.1.8(Squit) e 3.4.7(Connect).
Un potere più controverso degli operatori è l’abilitazione a rimuovere forzatamente un utente dalla connessione alla rete,i.e., gli operatori sono abilitati a chiudere la connessione attraverso qualsiasi client e server. La motivazione per questa azione è molto significativa in quanto l’abusarne è sia fastidioso quanto dannoso. Per ulteriori dettagli riguardo a questo tipo di azione vedi la sezione 3.7.1(Kill).

1.2.2 Servizi (Services)

Ogni servizio è distinto dagli altri servizi da un nome di servizio(service name) composto da un nickname e da un server name. Come per gli utenti,il nickname ha una lunghezza massima di nove(9) caratteri. Vedi il protocollo di regole grammaticali(sezione 2.3.1) per cosa può e cosa non può essere usato nel nome di un nick.

1.3 Canali

I nomi del canale sono stringhe(che cominciano con uno dei seguenti caratteri'&', '#', '+' o '!') di lunghezza fino a cinquanta(50) caratteri. Fatto d’obbligo che il primo carattere sia’&', '#', '+' o '!' la sola restrizione al nome di un canale è che esso non contenga nessun spazio(‘ ‘), control G
(^G o ASCII 7) o virgola(‘,’). Lo spazio è usato come parametro separatore e la virgola è usata come separatore di articoli su una lista di protocollo. I due punti(‘:’)possono anche essere usati come carattere separatore per la mask del canale. I nomi del canale sono case in sensitive.
Vedi il protocollo di regole grammaticali(sezione 2.3.1) per la sintassi esatta del nome canale.
Ogni prefisso caratterizza un diverso tipo di canale. La definizione del canale non è rilevante per il protocollo client-server e così esula dallo scopo di questo documento. Maggiori informazioni si possono trovare in “Internet Relay Chat: Gestione del Canale” [IRC-CHAN].

[Torna all'indice]

2. Descrizione del Client IRC

2.1 Approfondimento

Il protocollo qui descritto è usato solamente per la connessione client-server nel caso in cui il client si registra come utente.

2.2 Carattere dei codici

Nessuna specifica impostazione di carattere è descritta. Il protocollo si basa su una impostazione di codici composti da otto(8) bits che formano un ottetto. Ogni messaggio può essere formato da qualsiasi numero di questi ottetti;comunque,alcuni valori degli ottetti sono usati per i codici di
controllo,i quali fungono da delimitatori di messaggio. Senza curarci per ora del fatto che sia un protocollo a 8-bit,i separatori e le keywords fanno si che questo sia per lo più disponibile da terminali US-ASCII e da connessioni telnet. In conseguenza delle origini scandinave di IRC, i caratteri {}|^ sono considerati rispettivamente all’equivalenti caratteri []\~. Questo è un caso critico quando l’equivalenza interessa due nickname o nomi di canale.

2.3 Messaggi

Dai server e dai client vengono mandati anche altri messaggi,i quali possono o no generare una risposta. Se il messaggio contiene un comando valido,come descritto in successive sezioni, il client si aspetterebbe una risposta ma non è consigliato aspettare illimitatamente questa risposta;
i dialoghi tra client-server e server-server sono essenzialmente asincroni per natura. Ciascun messaggio IRC è formato principalmente da tre parti: il prefisso(facoltativo), il comando E i parametri di comando(massimo di quindici(15)). Il prefisso,il comando e tutti i parametri sono
Separati ciascuno da un carattere di spazio in formato ASCII (0x20).
La presenza di un prefisso è indicata dal carattere ASCII rappresentante i due punti(‘:’0x3b), il quale,da solo,deve essere il primo carattere del messaggio. Non ci deve essere nessuno spazio vuoto tra i due punti(‘:’) ed il prefisso. Il prefisso è usato dai server per indicare la vera origine del
messaggio. Nel qual caso il prefisso risultasse mancante,il messaggio verrà riconosciuto come se fosse stato originato dalla stessa connessione dalla quale è stato ricevuto.
I client non potrebbero usare nessun prefisso quando inviano un messaggio;nel qual caso ne usassero uno,il solo ritenuto valido sarà il nickname registrato associato con il client stesso. Il comando tra l’altro deve essere un comando IRC valido o tre semplici numeri rappresentati in
formato ASCII. I messaggi IRC sono sempre linee di caratteri terminanti con un CR-LF (Carriage Return – Line Feed) accoppiati,e questi messaggi non devono superare i 512 caratteri di lunghezza,comprendendo tutti i caratteri incluso CR-LF. In questo modo,per il comando ed i
suoi parametri sono permessi al massimo 510 caratteri. Non ci sono rimedi per la continuazione delle linee di messaggio. Per maggiori dettagli di esecuzione vedi la sezione 6.

2.3.1 Formato del Messaggio in Augmented BNF

I messaggi di protocollo devono essere presi dal contiguo flusso di ottetti. La soluzione attuale è quella di assegnare due caratteri,CR e LF,come separatori del messaggio. I messaggi vuoti sono silenziosamente ignorati in modo da permettere l’uso delle sequenze CR-LF tra i messaggi senza
ulteriori problemi. I messaggi estratti vengono analizzati nella struttura <prefisso>,<comando> ed elenco dei parametri(<params>).
La relativa rappresentazione Augmented BNF è:

NOTE:
1) Dopo aver estratto l’elenco parametri,tutti i parametri sono uguali se accoppiati per <middle> o <trailing>. <trailing> è solamente un sintattico trucco per permettere lo SPAZIO all’interno del parametro.
2) Il carattere NUL (%x00) non è di particolare rilievo nella formazione del messaggio e fondamentalmente potrebbe finire dentro un parametro,ma ciò potrebbe comportare ulteriori complessità nel trattamento di normale stringa C. Quindi, NUL non è ammesso all’interno dei messaggi.

La maggior parte dei messaggi di protocollo specifica ulteriori semantiche e sintassi per le stringhe di parametro estratte,dettate dalla loro posizione nell’elenco. Per esempio,molti comandi di server interpreteranno che il primo parametro dopo il comando è la lista dei target, i quali possono essere così descritti:

Altre sintassi di parametro sono:

NOTE:
1) La sintassi <hostaddr> è qua fondamentalmente considerata solo allo scopo di indicare il Formato da seguire per gli indirizzi IP. Questo implica che l’esecuzione di questo protocollo usi TCP/IP come protocollo di rete,ma non impedisce che si possano utilizzare altri protocolli.
2) <hostname> ha una lunghezza massima di 63 caratteri. Questa è una limitazione del protocollo in quanto l’internet hostname può essere più lungo. Tale restrizione è necessaria in quanto i messaggi IRC hanno una lunghezza massima limitata a 512 caratteri. I client che si connettono da un host più lungo di 63 caratteri vengono registrati usando un indirizzo host numerico anzichè l’hostname.
3) Alcuni parametri usati in questa sezione non vengono qui definiti non essendoci particolari specifiche a riguardo se non il fatto che il nome viene usato per comodità. Questi parametri seguono la normale sintassi definita per <params>.

2.4 Risposte Numeriche

2.5 Espressioni Wildcard

Quando in una stringa è permessa una wildcard,questa viene assegnata come una “mask”. Per la stringa che accoppia lo scopo,il protocollo consente l’uso di due caratteri speciali: ’?’(%x3F) assegnato ad uno e solamente un carattere,e ‘*’ (%x2A) assegnato a qualsiasi numero di qualsiasi carattere. Questi due caratteri possono essere elusi usando il carattere ‘\’ (%x5C).
La relativa sintassi Augmented BNF è:

Esempi:
a?c ;assegnato a qualsiasi stringa di tre caratteri in lunghezza che inizia con “a” e finisce con “c”

a*c ;assegnato a qualsiasi stringa uguale o più piccola di due caratteri in lunghezza che comincia con “a” e finisce con “c”.

[Torna all'indice]

3. Dettagli del Messaggio

Nelle pagine seguenti ci sono le descrizioni per ciascun messaggio riconosciuto dal client e dal server IRC. Tutti i comandi descritti in questa sezione devono essere attuati da ogni server per questo protocollo. Dove si ha ERR_NOSUCHSERVER come risposta di ritorno,significa che il
target del messaggio non è stato trovato. Per un comando,il server non deve inviare nessun’altra risposta dopo questo errore. Per il server al quale è connesso il client,è richiesto di analizzare l’intero messaggio e restituire il relativo messaggio d’errore. Se sono presenti più parametri, ne deve essere controllata la validità di ciascuno ed al client deve essere inviata l’adeguata risposta.
Nel caso di messaggio non corretto,in quanto si serve negli elenchi di parametro di separatori di comando, per ciascuno di questi deve essere in inviata una risposta.

3.1 Registrazione della Connessione

Il comando qui descritto viene usato per registrare una connessione con un server IRC cosi' come la disconnessione corretta di un utente.
Il comando “PASS” non è richiesto per la connessione di un client,ma deve venire prima dell’ultima combinazione NICK/USER(per una connessione utente) o del comando SERVICE (per una connessione SERVICE). La sequenza di registrazione raccomandata per un client è la seguente:

1. Pass message
2. Nick message 2. Service message
3. User message

A sequenza avvenuta con successo il client riceverà un messaggio,RPL_WELCOME(per utenti) o RPL_YOURESERVICE(per i services),di avvenuta registrazione della connessione e che tutta la rete IRC ne è a conoscenza. Il messaggio di risposta deve contenere l’intero identificatore del client sul quale è stato registrato.

3.1.1 Messaggio Password

Comando : PASS
Parametri : <password>

Il comando PASS è usato per settare una ‘password di connessione’. La password facoltativa può e deve essere settata prima che sia fatto qualsiasi tentativo di registrazione della connessione. Generalmente ciò richiede che l’utente invii il comando Pass prima che sia inviata la combinazione NICK/USER.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Esempio:

PASS secretpasswordhere

3.1.2 Messaggio Nick

Il comando NICK viene usato per dare all’utente un nickname oppure per cambiare quello già esistente.

Risposte numeriche:

ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION
ERR_UNAVAILRESOURCE ERR_RESTRICTED

Esempi:

NICK Wiz ; mette il nuovo nick ‘Wiz’ se la sezione non è ancora stata registrata, o l’utente cambia il suo nickname in ‘Wiz’.
:WiZ!jto@tolsun.oulu.fi NICK Kilroy ; il server stà dicendo che Wiz ha cambiato il suo nickname in Kilroy.

3.1.3 Messaggio Utente

Comando: USER
Parametri: <user> <mode> <unused> <realname>

Il comando USER è usato all’inizio della connessione per indicare l’username,l’hostname ed il realname (nome reale) di un nuovo utente. Il parametro <mode> potrebbe essere numerico e può essere usato per impostare automaticamente le modalità dell’utente durante la registrazione con il server. Questo è un parametro bitmask con soli 2 bits assume qualsiasi significato: se il bit 2 è impostato sarà settata la modalità utente ‘w’ e se il bit 3 è impostato,sarà settata la modalità ‘i’. (Vedi la sezione 3.1.5 “Modalità Utenti”). Il <realname> può contenere caratteri di spazio.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Esempio:

USER guest 0 * :Ronnie Reagan ; l’utente si sta registrando con username “guest” e con un realname “Ronnie Reagan”.

USER guest 8 * :Ronnie Reagan ; l’utente si sta registrando con username “guest“, con un Realname “Ronnie Reagan” e sta chiedendo di essere impostato invisibile.

3.1.4 Messaggio Operatore

Comando: OPER
Parametri: <name> <password>

Un normale utente usa il comando OPER per ottenere i privilegi da operatore. Per poter concedere tali privilegi,è richiesta la combinazione <name> e <password>. Ad operazione avvenuta con successo,l’utente riceverà un MODE messagge indicante le nuove modalità dello stesso

Risposte numeriche:

ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH

Esempio:

OPER foo bar ; si sta registrando come operatore usando l’username ‘foo’ e la password ‘bar’

3.1.5 Messaggio modalità Utente

Comando: MODE
Parametri: <nickname>
*( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
Le modalità dell’utente sono principalmente dei cambiamenti i quali assegnano il modo in cui il client viene visto dagli altri o i messaggi extra che il client riceve. Un comando di modalità dell’utente deve essere accettato solamente se entrambi i mittenti , che vengono dati come parametro del messaggio e del nickname, sono gli stessi. Se nessun’altro parametro è dato,il server ritornerà le correnti impostazioni per il nick.
Le modalità disponibili sono le seguenti:

a - l’utente è contrassegnato come away
i - segna un utente come invisibile
w - l’utente riceve wallops
r - connessione dell’utente ristretta
o - contrassegno di operatore
O - contrassegno di operatore locale
s – permette ad un utente di ricevere notices del server

Modalità addizionali potranno essere disponibili più avanti.

Il contrassegno ‘a’ non dovrebbe risultare faticoso per l’utente che usa il comando MODE, in alternativa è richiesto l’uso del comando AWAY.
Se un utente tentasse da solo di farsi operatore usando il segno “+o” o “+O”,il tentativo verrebbe ignorato in quanto gli utente potrebbero raggirare il meccanismo di autentificazione del comando OPER. Comunque non c’è nessuna restrizione a qualsiasi deopping effettuato sul sé stessi usando
“-o” o “-O”.
Dall’altro verso,se un utente tenta di fare liberamente da solo l’uso del segno “-r”,il tentativo sarebbe ignorato.Non c’è nessuna restrizione a qualsiasi deopping su sé stessi usando “+r”. Questo segno è settato tipicamente dal server,dopo una connessione avvenuta con successo,per ragioni amministrative.Mentre le restrizioni imposte sono attivate è chiaro che ad un utente con restrizioni non è concesso cambiare il nickname nemmeno se fosse operatore del canale.
Il segno ‘s’ è obsoleto,ma potrebbe ancora essere usato.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH
ERR_UMODEUNKNOWNFLAG RPL_UMODEIS

Esempi:

MODE WiZ –w ; comando eseguito da Wiz per disattivare la ricezione di messaggi Wallops.

MODE Angel +i ; comando eseguito da Angel per rendersi invisibile.

MODE WiZ –o ; deop di Wiz (rimosso dallo stato di operatore)

3.1.6 Messaggio Servizio

Il comando SERVICE per registrare un nuovo servizio. I parametri di comando specificano il nickname di servizio,la distribuzione,il tipo e le info di un nuovo servizio. Il parametro <distribuzione> viene usato per specificare la visibilità di un servizio. Il servizio può Solamente essere riconosciuto dai server che hanno nel nome un riscontro con la distribuzione. Perché un server sia a conoscenza del servizio,il percorso della rete tra questo server ed il server sul quale il servizio è connesso deve essere composto da server i quali trovano corrispondenza tra il loro nome e la mask.
Il parametro <tipo> è attualmente riservato per un uso futuro.

Risposte numeriche:

ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE RPL_YOURHOST
RPL_MYINFO

Esempio:

SERVICE dict * *.fr 0 0 : Dizionario francese ; Service registering itself with a name of "dict". Questo servizio sarà disponibile solo nei server con estensione "*.fr".

3.1.7 Quit

Comando: QUIT
Parametri: [ <Messaggio di quit> ]

Una sessione del client termina con il messaggio di quit. Il server riconosce ciò per l’invio di un messaggio di ERROR al client.

Risposte numeriche: Nessuna.

Esempio:

QUIT: Andato a pranzare. ; Preferito il formato messaggio.

:syrk!kalt@millennium.stealth.net QUIT : andato a pranzare; l’utente syrk ha abbandonato IRC per pranzare.

3.1.8 Squit

Il comando SQUIT è disponibile solamente per gli operatori. E’ usato per disconnettere link del server. Inoltre i servers possono generare messaggi di SQUIT per condizioni di errore. Un messaggio di SQUIT potrebbe inoltre interessare la connessione di un server remoto. In questo caso il messaggio di SQUIT sarà semplicemente spedito al server remoto senza preoccupare i servers nel mezzo,l’operatore ed il server remoto.
Il <commento> dovrebbe essere fornito da tutti gli operatori che eseguono uno SQUIT per un server remoto. Il server incaricato di disconnettere un altro server,genera un messaggio di WALLOPS con incluso il <commento> così che gli altri utenti possano venir informati delle ragioni di tale azione.

Risposte numeriche:

ERR_NOPRIVILEGES ERR_NOSUCHSERVER
ERR_NEEDMOREPARAMS

Esempi:

SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server tolson.oulu.fi to terminate its connection with comment “Bad Link”.

:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; commando eseguito da Trillian per sconnettere "cm22.eng.umd.edu" dalla rete con il commento“Server out of control”.

3.2 Operazioni Canale

Questo gruppo di messaggi è condizionato dalla gestione dei canali,le loro proprietà (modalità del canale) ed i loro contenuti (tipicamente gli utenti). Per questa ragione questi messaggi non dovrebbero essere messi a disposizione dei servizi.
Tutti questi messaggi sono delle richieste che a loro volta saranno o no concesse dal server.
Il server deve inviare una risposta che informa l’utente qualora la richiesta sia stata concessa,negata o abbia generato un errore. Quando il server concede la richiesta il messaggio viene rispedito indietro(eventualmente riformattato) all’utente con il prefisso impostato all’utente stesso
Le regole su come gestire i canali sono imposte dai server. Queste regole sono inoltre lo scopo di questo documento. Maggiori dettagli sono forniti in "Internet Relay Chat: Channel Management" [IRC-CHAN].

3.2.1 Messaggio Join

Comando: JOIN
Parametri: ( <canale> *( "," <canale> ) [ <key> *( "," <key> ) ] ) / "0"

Il comando JOIN è usato da un utente per richiedere di iniziare a leggere nello specifico canale. I servers devono essere in grado di analizzare gli argomenti sotto forma di lista di scopi,ma non dovrebbe usare liste quando invia messaggi di JOIN al client. Una volta che l’utente è entrato nel
canale,riceve informazioni di tutti i comandi che il suo server riceve a riguardo del canale stesso. Queste informazioni includono il JOIN,MODE,KICK,PART,QUIT e naturalmente PRIVMSG/NOTICE. Questo permette ai membri del canale di tenere traccia degli altri utenti
dello stesso canale ed anche delle modalità di quest’ultimo. Se un JOIN ha avuto buon esito,l’utente come conferma riceve un messaggio di JOIN,quindi successivamente gli viene inviato il topic del canale (usando RPL_TOPIC) e la lista degli utenti che sono nel canale (usando RPL_NAMREPLY) la quale deve includere gli utenti presenti al momento del join.
Da notare che questo messaggio accetta uno speciale argomento(“0”),il quale è una speciale richiesta,fatta a tutti gli utenti,di lasciare il canale del quale l’utente fa parte. Il server interpreterà questo messaggio come se l’utente abbia inviato un comando PART(vedi sessione 3.2.2) per ogni
canale di cui egli è membro.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
RPL_TOPIC

Esempi:

JOIN #foo,&bar fubar ; Comando per il join nel canale #foo usando la chiave “fubar” e &bar usando nessuna chiave.

JOIN #foo,#bar fubar,foobar ; Comando per il join nel canale #foo usando la chiave “fubar” e nel canale #bar usando la chiave “foobar”.

JOIN #foo,#bar ; Comando per il join nei canali #foo e #bar.

JOIN 0 ; Lasciare tutti i canali attualmente frequentati.

:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; Messaggio di JOIN da parte di Wiz nel canale #Twilight_zone.

3.2.2 Messaggio Part

Comando: PART
Parametri: <canale> *( "," <canale> ) [ <Messaggio di Part> ]

Il comando PART provoca la rimozione dall’elenco dei membri attivi,dell’utente che invia il messaggio,in tutti quei canali elencati nella stringa di parametro. Se viene dato un “Messaggio di Part”,questo invierà il nickname anziché il messaggio di default. Qesto sempre che sia concesso
dal server. I server devono esere capaci di analizzare gli argomenti sotto forma di elenco dei target, ma non dovrebbe usare le liste nell’inviare messaggi di PART ai clients.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL ERR_NOTONCHANNEL

Esempi:

PART #twilight_zone ; Comando per lasciare il canale #twilight_zone

PART #oz-ops,&group5 ; Comandoper lasciare entrambi i canali“&group5” ed “#oz-ops”.

:WiZ!jto@tolsun.oulu.fi PART #playzone :I lost ; L’utente WiZ stà lasciando il canale“#playzone” con il messaggio”I lost”.

3.2.3 Messaggio modalità Canale

Comando: MODE
Parametri: <canale> *( ( "-" / "+" ) *<modes> *<modeparams> )

Il comando MODE è disponibile affinché gli utenti possano chiedere e cambiare le caratteristiche di un canale. Per maggiori dettagli sull’uso e la disponibilità delle modalità vedi "Internet Relay Chat: Channel Management" [IRC-CHAN]. Da notare che c’è un limite massimo di tre(3) cambi
per comando per le modalità interessate un parametro.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_KEYSET
ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED
ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE
RPL_CHANNELMODEIS
RPL_BANLIST RPL_ENDOFBANLIST
RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST
RPL_INVITELIST RPL_ENDOFINVITELIST
RPL_UNIQOPIS

I seguenti esempi sono forniti per aiutare a comprendere la sintassi del comando MODE,ma si riferiscono a modalità definite nell’ "Internet Relay Chat: Channel Management" [IRC-CHAN].

Esempi:

MODE #Finnish +imI *!*@*.fi ; Comando per impostare il canale #Finnish moderato e con accesso consentito solo su invito con utenti , aventi nell’hostname il riscontro *.fi , automaticamente invitati.

MODE #Finnish +o Kilroy ; Comando per dare i privilegi da chanop (operatore di canale) a Kilroy nel canale #Finnish.

MODE #Finnish +v Wiz ; Comando per consentire a Wiz di parlare nel canale #Finnish.

MODE #Fins –s ; Comando per rimuovere il contrassegno‘segreto’ al canale #Fins.

MODE #42 +k oulu ; Comando per impostare “oulu” come chiave del canale #42.

MODE #42 -k oulu ; Comando per rimuovere la chave del canale “oulu” dal canale #42.

MODE #eu-opers +l 10 ; Comando per impostare a 10 il limite di Utenti nel canale #eu-opers.

:WiZ!jto@tolsun.oulu.fi MODE #eu-opers –l ; L’utente WiZ stà rimuovendo il limite per il numero di utenti nel canale #ue-opers.

MODE &oulu +b ; Comando per elencare le mask bannate Nel canale &oulu.

MODE &oulu +b *!*@* ; Comando per impedire il join a tutti gli Utenti.

MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu ; Comando per impedire a qualsiasi utente che che ha nell’hostname un riscontro con
*.edu di effettuare il join , tranne se il riscontro è con *.bu.edu .

MODE #bu +be *!*@*.edu *!*@*.bu.edu ; Comando per impedire a qualsiasi utente che che ha nell’hostname un riscontro con *.edu di effettuare il join , tranne se il riscontro è con *.bu.edu .

MODE #meditation e ; Comando per elencare le mask in modalità eccezione nel canale #meditation.

MODE #meditation I ; Comando per elencare le mask in modalità invito nel canale #meditation.

MODE !12345ircd O ; Comando per chiedre chi è il founder del canale "!12345ircd".

3.2.4 Messaggio Topic

Comando: TOPIC
Parametri: <canale> [ <topic> ]

Il comando TOPIC è usato per cambiare o visualizzare il topic di un canale. Se non c’è nessun topic nel canale,verrà tornato il topic <channel>. Se il parametro <topic> è presente,il topic per quel canale verrà cambiato,sempre che questa azione sia permessa all’utente che la richiede.
Se il parametro <topic> è una strnga vuota,il topic di quel canale verrà rimosso.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES

Esempi:

:WiZ!jto@tolsun.oulu.fi TOPIC #test :Nuovo topic ; L’utente WiZ stà impostando il topic.

TOPIC #test :altrotopic ; Comando per impostare il topic”altrotopic” Nel canale #test.

TOPIC #test : ; Comando per cancellare il topic nel canale #test.

TOPIC #test ; Comando per controllare il topic del canale #test.

3.2.5 Messaggio Nomi

Comando: NAMES
Parametri: [ <canale> *( "," <canale> ) [ <target> ] ]

Usando il comando NAMES un utente può elencare tutti i nicknames a lui visibili. Per maggiori dettagli per cosa è o cosa non è visibile vedi "Internet Relay Chat: Channel Management" [IRC- CHAN]. Il parametro <canale> specifica quale canale deve restituire informazioni a riguardo.
Non ci sono risposte di errore per nomi di canale errati. Se non è dato nessun parametro <canale>,viene restituita una lista di tutti i canali ed i loro
occupanti. Alla fine di questa lista,una lista di utenti che sono visibili , ma allo stesso tempo in nessun canale o in un canale non visibile , sono elencati come presenti nel canale “*”. Se il parametro <target> è specificato,la richiesta viene avanzata a quel server che genererà la risposta. Wildcards sono concesse nel parametro <target>.

Numeriche:

ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
RPL_NAMREPLY RPL_ENDOFNAMES

Esempi:

NAMES #twilight_zone,#42 ; Comando per elencare gli utenti visibili nei canali #twilight_zone e #42.

NAMES ; Comando per elencare tutti i canali ed utenti visibili.

3.2.6 Messaggio List

Il comando LIST viene usato per elencare i canali ed i loro topics. Se il parametro <canale> è usato, solamente lo status di quel canale viene visualizzato. Se il parametro <target> è specificato,la richiesta sarà inoltrata a quel server che genererà la risposta. Le wildcards sono consentite nel parametro <target>.

Risposte numeriche:

ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
RPL_LIST RPL_LISTEND

Esempi:

LIST ; Comando per elencare tutti i canali.

LIST #twilight_zone,#42 ; Comando per elencare i canali #twilight_zone e #42

3.2.7 Messaggio Invite

Il comando INVITE viene usato per invitare un utente in un canale. Il parametro <nickname> è il nick dell’utente che viene invitato nel canale <canale>. Unica restrizione è che il canale nel quale viene invitato l’utente sia presente o abbia un nome valido. Inoltre,se il canale esiste, è consentito
di invitare altri utenti solamente ai membri di quel canale. Quando il canale è impostato in con la invite-only,solamente gli operatori possono eseguire il comando INVITE. Solamente l’utente che manda l’invito e quello che stà per essere invitato riceveranno la notifica dell’invito. Agli altri membri del canale non verrà notificato. (Questo è diverso rispetto ai cambi di modalità ed è a volte fonte di guai per gli utenti.)

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAY

Esempi:

:Angel!wings@irc.org INVITE Wiz #Dust ; Messahhio a Wiz quando viene invitato dall’utente Angel nel canale #Dust.

INVITE Wiz #Twilight_Zone ; Comando per invitare Wiz nel canale #Twilight_Zone.

3.2.8 Comando Kick

Comando: KICK
Parametri: <canale> *( "," <canale> ) <utente> *( "," <utente> ) [<commento>]

Il comando KICK può essere usato per richiedere la rimozione forzata di un utente dal canale. Esso fa in modo che l’<utente> lasci il <canale> tramite una forzatura. Perché il messaggio sia sintatticamente corretto,non deve esserci nemmeno un parametro canale e molteplici parametri
utenti o tanti parametri canale come quanti parametri utente ci sono. Se viene dato un commento, questo verrà inviato al posto del messaggio di default,il nickname dell’utente che ha eseguito il KICK. Il server non deve inviare messaggi di KICK con più canali o utenti ai clients.
Questo è necessario per un discorso di compatibilità con softwares di vecchi clients.

Risposte numeriche:

ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL

Esempi:

KICK &Melbourne Matthew ; Comando per espellere Matthew dal canale &Melbourne.

KICK #Finnish John :Parlare Inglese ; Comando per espellere John da #Finnish usando “Parlare Inglese” come
motivazione (comment).

:WiZ!jto@tolsun.oulu.fi KICK #Finnish John ; Messaggio KICK sul canale #Finnish da parte di WiZ per rimuovere John dal canale

3.3 Invio Messaggi

Il principale scopo del protocollo IRC è di fornire una base ai clients per poter comunicare con altri. PRIVMSG, NOTICE e SQUERY (descritto nella sezione 3.5 Domanda di Servizio e Comandi) sono i soli messaggi disponibili,i quali attualmente si occupano della consegna di un
messaggio di testo da un client ad un altro - il resto non fa altro che rendere queste cose possibili e dare la sicurezza che avvengano.

3.3.1 Messaggi Private

Comando: PRIVMSG
Parametri: <msgtarget> <testo da spedire>

PRIVMSG è usato per inviare messaggi privati tra gli utenti,cioè come inviare messaggi nei canali. <msgtarget> è generalmente il nickname di chi riceve il messaggio,o un nome di canale. Il parametro <msgtarget> può anche essere una host mask (#<mask>) oppure una server mask
($<mask>). In entrambi i casi il server invierà il PRIVMSG solamente a quei server o host che combaciano con la mask. La mask deve contenere al limite 1 (uno) “.” e nessuna wildcards dopo l’ultimo “.”. Questo è richiesto per evitare che la gente invii messaggi a "#*" o "$*", i quali verrebbero divulgati a tutti gli utenti. Wildcards sono i caratteri '*' e '?'. Questa estensione al comando PRIVMSG è disponibile solamente per gli operatori.

Risposte numeriche:

ERR_NORECIPIENT ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAY

Esempi:

:Angel!wings@irc.org PRIVMSG Wiz : Stai ricevendo questo messaggio? ; Messaggio da Amgel a Wiz.

PRIVMSG Angel :si,lo stò ricevendo ! ; Comando per inviare un messaggio ad Angel.

PRIVMSG jto@tolsun.oulu.fi :Ciao ! ; Commando per inviare un messaggio ad un utente sul server tolsun.oulu.fi con l’username di “jto”.

PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Sei una rana? ; Messaggio ad un utente sul server irc.stealth.net con username “kalt” e connesso dall’host millennium.stealth.net.

PRIVMSG kalt%millennium.stealth.net :Ti piace il formaggio? ; Messaggio ad un utente sul server locale con username “kalt” e connesso dall’host
millennium.stealth.net.

PRIVMSG Wiz!jto@tolsun.oulu.fi :Ciao ! ; Messaggio all’utente con nickname Wiz connesso dall’host tolsun.oulu.fi e avente username “jto”.

PRIVMSG $*.fi :Server tolsun.oulu.fi riavvio. ; Messaggio a tutti gli utenti su un server aventi un nome combaciante con *.fi.

PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions ; Messaggio a tutti gli utenti proveniente da un host che ha il nome combaciante con *.edu.

3.3.2 Notice

Comando: NOTICE
Parametri: <msgtarget> <testo>

Il comando NOTICE viene usato similarmente a PRIVMSG. La differenza tra NOTICE è PRIVMSG stà nel fatto che le risposte automatiche non devono malessere inviate in risposta ad un Messaggio di NOTICE. Questa regola viene applicata anche ai servers – essi sulla ricezione di un
notice non devono rimandare indietro nessuna risposta di errore al client. Scopo di questa regola è quello di evitare ingarbugli tra i clients che spediscono qualcosa automaticamente qualcosa in risposta a quello che hanno ricevuto. Questo comando è disponibile ai services come utenti.
This is typically used by services, and automatons (clients with either an AI or other interactive program controlling their actions).
Vedi PRIVMSG per maggiori dettagli su risposte ed esempi.

3.4 Domande e Comandi Server

I comandi del gruppo domande del server sono stati destinati per restituire informazioni riguardanti qualsiasi server connesso alla rete. In queste domande, dove un parametro si presenta come <target>,le wildcard mask sono generalmente valide. Per ogni parametro,comunque, viene
vengono generate una domanda e una serie di risposte. Nella maggior parte dei casi,se viene dato un nickname,esso verrà inteso come il server al quale l’utente è connesso. Questi messaggi hanno generalmente poco valore per i services,viene quindi raccomandato di vietarne l’uso ai services.

3.4.1 Messaggio Motd

Comando: MOTD
Parametri: [ <target> ]

Il comando MOTD è usato per ottenere il “Messaggio del Giorno” del server stabilito o il corrente server se il <target> è omesso. Le wildcards sono consentite nel parametro <target>.

Risposte numeriche:

RPL_MOTDSTART RPL_MOTD
RPL_ENDOFMOTD ERR_NOMOTD

3.4.2 Messaggio Lusers

Comando: LUSERS
Parametri: [ <mask> [ <target> ] ]

Il comando LUSERS viene usato per ottenere statistiche riguardanti la dimensione della rete IRC. Se non è dato nessun parametro,la risposta riguarderà l’intera net. Se è specificata una <mask>, di conseguenza la risposta sarà concernente la parte di network formata dai servers aventi la mask combaciante con quella data. Infine,se il parametro <target> è specificato,la richiesta viene avanzata a quel server , il quale genererà la risposta.
Le wildcards cono consentite nel parametro <target>

Risposte numeriche:

RPL_LUSERCLIENT RPL_LUSEROP
RPL_LUSERUNKOWN RPL_LUSERCHANNELS
RPL_LUSERME ERR_NOSUCHSERVER

3.4.3 Messaggio Version

Comando: VERSION
Parametri: [ <target> ]

Il comando VERSION è usato per chiedere la versione del programma del server. Il parametro opzionale <target> viene usato per chiedere la versione del programma del server al quale un client non è direttamente connesso. Le wildcards sono consentite nel parametro <target>.

Risposte numeriche:

ERR_NOSUCHSERVER RPL_VERSION

Esempi:

VERSION tolsun.oulu.fi ; Comando per verificare la versione del server "tolsun.oulu.fi".

3.4.4 Messaggio Stats

Comando: STATS
Parametri: [ <domanda> [ <target> ] ]

Il comando STATS viene usato per richiedere statistiche di un certo server. Se il parametro <domanda> è omesso,solamente la risposta di fine statistiche viene ritornata. Una richiesta può essere fatta per qualsiasi singola lettera,la quale viene controllata solamente dal server di destinazione ed è oltrepassata dai server intermedi,ignorata ed inalterata. Le wildcards sono consentite nel parametro <target>. Eccetto per i casi sottoriportati,l’elenco delle richieste valide dipende dall’utilizzo. Le richieste standard sottoriportate sarebbero supportate dal server:

l - restituisce un elenco delle connessioni del server,mostrando per quanto tempo è stata stabilita una connessione ed il traffico oltre alla connessione in kbytes ed i messaggi per ogni direzione.
m – restituisce il conto delle volte che ogni comando supportato dal server è stato usato; il conto dei comandi non utilizzati potrebbe essere uguale a zero.
o – restituisce un elenco degli operatori.
u - restituisce uina stinga indicante per quanto tempo il server è stato up.

Si raccomanda inoltre che la configurazione d’accesso del client e del server sia divulgata in questo modo.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_STATSLINKINFO RPL_STATSUPTIME
RPL_STATSCOMMANDS RPL_STATSOLINE
RPL_ENDOFSTATS

Esempi:

STATS m ; Comando per controllare l’uso di un comando per il serever al quale sei connesso.

3.4.5 Messaggio Links

Comando: LINKS
Parametri: [ [ <server remoto> ] <mask del server> ]

Col comando LINKS un utente può elencare tutti i nomi dei server,i quali sono conosciuti dal server a cui è rivolta la domanda. La lista di server ritornata deve combaciare con la mask e se non è data nessuna mask,saràò ritornata la lista completa. Se il <server remoto> è dato in aggiunta alla <mask del server>,il comando LINKS viene inoltrato al primo server trovato avente il nome combaciante,ed a quel server viene poi richiesto di rispondere alla domanda.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKS

Esempi:

LINKS *.au ; Comando per elencare tutti quei server aventi il nome combaciante con *.au.

LINKS *.edu *.bu.edu ; Command to list servers matching *.bu.edu as seen by the first server matching *.edu.

3.4.6 Messaggio Time

Comando: TIME
Parametri: [ <target> ]

Il comando TIME serve per chiedere l’ora locale dal specificato server. Se non è dato il parametro <target> il server specificato deve rispondere alla domanda.

Risposte numeriche:

ERR_NOSUCHSERVER RPL_TIME

Esempi:

TIME tolsun.oulu.fi ; Controlla l’ora del server "tolson.oulu.fi".

3.4.7 Mesaggio Connect

Comando: CONNECT
Parametri: <target server> <porta> [ <server remoto> ]

Il comando CONNECT può essere usato per chiedere ad un server di provare a stabilire una nuova connessione ad un altro server immediatamente. CONNECT è un comando privilegiato e dovrebbe essere disponibile solamente agli operatori IRC. Se è dato un <server remoto> e la sua mask non combacia col nome del server che si stà analizzando,il tentativo di CONNECT è inviato al primo server remoto che combacia. Diversamente il tentativo di CONNECT è fatto dal server che stà analizzando la richiesta.
Il server che stà ricevendo un comando di CONNECT remoto dovrebbe generare un messaggio di WALLOPS col quale descrive la provenienza ed il target della richiesta.

Risposte numeriche:

ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMS

Esempi:

CONNECT tolsun.oulu.fi 6667 ; Comando per tentare di connettere il server locale a tolsun.oulu.fi sulla porta 6667.

3.4.8 Messaggio Trace

Comando: TRACE
Parametri: [ <target> ]

Il comando TRACE è usato per trovare la via ad un server specifico ed informazioni riguardo i suoi pari. Ogni server che analizza questo comando, deve riportare le informazioni a chi l’ha inviato. Le risposte,nel passare dai links,formano una catena la quale mostra il tracciato di destinazione. Dopo avere spedito indietro questa risposta,la domanda deve essere inviata al prossimo server fino a raggiungere quello indicato nel <target>.
Il comando TRACE è usato per trovare la via ad un server specifico. Ogni server che analizza questo messaggio deve dire al mittente riguardo a sé stesso attraverso l’invio di una risposta indicante che esse è un link intermedio,formando così una catena di risposte. Dopo avere spedito indietro queste risposte,esso deve poi inviare il messaggio di TRACE al prossimo server fino a che il server dato è raggiunto. Se il parametro <target> viene omesso,si raccomanda che il comando TRACE invii un messaggio al mittente dicendo a quali server il server locale è direttamente connesso. Se la destinazione data dal <target> è un server reale,il server di destinazione deve riportare tutti i servers,i services e gli operatori che sono connessi ad esso; se il comando è stato avanzato da un operatore,il server potrebbe riportare anche tutti gli utenti ad esso connessi. Se la destinazione data dal <target> è un nickname,viene data solamente una risposta per quel nickname. Se il parametro <target> è omesso,si raccomanda che il comando TRACE venga analizzato come targeted to the processing server. Le wildcards sono consentite nel parametro <target>.

Risposte numeriche:

ERR_NOSUCHSERVER

Se il messaggio TRACE è destinato ad un altro server,tutti i server intermedi devono restituire una risposta RPL_TRACELINK per indicare che il TRACE passa attraverso loro e per dove stà proseguendo.

RPL_TRACELINK

Una risposta TRACE potrebbe 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 RPL_TRACELOG
RPL_TRACEEND

Esempi:

TRACE *.oulu.fi ; TRACE per un server combaciante con *.oulu.fi.

3.4.9 Comando Admin

Comando: ADMIN
Parametri: [ <target> ]

Il comando ADMIN viene usato per trovare informazioni riguardanti gli amministratori di un dato server,o del corrente server se viene omesso il parametro <target>. Ogni server deve essere abilitato ad inoltrare messaggi ADMIN agli altri server.
Le wildcards sono consentite nel parametro <target>.

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.

ADMIN syrk ; ADMIN richiede a quale server è connesso l’utente syrk.

3.4.10 Comando Info

Comando: INFO
Parametri: [ <target> ]

Il comando INFO richiede la restituzione di informazioni che descrivono il server: la sua versione, quando è stata compilata,il livello patch,quando è stato attivato,e qualsiasi altra informazione che potrebbe essere rilevante. Le wilcards sono consentite nel parametro <target>.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_INFO RPL_ENDOFINFO

Esempi:

INFO csd.bu.edu ; Richiesta una risposta INFO da csd.bu.edu.

INFO Angel ; Richiesta una info dal server al quale è connesso Angel.

3.5 Domanda di Servizio e Comandi

Il gruppo di comandi della domanda di servizio(service) è stato creato per tornare informazioni riguardanti qualsiasi servizio connesso alla network.

3.5.1 Messaggio Servlist

Comando: SERVLIST
Parametri: [ <mask> [ <tipo> ] ]

Il comando SERVLIST è usato per elencare i servizi(services) attualmente connessi alla network e visibili all’utente che inoltra il comando. I parametri opzionali potrebbero essere usati per limitare il risultato della domanda(riscontrando il nome del service ed il tipo di service).

Risposte numeriche:

RPL_SERVLIST RPL_SERVLISTEND

3.5.2 Squery

Comando: SQUERY
Parametri: <nome del service> <testo>

Il comando SQUERY è usato similarmente al PRIVMSG. L’unica differenza è che il ricevente deve essere un service. Questo è l’unico modo per un messaggio di testo di essere rilasciato ad un service. Per maggiori dettagli su risposte ed esempi vedi PRIVMSG.

Esempi:

SQUERY irchelp :HELP privmsg ; Messaggio al service con nickname irchelp.

SQUERY dict@irc.fr :fr2en blaireau ; Messaggio al service con nome dict@irc.fr.

3.6 Domande riguardanti l’Utente

Le domande dell’utente sono un gruppo di comandi che principalmente interessano il trovare dettagli su un particolare utente o gruppo d’utenti. Quando si usano wildcards con qualsiasi di questi comandi,se c’è un riscontro,questi restituiranno solamente informazioni sugli utenti a te visibili. La visibilità di un utente è determinata da una combinazione di modalità dell’utente e dalla comune impostazione dei canali in cui si è.
Although services SHOULD NOT be using this class of message, they are allowed to.

3.6.1 Domanda Who

Comando: WHO
Parametri: [ <mask> [ "o" ] ]

Il comando WHO viene usato da un client per generare una domanda la quale restituisce un elenco di informazioni combacianti col parametro <mask> dato dal client. In assenza del parametro <mask> tutti quelli visibili(utenti che non sono invisibili(modalità utente +i) e chi non ha un canale comune con il client richiedente) sono elencati. Lo stesso risultato può essere ottenuto usando una <mask> pari a "0" o qualsiasi wildcard la quale terminerà riscontrando qualsiasi utente visibile.
Contrariamente,la <mask> passata a WHO è combaciata all’host dell’utente,server,nome reale e nickname se la <mask> del canale non può essere trovata. Se è passato il parametro "o" sono restituiti solamente gli operatori concordanti con la <mask> fornita.

Risposte numeriche:

ERR_NOSUCHSERVER
RPL_WHOREPLY RPL_ENDOFWHO

Esempi:

WHO *.fi ; Comando per elencare tutti gli utenti che combaciano con "*.fi".

WHO jto* o ; Comando per elencare tutti gli utenti aventi riscontro con "jto*" se essi sono un operatore.

3.6.2 Domanda Whois

Comando: WHOIS
Parametri: [ <target> ] <mask> *( "," <mask> )

Questo comando è usato per chiedere informazioni riguardanti un particolare utente. Il server risponderà a questo comando con parecchi messaggi numerici indicanti differenti stati di ogni utente che troverà riscontro con la mask(se tu hai i consensi per vederli). Se nella <mask> non è presente alcuna wildcard,qualsiasi informazione che ti è consentita vedere,riguardante quel nick, sarà presentata.
Se il parametro <target> è specificato,esso invia la domanda ad un server specifico. Esso è utile se vuoi sapere per quanto tempo l’utente in questione è stato inattivo,in quanto solamente il server locale(i.e., il server al quale l’utente è direttamente connesso)conosce quell’informazione,mentre qualsiasi altra cosa è globalmente conosciuta.
Le wildcards sono consentite nel parametro <target>.

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 ; Restituisce disponibili informazioni sull’utente riguardanti il nick wiz.

WHOIS eff.org trillian ; Chiede al server eff.org informazioni per l’utente riguardanti Trillian.

3.6.3 Whowas

Comando: WHOWAS
Parametri: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]

Whowas richiede informazioni riguardanti un nickname non esistente da molto. Questo potrebbe essere dovuto sia per un nickname cambiato che per un utente che ha lasciato IRC.
In risposta a questa domanda,il server perlustra attraverso la cronologia del suo nickname,cercando qualsiasi nick lessicalmente identico(nessuna wildcard combaciante qui). La cronologia è perlustrata all’indietro,restituendo la prima entrata più recente. Se ci sono più entrate,saranno restituite sulla risposta <count>(o tutte loro se non è dato nessun parametro <count>).
Se come parametro <count> viene passato un numero non positivo,verrà fatta una ricerca completa. Le wildcards sono consentite nel parametro <target>.

Risposte numeriche:

ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
RPL_WHOWASUSER RPL_WHOISSERVER
RPL_ENDOFWHOWAS

Esempi:

WHOWAS Wiz ; Restituisce tutte le informazioni contenute nella storia del nick,riguardanti il nick “Wiz”.

WHOWAS Mermaid 9 ; Restituisce al massimo le nove più recenti entrate nella storia del nick,per “Mermaid”.

WHOWAS Trillian 1 *.edu ; Restituisce la più recente cronologia per “Trillian” dal primo server che trova riscontro con "*.edu".

3.7 Messaggi Miscellaneuos

I messaggi di questa categoria non trovano alcun inserimento nelle categorie sopra riportate, ma fanno anche queste parte del protocollo e sono da questo richieste.

3.7.1 Messaggio Kill

Comando: KILL
Parametri: <nickname> <commento>

Il comando KILL viene usato per provocare la chiusura della connessione tra server-client dal server al quale è attualmente connesso. I servers generano messaggi KILL per collisioni di nick. Esso potrebbe anche essere reso disponibile agli utenti che hanno lo stato di operatore. I clients aventi la riconnessione automatica in realtà eseguono questo comando inutilmente fino a quando ha durata la disconnessione. Esso crea,comunque,un interruzione d’afflusso dei dati e può essere usato per fermare un flooding sia casuale che provocato da utenti abusivi. Gli utenti abusivi generalmente non importano in quanto essi si riconnetteranno prontamente e riassumeranno il loro comportamento abusivo. Per impedire l’abuso di questo comando, qualsiasi utente può ricevere messaggi KILL generati per altri in modo da stare attenti a situazioni che porterebbero guai. In un’arena,dove è richiesto ai nicknames di essere globalmente unici tutte le volte,i messaggi KILL sono inviati ogni volta che vengono rilevati “cloni”(che è un tentativo per registrare due utanti con lo stesso nickname)con la speranza che scompariscano entrambi e solamente uno riapparisca. Quando un client è rimosso come risultato di un messaggio KILL, il server dovrebbe aggiungere il nickname alla lista dei nickname non disponibili in modo da impedire al client di riusare questo nome immediatamente il quale è generalmente l’esempio di comportamento fastidioso spesso dovuti al mancato utilizzo di "KILL loops". Per maggiori informazioni riguardanti questa procedure,vedi il documento "IRC Server Protocol" [IRC-SERVER].
Il commento inserito deve rispecchiare la reale ragione del KILL. Per KILLS generati da server, generalmente il commento è composto da dettagli riguardanti le origini di due nicknames in conflitto. Per prevenire e scoraggiare i fake KILLs il commento riporta anche come 'kill-path' chi esegue il KILL e da quale server lo esegue.

Risposte numeriche:

ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK ERR_CANTKILLSERVER

Note:
Si raccomanda che solamente gli operatori siano abilitati ad eseguire un kill su altri utenti attraverso il comando KILL. Questo comando è stato oggetto di molte controversie durante gli anni e con le sopracitate raccomandazioni. E’ inoltre profondamente risaputo che a non ancora operatori è consentito pillare utenti su server remoti.

3.7.2 Messaggio Ping

Comando: PING
Parametri: <server1> [ <server2> ]

Il comando PING è usato per testare la presenza di un client o di un server attivi all’altro capo della connessione. I server inviano un messaggio PING ad intervalli regolari se nessun’altra attività proveniente da una connessione è rilevata. Se una connessione fallisce la risposta ad un messaggio PING per un definito numero di volte,quella connessione viene interrotta. Un messaggio PING potrebbe essere inviato anche se una connessione è attiva. Quando viene ricevuto un messaggio PING,l’appropriato messaggio PONG deve essere inviato in risposta al <server1>(server che invia in uscita il messaggio PING)il più presto possibile. Se il parametro <server2> è specificato,esso rappresenta il target del ping,ed il messaggio viene là inoltrato.

Risposte numeriche:

ERR_NOORIGIN ERR_NOSUCHSERVER

Esempi:

PING tolsun.oulu.fi ; Comando per inviare un messaggio PING al server.

PING WiZ tolsun.oulu.fi ; Comando eseguito da WiZ per inviare un messaggio PING al server "tolsun.oulu.fi".

PING :irc.funet.fi ; Messaggio PING inviato dal server "irc.funet.fi".

3.7.3 Messaggio Pong

Comando: PONG
Parametri: <server> [ <server2> ]

Il messaggio PONG è una risposta al messaggio ping. Se il parametro <server2> è specificato, questo messaggio deve essere inoltrato al dato target. Il parametro <server> è il nome della entità che ha risposto al messaggio ping e 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.

3.7.4 Error

Comando: ERROR
Parametri: <messaggio di errore>

Il comando ERROR è per l’uso da parte dei server quando devono riportare seri o fatali errori ai loro pari. Esso può anche assere inviato da un server all’altro ma non deve essere accettato da nessun client normale sconosciuto. Solamente un messaggio ERROR dovrebbe essere usato per riportare errori che accadono con un link server-to-sever. Un messaggio ERROR viene inviato al server all’altro capo(il quale lo riporta agli appropriati utenti locali e lo registra),agli appropriati utenti locali e viene registrato. Esso non è rimandato a nessun altro server da parte del server ricevente. Il messaggio ERROR viene anche usato prima del terminare di una connessione client. Quando un server invia ai suoi operatori un messaggio ERROR ricevuto,tale messaggio dovrebbe essere inserito in un messaggio NOTICE indicando che il client non era responsabile dell’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.

[Torna all'indice]

4 Configurazioni Facoltative

Questa sezione descrive messaggi OPTIONAL. Essi non sono richiesti,dalla normale applicazione del protocollo qui descritto,per l’esecuzione del lavoro del server. In assenza di configurazione,un messaggio di risposta error deve essere generato oppure un errore comando sconosciuto.
Se il messaggio è destinato ad un altro server per rispondere, poi esso deve essere passato oltre (elementare procedura richiesta). Le numeriche assegnate sono elencate con i messaggi che seguono
Da questa sezione,solamente i messaggi USERHOST e ISON sono disponibili ai services.

4.1 Away

Comando: AWAY
Parametri: [ <testo> ]

Con il comando AWAY i client possono impostare una risposta automatica per qualsiasi comando PRIVMSG diretto a loro. Il server spedisce una risposta automatica al client che invia il comando PRIVMSG. Il solo server a rispondere è quello a cui è connesso il client che invia.
Il comando AWAY viene usato sia con un parametro,per impostare un messaggio di AWAY,sia senza parametri,per rimuovere il messaggio di AWAY. A causa del suo alto costo(memoria e banda larga)il messaggio AWAY dovrebbe venire usato solamente per la comunicazione client-server. Un server potrebbe scegliere di ignorare silenziosamente un messaggio AWAY ricevuto da altri server. Per aggiornare lo stato di away di un client attraverso i server,dovrebbe essere invece usata la modalità utente ‘a’ (vedi sezione 3.1.5).

Risposte numeriche:

RPL_UNAWAY RPL_NOWAWAY

Esempio:

AWAY :Andato a pranzare. Torno tra 5 minuti ; Messaggio per impostare il seguente messaggio away ” Andato a pranzare.Torno tra 5 minuti”.

4.2 Messaggio Rehash

Comando: REHASH
Parametri: Nessuno

Il comando REHASH è un comando amministrativo che può essere usato da un operatore per forzare il server a rileggere ed eseguire il suo file di configurazione.

Risposte numeriche:

RPL_REHASHING ERR_NOPRIVILEGES

Esempio:

REHASH ; Messaggio da un utente con lo stato di operatore al server per chiedere di rileggere il suo file di configurazione.

4.3 Messaggio Die

Comando: DIE
Parametri: Nessuno

Un operatore può usare il comando DIE per interrompere il server. Questo messaggio è facoltativo in quanto esso potrebbe rischioso consentire a determinata gente di connettersi al server come operatori ed eseguire questo comando. Il comando DIE deve sempre essere totalmente eseguito dal server al quale il client che invia è connesso e non deve essere passato ad altri server connessi.

Risposte numeriche:

ERR_NOPRIVILEGES

Esempio:

DIE ; Nessun parametri richiesti.

4.4 Messaggio Restart

Comando: RESTART
Parametri: Nessuno

Un operatore può usare il comando RESTART per obbligare il server a riavviarsi da solo. Questo messaggio è facoltativo in quanto esso potrebbe rischioso consentire a determinata gente di connettersi al server come operatori ed eseguire questo comando,provocando(al minimo)un crollo al server. Il comando RESTART deve sempre essere totalmente eseguito dal server al quale il client che invia è connesso e non deve essere passato ad altri server connessi.

Risposte numeriche:

ERR_NOPRIVILEGES

Esempio:

RESTART ; Nessun parametri richiesti.

4.5 Messaggio Summon

Comando: SUMMON
Parametri: <utente> [ <target> [ <canale> ] ]

Il comando SUMMON può essere usato per dare agli utenti,che sono su un host di un IRC server, un messaggio che chiede a loro di accedere a IRC. Questo messaggio viene trasmesso solo se il server ricevente ha l'opzione SUMMON abilitato, se l'utente e' realmente loggato e se il server ricevente ha i diritti di scrittura sul processo tty dell'utente. Se non è dato alcun parametro <server>,esso proverà a chiamare utenti dal severa cui il client è connesso assumendolo come target. Se la chiamata non è abilitata in un server,questi deve ritornare il numerico ERR_SUMMONDISABLED

Risposte numeriche:

ERR_NORECIPIENT ERR_FILEERROR
ERR_NOLOGIN ERR_NOSUCHSERVER
ERR_SUMMONDISABLED RPL_SUMMONING

Esempi:

SUMMON jto ; Chiama l’utente jto sull’host del server.

SUMMON jto tolsun.oulu.fi ; Chiama l’utente jto sull’host di un server chiamato"tolsun.oulu.fi".

4.6 Utenti

Comando: USERS
Parametri: [ <target> ]

Il comando USERS restituisce un elenco di utenti registrati nel server in un formato simile ai comandi UNIX who(1),rusers(1) e finger(1). Se disabilitato,la corretta risposta numerica deve essere restituita per indicare ciò. A causa delle implicazioni di sicurezza di ciascun comando, esso dovrebbe essere disabilitato di default nelle esecuzioni del server. Abilitandolo,richiederebbe il ricompilare il server o qualche cambio equivalente piuttosto di un semplice adeguamento di un opzione e riavviare il server. La procedura per abilitare questo comando includerebbe idonei ed ampi commenti.

Risposte numeriche:

ERR_NOSUCHSERVER ERR_FILEERROR
RPL_USERSSTART RPL_USERS
RPL_NOUSERS RPL_ENDOFUSERS
ERR_USERSDISABLED

Risposta disabled:

ERR_USERSDISABLED

Esempio:

USERS eff.org ; Richiede un elenco di utenti registrati sul server eff.org.

4.7 Messaggio Operwall

Comando: WALLOPS
Parametri: <testo da inviare>

Il comando WALLOPS è usato per inviare un messaggio a tutti gli attuali utenti connessi che hanno per sé stessi impostato la modalità utente ‘w’ (vedi la sezione 3.1.5 Modalità Utente). Dopo aver reso effettivo WALLOPS come comando utenti ne venne spesso riscontrato un uso abusivo come mezzo per inviare un messaggio a molta gente. In considerazione di ciò,si raccomanda che l’esecuzione di WALLOPS consenta e riconosca solamente i server come originatori di WALLOPS.

Risposte numeriche:

ERR_NEEDMOREPARAMS

Esempio:

:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; Messaggio WALLOPS da csd.bu.edu che annuncia un messaggio CONNECT ricevuto da Joshua ed eseguito.

4.8 Messaggio Userhost

Comando: USERHOST
Parametri: <nickname> *( SPAZIO <nickname> )

Il comando USERHOST acquisisce una elenco fino a 5 nickname,ognuno separato da un carattere di spazio e restituisce una lista di informazioni riguardanti ciascun nickname trovato.
L’elenco restituito uno spazio che separa ogni risposta.

Risposte numeriche:

RPL_USERHOST ERR_NEEDMOREPARAMS

Esempio:

USERHOST Wiz Michael syrk ; USERHOST richiede informazioni riguardanti i
nick "Wiz", "Michael", and "syrk".

:ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net ; Risposta per l’utente syrk.

4.9 Messaggio Ison

Comando: ISON
Parametri: <nickname> *( SPAZIO <nickname> )

Il comando ISON venne reso effettivo per attuare un mezzo rapido ed efficiente per ottenere una risposta in modo da sapere se un dato nick era attualmente su IRC. ISON accetta solamente un (1)
tipo di parametro: una lista di nick separati dallo spazio. Per ciascun nickname presente nell’elenco il server aggiunge una sua stringa di risposta. Così la stringa di risposta potrebbe essere: restituita vuota(nessuno dei dati nick è presente),un esatta copia della stringa di parametro(tutti loro presenti) o qualsiasi altra sottoserie della serie di nick dati nel parametro. La sola restrizione al numero di nick che possono essere controllati è che la composta lunghezza non deve essere troppo grande per non provocare la rottura del server,così viene fissata a 512 caratteri. ISON è eseguito solamente dal server locale al client che invia il comando e non passato ad altri server per ulteriori esecuzioni.

Risposte numeriche:

RPL_ISON ERR_NEEDMOREPARAMS

Esempio:

ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk ; Semplice richiesta ISON per sette nick.

[Torna all'indice]

5 Risposte

Quello che segue è un elenco di risposte numeriche generate in risposta ai comandi dati qui sopra.
Ogni numerica è data con il proprio numero,nome e stringa di risposta.

5.1 Risposte al comando

Le numeriche comprese nel campo da 001 a 099 vengono usate solamente per le connessioni tra client-server e non dovrebbero mai viaggiare attraverso i servers. Le risposte generate come conseguenza dei comandi si trovano nel campo da 200 a 399.

Il server invia le risposte da 001 a 004 ad un utente ad avvenuta corretta registrazione.

Spedito dal server ad un utente per proporre un server alternativo. Questo viene spesso usato quando la connessione è negata in quanto il server è già pieno.

Formato della risposta usata da USERHOST per elencare le risposte alla lista della domanda.
La stringa della risposta è composta come segue:

risposta = nickname [ "*" ] "=" ( "+" / "-" ) hostname

Il carattere ‘*’ indica se il client si è registrato come operatore. I caratteri '-' o '+' indicano rispettivamente se il client ha impostato o meno un messaggio AWAY.

Formato della risposta usato da ISON per elencare le risposte alla lista della domanda.

Queste risposte sono usate con il commando AWAY(se consentito). RPL_AWAY viene mandato a qualsiasi client che invia un PRIVMSG ad un client away. RPL_AWAY viene inviato solamente dal server al quale il client è connesso. Le risposte RPL_UNAWAY e RPL_NOWAWAY sono inviate quando il client rimuove e imposta un messaggio AWAY.

Le risposte 311-313 e 317-319 sono tutte risposte generate come conseguenza di un messaggio WHOIS. Dato che sono presenti abbastanza parametri,il server che risponde deve o formulare una risposta non compresa nelle sopraccitate numeriche (se la domanda nick è stata trovata) o restituire una risposta di errore. Il '*' in RPL_WHOISUSER è presente come carattere letterale e non come una wildcard. Per ogni risposta impostata,solamente RPL_WHOISCHANNELS potrebbe comparire più di una volta (per lunghi elenchi di nomi di canale). I caratteri ‘@’ e ‘+’ vicini al nome nel canale indicano se un client è un operatore di canale oppure se gli è stato concesso il permesso di parlare in un canale moderato. La risposta RPL_ENDOFWHOIS viene usata per segnare la fine dell’esecuzione di un messaggio WHOIS.

Quando in risposta ad un messaggio WHOWAS,un server deve usare le risposte RPL_WHOWASUSER , RPL_WHOISSERVER o ERR_WASNOSUCHNICK per ciascun nome nell’elenco presentato. Alla fine di tutta la serie di risposte,deve esserci RPL_ENDOFWHOWAS
(tranne se c’era solamente una risposta ed era un errore).

Le risposte RPL_LIST e RPL_LISTEND segnano le risposte con dati e di fine della risposta del server al comando LIST. Se non ci sono canali disponibili da restituire,solamente la risposta di fine deve essere inviata.

Quando inviando un messaggio TOPIC per acquisire il topic del canale,una delle due risposte viene spedita. Se il topic è impostato, RPL_TOPIC viene spedito indietro,in caso diverso RPL_NOTOPIC.

Restituito dal server per indicare che il tentato messaggio INVITE è risultato positivo e stà per essere passato sul server finale.

Restituito dal server in risposta ad un messaggio SUMMON per indicare che esso stà chiamando quell’utente.

Quando elencando le ‘mask di invito’ per un dato canale,ad un server viene richiesto di restituire la lista usando i messaggi RPL_INVITELIST e RPL_ENDOFINVITELIST. Un RPL_INVITELIST separato è mandato per ciascuna mask attiva. Dopo che le mask sono state elencate(o se nessuna è presente)un RPL_ENDOFINVITELIST deve essere spedito.

Quando elencando le ‘exception mask’ per un dato canale,al server è richiesto di restituire la lista usando i messaggi RPL_EXCEPTLIST e RPL_ENDOFEXCEPTLIST. Per ogni mask attiva viene inviato un separato RPL_EXCEPTLIST. Finito di elencare le masks(o se non ce ne sono) deve essere inviato un RPL_ENDOFEXCEPTLIST .

Risposta del server per mostrare i dettagli della propria versione. Il <version> è la versione del software in uso(incluso qualsiasi revisione a livello di patch) e il <debuglevel> è usato per indicare se il server stà lavorando in ‘modalità debug’. Il campo “comments”poterebbe contenere qualsiasi commento riguardante la versione o ulteriori dettagli di questa.

RPL_WHOREPLY e RPL_ENDOFWHO vengono entrambi usati per rispondere ad un messaggio WHO. RPL_WHOREPLY è inviato solamente se c’è un appropriato riscontro con la domanda di WHO. Se con il comando WHO viene fornito un elenco di parametri,un RPL_ENDOFWHO deve essere inviato dopo aver analizzato ogni elenco parimenti con <name> essendo un dettaglio.

Di ritorno a un messaggio NAMES,le risposte RPL_NAMREPLY e RPL_ENDOFNAMES vengono entrambe tornate restituite dal server al client. Se,come da domanda,nessun canale viene trovato,solamente RPL_ENDOFNAMES viene ritornato. L’eccezione a ciò è quando un messaggio NAMES viene inviato senza alcun parametro e tutti i canali visibili vengono restituiti in una serie di messaggi RPL_NAMEREPLY con un RPL_ENDOFNAMES per segnare la fine.

In risposta al messaggio LINKS il server deve restituire le risposte usando la numerica RPL_LINKS e segnare la fine dell’elenco usando la risposta RPL_ENDOFLINKS.

Quando nell’elencare I ‘bans’ attivi in un dato canale,al server viene richiesto di restituire la lista usando i messaggi RPL_BANLIST e RPL_ENDOFBANLIST. Un separato RPL_BANLIST viene inviato per ciascuna banmask attiva. Dopo avere elencato le banmasks(o se non ce ne sono presenti)
Deve essere inviato un RPL_ENDOFBANLIST.

Nel rispondere ad un messaggio INFO,ad un server viene richiesto di restituire tutte le sue ‘info’ in una serie di messaggi RPL_INFO con una risposta RPL_ENDOFINFO per indicare la fine di tutte le risposte.

Quando rispondendo al messaggio MOTD ed il file MOTD viene trovato,il file è visualizzato linea per linea con ciascuna linea non più lunga di 80 caratteri,usando le risposte in formato RPL_MOTD
Queste devono essere accompagnate da un RPL_MOTDSTART (prima dei RPL_MOTDs) e da un RPL_ENDOFMOTD (dopo).

RPL_YOUREOPER viene restituito solamente al client che ha eseguito con successo il messaggio OPER e guadagnato lo stato di operatore.

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

Inviato da un server ad un service a registrazione avvenuta con successo.

Quando in risposta ad un messaggio TIME un server deve inviare la risposta usando il formato RPL_TIME. La stringa che mostra il time ha bisogno di contenere solamente la corretta data e ora.
Non c’è nessuna ulteriore richiesta per la stringa time.

Se il messaggio USERS è distribuito da un server,vengono usate le risposte RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS e RPL_NOUSERS. RPL_USERSSTART deve essere inviata per prima,seguita da una sequenza di RPL_USERS o da un singolo RPL_NOUSER. A terminare RPL_ENDOFUSERS.

Le RPL_TRACE* vengono tutte restituite dal server in risposta al messaggio TRACE.
Quante ne vengono restituite dipende dal messaggio TRACE e se è inviato da un operatore o no.
Non c’è un ordine prestabilito per quale deve venire prima o dopo.
Le risposte RPL_TRACEUNKNOWN, RPL_TRACECONNECTING e RPL_TRACEHANDSHAKE vengono usate per quelle connessioni che non sono state pienamente stabilite,che sono sconosciute,che stanno ancora tentando di connettersi o nel procinto di completare il 'server handshake'. RPL_TRACELINK è inviato da qualsiasi server che riceve un messaggio TRACE e deve passarlo ad un altro server. L’elenco di RPL_TRACELINKs inviato in risposta ad un comando TRACE attraversante la rete IRC,dovrebbe riflettere l’attuale collegamento dei servers tra di loro lungo quel percorso. RPL_TRACENEWTYPE deve essere usato per qualsiasi connessione che non rientra nelle altre categorie ma viene ugualmente visualizzata.
RPL_TRACEEND viene inviato per indicare la fine della lista.

Riporta statistiche riguardanti una connessione. <linkname> identifica la particolare connessione, <sendq> è la somma di dati accodati ed in attesa di essere inviati, <sent messages> il numero di messaggi inviati e <sent Kbytes> la dimensione di dati inviati espressa in Kbytes.
<received messages> e <received Kbytes> sono rispettivamente l’equivalente di <sent messages> e <sent Kbytes> per i dati ricevuti. <time open> indica in secondi per quanto tempo è rimasta attiva la connessione.

Riporta statistiche riguardanti l’uso dei comandi.

Riporta l’uptime del server.

Riporta gli hosts consentiti da dove un utente può diventare operatore IRC.

Per rispondere ad una domanda riguardo alle modalità di un client, RPL_UMODEIS è restituita.

Quando nell’elencare i services in risposta ad un messaggio SERVLIST,ad un server viene richiesto di restituire la lista usando i messaggi RPL_SERVLIST e RPL_SERVLISTEND. Un separato RPL_SERVLIST viene inviato per ciascun service. Dopo che i services sono stati elencati ( o se non ce ne sono presenti) un RPL_SERVLISTEND deve essere inviato.

Nell’eseguire un messaggio LUSERS il server invia una serie di risposte da RPL_LUSERCLIENT,
RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS e RPL_LUSERME.
Un server,nel rispondere,deve restituire RPL_LUSERCLIENT e RPL_LUSERME. Le altre risposte sono restituite solamente se si riscontra un calcolo per loro.

Quando rispondendo ad un messaggio ADMIN,un server si aspetta l’uso delle risposte RPL_ADMINME accoppiate a RPL_ADMINEMAIL e fornisce un messaggio di testo con ognuna.
For RPL_ADMINLOC1 a description of what city, state and country the server is in is expected, followed by details of the institution (RPL_ADMINLOC2) and finally the administrative contact for the server (an email address here is REQUIRED)in RPL_ADMINEMAIL.

Quando un server lascia cadere un commando senza eseguirlo deve usare la risposta RPL_TRYAGAIN per informare il client originante il comando.

5.2 Risposte di Errore

Le risposte di errore si trovano nel campo da 400 a 599.

Usato per indicare che il parametro nickname fornito ad un comando non è attualmente in uso.

Usato per indicare che il nome del server dato attualmente non esiste.

Usato per indicare che il dato nome di canale non è valido.

Inviato ad un utente che (a) non è in un canale in modalità +n o (b) non è un operatore di canale ( o in modalità +v) in un canale che è settato con la modalità +m o quando l’utente è bannato è tenta di inviare un messaggio PRIVMSG a quel canale.

Inviato ad un utente che,avendo già raggiunto il numero massimo di canali consentiti,stà cercando di entrare in un altro canale.

Ritornato da WHOWAS per indicare che non c’è nessuna informazione nella cronologia per quel nick.

Restituito ad un client che stà tentando di inviare un PRIVMSG/NOTICE usando il formato di destinazione user@host e per un user@host che ha molte necessità.

Restituito ad un client che stà tentando di inviare un PRIVMSG/NOTICE a troppi destinatari.

Restituito ad un client che stà cercando di entrare in un canale sicuro usando lo shortname quando ci sono più di un canale simili.

Restituito ad un clent che stà tentando di inviare una SQUERY ad un service che non esiste.

Messaggio di PING o PONG che ha perso il parametro originante.

412-415 sono restituiti da PRIVMSG per indicare che il messaggio non è stato diffuso per alcune ragioni. ERR_NOTOPLEVEL e ERR_WILDTOPLEVEL sono errori restituiti quando si fa un uso non valido di "PRIVMSG $<server>" o "PRIVMSG #<host>".

Restituito ad un client registrato per indicare che il commando usato è sconosciuto dal server

Il file MOTD del server non può essere aperto dal server.

Restituito dal server in risposta ad un messaggio ADMIN quando c’è un errore nel ricercare le appropriate informazioni.

Messaggio di errore generico usato per riportare un operazione del file fallita durante l’esecuzione di un messaggio.

Restituito quando il parametro nickname è atteso per un comando e non è trovato.

Restituito dopo aver ricevuto un messaggio NICK contenente caratteri che non rientrano nelle impostazioni definite. Vedi sezione 2.3.1 per maggiori dettagli riguardo ai nicknames validi.

Restituito quando un messaggio NICK è risultato come tentativo di cambiare in un nickname già attualmente esistente.

Restituito da un server ad un client quando viene riscontrata una collisione tra nickname(registrazione di un nick che già esiste su un altro server).

Restituito da un server ad un utente che ctà cercando di entrare in un canale attualmente bloccato dal meccanismo di ritardo del canale.

Restituito da un server ad un utente che stà cercando di cambiare nickname quando questo è bloccato dal meccanismo di ritardo del nick.

Restituito dal server per indicare che il target utente del comando non è nel canale specificato.

Restituito dal server ogni volta che un client prova ad eseguire un comando che interessa un canale del quale il client non è membro.

Restituito quando un client prova ad invitare un utente in un canale dove già è presente.

Restituito dopo un commando SUMMON,per un utente,inabilitato ad essere eseguito in quanto l’utente non era loggato.

Restituito come risposta ad un commando SUMMON. Deve essere restituito da qualsiasi server che non compie il comando.

Restituito come risposta ad un commando USERS. Deve essere restituito da qualsiasi server che non compie il comando.

Restituito dal server per indicare che il client deve essere registrato prima che il server gli permetta di essere analizzato nel dettaglio.

Restituito dal server per numerosi comandi per indicare al client che il comando non fornisce sufficienti parametri.

Restituito dal server a qualsiasi link che prova a cambiare parte dei dettagli registrati (come la password o dettagli utente dal secondo messaggio USER).

Restituito ad un client che tenta di registrarsi con un server che non è stato settato a consentire connessioni dall’host che stà effettuando il tentativo di connessione.

Restituito per indicare un tentativo fallito di registrazione della connessione per la quale è richiesta una password e non è stata data o data in modo incorretto.

Restituito dopo un tentativo di connettersi e registrarsi con un server che è stato settato esplicitamente per negarti le connessioni.

Inviato da un server ad un utente per informare che sarà presto negato.

Qualsiasi commando che per essere eseguito richiede privilegi da operatore,deve restituire questo errore per indicare che il tentativo non ha avuto successo.

Qualsiasi commando che richiede privilegi da operatore di canale(come ad esempio i messaggi MODE) deve restituire questo errore nel caso che il client che stà tentando non è operatore di canale nel canale specificato.

Qualsiasi tentative di usare il commando KILL su un server deve essere respinto e questo errore ritornato direttamente al client.

Inviato dal server ad un utente alla connessione per indicare la natura limitata della connessione
(modalità utente “+r”).

Qualsiasi MODE che richiede privilegi da “creatore del canale” deve restituire questo errore se il client che stà facendo il tentativo non è operatore di canale nel canale specificato.

Se il client invia un messaggio OPER ed il server non è stato configurato per consentire una connessione come operatore dall’host del client,questo errore deve essere ritornato.

Restituito dal server per indicare che un messaggio MODE è stato spedito con un parametro nickname e che la flag di modalità inviata non è stata riconosciuta.

Errore inviato a qualsiasi utente che stà cercando di vedere o cambiare le modalità di un utente diverso da sé stesso.

5.3 Numerazioni Riservate

Queste numeriche non sono descritte sopra,esse rientrano in una delle seguenti categorie:
· Non più in uso
· Riservato per un progettato uso futuro
· Di uso corrente ma non fanno parte delle generiche caratteristiche dell’attuale server IRC

231 RPL_SERVICEINFO
232 RPL_ENDOFSERVICES
233 RPL_SERVICE
300 RPL_NONE
316 RPL_WHOISCHANOP
361 RPL_KILLDONE
362 RPL_CLOSING
363 RPL_CLOSEEND
373 RPL_INFOSTART
384 RPL_MYPORTIS

213 RPL_STATSCLINE
214 RPL_STATSNLINE
215 RPL_STATSILINE
216 RPL_STATSKLINE
217 RPL_STATSQLINE
218 RPL_STATSYLINE
240 RPL_STATSVLINE
241 RPL_STATSLLINE
244 RPL_STATSHLINE
244 RPL_STATSSLINE
246 RPL_STATSPING
247 RPL_STATSBLINE
250 RPL_STATSDLINE

492 ERR_NOSERVICEHOST

[Torna all'indice]

6. Esecuzioni

Il software IRC,versione 2.10 è solamente la completa esecuzione del protocollo IRC(client-server)
A causa di piccoli cambiamenti nel protocollo client dalla pubblicazione dell’RFC 1459 [IRC],le esecuzioni che la seguono sono probabilmente fornite con questo protocollo o per richiedere una piccola somma di cambiamenti per giungere a soddisfazione.

[Torna all'indice]

7. Problemi Attuali

Ci sono un numero di problemi conosciuti col protocollo client IRC ed in modo più generale con il protocollo server di IRC. In ordine per evitare lente compatibilità con vecchi clients,questo protocollo non è stato sviluppato dalla pubblicazione dell’RFC 1459 [IRC].

7.1 Nicknames

L’idea del nickname per un utente in IRC è molto conveniente per quando si parla a ciascun altro al di fuori del canale,ma lo spazio per il nickname,come attualmente, non è illimitato. Non è raro per molta gente voler usare lo stesso nick. Se un nickname viene scelto da due persone,usando questo protocollo una delle due non avrà successo o entrambi saranno rimosse mediante l’uso di un server KILL (vedi sezione 3.7.1).

7.2 Limitazioni di Wildcards

Non c’è modo di eludere il carattere "\" (%x5C). Mentre questo generalmente non è un problema,esso fa si che sia impossibile formare una mask con un carattere backslash ("\") che precede una wildcard.

7.3 Considerazioni di Sicurezza

Le questioni della sicurezza relative a questo protocollo sono discusse nell’ "IRC Server Protocol" [IRC-SERVER] soprattutto su come sono un problema per la connessione dalla parte del server.

[Torna all'indice]

8. Supporto Attuale e Disponibilità

Mailing lists per le discussioni relative a IRC:
- Discussioni generali: ircd-users@irc.org
- Sviluppo protocollo: ircd-dev@irc.org

Esecuzioni del software:
- ftp://ftp.irc.org/irc/server
- ftp://ftp.funet.fi/pub/unix/irc
- ftp://ftp.irc.org/irc/clients

Newsgroup: alt.irc

[Torna all'indice]

9. Ringraziamenti

Parti di questo documento sono state copiate dall’ RFC 1459 [IRC] il quale per primo formalmente ha documentato il protocollo IRC. Esso ha tratto anche beneficio da molti incontri di revisioni e commenti. In particolar modo le seguenti persone hanno apportato un significativo contributo a questo documento:
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen,
Magnus Tjernstrom, Stefan Zehl.

[Torna all'indice]

10. Referenze

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[HNAME] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.

[IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
RFC 1459, May 1993.

[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.

[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, April 2000.

[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, April 2000.

[Torna all'indice]

11. Indirizzo dell’Autore

Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA

EMail: kalt@stealth.net

[Torna all'indice]

12. Enunciato del Copyright Completo

Copyright (C) The Internet Society (2000). Tutti i diritti riservati. Questo documento e le sue traduzioni possono essere copiati e dati ad altri, e i lavori derivati che commentano sopra o altrimenti lo spiegano o aiutano nella sua messa in opera possono essere preparati, copiati, pubblicati, interi o a pezzi, senza riserva nessuna, alla condizione che questo avviso di copyright e questo paragrafo siano inclusi in tutte le copie e lavori derivativi. Tuttavia, questo documento, non deve essere modificato in nessun modo, togliendo l'avviso di copyright o riferimenti all'Internet Society o altri organismi di Internet, ad eccezione di, come richiesto per l'intenzione di sviluppare i standard di Internet in questo caso le modalità per i copyright definite nel trattamento dei Standard di Internet devono essere seguite, o come richiesto per essere tradutzioni in linguaggi diversi altri che l'Inglese. I permessi limiti concessi sopra sono perpetui e non sarano ritrattati dalla Internet Society o i suoi successori o legatori.
Questo documento e le informazioni contenute qui dentro sono dati in base a "TALE E QUALE" e THE INTERNET SOCIETY E L'INGEGNERIA DEI SISTEMI LAVORATORI DENEGA TUTTE LE GARANZIE ESPRESSE O TACITE, INCLUDENDO MA NON LIMITATO A QUALSIASI GUARANZIA CHE L'USO DELL' INFORMAZIONE ACCLUSA NON USURPERA QUALSIASI DIRITTI O QUALSIASI GARANZIE TACITE DI MERCANTABILITA O CONVENIENZA PER UN PROPOSITO PARTICOLARE.
Ringraziamenti: Il finanziamento per la funzione di Editore di RFC e' attualmente data dalla Internet Society.

Traduzione dell'RFC 2811 in lingua originale a cura di :
Giandomenico "TiNtOrEtTo" Moioli tintoretto@ircitaly.net
Michele "M|[ck]3y" Bagnoli mickey@ircitaly.net
Ultima revisione: 5 Maggio 2004

E' possibile copiare e diffondere, integralmente o parzialmente, gli articoli solo citando la fonte www.irchelp.it e i rispettivi autori.
IRCHelp.it e IRCItaly.net sono prodotti registrati da WWWorld S.r.l. P.IVA 02207191202 per correzioni, suggerimenti, contatti: info@ircitaly.net