domenica 23 luglio - 02:47
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: 989502 file
Totale: 1503994 MB

footer

Links amici

IRCx RFC
INTERNET-DRAFT Dalen Abraham
Scade: 16 Dicembre, 1998
Microsoft Corporation
Giugno 1998


Estensione del Protocollo di Internet Relay Chat (IRCX)


1. Stato di questo Memorandum

Questo documento è un Internet-Draft. Gli Internet-Drafts
sono documenti creati dalla Internet Engineering Task Force
(IETF), riguardo quanto da loro prodotto. Da notare che,
anche altri gruppi possono produrre Internet-Draft.

Internet-Drafts sono abbozzi, che hanno una validità massima
di 6 mesi e possono essere aggiornati, rimpiazzati, o resi
obsoleti da altri testi, in ogni momento.
E' inappropriato usare gli Internet-Drafts come manuali
di riferimento o citarli diversamente che "in fase lavorativa".

Per vedere l'intera lista di Internet-Drafts, cerca il file
"1id-abstracts.txt" presente su Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Nord Europa),
ftp.nis.garr.it (Sud Europa), munnari.oz.au (Pacifico),
ftp.ietf.org (US Costa Est), or ftp.isi.edu (US Costa Ovest).

2. Astrazione

Questo documento descrive l'IRCX, un set di estensioni del
protocollo di Internet Relay Chat (IRC) definito nell'RFC 1459[1].
Sono definite solo le interazioni tra client-server.
Le funzionalità aggiunte includono l'autenticazione dell'utente
per sistemi di sicurezza multipli, supporto per i caratteri UNICODE[2],
sicurezza multipiattaforma e un meccanismo di funzionamento unico.
I server di Chat possono supportare canali o server/services
con il pieno controllo su tutti i messaggi e gli eventoi.
Questi servizi comunicano con il server principale, tramite una connessione
IRC estesa.

Tutti i cambiamenti del protocollo IRC sono destinati a scontrarsi
con i clients esistenti. Supporti del protocollo esteso, possono essere
presenti nei client per il vantaggio di aggiungere nuove funzionalità
o conformarsi al protocollo di base, definito dall'RFC 1459.




[Pagina 1]




INTERNET-DRAFT IRCX Giugno 1998


2.1. Contenuti

1. Stato di questo Memorandum................................1
2. Astrazione................................................1
2.1. Contenuti............................................2
3. Encoding UTF8 per i caratteri UNICODE.....................5
4. Termini e Definizioni.....................................5
4.1. Livello d'accesso Utente.............................6
4.2. Prefissi.............................................6
5. Messaggi Client IRCX......................................7
5.1. Comando ACCESS (nuovo comando IRCX)..................8
5.1.1. Parametri........................................8
5.1.2. Risultati........................................8
5.1.3. Errori possibili.................................9
5.1.4. Approfondimenti..................................9
5.1.5. Esempi...........................................9
5.2. Comando AUTH (nuovo comando IRCX)...................10
5.2.1. Parametri.......................................10
5.2.2. Risultati.......................................10
5.2.3. Errori possibili................................10
5.2.4. Approfondimenti.................................10
5.2.5. Esempi..........................................10
5.3. CREATE (nuovo comando IRCX).........................11
5.3.1. Parametri.......................................11
5.3.2. Risultati.......................................11
5.3.3. Errori possibili................................11
5.3.4. Approfondimenti.................................12
5.3.5. Esempi..........................................12
5.4. DATA / REQUEST / REPLY (nuovo comando IRCX).........12
5.4.1. Parametri.......................................12
5.4.2. Risultati.......................................13
5.4.3. Errori possibili................................13
5.4.4. Approfondimenti.................................13
5.4.5. Esempi..........................................13
5.5. evento (nuovo comando IRCX)..........................13
5.5.1. Parametri.......................................13
5.5.2. Risultati.......................................14
5.5.3. Errori possibili................................14
5.5.4. Approfondimenti.................................14
5.5.5. Esempi..........................................14
5.6. IRCX (nuovo comando IRCX)...........................15
5.6.1. Parametri.......................................15
5.6.2. Risultati.......................................15
5.6.3. Esempi..........................................15
5.7. ISIRCX (nuovo comando IRCX).........................15
5.7.1. Risultati.......................................15
5.8. LISTX (nuovo comando IRCX)..........................15
5.8.1. Parametri.......................................16
5.8.2. Risultati.......................................16
5.8.3. Approfondimenti.................................17
5.9. MODE (estensione del comando RFC 1459)..............17
5.9.1. Risultati.......................................17
5.9.2. Approfondimenti.................................17
5.10. NOTICE (estensione del comando RFC 1459)............18


[Pagina 2]




INTERNET-DRAFT IRCX Giugno 1998


5.10.1. Risultati......................................18
5.11. PRIVMSG (estensione del comando RFC 1459)...........18
5.11.1. Risultati......................................18
5.12. PROP (nuovo messaggio IRCX).........................18
5.12.1. Risultati......................................18
5.12.2. Errori possibili...............................19
5.12.3. Approfondimenti................................19
5.12.4. Esempi.........................................19
5.13. WHISPER (nuovo messaggio IRCX)......................19
5.13.1. Risultati......................................19
5.13.2. Errori possibili...............................19
5.13.3. Approfondimenti................................20
6. IRCX Server Messages.....................................20
6.1. AUTH (nuovo messaggio IRCX).........................20
6.1.1. Parametri.......................................20
6.1.2. Approfondimenti.................................21
6.2. CLONE (nuovo messaggio IRCX)........................21
6.2.1. Parametri.......................................21
6.2.2. Approfondimenti.................................21
6.2.3. Esempi..........................................21
6.3. CREATE (nuovo messaggio IRCX).......................21
6.3.1. Parametri.......................................21
6.3.2. Approfondimenti.................................22
6.3.3. Esempi..........................................22
6.4. DATA / REQUEST / REPLY (nuovo messaggio IRCX).......22
6.4.1. Parametri.......................................22
6.4.2. Approfondimenti.................................22
6.5. evento (nuovo messaggio IRCX)........................23
6.5.1. Parametri.......................................23
6.5.2. Esempi..........................................23
6.6. KNOCK (nuovo messaggio IRCX)........................23
6.6.1. Parametri.......................................24
6.6.2. Approfondimenti.................................24
6.7. REDIRECT (nuovo messaggio IRCX).....................24
6.7.1. Parametri.......................................24
6.7.2. Approfondimenti.................................24
6.7.3. Esempi..........................................24
6.8. WHISPER (nuovo messaggio IRCX)......................24
6.8.1. Parametri.......................................24
6.8.2. Approfondimenti.................................25
6.8.3. Esempi..........................................25
7. Modalità Utente e Proprietà..............................25
7.1. OWNER (IRCX +q).....................................25
7.2. GAG (IRCX +z).......................................25
8. Modalità Canale e Proprietà..............................26
8.1. Modalità............................................26
8.1.1. PUBBLICO (RFC1459 default)........................26
8.1.2. PRIVATO (RFC1459 +p)............................26
8.1.3. NASCOSTO (IRCX +h)................................26
8.1.4. SEGRETO (RFC1459 +s).............................26
8.1.5. MODERATED (RFC1459 +m)..........................27
8.1.6. NOEXTERN (RFC1459 +n)...........................27
8.1.7. TOPICOP (RFC1459 +t)............................27
8.1.8. INVITE (RFC1459 +i).............................27


[Pagina 3]




INTERNET-DRAFT IRCX Giugno 1998


8.1.9. KNOCK (IRCX +u).................................27
8.1.10.NOFORMAT (IRCX +f)..............................27
8.1.11.NOWHISPER (IRCX +w).............................28
8.1.12.AUDITORIUM (IRCX +x)............................28
8.1.13.REGISTERED (IRCX +r)............................28
8.1.14.SERVICE (IRCX +z)...............................28
8.1.15.AUTHONLY (IRCX +a)..............................29
8.1.16.CLONEABLE (IRCX +d).............................29
8.1.17.CLONE (IRCX +e).................................29
8.2. Proprietà...........................................30
8.2.1. OID (R/O).......................................30
8.2.2. NAME (R/O)......................................30
8.2.3. CREATION (R/O)..................................30
8.2.4. LANGUAGE........................................30
8.2.5. OWNERKEY........................................30
8.2.6. HOSTKEY.........................................31
8.2.7. MEMBERKEY.......................................31
8.2.8. PICS............................................31
8.2.9. TOPIC...........................................31
8.2.10.SUBJECT.........................................31
8.2.11.CLIENT..........................................31
8.2.12.ONJOIN..........................................32
8.2.13.ONPART..........................................32
8.2.14.LAG.............................................32
8.2.15.ACCOUNT.........................................32
8.2.16.CLIENTGUID......................................32
8.2.17.SERVICEPATH.....................................33
9. Risposte Comandi IRCX....................................33
9.1. Risposte Comandi....................................33
9.2. Risposte Errori IRCX................................36
10. Considerazioni di Sicurezza..............................39
11. Riconoscimenti...........................................40
12. Riferimenti..............................................40
13. Indirizzi Autori.........................................40






















[Pagina 4]




INTERNET-DRAFT IRCX Giugno 1998


3. Encoding UTF8 per i caratteri UNICODE

Permettendo la visualizzazione delle stringhe in caratteri
UNICODE, vi è l'introduzione di un set di problemi di compatibilità.
L'encoding UTF8 è utilizzato per convertire, caratteri UNICODE
globali, in stringhe compatibili con i server IRC e clients IRC
esistenti.

Per permettere il contenimento totale di tutti i caratteri
UNICODE, si dovrà introdurre un post-processo addizionale,
che andrà ad intervenire nel risultato della traduzione UTF8.

Tutte le stringhe che inizieranno con il carattere '%' (es.
motivazioni del comando REDIRECT), saranno interpretate come
stringhe codificate UTF8 UNICODE.

I caratteri UNICODE codificati in UTF8 potrebbero usare più bytes
di un semplice carattere ASCII. Per assicurare la compatibilità,
le stringhe UNICODE, come nicknames o nomi canale, devono rientrare
nella lunghezza standard, misurata in bytes, non in caratteri.

Il carattere di quoting per il post-processo è il '\'.
Tutta la mappatura è mostrata nella tabella qui sotto.

Tabella 1 - Caratteri per il Quoting nell'UTF8

\b " " (blank)

\c ","

\\ "\"

\r CR

\n LF

\t TAB

I clients IRCX vedono le stringhe codificate UTF8 UNICODE nella loro forma
nativa. In questo modo, clients non-IRCX non possono interagire con nicks
(i nicks UNICODE sono tradotti dal server in una forma utilizzabile dai clients
non-IRCX, prima di essere spediti ad essi). Questa forma utilizzabile è
un semplice formato esadecimale, preceduto dal carattere '^'.
I clients non-IRCX possono usare questa forma esadecimale
per specificare gli utenti IRCX/UNICODE.

4. Termini e Definizioni

In questo documento utenteemo dei particolari termini
che sono definiti nelle pagine seguenti.

La lunghezza delle stringhe è indicata in "caratteri",
in riferimento ai caratteri ASCII, in quanto ogni stringa UNICODE
dev'essere codificata in ASCII per il protocollo IRC.


[Pagina 5]




INTERNET-DRAFT IRCX Giugno 1998


Tabella 2 - Definizioni e Termini

Chat Network Un Chat Network è formato da uno o più
servers linkati assieme.

Server Un Server è una macchina singola che ospita un IRCd.

Canale Un Canale (qualche volta chiamata room o
conferenza) è un luogo virtuale di conversazione
tra uno o più utenti.

Membro Un Membro è un utente che è parte di una conversazione
nel canale.

Utente Un Utente è un client che ha effettuato una connessione
al server.

Oggetto Un Oggetto è un termine generale per i canali,
utenti, membri (utenti del canale), e
servers. Questo tipo di oggetto può essere
determinato dal primo carattere del nome dell'
oggetto.

4.1. Livelli d'accesso utente

Ci sono sei livelli di accesso che definiscono l'abilità all'utente
di effettuare un certo tipo di operazioni. Alcuni livelli sono determinati
nel contesto delle operazioni che eseguirà.

Tabella 3 - Definizione dei Livelli Client

Sysop Manager Un Sysop Manager ha accesso completo a tutti i
comandi.

Sysop Un Chat Sysop controlla il chat network.
Nell'RFC 1459 è definito IRCOp.


canale Owner Un canale Owner gestisce il canale
e i relativi canale Hosts.

canale Host Un canale Host gestisce il canale.
Nell'RFC 1459 è definito ChanOp.

canale Member Un canale Member è un membro del canale.

Chat utente Un Chat utente è un client connesso al server.

NT: I nomi sono stati mantenuti in lingua originale, in quanto,
rappresentano uno standard identificativo universale.

4.2. Prefissi

Ogni oggetto contiene un prefisso univoco, che identifica il tipo
di oggetto. Effettuando il tagging degli oggetti UNICODE con un speciale
prefisso, un client può facilmente decidere se usare lo standard ASCII
oppure UNICODE, quando spedisce un messaggio ad un utente o canale.
Il client IRCX è responsabile, quando spedisce una stringa UNICODE, per


[Pagina 6]




INTERNET-DRAFT IRCX Giugno 1998


quanto riguarda il prefisso, con un carattere '%', in modo che i
client IRCX possano interpretarlo come UNICODE.

Tabella 4 - Identificatori degli oggetti

# Il prefisso '#' identifica un canale globale (RFC1459).

& Il prefisso '&' identifica un canale locale (RFC1459).

%# Il prefisso "%#" identifica un canale globale esteso
(modifica apportata riguardo le stringhe codificate UTF8 UNICODE).

%& Il prefisso "%&" identifica un canale locale esteso
(modifica apportata riguardo le stringhe codificate UTF8 UNICODE).

% Il carattere "%", seguito da uno spazio o ",", può
identificare l'ultimo canale in cui il client è stato membro.
Questa funzione ottimizza il processing del server, nei messaggi
multipli, dal client al canale.

A > } Dall'"A" all'"}" vi sono i prefissi che identificano lo standard
dei nicknames specificato nell'RFC 1459.

' Il prefisso "'" identifica i nicknames estesi di IRCX
che consistono in stringhe modificate e codificate UTF8 UNICODE.
Il carattere "'" seguito da uno spazio o ","
è usato per rappresentare le connessioni dei clients locali.
Il carattere seguente può essere da "0"
a "9", "-", e tutti i caratteri superiori all'"A".

^ Il prefisso "^" identifica un nickname tradotto
dall'UTF8 in caratteri esadecimali in modo che il nickname
possa essere visto anche dai clients non-IRCX.
I caratteri seguiti dal "^" possono essere quelli standard
dei nicknames (RFC 1459).

0 Il prefisso "0" identifica un identificatore di un oggetto
interno (OID). L'OID consiste nel prefisso '0'
e otto numeri esadecimali. Se non è supportato dal server,
l'OID deve essere riportato "0".

$ Il prefisso "$" identifica un server del network.
Il carattere "$" seguito da uno spazio o "," può essere
usato per rappresentare il server locale a cui il client
è connesso.

5. Messaggi Client IRCX

Questa sezione contiene i comandi dettagliati introdotti o modificati
rispetto lo standard dell'RFC 1459. Le risposte dal server sono discusse,
in modo specifico, nella prossima sezione.



[Pagina 7]




INTERNET-DRAFT IRCX Giugno 1998


5.1. Comando ACCESS (nuovo comando IRCX)

Crea un accesso ad un oggetto, permettendo così di stabilire
l'uso di quest'ultimo, incluso canali, utenti o il server.
ACCESS LIST è usato per creare una lista di tutti gli accessi
degli oggetti, e CLEAR è usato per pulire tutti quelli
dello stesso livello (di quello specificato in input).

Sintassi 1: ACCESS LIST

Sintassi 2: ACCESS ADD|DELETE
[ [:]]

Sintassi 3: ACCESS CLEAR []

5.1.1. Parametri

L'oggetto di quell'accesso può essere
limitato o ristabilito.
Può essere il nome di un canale, nickname, $ o *.

Il livello d'accesso può essere dato o tolto.
Le possibili scelte sono:

DENY Disabilita l'accesso ad un oggetto accessibile

GRANT Abilita l'accesso ad un oggetto inaccessibile

HOST Accesso canale host al canale specificato

OWNER Accesso canale owner al canale specificato

VOICE Accesso Voice al canale specificato

Mask per identificare un utente dal nickname, utenteid, host o
dalle caratteristiche del server. Supporta wildcards * e ?.

Imposta i minuti di permanenza dell'accesso.
il valore 0 indica per un tempo illimitato.

Indica la motivazione, che verrà fornita quando un utente
tenterà un accesso vietato, relativa ad un accesso.

5.1.2. Risultati

IRCRPL_ACCESSADD

IRCRPL_ACCESSDELETE

IRCRPL_ACCESSSTART

IRCRPL_ACCESSLIST

IRCRPL_ACCESSEND



[Pagina 8]




INTERNET-DRAFT IRCX Giugno 1998


5.1.3. Errori possibili

Sono disponibili i seguenti messaggi d'errore:

IRCERR_BADlivello

IRCERR_DUPACCESS

IRCERR_MISACCESS

IRCERR_TOOMANYACCESSES

IRCERR_TOOMANYARGUMENTS

IRCERR_BADcomando

IRCERR_NOTSUPPORTED

IRCERR_NOACCESS

5.1.4. Approfondimenti

Un oggetto con l'accesso GRANT attivo, senza quello DENY, è
definito per tutti gli utenti che non sono coperti da una regola
GRANT. Se ci sono accessi multipli, nella lista,
quest'ultimi verranno eseguiti nel seguente ordine: OWNER,
HOST, VOICE, GRANT, DENY.

Hosts e Owners possono aggiungere o togliere accessi nel loro canale.
Gli Hosts non possono rimuovere gli accessi inseriti dagli Owners.
Un utente può aggiungere o togliere accessi che lo riguardano (non in un canale).
Sysops e Sysop managers possono aggiungere o togliere accessi sia dal server
che dal network intero.

Un utente che ha bloccato un altro utente, non riceve alcun messaggio da quest'ultimo
(inviti inclusi).

5.1.5. Esempi

Per rendere, "piper", un canale host, quando entra nel canale,
"#mychan":

ACCESS #mychan ADD HOST piper

Per garantire l'accesso normale alla rete, ad un gruppo ristretto di persone
e vietarne ad un gruppo più esteso:

ACCESS * ADD DENY * :chiuso (festa privata)

ACCESS * ADD GRANT *.company.com :queste persone possono entrare

Per cancellare un accesso vietato, nella rete, che non permette l'entrata
a '*' (questo non rimuoverà nessun altro accesso vietato (Es. '*.com')):


[Pagina 9]




INTERNET-DRAFT IRCX Giugno 1998


ACCESS * DELETE DENY *

Per pulire tutti i livelli di divieto, nel server locale:

ACCESS $ CLEAR DENY

Per pulire tutti i livelli di divieto, in un canale:

ACCESS #mychan CLEAR

5.2. Comando AUTH (nuovo comando IRCX)

Autentica un client usando il sistema di autenticazione SASL[4].

Sintassi 1: AUTH [:]

5.2.1. Parametri

Il nome del sistema SASL in uso per l'autenticazione.

La sequenza è un valore di 'I' o 'S'. Il valore 'I'
specifica per i messaggi AUTH iniziali e 'S' per tutti i seguenti.
Se il client specifica '*' per la sequenza, il server bloccherà
la sequenza di autenticazione e fornirà l'errore
IRCERR_AUTHENTICATIONFAILED.

Questo è un parametro opzionale, spedito nei messaggi
AUTH. Il contenuto dipende dal sistema di autenticazione usato.
Ogni contenuto deve rispettare lo standard nel formato di paginazione
(Es. \r per il carriage return) per essere compatibile con le restrizioni
della formattazione del messaggio IRC.

5.2.2. Risultati

AUTH messaggio

5.2.3. Errori Possibili

ERR_NEEDMOREPARAMS

IRCERR_ALREADYAUTHENTICATED

IRCERR_ALREADYREGISTERED

IRCERR_AUTHENTICATIONFAILED

IRCERR_AUTHENTICATIONSUSPENDED

IRCERR_BADcomando

IRCERR_UNKNOWNPACKAGE


[Pagina 10]




INTERNET-DRAFT IRCX Giugno 1998


5.2.4. Approfondimenti

Se il server supporta l'IRCX con un meccanismo SASL
specifico, il primo messaggio dal client IRCX
dovrà essere il comando AUTH (se l'autenticazione è attiva),
prima che l'utente invii i comandi utente e NICK.
Usa MODE ISIRCX per determinare se il server supporta IRCX.

5.2.5. Esempi

Client: AUTH NTLM I :

Server: AUTH NTLM S :

Client: AUTH NTLM S :

Server: AUTH NTLM * utenteid@domain 03FA4534C

5.3. CREATE (nuovo comando IRCX)

Crea un canale nuovo e/o entra in un canale già esistente.

Sintassi: CREATE [ []]

5.3.1. Parametri

Il nome del canale.

Le modalità di canale iniziali, non separate dagli spazi (come
il comando MODE). Include il mode 'e' per forzare la creazione
di un clone del canale clonabile.

Argomento opzionale del mode, separato da degli spazi,
nello stesso ordine dei modes. Per il mode 'l', l'argomento sarà il
numero massimo di membri permessi in canale.
Per il mode 'k', l'argomento sarà la KeyChan per entrare.
Solo le uniche modalità che richiedono gli argomenti, come parametro.

5.3.2. Risultati

CREATE messaggio

JOIN messaggio

RPL_TOPIC

RPL_NAMEPLY

RPL_ENDOFNAMES

5.3.3. Errori Possibili

IRCERR_canaleEXIST


[Pagina 11]




INTERNET-DRAFT IRCX Giugno 1998


IRCERR_ALREADYONcanale

ERR_NEEDMOREPARAMS

ERR_INVITEONLYCHAN

ERR_canaleISFULL

ERR_BANNEDFROMCHAN

ERR_BADcanaleKEY

ERR_TOOMANYcanaleS

ERR_UNKNOWNcomando

5.3.4. Approfondimenti

Il comando CREATE fornisce un metodo per specificare le proprietà
durante la creazione del canale, e anche, per aprire un nuovo canale
(se quest'ultimo non esiste).
Se l'utente non è in modalità IRCX, il server fornisce l'errore
ERR_UNKNOWNcomando.

5.3.5. Esempi

Questo esempio mostra la creazione di un canale moderato (m)
con le seguenti proprietà e modalità: il suo topic può essere
modificato solo dall'owner o dagli hosts (t = TOPICOP), i messaggi
dall'esterno sono bloccati (n = NOEXTERN), è limitato a 50 utenti (l 50),
ha una KeyChan 'password' (k password), e verrà creato solo se non
esiste già (c = CREATE)

Client: CREATE #Mycanale tnmlkc 50 password

Server: CREATE #Mycanale 048532944

5.4. DATA / REQUEST / REPLY (nuovo comando IRCX)

Usato per spedire dati ordinati, richieste o risposte. La sintassi per ogniuno
è la stessa, ma i clients possono usare REQUEST per indicare la richiesta di un
REPLY, e usare REPLY per indicare che REQUEST è stato effettuato.
Se l'utente non è in modalità IRCX, il server fornisce, come risposta,
ERR_UNKNOWNcomando.

Sintassi 1: DATA :

5.4.1. Parametri

L'obbiettivo del comando. Target può essere un nick, una lista di nicks,
un canale, una lista di canali, o un canale seguito da una lista di alcuni
membri del canale. Questa



[Pagina 12]




INTERNET-DRAFT IRCX Giugno 1998


definizione di verrà usata in questo
documento.

Campo testo che i clients usano per sapere come
interpretare il dato. I caratteri validi sono [A..z], [0..9] e (.).
Il primo carattere de'vessere uno dei [A..z].
Massimo 15 caratteri. Se il tag inizia con un ADM, SYS,
OWN o HST allora l'origine deve avere il privilegio appropriato
(Sysop Manager, Sysop, canale Owner o canale Host.
canale Owner & Host invieranno nel canale il messaggio
appena spedito.) Il server, in se, può spedire tags che
iniziano con queste parole riservate.

Il carico o il dato del messaggio, finisce con una
nuova linea. Le linee nuove o i caratteri di controllo, presenti nel
messaggio, devono presentare un carriage return.

5.4.2. Risultati

DATA messaggio

5.4.3. Errori Possibili

ERR_UNKNOWNcomando

5.4.4. Approfondimenti

REPLY e REQUEST possono essere usati, in sostituzione a "DATA".
I servers IRCX non dovrebbero spedire comandi DATA ai clients,
che non hanno indicato il loro supporto all'IRCX.
I clients devono solo processare il messaggio DATA
se conoscono e supportano il tag in uso.

I prefissi devono indicare l'organizzazione che li specifica,
quando appropriato. Ad esempio: MYORG.AVATAR dev'essere un tag
usato da MyOrg, come sarebbero i tags MYORG.*.

5.4.5. Esempio

Spedire banners ad dal server sysop al canale, "#canale":

DATA #canale SYS.AD.SMALL :

5.5. evento (nuovo comando IRCX)

Aggiunge/Cambia/Rimuove il logging degli eventoi effettuati
presso un client, dalla connessione. La lista dei tipi di eventoi e di come
le masks vengono applicate, non è specificato qua.

Sintassi 1: evento [ADD | DELETE] []

Sintassi 2: evento LIST []

5.5.1. Parametri



[Pagina 13]




INTERNET-DRAFT IRCX Giugno 1998


Tipo di eventoo, può essere canale, MEMBER, SERVER,
CONNECTION, SOCKET o utente.

Mask opzionale, che stabilisce un criterio di logging
degli eventoi.

5.5.2. Risultati

IRCRPL_eventoADD

IRCRPL_eventoDEL

IRCRPL_eventoSTART

IRCRPL_eventoLIST

IRCRPL_eventoEND

5.5.3. Errori Possibili

ERR_NEEDMOREPARAMS

ERR_NOPRIVILEGES

IRCERR_BADFUNCTION

IRCERR_eventoDUP

IRCERR_eventoMIS

IRCERR_NOSUCHevento

IRCERR_TOOMANYeventoS

5.5.4. Approfondimenti

Il comando evento può essere usato dalle altre implementazioni del server,
per definire gli eventoi che i sysop manager o i sysop del server
vorrebbero che fossero notificati. Solo i sysop managers e/o
i sysop possono ricevere i messaggi evento.

5.5.5. Esempi

Aggiunge un eventoo canale.

Client: evento ADD canale

Server: : 806 canale *!*@*$*

Aggiunge una lista di eventoi senza che alcun eventoo dia una risposta.

Client: evento LIST

Server: : 808 :Inizio degli eventoi


[Pagina 14]




INTERNET-DRAFT IRCX Giugno 1998


: 809 canale *!*@*$*

: 810 :Fine degli eventoi

5.6. IRCX (nuovo comando IRCX)

Abilita la modalità IRCX e mostra lo status dell'IRCX. Usa MODE ISIRCX
per vedere se il server supporta l'IRCX.

Sintassi: IRCX

5.6.1. Parametri

Nessuno.

5.6.2. Risultati

IRCRPL_IRCX

5.6.3. Esempi

Questo esempio include un server che supporta l'IRCX, e 3 dispositivi
di autenticazione.

Client: IRCX

Server: : 800 1 0 NTLM,DPA,ANON 512 *

5.7. ISIRCX (nuovo comando IRCX)

Mostra se un server supporta il protocollo RFC1459 esteso (IRCX).
Il server fornisce il dato, nella stessa maniera del messaggio IRCX.

Usa ISIRCX dopo essere entrato nel server, per ottenere le informazioni.

Sintassi: ISIRCX

5.7.1. Risultati

IRCRPL_IRCX

5.8. LISTX (nuovo comando IRCX)

versionee estesa del comando LIST, che fornisce dei parametri aggiuntivi
riguardo le proprietà di canale.
I canali, con nome esteso, verranno visualizzati anche dai clients
non-IRCX. Alcune modalità di canale, e stringhe PICS, sono presenti
nella risposta. Solo le chanflags che non presentano un argomento
aggiuntivo, sono incluse den campo .
I clients dovrebbero usare un limite di querying, in modo da evitare
il sovraccarico, che potrebbe causare un drop da parte del server.

Sintassi 1: LISTX []


[Pagina 15]




INTERNET-DRAFT IRCX Giugno 1998


Sintassi 2: LISTX []

5.8.1. Parametri

Lista dei canali. Può essere richiesta in modo
da trovare il ratings PICS oppure i modes di quei canali.
Se non sono specificati i canali, il server spedirà tutta
la lista attiva.

Una o più query, separate da spazi o virgole.

Tabella 5 - Parametri del comando LIST

<# Mostra tutti i canali con meno di # membri.

># Mostra tutti i canali con più di # membri.

C<# Mostra tutti i canali creati prima di # minuti
fa.

C># Mostra tutti i canali creati dopo di # minuti
fa.

L= Mostra i canali con una proprietà di linguaggio
che presenti la stringa fornita come parametro.

N= Mostra i canali con un nome che rientri nella mask
fornita in input.

R=0 Mostra i canali non registrati.

R=1 Mostra i canali registrati.

S= Mostra i canali che hanno un soggetto che rientri
nella mask specificata.

T<# Mostra i canali che hanno cambiato topic prima di # minuti fa.

T># Mostra i canali che hanno cambiato topic dopo di # minuti fa.

T= Mostra i canali che hanno un topic che rientri nella mask
specificata.

Numero massimo di risposte, indipendente dalla mask usata.

Sequenza di caratteri usata per creare la lista.
I caratteri * e ? possono essere usati nella ricerca.

5.8.2. Risultati


[Pagina 16]




INTERNET-DRAFT IRCX Giugno 1998


IRCRPL_LISTXSTART

IRCRPL_LISTXLIST

IRCRPL_LISTXPICS

IRCRPL_LISTXTRUNC

IRCRPL_LISTXEND

5.8.3. Approfondimenti

Per comporre una mask, si possono usare questi particolari caratteri di controllo.

Tabella 6 - Caratteri di controllo nella stringa mask

\b per il " " blank

\c per il ","

\\ per il "\"

\* per il *

\? per il ?

Il PICS risponde solo se non è a null.

Il limite record di '0' (zero) o blank sarà interpretato come
illimitato.

5.9. MODE (estensione del comando descritto nell'RFC 1459)

Il comando MODE può essere usato per i nuovi utenti o per le chanflags
(vedi le prossime sezioni). In aggiunta, la sintassi speciale "MODE
ISIRCX" può essere usata per aiutare i clients nel trovare un server IRCX, prima
di effettuare il logging.

Sintassi: MODE ISIRCX

5.9.1. Risultato

MODE messaggio

IRCRPL_IRCX

5.9.2. Approfondimenti

La modalità ISIRCX (dev'essere scritto a caratteri MAIUSCOLI)
è funzionale solo prima che l'utente abbia eseguito la registrazione
nel server.
I servers IRCX rispondono con un IRCRPL_IRCX e i servers non-IRCX
devono rispondere un codice d'errore. Questo permette agli utenti
non registrati di vedere se il server supporta IRCX.



[Pagina 17]




INTERNET-DRAFT IRCX Giugno 1998


Vedere l'RFC1459 per ulteriori dettagli nel comando MODE originale e
nei relativi parametri.

5.10. NOTICE (estensione del comando descritto nell'RFC 1459)

Spedisce un notice ad un canale o ad un utente. Nell'RFC1459, un notice,
può essere spedito solo ad un canale o ad una lista di utenti.
Ora, invece, può essere inviato ad una lista di utenti che hanno una particolarità
all'interno di un canale. Come prima, gli utenti non riceveranno la lista
di tutti coloro a cui è stato spedito il notice.

Sintassi: NOTICE :

5.10.1. Risultati

Com'era già stato definito nell'RFC1459, sono presenti delle
funzionalità aggiuntive, di spedizione alla lista di nicknames,
con particolarità presenti nel canale.

5.11. PRIVMSG (estensione del comando descritto nell'RFC 1459)

Spedisce un messaggio ad un canale o un utente. PRIVMSG è esteso come il NOTICE.

Sintassi: PRIVMSG :

5.11.1. Risultati

Com'era già stato definito nell'RFC1459, sono presenti delle
funzionalità aggiuntive, di spedizione alla lista di nicknames,
con particolarità presenti nel canale.

5.12. PROP (nuovo comando IRCX)

Aggiunge, cambia o cancella la proprietà di dato di un canale.

Per ottenere una proprietà:

Sintassi 1: PROP [,]

Per settare o cambiare proprietà:

Sintassi 2: PROP :

Per cancellare una proprietà:

Sintassi 3: PROP :

5.12.1. Risultati

PROP messaggio

IRCRPL_PROPLIST



[Pagina 18]




INTERNET-DRAFT IRCX Giugno 1998


IRCRPL_PROPEND

5.12.2. Errori Possibili

IRCERR_BADcomando

IRCERR_BADproprietà

IRCERR_SECURITY

IRCERR_NOSUCHoggetto

IRCERR_TOOMANYARGUMENTS

IRCERR_BADvalore

5.12.3. Approfondimenti

Il comando PROP fornisce un nuovo metodo per manipolare le stringhe e le
proprietà numeriche dei canali. Se una proprietà opzionale di canale
non è supportata nel server, quest'ultimo risponderà con un IRCERR_BADproprietà.

Vedi la sezione 8.2 per la definizione delle proprietà di canale.

5.12.4. Esempi

Client: PROP #MyChan TOPIC,ONJOIN

Server: : 818 #MyChan TOPIC :Questo è il topic del canale

Server: : 818 #MyChan ONJOIN :Benvenuto nel mio canale

Server: : 819 #MyChan :Fine delle proprietà

Client: PROP #Mycanale TOPIC :Cambia il topic del mio canale

Server: PROP #Mycanale TOPIC :Cambia il topic del mio canale

5.13. WHISPER (nuovo comando IRCX)

Bisbiglia ad un membro del canale.

Sintassi: WHISPER :

5.13.1. Risultati

WHISPER messaggio

5.13.2. Errori Possibili


[Pagina 19]




INTERNET-DRAFT IRCX Giugno 1998


ERR_UNKNOWNcomando

ERR_CANNOTSENDTOCHAN

ERR_utenteNOTINcanale

ERR_NEEDMOREPARAMS

IRCERR_NOTONcanale

IRCERR_TOOMANYTARGETS

IRCERR_NOSUCHNICK

IRCERR_NOSUCHcanale

IRCERR_NOWHISPER

5.13.3. Approfondimenti

Il proposito del comando WHISPER è quello di bisbigliare ad uno o
più membri di un canale a seconda delle loro proprietà.
L'emittente e tutti i destinatari devono essere nel canale
specificato. Un bisbiglio è differente dalla ricezione di un messaggio
privato, in quanto, include, sia una lista utenti che il nome del canale,
che indica che il messaggio è privato, ma ha un contesto.

I clients IRCX devono mostrare il messaggio WHISPER con il contesto
(possibilmente una finestra) del canale specificato. I clients Non-
IRCX riceveranno un messaggio PRIVMSG con il contesto del (perdendo
la differenza del Whisper). Solo un Whisper, può essere spedito,
per nickname. Un utente può bisbigliare a se stesso.

La chanflag 'w' disabilita il comando tra i vari membri di canale
(ma non quelli spediti o ricevuti dagli Hosts (ChanOps)).

6. Messaggi Server IRCX

Questa sezione riassume tutti i nuovi messaggi estesi
che possono essere spediti al server.

6.1. AUTH (nuovo messaggio IRCX)

Negozia l'autenticazione con un client o informa quest'ultimo
che tale processo è andato a buon fine.

Sintassi 1 (autorizzazione negoziato): AUTH S
[:]

Sintassi 2 (autorizzazione avvenuta con successo): AUTH *


6.1.1. Parametri


[Pagina 20]




INTERNET-DRAFT IRCX Giugno 1998


Il nome del meccanismo SASL usato per l'autenticazione.

L'ident è utenteid@domain dell'account autenticato.
Questo è fornito come risposta finale dal server,
quando l'autenticazione ha avuto successo (Sintassi 2).

L'OID è l'identificatore interno dell'oggetto, assegnato
ad una connessione di un client. Se non è supportato dal server,
quest'ultimo deve fornire come risposta '0'.

Questo è un dato opzionale, spedito come argomento,
nel messaggio AUTH.

6.1.2. Approfondimenti

Il server spedirà la form della sintassi 2, quando il processo di autenticazione
è completato, oppure risponderà con un errore numerico.

6.2. CLONE (nuovo messaggio IRCX)

Informa gli hosts e gli owners che il canale clonabile, ha
ha un nuovo clone attivo.

Sintassi: CLONE

6.2.1. Parametri

Il nome del canale CLONE creato.

L'identificatore dell'oggetto del nuovo canale CLONE.
Il valore è dipendente dall'implementazione e dev'essere uguale a 0
se tale opzione non è supportata.

6.2.2. Approfondimenti

Il messaggio CLONE dev'essere spedito ogni volta,
agli hosts/owners, per informarli quando un canale CLONEABLE
è stato creato. Questo messaggio è inteso, nel suo utilizzo,
quando un applicazione automaticamente entra in un nuovo canale
CLONE. Un client non-IRCX non riceverà questo messaggio.

6.2.3. Esempio

Server: CLONE #MyChat1 034F8FF32

6.3. CREATE (nuovo messaggio IRCX)

Informa il client che il nuovo canale è stato creato.
Risposta del comando CREATE.

Sintassi: CREATE

6.3.1. Parametri


[Pagina 21]




INTERNET-DRAFT IRCX Giugno 1998


Il nome del canale creato.

L'identificatore dell'oggetto del nuovo canale.
Il valore è dipendente dall'implementazione e dev'essere uguale a 0
se tale opzione non è supportata.

6.3.2. Approfondimenti

Il messaggio CREATE è spedito in risposta al comando CREATE,
inviato dal client, se il canale specificato non
esisteva ed è stato creato dal server.

6.3.3. Esempio

Server: CREATE #MyChat1 034F8FF32

6.4. DATA / REQUEST / REPLY (nuovo messaggio IRCX)

Il messaggio DATA (può essere REQUEST o REPLY) è indirizzato
da un altro utente o spedito dal server. Il payload
o il messaggio, devono essere interpretati a seconda del tag.
Se il tag è sconosciuto, il messaggio è scartato.

Sintassi 1: :DATA :

:REQUEST :

:REPLY :

Se il messaggio DATA, REQUEST o REPLY è spedito ad un numero di membri
di un canale, l'utente riceventoe vedrà il nome del canale e il suo
nickname, nel messaggio:

Sintassi 2: :DATA :

6.4.1. Parametri

Può essere un utente o il server.

Canale o lista di nicknames (come spiegato qui sopra).

Tag d'identificazione.

Payload.

6.4.2. Approfondimenti

Il tag indica come comportarsi alla ricezione di un dato messaggio.
I tipi di Tag possono essere specificati dall'amministratore,
dagli sviluppatori di clients, dagli sviluppatori di servers ecc.

Un tag inizia con un SYS e può essere solo da un sysop, sysop
manager o dal server. Un tag inizia con un ADM e può solo
essere inviato da un sysop manager o da un server.


[Pagina 22]




INTERNET-DRAFT IRCX Giugno 1998


La funzionalità del messaggio DATA è differente dal
messaging client-to-client, in molti aspetti. Primo, incoraggiamo i gruppi
nel definire i loro tags e i loro formati per i dati speciali,
come, ad esempio, per indicare l'avatar di un utente in una chat grafica,
o per indicare un banner o un immagine che può essere scaricata.
Secondo, il messaggio DATA è più appropriato per contenuti che possono essere
spediti a più utenti, come ad esempio tutti quelli presenti in un canale.
Terzo, il messaggio DATA può provenire dal server.
Quarto, i prefissi SYS e ADM sono specificati in modo che tags importanti
sono riservati agli sysops, sysop managers e al server stesso,
con quello responsabile della verifica del mittente, prima che venga
divulgato il messaggio DATA.

6.5. evento (nuovo messaggio IRCX)

Notifica il client di un eventoo. Questi eventoi sono riservati
agli sysops e sysop managers, e sono spediti in aggiunta a quelli
standard di IRC.

Sintassi: evento

6.5.1. Parametri

Il numero di secondi trascorsi dalla mezzanotte
(00:00:00) dal 1 Gennaio, 1970 (tempo universale coordinato)
fino la somma complessiva di secondi trascorsi fino alla data
presente al momento della richiesta.

L'oggetto può essere un canale, membro, utente, connessione,
socket o server.

Il tipo di eventoo può variare a seconda dell'oggetto.
Per esempio, eventoi per canali possono essere Create, Destroy, cambio
Topic, cambio Mode, Collision.

Vario, a seconda del tipo di eventoo.

6.5.2. Esempio

Questo esempio è l'eventoo generato quando un utente
effettua il login nel server,
"chat1" col nickname, "john", mostrando le info utente
incluso l'indirizzo IP e la porta di connessione.

evento chat1 946080000 utente LOGON john!jsmith@uw.edu
192.29.93.93:1111

6.6. KNOCK (nuovo messaggio IRCX)

Informa l'owner e gli hosts di un canale che un utente
ha provato ad accedere in un canale, senza successo (probabilmente
in quanto il canale era pieno, la keychan errata, l'utente era bannato o per
altre ragioni).
Questo messaggio è spedito solo agli owners in modalità IRCX e hosts del
canale.



[Pagina 23]




INTERNET-DRAFT IRCX Giugno 1998


Sintassi: KNOCK

6.6.1. Parametro

Il campo utente è in formato nick!utenteid@host.

Nome del canale dove l'utente ha provato ad entrare.

Motivo percui l'utente ha provato ad entrare.

6.6.2. Approfondimenti

Un messaggio KNOCK non verrà spedito a clients non IRCX.

6.7. REDIRECT (nuovo messaggio IRCX)

Informa un client che deve connettersi ad un altro server.

Sintassi: REDIRECT :

6.7.1. Parametri

La lista di server è separata da una virgola
e fornisce host:port dei server presenti. L'host può essere
un hostname a tutti gli effetti, oppure un indirizzo IP.

Il motivo del redirect è formato da una stringa
indipendente, che può essere visualizzata opzionalmente dal client.

6.7.2. Approfondimenti

Il messaggio REDIRECT può essere spedito al client in qualsiasi momento,
per richiedere la disconnessione di un utente e la riconnessione presso
un altro server, specificato nella lista. Il messaggio REDIRECT è inviato
quando un server dev'essere spento.

Il messaggio REDIRECT non verrà spedito ai clients non IRCX.

6.7.3. Esempio

Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server pieno.

6.8. WHISPER (nuovo messaggio IRCX)

Bisbiglio da parte di un membro di canale.

Sintassi: WHISPER :

6.8.1. Parametri



[Pagina 24]




INTERNET-DRAFT IRCX Giugno 1998


Il nickname della persona che ha bisbigliato.

Il canale ove inviare il bisbiglio.

La lista di nicknames che riceveranno il messaggio.

Il contenuto del bisbiglio.

6.8.2. Approfondimenti

Il server deve trasformare il messaggio WHISPER in un PRIVMSG per i clients
che non sono IRCX.

6.8.3. Esempio

Server: Joe WHISPER #test Jill :Test whisper.

7. Modalità utente e loro proprietà

Queste sono le nuove modalità e proprietà aggiunte.
Il comando MODE, come definito dall'RFC1459, è utilizzato
per aggiungere o rimuovere modes.

7.1. OWNER (IRCX +q)

La modalità OWNER indica che l'utente è il possessore di un canale.
Solo l'Owner di canale può donare lo stato di OWNER ad un altro
membro del canale; però, ogniuno che abbia tale status attivo,
può rimuoverlo a se stesso.

I clients in modalità IRCX, vedono i nicknames in modalità
OWNER, con un prefisso '.', differentemente dagli Hosts, che
hanno un '@' (visibile nei comandi NAMES, WHO, WHOIS e tutti
quelli che effettuano una lista dei nicknames di un canale).

Da notare che la modalità HOST, utilizza il +o, che rappresentava
la modalità "operatore" nell'RFC1459. La sintassi per questi tipi di
modalità sono sempre le stesse:

MODE { + | - }q

7.2. GAG (IRCX +z)

La modalità GAG è applicata da un sysop o sysop manager, su un
utente, e, quest'ultimo, non può rimuoverla manualmente.
Questa modalità non viene notificata all'utente, in modo
da renderla più efficace.

Il server ignorerà tutti i messaggi spediti dall'utente
in modalità GAG, spediti verso un altro utente o canale.

MODE { + | - }z


[Pagina 25]




INTERNET-DRAFT IRCX Giugno 1998


8. Modalità canale e proprietà

Nuove modalità e proprietà sono stato aggiunte ai canali.

I canali supportano 4 stati esclusivi e mutabili, di visibilità:
pubblico, privato, nascosto e segreto. La visibilità di un canale
influiscono sulle modalità e proprietà disponibili ad un client.

8.1. Modes

Ogni oggetto di canale contiene un numero di settaggi di modalità binarie,
che possono essere sottoposte a query e opzionalmente aggiornate, tramite
il comando MODE (RFC1459).

8.1.1. PUBBLICO (default RFC1459)

Il canale è pubblico e tutte le informazioni riguardo un canale,
eccetto per i messaggi testuali, possono essere visualizzate dai
non-membri. La modalità PUBBLICO permette il settaggio di quella
PRIVATA, NASCOSTA e SEGRETA.

Questa modalità può essere settata dagli sysop managers, owners e
hosts di un canale. Può essere visualizzata dai sysops, membri di
canale, e utenti.

8.1.2. PRIVATO (RFC1459 +p)

Il canale è privato e solo il nome, il numero di membri e
le proprietà PICS vengono visualizzate ai non-membri.
La modalità PRIVATO permette il settaggio di quella PUBBLICA,
NASCOSTA e SEGRETA.

Questa modalità può essere settata dai sysop managers, owners e
hosts di canale. Non può essere visualizzata ai sysops o utenti.

8.1.3. NASCOSTO (IRCX +h)

Il canale è nascosto e non può essere localizzato
tramite la lista di canali, ai non-membri.
La modalità NASCOSTO permette il settaggio di quella PUBBLICA,
PRIVATA e SEGRETA. La motivazione della creazione di questa
nuova modalità NASCOSTA, è di permettere l'esistenza dei canali
senza che sia possibile vederli listandoli, ma conoscendo già,
a priori, il nome del canale. Un canale NASCOSTO, ha lo stesso
funzionamento di quello PUBBLICO, eccetto il fatto che non viene
inserito nelle liste prodotte dai comandi LIST e LISTX.

Questa modalità può essere settata e visualizzata come quella PUBBLICA.

8.1.4. SEGRETO (RFC1459 +s)





[Pagina 26]




INTERNET-DRAFT IRCX Giugno 1998


Il canale è segreto e non può essere localizzato da nessuna
richiesta effettuata da un non-membro. La modalità SEGRETA
permette l'accesso a quella PUBBLICA, PRIVATA e NASCOSTA.

Questa modalità può essere settata e visualizzata come quella PRIVATA.

8.1.5. MODERATO (RFC1459 +m)

Normalmente, un nuovo membro di canale, fin dalla sua entrata, può parlare.
Nella modalità moderata, invece, non è così.
Questi possono inviare messaggi in canale solo se hanno il mode '+v' attivo
presso il loro nickname.

Questa modalità può essere settata e visualizzata dai sysop managers, owners e
hosts del canale.

8.1.6. NOEXTERN (RFC1459 +n)

La modalità NOEXTERN blocca tutti i messaggi spediti dai non-membri,
diretti al canale. Un sysop manager può spedire ugualmente i messaggi.

8.1.7. TOPICOP (RFC1459 +t)

La modalità TOPICOP permette solo ai owners di canale e agli hosts, di poter
modificare il contenuto del topic.

8.1.8. INVITE (RFC1459 +i)

La modalità INVITE permette l'entrata solo agli utenti che hanno ricevuto
il permesso, tramite il comando INVITE. Solo gli owners e gli hosts possono
effettuare tale comando, quando questa modalità è attiva.

8.1.9. KNOCK (IRCX +u)

La modalità estesa del comando KNOCK invia i messaggi di tentato
LimitWalk, se un utente tenta di entrare e il server gli vieti di farlo.

8.1.10. NOFORMAT (IRCX +f)

La modalità NOFORMAT è un indicazione, all'applicazione client,
di non formattare il testo ricevuto in canale.


[Pagina 27]




INTERNET-DRAFT IRCX Giugno 1998


Di norma, i clients, inseriscono un prefisso ai messaggi di testo,
("x dice y", oppure, "x bisbiglia ad x e y").
Se la modalità NOFORMAT è attiva, viene visualizzato solo il testo
inviato. I clients non dovrebbero ripetere il testo spedito dal client.
Questo permette alle applicazioni di controllare la formattazione
ai clients. Questi dovranno informare gli utenti che il messaggio
è spoofato, con questa modalità settata.

Questa modalità può essere impostata solo dai sysop managers. Può essere letta
dai sysop managers, sysops, owners, hosts e membri del canale.
Può essere letta dagli utenti, se il canale è PUBBLICO o NASCOSTO.

8.1.11. NOWHISPER (IRCX +w)

La modalità NOWHISPER previene la spedizione di Whisper, tramite canale.

Questa modalità può essere settata dai sysop managers e owners.
Può essere letta dai sysops, hosts e membri di un canale, e dagli altri
utenti, se quest'ultimo è PUBBLICO o NASCOSTO.

8.1.12. AUDITORIUM (IRCX +x)

La modalità AUDITORIUM restringe la visibilità e la spedizione di
messaggi nel canale. I membri vedranno solo se stessi e gli hosts/owners di canale.
Qualsiasi messaggio spedito da un membro può essere ricevuto solo dai moderatori,
che vedranno tutti i membri del canale. I messaggi spediti dagli hosts/owners,
verranno inviati a tutti i membri del canale. I messaggi di JOIN/PART non verranno
visualizzati. Questa modalità è stata disegnata per quei canali che hanno utenti,
i quali, non vogliono leggersi l'un l'altri. Da notare che la modalità AUDITORIUM,
può essere settata solo durante la creazione del canale, impostandola nel comando
CREATE.

Questo comando può essere settato solo da sysop managers, sysops, e
owners. Può essere anche letto dagli hosts, membri del canale e dagli altri
utenti, se quest'ultimo è PUBBLICO o NASCOSTO.

8.1.13. REGISTERED (IRCX +r)

Il canale è registrato dall'amministratore del network di chat.
La procedura di registrazione non è definita qua. Solo il server e gli amministratori
possono impostare questa modalità.

Può essere letto dagli sysop managers, sysops, owners, hosts, e membri di canale.
Possono leggerlo anche gli utenti, se il canale è PUBBLICO o NASCOSTO.

8.1.14. SERVICE (IRCX +z)



[Pagina 28]




INTERNET-DRAFT IRCX Giugno 1998


Un servizio monitora/controlla un canale. Questa è un indicazione ai clients che
spediscono il traffico di canale, monitorato dal Chat Service, che non appare
come membro nel canale.

Questa modalità può essere impostata solo dal Chat Server. Può essere letta
dagli sysop managers, sysops, owners, hosts e membri del canale.
Possono leggerla anche gli utenti, se il canale è PUBBLICO o NASCOSTO.

8.1.15. AUTHONLY (IRCX +a)

La modalità AUTHONLY permette l'accesso solo agli utenti che sono stati
autenticati dal server. Nota che un utente autenticato, è un utente che si è
identificato, in modo soddisfacente, tramite il comando PASS o AUTH.

Questa modalità può essere settata dagli sysop managers o owners di canale.
Può essere letta dagli sysops, hosts e membri del canale.
Può essere letta dagli utenti di un canale, se quest'ultimo è PUBBLICO o
NASCOSTO.

8.1.16. CLONEABLE (IRCX +d)

La modalità CLONEABLE definisce un canale che crea un nuovo clone,
se il canale parente è pieno. Un canale clonato è creato con lo stesso
nome del canale parente, col suffisso numerico che inizia da 1, fino
a coprire il range a 99. Non è possibile attivare questa modalità,
se il nome del canale termina con un numero. Il canale clonato eredita
i modes e le proprietà del canale parente, quando questo viene creato.
Durante la creazione, tutti i canali che hanno quel nome, ma sono già occupati,
vengono rimossi, onde evitare takeovers.

E' consigliato mantenere il permesso di settaggio di questa flag solo
ai sysop. Può essere letto da sysops, owners, hosts
e membri del canale. Può essere letta dagli utenti di un canale, se quest'ultimo
è PUBBLICO o NASCOSTO.

8.1.17. CLONE (IRCX +e)

La modalità CLONE definisce un canale che è stato creato, da un altro
canale parente, che ha raggiunto il limite massimo di utenza.
Gli utenti, di norma, entrano nel canale parente, sebbene un utente
possa entrare in un canale clonato che non è completo.
Un sysop manager può impostare questo canale, ma solo quando viene creato.
Quest'ultimo, inoltre, leggerà il canale come se fosse in modalità SERVICE.




[Pagina 29]




INTERNET-DRAFT IRCX Giugno 1998


8.2. Proprietà

Ogni oggetto di canale contiene un numero di proprietà che possono essere
richieste e opzionalmente aggiornate, tramite il comando IRCX PROP.
Owners e hosts possono aggiornare questa proprietà per il proprio canale.
Sysop Managers e Sysops possono usare il comando PROP su un canale, solo diventando
host/owner di questo. Gli utenti e i membri possono leggere solo le proprietà.

8.2.1. OID (R/O)

La proprietà di canale OID è l'identificatore dell'oggetto interno di un canale.
Come un collegamento, l'OID può essere usato opzionalmente come sostituto della
stringa completa del canale. Se l'OID è settato a "0", significa che questa
opzione non è supportata dal server.

Questa proprietò può essere letta da tutti gli utenti, eccetto da quelli ordinari, quando
il canale è SEGRETO o PRIVATO.

8.2.2. NAME (R/O)

La proprietà di canale NAME è il nome del canale (limitato a
63 caratteri, includendo 1 o 2 caratteri per il prefisso).
I caratteri validi sono gli stessi specificati nell'RFC 1459.

Questa proprietà può essere letta o settata come la proprietà OID.

8.2.3. CREATION (R/O)

La proprietà di canale CREATION corrisponde alla data di creazione del canale,
In secondi, passati dalla mezzanotte (00:00:00), 1 Gennaio, 1970,
(tempo universale coordinato).

Questa proprietà può essere letta o settata come la proprietà OID.

8.2.4. LANGUAGE

La proprietà di canale LANGUAGE è il tipo di linguaggio che si preferisce.
La proprietà LANGUAGE è limitata a 31 caratteri.
Si raccomanda la visione dell'RFC1766[6] per formare la stringa
secondo la sintassi corretta.

Questa proprietà può essere settata e letta dai sysop managers, owners
e hosts del canale. Questa può essere letta dai sysop managers,
sysops e i membri. Può essere letta dall'utente, se il canale è PUBBLICO o NASCOSTO.

8.2.5. OWNERKEY

La proprietà di canale OWNERKEY è la password del proprietario del canale,
che permette a quest'ultimo l'ottenimento dell'accesso Owner, al canale.
La proprietà OWNERKEY è limitata a 31 caratteri.



[Pagina 30]




INTERNET-DRAFT IRCX Giugno 1998


Questa proprietà può essere settata dagli sysop manager o dall'owner di canale.
Questa non può essere letta mai.

8.2.6. HOSTKEY

La proprietà di canale HOSTKEY è la parola chiave dell'host per ottenere lo status
di Host nel canale (ChanOp). La proprietà HOSTKEY è limitata a 31 caratteri.

Questa proprietà può essere letta o settata come la proprietà OWNERKEY.

8.2.7. MEMBERKEY

La proprietà di canale MEMBERKEY è la parola chiave richiesta per entrare in canale.
La proprietà MEMBERKEY è limitata a 31 caratteri.
Questo comando può essere sostituito con il MODE, seguendo i parametri di compilazione
corretti.

Questa proprietà può essere letta o settata come la proprietà OWNERKEY.

8.2.8. PICS

La proprietà di canale PICS è la percentuale corrente dei PICS del canale.
I clients di chat che hanno abilitato i PICS possono usare questa proprietà
per determinare se il canale è appropriato per l'utente.
La proprietà PICS è limitata a 255 caratteri. Il formato del campo è
definito da PICS (see http://www.w3.org).

This proprietà may be set by sysop managers and read by all.
It may not be read by ordinary utentes if the canale is SEGRETO.

8.2.9. TOPIC

La proprietà di canale TOPIC è l'argomento corrente del canale.
Questa proprietà è limitata ad un massimo di 160 caratteri.

Questa proprietà può essere settata e letta dai sysop managers, owners
e hosts del canale. Può essere letta dai sysops e dai membri del canale.
Può essere letta agli utenti se il canale è PUBBLICO o NASCOSTO.

8.2.10. SUBJECT

La proprietà di canale SUBJECT è una stringa che può contenere delle parole
chiave (come oggetto), per i motori di ricerca. La proprietà SUBJECT è limitata
a 31 caratteri.

Questa proprietà può essere settata e letta come la proprietà TOPIC.

8.2.11. CLIENT




[Pagina 31]




INTERNET-DRAFT IRCX Giugno 1998


La proprietà di canale CLIENT contiene un informazione specifica diretta al client.
Il formato non è definito dal server. La proprietà CLIENT è limitata a 255 caratteri.

Questa proprietà può essere settata e letta come la proprietà TOPIC.

8.2.12. ONJOIN

La proprietà di canale ONJOIN contiene una stringa spedita (via
PRIVMSG) ad un utente dopo che l'utente è entrato in un canale.
Il nome del canale è visualizzato come emittente del messaggio.
canale name is displayed as the sender of the message. Solo gli utenti
che entrano in canale vedranno questo messaggio. Linee multiple possono essere
generate inserendo '\n' nella stringa. La proprietà ONJOIN
è limitata a 255 caratteri.

Questa proprietà può essere settata e letta dai sysop managers, owners
e hosts di un canale. Può essere letta anche dagli sysops.

8.2.13. ONPART

La proprietà di canale ONPART contiene una stringa che viene spedita
(via NOTICE) ad un utente dopo che ha lasciato un canale. Il nome del canale
è visualizzato come emittente del messaggio. Solo l'utente usito dal canale
vedrà questo messaggio. Possono essere generate linee multiple, inserendo un '\n' nella stringa.
La proprietà ONPART è limitata a 255 caratteri.

La proprietà può essere settata e letta come la proprietà ONJOIN.

8.2.14. LAG

La proprietà di canale LAG contiene un valore numerico che ha un range numerico
che và da 0 a 2 secondi. Il server aggiungerà un ritardo artificiale a quella lunghezza
tra un messaggio sequenziale proveniente da tutti i membri di canale.
Tutti i messaggi di canale sono coinvolti con tale proprietà.

Questa proprietà può essere settata dai sysop managers e
owners. Può essere addizionalmente letto dagli sysops, hosts, se il canale
membri of the canale. It can be read by utentes if the
canale è PUBBLICO o NASCOSTO.

8.2.15. ACCOUNT

La proprietà di canale ACCOUNT contiene una stringa ad implementazione dipendente
da allegare alla sicurezza dell'account. Questo controlla gli accessi al canale usando
il sistema di sicurezza dell'OS nativo. La proprietà ACCOUNT è limitata a 31 caratteri.

Questa proprietà può essere settata dai sysop managers. Può essere letta solo dai
sysop managers, sysops e owners del canale.

8.2.16. CLIENTGUID

[Pagina 32]




INTERNET-DRAFT IRCX Giugno 1998


La proprietà di canale CLIENTGUID contiene un GUID che definisce il protocollo client
ultilizzato sul canale.

Questa proprietà può essere settata e letta come la proprietà LAG.

8.2.17. SERVICEPATH

La proprietà di canale SERVICEPATH, contiene il percorso esteso da parte del server
che ha effettuato un operazione su un canale. I dettagli sono dipendenti dalle implementazioni.

Questa proprietà può essere settata e letta come la proprietà LAG.

9. IRCX Risposte ai Comandi

Le nuove risposte numeriche all'IRCX seguono lo stesso metodo di quelle standard,
con un range specifico per le risposte del comando e per quelle relative agli errori
risultati. Le risposte dei comandi IRCX vanno dall'800 all'899 e 900 a
999 sono per gli errori.

9.1. Risposte Comandi

800 - IRCRPL_IRCX



Risposta ai comandi IRCX e ISIRCX.
indica se il client ha la modalità IRCX attivata (0 per disabilitato,
1 per abilitato). è la versione del protocollo IRCX
partito da 0. contiene la lista dei pacchetti d'autenticazione supportati
dal server. Il nome pacchetto "ANON" è riservato per indicare che le connessioni
anonime sono permesse. definisce la grandezza massima del messaggio
con il standard 512. contiene una lista di opzioni supportate
dal server; queste sono dipendenti dall'implementazione. Se non ci sono opzioni
disponibili, si userà il carattere '*'.

801 - IRCRPL_ACCESSADD

:

Riposta di successo del comando ACCESS ADD.
è il nome dell'oggetto al quale è imposta la restrizione d'accesso
(i.e. nome canale o nome utente).
è il livello dell'accesso aggiunto (i.e. GRANT, DENY).
è la mask di selezione. Se non viene fornita alcuna mask in input, verrà
usata quella predefinita *!*@*$*.
è l'ammontare di tempo relativo alla permanenza dell'impostazione
settata.
è colui che ha aggiunto il dato alla lista ACCESS.
è il motivo fornito al comando ACCESS ADD.

802 - IRCRPL_ACCESSDELETE


[Pagina 33]




INTERNET-DRAFT IRCX Giugno 1998




Risponde ad un comando ACCESS DELETE riuscito con successo. Vedi la risposta
del RAW 801, per la spiegazione dei campi.

803 - IRCRPL_ACCESSSTART

:Inizio dei dati di accesso

Inizio della lista dei dati d'accesso. è l'oggetto
che viene applicato come restrizione all'accesso (i.e. nome canale o
nome utente). Il prossimo messaggio sarà una risposta IRCRPL_ACCESSLIST o
IRCRPL_ACCESSEND.

804 - IRCRPL_ACCESSLIST

:

Un dato della lista d'accesso. Vedi 801 per ulteriori info a riguardo.

805 - IRCRPL_ACCESSEND

:Fine dei dati d'accesso

Fine della lista dei dati d'accesso. Vedi 803 per ulteriori info riguardo i parametri.
questa risposta è sempre seguita da un IRCRPL_ACCESSSTART o IRCRPL_ACCESSLIST.

806 - IRCRPL_EVENTADD



La risposta di avvenuta conoscenza all'evento legato al comando ADD.
contiene il nome dell'evento aggiunto.
è la mask di selezione. Se non vengono fornite masks nel comando evento, la mask
predefinita usata sarà *!*@*$*.

807 - IRCRPL_EVENTDEL



La risposta di avvenuta conoscenza all'evento legato al comando DELETE.
contiene il nome dell'evento cancellato.
è la mask di selezione. Se non vengono fornite masks nel comando evento, la mask
predefinita usata sarà *!*@*$*.

808 - IRCRPL_EVENTSTART

:Inizio Evento

Risposta all'evento LIST , messaggio che dichiara l'inizio dell'evento list.



[Pagina 34]




INTERNET-DRAFT IRCX Giugno 1998


809 - IRCRPL_EVENTLIST



Risposta all'evento LIST , messaggio che visualizza una lista di tutti gli eventi
che interessano il client.

810 - IRCRPL_EVENTEND

:Fine dell'Evento

Risposta all'evento LIST , messaggio che indica la fine dell'evento list.

811 - IRCRPL_LISTXSTART

:Inizio di ListX

Prima risposta al comando LISTX (lista estesa). Sempre seguito dalle risposte 812, 816 o 817.

812 - IRCRPL_LISTXLIST

:

Oggetti di una lista singola, nella lista estesa dei canali.
Il è il nome del canale nella lista.
specifica le modalità di canale, correntemente settate in questo.
lista i membri correnti nel canale.
ritorna il limite membri presente nel canale specificato.
fornisce il topic del canale.

813 - IRCRPL_LISTXPICS

:

Stringa percentuale dei PICS dell'ultimo canale listato (seguente un messaggio
812).

816 - IRCRPL_LISTXTRUNC

:Trunk di LISTX

Ultima risposta del comando LISTX, questo perchè l'utente ha chiesto
una lista di canali limitata o perchè il server ha bloccato quest'ultima
in modo da prevenire il flood. Questo errore viene sempre accompagnato
con i 811, 812 o 813.

817 - IRCRPL_LISTXEND

:Fine ListX

Ultima risposta al comando LISTX, che indica che la lista è finita.
Sempre segue una risposta del tipo 811, 812 o 813.


[Pagina 35]




INTERNET-DRAFT IRCX Giugno 1998


818 - IRCRPL_PROPLIST

:

Un valore nella lista proprietà. è il nome dell'oggetto
oggetto (i.e., nome canale). è la proprietà nella lista.
è il valore della proprietà listata.

819 - IRCRPL_PROPEND

:Fine delle proprietà

Ultimo messaggio fornito dopo la richiesta della lista di proprietà.

9.2. IRCX Risposte Errori.

900 - Comando IRCERR_BAD

:Comando errato

Risposta ad un comando scorrettamente formattato.

901 - IRCERR_TOOMANYARGUMENTS

:Troppi argomenti

Risposta "troppi argomenti" fornita dal comando.

902 - IRCERR_BADFUNCTION

:Funzione errata

Risposta al comando che supporta la funzione, con una funzione non valida, spedita dall'utente.
Ad esempio, un comando evento supporta una funzione.

903 - Livello IRCERR_BAD

:Livello errato

Risposta ad un comando ACCESS con un livello specificato errato (i.e.
non GRANT, DENY...)

904 - IRCERR_BADTAG

:Tag messaggio errato.

Risposta ad un DATA/REQUEST/REPLY con un messaggio tag errato.

905 - Proprietà IRCERR_BAD

:Proprietà specificata errata



[Pagina 36]




INTERNET-DRAFT IRCX Giugno 1998


Risposta al comando di proprietà di un canale con una proprietà specificata
errata.

906 - Valore IRCERR_BAD

:Valore specificato errato

Risposta di un tentativo di settaggio di una proprietà intera,
ad un valore stringa (comando PROP).

907 - IRCERR_RESOURCE

:Risorse non sufficenti

Il server non ha abbastanza risorse libere per effettuare il comando.

908 - IRCERR_SECURITY

:Nessun permesso per effettuare il comando

Per motivi di sicurezza, il comando/funzione/operazione non è permessa a questo
livello d'accesso del client.

909 - IRCERR_ALREADYAUTHENTICATED

:Già autenticato

Questo utente si è già autenticato al server.

910 - IRCERR_AUTHENTICATIONFAILED

:Autenticazione fallita

L'autenticazione è fallita a causa di un errato UserID/Password o
a causa di un problema di server/network.

911 - IRCERR_AUTHENTICATIONSUSPENDED

:Autenticazione sospesa per questo IP

L'autenticazione è stata temporaneamente disabilitata, a causa del
numero eccessivo di tentativi falliti di autenticazione da questo IP.

912 - IRCERR_UNKNOWNPACKAGE

:Package di autenticazione non supportato

Il package di autenticazione specificato non è conosciuto dal server.
Il comando ISIRCX fornirà la lista di packages d'autenticazione disponibili.

913 - IRCERR_NOACCESS

:Nessun accesso


[Pagina 37]




INTERNET-DRAFT IRCX Giugno 1998


Risposta ad un utente che prova a cambiare l'oggetto dell'access list, ma
non ha sufficienti privilegi per effettuare la modifica.

914 - IRCERR_DUPACCESS

:Dato d'accesso duplicato

Il dato d'accesso già esiste per la mask dell'utente specificata.

915 - IRCERR_MISACCESS

:Dato d'accesso sconosciuto

Risposta al comando ACCESS DELETE quando il server non riconosce il dato da rimuovere.

916 - IRCERR_TOOMANYACCESSES

:Troppi dati d'accesso

Risposta al comando ACCESS ADD quando il massimo numero di dati d'accesso viene raggiunto.

918 - IRCERR_EVENTDUP

:Dato d'evento duplicato

L'utente ha richiesto un evento che è già stato spedito.

919 - IRCERR_EVENTMIS

:Dato evento sconosciuto

Risposta all'evento del comando REMOVE, quando un utente non è ancora pronto per
ricevere l'evento specificato.

920 - IRCERR_NOSUCHEVENT

:Non è presente quel tipo di evento

Risposta all'evento del comando ADD, quando il server non riconosce l'evento
specificato.

921 - IRCERR_TOOMANYEVENTS

:Troppi eventi specificati

Risposta all'evento del comando ADD, quando un utente non può aggiungere altri
eventi da monitorare.

923 - IRCERR_NOWHISPER

:Whisper non permesso



[Pagina 38]




INTERNET-DRAFT IRCX Giugno 1998


Risposta al comando WHISPER, quando il canale non permette la spedizione
di whispers.

924 - IRCERR_NOSUCHOBJECT

:Nessun oggetto trovato

Risposta ad un tentativo di definire una proprietà per un oggetto, che non
può essere trovato (comando PROP).

925 - IRCERR_NOTSUPPORTED

:Oggetto non supportato dal comando

Risposta ai comandi PROP e ACCESS quando un oggetto errato viene specificato
nel comando.

926 - IRCERR_CHANNELEXIST

:Il canale esiste già

Il nome del canale nel comando CREATE esiste già nel server e il mode +c è presente.

927 - IRCERR_ALREADYONCHANNEL

:Già in canale

Risposta al tentativo di join di un utente già presente nel canale impostato come
parametro.

999 - IRCERR_UNKNOWNERROR

:Codice d'errore sconosciuto

L'errore interno generato non figura essere una risposta d'errore IRCX valida.
Il codice d'errore è dipendente dall'implementazione effettuata.

10. Considerazioni sulla Sicurezza

Particolarità sulla sicurezza verranno discusse nella sezione
"autenticazione".

I comandi IRCX e ISIRCX forniscono un set di meccanismi di autenticazione
supportati dal server. Questo metodo è vulnerabile agli attacchi
"middle man" in quanto, è possibile modificare la lista delle autenticazioni
e offre solo una transazione password di ritorno "clear-text".
Per evitare ciò, solo i metodi di autenticazione con un sistema di
risposta a "confronto", dovrebbero essere usati.

Siccome tutti i comandi di amministrazione dell'RFC1459 e IRCX sono
spediti tramite "clear-text", occorre proteggere i dati tramite un sistema
di crypting, quale SSL or IPSEC. Il meccanismo per


[Pagina 39]




INTERNET-DRAFT IRCX Giugno 1998


stabilire queste connessioni non riguardano questo documento.

11. Riconoscimenti

Riconoscimenti specifici sono presenti per le seguenti persone
in quanto hanno provveduto alla modifica della versionee precedente:

Kent Cedola, Lisa Dusseault e Thomas Pfenning

In aggiunta, hanno provveduto alla revisione e ai commenti.
Ci sono molte altre persone che hanno partecipato, ma
per semplicità, abbiamo riportato solo coloro che hanno creato
questo file.

In ordine alfabetico:

Josh Cohen, Alex Hoppman, David Kurlander, Robert Uttecht e
Teoman Smith

12. Riferimenti

[1] "Internet Relay Chat Protocol", Network Working Group RFC
1459, J. Oikarinen, D. Reed, Maggio 1993

[2] The Unicode Consortium, "The Unicode Standard versione
2.0", Addison Wesley Developers Press, Luglio 1996

[3] "INTERNET MESSAGE ACCESS PROTOCOL - versione 4rev1",
Network Working Group RFC 2060, M. Crispin, Dicembre 1996

[4] "Simple Authentication and Security Layer (SASL)", Work
in Progress, draft-myers-auth-sasl-07.txt, J. Myers, Dicembre
1996

[5] "The SSL Protocol versione 3.0", Work in Progress, draft-
ietf-tls-ssl-versione3-00.txt, Alan O. Freier, Philip Karlton,
Paul C. Kocher, Novembre 1996

[6] "Tags for the Identification of Languages", Network
Working Group RFC 1766, H. Alvestrand, Marzo 1995

13. Indirizzi Autori

Dalen Abraham

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

EMail: dalena@microsoft.com



[Pagina 40]


BIS. Traduzione interamente a cura di

Massimiliano Forner (PUOJACKZ)

2003/2004

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.218 sec con 25 queries
Spampoison
Sviluppato con Notepad++
website monitoring service