要約

  • RFC 1179 は既存の LPD 実装を記録した情報文書である。TCP 515 番ポートの daemon は名前付き印刷キューへの命令を受け、待機中ジョブの印刷開始も命令として受ける。
  • Receive job では daemon がファイル・サブコマンドをまず確認し、クライアントが宣言済みバイト列の終了をゼロのオクテットで知らせ、その後に第二の確認がある。この連鎖は受信処理を示しても、印刷済みページを示さない。

一つの状態語に入らない工程

印刷要求は、アプリケーションから紙へ一度に移るものではない。クライアントが依頼し、daemon がプロトコルの一段を受理し、キューが待機項目を持ち、処理が開始され、制御ファイルがデータの解釈を指定し、最後に装置が出力するかもしれない。観測者も権限も異なる工程を「印刷完了」にまとめると、表示は分かりやすくても履歴は不正確になる。

1990年8月の RFC 1179 は、広く用いられた既存のラインプリンタ daemon プロトコルを説明したもので、Internet Standard ではない。そこにあるのは命令、ファイル形式、daemon の応答である。ネットワーク会話の応答を、物理的な出力の判定へ膨らませる契約はない。

LPD は TCP を使い、daemon はポート 515 で待つ。daemon への各命令には新しい接続を作る。バイナリの命令コードの後に ASCII のキュー名、必要なら追加のオペランドが続く。RFC は命令名を daemon に対する命令文として解釈するよう求める。命令を渡したことと、その命令が描く結果が起きたことは別である。

Print any waiting jobs はその差を端的に示す。印刷処理がまだ動いていなければ開始する命令である。特定のジョブが選ばれたこと、データが解釈できること、用紙があること、ページが出たことは報告しない。開始命令はファイル受信の後にあり、出力の観測より前にある。

ファイル受信には二つの肯定があった

クライアントが Receive job を送った後、制御ファイルまたはデータファイルを受け取らせるサブコマンドを送れる。サブコマンドの後には daemon の確認を待たなければならない。ゼロ・ビットのオクテットは肯定、他のパターンは否定である。これは交換の次の手順への応答であって、ジョブ全体への評決ではない。

次にファイル境界がある。サブコマンドはバイト数とファイル名を含み、クライアントは同じ TCP 接続でその数のオクテットを送る。送信を終えると、クライアントはゼロのオクテットを送り、送ったファイルが完了したと示す。その地点で二段目の確認が必要になる。長さを示したデータファイルも同じ構造を持つ。

ここには三つの異なる記録がある。最初の確認はサブコマンドについてのもの。クライアントのゼロは、宣言したバイト列を送り終えたという自己申告。二番目の確認は、その境界の後の daemon の応答である。これらを結べば受信交換の進行を追える。しかし、どれも印刷の観測ではない。

バイト数は文書の意味も決めない。RFC 1179 ではデータファイルに任意の8ビット値を入れられ、内容の解釈は対応する制御ファイルで決まる。数が合うことは、印刷記述として有効であること、formatter が理解すること、装置が紙へ変換したことを証明しない。

制御ファイルは指示であり、身元帳ではない

制御ファイルはホスト名、利用者識別子、元のファイル名、形式、印刷後のメール要求などを指定できる。これらは daemon がデータを扱うための入力であり、人物の検証済み身元、文書の所有、通知の受領を証明する帳簿ではない。ジョブ番号も RFC の範囲内での区別であって、永続的な世界的 ID ではない。

キューの状態照会や削除命令にも同じ境界がある。RFC は agent が他者のジョブを消せる条件を定め、root 以外には制限を置く。それは一つのローカル命令の規則であり、誰が文書を読んだか、受け取ったか、出力を管理したかを示す一般的な認可体系ではない。

LPD が残した価値は、実際に確認できる途中の状態を言葉にしたことにある。daemon がサブコマンドを受けた、クライアントがバイト列の終わりを述べた、daemon がその後応答した、キュー起動を命じた、と言える。ページが印刷され、誰かに渡り、何かが実行されたと言うには、別の表面から証拠を取らなければならない。

出典