💾 Archived View for geminiprotocol.net › docs › ja › tech-overview.gmi captured on 2024-08-18 at 17:15:16. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-07-08)

🚧 View Differences

-=-=-=-=-=-=-

プロジェクトGeminiの技術的な概観

序

本文書は完全な「Gemini技術スタック」、つまりネットワーク輸送プロトコルと「gemtext」マークアップ形式の両方のラフスケッチを提供します。スケッチは不正確であるという意味での「ラフ」ではなく、単にGeminiの全ての面を完全に詳細に示していないという意味です。プロジェクトGeminiのFAQにあるよりも水面下でのGeminiの仕組みについてずっと詳しい情報を提供していますが、分かれている正式な仕様ほどには詳しくありません。技術的に洗練された読み手の好奇心を満足させるには充分でしょう。またエッジケースや応用アプリケーションを抜きにすればそれなりにうまく動くソフトウェアを手早く実装することもできます。これは規範的な文書ではありません。ここに書かれていることと2つの正式な仕様の何れかと矛盾するときは正式な仕様が優越します。

プロジェクトGeminiのFAQ

Geminiのネットワークのプロトコルの仕様

Geminiハイパーテキスト形式（「gemtext」）の仕様

1 概観

Geminiは要求応答型トランザクションに特化したクライアントサーバー手続きです。大まかにはgopherやHTTPに似ています。接続は単一のトランザクションの一方で閉じ、再利用できません。GeminiがTCP/IP上でサーバーから与えられるとき、サーバーはポート1965（最初の有人GeminiミッションであるGemini3の年であり、'65年3月に飛行しました）で待ち受けます。これは非特権的なポートであるため、「何者でもない」利用者としてサーバーを走らせることはとても簡単です。例えば、たとえサーバーがGoで書かれており、そのために伝統的なやり方で権限を施せないとしてもです。

1.1 Geminiのトランザクション

Geminiのトランザクションには1種類あり、大まかにgopher要求やHTTP「GET」要求と等価です。トランザクションは以下のように発生します。

C: 接続を開く

S: 接続を受け付ける

C/S: TLSハンドシェイクを完了（4節参照）

C: サーバー証明書を検証（4.2を参照）

C: 要求を送信（CRLFで終端する1行）（2節を参照）

S: 応答ヘッダを送信（CRLFで終端する1行）。成功でない状態下では接続を閉じる（3.1と3.2を参照）

S: 応答本体を送信（テキストないしバイナリデータ）（3.3参照）

S: 接続を閉じる（TLSのclose_notifyを含む。4節参照）

C: 応答を処理（3.4参照）

なお、クライアントはサーバーが応答処理を開始するために接続を閉じるまで待機する義務はありません。上記では簡単さ・明快さのためにこのように示されており、典型的な状況下で接続を閉じる責任はサーバー側にあること、接続は応答本文の完了後直ちに閉じられるべきであることを強調しておきます。

1.2 GeminiのURIスキーム

Geminiを介してホストされる資源はスキーム「gemini」を持つURIを使って指定されます。このスキームはRFC 3986で定義される一般的なURIの構文と構文上互換性がありますが、一般的な構文の全ての要素には対応していません。特に、権限的な要素が許可されており要件にもなっていますが、その利用者情報の部分要素は許可されていません。ホストの部分要素は必須です。ポートの部分要素は省略可能であり、既定値は1965です。パス、クエリ、フラグメントの要素は許可されており、一般的な構文により定義されている範囲を越えた特別な意味を持ちません。空のパスは「/」からのみ構成されるパスと等価です。パス中の空白は+ではなく%20で符号化されるべきです。

クライアントは要求を送る前に（RFC 3986により）URIを正規化すべきです。サーバーは要求を処理する前に受け取ったURIを正規化すべきです。

2 Geminiの応答

Geminiの要求はCRLFで終端する以下の構造を持つ単一の行です。

<URL><CR><LF>

<URL>はスキームを含めてUTF-8で符号化された絶対URLであり、最大長が1024バイトです。要求はU+FEFFバイト順序印から始まってはなりません。

絶対URLの代わりにパスやセクタのみを送ることはHTTPの「Host」ヘッダを構築することと等価な効果があります。同じIPアドレスに複数のGeminiドメインの仮想ホストをすることを許します。また、任意でプロキシとして機能することも許可されます。「gemini」以外のスキームの要求を含めることで、サーバーが任意でプロトコルを翻訳する関門として機能することを許可します。例えばGemini上でgopher資源を取得するなどです。プロキシは任意であり、大多数のサーバーはそれぞれのドメインの資源の要求にのみ応答することが期待されます。

クライアントは要求中の最初の<CR><LF>の出現以降に何らも送ってはなりません。またサーバーは最初の<CR><LF>の最初の出現以降に送られたものは何であれ無視しなければなりません。

3 Geminiの応答

Geminiの応答は単一のCRLFで終端する単一のヘッダ行と、任意で続く応答本文からなります。

3.1 応答ヘッダ

Geminiの応答ヘッダは以下のような形式です。

<状態><空白><メタ情報><CR><LF>

<状態>は2桁の数値の状態コードであり、3.2と補遺1に後述する通りです。

<空白>は単一の空白文字です。つまりバイト0x20です。

<メタ情報>はUTF-8で符号化された最大長1024バイトの文字列です。その意味は<状態>に依存します。

全体の応答ヘッダと部分文字列としての<メタ情報>はU+FEFFバイト順序印で始まってはなりません。

<状態>が「成功」のコードの範囲に属していない場合、サーバーはヘッダを送った後に接続を閉じなければなりません。また応答本文を送ってはなりません。

サーバーが2桁の数字でない<状態>や長さが1024バイトを越える<メタ情報>を送る場合、クライアントは接続を閉じて応答ヘッダを無視し、利用者にエラーを知らせるべきです。

3.2 状態コード

Geminiは2桁の数値の状態コードを使います。関連する状態コードは最初の桁で同じ値を共有します。重要なこととして、Geminiの状態コードの最初の桁はHTTPにあるような「クライアントエラー」や「サーバーエラー」のような曖昧な分類にコードを集合で分けてはいません。その代わり、最初の桁だけでクライアントがどのように応答を扱えばよいかを判定するに充分な情報を提供します。設計上では、最初の桁を見るだけで単純ですが完全な機能を持つクライアントを書くことが可能となっています。2つ目の桁ではより詳細な情報が提供されています。曖昧さのないサーバーのログ記録のためであり、ちょっとばかり能率的な利用者インターフェースを提供する簡単で対話的なクライアントを書くことができます。また内容収集器や検索エンジンクローラなどのようなより強固で賢く自動的なクライアントを書くこともできます。

応答コードの最初の桁は曖昧さなく応答を6つの分類に仕分けます。この分類は<メタ情報>行の意味論を定義します。

3.2.1 1x (INPUT)

1から始まる状態コードはINPUT状態コードです。その意味は次の通りです。

要求された資源はテキストの利用者の入力を受け付けます。<META>行は利用者に表示されるべき質問内容です。それから問い合わせ要素を含む利用者の入力と共に再び同じ資源を要求すべきです。要求に含まれる問い合わせはRFC3986での通常の一般的なURLに沿うものです。つまり?でパスと区別されます。利用者の入力中の予約文字はRFC2986により「パーセント文字で符号化」されなければなりません。また空白文字もまたパーセント文字で符号化すべきです。

3.2.2 2x (SUCCESS)

2から始まる状態コードはSUCCESS状態コードです。その意味は以下の通りです。

応答は適切に処理され、応答本文が応答ヘッダの後に来ます。<メタ情報>行はMIMEメディア種別であり応答本文に適用されます。

3.2.3 3x (REDIRECT)

3で始まる状態コードはREDIRECT状態コードです。その意味は次の通りです。

サーバーはクライアントを要求された資源のある新しい場所にリダイレクトします。応答本文はありません。<META>は要求された資源のある新しいURLです。URLは絶対的ないし相対的なものです。相対的であれば元の要求で使ったURLに対して解決されます。元の要求で使われていたURLにクエリ文字列が含まれていた場合、クライアントはこの文字列をリダイレクトのURLに適用してはならず、リダイレクトのURLを「そのまま」使わなければなりません。リダイレクトは一時的なものと見做されるべきです。つまりクライアントは資源を元のアドレスで要求し続けるべきであり、自動的にブックマークを更新するような便宜がはかられるべきではありません。応答本文はありません。

3.2.4 4x (TEMPORARY FAILURE)

4から始まる状態コードはTEMPORARY FAILURE状態コードです。その意味は以下の通りです。

要求が失敗しました。応答本文はありません。失敗の性質は一時的なものです。つまり将来的に同一の要求は成功する可能性があります。<メタ情報>の内容で失敗の追加情報を提供して構いませんし、それは人間の利用者に表示すべきです。

3.2.5 5x (PERMANENT FAILURE)

5から始まる状態コードはPERMANENT FAILURE状態コードです。その意味は以下の通りです。

要求が失敗しました。応答本文はありません。失敗の性質は永久のものです。つまり将来に亙って同一の要求は同じ理由により確実に失敗します。<メタ情報>の内容では失敗についての追加情報を提供して構いませんし、人間の利用者に表示されるべきです。収集器や索引生成クローラのような自動的なクライアントはこの要求を繰り返すべきではありません。

3.2.6 6x (CLIENT CERTIFICATE REQUIRED)

6から始まる状態コードはCLIENT CERTIFICATE REQUIRED状態コードです。その意味は以下の通りです。

要求された資源はクライアントがアクセスする際の証明書を要求します。要求が証明書なしにされた場合、要求はその1度だけにすべきです。要求が証明書付きでされた場合、サーバーは受け付けず要求は別の証明書で繰り返されるべきです。<メタ情報>の内容（また特定の6xコード）で証明書の要件についての追加情報や証明書が拒絶された理由を提供して構いません。

3.2.7 補足

なお、人間が使用するための基本的な対話的クライアントのための補足として、エラー4ないし5は「エラー」の見出しの下に<メタ情報>の内容を単に表示するだけで、効果的にそれぞれを扱うことができます。エラーが一時的なものか恒常的なものかを区別することは、主に自動的なクライアントの良い振舞いに関係します。基本的なクライアントはクライアント証明書の認証に対応しないことを選んでも構いません。その場合、（1、2、3、4と5の組み合わせから始まる状態に対する）4つのそれぞれの状態制御の仕組みが必要です。

完全な2桁のシステムは補遺1で詳解されます。なおそれぞれの妥当な6つの最初の桁について、2桁がゼロのコードは特別な意味のない種類の一般的な状態に対応します。つまり、発展的な機能のない基本的なサーバーは10、20、30、40、50のコードを返しさえすれば良いのです。

Geminiの状態コードシステムは慎重に設計されており、2桁目の表現力（とそれに伴って増大する複雑性）がサーバーとクライアントの両方にとって完全に「任意で有効にできる」もになるようにしています。

3.3 応答本文

応答本文は単なる生の内容であり、gopherよろしくテキストないしバイナリです。圧縮や断片化、内容や転送の符号化といった類の対応はありません。サーバーは最終バイトの後に接続を閉じ、gopherの孤立ドットのような「応答末尾」信号はありません。

応答本文はヘッダがSUCCESS状態（つまり状態コードの最初の桁2）を示すときにのみ付属するものです。そのような応答において、<メタ情報>はRFC 2046に定義されるMIMEメディア種別です。

インターネットメディア種別は正統な形式で登録されたものです。Geminiを介して転送される内容は、転送に先立って適切且つ正統な形式で表現されなければなりません。ただし次の段落で定義されるように、「text」種別は例外です。

正統な形式において、「text」のメディア副種別では、テキスト行の改行としてCRLFが使われます。Geminiはこの要件を緩め、LF単独のテキストメディアの転送を許します（ただしCR単独は許しません）。ただし、応答本文全体で一貫性を持って改行されている場合に限ります。Geminiのクライアントでは、Geminiを介して受け取ったテキストメディア中のCRLFとLFを、改行の表現として受け付けなければなりません。

MIME種別が「text/」から始まっており文字集合が明示的に与えられていない場合、文字集合はUTF-8であることが仮定されるべきです。準拠するクライアントはUTF-8で符号化されたtext/*の応答に対応しなければなりません。クライアントは任意で他の符号化方式に対応しても構いません。複合できない文字集合で応答を受け取ったクライアントは文字化けを表示する代わりに起こったことを丁寧に利用者に伝えるべきです。

<メタ情報>が空文字列である場合、MIME種別は既定で「text/gemini; charset=utf-8」でなければなりません。text/geminiメディア種別は5節で定義されます。

3.4 応答本文の取り扱い

クライアントによる応答の扱いは提供されたMIME種別の情報により実施されるべきです。Geminiは独自のMIME種別（text/gemini）を定義しており、この扱いについては5節で後述されます。その他全ての場合でクライアントはMIME種別に基づいて「何らかの意味のある」ことをすべきです。最小限主義のクライアントは書���化することなく画面にgemtext以外全部のtext/*の応答を出力する戦略を採っても構いませんし、テキスト応答でないものをディスクに保存するというのも良いでしょう。unixシステム向けのクライアントは、テキストでない種別の扱いについて、/etc/mailcapにインストールされたプログラムをあたると良いでしょう。

4 TLS

GeminiのトランザクションにTLSを使用することは必須です。

TSLへのサーバー名表示 (Server Name Indication; SNI) の仕様も必須です。これにより名前による仮想ホストが活用できます。

RFC 5246及び8446により、Geminiのサーバーは完全な応答を送った後に接続を閉じるのに先立ちTLSの`close_notify`を送らなければなりません。これはネットワークのエラーや攻撃により不完全に閉じた応答と完遂した応答を区別するために必須です。

4.1 バージョン要件

サーバーはTLSバージョン1.2以上を使わなければなりません。またTLSバージョン1.3以上を使うべきです。TLS 1.2は、利用できる実装ライブラリの範囲を劇的に減らしてしまうことを避けるために当面の間、気は進まないものの許可されています。近い将来、TLS 1.3以上を使う仕様にできることを望んでいます。時代を先取りするクライアントはTLSバージョン以下を使うサーバーへの接続を拒絶しても構いません。

4.2 サーバー証明書の検証

クライアントはTLS接続を好きなだけ検証して良い（全くしなくても良い）ですが、強く推奨されるやり方は、軽量な「TOFU」証明書ピン留めシステムを実装することです。これは自己証明証明書を第一級市民として扱うものです。これによりネットワーク上の余計な負担が大幅に減り（証明書が送られるだけでよく、鎖全体でなくて良くなります）、Geminiのサイトを設定する敷居が低くなります（CAに支払いをしたりLet's Encryptのcronジョブを設定したりすることなく、証明書を作って実行するだけになります）。

TOFUは「Trust On First Use」から取っており、OpenSSHで使われる公開鍵セキュリティモデルに似たものです。最初にGeminiクライアントがサーバーに接続したとき、何であれ提示された証明書を受け付けます。その証明書の指紋と期限日は（SSHの.known_hostsファイルと同様に）永続的なデータベースに保存され、サーバーのホスト名とポート番号に紐付きます。以降は同じホスト名と同じポート番号への接続では、受け取った証明書の指紋が計算されデータベース中のものと比較されます。もし証明書を以前に受け取っておらず、以前の証明書の期限日が過ぎていなければ、利用者には警告が表示されます。これはwebブラウザの利用者が信頼できるCAに至る署名鎖のない証明書を受け取ったときの表示と似たものです。

このモデルは完全とは言い難いものですが、自己証明証明書を単に無条件に受け付けるよりはひどくはなく、ずっとマシです。

4.3 クライアント証明書

webでは滅多に見ませんが、TLSではクライアントが証明書を使ってサーバーに自己を証明することができます。ちょうどサーバーが伝統的に自身をクライアントに証明するのと同じやり方です。Geminiにはサーバーに受け付ける方向の要求をする機能が含まれており、クライアントはクライアントの証明書付きの要求を繰り返します。これは大変柔軟であり、かなりセキュアなのですが、幾つかの応用例でクライアントの同定についてとても単純な気付きがあります。

• 必要に応じて生成され使用した後に直ちに削除される短命のクライアント証明書は、アプリケーションにとってサーバー側の状態を維持する「セッション識別子」として使えます。この役割において、クライアント証明書はHTTPのクッキーの代わりとして機能しますが、クッキーとは異なりクライアントにより自発的に生成され、クライアントが証明書と照合するキーを削除してしまえば、（いわゆる「スーパークッキー」とは異なり）サーバーは後で同じ値に「復活」することが全く不可能になります。
• 長命のクライアント証明書は複数の利用者がいるアプリケーションで利用者を確実に同定でき、ブルートフォースの可能性があるパスワードの必要はありません。証明書のハッシュから利用者の識別情報に対応付けるデータベースが盗み取られたとしてもセキュリティの危機ではなく、証明書へのレインボーテーブル攻撃は実行可能ではありません。
• セルフホストの単一利用者のアプリケーションはOpenSSHと似たやり方で簡単且つ確実にセキュアにできます。利用者は自己署名した証明書を生成し、許可される証明書のサーバー側の一覧にハッシュを追加します。これはSSHにおける.authorized_keysに似たような機構です。

Geminiの要求は典型的にはクライアント証明書なしで行われます。もし要求された資源にクライアント証明書が必要で、要求に含まれていなければ、サーバーは状態コード60、61、62で応答できます（補遺1のクライアント証明書に関係する全ての状態コードの説明を参照）。それらの状態コードに対する応答で生成されたり読み込まれたりしたクライアント証明書は、要求するURLと同じホスト名とポート番号に紐付くスコープと要求するURLのパスの配下にある全てのパスを受け持ちます。例えばgemini://example.com/fooが状態60を返し、利用者が新しいクライアント証明書を生成してこれに応答することを選んだ場合、その同じ証明書が以降のgemini://example.com/fooやgemini://example.com/foo/bar、gemini://example.com/foo/bar/baz等々への要求で使われ、利用者が証明書を削除すると決めたり一時的に非活性にしたりするときまで続きます。人間の利用者のための対話的なクライアントについては、そのような動作を簡単にできるように、そしてクライアント証明書の使用に関して利用者に包括的に完全な制御を与えるように強くお勧めします。

5 text/geminiメディア種別

5.1 概観

HTMLがHTTPの「独自の」応答形式であり、素のテキストがgopherの独自の応答形式であるのと同じ意味で、Geminiは独自の応答形式を定義しています。ただしもちろん、応答ヘッダにMIME種別を含めているおかげで、Geminiは素のテキスト、リッチテキスト、HTML、Markdown、LaTeXなどをサーバーから送ることができます。

種別「text/gemini」の応答本文は軽量ハイパーテキスト形式の一種であり、gophermapsとMarkdownから着想を得ています。この形式ではGopherの素のテキストより豊かな表示上の可能性を許していますが、非常に解析が簡単であることは保たれています。形式は行指向であり、各行を独立して処理し、文書を一度だけ通しつつ呈示を満足に行えます。gopherに従い、リンクは1行毎にのみ表示でき、整っている箇条書のような構造を推進します。

単純なクライアントが2桁目を無視しても正しく機能するようにGeminiの2桁の状態コードが設計されているのと似ており、text/gemini形式は単純なクライアントが発展的な機能を無視してもとても有用であることは変わらないように設計されています。

5.2 引数

「text」最上位メディア種別の副種別である「text/gemini」は、RFC2046に定義されている「charset」引数を継承します。しかしながら、Geminiを介して転送される「text」内容の「charset」の既定値は「UTF-8」です。

「text/gemini」副種別で個別に定義されている追加の引数が1つあります。それは「lang」引数です。「lang」の値は「text/gemini」文書のテキスト内容が書かれている自然言語を示すものです。「lang」引数の存在は省略できます。「lang」引数があるとき、その解釈は完全にクライアントで定義されます。例えば、テキスト音声合成の技術を使ってGeminiで表された内容が目の不自由な利用者にとってアクセシビリティのあるものにするクライアントは、「lang」値を使って内容の発音を向上しても良いでしょう。テキストを画面に呈示するクライアントは「lang」値を使ってテキストが左横書きと右横書きのどちらで表示すべきかを判定しても良いでしょう。左横書きで書かれた言語だけを読む利用者用の単純なクライアントでは、単に「lang」値を無視すれば良いでしょう。「lang」引数が無い場合、何らの既定値も仮定されず、（テキスト合成音声の画面読み上げ器といった）内容を処理するための言語の決定が必要なクライアントは、「lang」引数が欠落している場合にどのように処理を続ければ良いか決定するための利用者の入力に依存すべきです。

「lang」引数の妥当な値はBCP47に定義される1つ以上の言語タグのコンマ区切のリストです。例えば以下です。

• 「text/gemini; lang=en」は英語で書かれたtext/gemini文書を示します
• 「text/gemini; lang=fr」はフランス語で書かれたtext/gemini文書を示します
• 「text/gemini; lang=en,fr」は英語とフランス語が混ぜ書きされた文書を示します
• 「text/gemini; lang=de-CH」はスイスドイツ語で書かれたtext/gemini文書を示します
• 「text/gemini; lang=sr-Cyrl」はキリル文字を使うセルビア語で書かれた、text/gemini文書を示します
• 「text/gemini; lang=zh-Hans-CN」は、中国本土で使われている簡体字を使う、中国語で書かれたtext/gemini文書を示します

5.3 行指向の設計

既に言及したように、text/gemini形式は行指向です。text/gemini文書の各行は単一の「行種別」を持ちます。行の最初の3文字を調べることでこの種類を曖昧さなく判定することが可能です。行の種類があることで利用者にどのように表示されるかを決定します。特定の行の種類に関連付けられる表示や呈示の詳細は厳密に各個別の行の範疇において制限されます。

計7つの行の種別があります。しかし完全な機能を持ち仕様に準拠するGeminiクライアントはその内の4つを認識し扱いさえすれば良いのです。これらは「中核の行の種別」（5.4参照）です。発展的なクライアントは追加で「発展的な行の種別」（5.5参照）についても扱えるようにできます。単純なクライアントは発展的な行の種別の全てを中核の行の種別と等価なものとして扱うだけでも、充分な利用者体験を提供できます。

5.4 中核の行の種別

4つの中核の行の種別は以下の通りです。

5.4.1 テキスト行

テキスト行は最も基本的な行の種別です。これは後述するどの行の種別の定義にも合致しない任意の行が、既定としてテキスト行になるということです。よくあるtext/gemini文書の大多数の行がこのテキスト行になるでしょう。

テキスト行はクライアントの目に見える範囲の適切な幅に折り返された後に利用者に表示されるべきです。テキスト行はは、一般的な読み方をする上で視覚的に見やすいように利用者に表示されるべきです。細かい意味合いについてはクライアント側に裁量があります。例えば可変幅のフォントが使われても良いですし、空白が正規化されても良いですし、単語間の空白より文の間の空白が長くなるようにしても良い、といった感じで表示上の工夫を適用するのは構いません。クライアントはフォントやフォントの大きさや背景色などを変えることによって、テキスト行の見た目を独自のものにしたりすることを利用者に許しても構いません。著者はテキストの内容に専念し、テキスト行の精密な呈示について管理できるとは思わないことです。このようにして扱われると正しく表示されないようなASCIIアートやコンピューターのソースコードなどは、書式化済み切り替え行の間に囲まれるべきです（5.4.3参照）。

空行はテキスト行に含まれ、特別な意味はありません。それぞれについて垂直な空の空間として目に見えない形で個別に呈示されるべきです。連続する空白行はより少ない空白行に縮めるべきではありません。

クライアントの機器の画面に収まる分より長いテキスト行は収まるように「折り返される」べきです。つまり、長い行は機器に適切な幅の複数の連続する行に（理想的には空白やハイフンのところで）分割されるべきです。この折り返しはテキストの各行に独立して適用されます。しかし、クライアントの機器の画面より短い複数の連続するテキスト行は、より少ない数でより長い行に結合されるべきではありません。

このテキスト書式の手法を最大限活かすため、text/geminiで内容を書く著者は特定の固定幅で手作業で折り返すことは避けるべきです。これはGopherspaceの慣習として80文字以内で折り返すのが典型であるのとは対照的です。その代わりに、一繋がりの塊として表示されるべきテキストは単一の長い行として書かれるべきです。ほとんどのテキストエディタは「ソフトな折り返し」にするよう構成できます。つまりこうした種類のファイルを書く上で単語の協会で長い行を折り返して表示し、著者の画面の機器に合うようにするのです。

内容をハードに折り返さないと気が済まない著者に気付いてほしいのですが、ハードな折り返しの長さと同じかそれ以上の幅の画面の機器のクライアントではいい感じに表示されるとしても、それより狭いクライアントでは不規則な行の幅となって現れてしまいます。

5.4.2 リンク行

「=>」の2文字から始まる行はリンク行です。この行は以下の構文をしています。

=>[<空白>]<URL>[<空白><利用者に親しみやすいリンクの名前>]

ここで、次の通りです。

• <空白>は非ゼロの連続する空白文字ないしタブ文字です。
• 角括弧は、囲まれている内容が省けることを示しています。
• <URL>はURLであり、絶対的なものにも相対的なものにもできます。

以下の例は、全て正当なリンク行です。

=> gemini://example.org/
=> gemini://example.org/ リンクの一例
=> gemini://example.org/foo	同じホストにある別のリンクの例
=> foo/bar/baz.txt	相対リンク
=> 	gopher://example.org:70/1 gopherのリンク

リンク行内のURLはRFC 3986にしたがって予約された文字と空白はパーセント文字で符号化されなければなりません。

なお、リンクのURLはgeminiでないスキームであって構いません。つまり、Geminiの文書は単純かつ典雅に他のプロトコルを介してホストされている文書へのリンクを張れるのです。gopherでない内容へのリンクは`h`項目の種類の非標準的な適応をせざるを得ないgophermapとは異なります。

クライアントはクライアントの著者が望む通りのやり方でリンクを表示できます。しかしクライアントはスキームがネットワークプロトコルに対応するリンク（例えばgemini://、gopher://、https://、ftp://などから始まるリンク）の表示にあたっていかなる自動的なネットワーク接続もしてはなりません。

5.4.3 書式化切替え行

最初の3文字が「```」である行（つまり先頭に空白のない3つの連続する逆引用符）は書式化済み切替え行です。この行は利用者に表示する呈示される出力に含まれるべきではありません。その代わりに構文解析器は書式化済みモードの「有効」と「無効」が切り替わります。書式化済みモードは文書の開始時は「無効」であるべきです。書式化済みモードの現在の状態は、構文解析器が維持する必要のある内部状態であるに過ぎません。書式化済みモードが「有効」のとき、通常の行を識別する規則は停止し、全ての行は書式化済みテキスト行となります（5.4.4参照）。

書式化済み切り替え行はHTMLでの<pre>と</pre>タグのようなものと考えられます。

書式化済みモードを有効に切り替える書式化済み切替え行の先頭の「```」以降のテキストは、切り替え行に続く書式化済みテキスト行に付随する「代替テキスト」としてクライアントにより解釈されて構いません。代替テキストの使用はクライアントの裁量にあり、単純なクライアントは無視して構いません。代替テキストはASCIIアートやテキストらしくない内容に付けることをお勧めします。例えば、画面読み上げ器を通じて呈示される際に有意味に理解できないものであったり、検索エンジンにより索引として有効活用できるものであったりします。コンピュータのソースコードに使ってプログラミング言語の指定しても構いません。発展的なクライアントは構文彩色に使っても構いません。

書式化済みモードを無効に切り替える書式化済み切替え行の先頭の「```」に続くテキストは、クライアントで無視されなければなりません。

5.4.4 書式化済みテキスト行

書式化済みモードではテキスト行は利用者に対して「中立」に、空白の変更や装飾的な改善なしに固定幅フォントで表示されるべきです。グラフィカルなクライアントは、クライアントの目に見える範囲よりも長い書式化済みテキスト行の表示について、折り返すよりかは画面スクロールの仕組みを使うべきです。書式化済みテキスト行を表示する上で、クライアントはASCIIアートやコンピュータのソースコードのような活用例を念頭に置くべきです。具体的には空白が重要な言語で書かれたソースコード（例えばPython）はクライアントでファイルに切り貼りしたときに特に問題なく解釈やコンパイルができるようにすべきです。クライアントが表示するやり方で問題が起こらないようにすべきです。

5.5 発展的な行の種類

以降の発展的な行の種類は発展的なクライアントでは認識しても構いません。5.4.1にあるように単純なクライアントは全てをテキスト行として扱って構いません。不可欠な機能は損なわれません。

5.5.1 見出し行

「#」から始まる行は見出し行です。見出し行は1、2、3個の連続する「#」文字から構成され、任意で空白が続き、その後ろに見出しのテキストが来ます。#と##と###はHTMLでの<h1>と<h2>と<h3>のようなものと考えられます。

見出しテキストの内容は利用者に表示されるべきであり、クライアントは特別な書式化を使って構いません。例えば見出しになっていることを示すためにより大きかったり太かったりするフォントを使うなどです（単純なクライアントでは先頭の#を含めてその行を表示し、全く装飾しなくて構いません）。しかし、見出し行の主眼の目的は装飾のためでなく意味論的なものであり、文書の内部構造についての機械で読み取れる表現を提供することなのです。発展的なクライアントはこの情報を使って、例えば長い文書については画面脇に階層的に書式化された「目次」を自動的に生成して表示して構いません。こうすると利用者は簡単に特定の節に飛ぶことができ、スクロールしまくらなくて良くなります。CMS的なツールについては、ディレクトリ内のgemtext文書に対してメニューやAtom/RSSフィードを自動生成するのに、ファイルの最初の見出しを人間が親しみやすい題名として使えます。

5.5.2 順不同リスト項目

「* 」から始まる行は順不同リスト項目です。この行の種類は純粋に装飾上の理由から存在しています。*は発展的なクライアントでは点の記号で置き換えても構いません。「* 」の後のテキストはあたかもテキスト行のように利用者に表示されるべきです。つまり、目に見える範囲に収まるように折り返し、「いい感じ」に書式化するのです。発展的なクライアントは点の記号の空白を考慮に入れて、長いリスト項目を折り返すときにその項目に対応する全ての行が画面端から等しい距離で間が空くようにすることもできます。

5.5.3 引用行

「>」から始まる行は引用行です。この行の種類が存在しているのは、発展的なクライアントが読者のために装飾の区別ができるようにするためです。特定のテキストが外部の資料から引用されたものだというような、重要な意味論的な情報が読者に伝わります。例えば、長い行を目に見える範囲に折り返すとき、結果的に表示される各行には前方に「>」記号が置かれていても構いません。

補遺1 2桁の状態コードの全容

10 INPUT

3.2で単一桁のコード1での定義に従います。

11 SENSITIVE INPUT

状態コード10に従いますが、パスワードのような機密性のある入力に使います。クライアントは状態コード10に従って質問を表示すべきです。ただし利用者の入力は「肩越しに覗いて」読み取られることを防ぐため、画面に表示すべきではありません。

20 SUCCESS

3.2の単一桁コード2の定義に従います。

30 REDIRECT - TEMPORARY

3.2の単一桁3の定義に従います。

31 REDIRECT - PERMANENT

要求された資源は一貫して将来、与えられた新しいURLに要求すべきです。検索エンジンの索引作成器や内容収集器は構成を更新して古いURLに要求することを避け、エンドユーザーのクライアントは自動的にブックマークを更新したりなどすべきです。なお状態コードの最初の桁だけに注意を払うクライアントはこれを一時的なリダイレクトとして扱います。それでも正しい場所に行き着きますが、このリダイレクトが永久のものであるかどうかの知識を活用できません。ですから毎回リダイレクトに従わなければならないことにより小さな効率上の代償を払います。

40 TEMPORARY FAILURE

3.2の単一桁4の定義に従います。

41 SERVER UNAVAILABLE

オーバーロードやサーバーの保守作業のため利用できません（HTTP 503と関連）。

42 CGI ERROR

CGIやそれに似た動的な内容を生成するシステムの処理が、予期せず異常終了したり、時間切れになったりしました。

43 PROXY ERROR

サーバーで正常にリモートホストとのトランザクションを完了できなかったため、プロキシの要求が失敗しました（HTTP 502、504と関連）。

44 SLOW DOWN

レート制限が効いています。<メタ情報>はクライアントが別の要求をこのサーバーにする前に待機しなければいけない秒数の整数値です（HTTP 429が関連）。

50 PERMANENT FAILURE

3.2の単一桁コードの定義に従います。

51 NOT FOUND

要求された資源は見付かりませんでしたが、将来は利用できるかもしれません（HTTP 404が関連）（この重要な状態コードをどうにかして覚えようとしていますか？簡単なことです。エリア51では隠されたものは見付けられませんからね）。

52 GONE

要求された資源は最早入手できず、再び手に入ることもありません。検索エンジンや類するツールでは、この資源を索引から削除すべきです。内容収集器では資源の要求を止め、人間の利用者に購読していた資源が散逸したことを伝えるべきです（HTTP 410が関連）。

53 PROXY REQUEST REFUSED

ドメインの資源への要求がサーバーから送られず、サーバーでプロキシの要求が受け付けられません。

59 BAD REQUEST

サーバーがクライアントの要求を解析しませんでした。間違って書式化された要求であったためと見られます（HTTP 400に関連）。

60 CLIENT CERTIFICATE REQUIRED

3.2の単一コード6の定義に従います。

61 CERTIFICATE NOT AUTHORISED

与えられたクライアント証明書には、要求された資源にアクセスする権限がありません。問題が証明書自体になく、他の資源に対しては権限がある可能性があります。

62 CERTIFICATE NOT VALID

与えられたクライアント証明書が不当であるため受け付けられませんでした。これは証明書の内容やそれ自身に問題があることを示しており、特定の要求された資源については考慮されません。最もありそうな原因は証明書の妥当性の開始日が未来になっているか期限日が過ぎているかですが、このコードは不当なシグネチャやX509標準要件の違反を示している可能性もあります。<メタ情報>は厳密なエラーについての情報を提供すべきです。