メインコンテンツまでスキップ

1. Introduction (はじめに)

URI [RFC3986] には、構造化されたアプリケーションデータが非常に頻繁に含まれます。これには、ファイルシステムからのアーティファクト (パスコンポーネントによく現れる) やユーザー情報 (クエリコンポーネントによく含まれる) が含まれる場合があります。場合によっては、権限コンポーネント (Authority Component) にアプリケーション固有のデータが含まれることさえあります (例えば、一部のアプリケーションは、パーティション化やディスパッチの形式を可能にするために複数のホスト名に分散されています)。

実装は、URIの構造にさらなる制約を課すことができます。例えば、多くのWebサーバーは、最後のパスセグメントのファイル拡張子を使用してレスポンスのメディアタイプを決定します。同様に、パッケージ化されたアプリケーションは、限られた方法でのみ変更できる高度に構造化されたURIを持つことがよくあります (多くの場合、展開されるホスト名とポートのみ)。

URIの所有者 ([webarch] セクション2.2.2.1で定義) がサーバーまたはアプリケーションの使用を選択しているため、これは合理的な権限委任と見なすことができます。しかし、そのような規約が所有者以外の当事者によって義務付けられる場合、いくつかの潜在的に有害な影響を及ぼす可能性があります:

  • 衝突 (Collisions) - URI構造に関するアドホックな規約がより多く標準化されるにつれて、それらの間で衝突が発生する可能性が高くなります (特に、サーバー、アプリケーション、および個々の展開が独自の規約を持つことを考慮すると)。

  • 希釈 (Dilution) - URIに追加される情報が一時的である場合、これはその安定性を低下させることによってその有用性を希釈し ([webarch] セクション3.5.1を参照)、URIの複数の代替形式が存在する原因となる可能性があります ([webarch] セクション2.3.1を参照)。

  • 硬直性 (Rigidity) - 固定されたURI構文は、望ましい展開パターンを妨げることがよくあります。例えば、権限が単一のホスト名で複数のアプリケーションを提供することを望む場合、それらのURIが必要な柔軟性を許可しない場合、これを行うことが困難または不可能になります。

  • 運用上の困難 (Operational Difficulty) - 一部の実装では、特定のURI規約をサポートすることが困難な場合があります。例えば、特定のクエリパラメータを "http" URIで使用するように指定すると、ファイルシステムからレスポンスを提供するWebサーバーの使用が排除される可能性があります。同様に、その動作のために基本パス (例: "/v1") を固定するアプリケーションは、同じホスト上に同じプレフィックスを持つ他のアプリケーションを展開することを不可能にします。

  • クライアントの仮定 (Client Assumptions) - 規約が標準化されると、一部のクライアントは、それらの規約が見られるときに標準が使用されていると必然的に仮定します。これは相互運用性の問題につながる可能性があります。例えば、"sig" URIクエリパラメータがそのペイロードがURIの暗号署名であることを示すと仕様が文書化している場合、望ましくない動作につながる可能性があります。

したがって、[RFC3986] によって明示的に許可されていない方法で既存のURI構造を制約する標準を公開すること (通常、URIスキーム定義を更新することによって) は、これらの理由およびURIの構造がその所有者によってしっかりと制御される必要があるという理由から、時に問題があります。

本文書は、標準においてURI構造、規約、およびフォーマットを確立するための最良の現行実践のいくつかを説明します。また、セクション3で仕様のための戦略を提供します。

1.1. Intended Audience (対象読者)​

本文書のガイドラインと要件は、URIまたはその一部の構文または構造を制約する仕様の作成者を対象としています。そのような仕様の2つのクラスが特に呼び出されます:

  • プロトコル拡張 ("Extensions") - 任意の識別子または可能な識別子の大きなサブセットに適用できる新しい機能を提供する仕様。例えば、"http" URIの新しい署名メカニズム、任意のURIのメタデータ、または新しいフォーマット。

  • URIを使用するアプリケーション ("Applications") - 特定のニーズを満たすためにURIを使用する仕様。例えば、ホスト上の特定の情報へのHTTPインターフェース。

一般的なクラス "Specifications" を対象とする要件は、上記に列挙されたものを含むすべての仕様およびその他の仕様に適用されます。

本仕様は、URIを合法的に所有している、またはその所有権を委任した当事者によるURIの制御の割り当てを妨げるものと解釈されるべきではありません (SHOULD NOT)。例えば、仕様は、レジストリの確立の一部として、IANAのWebサイト上のURIのセマンティクスを合法的に定義する場合があります。

本文書のガイダンスからすでに逸脱している既存のIETF仕様が存在する可能性があります。これらの場合、適切な結果を決定するのは、関連するコミュニティ (すなわち、URIスキームのコミュニティおよび問題の仕様を作成した関連コミュニティ) 次第です。例えば、スキーム定義を更新するか、仕様を変更するかです。

1.2. Notational Conventions (表記規則)​

本文書のキーワード "MUST" (しなければならない)、"MUST NOT" (してはならない)、"REQUIRED" (必須である)、"SHALL" (するものとする)、"SHALL NOT" (しないものとする)、"SHOULD" (すべきである)、"SHOULD NOT" (すべきでない)、"RECOMMENDED" (推奨される)、"NOT RECOMMENDED" (推奨されない)、"MAY" (してもよい)、および "OPTIONAL" (任意である) は、ここに示されているように、すべて大文字で表示される場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されるものとします。

に最終更新