3. 指定 URI 结构的替代方案

鉴于 Section 1 中描述的问题, 对于希望使用 URI 的 Applications 和 Extensions, 最成功的策略是以 URI 原本设计的方式使用它们: 作为协议的一部分交换的链接, 而不是静态指定的语法. 若干现有规范可对此提供帮助.

[RFC8288] 为 Web links 指定了 relation types. 它通过提供一个 Web 链接框架, 使每个链接都有 relation type, context 和 target, 从而允许 Applications 定义链接的语义和连通性.

[RFC6570] 提供了 URI Templates 的标准语法, 可用于将 Application 专用变量动态插入 URI, 以支持这类 Applications, 同时避免侵犯 URI 所有者对 URI 的控制.

[RFC8615] 允许在选择加入该机制的 URI schemes 上将特定 paths "reserved" 为标准用途 ("http" 和 "https" 默认加入). 但请注意, 这不是面向需要结构化 URI 的 Applications 的通用 "escape valve". 更多信息请参见该规范.

试图通过指定更复杂的结构来避免冲突并不是可接受的解决方案, 也不能解决 Section 1 中描述的问题. 例如, 用 "myapp_" 给 query 参数加前缀并没有帮助, 因为该前缀本身也存在冲突风险 (因为它并未被 "reserved").