要約

  • RFC 3196の当初の記述は、最終的なPrint-Job応答の前に文書全体を受け取るかどうかを実装に委ねていた。技術的なErratum 2924はこの裁量をなくし、全データの受信を求めた。
  • 対象はIPPの最終的な成功・エラー応答である。HTTPの100 Continue、先行する転送エラー、ジョブ作成、紙への出力は、それぞれ別の出来事だ。

文書より先に返る応答

Internet Printing Protocol（IPP）は、印刷をネットワークサービスとして扱うために設計された。クライアントはHTTPで操作を送り、Print-Jobでは文書もリクエスト本文に含める。プリンターはIPPの状態を返し、成功したジョブには後から照会するための識別子が付く。ここには素朴だが重要な問いがある。本文の送信が続いているとき、サーバーはいつ処理結果を確定して返せるのか。

2001年11月のRFC 3196はIPP/1.1の実装ガイドで、当初は最終応答より前に文書全体を受け取るかどうかを実装次第としていた。2011年のErratum 2924は記述を改め、プリンターは成功・エラーを問わず最終応答を返す前に、すべての文書データを受け取らなければならないとした。新しい印刷機能を追加したのではない。文書がまだ流れている間に、最終応答が何を意味するかを明確にしたのである。

ストリーミング送信では、この境界が特に大切だ。本文の送信中にアプリケーションが結果を確定させると、クライアントは残りが消費されたのか、ジョブが作られたのか、再試行すべきか判断しにくい。Erratum 2924は最終IPP応答について、その曖昧さをプリンター側で抑える。

三つの確認を混同しない

ただし、規則の範囲は限定されている。HTTPの100 Continueは暫定応答であり、クライアントに本文の送信を続けてよいと伝える。IPP操作の成功を示すものではない。HTTPは、メソッドを実行しない場合などに早期の最終エラーを返すこともできる。本文や接続をどう扱うかは転送層の別問題であり、Erratum 2924はすべての早期信号を違反とはしていない。

Print-Jobが成功しても、紙が出てきたとは限らない。応答にjob-idやjob-uriがあれば、クライアントはその後の状態を照会できる。2017年のRFC 8010とRFC 8011はRFC 2910とRFC 2911を更新・置換し、HTTP転送、IPP操作、ジョブのライフサイクルを区別している。文書受信、ジョブ受付、処理、印字、利用者への引き渡しは別段階だ。

記録が裏付けるのは、規則と編集上の経緯であって、実装の普及ではない。RFC 3196はInformational文書で、新たな標準トラックのプロトコル仕様ではない。RFC EditorはErratum 2924をTechnicalと分類し、Michael Sweetが2011年8月に報告、Peter Saint-Andreが同年11月に検証した。どの製品がいつ採用したか、旧文言が原因の障害があったかは、これらの資料からは分からない。特定の業界事故を描く根拠はない。

ここから得られるのは、確認応答の読み方だ。転送開始は文書全体の受信を証明せず、ジョブ識別子は印刷物の出力を証明しない。訂正は一つの曖昧さを閉じたが、その先まで保証したわけではない。

出典

一次資料は規則と訂正履歴を示すが、製品への採用率、測定性能、実運用の普及、具体的な障害、永続保存や物理的な印刷を証明しない。