Quando il concetto di rete era agli albori e Internet era ancora molto in là a venire, nel 1969 era stata realizzata la prima rudimentale rete ARPANET che collegava fra loro quattro computer situati in California e nel vicino Utah. Steve Crocker, un ingegnere che allora lavorava alla UCLA (University of California, Los Angeles), si occupava dello sviluppo di software per gli enormi computer mainframe di rete dell'epoca. Volendo sollecitare consigli e opinioni da parte degli altri ingegneri impegnati sul progetto, egli scrisse un memorandum intitolato semplicemente "Host Software".

Allo scopo di tenere traccia dei successivi sviluppi e aggiornamenti del documento, un po' alla maniera con cui i programmatori tengono traccia delle diverse versioni e modifiche di un software, egli denominò il suo documento Request For Comment e la numerò con il numero 1. Questo tipo di memorandum, più comunemente noto col suo acronimo RFC, divenne in breve il metodo con il quale gli sviluppatori discutevano nuove proposte e progetti.

Le RFC si dimostrarono un utile e conveniente metodo per documentare e diffondere il lavoro dei ricercatori e finì per diventare una sorta di registro ufficiale delle scelte progettuali e architetturali e degli standard tecnici di Internet.

Oggi le RFC vengono emanate dalla Internet Engineering Task Force (IETF) and the Internet Society (Isoc), due organizzazioni che si occupano appunto, fra le altre cose, della stesura degli standard relativi a Internet (anche se in teoria chiunque può proporre la propria RFC e sottoporla alle precedenti organizzazioni). Sebbene le RFC abbiano mantenuto il nome originario (letteralmente "richiesta di commenti"), esse si sono trasformate col tempo in documenti strutturati e organizzati, contenenti molti dettagli tecnici e implementativi. Dopo la loro pubblicazione le RFC non vengono più modificate (si dice che sono statiche), ma, se occorrono aggiornamenti, vengono emanate delle nuove RFC che vanno a sostituire quelle ormai obsolete.

Il sito ufficiale RFC-Editor tiene memoria di tutte le RFC pubblicate (attualmente sono oltre 7000) e contiene un comodo motore di ricerca.

Non tutte le RFC costituiscono degli standard. I documenti in procinto di diventare standard evolvono secondo i seguenti passi:

• Proposed Standard: specifica sufficientemente stabile (cioè non soggetta a troppe revisioni), che ha ricevuto un sufficiente feedback dagli sviluppatori e ha suscitato un certo interesse nella comunità; tuttavia questa specifica non è ancora ritenuta sufficientemente matura;
  
  
• Draft Standard: indica una specifica stabile, ben conosciuta e applicata, in procinto di diventare uno standard a tutti gli effetti.
  
  
• Standard: richiede la presenza di un numero di implementazioni significativo e una notevole esperienza dimostrata dagli utenti su questo standard; si tratta di uno standard a tutti gli effetti (gli viene assegnato un numero progressivo nella lista degli standard, STD). 

I documenti che non sono ritenuti adatti ad essere Internet Standard vengono etichettati come:

• Experimental: documento relativo a qualcosa ancora in fase di ricerca; viene pubblicata 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 (sia IETF che IRTF), oppure un contributo individuale;
  
  
•  Informational: documento di tipo informativo su un determinato argomento; può non disporre di un particolare consenso nella comunità Internet e non rappresenta una raccomandazione di sorta;
  
  
• Historic: standard che sono ormai completamente rimpiazzati da nuove specifiche oppure sono caduti in disuso;
  
  
• 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

Per capire come è fatta in pratica una RFC la cosa migliore da fare è esaminarne brevemente una. Sul già citato sito RFC-Editor si possono facilmente reperire tutte le RFC. La tabella seguente cita le principali RFC relative ai protocolli più importanti:

Ogni RFC è un documento di testo (txt) strutturato in un ordine preciso. Qui sotto per esempio viene riportata integralmente la RFC 768 relativa all'UDP, uno dei protocolli più semplici:

Si note l'indicazione dell'autore della RFC e la data di creazione all'inizio del documento. Segue una breve introduzione nella quale sono indicati gli scopi e le funzioni del protocollo.

Segue la specifica del formato del datagram UDP col significato di ciascuno dei campi e la definizione dell'interfaccia col livello superiore (User Interface) e con quello inferiore (IP Interface).

Alcune RFC sono state create per scherzo e non sono destinate ovviamente a divenire standard. Per esempio la RFC 1149 descrive un metodo sperimentale per la consegna dei pacchetti IPv4 per mezzo di piccioni viaggiatori. Di solito queste RFC vengono pubblicate il primo di aprile di ogni anno. Qui potete leggere l'inizio della RFC 1149:

Network Working Group                                        D. Waitzman
Request for Comments: 1149                                       BBN STC
                                                            1 April 1990

   A Standard for the Transmission of IP Datagrams on Avian Carriers

Status of this Memo

   This memo describes an experimental method for the encapsulation of
   IP datagrams in avian carriers.  This specification is primarily
   useful in Metropolitan Area Networks.  This is an experimental, not
   recommended standard.  Distribution of this memo is unlimited.

Overview and Rational

   Avian carriers can provide high delay, low throughput, and low
   altitude service.  The connection topology is limited to a single
   point-to-point path for each carrier, used with standard carriers,
   but many carriers can be used without significant interference with
   each other, outside of early spring.  This is because of the 3D ether
   space available to the carriers, in contrast to the 1D ether used by
   IEEE802.3.  The carriers have an intrinsic collision avoidance
   system, which increases availability.  Unlike some network
   technologies, such as packet radio, communication is not limited to
   line-of-sight distance.  Connection oriented service is available in
   some cities, usually based upon a central hub topology.

Frame Format

   The IP datagram is printed, on a small scroll of paper, in
   hexadecimal, with each octet separated by whitestuff and blackstuff.
   The scroll of paper is wrapped around one leg of the avian carrier.
   A band of duct tape is used to secure the datagram's edges.  The
   bandwidth is limited to the leg length.  The MTU is variable, and
   paradoxically, generally increases with increased carrier age.  A
   typical MTU is 256 milligrams.  Some datagram padding may be needed.

   Upon receipt, the duct tape is removed and the paper copy of the
   datagram is optically scanned into a electronically transmittable
   form.

Si noti come, anche nelle RTF scherzose, sia mantenuto lo stesso rigoroso formato di quelle serie.

precedente - successiva

Sito realizzato in base al template offerto da

http://www.graphixmania.it

Segui @ElePrograMania