1. Introduction (简介)

URI [RFC3986] 通常包含结构化的应用程序数据。这可能包括来自文件系统的工件 (通常出现在路径组件中) 和用户信息 (通常在查询组件中)。在某些情况下，甚至可以在授权机构组件中包含特定于应用程序的数据 (例如，某些应用程序分布在多个主机名上以实现某种形式的分区或调度)。

实现可以对 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 或其部分的语法或结构的规范的作者。特别指出了两类此类规范：

• 协议扩展 ("Extensions") - 提供可应用于任何标识符或大量可能标识符的新功能的规范，例如，"http" URI 的新签名机制、任何 URI 的元数据或新格式。

• 使用 URI 的应用程序 ("Applications") - 使用 URI 满足特定需求的规范，例如，主机上特定信息的 HTTP 接口。

针对通用类别 "Specifications" 的要求适用于所有规范，包括上述列举的规范和其他规范。

请注意，本规范不应被解释为阻止合法拥有 URI 或已委托该所有权的各方分配对 URI 的控制；例如，规范可能合法地将 IANA 网站上的 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] 中描述的方式解释，如此处所示。