💾 Archived View for geminiprotocol.net › docs › eo › specifo.gmi captured on 2024-07-08 at 23:35:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
v0.16.1, 30-a de januaro 2022
Ĉi tio estas pliige malpli kruda skizo de fakta specifo pri Projecto Gemini. Kvankam ĝi ankoraŭ ne estas finpretigita, pluaj ŝanĝoj al la specifo verŝajne estos relative malgrandaj. Vi povas kodumi laŭ ĉi tiu pseŭdo-specifo kaj konfidas, ke ĝi verŝajne ne malfunkciiĝos pro masivaj ŝanĝoj sekvo-semajne; sed vi estas ankoraŭ urgita teni okulon sur daŭranta evoluo de la protokolo kaj fari ŝanĝojn laŭdeve.
Ĉi tiu estas provizita ĉefe por ke homoj povu informiĝi pri tio, kion mi pensas, sen devo legi multegajn malnovajn phlog-afiŝojn kaj konservi notojn.
Reago pri iu ajn parto de ĉi tio estas tre bonvena, bonvolu retpoŝti solderpunk@posteo.net.
La ŝlosilvortoj "DEVAS", "DEVAS NE", "POSTULATA", "DEVUS", "DEVUS NE", "REKOMENDITA", "NE REKOMENDITA", "POVAS", kaj "NEDEVIGA" ĉi-dokumente devus esti interpretitaj kiel priskribite en BCP14 [RFC2119] [RFC8174] kiam, kaj nur kiam, ili aperas tutmajuskle, kiel montrite ĉi tie.
Gemini estas kliento-servila protokolo kun peto-respondaj transakcioj, vaste similaj al gopher aŭ HTTP. Konektoj estas fermitaj fine de unuopa transakcio kaj ne povas esti reuzitaj. Kiam Gemini estas servita per TCP/IP, serviloj devus aŭskulti sur pordo 1965 (la unua pilotata Gemini-misio, Gemini 3, flugis en marto '65). Ĉi tio estas senprivilegia pordo, do estas tre facile ruli servilon kiel "neniu" uzanto, eĉ se, ekz., la servilo estas skribita en Go kaj ne povas faligi privilegiojn laŭ la kutima maniero.
Estas unu tipo de Gemini-transakcio, malglate ekvivala al gopher-peto aŭ HTTP "GET" peto. Transakcioj okazas jene:
K: Malfermas konekton
S: Akceptas konekton
K/S: Kompletigas TLS-manpremon (vidu sekcion 4)
K: Validigas servilan atestilon
K: Sendas peton (unu CRLF-finigitan linion)
S: Sendas respondkaplinion (unu CRLF-termigitan linion), malfermas konekton sub malsukcesaj statoj (vidu 3.1 kaj 3.2)
S: Sendas respondkorpon (tekstajn aŭ binarajn datumojn) (vidu 3.3)
S: Fermas konekton (inklusive de TLS close_notify, vidu sekcion 4)
K: Traktas respondon (vidu 3.4)
Notu, ke klientoj ne estas devigitaj atendi ĝis la servilo fermas la konekton por ekprilabori la respondon. Ĉi tio estas montrita supre nur por simpleco/klareco, por emfazi ke la respondeco fermi la konekton sub tipaj kondiĉoj kuŝas ĉe la servilo kaj ke la konekto devus esti fermita tuj post la kompletigo de la respondkorpo.
Rimedoj gastigataj sur Gemini estas identigitaj per URI-oj kun la skemo "gemini". Ĉi tiu skemo estas sintakse kongrua kun la ĝenerala URI-a sintakso difinita en RFC 3986, sed ne subtenas ĉiujn komponantojn de la ĝenerala sintakso. Specife, la aŭtoritata komponanto estas permesita kaj postulata, sed ĝia "userinfo" subkomponanto NE estas permesita. La gastiga subkomponento estas postulata. La porda subkomponento estas laŭvola, kun defaŭlta valoro de 1965. La voja, demanda, kaj fragmenta komponantoj estas permesitaj kaj havas neniujn specialajn signifojn preter tiuj difinitaj de la ĝenerala sintakso. Malplena vojo ekvivalentas al vojo konsistanta nur el "/". Spacoj en vojoj estu koditaj kiel %20, ne kiel +.
Klientoj DEVUS normaligi URI-oj (laŭ sekcio 6.2.3 de RFC 3986) antaŭ ol sendi petojn (vidu sekcion 2) kaj serviloj DEVUS normaligi ricevitajn URI-ojn antaŭ ol prilabori peton.
Gemini-petoj estas unuopa CRLF-finigita linio kun la jena strukturo:
<URL><CR><LF>
<URL> estas UTF-8 kodita absoluta URL, inkluzive de skemo, kun maksimuma longo de 1024 signoj. La peto DEVAS NE komenci per U+FEFF bajtorda marko.
Sendi absolutan URL anstataŭ nur vojon aŭ elektilon estas efektive ekvivalenta al enkonstruado de HTTP "Host" kaplinio. Ĝi permesas virtualan gastigadon de pluraj Gemini-domajnoj sur la sama IP-adreso. Ĝi ankaŭ permesas al serviloj laŭvole funkcii kiel prokuriloj. Inkluzivi skemojn krom "gemini" en petoj permesas al serviloj laŭvole funkcii kiel protokol-tradukaj enirejoj por, ekz., alporti Gopher-resursojn per Gemini. Prokurado estas laŭvola kaj la plej multaj serviloj estas atenditaj respondi petojn pri rimedoj ĉe sia propra domajno(j).
Klientoj DEVAS NE sendi ion post la unua okazo de <CR><LF> en peto, kaj serviloj DEVAS ignori ion sendita post la unua okazo de <CR><LF>.
Gemini-respondo konsistas el unuopa CRLF-finita linio, laŭvole sekvita de responda korpo.
Gemini-respondaj kaplinioj aspektas jene:
<STATO><SPACO><META><CR><LF>
<STATO> estas ducifera nombra statkodo, kiel priskribita malsupre en 3.2 kaj en aldono 1.
<SPACO> estas unuopa spaca signo, t.e. la bajto 0x20.
<META> estas UTF-8 kodita ĉeno maksimuman longon de 1024 bajtoj, kies signifo estas <STATO> dependa.
Kaj la responda kaplinio kiel tuto kaj <META> kiel subĉeno DEVAS NE komenci per U+FEFF bajtorda marko.
Se <STATO> ne apartenas al la kodgamo "SUKCESO", la servilo DEVAS fermi la konekton post sendo de la kaplinio kaj DEVAS NE sendi respondan korpon.
Se servilo sendas <STATO> kiu ne estas ducifera nombro aŭ <META> kiu longas pli ol 1024 bajtojn, la kliento DEVUS fermi la konekton kaj ignori la respondan kaplinion, sciigante la uzanton pri eraro.
Gemini uzas duciferajn nombrajn statkodojn. Rilataj statkodoj kunhavas la saman unuan ciferon. Grave, la unua cifero de Gemini-statkodoj ne grupigas kodojn en svagajn kategoriojn kiel "klienta eraro" kaj "servila eraro" laŭ HTTP. Anstataŭe, la unua cifero sole provizas sufiĉe da informo por ke kliento determinu kiel manipuli la respondon. Laŭ dezajno, eblas kodi simpla sed funkciplena klienton, kiu nur rigardas la unuan ciferon. La dua ciferon provizas pli fajngrajnan informon, por neambigua servila protokolado, por permesi kodi pli komfortajn interagaj klientojn, kiuj provizas iomete pli simpligitan uzantinterfacon, kaj por permesi kodi pli fortikajn kaj inteligentajn aŭtomatajn klientojn kiel enhavaj kunigiloj, serĉilaj grimpantoj, ktp.
La unua cifero de responda kodo neambigue metas la respondon en unu el ses kategeorioj, kiuj difinas la semantikon de la <META> linio.
Statkodoj komencantaj per 1 estas ENIGO statkodoj, kio signifas:
La petita rimedo akceptas linion de teksta uzanta enigo. La <META> linio estas instigo, kiu estu montrata al la uzanto. La sama rimedo tiam estu petata denove kun la uzanta enigo inkluzivata kiel demanda komponento. Demandoj estas inkluzivitaj en petoj laŭ la kutima ĝenera URL-difino en RFC 3986, t.e., apartigita de la vojo per ?. Rezervitaj signoj uzataj en la uzantenigo devas esti "procento-koditaj" laŭ RFC 3986, kaj ankaŭ spacsignoj devus esti procento-koditaj.
Statkodoj komencantaj per 2 estad SUKCESO statkodoj, kiu signifas:
La peto estis traktita sukcese kaj respondkorpo sekvos la respondkaplinion. La <META> linio estas MIME-meditipo, kiu aplikas al la respondkorpo.
Statkodoj komencantaj per 3 estas ALIDIREKTO statkodoj, kiu signifas:
La servilo estas alidirektanta la klienton al nova loko por la petita rimedo. Ne estas respondkorpo. <META> estas nova URL por la petita rimedo. La URL povas esti absoluta aŭ relativa. Se relativa, ĝi estu solvata kontraŭ la URL uzita en la originala peto. Se la URL uzita en la originala peto enhavis demandĉenon, la kliento DEVAS NE apliki tiun ĉenon al la alidirektila URL, anstataŭe uzante la alidirektilan URL-on "kiel estas". La alidirektilo devus esti konsiderata provizora, t.e., klientoj daŭre petu la rimedon ĉe la originala adreso kaj ne faru konvenecajn agojn kiel aŭtomate gisdatigi legosignojn. Ne estas respondkorpo.
Statkodoj komencantaj per 4 estas PROVIZORA MALSUKCESO statkodoj, kiu signifas:
La peto malsukcesis. Ne estas respondkorpo. La naturo de la malsukceso estas provizora, t.e. identa peto POVAS sukcesi estontece. La enhavo de <META> povas provizi plian informon pri la malsukceso, kaj estu montrata al homaj uzantoj.
Statkodoj komencantaj per 5 estas KONSTANTA MALSUKCESO statkodoj, kiu signifas:
La peto malsukcesis. Ne estas respondkorpo. La naturo de la malsukceso estas konstanta, t.e. indentaj estontaj petoj verŝajne malsukcesos samkiale.. La enhavo de <META> povas provizi plian informon pri la malsukceso, kaj estu montrata al la homaj uzantoj. Aŭtomataj klientoj kiel kunigiloj aŭ indeksantaj rampiloj ne ripetu ĉi tiun peton.
Statkodoj komencantaj per 6 estas KLIENTATESTILO POSTULATA statkodoj, kiu signifas:
La petita rimedo postulas klientatestilo por aliri. Se la peto estis farita sen atestilo, ĝi estu ripetata kun unu. Se la peto estis farita kun atestilo, la servilo ne akceptis ĝin kaj la peto estu ripetata kun malsama atestilo. La enhavo de <META> (kaj/aŭ la aparta 6x kodo) povas provizi plian informon pri atestilaj postuloj aŭ kial atestilo estis malakceptita.
Notu, ke por bazaj interagaj klientoj por homa uzo, eraroj 4 kaj 5 povas esti efike pritraktataj idente, simple montrante la enhavon de <META> sub titolo "ERARO". La provizora/petmanenta distingo ĉefe rilatas al bonkondutaj aŭtomataj klientoj. Bazaj klientoj povas ankaŭ elekti ne subteni klientatestila aŭtentigo, tiukaze nur kvar apartaj stataj pritraktaj rutinoj estas postulata (por statoj komencantaj pet 1, 2, 3 aŭ kombinita 4-aŭ-5).
La plena ducifra sistemo estas detalita en aldono 1. Rimarku, ke poe ĉiu el la ses validj unuaj cifroj, kodo kun dua cifro de nulo estas malspecifa stato tiatipa kun neniu specialaj semantikoj. Tio signifas, ke bazaj serviloj sen ia altnivela funkcieco nur necesas povi resendi kodojn 10, 20, 30, 40 aŭ 50.
La Gemini-starkoda sistemo estis zorge desegnita por ke la pliigita potenco (kaj kongrue pliigita malsimpleco) de la duaj cifroj estas tute laŭvola flanke de kaj serviloj kaj klientoj.
Respondkorpoj nur estas kruda enhavo, teksta aŭ binara, a la gopher. Ne estas subteno por kunpremado, pecetado aŭ ia alia enhava aŭ translokiĝa kodigado. La servilo malfermas la konekton malantaŭ la fina bajto; ne estas "respondfina" signalo kiel la soleca punkto de gopher.
Respondkorpoj nur akompanas respondojn kies kaplinio indikas stato SUKCESO (t.e., statkodo kies unua cifero estas 2). Por tiaj respondoj, <META> estas MIME-meditipo kiel difinita de RFC 2046.
Interretaj meditipoj estas registritaj kun kanona formo. Enhavo translokigita per Gemini DEVAS esti reprezentita en la taŭga kanona formo antaŭ ĝia tranklokigo krom "text" tipoj, kiel difinita en la sekva alineo.
Kiam kanonforme, medisubtipoj de la tipo "text" uzas CRLF kiel linirompon. Gemini malstreĉigas tiun postulon kaj permesas la translokiĝon de tekstaj medioj kun simpla LF sole (sed NE simpla ĈR sole) reprezenti linirompon kiam farite konsekvence tra tuta respondkorpo. Gemini-klientoj DEVAS akcepti CRLF kaj nuda LF kiel reprezentanton de linirompo en tekstaj medioj ricevitaj per Gemini.
Se MIME-tipo komencas per "text/" kaj no charset estas eksplicite donita, la charset estu supozita UTF-8. Obeemaj klientoj DEVAS subteni UTF-8-kodigitajn text/* respondojn. Klientoj POVAS nedivige subteni aliajn kodigojn. Klientoj ricenvanta respondojn laŭ charset kiŭn ili ne povas malkodigi DEVUS grace sciigi al la uzanton tion, kio okazis anstataŭ ol montri rubon.
Se <META> estas malplena ĉeno, la MIME-tipo DEVAS defaŭlti al "text/gemini; charset=UTF-8". La text/gemini meditipo estas difinita en sekcio 5.
Responda traktado fare de klientoj estu informita de la provizita MIME-tipo informo. Gemini difinas unu MIME-tipon propran (text/gemini) kies traktado estas diskutita malsupre en sekcio 5. En ĉiaj aliaj kazoj, klientoj faru "ion prudentan" baze de la MIME-tipo. Minimumemaj klientoj povus adopti strategion presi ĉiujn aliajn text/* respondojn ekranen sen formatado kaj konservi ĉiujn netekstajn respondojn disken.
Uzado de TLS por Gemini-transakcioj estas deviga.
Uzado de la etendaĵo Server Name Indication (SNI) al TLS estas ankaŭ deviga, por faciligi nom-bazitan virtualan gastigadon.
Laŭ RFC-oj 5246 kaj 8446, Gemini-serviloj DEVAS sendi TLS `close_notify` antaŭ ol fermi la konekton sendinte kompletan respondon. Tio estas esenca por malambiguigi kompltigitajn respondojn de respondoj fermitaj antaŭtempe pro reta eraro aŭ atako.
Serviloj DEVAS uzi TLS-version 1.2 aŭ pli altan kaj DEVUS uzi TLS-version 1.3 aŭ pli altan. TLS 1.2 estas kontraŭvole permesita nuntempe por eviti draste redukti la gamon de disponeblaj efektivigbibliotekoj. Espereble TLS 1.3 aŭ pli alta povos esti specifita en proksima estonteco. Klientoj dezirantaj esti "antaŭ la kurbo" POVAS rifuzi konekti al serviloj uzantaj TLS-version 1.2 aŭ malpli altan.
Klientoj povas validigi TLS-konektojn kiel ajn ili deziras (inkluzive neniel) sed la forte REKOMENDITA aliro estas efektivigi malpezan "TOFU" atestilo-pingladan sistemon kiu traktas memsubskribitajn atestilojn kiel unuaklasajn civitanojn. Tio grande reduktas TLS-superŝarĝon sur la reto (nur unu atestilo devas esti sendata, ne tuta ĉeno) kaj malaltigas la baron al eniro por agordi Gemini-ejon (ne bezonas pagi CA aŭ agordi ĉifrigadan cron-laboron, nur faru atestilon kaj iru).
TOFU estas mallongigo por la angla "Trust On First Use" (esperante, konfidu ĉe unua uzo) kaj estas publikŝlosila sekureca modelo simile al tiu uzita de OpenSSH. Konektante al servilo unuafoje, kliento akceptas kiun ajn testilon prezentitan. La fingrospuro kaj limdato de tiu atestilo estas konservitaj en persista datumbazo (kiel la dosiero .known_hosts por SSH) asociitaj kun la servila gastignomo. Je ĉiuj postaj konektoj al tiu gastignomo, la fingrospuro de la ricevita atestilo estas kalkulita kaj komparata kun tiu en la datumbazo. Se la atestilo ne estas tiu antaŭe ricevita sed la limdato de la antaŭa atestilo ne pasis, la uzanto estas montrita averton, kiel tiu montrita al retumilaj uzantoj ricevantaj atestilon sen subskriba ĉeno kondukanta al fidinda CA.
Tiu modelo estas neniel perfekta, sed ĝi ne teruras kaj vaste superas nur akcepti memsubskibitajn atestilojn senkondiĉe.
Kvankam malofte vidite rete, TLS pemesas klientoj identiĝi al serviloj per atestiloj, ekzakte same kiel serviloj tradicie identiĝas al la kliento. Gemini inkluzivas la kapablon por ke serviloj petu en-bande ke kliento ripetu peton kun klientatestilo. Tio estas tre fleksebla, alte sekura sed ankaŭ tre simpla nocio pri klienta identeco kun kelkaj aplikaĵoj:
Memgastigitaj, unu-uzantaj programaroj povas esti faclie kaj fidinde sekuritaj laŭ maniero konata el OpenSSH: la uzanto generas memsubskribitan atestilon kaj aldonas ĝian kradon al servilflanka listo de permesitaj atestiloj, kongrue al la dosiero .authorized_keys de SSH.
Gemini-petoj tipe estos farita sen klientatestilo. Se petita rimedo postulas klientatestilon kaj unu ne estas inkluzivita pete, la servilo povas respondi statkodon 60, 61 aŭ 62 (vidu aldonon 1 malsupre por priskibo de ĉiuj statkodoj rilataj al klientatestiloj). Klientatestilo generita aŭ ŝarĝita responde al tia statkodo havas ĝian skopon ligita al la sama gastignomo kiel la peta URL kaj al ĉiuj vojoj sub la vojo de la peta URL-vojo. Ekz., se peto por gemini://example.com/foo revenas staton 60 kaj la uzanto elektas generi novan klientatestilon responde al tio, la sama atestilo estu uzata por postaj petoj al gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, ktp., ĝis kiam la uzanto decidas forigi la atestilon aŭ provizore malaktivigi ĝin. Interagaj klientoj por homaj uzantoj estas forte rekomenditiaj fari tiajn agojn faĉilaj kaj ĝenerale doni al uzantoj plenan regadon sur la uzo de klientatestiloj.
Samkiel HTML estas la "denaska" respondformato de HTTP kaj simpla teksto estas la denaska respondformato de gopher, Gemini difinas sian propran denaskan respondformaton - kvankam kompreneble, danke al la inkludo de MIME-tipo en la respondkaplinio Gemini povas esti uzata por servi simplan tekston, riĉan tekston, HTML, Markdown, LaTeX, ktp.
Respondkorpoj de tipo "text/gemini" estas tipo de malpeza hiperteksta formato, kiu prenas inspiron de gopher-mapoj kaj de Markdown. La formato permesas pli riĉan tipografiajn eblecojn ol la simpla teksto de Gophĝr, sed restas facilege analizi. La formato estas linio-orientita, kaj kontentiga bildigo povas esti atingita per ununura paso de dokumento, prilaborante ĉiun linion sendepende. Kiel Gopher, ligiloj nur povas esti prezentitaj po unu linie, kuraĝigante netan, list-similan strukturon.
Samkiel la duciferaj Gemini-statkodoj estis desegnitaj por ke simplaj klientoj funkciu ĝuste ignorante la duan ciferon, la formato text/gemini estis desegnita por ke simplaj klientoj ignoru la pli altnivelajn funkciojn kaj ankoraŭ restu tre uzebla.
Kiel subtipo de la supro-nivela meditipo "text", "text/gemini" heredas la parametron "charset" difinitan en RFC 2046. Tamen, kiel notita en 3.3, la defaŭlta valoro de "charset" estas "UTF-8" por "text" enhavo transdonita per Gemini.
Ununura plia parametro specife al la subtipo "text/gemini" estas difinita: la parametro "lang". La valoro de "lang" precizas la naturan lingvon aŭ lingvo(j)n en kiu la tekstenhavo de "text/gemini" dokumento estas skribita. La ĉeesto de la parametro "lang" estas nedeviga. Kiam la parametro "lang" ĉeestas, ĝia interpreto estas tute difinita de la kliento. Ekzemple, kliento uzantaj teksto-al-paroladan teknologion por alirebligi Gemini-enhavon al viddifektitaj uzantoj povas uzi la valoron de "lang" por plibonigi prononcadon de enhavo. Klientoj bildigantaj tekston sur ekrano por determini ĉu teksto estu prezentata maldekstro-al-dekstre aŭ dekstro-al-maldekstre. Simplaj klientoj por uzantoj nur legantaj lingvojn skribitajn maldekstro-al-dekstre povas simple ignori la valoron de "lang". Kiam la paramtero "lang" ne ĉeestas, neniu defaŭlta valoro estu supozita kaj klientoj postulantaj ian ideeton pri lingvon por procezi la enhavon (kiel tekst-al-paroladaj ekranlegiloj) devus fidi sur uzantenigo por determini kiel procedi en la foresto de parametro "lang".
Validaj valoroj por la paramtro "lang" estas komo-apartigitaj listoj de unu aŭ pli lingvaj etikedoj kiel difinitaj en BCP47. Ekzemple:
Kiel menciite, la formato text/gemini estas liniorientita. Ĉiu linio de text/gemini dokumento havas ununuran "liniotipon". Eblas malambigue determini linian tipon nur per inspekto de ĝiaj unuaj tri signoj. Linia tipo determinas kiel ĝi estu prezentita al la uzanto. Iuj ajn detaloj pri prezentado aŭ bildigado kongruanta kun aparta liniotipo estas strikte limigita al tiu ununura linio.
Estas 7 malsamaj liniotipoj sume. Tamen, plenfunkcia kaj specifokonforma Gemini-kliento nur bezonas rekoni kaj trakti 4 el ili; ili estas la "kernaj liniotipoj" (vidu 5.4). Altnivelaj klientoj ankaŭ povas trakti la kromajn "altnivelajn liniotipojn" (vidu 5.5). Simplaj klientoj povas trakti ĉiujn altnivelajn liniotipojn kiel ekvivalentajn al unu el la kernaj linitipoj kaj ankoraŭ oferti sufiĉan uzantan sperton.
La kvar kernaj liniotipoj estas:
Tekstolinio estas la plej baza liniotipo - ĉiu linio kiu ne kongruas kun la difino de alia liniotipo difinita sube defaŭltas al tekstolinio. La plej multo da linioj en tipa text/gemini dokumento estos tekstolinioj.
Tekstolinioj devus esti prezentitaj al la uzanto post linifaldado al la ĝusta larĝo laŭ la klienta vidujo (vidu malsupre). Tekstolinioj povas esti prezentitaj al la uzanto laŭ vidplaĉa maniero por ĝenerala legado, la preciza signifo pri kiu estas laŭ klienta elekto. Ekzemple, tiparoj de ŝanĝiĝema larĝo povas esti uzataj, interspaco povas esti normaligita, kun spacoj inter frazoj igitaj pli larĝaj ol interspaco inter vortoj, kaj alia tiaj tipografiaj belaĵoj povas esti aplikitaj. Klientoj povas permesi uzantojn agordi la aperon de tekstolinioj per ŝanĝado de la tiparo, tipara grandeco, teksta kaj fona koloroj, ktp. Aŭtoroj ne devus atendi ekzerci regadon sur la preciza bildigo de sia tekstolinioj, nur sur ilia fakta teksta enhavo. Enhavo kiel ASCII-arto, komputila fontkodo, ktp., kiu eble aperas malĝuste kiam traktita tiel devus esti enfermita inter antaŭformataj ŝanĝlinioj (vidu 5.4.3)
Malplenaj linioj estas ekzemploj de tekstolinioj kaj havas nenian specialan signifon. Ili devus esti bildigitaj unuope kiel vertikala malplena spaco kiam ajn ili okazas. Ĉi-maniere, ili analogas al <br/> etikedojn en HTML. Sinsekvaj malplenaj linioj devus NE esti kolapsigitaj en malpli malplenajn liniojn. Notu ankaŭ, ke sinsekvaj nemalplenaj tekstolinioj ne formas ian koheran aron aŭ blokon simile al "alineo": ĉiu tekstolinio estas sendependa ento.
Tekstolinioj tro longaj por konveni klientan montraparaton DEVUS esti "falditaj" por konveni, t.e. longaj linioj devus esti fenditaj (ideale ĉe blankspaco aŭ ĉe streketoj) en multoblajn sinsekvajn liniojn de aparato-adekvata larĝo. Tiu faldado estas aplikta al ĉiu linio sendepende. Multoblaj sinsekvaj linioj pli mallongaj ol la klienta montraparato DEVAS NE esti kombinitaj en malpli, pli longajn liniojn.
Por preni plenavantaĝon de tiu maniero de teksta formatigo, aŭtoroj de text/gemini enhavo DEVUS eviti malmole faldi al specifa fiksa lonĝo, kontraste la konvencio en Gopher-spaco kie teksto estas tipe faldita ĉe 80 signoj aŭ malpli. Anstataŭe, teksto kiu devus esti prezentita kiel apuda bloko devus esti skribita kiel ununura longa linio. Plej multaj tekstredaktiloj povas esti agorditaj al "mola faldo", t.e. skribi tian dosieron montrante la longajn liniojn falditajn ĉe vortrandoj por konveni al la montraparato de la aŭtoro.
Aŭtoroj insistantaj pri malmole faldi sian enhavon DEVUS konscii, ke la enhavo aperos bonorde ĉe klientoj, kies montraparato estas same larĝa kiel la malmole faldita longo aŭ pli longa, sed aperos kun neregulaj liniolarĝoj ĉe malpli larĝaj klientoj.
Linioj komencantaj per la du signoj "=>" estas ligillinioj, kiuj havas la sekvan sintakson:
=>[<blankspaco>]<URL>[<blankspaco><UZANTAMIKA LIGILNOMO>]
kie:
All the following examples are valid link lines:
Jen ekzemploj de validaj ligillinioj:
=> gemini://example.org/ => gemini://example.org/ Ekzempla ligilo => gemini://example.org/foo Alia ekzempla ligilo ĉe la sama gastigo => foo/bar/baz.txt Relativa ligilo => gopher://example.org:70/1 Ligilo de gopher
URL-oj en ligillinioj devas havi reservitajn signojn kaj spacojn elcent-enkoditaj laŭ RFC 3986.
Notu, ke ligilaj URL-oj povas havi skemojn krom gemini. Tio signifas, ke Gemini-dokumentoj povas simple kaj elegante ligi al dokumentoj gastigitaj per aliaj protokoloj, malkiel gopher-mapoj, kiuj povas ligi al ne-gopher-enhavo per ne-norma adaptigo de la `h` erotipo.
Klientoj povas prezenti ligilojn al uzantoj laŭ deziro de la klientaŭtoro, tamen klientoj NE DEVAS aŭtomate fari ajnan retan konekton kiel parto de prezento de ligiloj, kies skemo kongruas kun reta protokolo (ekz. ligiloj komencantaj per gemini://, gopher://, https://, ftp://, ktp.).
Linio kies unuaj tri signoj estas "```" (t.e. tri sinsekvaj malantaŭaj tikmarkoj kun nenia gvida blankspaco) estas antaŭformata ŝanĝlinio. Tiuj linioj devus NE esti inkluzivitaj en la bildigita eligo prezentita al la uzanto. Anstataŭe, ĉi tiuj linioj ŝanĝas la analizilon inter antaŭformata reĝimo "ŝaltita" aŭ "malŝaltita". Antaŭformata reĝimo devus esti "malŝaltita" komence de la dokumento. La nuna stato de antaŭformata reĝimo estas la nura ena stato, kiun analizilo estas postulata konservi. Kiam antaŭformata reĝimo estas "ŝaltita", la kutimaj reguloj por identigi liniotipojn estas suspenditaj, kaj ĉiuj linioj devus esti identigitaj kiel antaŭformataj linioj (vidu 5.4.4).
Antaŭformataj ŝanĝlinioj povas estis pensitaj kiel analogaj al <pre> kaj </pre> etikedoj en HTML.
Teksto sekvanta la gvidan "```" de antaŭformata ŝanĝlinio kiu ŝanĝas antaŭformatan reĝimon ŝaltita POVAS esti interpretita kiel "altteksto" apartenanta al la antaŭformataj tekstlinioj kiuj sekvas la ŝanĝlinion. Uzo de altteksto estas laŭ la bontrovo de la kliento, kaj simplaj klientoj povas ignori ĝin. Altteksto estas rekomendita por ASCII-arto aŭ simila ne-teksta enhavo kiu, ekzemple, ne povas esti signifoplene komprenita kiam bildigita per ekranlegilo aŭ utile indeksita de serĉilo. Altteksto ankaŭ povas esti uzata por komputila fontkodo por identigi la programlingvon, kiun altnivelaj klientoj povas uzi por sintaksa reliefigo.
Teksto sekvanta la gvidan "```" de antaŭformata ŝanĝlinio kiu ŝanĝas antaŭformatan reĝimon malŝaltita DEVAS esti ignorita de klientoj.
Antaŭformataj tekstlinioj devus esti prezentitak al la uzanto laŭ "neŭtrala", fikslarĝa tiparo sen ŝanĝo al blankspaco aŭ stilaj plibonigoj. Grafikaj klientoj devas uzi rulajn mekanismojn por prezenti antaŭformatajn tekstliniojn pli longajn ol la klienta vidujo, prefere ol faldigo. Prezentante antaŭformatajn tekstliniojn, klientoj devas mensoteni uzojn kiel ekzemple ASCII-arto kaj komputila fontkodo; specife, fontkodo por lingvoj kun signifoplena blankspaco (ekz. Python) devus esti kopiita kaj algluita el la kliento en dosieron kaj interpretita/kompilita sen problemoj venantaj de kiel la kliento ilin prezentis.
La jenaj altnivelaj liniotipoj POVAS esti rekonitaj de altnivelaj klientoj. Simplaj klientoj POVAS trakti ĉiujn el ili kiel tekstliniojn laŭ 5.4.1 sen perdi esencajn funkciojn.
Linioj komencantaj per "#" estas titollinioj. Titollinioj konsistas el unu, du aŭ tri sinsekvaj "#" signoj, sekvata de nedeviga blankspaco, sekvata de titola teksto. La nombro da # signoj indikas la "nivelon" de titolo: #, ## kaj ### povas esti opiniitaj kiel analogaj al <h1>, <h2> kaj <h3>, respektive, en HTML.
Titolteksto devus esti prezentita al la uzanto, kaj klientoj POVAS uzi specialan formaton, ekz. pli granda aŭ grasa tiparo por indiki ĝian titolan staton (simplaj klientoj povas simple presi la linion, inkluzive de ĝiaj ĉefaj #j, sen ajna stilo). Tamen, la ĉefa motivo por la difino de titollinoj ne estas stila sed por provizi maŝinlegeblan reprezenton de la ena strukturo de la dokumento.Altnivelaj klientoj povas uzi tiujn informojn, ekzemple, por montri aŭtomate generitan kaj hierarkie formatitan "enhavtabelon" por longa dokumento en flanka panelo, permesante al uzantoj facile salti al specifaj sekcioj sen troa rulado. CMS-stilaj iloj aŭtomate generantaj menuojn aŭ Atom/RSS-fluojn por dosierujo de text/gemini dosieroj povas uzi la unuan titolon en la dosiero kiel hom-amika titolo.
Linioj komencantaj per "* " estas neordigitaj listeroj. Tiu liniotipo ekzitas pure por stilaj kialoj. La * povas esti anstataŭigita de kuglosimbolo en altnivelaj klientoj. Teksto malantaŭ la "* " devus esti prezentita al la uzanto kvazaŭ ĝi estus tekstlinio, t.e. faldita por konveni la vidujon kaj formatita "plaĉe". Altnivelaj klientoj povas kontopreni la spacon de la kuglo-simbolo kiam faldas longajn listerojn por certigi, ke ĉiu linio de teksto apartena al la listero estas kompensita la saman distancon de la maldekstro de la ekrano.
Linioj komencantaj per ">" estas citlinioj. Ĉi tiu liniotipo ekzistas por ke altnivelaj klientoj povas uzi distingan stilon por sciigi legantojn la gravajn semantikajn informojn, ke certa teksto estas citita el ekstera fonto. Ekzemple, faldigante longajn liniojn al la vidujo, ĉiu rezulta linio povas havi ">" simbolon metita antaŭe.
Laŭ difino de unucifera kodo 1 en 3.2.
Laŭ statkodo 10, sed por uzo kun tikla enigo kiel pasvortoj. Klientoj devus prezenti la instigilon laŭ statkodo 10, sed la uzanta enigo devus ne esti eĥita ekrane por malhelpi ĝin esti legita de "ŝultrosurfantoj".
Laŭ difino de unucifera kodo 2 en 3.2.
Laŭ difino de unucifera kodo 3 en 3.2.
La petita rimedo devus esti konstante petita ĉe la nova URL provizita estonte. Iloj kiel serĉilaj indeksigoj aŭ enhavaj kuniloj devus ĝusdatigi sian agordon por eviti peti la malnovan URL-on, kay finuzantaj klientoj povas aŭtomate ĝisdatigi legosignojn, ktp. Notu, ke klientoj, kiuj nur atentas la komencan ciferon de statkodoj, traktos ĉi tion kiel provizoran alidirektilon. Ili ankoraŭ finiĝos ĝustloke; ili simple ne povos uzi la scion ke ĉi tiu alidirektilo estas konstanta, do ili pagos malgrandan operacian punon devante sekvi la alidirektilon ĉiufoje.
Laŭ difino de unucifera kodo 4 en 3.2.
La servilo neatingeblas pro troŝarĝo aŭ prizorgado. (kp HTTP 503)
CGI-procezo, aŭ simila sistemo por generado de dinamika enhavo, finiĝis neatendite aŭ eltempiĝis.
Prokurila peto malsukcesis ĉar la servilo ne povis sukcese kompleti transagon kun la fora gastigo. (kp HTTP 502, 504)
Rapideca limigado efektas. <META> estas entjera nombro de sekundoj, kiujn la kliento devas atendi antaŭ ol alia peto estas farita al ĉi tiu servilo. (kp HTTP 429)
Laŭ difino de unucifera kodo 5 en 3.2.
La petita rimedo ne povis esti trovita sed eble haveblas estonte. (kp HTTP 404)
La petita rimedo jam ne haveblas kaj ne haveblos denove. Serĉiloj kaj similaj iloj devus forigi ĉi tiun rimedon de siaj indeksoj. Enhavkuniloj devus ĉesi peti la rimedon kaj sciigi al siaj homaj uzantoj, ke la abonita rimedo estas forinta. (kp HTTP 410)
La peto estis por rimedo ĉe domajno ne servita de la servilo kaj la servilo ne akceptas prokurilajn petojn.
La servilo maleblis analizi la klientan peton, supozeble pro misformita peto. (kp HTTP 400)
Laŭ difino de unucifera kodo 6 en 3.2.
La provizita klientatestilo ne estas aprobita por aliri la apartan petitan rimedon. La problemo ne estas je la atestilo mem, kiu eble estas aprobita por aliaj rimedoj.
La provizita klientatestilo ne estis akceptita ĉar ĝi ne validas. Tio indikas problemon je la atestilo mem, sen konsidero pri la aparta petita rimedo. La plej verŝajna kialo estas, ke la atestila ekvaliddato estas estonte aŭ ĝia findato pasis, sed ĉi tiu kodo eble ankaŭ indikas malvalidan subskribon, aŭ malobservo de normaj postuloj X509. <META> devus provizi plian informon pri la ekzakta eraro.