💾 Archived View for it.gemini-site.omarpolo.com › docs › it › specification.gmi captured on 2022-01-08 at 13:51:57. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
v0.14.3, 29 novembre 2020
È una bozza via via meno imprecisa di un'attuale specifica per il Progetto Gemini. Nonostante non sia ancora finalizzata, futuri cambiamenti saranno relativamente piccoli. È possibile scrivere codice seguendo questa pseudo-specifica ed essere confidenti che probabilmente non diventerà completamente non-funzionale per via di massivi cambiamenti la prossima settimana, ma rimane comunque la necessità di tener d'occhio l'avanzare dello sviluppo del protocollo e fare cambiamenti come richiesto.
Questo documento è fornito in modo che le persone possano stare al passo con quello che sto pensando senza dover leggere svariati phlog e tenere note.
Commenti su una qualsiasi parte sono estremamente benvenuti, per favore scrivere a solderpunk@posteo.net.
Gemini è un protocollo client-server con transazioni richiesta-risposta, grossomodo simile a gopher o HTTP. Le connessioni vengono chiuse alla fine di ogni transazione e non possono essere riutilizzate. Quando Gemini viene servito via TCP/IP, i server dovrebbero rimanere in ascolto sulla porta 1965 (la prima missione Gemini con equipaggio umano, la Gemini 3, volò nel marzo del '65). Questa è una porta non privilegiata, quindi è molto semplice far girare un server come utente "nobody" anche se, ad esempio, il server è scritto in Go e non puo' abbassare i privilegi nel modo tradizionale.
C'è un solo tipo di transazione Gemini, circa equivalente a una richiesta gopher od a una richista "GET" HTTP. Le transazioni avvengono nel seguente modo:
C: Apre una connessione
S: Accetta la connessione
C/S: Completano l'handshake TLS (vedi sezione 4)
C: Valida il certificato del server (vedi 4.2)
C: Invia una richiesta (una linea terminata con CRLF) (vedi sezione 2)
S: Invia l'intestazione della risposta (una riga terminata con CRLF), chiude la connessione in una situazione di mancato successo (vedi 3.1 e 3.2)
S: Invia il corpo della risposta (testo o dati binari) (vedi 3.3)
S: Chiude la connessione
C: Gestisce la risposta (vedi 3.4)
Le risorse disponibili attraverso Gemini sono indentificate usando URI con lo schema "gemini". Questo schema è sintatticamente compatibile con la sintassi generica definita nell'RFC 3986, ma non sono supportati tutti i componenti. In particolare, il componente "authority" è permesso nonché richiesto, ma il suo sottocomponente "userinfo" NON È ammesso. Il sottocomponente "host" è richiesto. Il sottocomponente "port" è opzionale con valore di default 1965. Le componenti "path", "query" e "fragment" sono permesse e non hanno alcun significato speciale oltre a quello definito dalla sintassi generica. Spazi negli URI Gemini dovrebbero essere codificati con %20, non +.
Le richieste Gemini sono formate da una singola linea terminata con CRLF seguendo la seguente struttura:
<URL><CR><LF>
<URL> è un URL assoluto, con tanto di schema, codificato in UTF-8 di lunghezza massima 1024 byte.
Inviare un URL assoluto invece di solo un path o un selettore è effettivamente equivalente ad includere un header "Host" in HTTP. Permette il virtual hosting di multipli domini Gemini sullo stesso indirizzo IP. Permette anche ai server di agire opzionalmente come proxy. Includere uno schema diverso da "gemini" permette ai server di agire opzionalmente come gateway traduttori di protocolli, ad esempio, per scaricare risorse gopher attraverso Gemini. Fare da proxy è opzionale e ci si aspetta che la vasta maggioranza dei server risponda solo alle richieste disponibili ai loro domini.
Le risposte Gemini consistono di una singola linea d'intestazione terminata con CRLF opzionalmente seguita dal corpo della risposta.
Le intestazioni Gemini hanno il seguente formato
<STATUS><SPAZIO><META><CR><LF>
<STATUS> è un codice di stato numerico di due cifre come descritto in seguito nella sezione 3.2 e nell'Appendice 1.
<SPAZIO> è un singolo carattere di spaziatura, ovvero il byte 0x20.
<META> è una stringa UTF-8 di lunghezza massima 1024 byte, il quale significato dipende dallo <STATUS>.
<STATUS> e <META> sono separati da un singolo carattere di spazio.
Se <STATUS> non appartiene all'insieme di codici di "SUCCESSO", allora il server DEVE chiudere la connessione dopo aver mandato l'intestazione e NON inviare un corpo della risposta.
Se un server invia uno <STATUS> che non è di due cifre o un <META> che supera i 1024 byte in lunghezza, il client DOVREBBE chiudere la connessione e ignorare l'intestazione della risposta, informando l'utente dell'errore.
Gemini usa un sistema di codici di stato a due cifre. Codici di risposta correlati hanno la stessa cifra iniziale. È Importante notare come, a differenza di HTTP, la prima cifra non li raggruppi in vaghe categorie come "Errore del client" od "Errore del server". La prima cifra da sola invece fornisce abbastanza informazioni ai client per determinare come gestirla. Per design, è possibile scrivere un client semplice ma completo che controlli solo la prima cifra. La seconda server per fornire un'informazione più dettagliata per chiarire i log del server, oppure per creare comode interfacce interattive per client con UI semplificate, ma anche per scrivere client automatici più robusti ed intelligenti per aggregatori di contenuti, crawler dei motori di ricerca ecc.
La prima cifra del codice di risposta la colloca in una delle seguenti sei categorie, che definiscono la semantica per la linea <META>.
Codici di stato che iniziano con 1 indicano una condizione di INPUT e significano che:
La risorsa richiesta accetta una linea testuale di input dall'utente. Il <META> è il prompt che dovrebbe essere mostrato all'utente. La stessa risorsa dovrebbe quindi essere richiesta di nuovo con l'input dell'utente incluso come componente query. Le "query" sono incluse nella richiesta secondo la solita definizione generica di URL presente nell'RFC3986, ovvero separata dal path da un ?. I caratteri riservati nell'input dell'utente devono essere "codificate in percentuale" (ndt. "percent-encoded" in inglese) come stabilito dall'RFC3986, e anche i caratteri di spazio dovrebbero essere codificati in tal modo.
Codici di stato che iniziano con 2 indicano una condizione di SUCCESSO e significano che:
La richiesta è stata gestita con successo e il corpo della risposta segue l'intestazione. La linea <META> indica il tipo MIME che si applica al corpo della risposta.
Codici di stato che iniziano con 3 indicano una condizione di REDIRECT e significano che:
Il server sta reindirizzando il client a un nuovo indirizzo per la risorsa richiesta. <META> è il nuovo URL per la risorsa richiesta. L'URL può essere tanto assoluto quanto relativo. Il reindirizzamento dovrebbero essere considerato temporaneo, ovvero i client dovrebbero continuare a richiedere la risorsa all'indirizzo originale e non effettuare azioni di convenienza per le prestazioni come aggiornare i segnalibri automaticamente. Non c'è alcun corpo della risposta.
Codici di stato che iniziano con 4 indicano una condizione di FALLIMENTO TEMPORANEO e significano che:
La richiesta è fallita. Non c'è un corpo della risposta. La natura del fallimento è temporanea, quindi una richiesta identica POTREBBE avere successo in futuro. Il contenuto del <META> fornisce informazioni aggiuntive sul fallimento, e dovrebbe essere mostrata agli utenti umani.
Codici di stato che iniziano con 5 indicano una condizione di FALLIMENTO PERMANENTE e significano che:
La richiesta è fallita. Non c'è corpo della risposta. La natura del fallimento è permanente quindi una richiesta identica in futuro sicuramente fallirà per lo stesso motivo. Il contenuto del <META> può fornire informazioni aggiuntive sul fallimento e dovrebbe essere mostrata ad utenti umani. Client automatici come aggregatori o crawler non dovrebbero ripetere la richiesta.
Codici di stato che iniziano con 6 indicano una condizione di RICHIESTA DEL CERTIFICATO CLIENT e significano che:
Per accedere alla risorsa richiesta è necessario un certificato client. Se la richiesta è stata fatta senza un certificato, dovrebbe essere rifatta con uno. Se la richiesta è stata fatta con un certificato, il server non l'ha accettato e un'altra richiesta dovrebbe essere fatta con un altro certificato. Il contenuto del <META> (e lo specifico codice 6x) possono fornire informazioni aggiuntive sui requisiti del certificato o sul motivo per il quale è stato rifiutato.
Per semplici client interattivi ad uso umano, le classi di errore 4 e 5 possono essere effettivamente gestite allo stesso modo: mostrando semplicemente il contenuto del <META> sotto l'intestazione "ERRORE". La distinzione tra errori permanenti e temporanei riguarda principalmente client automatici dal buon comportamento. Client basilari possono anche scegliere di non supportare l'autenticazione tramite certificati utente e, in tal caso, solo quattro routine di gestione dello stato diverse sono necessarie (per gli stati che iniziano con 1, 2, 3 o col composto 4-o-5).
Il sistema a due cifre completo è dettagliato nell'Appendice 1. Si noti che per ognuna delle prime sei cifre valide uno zero come seconda corrisponde allo stato generico per quel tipo senza nessuna semantica specifica. Ciò significa che semplici server senza funzionalità avanzate necessitano solo di poter ritornare 10, 20, 30, 40 o 50 come codici.
Il sistema di codici di stato di Gemini è stato attentamente progettato in modo che l'aumento di potere (e corrispondentemente l'aumento di complessità) della seconda cifra sia completamente facoltativa sia lato server che lato client.
I corpi della risposta sono solo contenuti grezzi, testo o binari, come su gopher. Non c'è supporto per compressione, chunking or altri sistemi di contenuto o codifiche di trasferimento. Il server chiude la connessione dopo il byte finale: non c'è un segnale "fine della risposta" come il "punto solitario" di gopher.
I corpi della risposta sono presenti solo nelle risposte la cui intestazione indichi lo stato di SUCCESSO (ovvero uno stato la cui prima cifra sia 2). Per quest'ultime, <META> è il tipo MIME come definito dall'RFC 2046.
I tipi di media internet sono registrati con una forma canonica. Il contenuto trasferito via Gemini DEVE essere rappresentato nella sua forma canonica prima della sua trasmissione, eccezion fatta per i tipi "text", come definiti nel prossimo paragrafo.
Quando presenti nella forma canonica, i sottotipi media del tipo "text" (testo). Gemini rilassa questo requisito e permette il trasporto di media di testo con soli LF (ma NON solo CR) come carattere di fine linea quando ciò viene fatto in modo consistente per tutto il corpo della risposta. I client Gemini DEVONO accettare CRLF e soli LF come rappresentativi di fine linea nei media di testo ricevuti via Gemini.
Se il tipo MIME inizia con "text/" e nessun charset viene fornito esplicitamente, deve essere assunto essere UTF-8. Client adempienti DEVONO supportare risposte text/* codificate in UTF-8. I client POSSONO opzionalmente supportare anche altre codifiche. Quando un client riceve una risposta con un charset che non è in grado di decodificare DOVREBBE gentilmente informare l'utente di cosa è successo invece di mostrare spazzatura.
Se <META> è una stringa vuota, il tipo MIME DEVE essere assunto come "text/gemini; charset=utf-8". Il media type text/gemini è definito nella sezione 5.
La gestione della risposta dovrebbe essere guidata dall'informazione fornita sul suo tipo MIME. Gemini definisce un proprio tipo MIME (text/gemini) la cui gestione è discussa in seguito nella sezione 5. In tutti gli altri casi, i client dovrebbero fare "qualcosa di sensato" in base al tipo MIME. Client minimali possono adottare la strategia di stampare tutti le altre risposte di tipo text/* a monitor senza formattazione e salvando tutte le risposte non testuali sul disco. Client per i sistemi UNIX possono consultare /etc/mailcap per trovare altri programmi in grado di gestire tipi non testuali.
L'uso di TLS per le transazioni Gemini è obbligatorio.
L'uso dell'estensione TLS "Server Name Indication" (SNI -- Indicazione del nome del server) è anch'essa obbligatoria, per facilitare il virtual hosting basato sui nomi di dominio.
I server DEVONO utilizzare la versione 1.2 o superiore di TLS e DOVREBBERO usare 1.3 o superiori. TLS 1.2 è temporaneamente ammessa per evitare di ridurre drasticamente la quantità di librerie che l'implementano. Si spera che TLS 1.3 o superiori possa diventare parte della specifica nel vicino futuro. I client che desiderano essere "un passo avanti" POSSONO rifiutarsi di collegarsi a server che usano la versione 1.2 o inferiori.
I client possono verificare le connessioni TLS come preferiscono (anche non fare nulla è permesso) ma l'approccio fortemente RACCOMANDATO è di implementare un semplice sistema di selezione dei certificati "TOFU" che consideri certificati autofirmati come cittadini di prima classe. Questo riduce enormemente il peso di TLS sulla rete (solo un certificato dev'essere inviato, non tutta la catena) e abbassa la barriera d'entrata per mettere su un sito Gemini (non c'è bisogno di pagare una CA o configurare un cron job per Let's Encrypt, basta creare un certificato per partire)
TOFU è un acronimo che sta per "Trust On First Use" ("Fiducia sul primo utilizzo") ed è un sistema di sicurezza a chiave pubblica simile a quello usato da OpenSSH. La prima volta che un client Gemini si collega ad un server accetta qualunque certificato gli venga presentato. Il fingerprint del certificato e la sua data di scadenza vengono salvati in un database persistente (come il file .known_hosts per SSH), associati con il nome del server. Su tutte le future connessioni per quell'hostname, il fingerprint del certificato ricevuto viene confrontato con quello salvato nel database. Se il certificato non è quello ricevuto precedentemente, ma la data di scadenza del precedente non è ancora passata, all'utente viene mostrato un messaggio, simile a quello che gli utenti dei browser Web vedono quando ricevono un certificato senza una catena di firme che porta ad una CA fidata.
Questo modello non è decisamente perfetto, ma non è terribile ed è di gran lunga superiore all'accettare certificati autofirmati incondizionatamente.
Nonostante siano raramente visti sul web, TLS permette agli utenti di identificarsi presso un server usando dei certificati, in modo del tutto analogo a come i server tradizionalmente si identificano ai client. Gemini include la possibilità per i server di richiedere che un client ripeta una richiesta con un certificato. È una nozione molto flessibile, altamente sicura nonché semplice di identità dell'utente con diverse applicazioni:
Le richieste Gemini saranno fatte tipicamente senza certificati utente. Se una risorsa richiesta richiede un certificato e tale non è stato incluso nella richiesta, il server può rispondere con un codice di stato 60, 61 o 62 (vedi Appendice 1 per una descrizione di tutti i codici riguardanti i certificati utente). Un certificato client che è stato generato o caricato in risposta ad uno di quei codici di stato è legato a quello stesso hostname dell'URL richiesto e di tutti i percorsi al di sotto di quello richiesto. Ad esempio, se la richiesta per gemini://example.com/foo ritorna uno status 60 e l'utente sceglie di generare un nuovo certificato, quello stesso certificato dovrebbe essere usato per le seguenti richieste a gemini://example.com/foo, gemini://example.com/foo/bar, gemini://example.com/foo/bar/baz ecc, fino a che l'utente non decide di cancellare il certificato o disattivarlo temporaneamente. Client interattivi per utenti umani sono quindi fortemente raccomandati di rendere tali azioni facili e dare il controllo totale all'utente sull'uso dei certificati.
Analogamente all'HTML, che viene considerato il formato "nativo" delle risposte HTTP, e al formato testo semplice che è considerato il formato nativo di gopher, Gemini definisce il proprio formato di risposta nativo sebbene, naturalmente, grazie all'inclusione del tipo MIME nell'intestazione della risposta, Gemini può essere usato per servire testo semplice, testo arricchito, HTML, Markdown, LaTeX, eccetera.
Il corpo della riposta di tipo "text/gemini" è costituito da un sistema di ipertesti piuttosto semplice, che trae ispirazione dalle mappe gopher e da Markdown. Il formato permette una formattazione tipografica più ricca rispetto al testo semplice di gopher, tuttavia rimane comunque semplice da interpretare (sia dalle macchine tramite parsing, che dagli esseri umani ndt.). Il formato è orientato alla linea e un sistema di resa del testo soddisfacente può essere ottenuto in una singola fase di interpretazione del documento, valutando il testo linea per linea. Come gopher, i link possono essere inclusi in numero di massimo uno per linea, incoraggiando in tal modo strutture pulite e simili ad una lista.
Così come i codici di stato a due cifre (del protocollo gemini ndt.) sono stati progettati in modo tale che i client più semplici possano funzionare ignorando la seconda cifra, il formato text/gemini è stato pensato in maniera che i client più elementari possano funzionare ignorando le caratteristiche più avanzate del formato rimanendo, tuttavia, usabili.
Come sotto-tipo del tipo principale di tipo "text", "text/gemini" eredita il parametro "codifica dei caratteri" ("charset") così come definito nell'RFC 2046. Comunque, come evidenziato nel paragrafo 3.3, il valore predefinito del "charset" è "UTF-8" per i contenuti testuali trasferiti attraverso Gemini.
Un unico parametro addizionale specifico per il sotto-tipo "text/gemini" è detto il parametro "lingua" ("lang"). Il valore di tale parametro caratterizza il linguaggio, o i linguaggi, naturali in cui il contenuto è stato scritto. La presenza del parametro "lang" è opzionale. Ove il parametro "lang" sia presente, la sua interpretazione è demandata interamente al client. Per esempio, client che usano tecnologie di sintesi vocale per assistere le persone ipovedenti potrebbero usare il parametro "lang" per migliorare la pronuncia dei contenuti. I client che stampano il testo su schermo potrebbero usare il parametro "lang" per determinare se il testo debba fluire da sinistra a destra o viceversa. I client più semplici potrebbero semplicemente ignorare il summenzionato parametro. Quando il parametro "lang" non è presente, non dovrebbe essere assunto nessun valore predefinito e i client che necessitano, per funzionare, di un valore di "lang" (come i già citati programmi di sintesi vocale) dovrebbero appoggiarsi ad un input da parte dell'utente per determinare come procedere in assenza di un valore indicato del parametro "lang".
Valori validi del parametro "lang" sono costituiti da una lista di uno o più campi lingue separati da virgola, campi definiti nell'RFC 4646. Ad esempio:
Come detto, il formato "text/gemini" è orientato alla linea. Ciascuna linea di un documento in questo formato possiede una singola caratteristica detta: "tipo-linea" ("line type"). È possibile stabilire univocamente il "line type" semplicemente ispezionando i primi tre caratteri della linea stessa. Il "line type" determina la maniera nella quale la stessa dovrebbe essere presentata all'utente. Qualunque dettaglio della presentazione o resa associata ad un particolare "line type" si limita alla linea che si sta analizzando in quel momento.
Ci sono sette diversi tipi di linea in totale. Benché un client completamente funzionale e che include tutte le caratteristiche definite dalla specifica dovrebbe essere capace di interpretarne solo 4 di questi. Si tratta dei tipi linea fondamentali ("core line type", vedi il paragrafo 5.4). I client più semplici possono trattare gli altri tipi di linea alla stregua dei "core line type" e offrire comunque un esperienza adeguata all'utente.
I quattro tipi di linea fondamentali sono:
Le linee di testo ("text line") sono il tipo di linea più importante, la definizione di "text line" è: qualunque linea che non sia interpretabile come un altro tipo di linea. La maggioranza delle linee in un usuale documento "text/gemini" saranno "text line".
Le linee di testo saranno presentate all'utente, dopo essere state adattate alla larghezza dello spazio concesso al client dal sistema in uso (p.es. larghezza di un terminale ndt.). Le "text line" saranno presentate in una delle maniere comunemente usate per facilitare la lettura, definizione per quest'ultima caratteristica che sarà lasciata al client stabilire. Per esempio, potrebbero essere usati caratteri a larghezza variabile, gli spazi potrebbero essere normalizzati, usano spazi più larghi tra frasi rispetto a quelli usati per dividere le parole, o altri tipi di convenzioni tipografiche potrebbero essere applicate. I client potrebbero permettere di personalizzare l'aspetto delle "text line" permettendo di alterare il tipo di carattere, la sua dimensione, i colori eccetera. Gli autori (di contenuti ndt.) non dovrebbero assumere di poter avere un controllo preciso sulla resa delle linee di testo, solo sul loro contenuto testuale. Contenuti tipo l'"ASCII art", codice sorgente ed altro che potrebbero essere resi in maniera incorretta se trattati come appena esposto dovrebbero essere racchiusi tra linee di "scambio formattazione" (vedi 5.4.3).
Le linee vuote ("blank") sono istanze delle "text line" e non possiedono alcun significato particolare. Dovrebbero essere rese individualmente come spazi verticali vuoti ogni volta che se ne presenta una. In tale maniera esse risultano equivalenti al contrassegno ("tag") <br/> dell'HTML. Linee vuote consecutive non dovrebbero essere compresse in un minor numero di spazi vuoti verticali. Notate anche che linee vuote consecutive non formano alcun tipo di blocco o corpo unitario come, ad esempio, un paragrafo: tutte le linee di testo sono entità a se stanti.
Le linee di testo che sono più lunghe dello spazio che il client mette a disposizione devono essere divise (dal client ndt.) appropriatamente in linee consecutive più corte in modo tale da adattarsi alla larghezza disponibile. Questo adattamento va operato per ogni linea in maniera indipendente. Linee consecutive che sono più brevi del dello spazio disponibile non devono essere unite in un numero minore di linee più lunghe.
Per comprendere pienamente i vantaggi di tale approccio alla formattazione dei testi, gli/le autori/ici di contenuti dovrebbero evitare di forzare le interruzioni di linea ad una specifica lunghezza, ciò si discosta dalla convenzione nel gopherspace dove il testo e' scritto immaginando una larghezza disponibile di 80 caratteri o meno. Invece linee di testo che dovrebbero essere mostrate come un unico blocco dovrebbero essere scritte come un unica linea (come nel documento che state leggendo ndt.). La maggior parte degli editor di testo possono essere configurati per forzare una interruzione di linea quando essa è mostrata sullo schermo e supera i margini della finestra, ma senza veramente modificare il contenuto del file che si sta elaborando.
Gli autori/ici che insistono nel forzare le interruzioni di linea come metodo di formattazione tipografica dovrebbero considerare che i loro contenuti verranno resi sul dispositivo del client correttamente solo se lo spazio disponibile per il testo è maggiore od uguale alla lunghezza delle linee stabilita a priori dall'autore/ice. Altrimenti la formattazione intesa sarà probabilmente perduta.
Le linee che iniziano per "=>" (due caratteri) sono linee di collegamento ("link line") specificate secondo la sintassi:
=>[<spazio vuoto>]<URL>[<spazio vuoto><nome del link>]
dove:
I seguenti sono tutti esempi validi di "link line":
=> gemini://example.org/ => gemini://example.org/ Un link di esempio => gemini://example.org/foo Un altro link di esempio sullo stesso host => foo/bar/baz.txt Un link relativo => gopher://example.org:70/1 Un link gopher
Gli URL nelle "link line" devono avere i caratteri riservati e gli spazi "percent-encoded" come definito dall'RFC 3986.
Da notare che gli URL dei link potrebbero avere schemi ("scheme") diversi da gemini. Cio' significa che i documenti gemini possono, in maniera semplice ed elegante, avere collegamenti a documenti che utilizzano altri protocolli, a differenza delle gophermaps che possono solo collegare documenti non gopher attribuendo un significato non standard al tipo item 'h'.
I client possono presentare i link agli utenti nella maniera che più li aggrada, però i client non devono avviare connessioni di rete in maniera automatica come parte del sistema per presentare i link i cui URL corrispondono a protocolli di rete (p.es. tutti gli URL assoluti, ovvero che iniziano con gemini://, gopher://, https://, ftp:// , ecc.).
(Nota: forse in questa parte ho esagerato con la traduzione "interpretativa", se l'ho fatto fatemi sapere che correggo ndc.)
Qualunque linea che inizi con la stringa "```" (tre accenti gravi inversi di seguito, senza spazi a precedenti) indica una linea che attiva o disattiva il passaggio alla modalità testo preformattato o meno ("preformatted toggle line"). Queste linee non dovrebbero essere incluse nel risultato reso all'utente. Invece queste linee ribaltano lo stato del parser (il programma che si occupa di interpretare il testo ndt.) da uno stato nel quale le linee sono interpretate secondo le regole qui esposte, ad uno nel quale le linee sono rese all'utente "tal quali", ovvero l'input viene semplicemente copiato sul dispositivo di output mantenendo teminatori di linea spazi bianchi e quant'altro. All'inizio del documento lo stato del parser è in modalità preformattazione disattivata ("off"). La modalità formattazione è l'unico stato interno che il parser deve mantenere per interpretare correttamente un testo gemini. Quando la modalità preformattazione è attiva, come detto, le linee seguenti sono considerate tutte preformattate e come tali vanno stampate (vedi 5.4.4).
Le "preformatted toggle line" sono da considerarsi equivalenti ai tag <pre> e </pre> dell'HTML.
Qualunque testo segua "```" di una "preformatted toggle line" che attivi la modalità preformattazione potrebbe essere interpretata dal client come "testo alternativo" ("alt text") riferibile alle linee preformattate che seguono la "preformatted toggle line" stessa. L'uso dell'"alt text" è a discrezione del client e quelli più semplici possono semplicemente ignorarlo. L"alt text" è consigliato per ASCII art o simili contenuti non testuali che, ad esempio, non potrebbero essere compresi da un lettore di schermi o sarebbe indicizzato con difficoltà dei motori di ricerca. L'"alt text" potrebbe anche essere usato per il codice sorgente di un programma che i client più raffinati potrebbero colorare con schemi di colore specifici.
Qualunque testo segua "```" quando questa linea cambi lo stato del disattivando la modalità preformattazione va ignorata da parte del client.
Le linee di testo preformattate ("Preformatted text line") dovrebbero essere presentate all'utente usando un font "neutro", monospaziato, senza alterazione degli spazi o altre trasformazioni stilistiche. I client grafici dovrebbero usare meccanismi di scorrimento ("scrolling") per presentare le linee preformattate più lunghe dello spazio a disposizione del programma, al posto di troncare le linee. Nel mostrare le linee preformattate i client, inoltre, dovrebbero tenere conto applicazioni come ASCII art e codice sorgente, in particolare prestare attenzione a linguaggi dove gli spazi sono semanticamente rilevanti (come il python), in questo caso le operazioni di copia/incolla non devono impedire di compilare/eseguire il programma in una maniera diversa da quella che si otterrebbe compilando/eseguendo il file originale.
I seguenti tipi di linea possono essere interpretati dai client ma non vi è obbligo. I client più semplici possono trattarli come linee di testo (vedi 5.4.1) senza incorrere in perdite di caratteristiche essenziali.
Le linee che iniziano con "#" sono dette linee di intestazione ("heading line"). Le linee di intestazione consistono in uno, due o tre caratteri "#" consecutivi, seguiti da uno spazio opzionale seguito, a sua volta, dal testo dell'intestazione vero e proprio. Il numero di caratteri indica il "livello" dell'intestazione, #, ## e ### possono essere pensati come equivalenti ad: <h1>, <h2> ed <h3> dell'HTML.
Il testo dell'intestazione dovrebbe essere presentato all'utente, i client potrebbero usare speciali regole di formattazione (p.es. font in grassetto) per indicare che si tratta di un intestazione (i client più semplici possono semplicemente stampare l'intera linea compreso il cancelletto). Comunque sia, la motivazione principale per il quale si è deciso di inserire le linee di intestazione non è tanto stilistica quanto per fornire una rappresentazione della struttura interna del documento che fosse interpretabile automaticamente da un elaboratore. I client più avanzati potrebbero usare questa informazione, per esempio, per mostrare un indice generato automaticamente a lato di un documento piuttosto lungo, permettendo di saltare da un elemento all'altro senza scorrere l'intero documento eccessivamente. Strumenti tipo CMS che generano automaticamente menu o feed Atom/RSS per una directory di file text/gemini potrebbero usare la prima intestazione come titolo del documento.
Le linee che iniziano per "* " sono considerate elementi di una lista non ordinata. Questa linea esiste esclusivamente per ragioni stilistiche. La "*" potrebbe essere rimpiazzata, in client più avanzati, da un cerchietto. Il testo dopo "* " dovrebbe essere presentato all'utente come se fosse una "text line", quindi adattato allo spazio a disposizione del programma e formattato opportunamente. I client più avanzati potrebbero tenere da conto lo spazio occupato dal simbolo all'inizio dell'elemento della lista (il cerchietto) quando tentano di adattare il contenuto di elementi molto lunghe per assicurarsi che il testo si allinei a sinistra correttamente, ovvero che le linee di corrispondenti allo stesso elemento della lista condividano la stessa quantità di spazio che le separa dalla sinistra dello schermo (o destra se il testo fluisce nella direzione opposta come in alcune lingue ndt.).
Le linee che iniziano con ">" sono citazioni ("quote line"). Queste linee esistono solo affinché i client più avanzati possano usare uno stile distinto per indicare all'utente che il testo è riportato da una diversa fonte. Per esempio se il contenuto di una "quote line" viene adattata allo schermo ciascuna delle linee in cui la prima venisse spezzata potrebbe avere un simbolo ">" che la precede.
Segue la definizione della cifra 1 in 3.2.
Simile allo stato 10, ma per input "sensibili", come password. I client dovrebbero presentare il prompt come per lo status 10, ma l'input dell'utente non dovrebbe essere mostrato a schermo per evitare che venga letto da occhi indiscreti.
Segue la definizione della cifra 2 in 3.2.
Segue la definizione della cifra 3 in 3.2.
La risorsa richiesta dovrebbe essere richiesta con il nuovo URL fornito in futuro. Strumenti come gli indexer dei motori di ricerca o gli aggregatori di contenuti dovrebbero aggiornare la loro configurazione per evitare di richiedere il vecchio URL, e client per l'utilizzo diretta dagli utenti possono aggiornare automaticamente segnalibri e altro. Si noti che i client che controllano solo la prima cifra dello status lo considereranno un redirect temporaneo. Finiranno comunque nel posto giusto, semplicemente non saranno in grado di notare che questo reindirizzamento è permanente, quindi pagheranno una piccola penalità in termini di performance dovuta dal dover seguire il redirect ogni volta.
Segue la definizione della cifra 4 in 3.2.
Il server non è disponibile per sovraccarico o manutenzione. (vedi HTTP 503)
Un progesso CGI, o un sistema simile per la generazione di contenuti dinamici, è fallito inaspettatamente o è andato in timeout.
Una richiesta ad un proxy è fallita perché il server non è stato in grado di completare la transazione con l'host remoto. (vedi HTTP 502 e 504)
È in effetto la limitazione delle richieste. <META> è un numero di secondi che il client deve aspettare prima di fare un'altra richiesta a questo server. (vedi HTTP 429)
Segue la definizione della cifra 5 in 3.2.
La risorsa richiesta non è stata travata, ma potrebbe essere disponibile in futuro. (vedi HTTP 404) (difficoltà col ricordare questo codice importante? Facile: non puoi trovare le cose nascoste nell'Area 51!)
La risorsa richiesta non è più disponibile e non sarà disponibile di nuovo. Motori di ricerca e strumenti simili dovrebbero rimuovere questa risorsa dai loro indici. Aggregatori di contenuti dovrebbero smettere di richiedere la risorsa e avvisare gli utenti umani che la risorsa iscritta non è più disponibile. (vedi HTTP 410)
Il server non è stato in grado di comprendere la richiesta del client, probabilmente per via di una richiesta malformata. (vedi HTTP 400)
Segue la definizione della cifra 6 in 3.2.
Il certificato utente fornito non è autorizzato per l'accesso alla risorsa richiesta. Il problema non riguarda il certificato stesso, che potrebbe essere autorizzato per altre risorse.
Il certificato utente fornito non è stato accettato perché non valido. Indica un problema col certificato in sé, senza nessuna considerazione con la risorsa richiesta. La causa più probabile è che la data di inizio di validità del certificato sia nel futuro o sia passata la sua data di scadenza, ma questo codice può anche indicare una firma non valida, o una violazione dei requisiti dello standard X509. Il <META> dovrebbe fornire più informazioni sull'esatto errore.