Sei sulla pagina 1di 7

• Introduzione:

Gli RFC - Request For Comment (richiesta di commento) sono dei documenti
ufficiali (file in ASCII) approvati dall'IETF (Internet Engineering Task Force) che
trattano vari argomenti inerenti Internet; propongono, aggiornano o rendono
obsoleti degli standard, forniscono spunti riflessivi, approfondiscono tematiche,
riportano risultati di ricerche, ecc. A volte sono di carattere tecnico, altre volte sono
descrittive, ma sempre molto utili.

• Approfondimento / esempi rfc:

RFC Editor assegna a ogni RFC un unico numero. Una volta che è stato assegnato
un numero di serie ad un rfc, esso non potrà più essere aggiornato o modificato; se
il documento richiede modifiche, gli autori pubblicano un nuovo documento.
Pertanto, alcuni RFC sostituiscono altri; una volta rinnovati i precedenti rfc sono
considerati deprecati obsoleti. Essi sono quindi esempi tangibili dell’evoluzione
della Rete.

Il processo di produzione RFC differisce dal processo di normalizzazione di norme


formali organizzazioni come ISO, infatti esperti di informatica possono proporre un
rfc, senza l’appoggio di un istituto esterno.
La struttura di un rfc è la seguente:

Xxxx

Titolo. Autori. Data.

(Format: xxxx) (Obsoletes xxxx)

(Obsoleted by xxxx) (Updates xxxx)

(Updated by xxxx) (Also FYI xxxx)

dove xxxx è il numero di una RFC. Il formato è seguito da un segno di uguale e dal
numero di byte. FYI xxxx sta per For Your Information e dà informazioni di
interesse generale, ma che non riguardano lo standard, sono una specie di FAQ.
STD xxxx è un riconoscimento superiore a RFC ed è il vero e proprio standard.
Obsoletes xxxx si riferisce ad altri documenti RFC che sono stati rimpiazzati da
questo; Obsoleted by xxxx è l'esatto contrario. Updates xxxx e Updated by xxxx
riguardano un update e non un rimpiazzo completo. Solo il precedente o seguente
nella catena degli aggiornamenti viene segnalato. Tutte le RFC sono disponibili
online; se non lo sono, viene indicato da (Not Online).

I principali rfc sono:

I. Rfc 114: che definisce il protocollo di trasferimento file fttp

II. Rfc 791: defiisce lo standard ipv4

III. Rfc 793: definisce il prototocollo tcp

IV. Rfc 868: definisce il protocollo del tempo

V. Rfc 937 e 1176: definiscono i protocolli di posta elettronica pop e imap.

VI. Rfc 2026: principale rfc che da le linee guida dello sviluppo degli stessi

A oggi gli rfc pubblicati sono più di 5000, l’elenco completo è pubblicato qui.
• Storia:

Gli rfc sono nati nel 1969, come parte del progetto arpanet. Inizialmente essi erano
distribuiti in copie cartacee tra i ricercatori arpa. Essi erano scritti in modo meno
formale di oggi, assimilabile agli attuali internet draft. Nel dicembre 1969
incominciarono a essere distribuiti tramite la rete arpanet. Da questa data gli rfc
assunsero una sempre maggiore importanza.

• Ciclo di vita:

Inizialmente un documento RFC viene creato come bozza Internet, solitamente


sviluppata da uno o più autori in un gruppo di lavoro IETF. Un gruppo di lavoro
IETF è un gruppo di singoli individui con compiti correlati a una specifica area
tecnologica della suite di protocolli TCP/IP. Il gruppo di lavoro IPv6 si occupa ad
esempio di favorire l'avanzamento degli standard IPv6. Dopo un periodo di
revisione e dopo avere ottenuto il consenso, l'IETF pubblica una versione finale
della bozza Internet assegnando ad essa un numero RFC.

Ai documenti RFC viene inoltre assegnato uno dei cinque livelli di classificazione:

I. Required (Necessario): È necessario provvedere all'implementazione in tutti i


gateway e gli host basati su TCP/IP.

II. Recommended (Consigliato): È consigliabile che le specifiche RFC vengano


implementate in tutti i gateway e gli host basati su TCP/IP. I documenti RFC
consigliati vengono in genere implementati.

III. Elective (Facoltativo): L'implementazione è facoltativa. L'applicazione della


specifica è stata accettata ma il suo utilizzo non si è mai diffuso su vasta
scala.
IV. Limited use (Utilizzo limitato): La specifica non è destinata all'utilizzo su vasta
scala.

V. Not recommended (Non consigliato): Non è consigliata l'implementazione.

Se un documento RFC viene considerato come standard, passa attraverso le fasi


di sviluppo, verifica e accettazione. Per quanto riguarda i processi relativi agi
standard Internet, tali fasi vengono formalmente definite livelli di maturità.

Agli standard Internet viene associato uno dei tre livelli di maturità elencati di
seguito. I livelli di maturità sono determinati dal gruppo di lavoro IETF che si occupa
del documento RFC e non dipendono dai livelli di classificazione.

I. Proposed Standard (Standard proposto): Una specifica di tipo Proposed


Standard è in genere stabile, ha consentito di determinare scelte di
progettazione note, è stata compresa a fondo, è stata sottoposta ad
approfondite analisi e ha suscitato un discreto interesse nella comunità, che
ne indica il valore.

II. Draft Standard (Standard bozza): Una specifica di tipo Draft Standard deve
essere compresa e conosciuta a fondo per raggiungere una certa stabilità,
sia per quanto riguarda la semantica che in qualità di base per lo sviluppo di
un'implementazione.

III. Internet Standard (Standard Internet): Una specifica di tipo Internet Standard,
detta anche semplicemente Standard, è caratterizzata da un alto livello di
maturità tecnica e da un'opinione generale che il protocollo o il servizio
specificato offra vantaggi significativi alla comunità Internet.
Il seguente schema rappresenta il ciclo di vita di una “Request For Comment”:
• Fonti:
 http://rfc.altervista.org/

 http://technet.microsoft.com/it-it/library/bb726991.aspx

 http://en.wikipedia.org/wiki/List_of_RFCs

 http://en.wikipedia.org/wiki/Request_for_Comments

 http://www.ietf.org/rfc.html

 http://digilander.libero.it/unno2/rfc.html