💾 Archived View for gemini.circumlunar.space › docs › de › spezifikation.gmi captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
v0.14.3, 29. November 2020
Dies ist eine zunehmend weniger ungenaue Skizze einer tatsächlichen Spezifikation für das Gemini-Projekt. Obwohl noch nicht fertiggestellt, werden zukünftige Änderungen der Spzifikation wahrscheinlich sehr klein sein. Sie können Code mit dieser Pseudo-Spezifikation schreiben und zuversichtlich sein, dass er nicht aufgrund von massiven Änderungen in der nächsten Woche völlig unbrauchbar wird, aber trotzdem empfiehlt es sich sehr, ein Auge auf die fortschreitende Entwicklung zu behalten und notwendige Änderungen vorzunehmen.
Dies wird hauptsächlich bereitgestellt, sodass Sie nicht erst Unmengen an alten Phlogs lesen und Notizen machen müssen, um zu wissen, worüber ich gerade nachdenke.
Rückmeldungen zu jeglichem Teil der Spezifikation sind sehr willkommen, bitte schreiben Sie ein E-Mail an solderpunk@posteo.net.
Dies ist eine Übersetzung der ursprünglich englischen Spezifikation. Im Falle der unterschiedlichen Auslegung dieser Spezifikationen sollte die englische Version als verbindlich gelten. Nur aus Gründen der besseren Lesbarkeit wurde ein sogenanntes generisches Maskulinum verwendet. Bezeichnungen des männlichen Genus sind so zu verstehen, das auch alle anderen Geschlechter eingeschlossen sind.
originäre englische Spezifikation
Gemini ist ein Client-Server-Protokoll mit Anfrage-Antwort-Transaktionen, grob ähnlich zu Gopher oder HTTP. Verbindungen werden nach jeder Transaktion geschlossen und können nicht wiederverwendet werden. Wenn Gemini über TCP/IP durchgeführt wird, sollten Server den Port 1965 nutzen (die erste bemannte Gemini-Mission, Gemini 3, flog im März '65). Dies ist ein unpriviligierter Port, sodass es sehr einfach ist einen Server als "nobody"-Nutzer auszuführen, selbst wenn z.B. der Server in Go geschrieben ist und damit nicht Privilegien in der üblichen Art abgeben kann.
Es gibt nur eine Art von Gemini-Transaktion, ungefähr gleich mit einer Gopher-Anfrage oder einer HTTP-"GET"-Anfrage. Transaktionen werden wie folgt durchgeführt:
C: Verbindung öffnen
S: Verbindung annehmen
C/S: TLS-Handshake durchführen (siehe Abschnitt 4)
C: Server-Zertifikat überprüfen (siehe 4.2)
C: Anfrage senden (eine CRLF-terminierte Zeile) (siehe Abschnitt 2)
S: Antwort-Kopfzeile senden (eine CRLF-terminierte Zeile), Verbindung trennen
wenn ein Fehler aufgetreten ist.
S: Antwort-Inhalt senden (Text oder binäre Daten) (siehe 3.3)
S: Verbindung trennen
C: Antwort verarbeiten (siehe 3.4)
Resourcen, die über Gemini gehostet werden, können mit dem URL-Schema "gemini" identifiziert werden. Dieses Schema ist syntaktisch kompatibel mit der generischen URI-Syntax wie definiert in RFC 3986, aber unterstüzt nicht alle Teile der generischen Syntax. Im Speziellen ist die Autoritäts-Komponente erlaubt und erforderlich, aber die Userinfo-Teilkomponente ist NICHT erlaubt. Die Host-Teilkomponente ist erforderlich. Die Port-Teilkomponente ist optional, mit einem Standardwert von 1965. Die Pfad-, Query- und Fragment-Komponenten sind erlaubt und haben keine besondere Bedeutung außerhalb der generischen Syntax. Leerzeichen in Gemini-URLs sollten nicht als + sondern als %20 kodiert werden.
Gemini-Anfragen sind einzelne CRLF-terminierte Zeilen mit der folgenden Struktur:
<URL><CR><LF>
<URL> ist eine UTF-8-kodierte absolute URL, einschließlich eines Schemas, mit einer maximalen Länge von 1024 Bytes.
Das Senden einer absoluten URL statt nur eines Pfad-Selektors ist effektiv äquivalent zum Erstellen einer HTTP-"Host"-Kopfzeile. Es erlaubt virtuelles Hosting mehrerer Gemini-Domains auf der gleichen IP-Adresse. Es erlaubt Servern auch, optional als Proxies zu handeln. Schemas in Anfragen zu erlauben, die nicht "gemini" sind, erlaubt Servern optional als Protokollumsetzer zu agieren um z.B. eine Gopher-Resource über Gemini bereitzustellen. Als Proxy zu agieren ist optional und es ist zu erwarten, dass der Großteil der Server nur Anfragen auf ihrer/n eigenen Domain(s) beantworten.
Gemini-Antworten bestehen aus einer einzelnen CRLF-terminierten Kopfzeile, optional gefolgt vom Antwort-Inhalt.
Gemini-Kopfzeilen sehen wie folgt aus:
<STATUS><LEERZEICHEN><META><CR><LF>
<STATUS> ist ein zweistelliger numerischer Statuscode wie unter 3.2 und in Anhang 1 beschrieben.
<LEERZEICHEN> ist ein einzelnes Leerzeichen, also das Byte 0x20.
<META> ist eine UTF-8-kodierte Zeichenkette mit einer maximalen Länge von 1024 Bytes, deren Bedeutung von <STATUS> abhängt.
<STATUS> und <META> sind von einem einzigen Leerzeichen von einander getrennt.
Wenn <STATUS> nicht zur "ERFOLG"-Kategorie gehört muss der Server die Verbindung nach dem Senden der Kopfzeile schließen und darf keinen Inhalt senden.
Wenn ein Server einen <STATUS> sendet, welcher nicht aus 2 Ziffern besteht, oder <META> länger als 1024 Bytes ist, sollte der Client die Verbindung abbrechen, den Inhalt verwerfen und den Nutzer über den Fehler informieren.
Gemini benutzt zweistellige numerische Statuscodes. Ähnliche Statuscodes haben die gleiche Startziffer. Wichtig ist, dass die Startziffer die Statuscodes nicht wie HTTP in vage Gruppen wie "Clientfehler" und "Serverfehler" abgrenzt. Stattdessen stellt die Startziffer genügend Informationen zur Verfügung, damit ein Client die Antwort verarbeiten kann. Die zweite Ziffer stellt genauere Informationen zur verfügung, für eindeutiges Serverlogging, für komfortablere interaktive Clients, die eine etwas modernere Nutzerschnittstelle zur Verfügung stellen, und um das schreiben besserer intelligenter automatisierter Clients wie Aggregatoren, Suchmaschinen-Crawlern usw. zu ermöglichen.
Die Startziffer eines Statuscodes ordnet die Antwort eindeutig einer von 6 Kategorien zu, welche die Semantik von <META> definieren.
Statuscodes, die mit einer 1 beginnen sind EINGABE-Statuscodes, das heißt:
Die angefragte Resource akzeptiert eine Zeile textueller Nutzereingabe. Die <META>-Zeile ist eine Aufforderung, die dem Nutzer angezeigt werden solllte. Die gleiche Resource sollte dann wieder angefragt werden, wobei die Nutzereingabe als Query-Komponente übermittelt wird. Queries sind in der Anfrage nach der üblichen generischen URL-Definition von RFC 3986 enthalten, also vom Pfad mit einem ? getrennt. Reservierte Zeichen in der Nutzereingabe müssen "Prozent-kodiert" werden, wie in RFC 3986 definiert. Leerzeichen sollten auch Prozent-kodiert werden.
Statuscodes, die mit einer 2 beginnen, sind ERFOLG-Statuscodes, das heißt:
Die Anfrage wurde erfolgreich verarbeitet und die Kopfzeile wird von Inhalt gefolgt. Die <META>-Zeile ist ein MIME-Type, welcher auf den Inhalt zutrifft.
Statuscodes, die mit einer 3 beginnn, sind UMLEITUNG-Statuscodes, das heißt:
Der Server leitet den Client zu einem neuen Ort für die angefragte Resource. Es gibt keinen Inhalt. <META> ist eine neue URL für die angefragte Resource. Die URL kann absolut oder relativ sein. Die Umleitung sollte als vorübergehend verstanden werden, Clients sollten also zukünftig die Resource an der ursprünglichen Adresse anfragen und nicht Komfort-Funktionen wie das automatische aktualisieren von Lesezeichen ausführen. Es gibt keinen Inhalt.
Statuscodes, die mit einer 4 beginnen, sind TEMPORÄRER FEHLER-Statuscodes, das heißt:
Die Anfrage ist fehlgeschlagen. Es gibt keinen Inhalt. Die Art des Fehlers ist vorübergehend, identische zukünftige Anfragen könnten also erfolgreich sein. Der Inhalt von <META> kann weitere Informationen zum Fehler beinhalten und sollte menschlichen Nutzern angezeigt werden.
Statuscodes, die mit einer 5 beginnen, sind PERMANTENTER FEHLER-Statuscodes, das heißt:
Die Anfrage ist fehlgeschlagen. Es gibt keinen Inhalt. Die Art des Fehlers ist dauerhaft, identische zukünftige Anfragen werden verlässlich aus dem selben Grund fehlschlagen. Der Inhalt von <META> kann weitere Informationen zum Fehler beinhalten und sollte menschlichen Nutzern angezeigt werden. Automatische Clients wie etwa Aggregatoren oder Indizierungs-Crawler sollten diese Anfrage nicht wiederholen.
Statuscodes, die mit einer 6 beginnen, sind NUTZERZERTIFIKAT ERFORDERLICH-Statuscodes, das heißt:
Die angefragte Resource erfordert ein Nutzerzertifikat, um darauf zugreifen zu können. Falls die Anfrage ohne ein Zertifikat durchgeführt wurde, sollte sie mit einem Nutzerzertifikat wiederholt werden. Falls die Anfrage mit einem Zertifikat durchgeführt wurde, akzeptierte der Server das Zertifikat nicht und die Anfrage sollte mit einem anderen Zertifikat wiederholt werden. Der Inhalt von <META> (und/oder der genaue 6x Statuscode) können weitere Informationen zu Zertifikatanforderungen bieten, oder den Grund, warum das Zertifikat zurückgewiesen wurde.
Für einen einfachen interaktiven Client für menschliche Benutzung können die Fehler 4 und 5 effektiv gleich behandelt werden, indem einfach der Inhalt von <META> unter der Überschrift "FEHLER" angezeigt wird. Die Unterscheidung in temporäre und permanente Fehler ist hauptsächlich für wohlerzogene automatische Clients relevant. Einfache Clients können sich dafür entscheiden, Nutzerzertifkat-Authentifizierung nicht unterstützen. In diesem Fall sind nur vier verschiedene Routinen zur Behandlung der verschiedenen Statuscodes erforderlich (Für Statuscodes mit den Startziffern 1, 2, 3 und kombiniert 4 und 5).
Das vollständige zweistellige System ist in Anhang 1 beschrieben. Dabei ist zu bemerken, dass ein Statuscode für jede der 6 verschiedenen ersten Ziffern gefolgt von einer Null einem generischen Status dieser Art ohne besondere Semantik gleich kommt. Das heißt, dass einfache Server ohne fortgeschrittene Funktionalität nur Statuscodes 10, 20, 30, 40 oder 50 zurückgeben müssen.
Das Statuscode-System ist mit Bedacht so gestaltet, dass die erweiterte Bedeutung (und entsprechend erhöhte Komplexität) der zweiten Ziffer vollständig optional für Server als auch Clients ist.
Der Antwort-Inhalt ist nur roher Inhalt, Text oder Binärdaten, à la Gopher. Es gibt keine Unterstützung für Kompression, Stückeln oder irgendeine andere Art von Inhaltsübermittlungskodierung. Der Server schließt die Verbindung nach dem letzten Byte, es gibt kein "Ende der Übermittlung"-Signal wie Gophers einsamen Punkt.
Nur Antworten mit Kopfzeilen, die einen ERFOLG-Status beinhalten (also einen Statuscode mit der Startziffer 2), haben einen Antwort-Inhalt. Für solche Antworten ist <META> ein MIME-Type wie in RFC 2046 definiert.
Internet Media Typen sind in einer kanonischen Form registriert. Inhalt, welcher über das Gemini-Protokoll übermittelt wird, muss vorher in der entsprechenden kanonischen Form repräsentiert sein, außer "text"-Medientypen, wie im nächsten Absatz definiert.
In kanonischer Form müssen Medien-Subtypen des "text"-Medientyps CRLF-Zeilenenden benutzen. Gemini entspannt diese Voraussetzung und erlaubt den Transport von "text"-Medientypen auch mit einem einzelnen LF (aber NICHT mit einem einzelnen CR), welcher den Zeilenumbruch darstellt, solange dies für den vollständigen Inhalt einheitlich genutzt wird. Gemini-Clients müssen in "text"-Medientypen, die über Gemini übermittelt werden, sowohl CRLF als auch nur LF als Zeilenende akzeptieren.
Wenn ein MIME-Type mit "text/" beginnt und kein "charset" gegeben ist, sollte eine Kodierung mit UTF-8 angenommen werden. Konforme Clients müssen UTF-8-kodierte "text/*"-Antworten unterstützen. Clients können optional weitere Kodierungen unterstützen. Wenn Clients eine Antwort mit einer Kodierung erhalten, welche sie nicht dekodieren können, sollten sie den Nutzer elegant über den Fehler informieren, statt Zeichensalat anzuzeigen.
Wenn <META> eine leere Zeichenkette ist, muss der MIME-Type "text/gemini; charset=utf-8" angenommen werden. Der "text/gemini"-Medientyp ist in Abschnitt 5 definiert.
Die Antwort-Behandlung durch Clients sollte dem übermittelten MIME-Type entsprechen. Gemini definiert einen eigenen MIME-Type (text/gemini), dessen Behandlung in Abschnitt 5 diskutiert wird. In allen anderen Fällen sollten clients "etwas sinvolles" entsprechend dem MIME-Type tun. Minimalistische Clients könnten eine Strategie annehmen, alle anderen "text/*"-Antworten ohne Formatierung auf dem Bildschirm auszugeben und alle anderen Antworten in eine Datei zu speichern. Clients für UNIX-Systeme könnten etwa die Datei /etc/mailcap nutzen, um installierte Programme für die Behandlung von nicht-"text"-Medientypen zu finden.
Die Benutzung von TLS ist für Gemini obligatorisch.
Die Benutzung der SNI-Erweiterung von TLS (Server Name Indication) ist obligatorisch, um namenbasiertes virtuelles Hosting zu erlauben.
Server müssen die TLS-Version 1.2 oder höher nutzen und sollten die TLS-Version 1.3 oder höher benutzen. TLS 1.2 ist vorübergehend widerwillig erlaubt, um keine drastische Einschränkung der verfügbaren Bibliotheken zu erzeugen. Hoffentlich kann in naher Zukunft TLS 1.3 oder höher spezifiziert werden. Clients, die der Entwicklung voraus sein wollen, können entscheiden, sich nicht mithilfe der TLS-Version 1.2 oder niedriger zu verbinden.
Clients können TLS-Verbindungen validieren, wie sie wollen (einschließlich überhaupt nicht), aber der dringend empfohlene Weg ist die Nutzung eines einfachen "TOFU" Certificate-Pinning-Systems welches selbstsignierte Zertifikate als Bürger erster Klasse behandelt. Dies reduziert den TLS-Verwaltungsaufwand im Netzwerk (nur 1 Zertifikat muss gesendet werden, nicht eine ganze Kette) und senkt die Zugangshürden zum Aufsetzen einer Gemini-Seite (keine Erfordernis, eine CA zu bezahlen oder einen Let's Encrypt cron job einzurichten, einfach ein Zertifikat erstellen und los).
TOFU steht für "Trust On First Use" (Vertrauen bei erster Benutzung) und ist ein Public-Key-Sicherheitsmodell ähnlich zu dem von OpenSSH. Wenn sich ein Gemini-Client das erste Mal mit einem Server verbindet, akzeptiert er jedes beliebige angebotene Zertifikat. Der Fingerabdruck und das Ablaufdatum dieses Zertifikates werden in einer dauerhaften Datenbank gespeichert (wie etwa der .known_hosts Datei für SSH), in Verbindung mit dem Hostnamen des Servers. Bei allen folgenden Verbindungen zu diesem Hostnamen wird der Fingerabdruck des empfangenen Zertifikates berechnet und mit dem Fingerabdruck aus der Datenbank abgeglichen. Wenn das Zertifikat nicht mit dem vorherigen übereinstimmt, aber das vorherige Ablaufdatum noch nicht erreicht ist, wird dem Nutzer eine Warnung angezeigt, analog zu solch einer, die Webbrowser benutzen, wenn sie ein Zertifikat erhalten, welches keine Kette zu einer vertrauenswürdigen CA hat.
Dieses Modell ist keineswegs perfekt, aber es ist auch nicht furchtbar und jedenfalls überlegen gegenüber dem blinden Akzeptieren von selbstsignierten Zertifikaten.
Auch wenn diese im Web selten anzutreffen sind, erlaubt TLS einem Client, sich am Server mit einem Zertifikat auszuweisen, genau wie der Server dies üblicherweise beim Client tut. Gemini schließt die Möglichkeit für Server ein, mit Nutzkanalsignalisierung die Nutzung eines Nutzerzertifikates zu fordern. Dies ist sehr flexibel, sehr sicher aber auch eine sehr einfache Möglichkeit für eine Nutzer-Identität für verschiedene Anwendungen:
Gemini-Anfragen werden üblicherweise ohne ein Nutzerzertifikat ausgeführt. Wenn eine angefragte Resource ein Nutzerzertifikat erfordert und in der Anfrage keines enthalten war, kann der Server mit einem Status 60, 61 oder 62 antworten (siehe Anhang 1 für eine Beschreibung aller Statuscodes zu Nutzerzertifikaten). Ein Nutzerzertifikat, welches als Antwort auf solch einen Statuscode erzeugt oder geladen wird, hat seinen eigenen Gültigkeitsbereich, gebunden an den gleichen Hostnamen wie die Anfrage-URL und an alle Pfade unterhalb des angefragten URL-Pfades. Zum Beispiel, wenn eine Anfrage für gemini://example.com/foo mit dem Statuscode 60 beantwortet wird und der Nutzer daraufhin entscheidet, ein neues Zertifikat zu generieren, sollte das gleiche Zertifikat für folgende Anfragen von gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc. genutzt werden, bis zu dem Zeitpunkt in dem der Nutzer das Zertifikat löscht oder entscheidet, es vorübergehend zu deaktivieren. Interaktiven Clients für menschliche Nutzer wird dringend empfohlen, solche Aktionen einfach zu gestalten und Beutzern generell volle Kontrolle über den Gebrauch von Nutzerzertifikaten zu geben.
So wie HTML das "eingeborene" Format für HTTP-Antworten ist, und einfacher Text entsprechend für Gopher-Antworten, definiert Gemini sein eigenes natives Antwort-Format - obwohl natürlich dank der Einbindung von MIME-Typen in der Antwort-Kopfzeile auch einfacher Text, Rich Text, HTML, Markdown, LaTeX etc. übermittelt werden können.
Antwort-Inhalte des Typs "text/gemini" sind eine Art abgespecktes Hypertext-Format, welces von Gophermaps und Markdown inspiriert ist. Das Format erlaubt reichere typografische Möglichkeiten als der einfache Text von Gopher, aber bleibt extrem einfach zu parsen. Das Format ist zeilenorientiert, und eine zufriedenstellende Darstellung kann in einem einzigen Durchlauf des Dokuments erreicht werden, wobei jede Zeile einzeln bearbeitet wird. Wie in Gopher können Verweise nur auf einer ganzen Zeile dargestellt werden, wodurch ordentliche, listenartige Strukturen angeregt werden.
Ähnlich wie zweistellige Statuscodes gestaltet wurden, so dass einfache Clients korrekt funktionieren können, ohne die zweite Ziffer zu beachten, wurde das text/gemini-Format so gestaltet, dass einfache Clients die fortgeschrittenen Formatierungen einfach ignorieren können und trotzdem nutzbar bleiben.
Als ein Subtyp des übergeordneten Medientyps "text" erbt "text/gemini" den "charset"-Parameter nach RFC 2046. Allerdings ist der Standardwert von "charset" wie in 3.3 beschrieben der Wert "utf-8" für jeglichen Inhalt des Typs "text", der über Gemini übermittelt wird.
Ein einziger weiterer Parameter ist speziell für den "text/gemini"-Subtyp definiert: Der "lang"-Parameter. Der Wert von "lang" bezeichnet die natürliche Sprache oder Sprache(n), in welcher der textuelle Inhalt eines "text/gemini"-Dokuments geschrieben ist. Das vorhandensein des "lang"-Parameters ist optional. Wenn der "lang"-Parameter vorhanden ist, ist seine Bedeutung vollständig vom Client definiert. Zum Beispiel können Clients, welche Text-zu-Sprache-Technologie verwenden, den "lang"-Parameter nutzen, um Gemini-Inhalte sehbehinderten Nutzern mit besserer Aussprache zugänglich zu machen. Clients, die Text auf einem Bildschirm darstellen, können anhand des "lang"-Parameters bestimmen, ob Text von links nach rechts oder von rechts nach links dargestellt werden soll. Einfache Clients für Nutzer, die Text in Sprachen lesen, die von links nach rechts geschrieben werden, können den Wert des "lang"-Parameters einfach ignorieren. Wenn der "lang"-Parameter nicht vorhanden ist, sollte kein standardmäßiger Wert angenommen werden, und Clients, die einen Begriff von Sprache benötigen, um den Inhalt zu verarbeiten (wie etwa Text-zu-Sprache-Screenreader) sollten auf Nutzereingaben basieren, um zu bestimmen, wie bei nichtvorhandensein des "lang"-Parameters verfahren werden soll.
Gültige Werte des "lang"-Parameters sind eine kommagetrennte Liste von einer oder mehreren Sprach-Tags wie definiert in RFC 4646. Zum Beispiel:
Wie gesagt ist das "text/gemini"-Format zeilenorientiert. Jede Zeile eines "text/gemini"-Dokuments hat einen einzigen "Zeilentyp". Es ist nur durch das Betrachten der ersten 3 Zeichen einer Zeile eindeutig möglich, den Zeilentyp festzustellen. Der Typ einer Zeile legt fest, wie sie dem Nutzer angezeigt werden sollte. Alle Details der Darstellung, die aus einem bestimmten Zeilentyp hervorgehen sind streng begrenzt auf diese einzelne Zeile.
Es gibt insgesamt 7 verschiedene Zeilentypen. Allerdings muss ein vollständig funktionaler und konformer Gemini-Client nur 4 verstehen - dies sind die "Kerntypen" (siehe 5.4). Fortgeschrittene Clients können auch die zusätzlichen "fortgeschrittenen Zeilentypen" verarbeiten (siehe 5.5). Einfache Clients können alle fortgeschrittenen Zeilentypen äquivalent zu einem der Kerntypen behandeln und immer noch eine adäquate Nutzererfahrung bieten.
Die 4 Kernzeilentypen sind:
Textzeilen sind der fundamentalste Zeilentyp - jede Zeile, die nicht zu einer Definition der anderen Zeilentypen passt, ist eine Textzeile. Der Großteil aller Zeilen in einem typischen "text/gemini"-Dokument gehört zu diesem Zeilentyp.
Textzeilen sollten dem Nutzer angezeigt werden, nachdem sie auf eine dem Anzeige-Gerät entsprechende Breite umgebrochen wurden (siehe weiter unten). Textzeilen können dem Nutzer so angezeigt werden, dass sie angenehm zu lesen sind; die genaue Bedeutung dessen liegt in der Diskretion des Clients. Zum Beispiel können proportionale Schriftarten genutzt werden, Leerraum normalisiert werden, sodass Leerraum zwischen Sätzen größer ist als zwischen Wörtern und weitere solche typografischen Nettigkeiten können angewandt werden. Clients können Nutzern erlauben, das Aussehen von Textzeilen anzupassen, indem Schriftart, Schriftgröße, Schrift- und Hintergrundfarbe usw. geändert werden. Autoren sollten nicht erwarten, irgendeine Kontrolle darüber zu haben, wie genau Textzeilen angezeigt werden, nur über den textuellen Inhalt. Inhalt wie ASCII-Kunst, Quellcode usw. sollte von Vorformatierungs-Umschaltzeilen eingeschlossen sein, da er sonst falsch dargestellt werden kann (siehe 5.4.3).
Leere Zeilen sind ebenfalls Textzeilen und haben keine besondere Bedeutung. Sie sollten einzeln als vertikaler Leerraum dargestellt werden. In dieser Weise sind sie ähnlich zu "<br/>"-Tags in HTML. Aufeinander folgende leere Zeilen sollten NICHT zu weniger leeren Zeilen zusammengefasst werden. Außerdem stellen aufeinander folgende nicht-leere Zeilen keine zusammenhängenden Einheiten oder Blöcke wie einen Absatz dar: Alle Textzeilen sind unabhängige Objekte.
Textzeilen, die so lang sind, dass sie nicht auf die Anzeige eines Clients passen, sollten umgebrochen werden, um zu passen. Das heißt, lange Zeilen werden aufgeteilt (idealerweise bei Leerraum oder Bindestrichen) in mehrere aufeinander folgende Zeilen einer Geräte-angemessenen Breite. Dieses Umbrechen wird auf jede Textzeile unabhängig angewendet. Mehrere aufeinander folgende Zeilen, die kürzer sind, als das Anzeigegerät, dürfen nicht in wenigere, längere Zeilen zusammengefasst werden.
Um diese Methode der Textformatierung voll auszunutzen, sollten Autoren von "text/gemini"-Inhalten vermeiden, Text auf eine vordefinierte Breite hart umzubrechen, im Gegensatz zu Konventionen im Gopherspace, wo Text typischerweise bei 80 oder weniger Zeichen umgebrochen wird. Stattdessen sollte Text, der als ein zusammenhängender Block dargestellt werden soll, auf eine gemeinsame Zeile geschrieben werden. Die meisten Text-Editoren können so konfiguriert werden, dass sie Text "weich" umbrechen, also so dass diese langen Zeilen nur für die Anzeige des Autors umgebrochen dargestellt werden, ohne Zeilenunbruch-Zeichen einzufügen.
Autoren, die darauf bestehen, ihre Inhalte auf eine feste Breite umzubrechen müssen sich bewusst sein, dass ihre Inhalte auf Geräten mit einer ausreichenden Breite zwar gut angezeigt werden, aber auf Geräten mit einer geringeren Breite mit irrationalen Zeilenumbrüchen dargestellt werden könnten.
Zeilen, die mit den zwei Zeichen "=>" beginnen, sind Verweis-Zeilen, welche die folgende Syntax haben:
=>[<LEERRAUM>]<URL>[<LEERRAUM><NUTZERFREUNDLICHER BEZEICHNER>]
Dabei gilt:
Alle der folgenden Beispiele sind gültige Verweis-Zeilen:
=> gemini://example.org/ => gemini://example.org/ Ein Beispiel-Verweis => gemini://example.org/foo ein weiteres Beispiel auf dem selben Host =>gemini://example.org/bar noch ein weiteres Beispiel auf dem selben Host => foo/bar/baz.txt eine relative URL => gohper://example.org:70/1 ein Gopherhole
Reservierte Zeichen und Leerraum in URLs in Verweis-Zeilen müssen RFC 3986 entsprechend Prozent-kodiert werden.
URLs in Verweis-Zeilen können ein anderes Schema als gemini haben. Das heißt, dass Gemini-Dokumente einfach und elegat auf Dokumente verweisen können, die durch andere Protokolle zugänglich sind, im Gegensatz zu Gophermaps, die zu nicht-Gopher-Inhalten nur mithilfe der nichtstandardisierten Erweiterung des "h" Item-Typs verlinken können.
Clients können Verweise so anzeigen, wie der Client-Autor es wünscht, allerdings dürfen Clients nie automatisch Netzwerkverbindungen aufbauen, um Links anzuzeigen, deren Schema einem Netzwerkprotokoll entspricht (etwa Verweise, die mit gemini://, gopher://, https://, ftp:// beginnen).
Alle Zeilen, deren erste drei Zeichen "```" sind (also drei aufeinander folgende Gravis ohne führenden Leerraum) sind Vorformatierungs-Umschaltzeilen. Diese Zeilen sollten dem Nutzer NICHT angezeigt werden. Stattdessen schalten diese Zeilen im Parser den Vorformatierungs-Modus an oder aus. Der Vorformatierungs-Modus sollte am Beginn des Dokuments ausgeschaltet sein. Der aktuelle Zustand des Vorformatierungs-Modus ist der einzige interne Zustand, den ein Parser speichern muss. Wenn der Vorformatierungs-Modus eingeschaltet ist, sind die üblichen Bedeutungen der übrigen Zeilentypen aufgehoben und alle Zeilen sollten als vorformatierte Zeilen identifiziert werden (siehe 5.4.4).
Vorformatierungs-Umschaltzeilen können sich ähnlich wie <pre> bzw. </pre> in HTML vorgestellt werden.
Jeglicher Text, der nach den führenden "```" einer Vorformatierungs-Umschaltzeile folgt, die den Vorformatierungs-Modus einschaltet, kann durch den Client als Alternativtext interpretiert werden, der die folgenden Zeilen beschreibt. Das Benutzen des Alternativtextes liegt im Entscheidungsbereich des Clients, ein einfacher Client kann diesen ignorieren. Alternativtext wird etwa für ASCII-Kunst und ähnlichen nicht-textuellen Inhalt empfohlen, welcher nicht sinnvoll verstanden werden kann, wenn er durch einen Screenreader dargestellt wird oder auch, wenn dieser Inhalt nich sinnvoll durch einen Suchmaschinen-Crawler indiziert werden kann. Alternativtext kann auch für Computer-Quelltext verwendet werden, um die Programmiersprache zu bezeichnen, was fortgeschrittene Clients zur Syntaxhervorhebung nutzen können.
Jeglicher Text, der nach den führenden "```" einer Vorformatierungs-Umschaltzeile folgt, die den Vorformatierungs-Modus ausschaltet, muss von Clients ignoriert werden.
Vorformatierte Textzeilen sollten dem Nutzer in einer "neutralen" nichtproportionalen Schriftart angezeigt werden, ohne Leerraum oder stilistische Elemente zu verändern. Grafische Clients sollten Bildlauf-Mechanismen verwenden, um vorformatierte Textzeilen anzuzeigen, die breiter als die Anzeigebreite des Gerätes sind, statt diese Zeilen umzubrechen. Wenn Clients vorformatierte Zeilen darstellen, sollten sie Anwendungen wie ASCII-Kunst und Quellcode im Blick haben: insbesondere Quellcode in Programmiersprachen mit signifikantem Leerraum (etwa Python) sollte kopiert und eingefügt werden können, ohne dass aus der Darstellungsweise Probleme entstehen.
Die folgenden fortgeschrittenen Zeilentypen konnen von fortgeschrittenen Clients erkannt werden. Einfache Clients können sie alle wie normale Textzeilen nach 5.4.1 behandeln, ohne das essentielle Funktionen verloren gehen.
Zeilen, die mit "#" beginnen, sind Überschrift-Zeilen. Überschrift-Zeilen bestehen aus einem, zwei oder drei aufeinander folgenden "#"-Zeichen, gefolgt von optionalem Leerraum, gefolgt vom Überschrift-Text. Die Anzahl der "#"-Zeichen bestimmt die "Ebene" einer Überschrift; #, ## und ### können entsprechend wie die HTML-Tags <h1>, <h2>, und <h3> verstanden werden.
Überschrift-Text sollte dem Nutzer angezeigt werden, und Clients können besondere Formatierung nutzen, etwa eine größere oder fette Schriftart, um den Status als Überschrift-Text hervorzuheben (einfache Clients können einfach die ganze Zeile, einschließlich der führenden # darstellen, ohne besondere Darstellung). Allerdings ist die hauptsächliche Motivation für die Definition des Überschrift-Zeilentyps nicht für eine stilistische Behandlung sondern für eine maschinenlesbare Darstellung der internen Struktur des Dokuments. Fortgeschrittene Clients können dies nutzen, um etwa eine automatisch generierte Hierarchie als "Inhaltsverzeichnis" für lange Dokumente in einer Nebenansicht anzuzeigen, um Nutzern das schnelle Springen zu bestimmten Abschnitten eines Dokuments zu ermöglichen, ohne übermäßige Benutzung der Bildlauf-Funktion. CMS-artige Werkzeuge, die automatisch Menüs oder Atom/RSS-Feeds für ein Verzeichnis von "text/gemini"-Dateien erzeugen, können die erste Überschrift der Datei als menschenlesbaren Titel nutzen.
Zeilen, die mit "* " beginnen, sind unsortierte Listeneinträge. Dieser Zeilentyp existiert nur für stilistische Zwecke. Der * kann von fortgeschrittenen Clients durch ein Aufzählungszeichen ersetzt werden. Jeglicher Text nach "* " sollte dem Benutzer wie eine Textzeile angezeigt werden, also umgebrochen, so dass sie "gut" in die Anzeigebreite des Gerätes passt. Fortgeschrittene Clients können dabei den Platz des Aufzählungszeichens beachten, wenn sie einen Listeneintrag umbrechen, so dass alle Textzeilen gleich stark eingerückt sind.
Zeilen, die mit "> " beginnen, sind Zitat-Zeilen. Dieser Zeilentyp existiert, damit fortgeschrittene Clients eine besondere Darstellung nutzen können, um die semantische Information zu vermitteln, dass dieser Text aus einer externen Quelle zitiert wird. Zum Beispiel kann jeder beim Umbrechen langer Zeilen entstehende Zeile ein ">"-Zeichen vorangestellt werden.
Wie die Definition des Statuscodes 1x in 3.2.
Wie bei Statuscode 10, aber für sensible Daten wie Passwörter. Clients sollten eine Eingabemöglichkeit anzeigen, welche die Benutzerangabe nicht auf den Bildschirm ausgibt, um zu verhindern, dass die Eingabe von neugierigen Mitlesern erspäht werden kann.
Wie die Definition des Statuscodes 2x in 3.2.
Wie die Definition des Statuscodes 3x in 3.2.
Die angefragte Resource sollte zukünftig immer von der neuen URL angefragt werden. Werkzeuge wie Suchmaschinen-Indizierer oder Aggregatoren sollten ihre Konfiguration aktualisieren, um zu vermeiden, die alte URL anzufordern, und Endbenutzer-Clients können etwa automatisch Lesezeichen aktualisieren. Clients, die nur die erste Ziffer des Statuscodes beachten, dies trotzdem als temporäre Umleitung behandeln werden. Sie werden trotzdem an der richtigen Stelle herauskommen, aber werden nichts mit der Information anfangen können, das diese Umleitung permanent ist. Somit werden sie eine kleine Laufzeit-Einbuße zahlen, indem sie jedes Mal der Umleitung folgen müssen.
Wie die Definition des Statuscodes 4x in 3.2.
Der Server ist aufgrund von Überlastung oder Wartungsarbeiten nicht verfügbar (siehe auch HTTP 503).
Ein CGI-Prozess oder ähnliches System, um dynamische Inhalte zu erstellen, ist unerwartet abgebrochen oder überschritt die vorgesehene Bearbeitungszeit.
Eine Proxy-Anfrage schlug fehl, weil der Server mit dem entfernten Rechner keine erfolgreiche Transaktion durchführen konnte (siehe auch HTTP 502, 504).
Die Anzahl der Anfrage wird begrenzt. <META> ist eine Ganzzahl von Sekunden, die der Client mindestens warten muss, bevor eine erneute Anfrage an den Server durchgeführt wird. (siehe auch HTTP 429).
Wie die Definition des Statuscodes 5x in 3.2.
Die angefragte Resource konnte nicht gefunden werden, aber könnte zukünftig verfügbar sein. (siehe auch HTTP 404) (Schwierigkeiten, sich diesen wichtigen Status-Code zu merken? Einfach: man knan nichts finden, was in Area 51 versteckt ist!)
Die angefragte Resource ist nicht mehr Verfügbar und wird nicht wieder verfügbar sein. Suchmaschinen und ähnliche Werkzeuge sollten diese Resource aus ihren Indizes entfernen. Aggregatoren sollten diese Resourcen nicht weiter anfragen und ihren menschlichen Nutzern anzeigen, dass diese Resource entfernt wurde (siehe auch HTTP 410).
Die angefragte Resource wird nicht von dem Server angeboten und der Server erlaubt keine Proxy-Anfragen.
Der Server konnte die Anfrage nicht verstehen, vermutlich aufgrund einer missformulierten Anfrage (siehe auch HTTP 400).
Wie die Definition des Statuscodes 6x in 3.2.
Das übermittelte Nutzerzertifikat ist nicht für die angefragte Resource authorisiert. Das Problem liegt nicht am Zertifikat selbst, welches möglicherweise für andere Resourcen authorisiert ist.
Das übermittelte Nutzerzertifikat wurde abgewiesen, weil es ungültig ist. Das Problem liegt am Zertifikat selbst, ohne Einbeziehung der angefragten Resource. Der wahrscheinlichste Grund ist, dass das Startdatum des Zertifikats in der Zukunft oder das Ablaufdatum in der Vergangenheit liegt, aber dieser Statuscode kann auch bedeuten, dass eine Signatur ungültig ist, oder eine Anforderung des X509-Standards nicht erfüllt ist. <META> sollte weitere Informationen über den genauen Fehler enthalten.