Internet Relay Chat: Direzione (gestione) del Canale

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 e illimitata.

Notifica di Copyright

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

Riassunto

Una delle più notevoli caratteristiche del protocollo di IRC (Internet Relay Chat) è quella di permettere agli utenti di essere ragruppati in forum chiamati canali, fornendo così la possibilità per una molteplicità di utenti di comunicare tra loro. All'inizio, c'era un unico tipo di canale, ma con gli anni, nuovi tipi sono apparsi sia come risposta a un bisogno che per meta sperimentale. Questo documento precisa come i canali, le loro caratteristiche e particolarità sono gestiti dai servers IRC.

Sommario

1. Introduzione
2. Caratteristiche del canale

2.1 Spazio per il nome
2.2 Estensione del canale
2.3 Accessori del canale
2.4 Utenti privilegiati del canale
2.4.1 Operatori del canale
2.4.2 Fondatori del canale

3.1 Canali standard
3.2 Canali Sicuri

4.1 Stato degli utenti
4.1.1 Stato di "Fondatore del canale"
4.1.2 Stato del Operatore del canale
4.1.3 Previlegi del Voice
4.2 Modalità del Canale
4.2.1 Modalità Anonimo
4.2.2 Modalità Solo su Invito
4.2.3 Modalità Canale Moderato
4.2.4 No Messaggi al Canale da Client esterni
4.2.5 Canale Silenzioso
4.2.6 Canali Privati e Segreti
4.2.7 Opzione Reop Server
4.2.8 Topic
4.2.9 Limite di Utenti
4.2.10 Chiave del Canale
4.3 Controllo dell'Accesso al Canale
4.3.1 Ban sul Canale ed Eccezione
4.3.2 Invito sul Canale

5.1 Tracce dei Canali Usati recentemente
5.2 Canali Sicuri
5.2.1 Identificatore di Canale
5.2.2 Ritardo del Canale
5.2.3 Finestra Abuso
5.2.4 Garantire sicurezza al namespace del canale
5.2.5 Meccanismo Reop Server

6.1 Labels - Etichette
6.1.1 Ritardo del Canale
6.1.2 Canali Sicuri
6.2 Ritardi nella Propagazione dei Modi
6.3 Conflitti e Modi del Canale
6.4 Esaurimento delle Risorse

7.1 Controllo dell'Accesso
7.2 Canale Privato
7.3 Anonimato

8. Assistenza Attuale e Disponibilità
9. Ringraziamenti
10. Referenze
11. Indirizzo dell'Autore
12. Enunciato del Copyright Completo

1. Introduzione

Questo documento definisce minutamente come i canali sono gestiti dai servers IRC e sarà principalmente utile alla gente che lavora al funzionamento di un server IRC. Anche se i concetti definiti qui sono una parte importante di IRC, non rimangono essenziali per generare clients. Mentre la tendenza sembra orientarsi verso clients sempre più complessi ed ”intelligenti", capaci di approfittare e di capire come funzionano i canali, per proporsi agli utenti con un'interfaccia sempre più immediata ed intuitiva, semplici clients possono essere generati senza leggere questo documento. Tanti concetti definiti qui sono stati disegnati facendo riferimento all'architettura di IRC [IRC-ARCH](RFC competente) e principalmente prendono tutto il loro senso in questo contesto. Tuttavia, tanti altri concetti potrebbero essere applicati ad altre architetture per potere fornire forum ad un sistema di conferenza. Infine c'è da notare che gli utenti di IRC possono trovare interessanti le sezioni che seguono, soprattutto le sezioni 2 ( Caratteristiche del Canale) e 4 (Modi del Canale).
[ Torna al Sommario ]

2. Caratteristiche del canale

Un canale è un gruppo con un nome, di uno o più utenti che vanno tutti a ricevere messaggi mandati a questo canale. Le caratteristiche di un canale sono il suo nome, proprietà e utenti attuali.
[ Torna al Sommario ]

2.1 Spazio per il nome (Namespace)

I nomi dei canali sono testi (preceduti da un carattere '&', '#', '+' o '!') di lunghezza fino a cinquanta (50) caratteri. I nomi dei canali sono riconosciuti comunque (siano essi in maiuscolo che in minuscolo). Fermo restando che il primo carattere sia uno di questi : '&', '#', '+' o '!' (chiamati qui "prefissi del canale"), l'unica restrizione sul nome del canale è che non DEVE comportare spazi (' '), un control G (^G o ASCII 7), una virgola (',' usata come un separatore di articoli su una lista di protocollo). Anche, un segno di due punti (':') è usato come separatore per la mask del canale. La sintassi esatta del nome del canale è definita in "IRC Server Protocol" [IRC-SERVER]. L'uso di diversi prefissi crea effettivamente quattro (4) spazi distinti per il nome (namespaces) per i nomi del canale. Questo è importante per le limitazioni del protocollo riguardanti gli spazi per il nome (namespaces)(in generale). Leggere sezione 6.1 ( Flag ) per altri particolari su questi limitazioni.
[ Torna al Sommario ]

2.2 Estensione del canale

L'esistenza del canale è riconosciuta da uno o più server sulla rete IRC. Un utente può solo diventare membro di un canale conosciuto dal server al quale l'utente è direttamente collegato. La lista dei servers che sanno dell'esistenza di un particolare canale DEVONO essere una parte contigua della rete di IRC, così i messaggi mandati al canale possono essere spediti a tutti gli utenti del canale. I canali con '&' come prefisso sono locali al server dove sono creati. Altri canali sono riconosciuti da uno (1) o più servers che sono connessi alla rete, in relazione alla maschera (mask) del canale :

Se non c'è una mask del canale, allora il canale è conosciuto da tutti i servers. Se il canale ha una mask, allora il canale DEVE solo essere conosciuto dal server che ha un utente locale sul canale, e dai vicini se la maschera corrisponde ai nomi dei servers locali e vicini. Da quando altri servers non hanno assolutamente conoscenza della esistenza di un canale , lo spazio formato dai servers che hanno un nome che corrisponde alla maschera deve essere contiguo per il canale per essere conosciuta da tutti i servers. Le maschere del canale sono meglio usate in congiunzione col server hostmasking [IRC-SERVER].
[ Torna al Sommario ]

2.3 Proprietà del canale

Ogni canale ha le sue proprietà, definite con i modi del canale (channel modes). I modi del canale possono essere settati dagli utenti del canale. I modi esercitano un'influenza sul modo con il quale i servers gestiscono i canali. I canali con il prefisso '+' non comportano i modi del canale. Questo vuol dire che tutti i modi sono disattivati, con l'eccezione dell'opzione del canale 't' che e' attivata.
[ Torna al Sommario ]

2.4 Utenti privilegiati del canale

Per potere avere un miglior controllo del canale e una certa forma di ordine, certi utenti del canale sono privilegiati. Solamente questi utenti sono autorizzati ad eseguire queste azioni sul canale :

2.4.1 Operatori del canale

Gli operatori del canale (anche chiamati "chop" o "chanop") su un dato canale sono considerati come 'possessori' del canale. La gestione di un canale è condivisa tra gli operatori. Gli operatori del canale sono identificati con il simbolo '@' vicino al loro nick quando è associato ad un canale (per esempio, risposte ai comandi NAMES , WHO e WHOIS ). Nel caso in cui i canali iniziano con il carattere '+' siccome il prefisso non supporta i modi del canale, allora gli utenti non possono avere lo stato di operatori del canale. [ Torna al Sommario ]

2.4.2 Fondatore del canale

Un utente che crea un canale con il carattere '!' come prefisso e' identificato come il “fondatore del canale”. Oltre a fondatore del canale, a questo utente viene anche dato lo stato di operatore del canale. In riconoscimento di questo stato, i fondatori del canale sono dotati della capacità di selezionare certi modi del canale che agli operatori del canale non è consentito settare. Il "fondatore del canale" può essere distinto dall operatore del canale mediante l'uso del comando MODE. Leggere il "IRC Client Protocol" [IRC-CLIENT] per ulteriori informazioni su questo argomento.
[ Torna al Sommario ]

3. Longevità del canale

Per quel che riguarda la longevità del canale, ci sono tipicamente due gruppi di canali : canali standard con il prefisso '&', '#' o '+', e i “canali sicuri” con il prefisso '!'.
[ Torna al Sommario ]

3.1 Canali standard

Questi canali sono creati implicitamente quando il primo utente entra in uno di questi canali e si estinguono quando l'ultimo utente lo lascia uscendo. Mentre il canale esiste, qualsiasi client puo dare la reference del canale usando il nome del canale. L'utente che crea un canale diventa automaticamente operatore del canale con l'ovvia eccezione dei canali che hanno un nome prefissato con il carattere '+', leggere sezione 4 (Modi del Canale). Leggere sezione 2.4.1 (Operatori del Canale) per altri particolari su questo argomento. Per poter evitare i canali duplicati (specialmente quando la rete IRC diventa divisa per colpa di una separazione (split) di 2 servers), i nomi dei canali NON DEVONO essere autorizzati ad essere riusati da un utente se l'operatore del canale (leggere sezione 2.4.1 (Operatori del Canale)) ha lasciato recentemente il canale per colpa di una separazione della rete. Se questo succede il nome del canale è provvisoriamente indisponibile. Il periodo per il quale un canale rimane indisponibile deve essere in armonia con la base della rete IRC. E' importante notare che questo impedisce agli utenti locali di creare un canale usando lo stesso nome, ma non impedisce al canale di essere ricreato da un utente remoto. Quest'ultimo capita tipicamente quando la rete IRC si riconnette. Ovviamente, questo meccanismo ha solo un significato per i canali con il nome che inizia con il carattere '#', ma PUO' essere usato per canali con il nome che inizia con il carattere '+'. Questo meccanismo e' generalmente conosciuto come "Channel Delay ".
[ Torna al Sommario ]

3.2 Canali Sicuri (Safe)

I “Canali Sicuri”(Safe), diversamente dagli altri canali, non sono implicitamente creati. Un utente che vuole creare questo canale DEVE chiederne la creazione mandando un comando speciale JOIN al server il quale identifica il canale (allora sconosciuto) con il carattere '!'. Il processo di creazione per questo tipo di canale e' rigorosamente controllato. L'utente sceglie solo una parte del nome del canale ,conosciuto come il “nome corto” ("short name") del canale, il server automaticamente mette un prefisso al nome dato dall'utente con un identificatore di canale composto di cinque (5) caratteri. Il nome del canale risultato dalla combinazione di questi due elementi è unico, proteggendo così il canale contro gli abusi basati sulle separazioni della rete. L'utente che crea questo tipo di canale diventa automaticamente "Fondatore del Canale". Leggere sezione 2.4.2 (Fondatore del Canale) per altri particolari su questo titolo. Un server NON DEVE permettere la creazione di un nuovo canale se un altro canale con lo stesso nome corto (short name) già esiste , o se un altro canale con lo stesso nome corto è esistito recentemente e qualsiasi dei suoi membri e' uscito per colpa della separazione(split) della rete. Questo tipo di canale si estingue dopo che l'ultimo utente esce e nessun altro membro è recentemente uscito dal canale per colpa della separazione della rete. Diversamente da come descritto nella sezione 5.2.2 (Ritardo del Canale: Delay), in questo caso, i nomi dei canali non diventano indisponibili : questi canali possono continuare ad esistere dopo l'uscita dell'ultimo utente. Solo l'utente che crea il canale diventa il “Fondatore del Canale”, gli utenti che entrono in un canale vuoto che esiste non diventano “Fondatori del Canale” e nemmeno “Operatori del Canale”. Per assicurare che i nomi del canale siano unici, l'identificatore di canale creato dal server DEVE seguire regole specifiche. Per altri particolari a riguardo, leggere sezione 5.2.1 (Identificatore di Canale).
[ Torna al Sommario ]

4. Modalità del Canale

I diversi modi disponibili per i canali sono i seguenti :

O – da lo stato di “fondatore del canale” ;
o - da/toglie la prerogativa di operatore del canale ;
v - da/toglie la prerogativa del voice ;
a - seleziona il modo di canale incognito ;
i - seleziona il modo di canale accessibile solo su invito ;
m – seleziona il modo di canale moderato ;
n - seleziona il no messaggi al canale da clients esterni ;
q - seleziona il modo di canale silenzioso ;
p - seleziona il modo di canale privato ;
s - seleziona il modo di canale segreto ;
r - seleziona il modo di canale reop server ;
t - seleziona il modo di argomento settabile solo dall' operatore del canale ;
k – attiva/toglie la chiave del canale (la password);
l - attiva/toglie il limite degli utenti sul canale ;
b – attiva/toglie la mask di ban per tenere gli utenti fuori dal canale ;
e - attiva/toglie una mask in modalità eccezionale per ignorare una mask di ban ;
I – attiva/toglie una mask di invito per consentire l'accesso solo su invito ;

A meno che non sia accennato diversamente in seguito, tutti questi modi possono essere settati dagli “operatori del canale” usando il comando MODE definito nel “Protocollo del Cliente IRC” ("IRC Client Protocol") [IRC-CLIENT].
[ Torna al Sommario ]

4.1 Stato di Utenti

I modi in questa categoria riguardano il nick di un utente del canale e come essi influiscono sui privilegi dati a questo utente.
[ Torna al Sommario ]

4.1.1 Stato di "Fondatore del Canale"

4.1.2 Stato di Operatore del Canale

Il modo 'o' è usato per selezionare lo stato di operatore di un utente del canale.
[ Torna al Sommario ]

4.1.3 Privilegi del Voice

Il modo 'v' è usato per dare e togliere il privilegio di poter parlare a/da un utente del canale. Gli utenti con questo privilegio possono parlare sui canali moderati. (Leggere sezione 4.2.3 (Modo del Canale Moderato).
[ Torna al Sommario ]

4.2 Modi del Canale

In questa categoria i modi sono usati per definire le proprietà che influiscono sul funzionamento dei canali.
[ Torna al Sommario ]

4.2.1 Modalità Anonimo

La modalità del canale 'a' definisce un canale anonimo. Questo vuol dire che quando un messaggio è mandato in un canale da un utente attraverso il server, allora DEVE essere mascherato. Per mascherare il messaggio, la provenienza è cambiata in " anonymous!anonymous@anonymous" (per esempio, un utente con un nick"anonymous", il nome dell'utente "anonymous" (incognito) e da un server chiamato "anonymous"). Per questa ragione, i servers DEVONO vietare agli utenti di usare il nick "anonymous". I servers NON DEVONO mandare i messaggi QUIT (exit) per utenti che escono da questi canali agli altri membri del canale ma, invece, generare un messaggio PART (allontanamento dal singolo canale). Sui canali che hanno come prefisso il carattere '&', questo segnale PUO' essere selezionato dagli operatori del canale, ma sui canali che hanno come prefisso il carattere '!', questo segnale puo' essere attivato (ma non sarà disattivato) solo dal "fondatore del canale". Questa opzione NON DEVE essere resa disponibile su altri tipi di canali. Le risposte ai comandi WHOIS, WHO e NAMES NON DEVONO rivelare la presenza di altri utenti sul canale con la opzione anonimo attivata.
[ Torna al Sommario ]

4.2.2 Modalità Solo su Invito

Quando l'opzione del canale 'i' è attivata,i nuovi utenti sono accettati solo se la loro mask corrisponde alla lista degli invitati (leggere sezione 4.3.2) o sono stati invitati da un operatore del canale. Questa modalità restringe anche l'uso del comando INVITE (leggere "IRC Client Protocol" [IRC-CLIENT]) agli operatori del canale.
[ Torna al Sommario ]

4.2.3 Modalità Canale Moderato

La modalità del canale 'm' è usata per controllare chi può parlare su un canale. Quando è attivata, solo gli operatori del canale, e gli utenti che hanno ricevuto il privilegio del voice possono mandare messaggi al canale. Questa modalità influisce solo sugli utenti.
[ Torna al Sommario ]

4.2.4 No Messaggi al Canale da Clients Esterni

Quando il modo del canale 'n' è attivato, solo gli utenti del canale POSSONO mandare messaggi al canale. Questo modo influisce solo sugli utenti.
[ Torna al Sommario ]

4.2.5 Canale Silenzioso (Quiet)

Il modo di canale 'q' è usato solo dai servers. Quando viene attivato, restringe il tipo di informazioni mandate agli utenti riguardanti le operazioni del canale : un altro utente che entra, l'uscita e il cambio di nick non sono mandati. Dal punto di vista di un utente, il canale contiene un utente solo. Questo e' usato tipicamente per creare speciali canali locali sui quali il server manda avvisi che si riferiscono alle sue operazioni. Questo era usato come modo più efficace e flessibile di sostituire il modo per utenti 's' definito in RFC 1459 [IRC].
[ Torna al Sommario ]

4.2.6 Canali Privati e Segreti

Il modo del canale 'p' è usato per indicare un canale "privato" e il modo del canale 's' per indicare un canale "segreto". Tutte e due le proprietà sono similari e nascondono l'esistenza del canale agli altri utenti. Questo significa che non c'è modo di ottenere il nome del canale dal server senza esserne un utente. In altre parole, questi canali DEVONO essere omessi dalle risposte alle richieste di comandi come il WHOIS. Quando un canale è "segreto",in aggiunta a quanto detto sopra, il server si comporterà come se il canale non esistesse per domande come quelle del comando di TOPIC (argomento), LIST (lista), NAMES (nomi). C'è da notare che vi è una eccezione a questa regola : i servers risponderanno correttamente al comando MODE. Infine , i canali segreti non sono elencati nella risposta al comando LUSERS (Leggere "Internet Relay Chat: Client Protocol" [IRC- CLIENT]) quando il parametro <maschera> (mask) è specificato. I modi del canale 'p' e 's' NON DEVONO essere attivati allo stesso tempo. Se il messaggio MODE che proviene da un server attiva il modo 'p' e il modo 's' è gia attivato per il canale, il cambio è ignorato in silenzio. Questo dovrebbe accadere solo durante una fase di ripristino della separazione di rete (accennato nel documento "IRC Server Protocol" [IRC-SERVER]).
[ Torna al Sommario ]

4.2.7 Flag di Reop Server

Il modo del canale 'r' è disponibile solo sui canali con il nome che inizia con il carattere '!' e PUO' solo essere selezionato dal fondatore del canale ("channel creator"). Questo modo è usato per impedire ad un canale di rimanere senza operatore del canale per un periodo di tempo prolungato. Quando questo modo è attivato,in qualsiasi canale ento (TOPIC)

L'opzione del canale 't' è usata per limitare l'uso del comando TOPIC ai soli operatori del canale.
[ Torna al Sommario ]

4.2.9 Limite di Utenti

Un limite di utenti può essere attivato sui canali usando il modo del canale 'l'. Quando il limite è raggiunto, i servers DEVONO vietare ai loro utenti locali di entrare nel canale. Il valore del limite DEVE solo essere attivato agli utenti del canale in risposta ad una richiesta del server.
[ Torna al Sommario ]

4.2.10 Chiave del Canale

Quando una chiave di canale è attivata (usando il modo 'k'), i servers DEVONO rifiutare la domanda dei loro utenti locali ad entrare nel canale a meno che questa chiave sia notificata La chiave del canale DEVE solamente essere visibile dagli utenti del canale in risposta ad una richiesta del server.
[ Torna al Sommario ]

4.3 Controllo dell'Accesso al Canale

L'ultima categoria dei modi è usata per controllare l'accesso al canale, essi si basano sulla mask. Al fine di ridurre la dimensione del database globale per i modi di Controllo attivati di accesso per i canali, i servers POSSONO mettere un limite massimo sul numero di questi modi attivati per un particolare canale. Se questa limitazione è imposta, DEVE solo interessare le richieste degli utenti. La limitazione DEVE essere consona con la base della rete IRC.
[ Torna al Sommario ]

4.3.1 Ban sul Canale ed Exceptions (eccezioni)

Quando un utente chiede di entrare in un canale, il suo server locale verifica che l'indirizzo dell'utente non corrisponda a qualsiasi mask di ban attivata per il canale. Se vi è corrispondenza , la richiesta dell'utente sarà rifiutata a meno che l'indirizzo corrisponda anche alla mask di eccezione attivata per il canale(+e). I servers NON DEVONO permettere a un utente del canale che e' stato bannato dal canale di parlare sullo stesso, a meno che questo utente sia un operatore di canale o abbia i privilegi del voice. (Leggere sezione 4.1.3 (Privelegi del Voice)). Un utente che è stato bannato da un canale ma che riceve un invito mandato da un operatore del canale, è autorizzato ad entrare nel canale.
[ Torna al Sommario ]

4.3.2 Invito sul Canale

Per i canali che hanno il modo solo su invito attivato (leggere sezione 4.2.2 (Modalità Solo su Invito)), gli utenti il cui indirizzo corrisponde a una maschera di invito attivata per il canale sono autorizzati ad entrare nel canale ad inviti.
[ Torna al Sommario ]

5. Attuali implementazioni e aggiunte

L'esecuzione di queste regole fanno parte del protocollo IRC server, versione 2.10. Il resto di questa sezione tratta di argomenti che sono importanti principalmente per quelli che vogliono installare un server ma alcune sezioni possono anche essere interessanti per programmatori di client.
[ Torna al Sommario ]

5.1 Tracce dei Canali Usati recentemente

Questo meccanismo è più comunemente conosciuto come "Ritardo di Canale" e generalmente si applica solamente ai canali con nomi prefissati con il carattere '#' (leggere sezione 3.1 "Canali Standard"). Quando avviene una separazione di rete , i servers DEVONO memorizzare quale canale ha perso un “operatore del canale” in conseguenza alla separazione. Questi canali sono allora in uno stato speciale che dura per un certo periodo di tempo. I canali non possono rimanere a lungo in questo particolare stato. Se tutti gli utenti del canale escono , il canale diventa indisponibile : i clients del server locale non possono entrare nel canale per tutto il tempo che rimarrà vuoto. Una volta che un canale è indisponibile, diventerà ancora disponibile o perchè un utente remoto e' entrato nel canale (più probabilmente perchè la rete sta riallineandosi), o perchè il periodo di ritardo e' scaduto (in questo caso il canale non esiste più e può essere ricreato). La durata per la quale la cancellazione del canale è ritardata DEVE essere impostata considerando molto fattori tra i quali la dimensione (riguardante l'utenza) della rete IRC, e la durata media delle separazioni della rete. Questa DEVE essere uniforme su tutti i servers di una determinata rete IRC.
[ Torna al Sommario ]

5.2 Canali Sicuri (Safe)

Questo documento presenta la nozione di "Canali Sicuri(Safe)". Questi canali hanno un nome prefissato con il carattere '!' e un grande sforzo è stato fatto per evitare collisioni in questo spazio del nome. I conflitti non sono impossibili, tuttavia sono molto spiacevoli.
[ Torna al Sommario ]

5.2.1 Identificatore di Canale

L'identificatore di canale e' una funzione del tempo. Il tempo corrente (come definito sotto UNIX per il numero di secondi passato da 00:00:00 GMT, Gennaio 1, 1970) e convertito in un multiplo di cinque (5) caratteri usando la base seguente : "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (ogni carattere ha un valore decimale iniziando da 0 per 'A' fino a 35 per '0'). L'identificatore di canale ha dunque una periodicità di 36^5 secondi (circa 700 giorni).
[ Torna al Sommario ]

5.2.2 Ritardo del canale (Delay)

Questi canali DEVONO essere soggetti al meccanismo di "ritardo del canale" descritto in sezione 5.1 (“Ritardo del Canale”). Tuttavia, il meccanismo può essere ancora migliorato. I servers DEVONO seguire i cambiamenti di tutti questi canali che perdono utenti come risultato della separazione (split) del canale, non importa che l'utente sia un “operatore del canale” o no. Tuttavia, questi canali NON diventano mai indisponibili, è sempre possibile entrarvi anche quando sono vuoti.
[ Torna al Sommario ]

5.2.3 Finestra Abuso

Gli attacchi su un particolare canale possono solo succedere una volta ogni tanto poichè la durata della separazione della rete raramente sono lunghi. Tuttavia, con fortuna e pazienza, e' ancora possibile per un utente provocare un conflitto di canale. Per evitare questo, i server DEVONO “guardare nel futuro” e custodire la lista dei nomi di canali sui quali l'utente stà per essere identificato (per esempio nei prossimi giorni). Questa lista dovrebbe rimanere corta per non essere un carico da sopportare per i servers ed essere utilizzata per evitare i conflitti dei canali impedendo la ri-creazione di un canale uguale, per un un periodo di tempo più lungo di quanto lo sia il ritardo del canale. Eventualmente un server può scegliere di estendere questa procedura per vietare solo la creazione di canali con lo stesso nome corto (poi ignorando l'identificatore di canale).
[ Torna al Sommario ]

5.2.4 Preservare sicurezza al Name Space del canale

La combinazione dei meccanismi descrita nelle sezioni 5.2.2 e 5.2.3 rende abbastanza difficile per un utente il creare una collisione di canale. Tuttavia, un altro tipo di abuso consiste nel creare molti canali che hanno lo stesso nome corto, ma identificativi diversi. Per evitare che questo succeda, i servers DEVONO vietare la creazione di un nuovo canale che ha lo stesso nome corto di un canale che già esiste.
[ Torna al Sommario ]

5.2.5 Meccanismo Reop Server

Quando un canale è rimasto senza Op per più tempo del periodo di "ritardo reop" e ha il modo del canale 'r' attivato (leggere sezione 4.2.7 (Segnale Reop Server)), i servers IRC sono responsabili del dare a caso lo stato di operatore del canale a qualcuno degli utenti. La logica esatta in uso per questo meccanismo dalla messa in opera attuale è descritta qui sotto. I servers POSSONO usare logiche disparate ma si RACCOMANDA che tutti i servers usino la stessa logica su una rete IRC particolare per mantenere sia coerenza che imparzialità. Per la stessa ragione, il "ritardo reop" DOVREBBE essere uniforme su tutti i servers di una determinata rete IRC. Come per il "ritardo del canale", il valore del "ritardo reop" DOVREBBE essere attivato considerando tanti fattori tra i quali la dimensione (riguardante l'utente) della rete IRC, e l'usuale durata della separazione della rete (split).

a) il meccanismo di reop è selezionato dopo un tempo a caso seguendo la scadenza del "ritardo reop". Questo dovrebbe limitare l'eventualità del meccanismo essendo selezionato nello stesso tempo (per lo stesso canale) su due servers separati.
b) Se il canale e' piccolo (cinque (5) utenti o meno), ed il "ritardo del canale" per questo canale è scaduto,allora reop tutti gli utenti del canale a condizione che almeno un utente sia locale al server.
c) Se il canale e' piccolo (cinque (5) utenti o meno), ed il "ritardo del canale" per questo canale e' scaduto, e il "ritardo reop" e' scaduto per piu tempo del suo valore,allora reop tutti i membri del canale.
d) Per altri casi, reop al più un utente nel canale,basandosi su qualche processo installato dentro il server. Se non fa il reop ad un utente, il processo dovrebbe fare in modo che un altro server faccia op qualcun altro. Questo processo DOVREBBE essere lo stesso su tutta la rete. Una buona soluzione potrebbe essere solo il reop a caso. (L'attuale impostazione fa in modo di scegliere un utente locale al server che non è stato inoccupato per troppo tempo, eventualmente differire l'azione, dunque lasciando ad altri servers la fortuna di trovare un utente "non troppo inoccupato". Questa complicazione è dovuta al fatto che i servers conoscono solo il tempo "inoccupato" degli utenti locali).

[ Torna al Sommario ]

6. Problemi Attuali

Ci sono alcuni problemi riconosciuti nella gestione dei canali IRC. Alcuni possono essere direttamente attribuiti alle regole definite in questo documento, mentre altri sono il risultato del "IRC Server Protocol" [IRC-SERVER] sottoriportato. Benché derivato da RFC 1459 [IRC], questo documento introduce parecchie novità nel tentativo di risolvere qualcuno dei problemi conosciuti.
[ Torna al Sommario ]

6.1 Labels

Questo documento definisce una delle tante label utilizzate dal Protocollo IRC. Benché ci siano parecchi spazi per nomi (namespaces) distinti (fondati sul prefisso del nome del canale), i duplicati dentro ognuno di questi non sono autorizzati. Attualmente è possibile, per gli utenti su diversi servers , scegliere una labelche può risultare in conflitto (con l'eccezione dei canali conosciuti da solo un server dove possono essere rimediati).
[ Torna al Sommario ]

6.1.1 Ritardo del Canale

Il meccanismo di ritardo del Canale spiegato nella sezione 5.1 (Tracce dei Canali Usati recentemente) e' usato per canali prefissati con il carattere '#'. E' una semplice prova per impedire che accadano conflitti. L'esperienza ha dimostrato che, in circostanze normali, è molto efficace ; tuttavia, ha ovviamente severe limitazioni che lo portano a non essere una soluzione adeguata al problema discusso qui.
[ Torna al Sommario ]

6.1.2 Canali Sicuri

I "Canali Sicuri" descriti in sezione 3.2 (Canali Sicuri) sono il modo migliore per impedire che accadano conflitti come anche impedire agli utenti di avere il controllo totale sulle label che hanno scelto. L'ovvio inconveniente per queste labels è che non sono facili da usare. Tuttavia, è giustamente facile per un client il migliorare su tutto ciò.
[ Torna al Sommario ]

6.2 La Propagazione dei Mode Provoca Ritardi

A causa dei ritardi della rete indotti dalla stessa, e a causa di ogni Server il quale è TENUTO a verificare la validità dei cambi di modo (per esempio se un utente esiste ed ha i giusti privilegi), non e' insolito per un messaggio MODE di avere effetto solo su una parte della rete, e così creare spesso una discrepanza tra i servers sullo stato attuale di un canale. Malgrado questo possa sembrare di facile risoluzione (con solo il server originale che verifica la validità dei cambi di modo), si è ritenuto opportuno non farlo per diverse ragioni. La preoccupazione è che i servers non possano fidarsi uno dell'altro e che un server che non si comporta come dovrebbe potrebbe essere facilmente rilevato. Questo modo di fare blocca anche gli effetti di "onde" sui canali che sono fuori sincronizzazione quando i cambi di modo provengono da diverse direzioni.
[ Torna al Sommario ]

6.3 Conflitti e Modi del Canale

Il documento [IRC-SERVER] "Internet Relay Chat: Server Protocol" descrive come le informazioni del canale sono scambiate quando due server si collegano l'uno all'altro. I conflitti di canale (siano giustificati o no) sono trattati come risultati impliciti, cioè che il canale risultante ha, come utenti tutti gli utenti del canale su uno o l'altro server prima della connessione. Allo stesso modo, ogni server manda i propri modi del canale all'altro. Dunque, ogni server riceve questi modi del canale. Per un dato canale ci sono 3 tipi di modi : opzioni, maschere, e informazioni (data). I primi due tipi sono facili da trattare in quanto sono attivati o disattivati. Se un certo modo è attivato su un server, DEVE esserlo pure sull'altro come risultato della connessione. Siccome gli argomenti non sono inviati come parte di questo scambio, non sono un problema. Tuttavia, i modi del canale 'l' e 'k' sono scambiati, e se sono attivati su tutti e due i servers prima della connessione, nessun meccanismo può decidere quale dei due valori abbia la precedenza. E' rimandato agli utenti il sistemare la discrepanza risultante.
[ Torna al Sommario ]

6.4 Esaurimento delle Risorse

I mode fondati sulle mask definiti in 4.3 fa sì che i server IRC (e la rete) siano vulnerabili ad un semplice abuso del sistema : un unico operatore di canale potrebbe attivare quante più diverse maschere possibili su un particolare canale. Questo potrebbe facilmente provocare una diminuzione di memoria del server ed anche della larghezza della banda della rete (da quando l'informazione è propagata agli altri server). Per questa ragione e' RACCOMANDATO che vi sia limite ai numeri di queste mask per i canali come sopra accennato in sezione 4.3. D'altronde, meccanismi più complessi POSSONO essere utilizzati per evitare di avere mask ridondanti attivate sullo stesso canale.
[ Torna al Sommario ]

7. Considerazioni di Sicurezza

7.1 Controllo dell'Accesso

Uno dei più importanti modi per controllare l'accesso ad un canale è quello di usare maschere che sono fondate sul nome dell'utente e nome del canale di connessione dello stesso. Questo meccanismo può essere efficace e sicuro solo se i servers di IRC hanno un modo preciso di varificare le connessioni degli utenti, e se gli utenti non possono facilmente raggirare questo metodo di identificazione della connessione. Anche se in teoria è possibile attivare un meccanismo di verifica come sopra citato, la maggior parte delle reti IRC (specialmente reti pubbliche) non hanno niente di tutto ciò installato e danno poca garanzia sull'esattezza del nome dell'utente e nome del canale per la connessione di un client particolare. Un altro modo di controllare l'accesso e' di usare una chiave di canale, ma da quando questa chiave è mandata in testo pubblico, decriptato , diventa un punto vulnerabile per eventuali tradizionali attacchi.
[ Torna al Sommario ]

7.2 Canale Privato

Per il fatto che le collisioni di canale sono trattati come eventi possibili (leggere sezione 6.3),è possibile agli utenti di entrare in un canale oltrepassando i suoi settaggi di controllo all'accesso. Questo metodo e' stato usato da individui per "prendere il controllo" dei canali acquistando "in modo illegittimo" lo stato di operatore di canale sul canale. Lo stesso metodo può essere usato per scoprire la lista esatto degli utenti di un canale, ed anche per eventualmente ricevere parti di messaggi mandati al canale.
[ Torna al Sommario ]

7.3 Anonimato

L'opzione di canale anonimo (leggere sezione 4.2.1) può essere usato per rendere tutti gli utenti su questo tipo di canale "anonimi" presentando tutti i messaggi al canale come originati da uno pseudo utente di cui il nick è "anonimous". Questo è fatto a livello client-server, e nessun anonimato è dato a livello server-server. Dovrebbe essere ovvio ai lettori, che il livello di anonimità offerto è minimo e senza sicurezza, e che i clients DEVONO dare seri ammonimenti agli utenti che entrano in questi canali.
[ Torna al Sommario ]

8. Assistenza Attuale e disponibilità

Liste di mailing per la discussione che riguardano IRC :

Discussione Generale : ircd-users@irc.org
Sviluppo del Protocollo : ircd-dev@irc.org
Attivazione del Software :

ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc

Newsgroup : alt.irc
[ Torna al Sommario ]

9. Ringraziamenti

Certe parti di questo documento sono state tratte dal RFC 1459 [IRC] che prima documentava il Protocollo IRC. Si è anche tratto beneficio da molte riviste e discussioni. In particolare, le persone qui sotto riportate hanno apportato un significativo contributo a questo documento : Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
[ Torna al Sommario ]

10. Referenze

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[ Torna al Sommario ]

11. Indirizzo dell'Autore

Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA EMail: kalt@stealth.net
[ Torna al Sommario ]

12. Enunciato del Copyright Completo

Copyright (C) The Internet Society (2000). Tutti i diritti riservati. Questo documento e le sue traduzioni possono essere copiate e/o cedute ad altri . I commenti , e quanto sopra riportato , possono essere aggiornati , pubblicati, integralmente o parzialmente , senza alcuna riserva a patto che questo avviso di copyright e questo paragrafo siano inclusi in tutti i lavori e/o copie derivanti. Vanno mantenuti i riferimenti all'internet society e a tutti gli organismi internet citati. Per mantenere gli standard internet ed eventualmente svilupparli e migliorarli devono essere tradotti in altre lingue oltre che dall'inglese, i premessi limiti sopracitati sono perpetui e non saranno ritrattati dall'internet society ne da i suoi successori o delegati.

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.
[ Torna al Sommario ]

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: 15 Marzo 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