domenica 23 luglio - 02:43
Google
 
Menù
  Home
  Come nasce IRC-Zone
  Glossario Informatico
  News
  I nostri progetti
  I nostri servizi
  Partners
  Diventa un Partner

IRC
  Cos'è IRC
  Storia di IRC
  Netiquette su IRC
  Emoticons
  Gergo della chat
  Lista Servers
  RFC 1459
  Shell Hosting

mIRC
  Cos'è il mIRC
  FAQ mIRC
  Configurazione mIRC
  Download mIRC
  Novità
  Script Stranieri
  Script Italiani
  MTS
  MTS Engine

mIRC Addon
  mIRC addon Audio
  mIRC addon SMS
  mIRC addon Grafica
  mIRC addon Utility
  mIRC addon Uso Bot

Client IRC
  Client IRC Linux
  Client IRC Mac
  Client IRC Win

XChat
  Cos'è XChat
  XChat per Win
  XChat per Unix

KVirc
  Cos'è KVirc
  FAQ KVirc
  Installazione su Linux
  KVirc Scripting
  KVirc per Mac
  KVirc per Win
  KVirc per Unix
  KVirc addon

Irssi
  Cos'è Irssi
  Download Irssi
  Download Moduli

Eggdrop/Windrop
  Cos'è un Eggdrop
  Download Eggdrop
  Configurazione Eggdrop
  Download Windrop
  Installazione Windrop

Tcl
  Download TCL
  Tutorial TCL scripting
  Documenti/Guide

BNC
  Cos'è un psyBNC
  Download psyBNC
  Configurazione psyBNC
  Download sBNC
  Configurazione sBNC

Linkaci!
footer

Credits
Somerights

footer

Statistiche
Ip: 54.161.21.157
Download: 989496 file
Totale: 1503983 MB

footer

Links amici

RFC 2811
Network Working Group C. Kalt
Richiesta di commento: 2811 Aprile 2000
Aggiornamenti: 1459
Categoria: Informativa

Internet Relay Chat: Gestione Canale

Status di questo Memorandum

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

Copyright

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

Astrazione

Una delle caratteristiche più importanti del protocollo IRC (Internet Relay
Chat) è quello di permettere il raggruppamento di utenti in forums, chiamati canali,
fornendo un mezzo che permetta a più utenti di comunicare tutti insieme.

In origine c'era solo una tipologia di canali, ma, col passare degli anni,
son stati introdotte delle nuove tipologie come risposta a particolari
necessità o per scopi sperimentali.

Questo documento specifica come i canali, le loro caratteristiche
e proprietà, siano gestite dai server IRC.

Tabella dei contenuti

1. Introduzione ............................................... 2
2. Caratteristiche Canali ..................................... 3
2.1 Area Nome .............................................. 3
2.2 Estensioni Canale ...................................... 3
2.3 Proprietà Canale ....................................... 4
2.4 Membri Del Canale Privilegiati ......................... 4
2.4.1 Operatori Del Canale .............................. 5
2.4.2 Creatore Del Canale ............................... 5
3. Tempo Di Esistenza Del Canale .............................. 5
3.1 Canali Standard ........................................ 5
3.2 Canali Sicuri .......................................... 6
4. Modalità Canale ............................................ 7
4.1 Status Membro .......................................... 7
4.1.1 Status "Creatore Di Canale" ....................... 7

Kalt Informativa [Pagina 1]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000


4.1.2 Status Operatore Di Canale ........................ 8
4.1.3 Privilegio Voice .................................. 8
4.2 Flags Di Canale ........................................ 8
4.2.1 Flag Anonimo ...................................... 8
4.2.2 Flag Di Solo Invito ............................... 8
4.2.3 Flag Canale Moderato .............................. 9
4.2.4 Nessun Messaggio In Canale Da Clients Esterni ..... 9
4.2.5 Canale Quiet ...................................... 9
4.2.6 Canale Privato & Segreto .......................... 9
4.2.7 Flag ReOp Server .................................. 10
4.2.8 Topic ............................................. 10
4.2.9 Limite Utente ..................................... 10
4.2.10 Chiave Canale .................................... 10
4.3 Controllo Accesso Canale ............................... 10
4.3.1 Ban Di Canale Ed Eccezione ........................ 11
4.3.2 Invito Permanente ................................. 11
5. Implementazioni Correnti ................................... 11
5.1 Traccia Dei Canali Usati Recentemente .................. 11
5.2 Canali Sicuri .......................................... 12
5.2.1 Identificatore Canale ............................. 12
5.2.2 Ritardo Canale .................................... 12
5.2.3 Finestra Abuso .................................... 13
5.2.4 Sicurezza Nell'Area Nome .......................... 13
5.2.5 Meccanismo Di ReOp Del Canale ..................... 13
6. Problemi Correnti .......................................... 14
6.1 Etichette .............................................. 14
6.1.1 Ritardo Canale .................................... 14
6.1.2 Canali Sicuri ..................................... 15
6.2 Ritardi Nella Propagazione Delle Modalità .............. 15
6.3 Collisioni E Modalità Di Canale ........................ 15
6.4 Esaurimento Delle Risorse .............................. 16
7. Considerazioni Sulla Sicurezza ............................. 16
7.1 Controllo Accesso ...................................... 16
7.2 Privacy Canale ......................................... 16
7.3 Anonimità ............................................... 17
8. Supporto E Disponibilità Correnti .......................... 17
9. Riconoscimenti ............................................. 17
10. Riferimenti ............................................... 18
11. Indirizzo Autore .......................................... 18
12. Copyright .................................................. 19

1. Introduzione

Questo documento definisce, in dettaglio, come i canali vengono gestiti
dai server IRC, informazione molto utile per le persone che vogliono creare un
server IRC.

Kalt Informativa [Pagina 2]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

Nonostante i concetti definiti qua siano una parte importante di IRC,
tali, però, non sono essenziali per la creazione dei clients.
L'avanzata nella creazione di clients è finalizzata allo sviluppo
di programmi sempre più intelligenti e complessi in modo da
ottenere dei vantaggi sfruttando la struttura interna dei canali
e fornendo un interfaccia sempre più semplificata all'utente.
La creazione di clients semplici, comunque, può essere benissimo
condotta senza leggere questo documento.

Molti concetti definiti qua sono stati specificati anche dall'architettura di IRC [IRC-ARCH]
dando senso a quanto discusso in questo contesto. Tuttavia, potrebbero essere
applicate anche ad altre architetture, al fine di ottenere dei forums
per dei sistemi di conferenza.

In ultima, c'è da notare che gli utenti di IRC potrebbero
trovare varie sezioni, di questo documento, interessanti ed in particolare
la sezione 2 (Caratteristiche Canali) e 4 (Modalità Di Canale).

2. Caratteristiche Canali

Un canale è un gruppo con nome di uno o più utenti, i quali ricevono
i messaggi indirizzati a tale canale. Un canale è caraterizzato
da un nome, dalle proprietà e dai membri presenti in esso.

2.1 Area Nome

I nomi di canali sono stringhe (iniziano con un carattere '&', '#', '+' o '!')
della lunghezza di cinquanta (50) caratteri. I nomi di canale sono
case insensitive (non c'è differenza tra maiuscole e minuscole).

E' richiesto che il primo carattere sia
'&', '#', '+' o '!' (chiamato "prefisso di canale"). L'unica restrizione
nel nome del canale è che non deve contenere spazi (' '), il control G (^G o ASCII 7), la virgola (','
che viene utilizzata come oggetto di separazione delle liste, nel protocollo).
Inoltre, il simbolo (':') è utilizzato come delimitatore della maschera di canale.
La sintassi esatta del nome del canale è definita nel "IRC Server Protocol" [IRC-SERVER].

L'uso dei prefissi differenti crea effettivamente quattro (4) aree nome
distinte per i nomi di canale. Ciò è importante a causa dei limiti riguardanti
le aree nome dichiarati dal protocollo (in genere). Controlla la sezione 6.1 (Etichette)
per ulteriori dettagli riguardo queste limitazioni.

2.2 Estensioni Canale

Un entità canale è conosciuta da una o più server nella rete IRC.
Un utente può solo diventare membro di un canale
conosciuto dal server al quale l'utente è direttamente connesso.
La lista di server i quali sono informati dell'esistenza di un particolare canale
devono essere parte della rete IRC, in modo che im essaggi vengano indirizzato al canale
e tale venga spedito a tutti i membri di canale.

Un canale che inizia col prefisso '&' è locale al server ov'è stato creato.

Altri canali sono conosciuti ad uno (1) o più servers connessi alla rete
a seconda della maschera di canale:

Se non ci sono mask di canale, questo è conosciuto da tutti i servers.

Se c'è una mask di canale, questo deve essere
conosciuto dai server che hanno degli utenti locali presenti in esso, e anche il proprio
"vicinato" se la maschera coincide sia con il nome del server locale che quello del "vicinato".
Siccome gli altri servers non hanno informazioni riguardo l'esistenza
di tale canale, l'area formata dal server avente il nome coincidente con la maschera
dev'essere contiguo per il canale, per essere conosciuto da tutti questi servers.
La maschera di canale è meglio usata in congiunzione con l'hostmasking del server [IRC-SERVER].

2.3 Proprietà Canale

Ogni canale ha le sue proprietà, le quali sono definite dalle modalità canale.
Tali modalità possono essere manipolate dai membri del canale.
Le modalità modificano il modo di gestire dei canali da parte dei servers.

I canal con il prefisso '+' non supportano modalità. Ciò significa che tutte le modalità
sono disattive, con l'eccezione della flag 't' (la quale è settata).

2.4 Membri Del Canale Privilegiati

Per permettere ai membri di canale di mantenere il controllo ed un certo ordine,
sono presenti dei privilegi. Solo gli utenti privilegiati possono effettuare le seguenti
azioni nel canale:

INVITE - Inviatare un utente in un canale a solo invito (modalità +i)
KICK - Espellere un client dal canale
MODE - Cambiare le modalità di canale, così come i privilegi dei membri
PRIVMSG - Spedire messaggi al canale (modalità +n, +m, +v)
TOPIC - Cambiare l'argomento di canale in caso di modalità +t

Kalt Informativa [Pagina 4]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

2.4.1 Operatori Del Canale

Gli operatori di canale (definiti anche come "ChOp" o "ChanOp") su un dato canale
sono considerati i possessori di tale canale. La possessione del canale è
condivisa tra gli operatori di canale.

Gli operatori di canale sono identificati col simbolo '@' affianco al loro nickname
associato al canale ove hanno il privilegio (es., in risposta al comando NAMES, WHO e WHOIS).

Se i canali iniziano col carattere '+' come prefisso, non supportano
le modalità di canale e nessun membro può avere lo status di operatore di
canale.

2.4.2 Creatore Del Canale

Un utente che crea un canale col carattere '!' come prefisso è definito
come "creatore del canale". Dalla creazione del canale, questo utente
ha anche lo status di operatore.

In riconoscimento del suo status, il creatore di canale ha
il permesso di attivare/disattivare certe modalità di canale che un operatore non
può manipolare.

Un "creatore di canale" può essere distinto da un operatore di canale
effettuando propriamente il comando MODE. Controlla il "IRC Client Protocol"
[IRC-CLIENT] per ulteriori informazioni riguardo questo argomento.

3. Tempo Di Esistenza Del Canale

Riguardo il tempo di esistenza di un canale, ci sono tipicamente 2 gruppi di canali:
i canali standard i quali hanno come prefisso '&', '#'
o '+', e i "canali sicuri" i quali hanno come prefisso '!'.

3.1 Canali Standard

Questi canali sono creato implicitamente quando un utente
vi entra per la prima volta e cessano di esistere quando l'ultimo utente li lascia.
Mentre il canale esiste, ogni utente può riferirsi al canale usando il nome del
canale stesso.

L'utente che ha creato il canale automanticamente diventa
operatore di canale con l'eccezione dei canali che hanno come prefisso
il carattere '+', controlla la sezione 4 (Modalità Canale). Controlla la sezione 2.4.1
(Operatori Del Canale) per ulteriori dettagli riguardo questo argomento.

Kalt Informativa [Pagina 5]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

Al fine di evitare la creazione di canali multipli (tipicamente quando una
rete IRC si divide a causa di uno split tra 2 o più servers), i nomi di canali non devono
essere permessi nel loro utilizzo dall'utente se l'operatore di canale (controlla la sezione 2.4.1 (Operatori
Del Canale)) ha abbandonato recentemente quest'ultimo a causa di uno split di rete. Se questo succede, il nome del
canale sarà temporaneamente non disponibile. La durata di indisponibilità del canale dev'essere decisa a seconda
delle basi della rete IRC. E' importante notare che ciò evita che gli utenti locali creino un canale usando lo stesso
nome, ma non impedisce che tale azioni venga compiuta dagli utenti remoti. Tale fatto accade tipicamente
quando una rete IRC effettua il rejoin. Ovviamente, questo meccanismo ha senso solo nei canali i cui nomi
iniziano con il carattere '#', ma può essere usato per i canali il cui nome
inizia col carattere '+'. Tale meccanismo è comunemente conosciuto come "Ritardo Di Canale".

3.2 Canali Sicuri

A differenza degli altri canali, i "Canali Sicuri" non sono creati implicitamente.
Un utente che desideri create tale tipo di canale deve richiederne la creazione spedendo
un comando JOIN speciale al server ove l'identificatore del canale è rimpiazzato col carattere'!'.
Il processo di creazione per questo dipo di canale è strettamente controllato.
L'utente sceglie solo la parte del nome del canale (conosciuto anche come "nome corto"),
il server, automaticamente, allega al nome fornito dall'utente un identificatore composto
da cinque (5) caratteri.
Il nome canale risultante dalla combinazione di questi 2 elementi è unico, redendo il canale sicuro
dagli abusi basati dagli splits della rete.

L'utente che crea il canale automaticamente diventa "creatore del canale".
Controlla la sezione 2.4.2 (Creatore Del Canale) per ulteriori dettagli
riguardo questo argomento.

Un server non deve permettere la creazione di un nuovo canale
se esiste un altro canale con lo stesso "nome corto"; o se un altro canal con lo stesso
nome corto esiste recentemente e uno dei suoi membri ha lasciato il canale a causa di uno split
di rete. Tale canale cessa di esistere dopo che l'ultimo utente abbandona e nessun altro utente
ha lasciato di recente il canale a causa di uno split di rete.

Differentemente dal meccanismo descritto nella sezione 5.2.2 (Ritardo Di Canale), in questo caso,
i nomi di canale rimangono disponibili: questi canali continuano ad esistere dopo che l'ultimo utente
è uscito. Solo l'utente che crea il canale diventa "creatore del canale". Gli utenti che entrano nel canale
vuoto esistente non diventano nè "creatori" nè "operatori".

Kalt Informativa [Pagina 6]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

Per assicurare l'univocità dei nomi di canale, l'identificatore
ceeato dal server deve seguire delle regole specifiche. Per ulteriori dettagli
vedere la sezione 5.2.1 (Identificatore Canale).

4. Modalità Canale

Le modalità disponibili sono:

O - fornisce lo status di "creatore del canale";
o - fornisce/rimuove il privilegio di operatore del canale;
v - fornisce/rimuove il privilegio voice;

a - setta la flag "anonimo" del canale;
i - setta la flag di "solo invito" del canale;
m - setta il canale "moderato";
n - setta il divieto di spedizione di messaggi in canale dall'esterno;
q - setta la flag quiet di canale;
p - setta la flag "privato" di canale;
s - setta la flag "segreto" di canale;
r - setta la flag di server reop di canale;
t - setta la flag di topic settabile solo dagli operatori di canale;

k - setta/rimuove la chiave di canale (password);
l - setta/rimuove il limite utente del canale;

b - setta/rimuove la ban mask per tenere gli utenti fuori dal canale;
e - setta/rimuove un eccezione alla mask di ban per l'override;
I - setta/rimuove una mask d'invito per l'override automatico della flag di solo invito;

A meno che non venga specificato diversamente altrove, tutte queste modalità sono manipolabili dagli operatori
di canale, utilizzando il comando MODE definito nel "IRC
Client Protocol" [IRC-CLIENT].

4.1 Status Membro

Le modalità in questa categoria usano il nickname dell'utente come parametro
e modificano i privilegi dell'utente specificato.

4.1.1 Status "Creatore Di Canale"

La modalità 'O' è usata solamente in congiunzione con i "canali sicuri" e non può essere manipolata
dagli utenti. I servers danno lo status di creatore di canale agli utenti che ne creano uno.

Kalt Informativa [Pagina 7]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

4.1.2 Status "Operatore Di Canale"

La modalità 'o' è usata per settare lo status di operatore ad un membro del canale.

4.1.3 Privilegio Voice

La modalità 'v' è usata per dare o rimuovere il privilegio voice ad/da un utente
del canale. Gli utenti, con questo privilegio, possono parlare nei canali moderati.
(Controlla la sezione 4.2.3 (Flag Canale Moderato).

4.2 Flags Canale

Le modalità di questa categoria definiscono le proprietà presenti nel canale ove operano.

4.2.1 Flag Anonimo

La flag di canale 'a' definisce un canale anonimo. Ciò significa che quando il messaggio
è sepdito nel canale e il server lo invia agli utenti presenti in questo, l'origine
dev'essere mascherata. Per mascherare il messaggio, l'origine de'vessere cambiata
in "anonymous!anonymous@anonymous."
(es., un utente con il nickname "anonymous", l'username "anonymous"
e da un host "anonymous."). A causa di questo, il server deve vietare agli utenti
di poter utilizzare il nickname "anonymous". Il server deve, inoltre, non spedire
messaggi di QUIT degli utenti che abbandonano i canali in tale modalità,
ma generare dei messaggi PART.

Nei canali che hanno come prefisso '&', questa flag dev'essere
settata dagli operatori di canale, ma nei canali '!',
questa flag dev'essere settata (ma può non essere disattivata) solo dal "creatore del canale".
Questa flag non deve essere disponibile in altri tipi di canale.

Le risposte ai comandi WHOIS, WHO e NAMES non devono rivelare la presenza
di altri utenti nel canale (se tale opzione è attiva).

4.2.2 Flag Di Solo Invito

Quando la flag di canale 'i' viene settata, i nuovi membri, che vogliono entrare,
vengono accettati solo se le loro mask coincidono con la Invite-list (lista invitati, vedere sezione 4.3.2)
o sono stati invitati da un operatore di canale. Tale flag può anche restringere l'uso
del comando INVITE (vedere "IRC Client Protocol" [IRC-CLIENT]) agli operatori di canale.

Kalt Informativa [Pagina 8]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

4.2.3 Flag Canale Moderato

La flag di canale 'm' è utilizzata per controllare chi parla in canale.
Quando è settata, solo gli operatori di canale, e i membri che hanno ricevuto il privilegio
voice, possono spedire messaggi nel canale.

Questa flag agisce solo presso gli utenti.

4.2.4 Nessun Messaggio In Canale Da Clients Esterni

Quando la flag di canale 'n' viene settata, solo i membri di canale possono spedire messaggi
in questo.

Questa flag agisce solo presso gli utenti.

4.2.5 Canale Quiet

La flag di canale 'q' è utilizzata solo dal server. Quando settata,
essa restringe il tipo di dati spediti agli utenti riguardo le operazioni
di canale: i messaggi di join degli utenti, parts e cambi di nicknames
non vengono visualizzati.
Dal punto di vista dell'utente, il canale contiene solo un utente.

Ciò è tipicamente usato per creare dei canali locali speciali, nei quali il server
invia i notices relativi alle sue operazioni. Ciò è utilizzato come rimpiazzo
più efficiente e flessibile della modalità utente 's' definita nell'RFC 1459 [IRC].

4.2.6 Canale Privato & Segreto

Quando la flag di canale 'p' è utilizzata, il canale è marchiato "privato" e la
flag di canale 's' marca il canale "segreto". Entrambi le proprietà sono
similari e nascondono la presenza del canale agli altri utenti.

Ciò significa che non vi sono modi per ottenere il nome del canale
dal server senza essere membro del canale. In altre parole, questi canali devono essere
omessi dalle risposte alle query (ad esempio dal comando WHOIS).

Quando il canale è "segreto", in aggiunta alla restrizione appena descritta, il server
dovrà agire come se il canale non esista, durante le queries (es. comandi
TOPIC, LIST, NAMES). Nota che c'è un'eccezione a questa regola:
i server risponderanno correttamente al comando MODE.
In ultima, i canali segreti non vengono contati nella risposta
al comando LUSERS (vedere "Internet Relay Chat: Client Protocol" [IRC-
CLIENT]) quando il parametro viene specificato.

Kalt Informativa [Pagina 9]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

Le flag di canale 'p' e 's' non devono essere settate contemporaneamente.
Se il messaggio MODE, originario dal server, setta il mode 'p' e la flag 's' è già presente in canale,
il cambio verrà ignorato silenziosamente. Ciò deve accadere solo durante la fase di risincronizzazione
successiva ad uno split (descritta dal documento "IRC Server Protocol" [IRC-SERVER]).

4.2.7 Flag ReOp Server

La flag di canale 'r' è disponibile solo nei canali che iniziano col carattere '!'
e possono solo essere manipolate dal creatore del canale.

Tale flag è utilizzata per evitare che il canale rimanga senza operatori di canale per un lungo
periodo di tempo. Quando questa flag è settata, il canale, se non contiene operatori per un
periodo maggiore di quello settato nel parametro "Ritardo ReOp", sarà sottoposto ad un
sistema di server reop di alcuni o tutti gli utenti del canale. Tale dispositivo è descritto
in dettaglio nella sezione 5.2.5 (Meccanismo Di ReOp Del Canale).

4.2.8 Topic

La flag di canale 't' è impiegata per restringere l'utilizzo del comando TOPIC ai soli operatori
di canale.

4.2.9 Limite Utente

Un limite utente può essere settato nei canali quando viene impostata la flag 'l'.
Quando il limite viene raggiunto, il server deve vietare il join ai nuovi membri.

Il valore del limite dev'essere solo disponibile ai membri di canale, nella risposta del server
inviata alla query del comando MODE.

4.2.10 Chiave Canale

Quando una chiave di canale viene settata (usando la modalità 'k'), i servers devono
rifiutare tutti i join degli utenti se la key non risulta come parametro fornito
col comando.

La chiave di canale dev'essere visualizzabile solo agli utenti del canale, come
risposta del server alla query del comando MODE.

4.3 Controllo Accesso Canale

L'ultima categoria di modalità è utilizzata per controllare l'accesso al canale, utilizzando
una mask come parametro.

Kalt Informativa [Pagina 10]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

Per ridurre la dimensione del database globale per le modalità di controllo degli accessi
settate per i canali, il server deve imporre un limite massimo nel numero di tali modalità
impostabili in un canale particolare. Se tale restrizione è impostata, deve coinvolgere solo
le richieste utente. Il limite deve essere omogeneo con la base della rete IRC.

4.3.1 Ban Di Canale Ed Eccezione

Quando un utente richiede di entrare in un canale, il suo server locale controlla se
l'indirizzo dell'utente coincide con qualsiasi di queste ban mask settate nel canale.
Se l'indirizzo coincide, la richiesta dell'utente (il comando JOIN) dev'essere vietato
fino a quando una mask di eccezione non viene settata nel canale (o la mask di ban non viene rimossa).

I Servers non devono permettere al membro di canale, se bannato, di poter parlare in questo,
se non è operatore di canale o ha il privilegio voice. (vedere sezione 4.1.3 (Privilegio Voice)).

Un utente bannato dal canale, il quale ha ricevuto l'invito da un operatore di canale, ha il permesso
di entrare nel canale.

4.3.2 Invito Permanente

I canali che hanno la flag di solo invito settata (vedere sezione 4.2.2
(Flag Di Solo Invito)), ammettono gli utenti solo se il proprio indirizzo coincide
con la mask d'invito (anche senza ricorrere al comando INVITE).

5. Implementazioni Correnti

La sola corrente implementazione di queste regole, come parte
del protocollo è il server IRC, 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
anche per i programmatori di client.

5.1 Traccia Dei Canali Usati Recentemente

Questo meccanismo è comunemente conosciuto come "Ritardo Di Canale" e generalmente
è applicato solamente ai canali i cui nomi presentano come prefisso il carattere
'#' (vedere la sezione 3.1 "Canali standard").

Quando accade uno split di rete, i servers dovrebbero tenere traccia di quali canali han perso
gli "operatori di canale" come risultato della rottura. Questi canali
sono in uno stato speciale che dura per un certo periodo di tempo.
In questo periodo, il canale non può cessare d'esistere.
Se tutti i membri di canale lasciano quest'ultimo, il canale diventa non disponibile:
il server locale non può far entrare gli utenti in questo fino a quando
rimane vuoto.

Quando il canale non è disponibile, ritornerà al suo stato originale
quando un utente remoto rientrerà in questo (e, specialmente, perchè
la rete si sta riunendo) o perchè il tempo di ritardo è scaduto (in tale
caso, il canale cessa di esistere e può essere ricreato).

La durata di ritardo della morte del canale dev'essere settata
tenendo in considerazione di vari fattori, es. le dimensioni della rete IRC
e della durata degli splits. Tale parametro dev'essere uniforme a tutti i servers
della rete.

5.2 Canali Sicuri

Questo documento introduce la nozione dei "canali sicuri". Questi canali
hanno un nome che presenta, come prefisso, il carattere '!' ed è stato
effettuato un grande sforzo per rendere questi sicuri evitando le collisioni
del proprio nome. Ovviamente, le collisioni non sono impossibili, tuttavia
sono molto rare.

5.2.1 Identificatore Canale

L'identificatore di canale è in funzione del tempo. Il tempo corrente
(definito in UNIX dal numero di secondi passato
dalla data 00:00:00 GMT, 1 Gennaio, 1970) è convertita in una stringa di cinque
(5) caratteri usando la seguente base: "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"
(ogni carattere ha un valore decimale iniziando da 0 per 'A' e da 35 per '0').

L'identificatore di canale ha una periodicità di 36^5 secondi (circa 700 giorni).

5.2.2 Ritardo Canale

Questi canali devono essere soggetti al meccanismo di "ritardo di canale"
descritto in sezione 5.1 (Ritardo Di Canale). Tuttavia, il meccanismo può
essere migliorato ulteriormente.

I servers devono tenere traccia di tutti quei canali che perdono
i membri come risultato di uno split di rete, non importa se l'utente è un
"operatore di canale" o no.

Tuttavia, questi canali non devono diventare non-disponibili, è sempre possibile
joinarli anche se sono vuoti.

Kalt Informativa [Pagina 12]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

5.2.3 Finestra Abuso

Gli attacchi ad un particolare canale possono accadono di rado poichè, la durata
degli split della rete, raramente sono lunghi. Tuttavia, con fortuna e pazienza,
è possibile, per un utente, causare una collisione di canale.
Per evitare tutto ciò, il server deve "osservare il futuro"
e tenere la lista di nomi di canale, con gli identificativi che verranno usati,
(in un periodo di tempo di alcuni giorni, ad esempio).
Tale lista deve rimanere di modeste dimensioni, in modo da non essere un problema
di carico per i servers nel mantenerla ed usarla per evitare le collisioni di canale,
bloccando la ri-creazione di tali canali per un periodo più lungo di quello
dichiarato dal ritardo di canale.

Eventualmente un server può scegliere di estendere questa procedura per proibire
la creazione di canali solo con lo stesso nome corto (ed ignorando l'identificatore di canale).

5.2.4 Sicurezza Nell'Area Nome

La combinazione del meccanismo descritto nella sezione 5.2.2 e
5.2.3 rende abbastanza difficile la possibilità che un utente possa
causare una collisione di canale. Tuttavia, un altro tipo di abuso
consiste nel creare vari canali aventi lo stesso nome corto, ma con
identificatori differenti. Per evitare che ciò accada, il server deve vietare la creazione
di un nuovo canale che abbia lo stesso nome corto del canale corrente esistente.

5.2.5 Meccanismo di ReOp Del Server

Quando un canale è rimasto in modalità "opless" per un periodo più lungo di quello
stabilito dall'opzione "ritardo reop" e ha la flag di canale 'r' settata (vedere sezione
4.2.7 (Server Reop Flag)), il server IRC provvede fornendo lo status di operatore,
ad alcuni dei membri di canale, in modo casuale.

La logica esatta utilizzata per questo meccanismo dalla corrente implementazione
è descritta qua di seguito. I servers possono utilizzare una logica differente,
ma è fortemente raccomandato che tutti i servers utilizzino lo stesso metodo nella
rete IRC, in modo da mantenere la coerenza così come l'imparzialità.
Per le stesse ragioni, il "ritardo reop" dev'essere uniforme a tutti i servers
della rete IRC. Come per il "ritardo di canale", il valore del "ritardo reop"
dev'essere considerato da molti fattori, a seconda delle dimensioni della rete IRC,
e della durata media degli split di rete.

a) Il meccanismo di reop viene attivato dopo un tempo casuale
seguendo la scadenza del "ritardo reop". Ciò dovrebbe limitare l'eventualità
che il meccanismo venga attivato (nello stesso canale) allo stesso momento su due
servers differenti.

Kalt Informativa [Pagina 13]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

b) Se un canale è piccolo (cinque (5) utenti o di meno), e il "ritardo di canale"
del canale è scaduto, si dovrà rioppare tutti gli utenti se anche
almeno uno di questi è locale al server.

c) Se un canale è piccolo (cinque (5) utenti o di meno), e il "ritardo di canale"
del canale è scaduto, e il "ritardo reop" è scaduto, verranno rioppati
tutti gli utenti del canale.

d) In altri casi, si dovrà rioppare, come minimo, un utente nel canale, a seconda
di alcuni metodi decisi dal server. Se non viene rioppato un membro,
un altro server dovrà farlo. Il metodo dovrà essere lo stesso
su tutta la rete IRC. Una buona soluzione potrebbe essere il reop casuale.
(L'implementazione corrente, attualmente, tenta di scegliere
un membro locale al server che non abbia un inattività troppo lunga,
oppure, in caso, lasciare il compito agli altri servers.
Ciò, però, è un procedimento complesso, in quanto, i servers
conoscono solo il tempo d'inattività dei loro utenti locali)

6. Problemi Correnti

C'è un certo numero di problemi riconosciuti nella gestione dei canali IRC.
Alcuni di questi sono direttamente attribuibili alle regole definite in questo documento,
mentre altri sono il risultato del "IRC Server Protocol" [IRC-SERVER]. Sebbene derivati dall'RFC 1459 [IRC],
questo documento introduce varie novità, al fine di risolvere alcuni dei problemi conosciuti.

6.1 Etichette

Questo documento definisce uno delle tante etichette utilizzate nel protocollo IRC.
Sebbene ci siano molti "spazi nome" distinti (basati nel prefisso del nome del canale),
i duplicati non sono permessi. Correntemente, è possibile, per gli utenti di server differenti,
impiegare un etichetta che possa causare una collisione (con l'eccezione dei canali
conosciuti solo ai server ove questi vengono attivati).

6.1.1 Ritardo Canale

Il sistema di ritardo del canale, descritto nella sezione 5.1 (Traccia Dei Canali Usati Recentemente) e usato
per i perfissi di canale con il carattere '#' e un semplice tentativo di prevenzione
delle collisioni. L'esperienza ha dimostrato che, in normali circostante, ciò è molto efficiente;

Kalt Informativa [Pagina 14]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

tuttavia, è chiara la presenza di serie limitazioni che impediscono di considerare
tale sistema una soluzione adeguata riguardo il problema qui discusso.

6.1.2 Canali Sicuri

I canali sicuri, descritti nella sezione 3.2 (Canali Sicuri) sono una via migliore
per prevenire le collisioni, in quanto evitano che l'utente abbia il totale controllo
dell'etichetta da loro scelta. L'unico problema di tale sistema è che le etichette
non sono user friendly. Tuttavia, è facile per un client il migliorare su tutto ciò.

6.2 Ritardi Nella Propagazione Delle Modalità

A causa dei ritardi della rete indotti dalla stessa, e a causa di ogni Server,
il deve verificare la validità dei cambi di modalità (es. l'utente esiste e ha i giusti privilegi),
non è inusuale che il comando MODE coinvolga solo parte della rete, spesso causando
degli errori tra i servers, rispetto lo stato corrente del canale.

Nonostante tale problema sembri semplice da riparare (facendo in modo che il server originario
controlli la validità dei cambi di modalità), è stato deciso di non attuare tutto ciò, per varie ragioni.
Uno dei motivi è causato dalla mancanza di affidabilità tra i servers e un server (che non si comporta come
dovrebbe) può essere identificato facilmente. Questo modo di fare ferma anche gli effetti onda nei canali
non sincronizzati, quando i cambi di modalità provengono da direzioni differenti.

6.3 Collisioni E Modalità Di Canale

Il documento "Internet Relay Chat: Server Protocol" [IRC-SERVER]
descrive come i dati di canale vengono scambiati quando due server si connettono tra
di loro. Le collisioni di canale (legittime o no) sono trattate come eventi impliciti.
Ciò significa che il canale risultante ha per membri tutti gli utenti membri del canale
sia del primo che del secondo server (in fase di connessione).

Similmente, ogni server spedisce le modalità di canale all'altro.
Ogni server riceve queste modalità. Ci sono 3 tipi di modalità per il canale dato: flags, masks, e dati.
Il primo dei due tipi, sono semplici da trattare sia che risultino settati o no.
Se una modalità è settata in un server, dev'essere settata anche in tutti i rimanenti (durante
la connessione).

Kalt Informativa [Pagina 15]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

I topics non vengono spediti come parte di questo scambio,
essi non sono un problema. Tuttavia, le modalità di canale 'l' e 'k' vengono scambiate, e
se sono settate in entrambi i server, prima della connessione, non c'è modo per decidere quale
dei due valori ha la precedenza. In questo caso, l'aggiornamento è lasciato all'utente.

6.4 Esaurimento Delle Risorse

Le modalità basate nelle masks definite nella sezione 4.3 rendono il server IRC (e la rete)
vulnerabili ad un semplice abuso di sistema: un operatore dicanale singolo può settare
tutte le mask possibili, in un canale. Ciò può facilmente causare lo spreco di memoria
da parte del server IRC, così come banda di rete (in quanto le informazioni vengono propagate
anche alle altre reti IRC). Per questa ragione, si raccomanda di limitare il numero di masks per canale,
menzionate nella sezione 4.3.

Inoltre, possono essere utilizzati dei meccanismi più complessi per evitare d'avere delle masks ridondati, per
lo stesso canale.

7. Considerazioni Sulla Sicurezza

7.1 Controllo Accesso

Una delle vie principali per controllare l'accesso ad un canale è quello di utilizzare le masks basare nei nicknames
e negli hostnames delle connessioni degli utenti.
Tale meccanismo può essere efficiente e sicuro solo se il server IRC ha un sistema accurato per
autenticare le connessioni degli utenti, e se gli utenti non possono aggirare le medesime facilmente.
Nonostante sia, in teoria, possibile implementare un meccanismo di autenticazione stretta, molte reti IRC
(specialmente le reti pubbliche) non ne usano e forniscono poca garanzia riguardo l'accuratezza dell'username e dell'hostname
di una connessione client particolare.

Un'altra via per controllare l'accesso è nell'utilizzare le chiavi di canale, ma, a causa della base di funzionamento
di tale sistema (la password è un testo in chiaro), tale protezione è vulnerabile agli attacchi "Man In The Middle".

7.2 Privacy Canale

A causa della trattazione, come evento inclusivo, delle collisioni in canale (vedere
la sezione 6.3), è possibile, per gli utenti, entrare in un canale
scavalcando i settaggi di controllo d'accesso. Questo metodo è stato a lungo utilizzato
per effettuare i "take overs", ottenendo "illegittimamente" lo status di operatore nel canale.
Lo stesso metodo può essere usato per scoprire la lista esatta dei membri del canale, così come
eventualmente ricevere alcuni messaggi inviati in esso.

Kalt Informativa [Pagina 16]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

7.3 Anonimità

La flag di canale anonima (vedere sezione 4.2.1) può essere utilizzata
per rendere anonimi tutti gli utenti di un canale, preservando i messaggi e
generandoli da un pseudo-utente con il nickname "anonymous".
Ciò è effettuato a livello client-server, e non è fornita alcuna
anonimità a livello server-server.

Penso sia ovvio, ai lettori, che il livello di anonimità
offerto è poca e non molto sicura, e tali clients devono visualizzare delle avvertenze
ben chiare a tutti gli utenti che entrano in tali canali.

8. Supporto E Disponibilità Correnti

Mailing lists per le discussioni relative ad IRC:
Discussione Generica: ircd-users@irc.org
Sviluppo Protocollo: ircd-dev@irc.org

Implementazione nel Software:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://ftp.irc.org/irc/clients

Newsgroup: alt.irc

9. Riconoscimenti

Parte di questo documento è stato copiato dall'RFC 1459 [IRC], prima documentazione
del protocollo IRC. Inoltre, è stato ricontrollato e commentato.
In particolare, le seguenti persone hanno contribuito, in modo significativo,
nella scrittura di questo documento:

Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
Ruokonen, Magnus Tjernstrom, Stefan Zehl.

Kalt Informativa [Pagina 17]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

10. Riferimenti

[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: Architettura", RFC 2810,
Aprile 2000.

[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, Aprile 2000.

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

11. Indirizzo Autore

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

EMail: kalt@stealth.net

Kalt Informativa [Pagina 18]
RFC 2811 Internet Relay Chat: Gestione Canale Aprile 2000

12. Copyright

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

Questo documento e relativa traduzione, possono essere utilizzati come
spiegazione nei documenti d'implementazione. Pertanto possono essere copiati, pubblicati
e distribuiti completamente, o in parte, senza alcun genere di restrizione,
però, con i copyright citati, in tutti i paragrafi dove sono inclusi e in tutte le copie ove sono presenti.
Tuttavia, questo documento, in sè, non può essere modificato in nessun modo,
rimuovendo i copyrights o i riferimenti dell Internet Society o altre
organizzazione di Internet, eccetto qualora vi sia il bisogno,
per motivi di sviluppo degli standard di Internet. In tal caso, le procedure di
copyright definite nel processo degli Standards Internet, devono essere seguite,
anche in caso di traduzione per linguaggi diversi dall'inglese.

I permessi limitati garantiti sono perpetui e non verranno revocati dalla Internet Society,
dai suoi successori o dagli assegnati.

Questo documento e le informazioni che contiene sono fornite "AS IS".
LA INTERNET SOCIETY E INTERNET ENGINEERING TASK FORCE SMENTISCONO TUTTE LE GARANZIE, ESPRESSE O IMPLICITE,
INCLUSE E NON LIMITATE A QUELLE RIGUARDO L'USO DELLE INFORMAZIONI QUI CONTENUTE.
NON GARANTISCONO IN NESSUN MODO CHE QUANTO E' PRESENTE IN QUESTO DOCUMENTO NON POSSA ANDARE AD INFRANGERE
LEGGI O LE GARANZIE DI COMMERCIO E INTEGRITA', SE IN PROPOSITI PARTICOLARI.

Ringraziamenti

I fondi per la pubblicazione degli RFC sono supportati tutt'ora dalla Internet Society.

Kalt Informativa [Pagina 10]

BIS. Traduzione interamente a cura di

Massimiliano Forner (PUOJACKZ)

2003/2004



















Kalt Informativa [Pagina 19]


Branzilla Contest Redeem

Links utili

Newsletter
Iscriviti
Cancellati

Ci sono 41 iscritti

In rilievo..
  JackSMS v3
  Venom Script Lite

Documenti/Guide
  I Social Network
  Sicurezza in rete
  Cos'è SSL
  FAQ Bot
  Documenti su IRC
  FAQ Ident
  RFC 2810
  RFC 2811
  IRCx RFC

Informatica libera
  Gli Hoaxes
  Hoaxes report
  Documenti vari
  CensorWare
  Windows
  Linux

mIRC Scripting
  Codice ASCII
  Snippet mIRC scripting
  Tutorial mIRC scripting
  Dll per mIRC
  Utilities

IRCd
  Cos'è un IRCd
  Download Unreal
  Download Hybrid 6
  Download Hybrid 7
  Download Ultimate
  Download Bahamut
  Configurazione IRCd

IRC Services
  Cosa sono i Services
  Download Anope
  Download Epona
  Ircservices 5.0
  Ircservices 5.1
  Configurazione Epona
  Configurazione Anope
  Comandi ChanServ
  Comandi NickServ
  Comandi MemoServ

NeoStats
  Cosa sono i NeoStats
  Download NeoStats
  Configurazione NeoStats
  Download Moduli

IPv6
  Cos'è IPv6
  IPv6 su Win2000
  IPv6 su WinXP
  IPv6 su Linux
  IPv6 su mIRC e Xchat

Programmazione
  Tutorial C++
  Tutorial C
  Compilatori C/C++

Altro
  Contatti
  Banners Gallery

RSS Feed




Progetti
Starlight
IRCHippo

Validato CSS
Sito interamente sviluppato in PHP
MySQL
©2004+ IRC-Zone | Webmaster | Sitemap
Created by Cesare 'Kaesar83' Lasorella
Designed by Manuel 'erkokki' Cabras
IRC-Zone non è responsabile del contenuto dei siti linkati
Pagina creata in: 0.134 sec con 25 queries
Spampoison
Sviluppato con Notepad++
website monitoring service