Rfc
Contents
Titolo
RFC (Request For Comments)
Autore
Steve Crocker
Anno
1969 d.c.
Luogo
Usa
Descrizione
Steve Crocker, del gruppo di ricerca di Leonard Kleinrock all'UCLA, scrive il Request For Comments (RFC) numero l, un documento nel quale si descrivono i "protocolli" di connessione tra due computer. I documenti RFC sono proposte di innovazioni tecniche, "richieste di commenti" aperte a tutti nella rete. Lo stile aperto dei RFC viene immediatamente apprezzato da tutte le università e si crea un clima di intensa cooperazione che si riflette in quello del Network Working Group (NWG) che farà costante uso degli RFC (Gubitosa, 1998)
Una RFC, request for Comment, è un documento che viene pubblicato. Esso riguarda ogni standard della suite di protocolli TCP/IP, riporta informazioni o specifiche riguardanti nuove ricerche, innovazioni e metolodologie dell’ambito informatico o più nello specifico di internet. Le RFC sono mantenute dalla IAB (Intenet Architexture Board) e pubblicate con lo scopo di far conoscere, studiare e migliorare le specifiche riguardanti il TCP/IP. Sebbene gli standard TCP/IP vengano pubblicati sotto forma di RFC queste ultime non rappresentano tutte degli standard; a volte si tratta di specifiche in corso di studio o di test che possono diventare standard o essere scartate. Attraverso l’Internet society gli ingegneri o gli esperti informatici, possono pubblicare sottoforma di RfC dei memorandum, per esporre sia nuove idee sia alcune informazioni che non appena vengono vagliati dall’IETF (Internet Engineering Task Force) oppure dall’ IRTF (Internet Research Task Force) possono diventare degli standard internet. La storia di queste “richieste” risale al 1969, quando furono pubblicate come parte del progetto ARPANET, il manutentore e responsabile della loro edizione e del loro ciclo di vita è l’RFC Editor.furono scritte da Steve Crocker, del gruppo di ricerca di Leonard Kleinrock all'UCLA.
Classificazione
Dopo esser esaminata una RFC viene classificata:
- required: obbligatorio implementare su tutti gli host ed i gateway TCP/IP;
- recommended: non sono obbligatorie ma è raccomandato implementarle su ogni host e gateway;
- elective: non è obbligatorio implementarla anche se è completamente definita;
- limited use: non è destinata ad un impiego generale;
- not recomended: si consiglia di non implementarla.
Percorso.
I documenti in procinto di diventare standard evolvono secondo i seguenti passi di “maturazione”: +Proposed Standard: protocolli destinati a diventare standard previo processo e sperimentazione ulteriore; specifica sufficientemente stabile che ha ricevuto un sufficiente feedback dagli sviluppatori e ha un certo interesse nella comunità internet tuttavia ritebuta ancora immatura dagli implementa tori;
- Draft Standard: implementazione base per lo sviluppo dello standard finale, in questa fase sono richiesti soprattutto test e commenti; richiede la presenza di almeno due implementazioni che hanno dimostrato la loro interoperabilità indica che l'IESG (Internet Engineering Steering Group) ritiene lo standard sufficientemente maturo;
- Standard: richiede la presenza di un numero di implementazioni significativo e una notevole esperienza dimostrata dagli utenti su questo standard, gli viene assegnato un numero progressivo nella lista degli standard (STD).
I documenti che non sono ritenuti adatti ad essere Internet Standards vengono etichettati come:
- Experimental protocol: protocolli non destinati ad un utilizzo operativo ma destinati alla sperimentazione, ossia un documento relativo a qualcosa ancora in fase di ricerca, viene pubblicato a titolo informativo senza che ci sia la pretesa di farlo diventare standard a breve. Può essere l’output di un gruppo di lavoro Internet o un contributo individuale;
- Information protocol: protocolli sviluppati da rivenditori o organizzazioni autorevoli al di fuori degli organi ufficiali Intenet, cioè un documento di tipo informativo su un determinato argomento che può non disporre di un particolare consenso da parte della comunità Internet e non rappresenta una raccomandazione di sorta.
- Historic protocol: protocolli abbandonati o omai divenuti obsoleti che difficilmente diverranno standard, rimpiazzati da nuove specifiche.
- Best Common Practice (BCP): documenti che suggeriscono alcuni modi di comportamento/configurazione che non sono standard ma consigliati. Deve esistere consenso anche in questo caso, ma il processo di approvazione è più veloce
Ogni RFC pubblicata riceve un numero di documento, in caso di aggiornamento verrà pubblicata una nuova RFC alla quale verrà assegnato anche un nuovo numero identificativo. I documenti RFC sono proposte di innovazioni tecniche, "richieste di commenti" aperte a tutti nella rete. Lo stile aperto dei RFC viene immediatamente apprezzato da tutte le università e si crea un clima di intensa cooperazione che si riflette in quello del Network Working Group (NWG) che farà costante uso degli RFC (Gubitosa, 1998)
webliografia
IETF (Internet engineering Task Force): http://ietf.org;
The Internet Standard process (RFC2026): http://rfc-editor.org;
RFC Project: http://rfc.altervista.org;
Nic.it RFC database (FTP): ftp://ftp.nic.it/rfc.
