要約

  • RFC 3510 は IPP の印刷サービスと Job を絶対形式の ipp: URL で位置付けた一方、Job URL から作成元 Printer URL を得る変換は規定されていないと明記した。
  • パス要素を一つ追加する規約は相互運用性を高めるための勧告であり、URL の永続性、相手の真正性、要求の受理、紙への出力を証明するものではない。

RFC 3510 の核心は、よく知られたポート番号よりも、標準文書としては異例に率直な訂正にある。従来の説明は、Job の URI だけが分かれば、その Job を作成した Printer オブジェクトを識別できるとしていた。RFC 3510 は、その説明を誤りだとした。IPP Model にも IPP Protocol にも、Job URL から Printer URL への変換規則がなかったからである。

URL は履歴の証明書に見えやすい。scheme、ホスト、パス、そして記録番号のような末尾が並び、画面ではクリック可能になる。しかし文字列が担うのは命名と輸送の契約である。そこへ到達できることと、誰がいつ何を行ったかは別の命題だ。

2003 年 4 月に Standards Track として公開された RFC 3510 は、RFC 2910 の IPP URL 節を拡張し、曖昧さを減らした。ipp: scheme の適用範囲、既定ポート 631、application/ipp というメディア型、文字の符号化、構文、比較方法を定めたが、新しい URL パラメータは加えなかった。

ipp: URL が示せるのは、IPP 対応印刷サービス、またはそのサービスが管理する Job などのネットワークリソースである。相対 URL は許されず、絶対形式だけを使う。RFC 2911 の抽象モデルを RFC 2910 の HTTP transport に結び付けるため、別 transport なら別 scheme が必要になる。つまり ipp: は「どこかで印刷する」という一般記号ではない。

ポートを省略した場合は 631 に解決する。比較でも、ポートなしと明示的な :631 は同値である。パスがなければ Request-URI は / となり、要求と応答は application/ipp を使う。この共通規則により、表記の違いを別サービスと誤認する余地は減った。

ただし、パスは物理構成図ではない。同じホスト上の複数パスが、それぞれ独立した Printer オブジェクトを表せる。あるパスは実機、別のパスは負荷分散 spooler、複数機器の集まり、あるいは同じ機器を利用する別々の人間向けキューかもしれない。

ここでいう Printer はソフトウェアオブジェクトであり、必ずしも目の前の印刷機ではない。spooler、gateway、物理装置のいずれにも存在し得る。Printer URL が分かっても、最終的にどの装置が紙を出すか、途中で転送されるか、受取人キューが配送先を変えるかは分からない。論理的な独立性と物理的な透明性は別物である。

Job URL はこの限界をさらに鮮明にする。Print-Job 応答が ipp://example.com/printer/123 を返したとき、末尾の /123 を削れば作成元 Printer が得られるように見える。だが RFC 2911 は Job URI の形式を実装依存としていた。RFC 3510 も、要求の printer-uri と応答の job-uri の関係は実装依存だと結論付けた。

そこで示されたのが、対応する Printer URL にちょうど一つのパス要素を追加して Job URL を作るという SHOULD である。この規約を採用する実装の前向きな生成規則は揃う。しかし、既存のあらゆる文字列を逆向きに解ける法則にはならない。勧告には理由ある例外があり、旧実装や gateway が別の命名体系を持つ場合もある。

規約に従う場合でさえ、後日のパス操作より当時の文脈の方が強い証拠になる。クライアントは、送信した printer-uri、返された job-uri、認証したサーバーの身元、応答、時刻を一緒に保管すべきである。パスは複製、代理、再割り当てが可能だが、要求と応答の組は、誰がどの交換で名前を発行したかを残す。

時間にも境界がある。RFC 3510 によれば、Job URL が有効で意味を持つのは Job 完了までであり、その後は実装が任意に設ける保存期間に限られる。したがってブックマークは永久 ID ではない。後で URL が消えていても、Job が存在しなかった証拠にはならない。サービスが完了済みオブジェクトを消しただけかもしれない。

安全性の節は、構文が身元を代行できない理由を示す。偽の IPP URL は機密文書を悪意ある印刷サービスへ送れる。対策はサーバー認証と IPP のセキュリティ機構であり、パスの見た目ではない。反対に、正しい URL を無権限クライアントが使う問題にはクライアント認証と認可が必要だ。

IPP から LPD へのアプリケーション層 gateway は、さらに深い断絶を作る。RFC は、そこで IPP のセキュリティが密かに失われ得ると警告し、クライアント側に実用的な防御はなく、管理者がその構成を避けるべきだとした。近い側の endpoint を認証しても、その先の transport まで同じ性質だとは言えない。

URL には必要なクライアント認証方式やセキュリティ方式を表すパラメータもない。関連情報は discovery や directory から得られる。作業部会はパラメータ追加を検討したが、出荷済み IPP/1.1 実装との後方互換性を優先し、元の構文を保った。安定した名前と安全性の発見は、意図的に別の制御面へ置かれた。

証拠の階段は、URL の解析から始まる。ホスト、ポート、パスが解決し、endpoint が想定した HTTP binding で IPP を話す。サーバーの身元を認証し、クライアントの権限を確認する。Printer が操作を受理して Job を作成し、発行者と寿命を伴う Job URL を返す。Job が定義済み状態へ進み、装置が出力し、受取人が受領する。各段は次の段を自動的に証明しない。

実在するサービスでも Job を拒否できる。受理済み Job も取消し得る。ソフトウェア上の完了が物理出力より手前で観測される実装もある。出た紙が別トレイや別人へ渡ることもある。RFC 3510 はこれらを一つの成功値にまとめなかった。

Lu Heng が論じる記号的現実と運用的現実の区別を当てると、設計の節度が見える。標準 URL は共有可能な記号経路を作る。実際のコードが背後のオブジェクト、命名、保持期間、gateway の有無を決める。RFC の存在は技術契約の証拠だが、採用実績や個別文書の印刷実績ではない。

RFC 3510 は印刷を自己証明型にしたのではない。命名と transport の境界を整えながら、名前から推論できないことを明記した。その歴史的価値は、魅力的な近道を否定した点にある。Job URL は Job を指せる。しかし周囲の交換記録と実装情報なしには、それを作った Printer を教えてはくれない。

出典