この文書では、Geminiプロトコルを実装して利用するための様々な規約や手助けとなるスニペットについて記述します。これらは、プロトコル仕様では義務付けられていませんが、一般的には良いアイデアだと考えられています。 もしあなたがGeminiソフトウェアを書いたり、Geminiサイトを作ったりしているのであれば、正当な理由がない限り、一般的にここで示されたアドバイスに従うべきです。
Geminiサーバーは、クライアントに対して、提供するファイルのMIMEタイプを通知する必要があります。 サーバーがファイルの MIME タイプを知る最も便利な方法は、ファイル名の拡張子を利用することです。 拡張子からMIMEへのマッピングはほとんどが標準化されています (そして、UNIXシステムではしばしば /etc/mime.types ファイルがそれらでいっぱいになっています。) が、Geminiによって定義された text/gemini タイプで提供されるべきファイルをサーバがどう認識すべきか、という疑問が残ります。
現在のGeminiサーバーは、この目的のために .html または .gemini 拡張子を使用しているようです。新しいサーバーは、新しいものを追加するのではなく、これらのオプションのいずれかまたは両方をサポートすることが強く推奨されます。
ウェブサーバの慣例に従って、サーバのファイルシステム内のディレクトリにマップされるパスへのリクエストを受け取り、そのディレクトリに index.html または index.gemini という名前のファイルが存在する場合、そのパスに対してサービスが提供されます。
Geminiサーバーは、提供しているファイルのサイズをクライアントに通知しないため、サーバーの障害により接続が早期に切断された場合の検出が困難な場合があります。 このような事態が発生するリスクは、ファイルサイズが大きくなるほど高くなります。
また、Geminiは大容量ファイルの圧縮や、ファイル破損の検出を可能にするチェックサムをサポートしていないため、そのリスクもファイルサイズに比例して高くなります。
これらの理由から、Geminiは「非常に大きな」ファイルの転送にはあまり適していません。 何をもって「非常に大きなファイル」とするかは、インターネット接続の速度と信頼性、そしてユーザーの忍耐力にある程度依存します。 経験則から言うと、100MBを超えるファイルは他の方法で転送するのがベストだと思われます。
もちろん、GeminiはURLスキームを持つあらゆるプロトコルを介した、他のオンラインコンテンツへのリンクをサポートしているので、GeminiドキュメントからHTTPS、BitTorrent、IPFSなど、あなたの好きなプロトコルを介して提供される大きなファイルへのリンクは可能です。
Geminiは、text/* MIMEタイプの 「charset」 パラメータを用いることによって、任意のテキストエンコーディングをサポートしています。 これにより、「レガシー」なテキストコンテンツを、曖昧で地域的な符号化方式で提供することができます。
新しいコンテンツに対しては、どうか、どうか、どうか、UTF-8を使用してください。 Geminiの仕様では、クライアントがUTF-8テキストを処理できることが必須となっています。 他のエンコーディングのサポートはクライアント次第であり、保証されていません。 UTF-8でコンテンツを提供することによって、そのアクセシビリティを最大化し、UTF-8のみをサポートするシンプルなクライアントの実用性を最大化できます。
Geminiにリダイレクト機能が搭載されたのは、主にサイトの再構築やサーバー間のサイトの移行を、既存のリンクを壊すことなく行えるようにするためです。 このような機能を持たない、ドキュメントが相互に接続された大規模な空間は、必然的に「もろい」「不安定な」(brittle)ものになります。
しかし、一般的にリダイレクトは厄介なものです。 リダイレクトはプロトコルの透明性を低下させ、人々がどのリンクをたどるべきか十分な情報を得た上での選択をすることを難しくし、人々のオンライン活動に関する情報を第三者に漏らす可能性があります。 GeminiではHTTPほどひどくはありませんが (CookieやRefererヘッダがないため) 、せいぜい必要悪にとどまっています。
そのため、リダイレクトを軽々しく使うのは控えてください。 URL短縮のようなものは、ほとんど何のメリットもありません。 一般的に、リンク切れを防ぐ以外の目的でリダイレクトを使うのは、じっくり考えてからにしてください。
クライアントは、リダイレクトに従うかどうかユーザに判断を求めることもできますし、自動的にリダイレクトに従うこともできます。 リダイレクトに自動的に従うクライアントを書く場合、以下の問題に留意するべきです。
誤った設定や悪意のあるGeminiサーバーは、リダイレクトに盲従するクライアントがリダイレクトの無限ループに陥ったり、非常に長いリダイレクトの連鎖を完了しなければならないような方法でリダイレクトを提供する可能性があります。 クライアントを堅牢にするためには、このような状況を検知し、それに対処するのに十分な賢さが必要でしょう。 最も単純な実装は、N個以上の連続したリダイレクトを拒否することです。 Nは5以下に設定することが推奨されます。 これはHTTPのオリジナルの勧告に沿ったものです(RFC-2068参照)。
プロトコル間リダイレクト(すなわち、GeminiからGopherのような他のものへのリダイレクト)はGemini内で可能ですが、非常に強く推奨されません。 しかし、誤った設定や悪意のあるサーバは常にそのようなリダイレクトを提供しうるので、よく書かれたクライアントはそれを検知して適切に応答できるように努めるべきです。
一般にリダイレクトに従うクライアントであっても、HTTPやGopherのようなTLSで保護されていないプロトコルへのリダイレクトが提供された場合、クライアントがこれらのプロトコルをサポートしていると仮定して、自動的にユーザーに警告し明示的に確認を求めることが強く推奨されます。 これにより、意図しないプレーンテキストの転送を避けることができます。
TLS 1.3は劇的にシンプルで、多くの安全でない暗号プリミティブを削除しているにもかかわらず、GeminiではTLS 1.2が不本意ながら許可されています。 これは、現在OpenSSLだけがTLS 1.3をうまくサポートしているようなので、TLS 1.3以上を要求すると、LibreSSLやBearSSLといったライブラリの利用を妨げることになるからです。
TLS 1.2をサポートすることを選択したクライアントとサーバーの作者は、理想的には TLS 1.3と同様のセキュリティを提供する暗号スイートのみを使用することを許可するべきです。 また、特にそのようなソフトウェアは以下のようにすべきです。