2. Best Current Practices for Standardizing Structured URIs (構造化URIの標準化に関する最良の現行実践)
本セクションは、仕様がURI内で構造とセマンティクスをどのように定義すべきかについて助言することにより、[RFC3986] を更新します。最良の実践は、以下に説明するように、問題のURIコンポーネントによって異なります。
2.1. URI Schemes (URIスキーム)
アプリケーションと拡張は、1つ以上の特定のURIスキームの使用を要求できます (MAY)。例えば、アプリケーションが "http" と "https" のURIをサポートすることを要求することは完全に受け入れられます。ただし、アプリケーションは、指定されたスキームでのみ明らかに使用可能でない限り、将来的に他のURIスキームの使用を排除すべきではありません (ought not)。
URIスキーム全体のサブ構造を定義する仕様 (例えば、URIスキーム名のプレフィックスまたはサフィックス) は、[BCP35] を変更することによってそうしなければなりません (MUST) (例外的な状況)。
2.2. URI Authorities (URI権限)
スキーム定義は、URIにおける権限コンポーネント (Authority Component) の存在、フォーマット、およびセマンティクスを定義します。他のすべての仕様は、スキーム登録自体またはそれが依存する構造 (例えば、[RFC1034] のセクション3.5で定義されているDNS名構文) を更新しない限り、URI権限の構造またはセマンティクスを制約または定義してはなりません (MUST NOT)。
例えば、拡張またはアプリケーションは、"https://foo_app.example.com" の "foo" プレフィックスが意味を持つ、またはURIで特別な処理をトリガーすると言うことはできません。ただし、"http" URIスキームまたはDNSホスト名構文を更新する場合を除きます。
アプリケーションは、該当する場合、使用するポートを指定または制約できます (MAY)。例えば、BarAppはポートnnnnで実行できます (適切に登録されている場合)。
2.3. URI Paths (URIパス)
スキーム定義は、URIにおけるパスコンポーネント (Path Component) の存在、フォーマット、およびセマンティクスを定義しますが、これらは特定の展開におけるアプリケーションに委任されることがよくあります。
衝突、硬直性、および誤ったクライアントの仮定を避けるために、仕様は、スキーム定義によって許可されない限り、URIパスの固定プレフィックス (例えば、"/myapp") を定義してはなりません (MUST NOT)。
この要件の1つの例外は、[RFC8615] で指定されている登録済みの "既知の (well-known)" URIです。そのメカニズムの適用性の説明については、その文書を参照してください。
これは、サーバーによって制御されるリソースの "下" にURIのパス構造を定義するアプリケーションには適用されないことに注意してください。プレフィックスはアプリケーションを展開する当事者の制御下にあるため、衝突と硬直性が回避され、誤ったクライアントの仮定のリスクが軽減されます。
例えば、アプリケーションは "app_root" を展開制御されたURIプレフィックスとして定義する場合があります。その後、アプリケーション定義のリソースが "{app_root}/foo" および "{app_root}/bar" に存在すると仮定される場合があります。
拡張は、同様に衝突と誤ったクライアントの仮定を避けるために、個々のURIコンポーネント内で構造 (例えば、プレフィックスまたはサフィックス) を定義してはなりません (MUST NOT)。
2.4. URI Queries (URIクエリ)
URIのクエリコンポーネント (Query Component) の存在、フォーマット、およびセマンティクスは、多くの要因に依存し、スキーム定義によって制約される場合があります。多くの場合、それらはリソース自体の実装によって決定されます。
アプリケーションは、その制御下にあるリソースのクエリ構文を指定できます (MAY)。ただし、そうすることで、特定の形式のクエリをサポートしない展開に運用上の困難を引き起こす可能性があります。例えば、サイトは、クエリパラメータをサポートしない "静的" ファイルを使用してアプリケーションをサポートすることを望む場合があります。
拡張は、衝突と誤ったクライアントの仮定を避けるために、クエリのフォーマットまたはセマンティクスを制約してはなりません (MUST NOT)。例えば、"sig" という名前のすべてのクエリパラメータが暗号署名を示すと指示する拡張は、サイト上に潜在的に既存のクエリパラメータと衝突し、クライアントが一致するクエリパラメータが署名であると仮定する原因となります。
[HTML5] の "フォーム送信 (Form submission)" セクションに従って、HTMLはフォーム送信で使用されるクエリ文字列の構文を制約します。新しいフォーム言語は、より広範なURIの作成を可能にすることが推奨されます (例えば、フォームが新しいパスコンポーネントを作成できるようにするなど)。
2.5. URI Fragment Identifiers (URIフラグメント識別子)
[RFC3986] のセクション3.5は、フラグメント識別子 (Fragment Identifiers) の構文とセマンティクスを、潜在的に取得されるリソースのメディアタイプに依存するものとして指定しています。その結果、他の仕様は、メディアタイプがその定義で再利用するために明示的に定義しない限り、フラグメント識別子内で構造を定義してはなりません (MUST NOT) (例えば、JSON Pointer [RFC6901] が行うように)。
それによって制御されていないメディアタイプ全体で共通のフラグメント識別子を定義するアプリケーションは、それらのメディアタイプのハンドラとの相互運用性の問題を引き起こします (新しい非標準構文が期待されていないため)。