摘要

  • RFC 3380 把受支持的 Set-Job-Attributes 请求当作一个完整的新作业状态，而不是允许打印机只应用其中几个字段。
  • 属性不受支持或彼此冲突时，打印机必须拒绝整项请求并保持 Job 不变；这既不等于取消作业，也不能证明纸张输出情况。

2002 年 9 月，IPP 为作业管理增加了一道更明确的边界。用户或操作员可能在提交后才发现漏选了装订等打印选项。RFC 3380 提供了一种可选替代方案：修改现有 Job 对象，而不是取消后重新提交。

打印机不能只检查用户新提交的字段。它要把这些字段与未修改的 Job 属性合在一起评估。标准提出一个反事实问题：如果按这个最终组合新建作业，并启用 ipp-attribute-fidelity=true，打印机是否会接受？如果会，就必须接受修改；如果不会，就必须拒绝，而且现有 Job 必须保持原样。遇到一个不支持的属性、不可设置的字段或不受支持的值时，打印机不能悄悄保留“好处理”的字段、只丢掉问题字段。整个请求要么全部生效，要么全部不变。

这不仅是错误提示的设计，它避免客户端把部分修改误当成请求的完整状态。响应可以指出验证失败的属性，同时作业继续保持旧状态。授权又是另一项判断：经过认证的请求者必须是作业所有者、操作员或管理员。有权提出修改，不代表提交的组合就一定有效。

RFC 3380 还为打印机配置属性规定了整项原子修改，并加入 Get-Printer-Supported-Values，以查询某些可设置属性能够接受的值。printer-xri-supported 也能把相关的 URI、认证及安全描述一起更新。但 Set 操作是可选的。规范说明的是设计契约，不能证明某台打印机实现了它、某个客户端使用过它，或最终有一张纸打印出来。

RFC 3196 讨论的是另一件事：打印机何时可以在收到文档数据后返回最终响应。RFC 3380 讨论的是如何改动 Job 属性。更新被接受或拒绝，都不能证明文档已完整接收、已处理或已打印。协议状态变更的回执，不是机房里的物理结果回执。参见 RFC 3380、RFC 2911 和 RFC 3196。RFC 3380 是可选扩展；这些标准文本不构成部署或互操作证据。

来源