要約

  • RFC 3380は、対応するSet-Job-Attributes要求を一つの完成した状態案として評価し、属性を部分的に適用する設計を認めなかった。
  • 未対応または矛盾する値があれば要求全体を拒否し、Jobを変更前のまま残す。これは印刷ジョブの取消しでも、紙への出力の証明でもない。

2002年9月、IPPの管理面に明確な境界が加わった。送信後にステープルなどの仕上げ指定を忘れたと気づくことがある。RFC 3380は、既存のJobオブジェクトを変更し、取消しと再送を避ける任意の方法を示した。

プリンターは新しい属性だけを検査するのではない。クライアントが変更しない属性と合わせた全体を評価する。ipp-attribute-fidelity=trueでその最終セットを持つ新規Jobが受理されるなら、変更要求も受理しなければならない。新規作成なら拒否される組み合わせなら、変更要求も拒否し、既存Jobをそのままにする。未対応、設定不可、値の不一致が一つあっても、適用しやすい属性だけ残すことはできない。要求は全部適用か、全部不適用かである。

この規則により、クライアントが部分変更を希望状態と誤認する危険が減る。応答は検証に失敗した属性を示せる一方、Jobは以前の状態を保つ。認証済みの要求者が所有者、オペレーターまたは管理者でなければならないという権限確認は、属性セットの有効性とは別の判定だ。変更を求める権限があっても、矛盾した値が正しくなるわけではない。

同じRFCはPrinter属性の一括変更も扱い、設定可能なxxx-supported属性について受理可能な値を調べるGet-Printer-Supported-Valuesを導入した。printer-xri-supportedからURI、認証方式、セキュリティの対応関係をまとめて更新する仕組みもある。しかしSet操作は任意である。仕様は設計契約を示すだけで、特定機器の実装、クライアントによる利用、印刷完了を証明しない。

RFC 3196の訂正が扱うのは、文書データ受信後に最終応答を返す時点である。RFC 3380はJob属性の変更を扱う。更新の成功・拒否はいずれも、文書の完全受信、処理、物理出力を示さない。プロトコル上の状態変更は、印刷室からの結果通知ではない。一次資料：RFC 3380、RFC 2911、RFC 3196。この拡張は任意であり、規格文書は普及や相互運用の証拠ではない。

出典