Glossario Usenet

BBS

Le BBS, a differenza della posta elettronica, consentono di organizzare le informazioni come risorse comuni condivise, in directory che non appartengono al singolo utente. I messaggi arrivano in aree di proprietà del software della bacheca elettronica: molti utenti possono leggere contemporaneamente la stessa copia , come se si trattasse di un giornale comune o di un avviso affisso ad un muro, mediante programmi software progettati per organizzare e leggere i numerosi messaggi. Invece di inviare un messaggio ad una persona, lo si invia, o “affigge”, in un gruppo della BBS.

INTERNET

Nel settore delle reti, il termine tecnico per designare il collegamento di reti è internetworking, mentre per indicare una rete di reti viene impiegato il termine internetwork o internet. La nuova internet work, incentrata su ARPAnet fu soprannominata Internet, con la “I” maiuscola.

TCP/IP

TCP/IP è l’acronimo di (Trasmission Control Protocol/Internetworking Protocol).

ARPA ( Advanced Research Projects Agency), negli anni sessanta, attuò una serie di progetti basati sulla creazione di hardware e software per realizzare una piccola rete sperimentale basata sulla commutazione di pacchetto.

Dal progetto ARPAnet e dal concetto di internetworking (ovvero del collegamento di singole reti in un’entità più grande) si sviluppò un nuovo protocollo di comunicazione che permise l’interconnessione di reti a commutazione di pacchetto eterogenee: il protocollo TCP/IP (Trasmission Control Protocol/Internetworking Protocol).

La commutazione di pacchetto è un metodo di condivisione della linea telefonica tra computer, per cui ogni flusso di dati viene suddiviso in pacchetti. Ogni pacchetto è formato da una porzione di dati e da una sezione denominata intestazione contenente informazioni quali l’indirizzo del mittente e del destinatario, il numero di ID del pacchetto per consentire il riassemblaggio delle porzioni di dati nell’ordine esatto, l’ora della creazione del pacchetto e le informazioni per verificare che il contenuto del pacchetto sia stato trasmesso correttamente.

Il processo di trasmissione di un pacchetto prende il nome di commutazione. I pacchetti vengono commutati attraverso la rete (definita come un insieme di linee e nodi, dove le linee sono i percorsi nei quali scorrono i dati, mentre i nodi sono i punti in cui le linee si intersecano e le risorse, ovvero i dati, vengono trasferiti ad altre linee). Nella rete i pacchetti sono trasferiti da un commutatore di pacchetto (nodo) di una linea al successivo che esamina l’intestazione per decidere a quale linea commutare (o inoltrare) il pacchetto. Con la commutazione di pacchetto molti flussi di dati possono essere inseriti e mescolati su di una linea comune per essere in seguito riordinati nella loro forma originaria all’altra estremità. Grazie alle informazioni contenute in ciascun pacchetto, i pacchetti provenienti da una sorgente possono anche essere trasmessi attraverso percorsi (route) diversi e arrivare tutti a destinazione.

NEWSGROUP

Un gruppo di notizie o Newsgroup può essere diviso in sottogruppi in una sorta di gerarchia. L’assegnazione dei nomi nei Newsgroup di Usenet segue determinate convenzioni: i nomi dei gruppi e dei sottogruppi sono separati da un punto (.). Il nome della parte sinistra indica la gerarchia di massimo livello. Per esempio it.discussioni.auto indica il sottogruppo auto nel gruppo discussioni della gerarchia it (italiano).

RFC

I documenti RFC (Request for Comments) sono le serie ufficiali di documenti che definiscono gli standard e gli altri aspetti di Internet, identificati sovente con un numero di RFC (per esempio: RFC 1822) oltre che con un titolo. Scritte da sviluppatori di spicco di Internet, le Request for Comments vanno dalle specifiche dei protocolli alle proposte, alle analisi, alle specifiche, ai resoconti generali, fino ad argomenti più leggeri come saggi umoristici occasionali o argomenti culturali quali poesie.

RFC 822

L’RFC 822 è un documento che contiene i riferimenti per il formato standard dei messaggi di testo “ARPA Internet”.

ASCII

ASCII è l’acronimo di American Standard Code for Information Interchange, ovvero un sistema di codifica che permette una corrispondenza biunivoca tra i numeri binari ed un insieme di caratteri (alfanumerici e di servizio). Ciò che ne deriva è una tabella su cui viene riportato il numero binario con il corrispondente carattere di riferimento. Nelle tabelle ASCII si usa indicare il valore numerico in formato decimale o esadecimale. La codifica ASCII può essere a 7 bit oppure a 8 bit. Nel primo caso comprende 27=128 caratteri dei quali, quelli fino al valore decimale 31, sono caratteri di controllo non stampabili. Nel secondo caso comprende 28=256 caratteri ovvero i caratteri di controllo, quelli stampabili più gli estesi.

Oltre a quella ASCII esistono altre tabelle codici nate per soddisfare esigenze diverse come quella di gestire un sistema in una lingua diversa dall’inglese.

NEWSGROUP MODERATI

I Newsgroup moderati sono Newsgroup in cui tutti i messaggi sono sottoposti al vaglio di una persona definita il moderatore del gruppo. Il moderatore dovrà decidere della pertinenza di ciascun messaggio all’argomento del Newsgroup.

RFC 1521

L’RFC 1521 decreta lo standard MIME (Multipurpose Internet Mail Extensions).

RFC 1426

L’RFC 1426 decreta l’estensione ad 8 bit del servizio MIME.

CHARSET

Un parametro aggiuntivo, indicato insieme al valore /plain e separato da questo dal carattere “;” è charset, ovvero il set di caratteri adottato per comporre il mesaggio. Un set di caratteri è sostanzialmente una tabella in cui, per ogni carattere è riportato l’equivalente codice binario o esadecimale. La composizione e interpretazione del testo del messaggio avviene ad opera del Local mail user Agent che deve avere a disposizione, nel sistema, la tabella codice. Alcune tabelle codice sono le seguenti:

US-ASCII (ASCII); ISO-88591 (Latina: Europa occidentale); ISO-88592 (Latina: Europa centrale/est). Per una lista esaustiva riferirsi all’RFC 1521 pag. 28.

RFC 1341

L’RFC 1341 decreta lo standard MIME. È stato sostituito dall’RFC 1521. Ma la parte che riguarda il testo richtext è ancora valida.

SGML

SGML è l’acronimo di Standard Generalized Mark-up Language. Un documento in linguaggio SGML contiene due tipi d’informazione: la struttura ed il contenuto. La struttura è determinata da particolari istruzioni sempre in formato testo (Murk-up tags) racchiuse tra parentesi angolari . Il contenuto è rappresentato dal testo racchiuso tra i Murk-up tags. Per struttura si intendono le parti logiche di un documento (Capitoli, sezioni, paragrafi, ecc.) [http://www.techapps.co.uk/iihb_sgml.html]

EDITOR/VIEWER SGML

Sono programmi per comporre o semplicemente visualizzare documenti scritti in SGML. Nell’RFC 1341 (sostituito dall’RFC 1521) (Appendice D) viene proposto un semplice programma in 44 linee per tradurre un testo in “richtext” in “plain text.

RFC 1563

L’RFC 1563 (The text/enriched MIME Content-type) specifica la sintassi del testo formattato “enriched“.

RFC 1866

L’RFC 1866 definisce la sintassi dell’HTML (Hypertext Markup Language, simile all’SGML di cui sopra) nonché il valore “/html” del campo “Content-Type:”

BOUNDARY

Il corpo del messaggio in questo caso è costituito da diverse parti ciascuna delimitata da precisi confini (boundary) espressi sotto forma di caratteri alfanumerici identificativi indicati anche nell’intestazione del messaggio nel campo Content-Type. La voce boundary=”caratteri alfanumerici”, infatti, segue con il carattere “;” la dicitura multipart . Ciascuna parte del corpo del messaggio – incapsulata tra il valore boundary specificato nell’intestazione e preceduto dai caratteri “–” (codice ASCII decimale 45) – contiene a sua volta una intestazione ed un corpo separati da una riga vuota, in maniera simile a quella specificata nell’RFC 822 e nell’RFC 1521. Il valore del boundary preceduto e terminato dai caratteri “–” indica la fine dell’ultima parte in cui è diviso il corpo del messaggio. Il testo contenuto tra i boundary può terminare con una linea vuota (in tal caso trattasi di testo esplicito in formato ASCII. Ciò viene indicato anche nell’intestazione del boundary stesso) oppure no (in questo caso trattasi di testo implicito in formato ASCII e non è necessario indicarlo nell’intestazione del boundary). [Vedere Appendice A per un esempio]

MESSAGE/PARTIAL

Tre parametri sono richiesti nel campo Content-Type (i parametri sono indicati successivamente al valore message/partial e separati da questo e tra loro dal carattere “;”). Il parametro “id” è un identificatore unico usato per riassemblare le parti del messaggio. Il parametro “number” è un numero intero che indica la sequenza delle parti del messaggio da assemblare (la numerazione inizia da 1 e non da 0). Il parametro “total” che indica il numero totale delle parti in cui è stato scomposto il messaggio. [Vedere Appendice A per un esempio]

MESSAGE/EXTERNAL-BODY

Quando il valore del campo “Content-Type: ” è “message/external-body” troviamo dei valori aggiuntivi per alcuni campi atti a descrivere determinate caratteristiche del file esterno che rappresenta il corpo del messaggio. Tali valori, separati tra loro dal carattere “;” , sono i seguenti:

Content-Type: message/external-body;

access-type=

ftp Il corpo del messaggio è accessibile come file usando il protocollo ftp [RFC 959].

name=

Il nome del file che contiene il corpo del messaggio. tftp Il corpo del messaggio è accessibile tramite file usando il protocollo tftp [RFC 783].

site=

Nome del dominio della macchina o delle macchine che contengono il file anon-ftp accesso ftp anonimo: non sono richiesti nome e password .

directory=

La directory dalla quale il file è disponibile (campo disponibile solo per l’ftp e l’tftp access-type) local-file Il file è accessibile nella macchina locale come file.

mode=

La modalità di ricezione del file (campo disponibile solo per l’ftp e l’tftp access-type). Riferirsi all’RFC 959 e RFC 783 per le specifiche. afs Il file è accessibile tramite l’AFS file system

server=

L’indirizzo email del server che contiene il file (campo disponibile solo per il mail server access-type ) mail-server Il file è accessibile tramite un mail-server.

subject=

L’oggetto della mail spedita per ottenere i dati (campo disponibile solo per il mail server access-type ) expiration Data oltre la quale il file potrebbe non essere più disponibile. L’RFC 1123 estende le possibilità dell’RFC 822 in termini di numeri per la data: permette 4 digit per l’anno.

size=

La lunghezza del file

permission=

Indica se l’utente può accedere al file o solo in lettura (read), oppure in lettura/scrittura (read-write).

Nota: alla fine dei valori spiegati appena sopra, trova posto, separata da due linee vuote, l’intestazione del corpo incapsulato nel file. Nel senso che il corpo disponibile nel file ha un’intestazione che viene riportata nel messaggio d’origine. [Vedere Appendice A per un esempio]

OCTET-STREAM

Il valore octet-stream può avere i seguenti parametri indicati in successione e separati dal carattere “;”:

type: tipo o categoria del dato.

padding: numero di bit di “riempimento” usati laddove i bit totali dai dati inclusi nel corpo non sono multipli di un byte.

name: parametro introdotto già dall’RFC 1341 suggerisce il nome del file quando appunto i dati vengono salvati in un file.

RFC 1740

L’RFC 1740 (MIME Encapsulation of Macintosh files – MacMIME) decreta lo standard per l’incapsulazione dei file Apple Macintosh.

RFC 2387

L’RFC 2387 (The MIME Multipart/Related Content-type) decreta le specifiche per un nuovo valore del campo “Content-Type: ” .

PEM

PEM sta per privacy-enhanced mail. I dettagli del servizio PEM sono contenuti nell’RFC 1421, 1422, 1423, 1424.

PGP

PGP sta per Pretty Good Privacy. I dettagli del formato PGP sono contenuti nell’RFC 1991, 2015 e 1847.

SIMMETRICO

Con il sistema a chiave simmetrica, un messaggio è crittato e decrittato usando la stessa chiave ; questa deve essere conosciuta sia dal mittente che dal ricevente. La chiave passa dall’uno all’altro, attraverso una transazione separata, ma il sistema è vulnerabile perchè essa può venir rubata nel momento in cui attraversa la rete.

ASIMMETRICO

PGP utilizza una tecnica di criptazione basata su chiavi pubbliche asimmetriche, che prevede la presenza di due chiavi: una pubblica, che l’autore può mettere a disposizione di chiunque inviandola a un apposito server Web e una privata, conservata solo dall’utente e protetta da un codice di accesso personale. Per trasmettere un messaggio in forma protetta è anzitutto necessario che il mittente scarichi dal server Web la chiave pubblica del destinatario e cripti con questa il documento; il destinatario potrà a questo punto decriptare la comunicazione ricevuta tramite la propria chiave privata, utilizzando il codice di accesso personale. Chiaramente è virtualmente impossibile risalire dalla chiave pubblica a quella privata, poiché gli algoritmi di criptazione utilizzati hanno raggiunto livelli di sicurezza paragonabili a quelli impiegati in campo militare, impedendo qualsiasi tentativo di decifrazione operato tramite sistemi di analisi matematica.

Per firmare elettronicamente un messaggio PGP utilizza invece un metodo inverso a quello impiegato per la criptazione e cioè adopera la chiave privata (ed il relativo codice di accesso) per apporre la firma e quella pubblica per verificare la conformità del messaggio con l’impronta generata durante la sigla.

MESSAGGIO CRIPTATO PGP

Un messaggio criptato è formato da due parti: la prima costituita da una informazione di controllo indicante la versione dell’ application/pgp-encrypted, la seconda contenente i dati criptati avente “application/octet-stream” come valore del Content-Type nell’intestazione. Ogni parte è ovviamente racchiusa tra i boundary. [Vedere l’appendice A per un esempio]

MESSAGGIO FIRMATO PGP

Un messaggio firmato è costituito da due parti: la prima contenente i dati in formato MIME, la seconda contenente la firma con “ application/pgp-signature” come valore del campo Content-Type. [Vedere l’appendice A per un esempio]

QUOTING

Dall’inglese to quote: citare

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...