摘要

  • RFC 2122 定义的 URL 指向交互式多媒体服务，而非数据对象；VEMMI 客户端通常在默认 575 端口上建立一条持续 TCP 会话。
  • URL 可以选择服务并携带带标签参数，却不得包含用户名或密码；浏览器支持、身份验证以及收到 VEMMI_Open 都是后续、可分别观察的阶段。
  • application/vemmi 承担独立的对象传输角色；operative object 可能是可执行程序，因此下载、用户批准、执行与安全结果必须留下不同记录。

这是服务地址，不是对象地址

RFC 2122 于 1997 年 3 月以 Proposed Standard 发布，为 VEMMI（用于可视图文与多媒体/超媒体信息检索服务的增强人机界面）定义 vemmi 方案。那正是 Web 逐渐成为统一入口，而许多在线系统仍保留专用客户端、状态机与交互模型的时期。

文档把核心边界说得很直接：VEMMI URL 不指定数据对象，而是指定一个多媒体交互服务。典型 VEMMI 运行期间，客户端与服务器之间维持一条 TCP/IP 链接，用它管理多媒体对象并上报用户动作。URL 的职责，是说明从哪里、以何种服务选择开始。

基本形式为 vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value>。端口和服务名都可以省略；未写端口时采用 575。客户端还可出于安全策略忽略 URL 显式给出的其他端口。服务名之后可以带成对的属性和值，用于传递上下文或请求特定处理。

这些语法能表达启动意图，却不能证明动作已完成。主机名不证明解析成功，575 不证明有人监听，服务名不证明服务器提供该服务，参数也不证明远端接受或执行了它。URL 是一条候选启动指令。

一次点击只开始了分阶段对话

规范描述的客户端—服务器对话表明，链接不是完成交易的收据。连接建立后，服务器可以依次询问 service:、username: 与 password:。客户端可能从 URL 取得服务名，从本地配置取得身份信息，或向用户询问。终端在此期间仍处于兼容可视图文或 telnet 的“standard”模式，直到收到 VEMMI_Open 才进入 VEMMI 状态。

RFC 2122 明确禁止把用户名和密码放进 URL。服务选择与带标签数据可以随链接传递，身份却留在后续对话中。文档示例里有 200 OK 与 401 Unauthorized，但它们是状态语法示意，不是一次真实部署测量。

因此，证据链至少包括：用户选择链接；浏览器识别方案；找到处理程序；客户端启动；主机解析；TCP 建连；服务问答匹配；身份挑战通过；收到 VEMMI_Open；会话运行；目标结果出现。每张收据只属于一个转换，不能借用下一阶段的证明力。

不认识方案时，失败发生在服务之前

RFC 预想 VEMMI 支持可以内置在浏览器，也可以由关联软件或插件提供。若完全没有支持，文档列出两种行为：有的浏览器直接把未知方案视为不可恢复错误；另一些会误把它当相对 URL，向提供当前页面的 HTTP 服务器发出畸形请求，最后得到 not found。

这条历史细节十分重要。HTML 里出现可点击的 vemmi://，并不代表读者的软件知道如何处理。即便方案成功解析，也只证明派发能力，不证明客户端版本、配置、网络可达性或远端服务状态。

文档提出若干友好降级办法，例如同时提供客户端下载、让 HTTP 服务器识别误发的相对请求，或通过 Accept: application/vemmi 推测解码器存在。这些都是建议机制，不是浏览器覆盖率数据。本文不据此推断实际实现范围。

对象传输与会话启动是两个角色

RFC 2122 同时登记了 application/vemmi。该媒体类型让 VEMMI 对象可经 HTTP、电子邮件等方式传输；客户端可以通过 HTTP 取回对象，而不建立持续 VEMMI 会话。对不能增加新 URL 方案的浏览器，媒体类型承载的文本文件甚至可以只装一条待启动的 VEMMI URL。

两种机制服务于同一生态，却承担不同工作。vemmi URL 命名并启动服务路径，application/vemmi 标记需要传输和解码的对象。接受该媒体类型可能说明某个解码器已注册，但不证明远端服务存活，更不证明会话会完成认证并打开。

IANA 当前仍把 vemmi 列为永久 URI scheme，把 application/vemmi 列为媒体类型，也保留 VEMMI 的 575 端口。这些是注册事实，不是心跳：它们不证明软件仍受维护、端口正在监听、存在流量、完成互操作或具有采用规模。

可执行对象另有一道同意边界

更关键的边界出现在传输之后。VEMMI 的 metacode object 可以包含命令序列，operative object 则可能是在客户端平台运行的可执行程序。RFC 强烈建议对潜在不安全对象关闭自动执行，至少也要在启动前询问用户批准。

这项建议把“收到”与“授权”拆开。媒体类型可以识别包，会话可以交付包，解码器可以解析包；这些动作都不能赋予执行许可。即使用户批准，也不证明二进制适合当前平台、行为安全或结果符合预期。

RFC 还把当时的用户名/密码机制称为不安全、仅为向后兼容保留。这是 1997 年规范中的历史判断，不能包装成今天的安全方案。它留下的架构价值更窄也更可靠：身份、传输与代码执行必须由不同控制点负责。

历史意义在于逐阶段记账

RFC 1738 已经规定 URL 的解释取决于 scheme，并允许“访问”不只等于取回文件。RFC 2122 是这种扩展性的精确历史切片：Web 页面充当会合点，实际工作则转入一套独立、有状态的运行环境。

Lu Heng 的 Running-Code Primacy 提供了一条阅读纪律：文档或注册条目不能借用真实运行结果的权威。Minimum Initial Specification 也把共同初始规则与本地采用、运行决定分开。对应到这里，登记 scheme 证明名称与语法获得标准化，不证明任何具体用户已经通过后续关口。

正确的历史记录不是“链接有效”，而是一串动词：命名、解析、派发、连接、选择、询问、认证、开启、交付、批准、执行、观察。RFC 2122 的价值，在于一次点击就暴露了这些层；几乎所有运行误判，都始于把它们擦成同一个“成功”。

来源