摘要

  • RFC 3196 原先允许实现自行决定：是否在发出 Print-Job 最终响应之前接收全部文档数据。技术勘误 2924 撤销了这种弹性，要求先接收完整文档。
  • 该要求针对 IPP 最终成功或错误响应。HTTP 100 Continue、提前出现的传输错误、作业创建以及纸张实际输出，都是不同事件，不能混为一谈。

答复先于文档

互联网打印协议（IPP）试图把打印变成网络服务。客户端通过 HTTP 提交操作；对于 Print-Job，文档本身也随请求正文一起传送。打印机返回 IPP 状态，成功时还可能给出作业标识。这个普通的往返隐藏着一个操作层问题：请求正文仍在路上时，服务器何时才有资格宣告结果？

2001 年 11 月发布的 RFC 3196 是 IPP/1.1 实施指南。它最初把打印机是否先收完文档再返回最终成功或错误响应，留给各实现决定。2011 年的勘误 2924 改写了这一句：打印机在返回该响应之前，MUST 接收全部文档数据。这不是增加一种打印功能，而是给“最终答复”设定了更清楚的时点，尤其适用于文档体量大、分段或持续上传的情形。

如果客户端在正文尚未发送完时就收到最终结果，它可能无法判断剩余数据是否已被接收、作业是否存在、重试会不会产生重复作业。勘误将这层不确定性收窄：对 IPP 最终响应而言，打印机必须等到完整文档已被接收。

三种确认，三种含义

这条规则有明确边界。HTTP 100 Continue 是临时响应，表示客户端可以继续发送正文；它不是 IPP 操作成功。某些情况下，如果服务器不会执行该方法，HTTP 也允许提前返回最终错误；正文和连接如何处置，属于传输层问题。勘误并未把任何提前信号都定性为违规。

Print-Job 成功也不等于纸张已经输出。响应可以返回 job-id 和 job-uri，客户端据此继续查询作业状态。2017 年的 RFC 8010 与 RFC 8011 更新并取代了 RFC 2910 与 RFC 2911，仍将 HTTP 传输、IPP 操作语义和作业生命周期分开。文档被接收、作业被接受、作业被处理、打印机完成成像、成品交到用户手中，是不同阶段。

文献能证明规则及其编辑过程，却不能证明实施情况。RFC 3196 是 Informational 指南，不是新发布的标准轨道协议规范。RFC Editor 将勘误 2924 标为 Technical；Michael Sweet 于 2011 年 8 月提交，Peter Saint-Andre 于同年 11 月核验。现有记录没有说明哪些产品何时采纳了修正，也没有记录某次故障由旧措辞导致。因此，把它写成行业事故史会超出证据。

值得留下的是一条证据原则：每次确认都只说明某一层发生了什么。传输开始不代表完整文档已到达；作业编号也不代表纸张已交付。勘误关闭了一个具体歧义，并没有替后续阶段作保证。

来源

这些一手资料说明的是协议规则和勘误沿革，不足以证明产品采纳率、实测性能、部署普及程度、具体故障，或持久存储和实际出纸结果。