Nonostante Internet abbia assunto le proporzioni che tutti conoscono, al di là delle flessioni o presunte tali che si possono essere verificate negli ultimi anni, il sistema nel suo complesso è regolato tuttora da una forma di anarchia.
Non esiste infatti un comitato ufficiale che si possa definire "a capo" della rete, ma solamente dei nuclei di specialisti che ne analizzano le tendenze e le necessità ed in base a queste studiano soluzioni sempre più efficienti ed evolute.
Sono proprio le IETF, ossia le Internet Engineering Task Force, e le IESG (Internet Engineering Steering Group) che, suddivisi in gruppi di studio per argomento, si occupano dell'evoluzione di differenti aspetti di Internet.

Il tutto avviene con la pubblicazione di Request For Comments (RFC) ossia di documenti che, seguendo diversi percorsi (la proposta di standard prima di tutto, seguita poi dalla bozza di standard, dallo standard definitivo e dall'assegnazione della dicitura "storico" per tutti i documenti superati o inutilizzati), arrivano a definire gli standard di un protocollo, proprio come nel caso di NNTP.
A volte poi i protocolli in possono raggiungere un livello di popolarità e diffusione senza che ne sia stato pubblicato uno standard, ossia senza l'approvazione degli IESG.
In tal caso interviene un terzo gruppo definito come IAB (Internet Architecture Board) che raccomanda il loro adeguamento al processo evolutivo descritto poco sopra.
Com'è possibile conoscere in qualsiasi momento lo stato di evoluzione di un protocollo e parteciparvi attivamente? Prima di tutto sarà necessario scegliere un argomento di studio di proprio interesse (che può essere un protocollo, un particolare ambito in tema di reti e così via), cercandolo in rete o negli archivi specializzati (il più delle volte sono distribuiti sottoforma di semplice file di testo e talvolta in .pdf) oppure facendo richiesta tramite email.
Scrivendo infatti un messaggio all'indirizzo nis-info@nis.nsf.net con un oggetto in bianco e come testo la frase "send rfcnnnn" dove nnnn rappresenta il numero della RFC desiderata, si potrà ricevere nella propria casella di posta il documento desiderato.

Circa dieci anni fa è apparso un modello di comunicazione tra client e server delle news che di fatto definiva per la prima volta in maniera precisa e puntuale le logiche del protocollo NNTP. Dalla comparsa del modello RFC997 il protocollo NNTP è diventato uno degli standard di comunicazione che Internet può vantare.
Arrivato ad un certo livello di popolarità, si è cercato di estendere le potenzialità del Network News Transfer Protocol creando nuovi parametri di comunicazione, fino ad arrivare all'anno 1991, quando addirittura si cercò di revisionare interamente il protocollo. Sfortunatamente l'impresa di creare un nuovo standard non riuscì appieno ma il lavoro svolto lasciò comunque delle tracce che gli anni seguenti si portarono dietro: nacquero infatti dei comandi aggiuntivi ed ulteriori rispetto agli standard RFC997.

Comandi ed estensioni in genere che i più sofisticati newsreader utilizzano comunemente (ma che talvolta non sono altro che piccole deviazioni dai modelli originali definiti dalla RFC997) e che insieme vanno a costituire standard più evoluti come ad esempio l'RFC2980, creato dal gruppo IETF NNTP-EXT (la cosiddetta Internet Engineering Task Force che si occupa delle estensioni del protocollo NNTP) presieduto da Ned Freed e Stan Barber.

Il fatto che l'RFC997 sia però tuttora la maggiore autorità nel definire il protocollo NNTP si comprende proprio dalle note di introduzione della guida RFC2980 (facilmente reperibili in rete in un comodo formato di estensione .TXT), dove viene sottolineato che tutte le estensioni che in qualche modo escono dalla strada tracciata dal modello RFC997 non devono essere considerate come ufficiali e che quindi l'utilizzo indistinto di tali estensioni potrebbe non essere supportato da alcuni server delle news.
La differenza tra i due modelli è facilmente riconducibile a tre nuovi gruppi di estensioni.
Rispetto a quelle definite dalla RFC997 il modello di Newd Freed e Stan Barber presenta in aggiunta le cosiddette "estensioni Transport" che definiscono comandi addizionali atti al trasferimento di articoli da un server all'altro, le "estensioni Newsreader" che forniscono una scelta più ampia di comandi per la selezione ed il download di newsgroups e di articoli dai server delle news.
Infine le cosiddette "Other extensions" rappresentano quei comandi aggiuntivi di utilità varia che non rientrano nei due gruppi sopra elencati.

In conclusione: quale standard adottare per creare un lettore di news? La risposta assoluta non esiste in quanto tutti i server delle news hanno di certo implementato il modello base RFC997 ma il sistema USENET li ha obbligati ad allargare i propri compiti imponendo di adottare determinate estensioni.
Ecco un semplice esempio. Tutti i possessori di Microsoft Outlook Express hanno la possibilità di visionare di ogni singolo articolo non solamente l'oggetto, il mittente e la combinazione data/ora che lo contraddistinguono, ma anche la dimensione del corpo del messaggio (corpo che, come si vedrà successivamente è costituito da una linea di specifiche relative al messaggio racchiuso tra i simboli "<" e ">" , una serie di linee che formano il testo del messaggio più l'eventuale allegato codificato tramite i sistemi UUencode, Base64 e quant'altro).
Dalla lettura delle dimensioni del messaggio può dipendere la scelta di scaricare o meno il messaggio dal server.
Purtroppo però RFC997 consente solamente di determinare il numero di linee di cui il corpo del messaggio si compone.
Il problema viene risolto accostando alle specifiche RFC997 un comando RFC2980 che, in modo simile al corrispondente del modello RFC997 ritorna un'overview del messaggio (cioè la lista delle informazioni generali dell'articolo), che però in questo caso si rivelano molto più dettagliate.
Non è detto che però tutti i comandi avanzati delle RFC successive alla 997 siano stati implementati da tutti i server delle news: il rischio è pertanto quello di richiedere ad un server delle news un operazione alla quale non è stato addestrato correttamente.

Il primo parametro da impostare nello sviluppo di un newsreader è sicuramente il nome server delle news al quale connettersi per poi portare avanti una comunicazione fatta di richieste e di risposte.
Come già visto nei primi capitoli, il server delle news è il contenitore di tutti i newsgroup ossia l'elemento fisico al quale ci si deve riferire per poter ottenere informazioni utili in merito alla lista complessiva dei gruppi, al singolo gruppo, alla lista di tutti gli articoli e, scendendo ancora di più verso il basso al singolo articolo.
Come regola generale la scelta del server delle news dovrebbe essere lasciata all'utente finale: la totalità dei newsreader in commercio prevede infatti come opzione la possibilità di configurare uno o più server tramite semplici caselle di testo o nei casi migliori mediante complessi pannelli di opzioni.
Nell'immagine sottostante viene mostrato l'esempio di Microsoft Outlook Express il quale permette di selezionare più server e di impostare per ciascuno i parametri di connessione e di autenticazione.

Il nome del server può essere indicato tramite il suo indirizzo IP oppure utilizzando il nome per esteso che generalmente presenta il suffisso news seguito da un punto e dal nome che identifica il server:

news.server.it

Essendo un valore imprecisato il nome del server deve essere obbligatoriamente inserito in una variabile. Tale variabile avrà uno scopo globale nel senso che deve poter essere disponibile per la totalità dei moduli di codice di cui il progetto finale sarà costituito.
E' buona regola pertanto creare un modulo .vb (nel caso di Visual Basic .NET) o .bas (nel caso di Visual Basic 6) nel quale selezionare un'area da riservare esclusivamente alla definizione della variabile che andrà a contenere il nome del server. All'interno della stessa area si prevederà poi la definizione delle altre variabili globali quali il time-out ed il numero che identifica la porta di connessione legata al protocollo NNTP. Queste definizioni verranno in ogni caso approfondite nei capitoli che seguono.
Pertanto si andrà ad aggiungere al progetto un nuovo modulo scegliendo dal menu principale la voce Progetto e selezionando l'opzione 'Aggiungi modulo' oppure premendo il pulsante 'Aggiungi' come nel caso mostrato in figura:

VB6	VB.NET

Mentre in VB6 la scelta del modulo sarà unica in VB.NET comparirà una finestra dalla quale poter scegliere il tipo di modulo da includere nel progetto tra i tanti disponibili (Windows Forms, Modulo, modulo di Classe e così via).
In entrambi i casi comunque selezionare Modulo e rinominarlo dal nome originario Module1.bas o Module1.vb in Modulo_Impostazioni.bas o Modulo_Impostazioni.vb proprio come viene mostrato nella figura sottostante, nel caso di Visual Basic .NET:

Una volta accertata la correttezza del nuovo nome del modulo premere il pulsante Apri.
L'ambiente di sviluppo si trasferirà in questo modo sul nuovo modulo di progetto, nel quale in Visual Basic .NET è già stato impostato il codice di apertura e di chiusura che corrisponde al seguente blocco:

Non resta altro a questo punto che aggiungere una nuova variabile definita come Public ossia di scopo esteso a tutti i moduli di codice del progetto, denominandola in modo significativo. Ad esempio: