トップページ - 翻訳ドキュメント - RFC 3805

原文：ftp://ftp.rfc-editor.org/in-notes/rfc3805.txt
訳注：
プリンタ関連の用語に詳しいわけではないです。聞いたことがある気がする言葉を勝手に使っています。
どこまで日本語にするかが定まらず、日本語と英語とが中途半端に共存しています。そのうち直したいです。

ソーシャルブックマーク：

Printer MIB v2

この文書の位置付け

この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards"(STD 1)を参照して欲しい。この文書の配布は無制限である。

著作権情報

Copyright (C) The Internet Society (2004).

要約

この文書は、印刷環境のためのモデルと管理可能なオブジェクトの定義を提供する。この MIB に含まれるオブジェクトとは、印刷デバイスの中の論理的・物理的な実体に相当する。この文書は RFC 1759 を廃止する。

目次

1. 導入

1.1. ネットワーク印刷環境

あらゆるコンピュータ環境において印刷文書の生成を管理することは複雑な問題である。基本的にこの問題は重複する二つの部分、印刷の管理とプリンタの管理とに分けられる。印刷は印刷されるファイルの生成に始まり、プリンタの選択、印刷属性の選択、キューイング、リソース管理、スケジューリング、そしてユーザーへの通知を含む最終的な印刷までの、印刷文書を提供する全てのプロセスを網羅する。印刷プロセスの大半はここで示すモデルの範囲外であり、プリンタの管理のみが対象である。

                図 1 - プリンタから見たネットワーク

   システム プリンタ    資源      ユーザー      ユーザー       ユーザー
    管理者  オペレータ  管理者
      O         O         O         O             O              O
    ／|＼     ／|＼     ／|＼     ／|＼         ／|＼          ／|＼
    ／ ＼     ／ ＼     ／ ＼     ／ ＼         ／ ＼          ／ ＼
      |         |         |         |             |              |
+---------+ +-------+ +-------+ +-------+   +-----------+ +-----------+
|configur-| |printer| | asset | |printer|   |   user    | |   user    |
|ator     | |manager| |manager| |browser|   |application| |application|
+---------+ +-------+ +-------+ +-------+   +-----------+ +-----------+
   ^            ^         ^         ^             |             |
   |R/W         |R/W      |R        |R      +-----------+ +-----------+
   |            |         |         |       |  spooler  | |  spooler  |
   |            |         |         |       +-----------+ +-----------+
   |            |         |         |             |             |
   |            |         |         |       +-----------+ +-----------+
   |            |         |         |       |supervisor | |supervisor |
   |            |         |         |       +-----------+ +-----------+
   |            |         |         |        ^       ^     ^       ^
   |            |         |         |        |R      |R/W  |R      |R/W
   v            v         |         |        |       |     |       |
==================================================   |   =====     |
                     |                          print|        print|
                     |SNMP                       data|         data|
  +-----+        +-------+                        PCL|          PCL|
  | MIB |<------>| agent |                 PostScript|   PostScript|
  +-----+        +-------+                       NPAP|         NPAP|
                     |unspecified                etc.|         etc.|
              +=============+  +-----------------+   |             |
              |             |--|channel/interface|<--+             |
              |             |  +-----------------+                 |
              |   PRINTER   |                                      |
              |             |  +-----------------+                 |
              |             |--|channel/interface|<----------------+
              +=============+  +-----------------+

1.2. プリンタデバイス概観

プリンタは、入力元からメディアを取り出し、ページ記述言語やページ制御言語に従ってそのメディア上に描画を行い、場合によっては仕上げ加工を行いながらその結果を何らかの出力先に出力する物理的装置である。プリンタは消耗品を消費し、廃棄物を生成し、機械的な問題を持つ複雑な装置である。物理的装置の管理において、プリンタやその様々なサブパーツに関する説明や状態や警告といった情報は、消耗品の補充や装置のメンテナンスなどのためにエンドユーザーやキーオペレータに報告されるように、管理アプリケーションから利用可能でなければならない。物理的なプリンタの管理に必要な情報と印刷ジョブの管理に必要な情報とはかなり重複しており、それぞれの管理領域でのタスクの多くは同一、または類似の情報を必要とする。

1.3. プリンタ情報のカテゴリ

プリンタに関する情報は三つの基本的なカテゴリ、説明・状態・警告に分類される。

1.3.1. 説明

説明は、プリンタとその様々なサブパーツの構成と能力に関する情報を伝達する。この情報の大部分は静的なものであり、一般にシステムの運用中には変化しないが、プリンタの修理や再構成、アップグレードの際には変化するかもしれない。説明はプリンタの目に見える状態の一部である。ここで言う状態とは、任意のタイミングにおけるプリンタの恒久的な状態を意味している。

1.3.2. 状態

状態は、プリンタとその様々なサブパーツの現在の動作状態に関する情報である。状態の使用例としては、管理アプリケーションは様々なサブパーツが印刷可能な状態なのか、あるいは印刷できない状態や将来的に印刷できなくなるかもしれない状態なのかを判断出来なければならないというものがある。

1.3.3. 警告

警告は、プリンタ内の報告可能なイベントの説明である。イベントとはプリンタの状態の変化である。これらの状態の変化の幾つかは管理アプリケーションの興味を引くものであり、それゆえに報告可能である。典型的には、これらはプリンタの印刷能力に影響を与えるイベントである。警告は通常、プリンタが接続されているコンピュータシステムの操作に対して非同期に発生する。簡便のため、これ以降 "警告"を、プリンタの状態の変化によって起こされたイベントと、そのイベントの説明との、両方の意味で使用する。

警告は二つの基本的なカテゴリ、致命的警告と非致命的警告に分類することができる。致命的警告はプリンタが停止状態に入ることがきっかけとなって起こり、その致命的警告を引き起こした条件が取り除かれない限り、印刷を続けることは出来ない。"用紙切れ"、"トナー切れ"、"排紙トレイフル"などが致命的警告の例である。非致命的警告は、印刷が停止しない状態に入るイベントによって起こる。そのような非致命的状態は、近い将来、印刷が停止する状態へと陥る原因となるかもしれない。この種の非致命的警告の例は、"用紙不足"、"トナー不足"、"排紙トレイ警告(output bin nealy full)"などである。あるいは非致命的警告は、プリンタの構成が変更されたことを示すような単なる情報提供であっても良い。

プリンタに関する説明・状態・警告の情報は、プリンタを説明するデータベースと見なすことが出来る。プリンタ用の管理アプリケーションは、そのデータベース内の情報がどのように、あるいは何の目的で必要とされるのかに基づく、異なるプリンタデータベースを参照したいだろう。

1.4. インターネット標準管理フレームワーク

現在のインターネット標準管理フレームワークを説明する詳細な概観については、RFC 3410[RFC3410]のセクション7を参照して欲しい。

被管理オブジェクトは、Management Information Base または MIB と名付けられた仮想情報ストアを通してアクセスされる。一般に MIB オブジェクトは、Simple Network Management Protocol(SNMP) を通してアクセスされる。MIB 内のオブジェクトは Structure of Management Information(SMI) で定義される手法を用いて定義される。この文書は、STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]、STD 58、RFC 2580[RFC2580] で説明されている SMIv2 に準拠した MIB モジュールを規定している。

1.5. 要求レベル

この文書におけるキーワード "MUST" "MUST NOT" "REQUIRED" "SHALL" "SHALL NOT" "SHOULD" "SOULD NOT" "RECOMMENDED" "MAY" "OPTIONAL" は、RFC 2119 で説明されているように解釈される。

準拠する実装はこの規約に従わなければならない。

2. プリンタモデル

プリンタの管理を成し遂げるには、プリンタを構成するサブユニットを表現するためのプリンタの抽象モデルが必要となる。プリンタは13種類のサブユニットから構成されるものとして記述できる。プリンタのサブユニットが物理的に認識できる装置と直接関連する必要はないという点に注目することは重要である。またサブユニットは、ページ記述言語のインタープリタや、プリンタの様々な操作モードをセットするコマンドプロセッサのような、定義可能な論理的プロセスの集合であっても良い。

図2は、プリンタとその基本的な13のサブユニットのブロック図である。

                       図 2 - プリンタブロック図

                               物理接続
                                   |
                                +-----------+
                                |           |
                            +-------------+ |
                            |  Interface  |-+
                            |    MIB-II   |
                            +-------------+
                                   |
                                +-----------+
                                |           |
                            +-------------+ |    +-----------+
                            | Channel     |-+    | Operator  |
                            |             |      |  Console  |
                            +-------------+      +-----------+
                                   |
                                +-----------+        +---------+
                                |           |        |         |
        +-----------+       +-------------+ |    +-----------+ |
        |  General  |       | Interpreter |-+    |  Alerts   |-+
        |  Printer  |       |             |      |           |
        +-----------+       +-------------+      +-----------+
                                   |
                   +-------------------------------+
                   |        System Controller      |
                   |        HOST-RESOURCES-MIB     |
                   +-------------------------------+

   +------+                    +--------+                  +--------+
   |      |                    |        |                  |        |
+-------+ |    +-------+    +---------+ |    +-------+   +--------+ |
| Input |-+  +--------+|    |  Marker |-+  +--------+|   | Output |-+
|       |===>|        |+<==>|         |<==>|        |+==>|        |
+-------+    +--+  +--+     +---------+    +--+  +--+    +--------+
   \            |  ||                         |  ||         \
    \           |  ||                         |  ||          \
     \          |  ||                         |  ||           \
    +--------+  |  |+-------------------------|  ||         +---------+
    |        |  |  +--------------------------+  ||         |         |
+----------+ |  |            Media Path          |+      +----------+ |
|  Media   |-+  +--------------------------------+       | Finisher |-+
|(optional)|                                             |(optional)|
+----------+                                             +----------+

2.1. プリンタモデル概観

このモデルは三つの基本的なパーツを持つ：(1)インタプリタへと投入されマーカーに入る印刷ファイルの流れ、(2)マーカーを通るメディアの流れ、(3)前二つの制御と手助けを行う補助的なサブユニット群。印刷データの流れは、何らかの形式のトランスポートプロトコルスタックが実行されている物理的な接続から始まる。トランスポートプロトコル(インターフェース)から提供されたデータはチャネル上に現れ、インタープリタへの入力となる。インタープリタはその印刷データをメディア上への描画に適した形式に変換する。

メディアは、そのメディアが選ばれた Input サブユニットに存在し、その後、最初に Media Path を経由して Marking サブユニットへ、そして(任意で)何らかの仕上げ処理を伴って Output サブユニットへと運ばれる。補助のサブユニットは、プリンタの制御、操作パネルの問合せ/制御、警告の報告、様々な自然言語と文字セットへのプリンタの適合を手助けする。全てのソフトウェアサブユニットは、Printer のプロセッサ・メモリ・ストレージシステムに相当する System Contoller 上で実行される。各サブユニットについては、以降で詳細に議論する。

Alerts 以外の全てのサブユニットは、状況を表す情報(説明または状態のどちらか)のみを報告する。Alerts サブユニットはイベント情報を報告する。

2.2. プリンタのサブユニット

プリンタは、グループと称される13種類のサブユニットから構成される。以下のセクションで様々な種類のサブユニットについて説明する。

2.2.1. General Printer

General Printer サブユニットは、プリンタの全般的な制御と状態に関する責任を持つ。１つのプリンタに対して正確に１つのGeneral Printerサブユニットが存在する。モデル中の General Printer Group が、General Printer サブユニットを表している。プリンタ全体の状態を提供したり、プリンタのリセットを可能にしたりするのに加え、このグループは、プリンタのパッケージ(具体的にはカバー)の状態に関する情報も提供する。General Printer サブユニットは、通常 System Controller 上に実装される。

2.2.1.1. 国際化考察

General Printer サブユニットの現地語化に関する部分は、MIB 内で使用されている特定の文字列の自然言語・国・文字セットを識別する責任を持つ。文字セットは、IANA Character Set MIB[CHARMIB] から取り込まれた IANACharset のテキスト表現を用いて識別される。

プリンタ毎に１つまたは複数の現地語化をサポート出来る。利用可能な現地語化は、Localization テーブル内で特定される。現地語化は、'xxxDescription' (サブユニットの説明)または 'prtConsoleDisplayBufferText' (ローカルコンソールの文字列)の名称を持つ文字列オブジェクトに対してのみ使用されるべきである(SHOULD)。

エージェントは、コード0〜127(10進)がUS-ASCII[ASCII]であるコード化された文字セットにおけるその他の全ての文字列を返すべきである(SHALL)。文字セットと言語に関する IETF のポリシーに従うために、エージェントはその他の全ての文字列を、ISO 10646[ISO10646] の UTF-8[RFC3629] 変換して返すべきである。オブジェクトの DESCRIPTION で特に要求されるのではない限り、制御コード(10進数でコード0-31および127)を使用するべきではない(SHALL NOT)。

General Printer の Localization テーブルの文字セットに関する部分は、オペレータコンソールに使用可能な文字セットと、表示オブジェクトのためのネットワーク管理要求を識別する責任を持つ。１つのプリンタに対して１つまたは複数の文字セットが存在して良い。Interpreter ユニットのためにコード化される文字セットと出力オクテットのデフォルトは、Interpreter サブユニット内の prtInterpreterDefaultCharSetIn および prtInterpreterDefaultCharSetOut によって表される。これらの入出力用文字セットは、インタープリタ言語内のコマンドによって上書きされても良い。

2.2.2. Inputs

Input サブユニットは、描画が行われるメディアをプリンタ内へと搬送するメカニズムである。１つのプリンタが１つまたは複数の Input サブユニットを持つ。モデル中の Input Group がそれらを表現している。モデルは、固定された給紙ビンと脱着可能なトレイを区別しない(脱着可能なトレイが取り外された時の報告を除く)。

独立して選択可能な給紙 "アドレス" と同じ数だけ Input サブユニットが存在する。例えばあるトレイが手動給紙と自動給紙の両方の機能を持っている場合、その二つの給紙を個別に選択出来る(選択しなければならない)場合には、それは二つの Input サブユニットということになる。しかしながら、手動給紙スロットに用紙を置くことが上記のトレイからの給紙よりも優先されるのであれば、それは１つの Input サブユニットと見なされるだろう。後者の場合、手動給紙スロットを独立して選択または指示する方法が存在しないためである。

2.2.3. Media

１つの Input サブユニットは、描画が行われる１つまたは複数のメディアの実体を保持することが出来る。一般的に、１つの Input サブユニットに対し、利用可能なメディアの大きな集合が存在する。Media Group は Input Group の拡張であり、Input サブユニット内のメディアを表している。Media Group は各 Input サブユニットの現在の内容を表しているだけであり、Input サブユニットに収容可能な内容は表しているのではない。

2.2.4. Outputs

Output サブユニットは、描画が行われたメディアを受け取るメカニズムである。モデル中の Output Group が、プリンタの持っている１つまたは複数の排紙メカニズムを表している。モデルは、固定された排紙ビンと脱着可能な排紙ビンを区別しない(脱着可能なビンが取り外された時の報告を除く)。

独立して選択可能な出力 "アドレス" と同じ数だけ Output サブユニットが存在する。Output サブユニットは２つ方法 (1) ビン番号またはビン名などの特定のメールボックスセレクタによって示される "メールボックス" の集合として、または(2) 複数のコピーが丁合を取られる "スロット" の集合として、という２つの手法で指定される。同じプリンタに両方のモードの Output サブユニットが使用されることもある。モデル化の観点から見て重要なことは、その Output サブユニットが個別に選択できるということだけである。

2.2.5. Finishers

Finisher は、メディアに対して描画以外の何らかの操作を行うサブユニットである。モデル中の Finisher Group が Finisher サブユニットを表している。仕上げ(finishing)プロセスの例には、ステイプル留め・パンチ・製本・挿入・折りたたみ等がある。仕上げプロセスは、そのプロセスに関連する消耗品を使用しても良い。ステイプル留め・製本・パンチは、消耗品を使用するプロセスの例である。１つのプリンタが１つ以上の Finisher サブユニットを持っても良く、各 Finisher サブユニットが１つまたは複数の Output サブユニットに関連しても良い。Finisher に付いては関連文書 Finisher MIB[RFC3806] で説明されている。

このモデルでは、排紙装置とそれに対応するフィニッシャとの間の正確な会話とシーケンスに付いては規定しない。それは仕上げプロセスの種類とプリンタシステムの正確な実装に依存する。この標準は、仕上げプロセスと排紙装置との論理的な対応は考慮しているが、対応する排紙装置との綿密なシーケンスや対話には何の制限も課さない。プリンタの正確な実装によっては、Output サブユニットと Finisher サブユニットとは個別に認識可能な物理的メカニズムに分けられても良いし、分けられなくても良い。さらに、１つの排紙装置が複数の Finisher サブユニットに関連しても良いし、１つの Finisher サブユニットが複数の排紙装置に関連しても良い。

2.2.6. Markers

Marker は印刷メディアに描画を行うメカニズムである。モデル中の Marker Groupが、Marger サブユニットとそれに関連する消耗品を表している。１つのプリンタが１つまたは複数の描画メカニズムを持つことが出来る。複数 Marker サブユニットの例としては、通常インク用と磁気インク用に別々のマーカーを持つプリンタや、補強加工デバイス(proofing device)と最終フィルムの両方に出力できるイメージセッター等がある。各描画デバイスは、それに関連する特性(描画技術や解像度など)の集合を持つことが出来る。

モデル中の Marker サブユニットは非常に一般化されたものと見なされており、描画プロセスの全ての側面を網羅している。例えば静電プロセス(xerographic process)の場合、融解プロセスと同時に描画プロセスも Marker の一般化されたコンセプトに含まれる。描画プロセスの一般化されたこのコンセプトの結果、１つの Marking サブユニットに関連する複数の描画用消耗品の概念が生じる。例えば乾燥印刷プロセスでは、トナーだけではなく融解用消耗品(例えば融解オイル)のような、個々に消費や交換が可能な他の消耗品が存在しても良い。さらにカラー印刷のプロセスの場合には、単一の描画デバイスに対して複数のトナーが存在するだろう。

2.2.7. Media Paths

Media Path は、メディアをプリンタ内で移動させ、メディアに関連する他の全てのサブユニット(Input、Output、Marker、Finisher)へと繋げるメカニズムを網羅する。１つのプリンタが１つ以上の Media Path を持つ。Media Path Group は全てのPathに適用されるいくつかのオブジェクトに加え、個々の Media Path のテーブルを持つ。

一般に Medhia Path の設計は、プリンタが扱える最大メディアサイズと同時に、プリンタの最高速度を決定する。Medhia Path は複雑なメカニズムであり、メディア搬送装置やメディアバッファ、両面ユニット、インターロックなどの、個々に識別可能なサブメカニズムを含むことが出来る。これら全てのサブメカニズムが全てのメディアパスに存在するわけではない。例えば、あるメディアパスではメディアの片面だけに印刷し、別のメディアパスではメディアを裏返して描画サブユニットに再度搬入するサブメカニズム(両面パス)を持っても良い。さらに両面パスでは、裏面を描画する前に表面だけ描画された複数のコピーをバッファするためのメカニズムを持っても良い。

2.2.8. System Controller

System Controller はプリンタのソフトウェアコンポーネントが実行されるサブユニットである。モデル中のHost Resources MIB[RFC2790] が System Controller を表している。Host Resources MIB はプリンタのプロセッサやメモリ、ディスク、ファイルシステム、およびその他の下位のサブメカニズムの仕様を考慮している。コントローラは単純なシングルプロセッサシステムからマルチプロセッサシステムまで網羅できる。さらにコントローラは、ハードディスクのような資源全体も網羅することが出来る。プリンタが複数のプロセッサと複数の資源を持っている場合でも、プリンタは１つの System Controller を持つようにモデル化される。

2.2.9. Interfaces

Interface は、プリンタへのデータ送信に責任を持つ通信部分と、それに関連するプロトコルである。１つのプリンタが１つ以上の Interface サブユニットを持つ。Interface は MIB-II[RFC1213],[RFC2863] の Interface Group によって表される。Interface の例としては、(簡単なプロトコルを持つか全くプロトコルを持たない)シリアルポートや、インターネットの IP や Novell の IPX 等が動作するイーサネットポートなどがある。

2.2.10. Print Job Delivery Channels

Print Job Delivery Channel サブユニットは、独立した印刷データソースを識別する(ここでの印刷データとは、印刷されるページを生成するために使用され、データおよび制御の両方を持つことが出来る情報である)。１つのプリンタが１つ以上のチャネルを持つ。モデル中の Print Job Delivery Channel Group がチャネルサブユニットを表している。プリンタへの印刷データの配送に使用される各チャネルとサービスプロトコルは、典型的には電子パスによって識別される。チャネルサブユニットは独立して利用可能(印刷データが流れることが可能な状態)または利用不可能(印刷データが流れることを止められた状態)であることが許される。これは、どのインタープリタが使用されるのかを特定したり、インタープリタ(およびSNMP)による環境変数の問い合わせや変更に使用されたりする、現在の制御言語(Control Language)を持つ。制御言語により明示的にインタープリタが指定されなかった場合に使用されるデフォルトのインタープリタも存在する。Print Job Delivery Channel サブユニットは、下層のインターフェイスに基づくことが出来る(通常はそうである)。

2.2.11. Interpreters

Interpreter サブユニットは、印刷データの内容をメディアに描画されるイメージへと変換する責任を持つ。１つのプリンタが１つ以上のインタープリタを持つ。モデル中の Interpreter Group が Interpreter サブユニットを表している。一般に各インタープリタは、System Controller サブユニット上で実行されるソフトウェアと共に実装される。Interpreter Table は、ページ記述言語インタープリタ(Page Description Language(PDL) Interpreter)と制御言語インタープリタ(Control Language Interpreter)の両方を含む１つのインタープリタ毎に１つのエントリーを持つ。

2.2.12. Console

多くのプリンタはプリンタ上にコンソール(プリンタの状態の表示や変更に使われるオペレータコンソール)を持つ。コンソールは数個のインジケータとスイッチだけといった簡単なものでも良いし、フルスクリーンディスプレイとキーボードといった複雑なものでも良い。このようなコンソールは高々１つだけ存在する。モデル中の Console Group がコンソールサブユニットを表している。そこに表示される情報の多くは様々な Group によって示されるプリンタの状態からも知ることが可能であるが、遠隔地からオペレータコンソールを問い合わせたり変更したり出来ることは有用である。例えば、管理アプリケーションはリモートプリンタのオペレータコンソール上のメッセージを利用者に示したいかもしれないし、管理アプリケーションの利用者はリモートプリンタのオペレータコンソール上の現在のメッセージを修正したいかもしれない。また別の例として、リモートアプリケーションがワークステーションの画面上に仮想コンソールを表示することも出来る。プリンタステータスのコンソールへのマッピングとその逆のマッピングの規則は標準化されていないため、コンソールのボタンとメニューの動作やコンソールの状態を再現することは不可能である。それゆえ、Console Group はコンソールへのアクセス手段を提供する。オペレータコンソールは通常、入力と表示のための追加のハードウェアと共に System Controller 上に実装される。

2.2.13. Alerts

Alert サブユニットは、報告可能なイベントの検出と警告テーブルへのエントリーの作成、そしてそのイベントが致命的なイベントであった場合には(その場合にのみ)トラップを起動する責任を持つ。この規則の例外は、トラップ "alertRemovalofBinaryChangeEntry" が生成された場合である。Alert サブユニットは Alerts Group と、具体的には Alert Table によって表される。このテーブルは、重要度・サブユニット・サブユニット内の詳細な位置情報・警告コード・プリンタ内でアクティブな各警告の説明を含む。報告可能なイベント毎に、Alert Table へ追加されるエントリーが発生する。

2.2.13.1. 状態と警告

プリンタの状態に関するサマリー情報は三つのレベル： (1) 全体としてのプリンタの状態、(2) サブユニットを表す Group のテーブル内で報告される様々なサブユニットの状態、(3) Altert Table内で報告される Alertコード、で報告される

2.2.13.2. 総合的なプリンタステータス

プリンタが取ることの出来る多くの状態のうち、管理者による特別な操作を必要とするような特定の状態は、より "興味深い(interesting)" ものと言える。このような状態は、全体としてのプリンタ、または特定のサブユニットに適用されることが許される。これら名前の付けられた状態とは以下の通りである：

非致命的警告(Non Critical Alert Active) - プリンタ全体の場合、１つ以上のサブユニットが非致命的警告を含んでいることを意味する。サブユニットの場合、そのサブユニットが非致命的警告を含んでいることを意味する。

致命的警告(Critical Alert Active) - プリンタ全体の場合、１つ以上のサブユニットが致命的警告を含んでいることを意味する。サブユニットの場合、そのサブユニットが致命的警告を含んでいることを意味する。

利用不可(Unavailable) - プリンタまたはサブユニットが利用出来ない(別の用語で "故障(broken)" あるいは "ダウン(down)" と同じ意味である)。一般にこれを利用可能にするには、訓練されたサービスマンが必要とされる。

オンラインまたはオフラインへの移行中(Moving on-line or off-line) - プリンタはオフライン、オフラインへの移行中、オンラインへの復帰中の何れかである。例えば電動ホッパーを持つプリンタでの用紙の補充は、用紙ビンを開くためにオフラインへの移行を発生させ、ホッパーに補充を行い最後に用紙ビンが印刷用に再配置されることでオンラインへと移行する。

スタンバイ(Standby) - プリンタまたはサブユニットは、すぐには利用できないが、次の指示を受け付けることは出来る。

利用可能(Available) - プリンタまたはサブユニットは通常通り機能している。

アイドル(Idle) - プリンタまたはサブユニットはすぐに利用可能である。

アクティブ(Active) - プリンタまたはサブユニットは、その主要な機能を実行中である。

使用中(Busy) - プリンタまたはサブユニットは何らか動作(主要な動作である必要はない)を実行中であり、主要な機能をすぐに利用可能な状態ではない。

Host Resources MIB [RFC2790] はプリンタの状態を説明するために使用される３つの状態オブジェクトを提供している: (1) hrDeviceTable 内のエントリーの hrDeviceStatus、(2) hrPrinterTable 内の hrPrinterStatus、(3) hrPrinterTable 内の hrPrinterDetectedErrorState 。これらのオブジェクトはプリンタが取り得る多くの状態を説明する。以下のテーブルは、Host Resources MIB 内のこれら三つのプリンタ関連オブジェクトの値が上記の状態とどのように関連するのかを示している。

これらの状態は起こり得る状態のサブセットに過ぎない - すなわち、これらは起こり得る状態の完全なリストではない。それでも注意するべき事柄がいくつかある。これらの状態を利用する時、致命的警告と非致命的警告とが同時に保留(pending)されていることを検出するのは不可能である - 両方が保留の場合には致命的警告の状態が優先される。さらに Host Resources MIB におけるスタンバイ状態のプリンタは、デバイスステータスが実行中(2)でプリンタステータスがその他(1)という、この重要なプリンタの状態を一意には識別しない状態の集合として表されるだろう。

サブユニット毎の詳細な状態は、サブユニット状態フィールド内に報告される。

2.2.13.2.1. Host Resources MIB Printer Status

網羅性のため、Host Resources MIB [RFC2790] のプリンタステータスオブジェクトの定義を以下に示す。

2.2.13.2.2. Sub-unit Status

サブユニットのステータスは、そのサブユニットを表すグループ内の主テーブル(principle table)のエントリー内に報告される。このテーブルにはステータスを報告するサブユニットのためにステータス列が存在し、通常その列の値は以下の方法に従う整数値となる。

PrtSubUnitStatusTC は、５つの独立した値(可用性・非致命的警告・致命的警告・オンライン・移行中)の合計となる整数値である：

例えば最終用紙の直前に紙詰まりを起こした給紙(トレイ)の場合、ステータスは27(紙詰まりによる 故障(3) + 致命的警告(16)と、用紙不足による非致命的警告(8)とにより利用不能)を示すだろう。

2.2.13.3. Alert Tables

Alert Group は全てのアクティブな警告を表す単一のテーブルから構成される。このセクションではそのテーブルの概要と、それがどのように管理されるかの解説を提供する。Alert Table の基本的な内容は、警告の深刻度(致命的または非致命的)、警告を発生させた状態変化が起こったグループとエントリー、警告に関する追加情報(より詳細な場所・警告コード・説明)、その警告を回復するために必要とされるトレーニングレベルの目安、である。

Alert Table は、冗長な情報(例えばイベントが発生したという情報)と、Alert Table にのみ現れる情報(例えば追加情報)を含んでいる。グループ内の単一のエントリーが２つ以上の警告を発生させ得る(例えば複数箇所での紙詰まり)ため、単一のテーブルが使用されている。追加情報と影響を受けたグループのエントリーとを関連付けるとき、その追加情報をそのエントリーに関連付けることで複数の報告が発生し得る場合には、１つの報告に対してのみ許される。プリンタ内で警告が発生する毎に、プリンタは１つ以上のエントリーを Alert Table に作成する。プリンタは、イベントが致命的・非致命的の何れに分類されるのかを決定する。警告の重要度が "致命的" の場合、プリンタはテーブルが変更されたことを示すトラップまたはイベント通知をホストに送信する。トラップが送信されるかどうかに関わらず、ユーザーに信頼できる情報を提供できるように、管理アプリケーションはどの状態が変化したのかを判断するために定期的にプリンタをポーリングし、このテーブルの読み取りと解析を行うことを期待される。

2.2.13.4. Alert Table の管理

警告テーブルは密度の低いテーブルである。これは、テーブルが現在アクティブな警告のエントリーのみを含み、テーブル内の行数またはエントリー数が動的であることを意味している。プリンタの実装によっては一度に２つ以上のイベントが追加または削除されても良い。

警告を生成するイベントは基本的に２種類存在する: 双変化イベント(binary change events)と単変化イベント(unary change events)である。双変化イベントはリーディングエッジイベントとトレイリングエッジイベントという対になって現れる。リーディングエッジイベントは出口が１つだけの状態へ入る(例えば実行状態から紙詰まりによる停止状態へ)。この状態からの唯一の出口は紙詰まりを修復することであり、それが行われるタイミングは明確である。トレイリングエッジイベントはリーディングエッジイベントで入った状態から出る。先の例の場合なら、紙詰まりの修復がトレイリングエッジイベントとなる。

Alert Table 内の双変化イベントを管理することは比較的容易である。リーディングエッジイベントのみが Alert Table にエントリーを作成する。Alert Table 内のリーディングエッジイベントの削除を示唆するトレイリングエッジイベントが発生するまで、このエントリーは存在し続ける。つまりトレイリングエッジイベントはエントリーを生成せず、対応するリーディングエッジイベントを削除するということである。リーディングエッジのエントリーの削除が単変化イベント "alertRemovalofBinaryChangeEntry" を発生させても良い。双変化イベントは同時に起こり得る最大数を計算することが出来るため、その多数のイベントを保持する Alert Table を作成することが可能である。テーブルがオーバーフローしたり、未解決のイベントに関する情報が失われたりする可能性は無い。

残念ながら、双変化イベントではないイベントが存在する。このもう１つのイベントカテゴリ(単変化イベント)は、構成が変化するイベントによって説明される。この種のイベントでは、機械の状態は変化したが、以前の状態と同程度に有効かつ戻る必要のない状態へと変化している。例えば、オペレータは主給紙ソースの用紙をレター用紙からリーガル用紙に変更するかもしれない。将来その用紙をレターに戻す可能性もあるが、そうではなくエグゼクティブ用紙かもしれない。ここが問題となるところで、Alert Table 内の単変化イベントのエントリーをいつまで保持すれば良いのかが明確ではない。もしそれらのエントリーが永久に削除されなければ、Alert Table は際限なく増加してしまうだろう。

エージェントは(特に双変化イベントの組や単変化イベントがテーブルをオーバーフローさせるかもしれない場合に) Alert Table を管理するために実装されたアルゴリズムを持つ必要がある。テーブルが一杯の時にさらに新しい警告を追加する必要がある場合、削除されるべき古い警告は以下の規則に従って選ばれるべきである：

1. 非致命的な単変化の警告を探し、それを削除する。複数の非致命的な単変化の警告がある場合、もっとも古いものを選ぶことが推奨される。非致命的な単変化の警告が無い場合は、
2. 非致命的な双変化の警告を探し、それを削除する。複数の非致命的な双変化の警告がある場合、もっとも古いものを選ぶことが推奨される。非致命的な双変化の警告が無い場合は、
3. 致命的な(双変化の)警告を探し、それを削除する。複数の致命的警告がある場合、もっとも古いものを選ぶことが推奨される。エージェントの実装者は、同時に起こり得る致命的警告の最大数を保持するのに十分な領域を提供することが推奨される。致命的警告は全て双変化イベントであることに注意してほしい。

Alert Table から削除された致命的な双変化警告のイベント中の場合、領域が空き、かつその警告条件にまだ当てはまるなら、対応する状態への遷移が存在しなかったとしても、Alert Table に再度追加されるべきである。これは、非致命的な双変化の警告でも同様に行われることが推奨される。追加される新しい警告エントリーは、テーブルから削除された元のエントリーと同じインデックスを持たないことに注意してほしい。

Alert Index は単調に増加する整数であるため、警告が削除されるとテーブル内の値に隙間が出来ることに注意してほしい。このような隙間を検出した場合、管理アプリケーションはプリンタの状態を再取得し、自分が観測しなかった状態変更を確認したいだろう。

2.3. Read-Write Objects

Printer MIB のいくつかのオブジェクトは、プリンタ内の特定のリソースの量や存在性を反映する。そのようなリソースの例としては、用紙トレイ内の用紙の数量やサイズ、ある種の出力オプションの存在などがある。プリンタによっては、これらのリソースの自動センサーを持っている。大部分のプリンタは全てのリソースのあらゆる属性のセンサーは持っていない。管理アプリケーションはこれらの値を検出できないプリンタのために、説明的な値または存在性を示す値を保持するオブジェクトへの書き込みを許される。読み書き可能オブジェクトの値を変更する能力は、エージェントの実装に依存しても良い。MIB の多くのオブジェクトは読み書き可能アクセスが許されているが、プリンタの実装は、管理アプリケーションがその値を変更することを、プリンタ自身が値を検出できない場合にだけ許可しても良い。いくつかのオブジェクトは値を変更するこの条件付き能力の振る舞いを明示的に宣言しているが、全ての読み書き可能オブジェクトはこのように振る舞うことを許される。

一般にオブジェクトは、以下の場合にPrinter MIB仕様において読み書き可能アクセスを与えられる：

1. そのオブジェクトが、ある種のプリンタが自身では検出できないリソースの導入に関連している場合。したがって、その導入をプリンタに知らせるためには外部の手段が必要とされる(ここでの外部とは、オペレータコンソールやリモート管理アプリケーションの利用を含む)。そして、
2. リソースの導入が報告されるなら、プリンタはリソースの導入が報告されない場合とは異なる振る舞いをするだろう。言い換えると、そのオブジェクトはプリンタが使用しない情報を置く場所としては使用されない。つまり、"sticky-note" ではない(訳注：sticky-note とは、粘着性のあるメモ用紙、つまり付箋紙みたいなもののことですが、適当な訳語が思いつかないのでそのままにしました)。別の言い方をすると、プリンタは与えられた情報を信頼し、その情報が正しいものとして動作するということである。例えばサイズを検出できないプリンタに何らかのサイズの用紙が搭載され、用紙サイズオブジェクトには別のサイズが設定された場合、プリンタは描画や用紙搬送における現在の用紙サイズとして、設定されている方のサイズを使用するだろう。
3. プリンタは、プリンタが知ることを許されていない特定のリソースの属性や存在についてのヒントを取得しても良い。例えば用紙トレイは取り外しと再装着が許されている。この取り外しと再装着が起きた場合、プリンタはその属性(トレイ上の用紙のサイズなど)が変化していないと仮定するか、対応するオブジェクトの値を"不明(unknown)"に変更するか、どちらかを許される(トレイ上の用紙の量についても同様だろう)。プリンタがオブジェクトの値に従って動作する限り、どちらの方法も受け入れられる。
4. 電源サイクルやコールドスタートをまたがって MIB オブジェクトの値が永続性を持つかどうかは実装依存である。prtMarkerLifeCount オブジェクトの値がプリンタのライフサイクルを通して持続することは特に重要である。従って、任意の MIB オブジェクトの値が電源サイクルをまたがって永続性を持つなら、prtMarkerLifeCount オブジェクトも永続性を持たなければならない。

2.4. 列挙型

列挙型(enums)は、１つまたは複数のオブジェクトで使用されるために定義されたシンボル値の集合である。共通して使用される列挙型は、各オブジェクト定義の SYNTAX 節で規定されるのではなく、シンボル化されたデータ型名(テキスト仕様(textual convention))を割り当てられる。

Printer MIB または関連する IANA Printer MIB において定義されるテキスト仕様は、RFC の発行または Designated Expert Review(Printer MIB の 'IANA Considerations' セクションおよび IANA Printer MIB の MODULE-IDENTITY の DESCRIPTION 節を参照)によって拡張可能である。これら全てのテキスト仕様は、以下の何れかである：

• a) Printer MIB 自身において２回以上使用されている。または、
• b) 関連する Finisher MIB において使用されており、インポートされた。または
• c) その他の MIB モジュール(ベンダー固有のものも含む)において使用されており、インポートされた。

またPrinter MIB は、"Integer32" のオブジェクトにおいて通常の数値の範囲外の状態を定義するために利用する特別な値を定義している：その他(other(-1))、不明(unknown(-2))、不完全(partial(-3))である。'不完全’は消耗品が多少は残っている状態(しかしその量は不定)、または許容量に多少の余裕がある状態(しかしその量は不定)を意味する。Integer32 の範囲のフィールドは、これらの特別な値がどのオブジェクトにおいて有効であるかを示している。

2.4.1. 新しい列挙値の登録

Printer MIB および関連する IANA Printer MIB は、新しい列挙値の追加を管理するために採用されたプロセスに従って、テキスト仕様のカテゴリをそれぞれ1つずつ定義している。

Type 1 - 全ての正当な値はPrinter MIB において定義される。追加の列挙値は新しいPrinter MIB の発行を必要とする。

Type 2 - 全ての正当な値は IANA Printer MIB において登録される。追加の列挙値は、"Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] で定義されている Designated Expert Review を必要とする。Designated Expert は Application Area の IETF Area Director によって選出される。

3. 他の MIB 仕様由来のグループ

このセクションでは、Printer MIBの実装を補完して完成させるためにサポートされるべき、その他の MIB が提供しているグループを確認する。またこのセクションでは、それらの MIB グループの包含に関連する、Printer MIB 構造のそれほど明確ではないいくつかの特徴も説明している。

3.1. System Group

MIB-II [RFC1213] の system group に含まれる全てのオブジェクトは実装されるべきである。しかしながら 2.4 で説明したように、実装者は、何が "system" を構成するのかを注意深く考察するべきである。

3.2. System Controller

Host Resources MIB [RFC2790] のストレージとデバイスグループは、プリンタのシステムコントローラと任意の補助デバイスをサポートするために実装されるべきである。実装者が妥当と考えるなら、Host Resources MIB のその他のグループ(System、Running Software、Running Software Performance、Installed Software)も実装されて良い。Host Resources MIB の構造のため、システムコントローラを構成するデバイスはプリンタと同じレベルになる。

3.3. Interface Group objects

MIB-II [RFC1213] の Interfaces Group の全てのオブジェクトは、プリンタへの全ての印刷情報インターフェイス(ネットワーク以外のインターフェイスを含む)のために実装されるべきである。

3.3.1. Interface Types

RFC 1213 [RFC1213] のインターフェイスグループは、"ifType" オブジェクトにおいて指定できる部分的なインターフェイスタイプのリストしか含んでいない。インターフェイスタイプの完全なリストは、"ftp://ftp.isi.edu/mib/iana.mib/ianaiftype.mib " の IANA レジストリを参照してほしい。

4. RFC 1759 との違い

この文書は RFC 1759 を廃止し、置き換わる。しかしながら、RFC 1759 準拠の実装はこの文書にも準拠する。RFC 1759 に対し、以下の変更が行われている：(変更に関する詳細は printmib の REVISION/DESCRIPTION 節を参照)

• 比較的重要ではない訂正と変更。表紙の更新と、セクション1へのボイラープレート "SNMP 管理フレームワーク(SNMP Management Framework)" の追加。
• RFC 番号ではなく MIB の名称を使用するために図2を更新。
• コード化された文字セットの説明と IANA 登録プロセスの更新。
• RFC 2790 に従い、hrPrinterDetectedErrorState の "coverOpen" (bit 4) を "doorOpen" に変更。
• 更新された Host Resources MIB (RFC 2790) において割り当てられ、部分的に説明されている hrPrinterDetectedErrorState の第2オクテットを追加。
• RFC 2790 に従い、hrPrinterDetetctedErrorState から hrDeviceStatus (警告(warning)/ダウン(down)) の固定された関連付けを削除。
• hrPrinterDetectedErrorState オブジェクトの RFC 2790 からの引用中で、ビット15を"未割当て"として示す代わりに、それを表から削除し、文章として追加。RFC 2790ではビット15を表の中には記述していないためである。
• 国際化考察を明確化。
• チャネルの説明の明確化と相互運用性の強化のため、Channel Group のテキスト仕様にチャネル毎の prtChannelInformation を追加。
• 廃止されたいくつかのチャネルタイプを非推奨に。
• Finisher MIB が提供している値を含むように、Alert Table と PrtMarkerSuppliesSupplyUnit のテキスト仕様を拡張。
• 単変化イベントと双変化イベントの違いに基づく警告の明確化。
• (オプションの)単変化イベント alertRemovalOfBinaryChangeEntry(1801) を追加。
• prtGeneralCurrentOperator および prtGeneralServicePerson の情報に接するための慣例を作成。
• prtAuxiliarySheetStartupPage PresentOnOff を追加。
• prtAuxiliarySheetBannerPage PresentOnOff を追加。
• prtGeneralPrinterName OCTET STRING を追加。
• prtGeneralSerialNumber OCTET STRING を追加。
• prtInputNextIndex Integer32 を追加。
• Input Switching Group を追加。
• prtAlertCriticalEvents Counter32 を追加。
• prtAlertAllEvents Counter32 を追加。
• 一般的な警告コードを含む列挙型 PrtAlertCode を更新。
• ５つの OBJECT-GROUP を追加(prtAuxilliarySheetGroup,prtInputSwitchingGroup, prtGeneralV2Group, prtAlertTableV2Group,prtChannelV2Group)。それらに９つの新しいオブジェクトを追加(prtAuxiliarySheetStartupPage, prtAuxiliarySheetBannerPage,prtGeneralPrinterName, prtGeneralSerialNumber,prtAlertCriticalEvents, prtAlertAllEvents,prtInputMediaLoadTimeout, prtInputNextIndex,prtChannelInformation)。printerV2Alert を含むように、１つの NOTIFICATION-GROUP を作成(prtAlertTrapGroup)。新しい OBJECT-GROUP と NOTIFICATION-GROUP を prtMIBCompliance に含有(全て(MANDATORY-GROUP節ではなく)GROUP節に)。これら９つの新しいオブジェクトはオプションである。従ってこの文書は RFC 1759 との後方互換性を持つ。
• prtAlertTime を強く推奨。
• doorOpen(501) と doorClosed(502) の警告コードの使用を非推奨とし、coverOpened(3) と coverClosed(4) を推奨。
• PrtConsoleDisableTC と PrtMarkerAddressabilityUnitTC のテキスト仕様を追加。オブジェクト PrtConsoleDisable と PrtMarkerAddressabilityUnit の文法を、それらの TC を使用するように変更。その新しい文法を反映するように PrtGeneralEntry と PrtMarkerColorantEntry の SEQUENCE を変更。
• テキスト仕様 "PrtLocalizedDescriptionStringTC" と "PrtConsoleDescriptionStringTC" を追加し、それらを使用するようにいくつかのオブジェクトを更新。
• 大部分の列挙型をテキスト仕様に変更。それに伴い、適切なテキスト仕様を指定するように多くのオブジェクトの SYNTAX を RFC 1759 から変更(28 の TC が追加された)。
• TC の名称 "MediaUnit" を "PrtMediaUnitTC" に、"CapacityUnit" を "PrtCapacityUnitTC"に、"SubUnitStatus" を "PrtSubUnitStatusTC" に変更。
• MAX-ACCESS に read-write を持つ全てのオブジェクトは、今回 MIN-ACCESS に read-only を持つ。
• IETF のガイドラインに従い、'IANA 考察' と '国際化考察' をトップレベルのセクションとして追加。
• セキュリティと著作権のセクションを更新。
• 参考文献を更新し、参考文献と引用文献のグループに分割。
• Appendix E - 全プリンタステータス一覧 を追加。
• 参加者と連絡手段を更新。
• テキスト仕様 CodedCharSet を削除し、IANACharset からのインポートに置換。
• オブジェクトやグループが必須またはオプションであることを示すコメントを全て削除。適合性セクションとの潜在的な競合を回避。
• 空の説明節にテキストを追加(prtStorageRefTable, prtDeviceRefTable, prtMarkerTable, prtMediaPathTable, prtChannelTable, prtInterpreterTable, prtConsoleLightTable, prtAlertTable)。
• prtInterpreterDefaultCharSetIn と prtInterpreterDefaultCharSetOut に、"DEFVAL { unknown }" を追加。
• 全ての表のインデックスオブジェクトの説明節において、"...値は安定した状態を保つことを期待される" を "...値は安定した状態を保つべきである" に変更。
• Integer32 の文法を持つ全てのオブジェクトに範囲を追加。
• prtAlertGroupIndex の説明節を改定。
• prtMediaPathEntry, prtChannelEntry, prtInterpreterEntry, printerV2Alert の各説明節に文章を追加。
• この MIB およびその他の MIB のテキスト仕様の使用法を説明するためにセクション 2.4 に文章を追加。また、列挙値 'other(-1)' と 'unknown(-2)' の一般的使用法を定義する注記を追加。
• インデックスの値をゼロには出来ないため、prtStorageRefSeqNumber, prtDeviceRefSeqNumber, prtConsoleLightIndex の範囲を (0..65535) から (1..65535) に変更(RFC 1759 は誤植)。
• prtInputMediaName, prtInputMediaColor, prtInputMediaType の各オブジェクト用に、今回 Standardized Media Names のための PWG Standard が推奨されている。
• prtChannelTypeTC に chSMTP(45) を追加。

5. The IANA Printer MIB

6. The Printer MIB

--             INPUT の計測
--
--     _______ |               |
--      ^      |               |
--      |      |               |                 |
--      |      |_ _ _ _ _ _ _ _| _______________ | 方向
--      |      |               |      ^          v
--   最大容量  |  トレイ内の   |      |
--      |      |   残シート    | 現在のレベル
--      |      |               |      |
--      v      |               |      v
--     _______ +_______________+ _______

--            OUTPUT の計測T
--
--   _______  |                | ________
--      ^     |                |     ^
--      |     |                |     |
--      |     |                |  残許容量
--   最大容量 |                |     |
--      |     |                |     v           ^
--      |     |_ _ _ _ _ _ _ _ | _______________ |方向
--      |     |                |                 |
--      |     |  Output 内の   |
--      v     |     シート     |
--   _______  +________________+

7. IANA 考察

この文書のセクション５で定義されている初期バージョンの IANA Printer MIB は IANA によってアーカイブに保管されており、この文書のセクション 2.4.1 で規定されているプロセスに従って引き続き保守されている。最新で権威のあるバージョンの IANA Printer MIB は以下のURLから入手可能である：

http://www.iana.org/assignments/ianaprinter-mib

8. 国際化考察

セクション 2.2.1.1 '国際化考察' を参照して欲しい。

9. セキュリティ考察

MIB モジュールには MAX-ACCESS 節が read-write や read-create である管理オブジェクトが数多く定義されている。このようなオブジェクトは、ある種のネットワーク環境において脆弱または細心の注意を要すると考えられ得る。セキュアではない環境において適切な保護手段なしに SET オペレーションをサポートすることは、ネットワーク運用にマイナスの影響を与え得る。ここにテーブルとオブジェクト、そしてそれらの過敏性/脆弱性に付いて示す：

SNMPv3 より前のバージョンの SNMP は適切なセキュリティを含んでいない。たとえネットワーク自体が(例えば IPSec の利用により)セキュアであったとしても、MIB モジュールのオブジェクトにアクセスしたり GET/SET (読み取り/変更/生成/削除)したりすることを、そのセキュアなネットワーク上の誰が許可するのかに関しては規制が存在しない。

実装者は、SNMPv3 の(認証とプライバシーのための)暗号化メカニズムの完全なサポートを含め、そのセキュリティ機能が SNMPv3 のフレームワーク([RFC3410], セクション 8 参照)によって提供されていると見なすことが推奨される(RECOMMENDED)。

さらに、SNMPv3 より前のバージョンの SNMP の採用は推奨されない(NOT RECOMMENDED)。代わりに SNMPv3 を採用し、暗号化セキュリティを利用可能にすることが推奨される(RECOMMENDED)。その結果、この MIB モジュールのインスタンスへのアクセス権を与える SNMP エンティティが、オブジェクトを実際に GET または SET (変更/作成/削除)する正当な権限を持つ本人(ユーザー)だけにそのアクセス権を与えるように適切に構成されることを保証するのは、顧客/オペレータの責任となる。

プリンタデバイスの操作上の能力が、管理するには著しく脆弱または困難な場合、この MIB 内の特定のオブジェクトは、変更を防止するために READ-ONLY としてタグ付けされている。さらに、この MIB 内の READ-WRITE オブジェクトのためにこのワーキンググループは、ベンダーがそれらのオブジェクトを READ-ONLY として実装することが自由であると述べている特別な適合ガイドラインを含んでいる。この適合性の許容は、特定のベンダーの脆弱性が製品ごとに異なる場合もカバーするべきである(MIN-ACCESS 節に関する適合性セクションを参照してほしい)。

10. 参考文献

10.1. 引用規格

[ASCII] ANSI, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986.

[CHARSET] IANA Character Set Registry: http://www.iana.org/assignments/character-sets

[CHARMIB] IANA Character Set MIB: http://www.iana.org/assignments/ianacharset-mib

[ISO10175] ISO, "Document Printing Application (DPA)", ISO 10175, 1996.

[ISO10646] ISO, "Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO 10646-1, September 2000. ISO, "Universal Multiple-Octet Coded Character Set (UCS) - Part 2: Supplemental Planes", ISO 10646-2, January 2001.

[PWGMEDIA] IEEE-ISTO PWG "The Printer Working Group Standard for Media Standardized Names", IEEE-ISTO PWG 5101.1-2002.

[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000.

[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.

[RFC3806] Bergman, R., Lewis, H., and I. McDonald, "Printer Finishing MIB", RFC 3806, June 2004.

10.2. 参考規格

[APPLEMAC] Apple staff, "Inside MacIntosh: Networking", 1994.

[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.

[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.

[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, August 1990.

[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.

[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol - HTTP/1.0", RFC 1945, May 1996.

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 1999.

[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.

[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.

[RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.

[RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.

[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.

[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.

[RFC3285] Gahrns, M. and T. Hain, "Using Microsoft Word to create Internet Drafts and RFCs", RFC 3285, May 2002.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.

Appendix A - 用語集

位置指定可能性(Addressability) - マーカーにおいて、位置指定可能性単位(addressability unit)当たりの独立して描画可能な単位(pel)の数。例えばインチ当たり300ドットであれば、1000 千分の一インチ当たり 300 (300 per 1000 Thousandths Of Inches)と表現され、ミリメートル当たり4ドットであれば、1000 マイクロメートル当たり 4 (4 per 1000 Micrometers)と表現される。アドレス可能な別々の位置は、描画エリア内のゲインにより重なったりほとんど同じ位置になるといった要因のために目視では確認が出来ないかもしれない。そのため、位置指定可能性は解像度ではない。

警告(Alert) - 警告テーブルにエントリーが存在する報告可能なイベント。

ビン(Bin) - Output サブユニットの１つで、取り外しが可能でも良いし、可能でなくても良い。

双変化イベント(Binary Change Event) - リーディングエッジイベントとトレイリングエッジイベントの組で現れるイベント。リーディングエッジイベントは出口が１つだけの状態に入る。双変化イベントは致命的でも非致命的でも良い。参照：単変化イベント。

バースティング(Bursting) - 連続するメディアを個々の束に分ける処理。典型的には、事前に形成された打ち抜き穴に沿って分けられる。

チャネル(Channel) - プリンタに提供されるデータの単独ソースを説明するために使用される用語。プリンタを説明するために私たちが使用するモデルは、任意の数のチャネルを許可している。同じ物理ポート上に複数のチャネルが存在することが出来る。一般にこれは、単一プリンタの同じ物理ポート上で、EtherTalk・TCP/IP・SPX/IPX プロトコルが同時に異なるデータストリームを提供できる Ethernet ポート上で実現される。

丁合(Collation) - 複数部の出力において、個々のコピーのページを、いつでも束ねることができる別々の束に配置すること。

制御言語(Control Language) - 印刷データチャネルを通してプリンタを制御するためのデータの文法または言語。

致命的警告(Critical Alert) - プリンタが利用不能な状態(プリンタは停止する)になるイベントによって引き起こされる警告。

デコレーティング(Decollating) - マルチパート形式の個々のパートを、各パート毎に別々のスタックに分割・ソートさせる処理。

説明(Description) - プリンタおよびその様々なサブユニットの構成と能力とに関する説明。

DPA - ISO 10175 Document Printing Application standard。(1) スプーラに印刷ジョブを投入したり、(2)スプーラ内の印刷ジョブを管理することを含む、印刷システムのためのクライアントサーバープロトコルの標準。

イベント(Event) - プリンタ内の状態変化。

グループ(Group) - プリンタのサブユニットの種類を表すオブジェクトの集合。

Host Resources MIB - [RFC2790] 参照。

IANA - Internet Assigned Numbers Authority。[RFC3232] 参照。

冪等(べきとう)(Idempotent) - 冪等とは、１回以上何度実行しても同じ状態になるような操作の属性である。これは、正しいデータベースにおいてデータ項目の状態を変更するだけで、その他の副作用を持たないようなデータ項目に対する操作に共通の属性である。SNMP のデータモデルはデータベースに対する操作のデータモデルであるため、SNMP MIB オブジェクトは冪等であると見なされるべきである。MIB が冪等ではない方法で定義された場合、パケット損失や複数のマネージャー、およびその他の一般的条件に直面したとき、そのデータモデルは些細なことで壊れてしまう可能性がある。

SNMP の Set 操作の結果として起こるべき動作に対する一般的な要求を満たすため、SNMP MIB は、ある状態から別の状態への変化が何らかの動作を引き起こす副作用を持つようにモデル化されても良い。このモデルでは、現在の値と等しい値をセットする SNMP 操作は何の動作も引き起こさないことに注意することは重要である。これは、SNMP SET リクエスト により何らかの動作が開始されることを可能にしながら、単独コマンドの冪等性を維持する。

給紙(Input) - Media Path へ搬送されるメディアのインスタンスが調達されるトレイまたはビン。

インタープリタ(Interpreter) - Page Description Language (PDL) や Control Language から構成されるデータストリームを処理するアルゴリズムの実体。

ローカライゼーション(Localization) - 現地語での情報を提供するために必要とされる自然言語・国・文字セットの仕様。

管理アプリケーション(Management Application) (別名:マネージャ(Manager)) - １つ以上の被管理ノードに対して問い合わせや管理を行うプログラム。

管理ステーション(Management Station) - １つ以上の管理アプリケーションを実行可能な物理的コンピュータ。

メディアパス(Media Path) - メディアのインスタンスを Input から マーカー へと通し、場合によってはメディアバッファや両面パスを通し、任意でフィニッシングを適用して Output へと搬送するメカニズム。Input と Output は Media Path の一部ではない。

非致命的警告(Non-critical Alert) - 印刷不可能な状態にはならない報告可能イベントによって引き起こされた警告。この種の警告は、例えばトナー不足のような印刷が将来利用不可能になるかもしれない状態につながっても良いし、プリンタの構成変更のような純粋な情報提供であっても良い。

排紙(Output) - プリンタによって処理されたメディアのインスタンスを受け取るビンまたはスタッカー。

ページ記述言語(Page Description Language (PDL)) - ページイメージのシーケンスとしての文書の電子的表現のための文法または言語。

プリンタ(Printer) - 給紙元からメディアを取り出し、メディア上に何らかのページ記述言語またはページ制御言語に従って描画を行い、場合によってはフィニッシングを適用しながら何らかの排紙先に結果を出す物理デバイス。

印刷(Printing) - 印刷されるファイルの生成に始まり、印刷属性の選択、プリンタの選択、ルーティング、キューイング、リソース管理、スケジューリング、ユーザーへの通知を含む最終的な印刷までの、印刷文書を生成するプロセス全体。

報告可能イベント(Reportable event) - プリンタを監視している管理ステーションにとって興味深いと考えられるイベント。

状態(Status) - プリンタおよびその様々なサブユニットの現在の動作状態に関する情報。これはプリンタの正確な物理的状態の抽象である。

サブメカニズム(Sub-mechanism) - サブユニットの区別可能なパーツ。

サブユニット(Sub-unit) - プリンタのパーツ。給紙ソースのような物理的なパーツでも、インタープリタのような論理的なパーツでも良い。

トレイ(Tray) - 一般的には取り外し可能な給紙サブユニット。

単変化イベント(Unary Change Event) - プリンタの状態変化(ただし、(しばしば)抜け出した状態と同じくらい有効で復帰を必要としない状態への変化)を表すイベント。参照：双変化イベント

可視状態 - プリンタの状態のうち、管理アプリケーションが調べることの出来る状態。

ワーニング(Warning) - 非致命的警告。参照：非致命的警告

Appendix B - メディアサイズ名称

PWG Standardized Media Names 仕様の section 5 Self Describing Names は、現在推奨されているメディアサイズ名を含んでいる。この付録では、RFC 1759 同様、ISO/IEC 10175 Document Printing Application (DPA) [ISO10175] 由来の標準化されているメディアサイズ名称を示す。管理アプリケーションは PWG 標準由来の名称を使用することが推奨される。しかしながら DPA を使用する多くのレガシーシステムが存在するため、開発者の便宜のためにそれらも示されている。

Printer MIB を実装するプリンタはこれらの名称の知識を持たない。しかしながら Printer MIB における全てのメディアサイズは、prtInputMediaDimFeedDirChosen と prtInputMediaDimXFeedDirChosen における値としてのメディアサイズを与えられる。

Appendix C - メディア名称

管理アプリケーション開発者への便宜のため、この付録では、ISO/IEC 10750 Document Printing Application (DPA) [ISO10175] 由来の標準化されたメディア名称を示す。メディア選択ダイアログを表示する管理アプリケーションは、ダイアログでサイズ・色・種類を別々に指定する代わりに、これらの名称を使用しても良い。このフォーマットと PWG Standardized Media Names 仕様 [PWGMEDIA] で定義されている名前とを使用して、新しい名称が作成されても良い。

標準化されたメディア名称を使用するということは、異なるシステム管理者の管理下の異なるベンダーのプリンタを扱う単独の管理アプリケーションが、同じメディアに対して同じ名称を使う傾向があることを意味する。名称によるメディア選択を使用する場合、その名称が意図する属性(サイズ、色、種類)は、MIB の適切なオブジェクト(prtInputMediaDimFeedDirDeclared、 prtInputMediaDimXFeedDirDeclared、 prtInputMediaType、 prtInputMediaColor)に明示的にマップされなければならない。prtInputMediaName オブジェクトはオペレータに対して表示されることを意図しており、純粋に説明的である。そのため、prtInputMediaName の値は他のメディア属性を変更することはなく、また、Input サブユニット内のメディアがその名称と一致していなくても警告を出すこともない。

北米のメディアのために、以下の標準値が定義されている：

封筒のために、以下の標準値が定義されている：

あまり一般的ではないメディアのために、以下の標準値が定義されている(白色のみ)：

工学メディア(engineering media)のために、以下の標準値が定義されている：

Appendix D - ユーザーの役割

背景

"役割モデル(Role Models)" の必要性の大部分は、MIB に提案されている任意のオブジェクトの重要性を理解する必要性に由来する。提案されているオブジェクトに対する実世界の必要性について、グループ内で何度も議論されてきた。大抵の場合その議論は、何らかの種類の印刷関係のタスクを実行する "活動的な(live)" 人から見た潜在的な利用法を説明する必要性に帰着する。

提案されているオブジェクトの値をそれに関連する人間のユーザーの認識を通して決定することは、一貫性のためにより形式化されたモデルが必要であるという、良く見られるものであることが分かった。人間指向のタスクの分類を記述するモデルは、この文書において "役割モデル(Role Models)" と呼ばれる。

役割モデルの開発においてプリンタやそれに関連する印刷システムに接する際、一般的に人が直面する共通かつ主要なタスクを識別する必要があった。ある種のタスクは様々な役割を識別するのに役立つであろうと期待された。

役割モデルの集合を提示する場合、まず最初に "代表的なプリントシステムタスク(Common Print System Tasks)" が提示され、次に役割モデルの定義の集合が続く。最後に、役割モデルとタスクを比較した単純な行列が提示される。

代表的なプリントシステムタスク(Common Print System Tasks)

プリンタや印刷システムを扱う中で人が遭遇する多くのタスクの調査により、任意の操作環境において以下のタスクが普及していることが分かった：

プリンタジョブ状態(Printer job state) - プリンタを含まないジョブの状態を決定する。

プリンタ能力(Printer capabilities) - プリンタの現在の能力を決定する。例えば利用可能なメディアサイズ、両面印刷、特定の種類のインタープリタなど。

プリンタジョブ投入(Printer job submission) - プリンタに印刷ジョブを投入する。

プリンタジョブ削除(Printer job removal) - プリンタからジョブを削除する。

イベント通知(Notification of events) - 定義済みプリンタイベントの存在通知を受け取る。イベントは、警告・エラー・ジョブステージ完了(例 "ジョブ終了(job done)")を含め、多くの種類であることが可能である。

プリンタ構成(Printer configuration) - プリンタの現在の構成を問い合わせる。

プリンタ消耗品(Printer consumables) - プリンタ内の何れかまたは全ての消耗品の現在の状態を決定する。

印刷ジョブ識別(Print job identification) - プリンタ内のジョブの識別を決定する。

プリンタ内部状態(Internal printer status) - プリンタの現在の状態を決定する。

プリンタ識別(Printer identification) - プリンタの識別を決定する。
プリンタ位置(Printer location) - プリンタの物理的な位置を決定する。

ローカルシステム構成(Local system configuration) - プリンタの操作に関する現在のローカルシステムの様々な局面を決定する。

これらの "タスク" は、ネットワーク環境におけるプリンタの操作を取り巻く要求事項の大部分を網羅する。このリストは、以下に記述する様々な役割モデルの定義の原則として提供されている。

提案されている役割モデル

以下に示すのは、任意の特定の Printer MIB オブジェクトに対する要求を評価するために使用される "役割モデル" の一覧である。カッコ内のキーワードは、この文書の後で説明されるマトリクスにおける特定の役割モデルの略称を表していることに注意してほしい。

ユーザー(User) (USER) - プリンタに印刷ジョブを投入する人またはアプリケーション。一般に、印刷環境における"エンドユーザー"と見なされる。

オペレータ(Operater) (OP) - 空のメディアトレイへの補充、満杯の出力トレイの排出、トナーカートリッジの交換、単純な紙詰まりの解消などを含む、日々のプリンタ保守に責任を持つ人。

技術者(Technician) (TECH) - 故障したプリンタの修理や定期的な予防保守、また一般にプリンタ内部に関する高度な訓練を必要とするようなその他のタスクを行う責任を持つ人。"技術者" の例としては、メーカーのフィールドサービスの代表者や、メーカーまたは類似の代理店による公式の訓練を受けた人などがあるだろう。

システム管理者(System Manager) (MGR) - プリンタ・印刷キュー・ネットワーク接続問題を含む、総合的な印刷環境に関連するコンポーネントの構成とトラブルシューティングに責任を持つ人。一般にこの人物は印刷システムコンポーネントの総合的な運用の完全性を確実にする責任を持ち、典型的にはその他の全ての役割モデルにおける関連の中心と見なされる。

ヘルプデスク(Help Desk) (HELP) - ユーザーの訓練や、ユーザーの印刷問題の解決を含む、印刷要求に関するユーザーのサポートに責任を持つ人。

資産管理者(Asset Manager) (AM) - 組織の印刷システム資源(主にプリンタ)の管理に責任を持つ人。このような人物は、印刷資源の位置を継続的に追跡・識別可能である必要がある。

収納可能数計画者(Capacity Planner) (CP) - プリンタの取得や利用傾向に基づいたプリンタの配置を計画する目的のために、プリンタ資源の利用を継続的に追跡する責任を持つ人。

インストーラ(Installer) (INST) - ローカルシステム上の印刷システムコンポーネントのインストールや構成に責任を持つ人またはアプリケーション。

監査者(Accountant) (ACCT) - 使用された資源を補充するために、印刷資源の利用を継続的に追跡する責任を持つ人。

代表的なプリントシステムタスクと役割モデルのマトリクス

以下のマトリクスは、定義済みの "代表的なプリントシステムタスク(Common Print System Tasks)" と様々な "役割モデル(Role Models)" との間の関係をより良く理解するために提供されている。

多くのタスクが多くの役割モデルに適用可能なように見えることを認識することは重要である。しかしながら、タスクの実際のコンテキストを考える場合、タスクの実際のコンテキストはしばしば役割モデルによって変更可能なものであると認識することは非常に重要である。

例えば "システム管理者" がプリンタに印刷ジョブを投入することが可能でなければならないのは明らかであるが、印刷ジョブを投入する場合、"システム管理者" と認識されているその人物は実際には "ユーザー" のコンテキストで動作している。そのため、印刷ジョブを投入するという要求は、システム管理者の要求事項としてはリストされていない。

反対に、"ユーザー" は自分が以前にプリンタに投入したジョブを削除可能でなければならない一方で、"オペレータ" はしばしば任意のプリンタから任意のジョブを削除することが可能であることを期待される。従って印刷ジョブの削除は、"ユーザー" と "オペレータ" の両方のための(微妙に異なる)要求事項である。

Role Models 役割モデル -----------

Appendix E - 全プリンタステータス一覧

ステータステーブルは、上位25のプリンタエラーのための慣例を確立している。このテーブルは、様々なプリンタの状態と、変数 Printer hrDeviceStatus・ hrPrinterStatus・ hrPrinterDetectedErrorState・ prtAlertGroup・ prtAlertCode、および様々なサブユニットステータス変数(prtInputStatus、 prtOutputStatus、 prtMarkerStatus、 prtMediaPathStatus、 prtChannelStatus)との間の推奨されている関係を定義している。このテーブルはこれらの変数の推奨される実装である。これは、その状態の結果として提供されることを期待される状態と様々な変数の集合の例を提供することで、この MIB の利用者と実装者とをガイドするために提供されている。この情報は、セクション 2.2.13.2 "総合的なプリンタステータス" を補完する。これはガイドラインであり、網羅的なリストではない。

PrtSubUnitStatusTC の定義は、SubUnitStatus が５つの独立した値/状態(可用性、致命的、非致命的、オンライン、移行中)の合計の整数であることを規定している。従って非致命的警告が示される場合、可用性・オンライン・移行中の値に非致命的警告の値(8)が合計された値になるだろう。

テーブルはランドスケープの書式で作成されており、以下に置かれている。
ftp://ftp.pwg.org/pub/pwg/pmp/contributions/Top25Errors.pdf.

Appendix F - 参加者

この文書のレビューを行い改善のための多数の示唆を提供する重要な成果を提出してくれた以下の個人に対し、Printer MIB Working Group は特別な感謝の意を表したい。

David Harrington - Enterasys Networks
Juergen Schoenwaelder - TU Braunschweig
Bert Wijnen - Lucent Technologies and IETF Op & Mngmt, Area Director

RFC 1759 を完成させた以前の作業が無ければ、このバージョンの MIB は不可能であっただろう。Printer MIB version 2 の著者は、この文書の基礎を開発した以下の個人に感謝したい。また、Printer MIB のアーキテクチャ開発における重要な技術的ガイドラインを提供してくれた Steve Waldbusser には、特別な感謝の意を示したい。

Joel Gyllenskog - Microworks
Tom Hastings - Xerox
Jay Martin - Underscore, Inc.
Ron Smith - Texas Instruments
Steve Waldbusser - Lucent Technologies
Don Wright - Lexmark
Steve Zilles - Adobe

以下の人々は、少なくとも一度は Printer MIB Working Group の会議に参加した(その多くはほとんどの会議に参加した)。

Ron Bergman - Hitachi Printing Solutions
Luis Cubero - Hewlett-Packard
Jay Cummings - Novell
Andy Davidson - Tektronix
Lee Farrell - Canon
Tom Hastings - Xerox
Scott Isaacson - Novell
Binnur Al-Kazily - Hewlett-Packard
Rick Landau - Digital Equipment Corporation
David Kellerman - Northlake Software
Harry Lewis - IBM
Pete Loya - Hewlett-Packard
Jay Martin - Underscore, Inc.
Bob Pentecost - Hewlett-Packard
Dave Roach - Unisys
Stuart Rowley - Kyocera
Bob Setterbo - Adobe
Mike Timperman - Lexmark
Randy Turner - 2Wire, Inc.
Bill Wagner - NETsilicon, Inc.
Chris Wellens - Interworking Labs
Craig Whittle - Sharp Labs
Don Wright - Lexmark
Lloyd Young - Lexmark
Atsushi Yuki - Kyocera
Steve Zilles - Adobe

重要な貢献者

Ray Casterline
Lighthouse Solutions, LLC

Phone: (716) 218-9910
EMail: RayCasterline@lhsolutions.com

Gary Gocek

Phone: (585) 223-3826
EMail: gary@gocek.org

Thomas N. Hastings
Xerox Corporation

Phone: (310) 333-6413
EMail: hastings@cp10.es.xerox.com

Scott Isaacson
Novell

Phone: (801) 861-7366
EMail: sisaacson@novell.com

Binnur Al-Kazily
Hewlett-Packard, Inc.

Phone: (208) 396-6372
EMail: binnur_al-kazily@hp.com

David Kellerman
Northlake Software

Phone: (503) 228-3383
EMail: kellerman@nls.com

Matt King
Lexmark International

Phone: (859) 232-6907
EMail: emking@lexmark.com

Jay Martin
Underscore, Inc.

Phone: (603) 889-7000
EMail: jkm@underscore.com

Mike McKay
Novell, Inc.

Bob Pentecost
Hewlett-Packard

Phone: (208) 396-3312
EMail: bpenteco@boi.hp.com

Stuart Rowley
Kyocera

Phone: (510) 299-7206
EMail: stuart.rowley@kyocera.com

Gail Songer
Peerless Systems Networking

Phone: (650) 569-4414
EMail: gsonger@peerless.com

Randy Turner
2Wire, Inc.

Phone (408) 895-1216
EMail: rturner@2wire.com

William Wagner
NETsilicon, Inc.

Phone: (781) 398-4588
EMail: WWagner@NetSilicon.com

Chris Wellens
Interworking Labs

Phone: (408) 685-3190
EMail: chrisw@iwl.com

F.D. Wright
Lexmark International

Phone: (859) 232-4808
EMail: don@lexmark.com

Lloyd Young
Lexmark International

Phone: (859) 232-5150
EMail: lpyoung@lexmark.com

Stephen N. Zilles
Adobe Systems, Inc.

Phone: (415) 962-4766
EMail: szilles@adobe.com

著者のアドレス

Ron Bergman (Chairman)
Hitachi Printing Solutions America
2635 Park Center Drive
Simi Valley, CA 93065-6209

Phone: (805) 578-4421
EMail: Ron.Bergman@hitachi-ps.us


Harry Lewis
IBM
6300 Diagonal Hwy.
Boulder, CO 80301

Phone (303) 924-5337
EMail: harryl@us.ibm.com


Ira McDonald
High North Inc
P.O. Box 221
Grand Marais, MI 49839

Phone: (906) 494-2434 or (906) 494-2697
EMail: imcdonald@sharplabs.com

Full Copyright Statement

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

知的所有権

IETFは、この文書中に説明されているテクノロジーの利用や実装に関連すると主張されるかもしれない全ての知的所有権またはその他の権利の正当性や範囲に関して、または利用可能/不可能にかかわらずそのような権利の下でのあらゆるライセンスの拡張に関して、どのような立場も取らない。また、そのような権利を認識するために特別な努力を行ったとも主張しない。RFC 文書における権利についての手続きに関連する情報は、BCP 78 または BCP 79 に見ることが出来る。

IETF 事務局への IPR 公開情報や利用可能になっているライセンス保証のコピー、またはこの規約の利用者や実装者がそのようなプロピライエタリな権利を利用するための一般的ライセンスや許可を取得しようとした試みの結果は、IETF オンライン IRP リポジトリ(http://www.ietf.org/ipr.)より入手可能である。

IETF は、著作権・特許・特許出願、またはこの標準を実装するのに必要とされるかもしれないテクノロジーをカバーするその他のプロピライエタリな権利に対し、関心のある全ての団体が注意を向けることを勧めている。IETF への情報は ietf-ipr@ietf.org へ宛てて欲しい。

謝辞

RFC Editor の働きへの基金は、現在 Internet Society によって提供されている。

トップページ - 翻訳ドキュメント - RFC 3805