摘要

  • RFC 3510 用绝对 ipp: URL 定位 IPP 打印服务及其管理的作业，却明确指出：从作业 URL 反推出创建该作业的 Printer URL，并没有被规范定义。
  • 在 Printer URL 后追加一个路径段，只是一项互操作建议；它不会让地址永久有效，也不会认证服务端、证明请求获接收，更不会证明纸张已经输出。

RFC 3510 最值得记住的句子，不是端口号，也不是 ABNF。它直接说，早先关于 job-printer-uri 的一项表述是错误的。旧文本认为，只要手里有 Job 的 URI，客户端就能识别创建该 Job 的 Printer 对象；RFC 3510 指出，无论 IPP 模型还是传输规范，都没有定义这种反向转换。

这句话击中了地址最容易制造的错觉。URL 看起来像一张收据：有 scheme、主机、路径，还可能带着一个像档案编号的数字。界面把它变成可点击链接后，人更容易把“能指到某处”理解成“已经证明历史”。其实每个字符都只属于命名与传输合同，字符串本身不会自动生成运营事实。

RFC 3510 于 2003 年 4 月作为 Standards Track 文档发布，用来扩展并澄清 RFC 2910 的 IPP URL 章节。它规定 ipp: 的适用范围、默认端口 631、关联媒体类型 application/ipp、字符编码、语法和比较规则，但没有加入新的 URL 参数。

ipp: 可以指向支持 IPP 的打印服务，也可以指向该服务管理的网络资源，例如 Job。它只能使用绝对形式，不能使用相对 URL；它把 RFC 2911 的抽象 IPP 模型绑定到 RFC 2910 定义的 HTTP 传输。若同一抽象协议改用别的传输方式，就应采用另一种 URL scheme。因此，ipp: 不是笼统的“网络打印”标签，而是一个明确的模型与承载组合。

端口被省略或留空时，客户端必须使用 631。比较两个 IPP URL 时，省略端口与明确写出 :631 等价。没有路径时，HTTP Request-URI 使用 /。请求与响应以 application/ipp 表示。这些规则消除了本可避免的分歧：两种拼写可以表示同一个入口，客户端也知道从哪组传输假设开始。

但路径从来不是物理布线图。RFC 的例子让同一主机下出现多个 Printer URL。某个路径可以代表实体设备，另一个可以代表负载均衡 spooler，也可以代表一组设备；同一台实体打印机甚至可以因不同收件人队列而暴露成两个逻辑 Printer。对 IPP 来说，它们都是彼此独立的 Printer 对象。

大写的 Printer 是软件对象，不等于桌面上的机器。它接收 Job 或管理操作，可以运行在 spooler、网关或实体打印设备上。抵达该对象的 URL 不能告诉你最终由哪台硬件留下墨迹，也不能说明任务是否会被转发，或者人的队列规则是否会改变目的地。命名层保留逻辑独立性，却没有承诺物理透明。

Job URL 把边界暴露得更彻底。Print-Job 响应可能返回 ipp://example.com/printer/123。视觉上的层级诱使客户端删掉 /123，把剩余部分当成创建它的 Printer URL。然而 RFC 2911 已说明，Job URI 的具体格式由实现决定。RFC 3510 因此进一步说明，提交时的 printer-uri 与返回的 job-uri 之间是什么关系，同样由实现决定。

规范给出的补救是一个惯例：符合 RFC 3510 的 Printer SHOULD 在对应 Printer URL 后恰好追加一个路径段来生成 Job URL。这为愿意遵循建议的实现提供了可预测的正向规则，却不是对所有既存 URL 的数学定理。SHOULD 允许有理由的例外，旧实现可能不同，网关也可能继承另一套命名系统。

即使实现采用这项惯例，上下文也比字符串拆解更强。客户端应同时保存实际提交的 printer-uri、服务返回的 job-uri、经过认证的服务端身份、响应内容和时间。后来再根据斜杠猜父路径，不如当时的请求—响应记录可靠。路径可以被复制、代理或重新分配；交易记录才能说明这个名字由谁在什么交换中发出。

时间又给地址加上一条限制。RFC 3510 规定，Job URL 只在 Job 完成之前保持有效和有意义；完成之后是否继续保存、保存多久，由实现决定。书签因此不是永久档案标识。稍后访问失败，可能只说明服务清理了 Job 对象，而不是该 Job 从未存在。若地址被重新使用，脱离签发时间的记录甚至可能指向另一个对象。

安全章节进一步说明为什么语法承担不了身份任务。伪造的 IPP URL 可以把机密文档引向恶意打印服务。防线是服务端认证与 IPP 安全机制，而不是观察路径是否“像真的”。反过来，未经授权的客户端也可能拿着真实 URL 访问真实服务；这需要客户端认证和授权。

应用层网关造成更深的断裂。RFC 3510 警告，IPP 到 LPD 的网关可能悄然破坏 IPP 的安全机制，而且客户端没有实际可用的防御；管理员应避免这种配置。客户端或许认证了近端 IPP 服务，却仍不知道后续链路是否保留相同安全属性。

URL 本身也没有参数声明必须使用哪种客户端认证或安全机制。发现服务或目录协议可以提供这类关联信息。工作组曾考虑把相关参数加入 ipp:，但为了与已经出货的 IPP/1.1 实现保持向后兼容，最终保留原有语法。命名格式保持稳定，安全能力发现则停留在相邻控制面。

这种分工不应被读成可以随意补想象的漏洞。URL 负责告诉客户端去哪里寻找 IPP 资源；发现机制描述能力；认证确认端点参与者；IPP 响应记录协议处理；Job 状态描述软件观察到的进度；实体设备与交付链需要另外证明现实世界发生了什么。

因此，一条诚实的证据链比界面上的绿色状态长得多。先是 ipp: URL 能解析，再是主机、端口和路径能解析；端点按预期的 HTTP 绑定讲 application/ipp；服务端身份获证；客户端身份与权限获证；Printer 接受操作并创建 Job；Job URL 连同签发者和时效被保存；Job 达到明确定义的状态；设备实际输出；最后由预定收件人取得结果。

较低一级全部为真，较高一级仍可能失败。真实服务可以拒绝 Job；已接收 Job 可以被取消；软件层的“完成”可能发生在实体输出之前；打印出的纸张可以进入错误纸盘或交给错误的人。RFC 3510 没有把这些问题压成一个成功标志，历史写作也不应替它压缩。

Lu Heng 关于符号现实与运营现实的区分在这里尤其有用。标准字符串创建共享的符号路径；运行中的代码决定路径后面是哪种服务对象、Job 如何命名、保存多久、是否经过网关。RFC 证明技术合同曾被写下，却不证明某个产品部署了它，也不证明某份文档已经被打印。

RFC 3510 的成就，不是让打印变得自证，而是减少命名与传输接口上的歧义，同时诚实记录地址不能证明什么。它最持久的遗产，正是拒绝了那个看似自然的推断：Job URL 可以命名 Job；离开交易与实现证据，它不能告诉你是哪一个 Printer 创建了 Job。

来源