インタネット印刷プロトコル(IPP) 1.1: モデル及び機能定義

この標準情報(TR)は，2000年9月にInternet Engineering Task Force (IETF)から公表されたRFC2911，Internet Printing Protocol 1.1: Model and Semanticsを翻訳し，技術的内容を変更することなく作成した標準情報(TR)である。

インタネット印刷プロトコル(Internet Printing Protocol，以下IPP)は，インタネットのツール及び技術を用いて分散型印刷に利用できるアプリケーションレベルのプロトコルとする。IPPの1.1版(IPP/1.1)は，一部管理用の操作を含んでいるが，主としてエンドユーザ機能に焦点を絞っている。この規定は，IPPのすべてを定義する一連の規定の一つとする。一連のIPP規定を次に示す。

• インタネット印刷プロトコルの設計目標 [RFC2567]
• インタネット印刷プロトコルの構造, モデル及びプロトコルに関する原理 [RFC2568]
• インタネット印刷プロトコル/1.1: モデル及び機能定義 (この規定)
• インタネット印刷プロトコル/1.1: 符号化及びトランスポート [RFC2910]
• インタネット印刷プロトコル/1.1: 実装者ガイド [IPP-IIG]
• LPDプロトコルとIPPプロトコルとの間の対応 [RFC2569]

初めてこれらのIPP規定を読む場合には，この順序で読むことを強く推奨する。

この規定は，次に示す構成をとる。

• 1.の残りで，分散型印刷のためのIPP簡易モデルを示す。

• 2.に，そのモデルで扱うオブジェクト型を，その基本的な振る舞い，属性及び相互動作によって示す。

• 3.は，IPP/1.1に含まれる操作を規定する。IPP操作は，同期型なので，操作ごとに要求及び応答がある。

• 4.は，そのモデルで用いる属性(及びその構文)を規定する。

• 5.及び6.は，それぞれ，プロトコルサポートするオブジェクトの実装適合性要件及びIANAへの考慮を要約する。

• 7.，8.，9.，10.及び11.は，引用規定，原規定の著者及び登録提案フォーマットに加えて，国際化及びセキュリティへの考慮を示す。

• 附属書A，附属書B及び附属書Cでは，用語，状態コード及びメッセージ，並びに"メディア"キーワード値を示す。

  備考　この規定は，"属性"，"キーワード"，"サポート"などの用語を用いる。これらの用語は特定の意味をもち，附属書A.2のIPPモデルのための用語，において定義される。"でなければならない(MUST)"，"してはならない(MUST NOT)"，"必要な(REQUIRED)"，"であることが望ましい(SHOULD)"，"でないことが望ましい(SHOULD NOT)"，"推奨の(RECOMMENDED)"，"してよい(MAY)"及び"オプションの(OPTIONAL)"という用語は，適合性に関する特定の意味をもつ。これらの用語は，附属書A.1の適合性の用語において定義されており，そのほとんどは，RFC2119[RFC2119]に基づく。

• 附属書Dでは，関係する属性とその値との間の相互動作の効果を明らかにする。

• 附属書Eでは，共通ディレクトリスキーマを生成するプリンタ属性の部分集合を列挙する。この属性は，プリンタを登録するときに有効であって，これによって，クライアントは，プリンタを名前だけではなく絞込み検索によっても見つけることができる。

• 附属書Fでは，IPP/1.1の規定を作成するために行った，IPP/1.0 "モデル及び機能定義"規定[RFC2566]からの追加及び変更を要約する。

• 附属書Gでは，著作権を表示する。

インタネットで動作可能な印刷プロトコルの実現を達成するために，インタネット印刷プロトコル(IPP)は，実世界での印刷課題を解決する多くの構成要素を抽象化した簡易印刷モデルに基づいている。インタネットは分散型計算環境であって, そこでは印刷サービスの要求者(クライアント，アプリケーション，プリンタドライバなど)は，印刷サービスの提供者と協同作業し対話する。このモデル及び機能定義の規定は，簡単なIPP用の抽象モデルを示す。ただし，その基盤となる構成は，複雑な"n段"のクライアントサーバシステムになってもよい。IPPモデルにおける重要な簡素化ステップは，印刷に必要となる主要オブジェクト及び主要インタフェースだけを開示することにある。このモデル規定に示すモデルは，IPPの最初の版(IPP/1.1)の適用範囲外の機能，インタフェース及び関係を含まない。IPP/1.1は，[HTPP]，[ISO10175]，[LDPA]，[P1387.4]，[PSIS]，[RFC1179]，[SWP]などの他の規定及び他の開発の作業から得た知見並びに関連する考えを数多く取り込んでいる。IPPは，文書印刷応用(Document Printing Application，DPA)[ISO10175]の規格に導入された印刷モデルによって強く影響されている。DPAは，エンドユーザ機能及び管理機能の両方を規定するが，IPPの版1.1(IPP/1.1)は，主として，エンドユーザ機能に焦点を絞り，わずかな追加的なオプションの操作者操作を伴う。

IPP/1.1モデルは，分散型印刷の重要な構成要素を次の二つのオブジェクト型にカプセル化する。

• Printer (2.1参照)
• Job (2.2参照)

各オブジェクト型は，操作(3.参照)及び属性(4.参照)の関連する集合をもつ。

しかし，(IPP/1.1モデルに基づく)実システムの実装においては，IPP/1.1モデルで明示的に定義されていない印刷サービスの他の構成要素が存在することを理解する必要がある。図1は，これらの他の構成要素に関してIPP/1.1が適合する箇所を示す。

図1 IPPと他の構成要素との位置付け

IPP Printerオブジェクトは，印刷サーバと関連付けられることが多いスプール機能，スケジュール機能及び複数の装置管理機能と共に，物理的な出力デバイスに通常関連付けられる機能をカプセル化する。Printerオブジェクトは，エンドユーザが絞込み文脈依存探索機構(附属書E参照)などに基づいてそのオブジェクトを検出し選択するディレクトリの中に，エントリとしてオプション登録される。ディレクトリは，Printerに関する比較的静的な情報の記録に用いられ，名前，文脈，プリンタ機能などの探索基準に合致するPrinterを，エンドユーザが探索し検出することを可能にする。状態，ロード済みの準備完了状態にあるメディア，プリンタのジョブ数，エラー，警告などのより動的な情報は，Printerオブジェクトを表現するだけのディレクトリの中のエントリと関連するのではなく，Printerオブジェクトそれ自体と直接的に関連する。

IPPクライアントは，クライアント側でIPPプロトコルを実装し，Printerオブジェクトを照会する能力をエンドユーザ(又はエンドユーザのためのプログラム実行)に与え，印刷ジョブを提出し管理する。IPPサーバは，サーバ側プロトコルを実装するPrinterオブジェクトの一部とする。Printerオブジェクトの残りの部分は，印刷サービスそれ自体の応用セマンティクスを実装する(又は応用セマンティクスにゲートウェイする。)。Printerオブジェクトは，出力デバイスの中に組み込まれてもよく，出力デバイスと通信するネットワーク上のホストに実装されてもよい。

ジョブがPrinterオブジェクトに提出され，Printerオブジェクトが提出要求における属性を検証するとき，Printerオブジェクトは新しいJobオブジェクトを生成する。次にエンドユーザは, 新しいJobオブジェクトと対話して，その状態を照会しジョブの進捗をモニタする。エンドユーザは，JobオブジェクトのCancel-Job操作を用いて，印刷ジョブを取り消すこともできる。エンドユーザは，JobオブジェクトのオプションのHold-Job操作，Release-Job操作，及びRestart-Job操作が実装されている場合には，それらを用いて，印刷ジョブを保留し，解放し，再始動することもできる。

特権をもったPrinterオブジェクトの操作者又は管理者は，必す(須)のCancel-Job操作，並びにオプションのHold-Job操作，Release-Job操作及びRestart-Job操作を用いて，いかなるユーザのジョブをも取り消し，保留し，解放し，再始動することができる。さらに，特権をもったPrinterオブジェクトの操作者又は管理者は，オプションのPause-Printer操作，Resume-Printer操作及びPurge-Jobs操作が実装されている場合には，それらを用いて，Printerオブジェクト(からのジョブ)の一時停止，再開又は破棄を行うことができる。

通知サービスはこのIPP/1.1規定の適用範囲外であるが，その通知サービスを用いて，エンドユーザは，Printer固有イベント及びJob固有イベントを記録し，受信することができる。エンドユーザは，Get-Printer-Attributes操作，Get-Jobs操作及びGet-Job-Attributes操作を用いたポーリングによって，Printerオブジェクトの状態を照会し，Jobオブジェクトの進捗に従うことができる。

IPP/1.1モデルは，Printer型及びJob型のオブジェクトを導入する。オブジェクトの各型は，実際のプリンタ又は実際の印刷ジョブといった実世界の実体の重要な様相をモデル化している。各オブジェクト型は，そのオブジェクト型のインスタンスがサポートできる可能な属性の集合として規定される。各オブジェクト(インスタンス)に関して，サポートされる属性及び値の実際の集合が，特定の実装を記述する。オブジェクトの属性及び値は，そのオブジェクトの状態，能力，実現可能な機能，ジョブ処理機能，並びにデフォルトの振る舞い及び特性を記述する。例えば，Printerオブジェクト型は，各Printerオブジェクトが潜在的にサポートする属性の集合として定義される。同様に，Jobオブジェクト型は，各Jobオブジェクトが潜在的にサポートする属性の集合として定義される。

オブジェクト型を定義する属性の集合に含まれる各属性は，次のとおりラベル付けされる。

• "必す(須)" ("REQUIRED")：各オブジェクトは，その属性をサポートしなければならない。 　
• "推奨"(RECOMMENDED)：各オブジェクトは，その属性をサポートすることが望ましい。
• "オプション" ("OPTIONAL")：各オブジェクトは，その属性をサポートしてもよい。

属性値の幾つかの定義は，オブジェクトがその値をサポートしなければならないか，又はサポートすることが望ましいことを示す。そうでない場合には，その値のサポートはオプションとする。

しかし，実装がある属性をサポートするとき，その実装は，その属性の可能な値を少なくとも一つはサポートしなければならない。

IPP/1.1モデルの主要構成要素として，Printerオブジェクトがある。Printerオブジェクトは，IPP/1.1プロトコルのサーバ側を実装する。そのプロトコルを使って，エンドユーザは，Printerオブジェクトの属性を照会し，印刷ジョブをPrinterオブジェクトに提出できる。Printerの抽象化の背後にある実際の実装構成要素は，別の形態及び別の構成をとってもよい。しかし，モデルの抽象化は，実際の構成要素の詳細構成をエンドユーザに見えないままにできる。3.は，Printer操作のすべてを詳細に規定する。

Printerオブジェクトの能力及び状態は，その属性によって記述される。Printer属性は，次の二つのグループに分割される。

• "job-template"属性: この属性は，Printerオブジェクトに関してサポートされるジョブ処理の能力及びデフォルトを記述する(4.2を参照)。
• "printer-description"属性: この属性は，Printerオブジェクトの識別，状態，位置，Printerオブジェクトに関する他の情報源への参照などを記述する(4.4を参照)。

Printerオブジェクトは，共通な文書出力デバイス及び印刷サービス提供者の抽象化なので，ファクシミリ装置，画像装置又はCD書込み装置などの，Printerオブジェクトと一貫性のあるセマンティクスをもつどのような実デバイス又は仮想デバイスをも表現するのに使用できる。

Printerオブジェクトをサポートする構成例を次に示す。

a)	スプーラ機能のない出力デバイス
b)	組込みスプーラをもつ出力デバイス
c)	一つ以上の関連出力デバイスをもつIPPサポートの印刷サーバ     1) 関連出力デバイスは，スプーリングジョブに対応可能でも対応不可能でもよい。     2) 関連出力デバイスは，IPPをサポートしていてもしていなくてもよい。

図2は，Printerオブジェクトが多様な分散型印刷の構成の主要部分にどのように実現されるかを例示する。図2の組込みの場合は，構成a)及び構成b)を表す。図2のホストの図及びファンアウトの図は，構成c)の1)及び構成c)の2)を表す。

この規定では，用語"クライアント"とは，IPP操作要求をIPP Printerオブジェクトに送付し，IPP操作応答を受諾するソフトウェア実体のこととする。クライアントは，次のものであってよい。

a)	エンドユーザによって制御されるソフトウェアの中に含まれる。例えば，アプリケーションの中で"Print"メニュー項目によって活性化される。
b)	出力デバイス又は他の"下りストリーム(downstream)"印刷サーバのどちらかにIPP要求を送信する印刷サーバの構成要素。

用語"IPP Printer"は，IPP操作要求を受諾しIPP操作応答を返却するネットワーク実体とする。その意味で，IPPオブジェクトは，次のものであってよい。

a)	IPP要求を受諾しデバイスを制御する(組込み)デバイス構成要素。
b)	IPP要求を受諾する印刷サーバの構成要素。印刷サーバは，一つ以上のネットワーク上のデバイスを，IPP又は他のプロトコルを使用して制御する。

凡例:

#####

出力デバイスの中に組み込まれるか，サーバの中でホストとなるPrinterオブジェクトを示す。Printerオブジェクトは，照会及びスプーリングの機能をもっていてももっていなくてもよい。

any

IPPを含むすべてのネットワークプロトコル又は直接接続を示す。

図2 分散型印刷の構成におけるPrinterオブジェクト

Jobオブジェクトは，印刷ジョブをモデル化するために用いられる。Jobオブジェクトは文書を含む。Jobオブジェクトを生成するために必要な情報は，生成要求の中で，エンドユーザからIPPクライアントを介してPrinterオブジェクトに送られる。Printerオブジェクトは生成要求の有効性を確認し，Printerオブジェクトがその要求を受諾すると，Printerオブジェクトは新しいJobオブジェクトを生成する。3.は，各Job操作の詳細を規定する。

Jobオブジェクトの特性及び状態は，その属性によって記述される。Job属性は，次の二つのグループに分けられる。

"job-template"属性

この属性は，クライアント又はエンドユーザによって供給され，すべてのPrinterオブジェクトのデフォルト及び/又は文書データの中に組み込まれた命令を上書きすることを意図したジョブ処理命令を含むことができる。(4.2を参照。)

"job-description"属性

この属性は，Jobオブジェクトの識別，状態，サイズなどを規定する。クライアントは，この属性の幾つかを供給し，Printerオブジェクトが，他の属性を生成する。(4.3を参照。)

実装は，Jobオブジェクトごとに少なくとも1文書をサポートしなければならない。実装は，Jobオブジェクトごとに複数の文書をサポートしてもよい。文書とは，次のいずれかとする。

• Printerオブジェクトによってサポートされるフォーマット(典型的には，ページ記述言語PDL)の文書データ列。
• それらの文書データ列への参照。

IPP/1.1においては，文書は，IPPオブジェクトとしてはモデル化されないので，オブジェクト識別子又は関連属性をもたない。すべてのジョブ処理命令は，Jobオブジェクト属性としてモデル化される。これらの属性は，Job Template属性と呼ばれ，Jobオブジェクトの中のすべての文書に等しく適用される。

IPPオブジェクトは，オブジェクト属性の永続的記憶と共に永続的に維持管理される関係をもつ。

Printerオブジェクトは，ジョブを"処理する"が，紙面にマークを付けるために決して実際には物理出力デバイスを用いない一つの論理デバイス又は一つ以上の物理出力デバイスのどちらかを表現する。論理デバイスの例は，ウェブページ発行者，又はオンライン文書の書庫若しくはレポジトリへのゲートウェイを含む。Printerオブジェクトは，0個以上のJobオブジェクトを含む。

Jobオブジェクトは，厳密に一つのPrinterオブジェクトに含まれるが，Jobオブジェクトに関連する同一文書データは，同じPrinterオブジェクト又は異なるPrinterオブジェクトのどちらかに送られる。この場合，最初のJobオブジェクトにほとんど同一の2番目のJobオブジェクトが生成されるが，それは新しい(別の)Jobオブジェクト識別子をもつことになる(2.4を参照)。

Jobオブジェクトは，(すべての文書が追加されてしまう以前には)空であるか又は一つ以上の文書を含むかのいずれかとする。含まれる文書が文書データ列であるとき，そのデータ列は，ただ一つの文書の中にだけ含まれることができる。しかし，同じ又は異なるJobオブジェクトの中の他の文書には，データ列の同一コピーが存在できる。含まれる文書が文書データの列への参照であるとき，(同じ又は異なるJobオブジェクトの中の)他の文書は同じ参照を含んでもよい。

Printerオブジェクト及びJobオブジェクトのすべては，URI[RFC2396]によって識別されるので，それらは永続的であいまい性なしに参照できる。各URLはURIの特化されたフォームなので，この規定の残りでは，より共通性の高い用語であるURIを用いるが，その利用法は，より特定なURLの記法をも含むことを意図している。

管理者は，トランスポート層セキュリティ(Transport Layer Security，TLS)[RFC2246]を用いて，認証及び/又はメッセージ機密をサポートするかサポートしないかのどちらかに，Printerオブジェクトを構成する。ただし，セキュリティ構成のための機構は，このIPP/1.1規定の適用範囲外とする。ある状況では，どちらの型(認証済み及び未認証)の接続も，ある種の折衝機構をもつ一つの通信チャネルを用いて確立できる。他の状況では，複数の通信チャネルが使われ，セキュリティ構成の型ごとに一つが使われる。8.に，セキュリティへの考慮及び構成の完全な記述を示す。

Printerオブジェクトが一つ以上の通信チャネルをサポートするとき，それらのチャネルの幾つか又はすべては，異なるセキュリティ機構をサポートし，要求してもよい。その場合，管理者は，一つのPrinterオブジェクトに対して，これらの複数通信チャネルを複数のURIとして同時にサポートすることを開示できる。そこでは，各URIは，そのPrinterオブジェクトに対して通信チャネルの一つを表す。この柔軟性をサポートするために，IPP Printerオブジェクト型は，"printer-uri-supported"属性という複数値の識別属性を定義する。それは，少なくとも一つのURIをもたなければならない。それは，一つより多いURIをもってもよい。つまり，各Printerオブジェクトは，少なくとも一つのURIをもつことになり，そのURIは，少なくとも一つのPrinterオブジェクトに対する通信チャネルを識別する。しかしそれは，一つより多いURIをもってもよく，そこでは各URIは，そのPrinterオブジェクトに対して別の通信チャネルを識別する。"printer-uri-supported"属性は，二つの付随属性，"uri-security-supported"及び"uri-authentication-supported"をもつ。どちらも"printer-uri-supported"として同じ基数をもつ。"uri-security-supported"属性は，"printer-uri-supported"にリストされる各URIのために用いられるセキュリティ機構を，その機構が存在する場合には，示すことを目的とする。"uri-authentication-supported"属性は，"printer-uri-supported"にリストされる各URIのために用いられる認証機構を，その機構が存在する場合には，示すことを目的とする。これらの3属性は，4.4.1，4.4.2及び4.4.3で完全に規定される。

ジョブが生成要求を介してPrinterオブジェクトに提出されるとき，クライアントは，一つだけのPrinterオブジェクトURIを供給する。PrinterオブジェクトURIを供給するクライアントは，"printer-uri-supported" Printer属性の値の一つでなければならない。

IPP/1.1は，どのようにしてクライアントがクライアント供給URIを得るかを規定しないが，Printerオブジェクトがディレクトリサービスにおけるエントリとして登録されることを推奨する。そこでエンドユーザ及びプログラムは，Printerを探すディレクトリに質問できる。附属書Eは，ディレクトリサービスにおけるPrinterオブジェクトエントリのための共通スキーマを規定し，エントリが実際のIPP Printerオブジェクトに対するブリッジとしてどのようにして動作するかを規定する。IPP Printerオブジェクトを表すディレクトリの中のエントリは，そのPrinterオブジェクトのための多くのURIをその属性の値として含む。

クライアントがPrinterオブジェクトに対して生成要求を提出するとき，Printerオブジェクトは，その要求の有効性を確認し，新しいJobオブジェクトを生成する。Printerオブジェクトは，"job-uri" Job属性の中に記録されるURIを新しいJobオブジェクトに割り当てる。Printerオブジェクトは，構成されたセキュリティ方式に基づくJob URIを生成し，生成要求の中でクライアントによって用いられるURIを生成する。

例えば，("https"スキームのURIをもつSSL3上のHTTPを用いて)SSL3の利用によってセキュリティ付きとされた通信チャネルと，(簡単な"http"スキームのURIを用いて)SSL3でのセキュリティを付与されていないもう一つの開放型通信チャネルとの両方をサポートするPrinterオブジェクトに着目する。クライアントがセキュリティ付きURIを用いてジョブを提出することがある場合には，Printerオブジェクトは，セキュリティ付きURIを新しいJobオブジェクトに割り当てる。クライアントが開放型チャネルURIを使ってジョブを提出することがある場合には，Printerは，開放型チャネルURIを新しいJobオブジェクトに割り当てる。

さらにPrinterオブジェクトは，Jobオブジェクトの"job-printer-uri"属性をも組み込む。これは，Jobオブジェクトを生成したPrinterオブジェクトに対する戻り参照とする。クライアントがJobオブジェクトの"job-uri"識別子へのアクセスだけをもつとき，クライアントは，どのPrinterオブジェクトがJobオブジェクトを生成したかを決定するために，Jobの"job-printer-uri"属性を照会できる。Printerオブジェクトが二つ以上のURIをサポートする場合，Printerオブジェクトは，値を構成し，Jobの"job-printer-uri"属性を組み込むためにジョブを生成するときに，クライアントによって供給される一つのURIを採用する。

JobオブジェクトにURIをもたせることは，柔軟性及びスケーラビリティを可能にする。例えば，実装によっては，Printerオブジェクトは，Printerオブジェクトそれ自体と同じ局所環境で処理されるJobを生成するかもしれない。この場合，Job URIは，PrinterのURIと，この段落中の後で示す一意の32ビット正整数などのJobオブジェクト用のある一意な構成要素との複合となるかもしれない。他の実装では，Printerオブジェクトは，すべてのJobオブジェクト生成要求を有効化するための中心的な情報集配センタ(clearing-house)となるかもしれないが，Jobオブジェクトそれ自体は，Printerオブジェクトから離れた環境で生成されるかもしれない。この場合，JobオブジェクトのURIは，PrinterオブジェクトのURIに対する物理位置関係を全くもたなくてもよい。JobオブジェクトがURIをもつことは，柔軟性及びスケーラビリティを可能にするが，多くの既存の印刷システムは，印刷ジョブを，独立のURIではなく32ビット正整数だけで識別するように強制する局所モデル又はインタフェース制約をもつ。この数値表現のJob IDは，生成要求がもともと提出されるPrinterオブジェクトの文脈の中だけで一意とする。したがって，(Job URIによるか又は数値表現のJob IDによるかのどちらかの)IPP Jobオブジェクトへのクライアントアクセスの型の両方を可能にするためには，Printerオブジェクトが生成要求の処理に成功し新しいJobオブジェクトを生成するとき，Printerオブジェクトは，Job URI及びJob IDの両方を生成しなければならない。("job-id"属性に記録された)Job IDは，生成要求がもともと提出されたPrinterオブジェクトの文脈中での意味だけをもつ。Job URI及びJob IDの両方をサポートするためのこの要件は，すべての型のクライアントが，クライアントの実装に課された局所的制約に拘わらず，Printerオブジェクト及びJobオブジェクトにアクセスすることを可能にする。

識別子に加えて，Printerオブジェクト及びJobオブジェクトは，名前("printer-name"及び"job-name")をもつ。オブジェクト名は，全オブジェクトのすべてのインスタンスにわたって一意である必要はない。Printerオブジェクトの名前は，このIPP/1.1規定の適用範囲外の機構を用いて管理者によって選ばれ設定される。Jobオブジェクトの名前は，そのジョブを提出するIPPクライアントによって，オプションとして選ばれ供給される。クライアントがJobオブジェクトの名前を供給しない場合は，Printerオブジェクトが，新しいJobオブジェクトの名前を生成する。いずれの場合も，名前は，局所的な意味をもつだけとする。

これらをまとめて次に示す。

• 各Printerオブジェクトは，一つ以上のURIで識別される。Printerの"printer-uri-supported"属性は，そのURIを含む。
• Printerオブジェクトの"uri-security-supported"属性は，通信チャネルのセキュリティプロトコルを識別する。そのプロトコルは，さまざまなPrinterオブジェクトURI(例えば，'tls'又は'none')について構築されたものであってもそうでなくてもよい。
• Printerオブジェクトの"uri-authentication-supported"属性は，認証機構を識別する。その機構は，さまざまなPrinterオブジェクトURI(例えば，'digest'又は'none')について構築されたもであってもそうでなくてもよい。
• 各Jobオブジェクトは，Job URIで識別される。Jobの"job-uri"属性が，そのURIを含む。
• 各Jobオブジェクトは，32ビットの正整数であるJob IDでも識別される。Jobの"job-id"属性は，Job IDを含む。そのJob IDは，そのJobオブジェクトを生成したPrinterオブジェクトの文脈の中でだけ一意とする。
• 各Jobオブジェクトは，"job-printer-uri"属性をもつ。その属性は，そのJobオブジェクトを生成するのに用いたPrinterオブジェクトのURIを含む。この属性は，そのJobオブジェクトに対してURIだけが与えられる場合に，Jobオブジェクトを生成したPrinterオブジェクトを決定するのに用いる。このリンク付けは，そのJobについてサポートされる言語，charset及び操作を決定するのに必要となる。これらサポートの基本は，生成側のPrinterオブジェクトに基づく。
• 各Printerオブジェクトは，(必ずしも一意である必要はない)名前をもつ。管理者は，このIPP/1.1規定の適用範囲外の機構を用いて，この名前を選び設定する。Printerオブジェクトの"printer-name"属性は，名前を含む。
• 各Jobオブジェクトは，(必ずしも一意である必要はない)名前をもつ。クライアントは，生成要求においてこの名前をオプションとして供給する。クライアントがこの名前を供給しないとき，Printerオブジェクトが，Jobオブジェクトのために名前を生成する。Jobオブジェクトの"job-name"属性は，名前を含む。

IPPオブジェクトは，操作をサポートする。操作は，要求及び応答から成る。クライアントがIPPオブジェクトと通信するとき，クライアントは，そのオブジェクトに対するURIに操作要求を発行する。操作要求及び操作応答は，操作を認識するパラメタをもつ。操作も，その操作の(意図する対象，現地化情報などの)実行時特徴に影響する属性をもつ。これらの操作特有の属性は，(Printerオブジェクト属性，Jobオブジェクト属性などのオブジェクト属性との比較で，)操作属性と呼ぶ。各要求は，それと共に，あらゆる操作属性，オブジェクト属性，及び/又は操作の実行に要求される文書データを運ぶ。各要求は，オブジェクトからの応答を要求する。各応答は，応答パラメタとしての状態コードで操作の成功又は失敗を表示する。応答は，あらゆる操作属性，オブジェクト属性，及び/又は操作要求の実行中に生成された状態メッセージを含む。

3.は，要求及び応答について，各操作と関連する，パラメタ，属性及びその他のデータに関してIPP操作のセマンティクスを記述する。

IPP/1.1 Printer操作を表1に示す。

Job操作を表2に示す。

Send-Document Job操作及びSend-URI Job操作は，Create-Job操作を用いて生成された既存の複数文書Jobオブジェクトを新規文書に加えるときに使われる。

すべてのIPP操作は，幾つかの共通パラメタ及び操作属性を要求する。これらの共通要素及びセマンティクスの特徴について，更に詳細な定義及び記述を次に示す。

あらゆる操作要求は，次の必す(須)パラメタを含む。

• "version-number"
• "operation-id"
• "request-id"
• 要求の型に必す(須)な属性

あらゆる操作応答は，次の必す(須)パラメタを含む。

• "version-number"
• "status-code"
• 対応する要求の中で供給された"request-id"
• 応答の型に必す(須)な属性

"符号化及びトランスポート"[RFC2910]は，これらのパラメタの符号化のための特別な規則を定義する。すべての他の操作要素は，属性及び属性のグループのための，より一般的な符号化規則を用いることを意味する。

各IPP操作要求は，識別する"operation-id"値を含む。有効な値は，"operations-supported" Printer属性(4.4.13参照)で定義する。クライアントは，正しい"operation-id"値を供給することで，どの操作が要求されるのかを指定する。

さらに，操作の起動は，すべて，"request-id"値で識別される。クライアントは，各要求ごとに，1から2**31-1まで(ただし両端を含む。)の範囲の(クライアントの要件に依存する恐らく一意な)整数でなければならない"request-id"を選択する。この"要求ID"によって，クライアントは，複数の処理中の要求を管理することができる。受信側のIPPオブジェクトは，クライアントが供給した"request-id"属性の32ビットすべてを応答へコピーする。そうすることで，たとえ"request-id"が範囲外であろうとも，クライアントは応答を正しい処理中の要求に対応させることができる。完全な"request-id"を受信する前に要求が終了する場合は，IPPオブジェクトは，要求を拒否し，"request-id"を0として応答を返す。

備考　 IPPの下のトランスポートプロトコルが，コネクション指向プロトコルの場合もあるかもしれない。このプロトコルは，対応する要求が送られた順序とは別の順序での応答を，クライアントが受信できないようにする。この場合，"request-id"属性は正しいプロトコル操作には，重要でないかもしれない。しかし，他の下位プロトコルへの対応付けでは，操作応答は，任意の順序で戻ることができる。この場合には，"request-id"は重要となる。

操作要求及び応答は，共に，属性及び/又は文書データのグループから成る。属性グループを次に示す。

操作属性(Operation Attributes)

この属性は，操作を使って渡され，操作要求を処理する間のIPPオブジェクトの動作に影響を与え，他の属性又は属性グループに影響を与えることもある。操作属性には，印刷ジョブに関連する文書データを示し，新規Jobオブジェクトと関連してもよいものもある。しかし，大部分の操作属性は，操作の存続時間を超えて永続的ではない。各操作属性の記述は，IPPオブジェクトのサポートに関して，どの操作属性が必す(須)であって，どれがオプションか，どの属性をクライアントが要求で供給し，どの属性をIPPオブジェクトが応答で供給しなければならないか，を示す適合性記述を含む。

ジョブテンプレート属性(Job Template Attributes)

この属性は，ジョブの処理に作用する。クライアントは生成要求でJob Template属性をオプションとして供給し，受信側オブジェクトはサポート済み属性すべてを受信する用意をしなければならない。Jobオブジェクトに対して，どのJob Template属性が生成要求で最初に要求されたかを後で問合せ可能であって，これらの属性は，Job Object属性として応答で返される。Printerオブジェクトに対しては，どの型のジョブ処理能力がサポートされるか，及び/又はデフォルトのジョブ処理動作は何か，を知るために，Job Template属性について問合せ可能とする。これらの属性はPrinter Object属性として応答で返される。"ipp-attribute-fidelity"操作属性は，すべてのクライアントが供給するJob Template属性("ipp-attribute-fidelity"の詳細な記述及び他の属性との関係については，3.2.1.2及び附属書Eを参照)の処理に影響を与える。

ジョブオブジェクト属性(Job Object Attributes)

この属性は，Jobオブジェクトに向けられた問合せ操作の応答で返される。

プリンタオブジェクト属性(Printer Object Attributes)

この属性は，Printerオブジェクトに向けられた問合せ操作の応答で返される。

未サポート属性(Unsupported Attributes)

生成要求で，クライアントは，Operation属性及びJob Template属性の集合を提供する。この属性又はその値がPrinterオブジェクトでサポートされていない場合，Printerオブジェクトは，応答で未サポート属性の集合を返す。3.1.7，3.2.1.2及び附属書Dで，生成要求でクライアントの提供したJob Template属性が，Printerオブジェクトでどのように処理されるか，及び未サポート属性がどのようにクライアントに返されるか，を詳細に示す。拡張可能性のために，あらゆるIPPオブジェクトは，サポートしていない新規又は未知の属性又は値を含む要求を受け付けるかもしれない。その場合，IPPオブジェクトは，できることを処理し，応答で未サポート属性を返す。Unsupported Attributeグループは，クライアントが要求で提供した未サポート属性を返すためにすべての操作応答に対して定義されている。

3.1の後半では，各操作を，各々の要求及び応答に対して許可され予期される属性のグループを識別することで形式的に定義する。モデルは，各要求又は各応答における各グループに対して特定の順序を指定するが，各グループ内の属性は，特に指定しない場合は，いかなる順序でもよい。

グループ内の属性は一意でなければならない。同じ名前をもつ属性が複数回出現する場合，そのグループは，異常とする。クライアントは，このような異常な要求を送ってはならないし，プリンタは，このような異常な応答を返してはならない。このような異常な要求がプリンタに提出された場合，プリンタは，実装に依存して，次のいずれかをしなければならない。

a)	'client-error-bad-request'の状態コード(B.1.4.1参照)で，要求を拒否する。
b)	属性インスタンスの一つだけを選択した後で，通常どおりに要求を処理する。

属性が重複して存在する場合，どちらの属性を選択するかは，実装に依存する。IPPプリンタは，複数のこれら重複した属性インスタンスからの値を使ってはならない。

各属性規定は，属性名に続けて，括弧内にその属性の構文の名前を入れたものを含む。さらに，各'integer'属性は，その属性の値に対して，括弧内に許される範囲を(m:n)として続ける。'text'属性又は'name'属性には，各々，その属性の値に対して，括弧内にオクテット単位での最大サイズを続ける。属性構文記法の詳細については，4.1の属性構文を参照のこと。

備考1 操作に含まれる文書データは，厳密には属性ではないが，順序付けの目的で特別の属性グループとして扱う。操作要求内での文書データ供給をサポートする操作は，Print-Job及びSend-Documentだけとする。文書データを含む操作応答は存在しない。

操作には，IPPオブジェクトのサポートを必す(須)とするものがあり，それ以外はオプションとする(5.2.2参照)。そこで，オプションの操作を使用する前に，クライアントは，最初に必す(須)のGet-Printer-Attributes操作を用いて，オプションのどのPrinter操作及びJob操作が実際にサポートされているかを決定するために，Printerの"operations-supported"属性を問い合わせることが望ましい。クライアントは，サポートされていないオプションの操作を使用しないほうがよい。IPPオブジェクトがサポートされていない操作を実行するための要求を受信した場合，'server-error-operation-not-supported'状態コードを返す(附属書B.1.5.2参照)。IPPオブジェクトが必す(須)操作をサポートしない場合は，不適合とする。

Job属性及びPrinter属性の中には，機械理解よりむしろ人間理解のために意図されたテキスト列及び名前の値をもつものがある('text'及び'name'の属性構文は4.1を参照)。"attributes-charset"及び"attributes-natural-language"という二つの特別なOperation Attributesについて，次に記述する。これらの属性は，常に，Operation Attributesグループの一部とする。たいていの属性グループでは，グループ内の属性の順序は，重要ではない。しかし，Operation Attributesグループ内のこれら二つの属性に対しては，順序は極めて重要となる。"attributes-charset"属性は，グループの最初の属性でなければならず，"attributes-natural-language"属性は，グループの2番目の属性でなければならない。言い換えると，これらの属性は，すべてのIPP要求及びIPP応答で供給され，グループの先頭に来なければならず，特定の順序で来なければならない。ジョブ生成操作に対して，IPP Printer実装は，新Jobオブジェクトと共にこれら二つの属性をJob Description属性として記憶する。この規定では簡潔さのために，すべての操作の要求及び応答がもつこれら操作属性の記述は繰り返さず，代わりに3.1を参照することにする。

すべてのIPP/1.1操作要求で，次の必す(須)操作属性を，クライアントは供給し，Printerオブジェクトはサポートしなければならない。

"attributes-charset" (charset)

この操作属性は，クライアントがこの要求で供給するあらゆる'text'属性及び'name'属性で用いるcharset(符号化文字集合及び符号化方式)を特定する。この属性は，Printerオブジェクトがすべての'text'属性及び'name'属性で(サポートされていれば)使わなければならないcharset，及びPrinterオブジェクトがこの要求の応答として返す状態メッセージを特定する。'text'属性構文及び'name'属性構文の規定については，4.1.1及び4.1.2を参照すること。

すべてのクライアント及びIPPオブジェクトは，'utf-8' charset [RFC2279]をサポートしなければならず，IANA[IANA-CS]で登録されている付加的なcharsetをサポートしてもよい。Printerオブジェクトがクライアントの提供するcharset値をサポートしていない場合，Printerオブジェクトは，要求を拒否し，応答として"attributes-charset"を'utf-8'に設定し，'client-error-charset-not-supported'状態コード及び'utf-8' charsetを用いた'text'属性又は'name'属性を返さなければならない。Printerは，Unsupported Attributes Groupの属性を返さなくてもよい(3.1.7及び3.2.1.2参照)。Printerオブジェクトは，サポート済みcharsetを"charset-supported" Printer属性の値(4.4.18参照)として示さなければならない。そうすることで，クライアントは，どのcharsetがサポートされているか決定するために問い合わせることができる。

備考　クライアントの実装は，次のことに注意するほうがよい。IPPオブジェクトは，'utf-8' charsetのサポートだけを要求されているので，可能な限り複数のIPPオブジェクト実装との相互接続を可能とするために，クライアントは，US-ASCII，ISO-8859-1などのより単純なcharsetだけを通したり表現できるにもかかわらず，"attributes-charset"操作属性に'utf-8'を供給することを望むかもしれない。この場合，クライアントは，応答で返される，ユーザに表示できない文字を除去(又はcharset変換)しなければならなくなる。一方で，クライアント及びIPPオブジェクトの両方がutf-8以外のcharsetも共通にサポートしている場合，クライアントは，charset変換又はデータ損失を避けるために，そのcharsetを使いたいと思うかもしれない。

この属性の値の構文及びセマンティクス解釈，並びに例示値に関しては，4.1.7の'charset'属性構文の記述を参照すること。

"attributes-natural-language" (naturalLanguage)

この操作属性は，クライアントが要求で供給している'text'属性及び'name'属性で用いられる自然言語を特定する。この属性は，Printerオブジェクトが，この要求の応答で返す，すべての'text'属性及び'name'属性並びに状態メッセージのために使用することが望ましい自然言語も特定する。なお，構文及びこの属性値のセマンティクスの解釈及び例に関しては，4.1.8の'naturalLanguage'属性構文表現を参照のこと。

Printerオブジェクトがサポートすることを要求される必す(須)自然言語はない。しかし，Printerオブジェクトの"generated-natural-language-supported"属性は，Printerオブジェクトと，IPPオブジェクトが生成するすべてのテキスト列のための包含されたJobオブジェクとによってサポートされる自然言語を特定する。クライアントは，生成されたメッセージに対してサポートされた自然言語を決定するために，この属性を問い合わせてもよい。

Printerオブジェクトがテキストを生成する属性，すなわち，"job-state-message"，"printer-state-message"など，及び状態メッセージ(3.1.6参照)に対して，Printerオブジェクトは，サポート済みの自然言語のいずれかで，テキスト列を生成可能でなければならない。クライアントがサポートしていない自然言語を要求をした場合，Printerオブジェクトは，Printerの"natural-language-configured"属性(4.4.19参照)で指定されたとおりに，Printerが設定する自然言語で，これらの生成されたメッセージを返さなければならない。

クライアント，認証システム，操作者，システム管理者又は製造者が提供するこの他の'text'属性及び'name'属性(すなわち，"job-originating-user-name"，"printer-name" (name)，"printer-location" (text)，"printer-info" (text)及び"printer-make-and-model" (text))に対しては，Printerオブジェクトの"natural-language-configured"属性によって特定されたPrinterの設定済み自然言語のサポートだけがPrinterオブジェクトに要求される。ただし，これらの属性には付加的な自然言語のサポートが許されている。

"attributes-natural-language"操作属性で供給された値とは異なる自然言語を用いた要求のいかなる'text'属性又は'name'属性に対しても，クライアントは，自然言語上書き(Natural Language Override)機構(4.1.1.2及び4.1.2.1)をこの供給された属性値に対して使用しなければならない。クライアントは，Natural Language Override機構を冗長に用いてもよい。すなわち，たとえ値が要求の"attributes-natural-language"操作属性で供給された値と同じ自然言語を用いた値であったとしても，この上書き機構を使用してもよい。

IPPオブジェクトは，IPPオブジェクトがその自然言語をサポートするしないに拘わらず(又は"ipp-attribute-fidelity"操作属性の値に依存せず)，任意の自然言語及び任意のNatural Language Overrideを受諾しなければならない。これは，IPPオブジェクトが，Printerオブジェクトの"generated-natural-language-supported"属性でどのような値をとろうと，すべてのクライアントが供給する値を受諾するということになる。この属性"generated-natural-language-supported"は，クライアントが供給したメッセージではなく生成されたメッセージだけに適用する。IPPオブジェクトは，すべてのクライアントが供給する属性を覚えていなくてはならない。それらの属性を問合せの応答で返した場合，IPPオブジェクトは，その自然言語を示さなければならない。

属性構文型が'text'又は 'name'(4.1.1及び4.1.2参照)である各値は，関連するNatural-Languageをもつ。この規定は，この関連がPrinterオブジェクト又はJobオブジェクトにどのように記憶されるかは規定しない。要求又は応答でこの値が符号化される場合，その自然言語は暗黙的又は明示的のいずれかとなる。

• 暗黙的な場合，値は，text/name値だけをもち，言語は，要求又は応答で"attributes-natural-language"操作属性によって指定される(4.1.1.1 textWithoutLanguage及び4.1.2.1 nameWithoutLanguage参照)。
• 明示的な場合(これは，Natural-Language Override事例としても知られるのだが)，値は言語及びtext/name値の両方を含む(4.1.1.2 textWithLanguage及び4.1.2.2 nameWithLanguage参照)。

例えば,"job-name"属性は，生成要求でクライアントが供給してもよい。この属性のtext値は，"attribute-natural-language"属性で識別される自然言語であるか，又はそれと異なる場合は，Natural Language Override機構で識別される。供給される場合，IPPオブジェクトは，"job-name"属性の値を，Jobオブジェクトの"job-name"属性に満たすために使う。クライアントがJobオブジェクトの"job-name"属性を問い合わせる場合は，IPPオブジェクトは記憶された属性を返し，それが応答の"attributes-natural-language"操作属性の報告と異なる場合は，自然言語を指定するためにNatural Language Override機構を用いる。IPPオブジェクトは，Natural Language Override機構を冗長に用いてもよい。すなわち，自然言語が，応答の"attributes-natural-language"操作属性で供給された値と同じ場合でも，その機構を使用してもよい。

IPPオブジェクトは，"attributes-natural-language"操作属性又はNatural Language Overrideを用いるあらゆる属性で供給された自然言語に基づく要求を拒絶してはならない。

クライアントは，自然言語とcharsetとの不正な組合せを用いた'text'属性又は'name'属性を供給しないことが望ましい。例えば，Printerオブジェクトが，charsetの'utf-8'，'iso-8859-1'及び'iso-8859-7'をサポートしているとする。さらに，このPrinterオブジェクトは，自然言語の'en'(英語)，'fr'(フランス語)及び'el'(ギリシャ語)もサポートしていたとする。Printerオブジェクトは，charset 'iso-8859-1'及び自然言語'el'をサポートしているが，恐らく，'iso-8859-1' charsetを用いたギリシャ語のテキスト列の組合せはサポートしていない。Printerオブジェクトは，この見かけ上の矛盾を，発生する文脈に依存して次の異なる方法で処理する。

• 生成要求の場合: クライアントが，見かけ上の矛盾した組合せを用いたtext属性又はname属性(例えば，"job-name"操作属性)を供給する場合，これは，Printerオブジェクト又はその正しい操作に影響しないクライアントの選択である。それゆえ，Printerオブジェクトは単にクライアントが供給する値を受諾し，Jobオブジェクトと共に記憶し，そのクライアント(又は任意のクライアント)がその属性を問い合わせる場合でも，同じ組合せを返す。
• Get-Printer-Attributesと類似の問合せ型の操作の場合: クライアントが見かけ上の矛盾した組合せを要求する場合，Printerオブジェクトは，クライアントが要求する自然言語以外のPrinterの設定による自然言語を使用して，(3.1.4.2で示すとおりに，)応答する。

どちらの場合も，Printerオブジェクトは，見かけ上の矛盾を理由に要求を拒否はしない。charset及び自然言語の可能性のある矛盾した組合せは，大域的な操作レベルで，又はNatural Language Overrideの属性ごとのレベルで，発生する。さらに，応答は常に明示的なcharset及び自然言語の情報を含むので，クライアントが応答を解釈する方法に関しての課題又はあいまい性は存在しない。

あらゆるIPP/1.1操作応答における次の必す(須)操作属性を，Printerオブジェクトは供給し，クライアントはサポートしなければならない。

"attributes-charset" (charset)

この操作属性は，Printerオブジェクトがこの応答で返す'text'属性及び'name'属性によって使用されるcharsetを識別する。この応答における値は，クライアントが要求で供給した"attributes-charset"操作属性と同じ値でなければならない。これが不可能な場合(すなわち，要求されたcharsetがサポートされていない場合)には，要求は拒否される。3.1.4.1で示す"attributes-charset"を参照すること。

Printerオブジェクトが'utf-8' charsetだけ以外のものもサポートする場合，Printerオブジェクトは，クライアントが要求するcharsetを用いて'text'属性及び'name'属性を返すために，可能な最高の忠実度に基づいてサポートされるcharsetの各々の間でコード変換できなければならない。しかし，関与するcharsetに依存して，charset変換の間に情報欠落が発生してもよい。例えば，Printerオブジェクトが，UTF-8の'a'からUS-ASCIIの'a'への(情報欠落のない)変換，ISO Latin 1 CAPITAL LETTER A WITH ACUTE ACCENTからUS-ASCIIの'A'への(アクセント欠落のある)変換，UTF-8 Japanese Kanji characterから，実装に依存して，'?' のようなISO Latin 1でのエラー文字指示，等価な10進コード又は文字の欠落などへの変換を行ってもよい。

二つ以上のcharsetをサポートする実装が，クライアントが供給するcharsetでデータを記憶するか，他のサポート済みcharsetの一つにコード変換してデータを記憶するかは，実装依存とする。コード変換中の情報欠落が最小となる戦略を試すのがよい。各応答に関しては，実装は，内部charsetから要求されたcharsetへと変換を行う。

"attributes-natural-language" (naturalLanguage)

この操作属性は，IPPオブジェクトが応答で返している任意の'text'属性及び'name'属性が使用する自然言語を識別する。"attributes-charset"操作属性とは異なり，IPPオブジェクトは，要求でクライアントが供給するものと同じ値を返す必要はない。IPPオブジェクトは，Jobオブジェクトの自然言語，又はクライアントが供給する自然言語以外のPrinterオブジェクトの"natural-language-configured"属性によって識別されるPrinterが設定する自然言語を返してもよい。"attributes-natural-language"操作属性で返される値とは異なる自然言語を使用した応答の'text'属性若しくは'name'属性又は状態メッセージに対して，IPPオブジェクトは，Natural Language Override機構(4.1.1.2及び4.1.2.2参照)を，返される各属性値に関して使用しなければならない。IPPオブジェクトは，Natural Language Override機構を冗長に使ってもよい。すなわち，値が，応答の"attributes-natural-language"操作属性で供給された値と同じ自然言語で記述されていても，Natural Language Override機構を使用してもよい。

すべてのIPP操作は，IPPオブジェクトに向けて行われる。Printer操作では，その操作は，URIの一つ(すなわち，Printerオブジェクトの"printer-uri-supported"属性における値の一つ)を使用して，Printerオブジェクトに向けて行われる。Printerオブジェクトが複数のURIをサポートする場合であっても，クライアントは，操作の対象としてただ一つのURIを供給する。クライアントは，"printer-uri (uri)"操作属性において正しいURIを供給することで，対象オブジェクトを特定する。

Job操作では，操作は次のいずれかに向けて行われる。

• Jobオブジェクトそれ自体。JobオブジェクトのURIを使用する。この場合，クライアントは，"job-uri (uri)"操作属性で供給される正しいURIで対象オブジェクトを識別する。
• Jobオブジェクトを生成したPrinterオブジェクト。PrinterオブジェクトURI及びJobオブジェクトのJob IDの両方を使用する。Jobオブジェクトを生成したPrinterオブジェクトがJob IDを生成したのだから，Printerオブジェクトは，クライアントが供給したJob IDを正しいJobオブジェクトと正しく関連付けられなければならない。クライアントは，"printer-uri (uri)"操作属性でPrinterオブジェクトのURIを，"job-id (integer(1:MAX))"操作属性でJobオブジェクトのJob IDを，それぞれ供給する。

操作が，JobオブジェクトのURIを使用して直接にJobオブジェクトに向けて行われる場合，クライアントは，余分な"job-id"操作属性を含んではならない。

操作対象属性は，あらゆる操作要求に含まれなければならない必す(須)操作属性とする。charset属性及び自然言語属性(3.1.4参照)と同様に，操作対象属性は，特別仕立ての操作属性とする。すべての場合で，操作対象属性のすぐ後には，操作属性グループ内の"attributes-charset"属性及び"attributes-natural-language"属性が続くが，特に次の順序規則が存在する。

• 操作対象属性が一つだけ(すなわち，"printer-uri"属性又は"job-uri"属性だけ)が存在する場合，その属性は，操作属性グループの3番目の属性でなければならない。
• Job操作が二つの操作対象属性(すなわち，"printer-uri"属性及び"job-id"属性)を使用する場合，"printer-uri"属性が3番目の属性であって，"job-id"属性が4番目の属性でなければならない。

すべての場合で，IPP操作の要求及び応答の本体内に含まれる対象URIは，相対フォーマットでなく，絶対フォーマットでなければならない。(相対URIは，HTTPサーバの有効範囲内の資源を識別するが，方式，ホスト又はポートを含まない。)

次の規則は，IPPオブジェクトを識別するURIのポート番号の使用に対して適用される。

備考　 IPPの"符号化及びトランスポート"の文書[RFC2910]は，IPPのHTTP/1.1への対応付けを示し，HTTP/1.1上のIPP使用のための新しいデフォルトポート番号を定義する。

すべての操作応答は，必す(須)の"status-code"パラメタ，並びにオプションの"status-message"操作属性及び"detailed-status-message"操作属性を含む。Print-URI及びSend-URIの応答は，オプションの"document-access-error"操作属性を含んでもよい。

必す(須)の"status-code"パラメタは要求の処理に関する情報を提供する。この状態コードは，自動的処理で使用することを意図している。IPPのクライアント実装は，状態コード値を，エンドユーザに対して意味をもつ現地化されたメッセージに変換することが望ましい。

"status-code"値は，意味をもつ数値とする。"status-code"構文は，値が0x0000〜0x7FFFの範囲だけ可能ということを除き，"type2 enum"(4.1又は"属性構文"を参照)と類似している。附属書Bは，状態コードを示し，数値を割り当て，ユーザの自然言語が英語である場合，クライアント利用のための各状態コードに対応する状態メッセージを与えている。

Printerがエラーなしで操作を実行し問題に出会わない場合は，応答において'successful-ok'の状態コードを返さなければならない。附属書Bを参照すること。

クライアントが表3に示すパラメタ又はOperation属性に対する未サポート値を供給する場合，Printerオブジェクトは，操作を拒否しなければならないが，Unsupported Attributesグループにおける未サポート属性値を返す必要はなく，示された状態コードを返さなければならない。

クライアントが他の属性に対して未サポート値を供給するか，未サポート属性を供給する場合， Printerは，Unsupported Attributesについて示す3.1.7で定義する状態コードを返す。

オプションの"status-message"操作属性は，操作状況の短いテキスト表現を提供する。"status-message"属性の構文は，"text(255)"であって，最大長は255オクタットとする(4.1.1参照)。状態メッセージは，人間のエンドユーザが使うことを意図している。応答が，"status-message"属性を含む場合，IPPクライアントは，メッセージを調べたり表示したりする必要はないが，実装固有の方法でそれを行うことが望ましい。"status-message"は，Printerオブジェクトの後の版が，クライアントの初期の版が理解できないかもしれない状態コードに添付し人間のユーザのための付加情報として返す場合に特に有用となる。

Printerオブジェクトが"status-message"操作属性をサポートする場合，Printerオブジェクトは，Printerオブジェクトの"generated-natural-language-supported"属性(3.1.4.1で規定する"attributes-natural-language"操作属性を参照)によって識別される自然言語のいずれかを用いてこのメッセージを生成できなければならない。附属書Bに，英語を使った場合のPrinterが返却する状態メッセージのためのテキストを示す。

返却された'text'属性に対して3.1.4.1で示すとおり，このメッセージを生成する選択がある場合は，Printerオブジェクトは，クライアント要求における"attributes-natural-language"の値によって示される自然言語を，サポートされていれば使用し，そうでない場合には，Printerオブジェクトは，Printerオブジェクト自体の"natural-language-configured"属性における値を使用する。

Printerオブジェクトが"status-message"操作属性をサポートしている場合，次のエラー状態コード，'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server-error-operation-not-supported'及び'server-error-version-not-supported'に対する状態メッセージ(附属書B参照)を返すために，必す(須)の'utf-8' charsetを用いるほうがよい。この場合，エラー応答では，"attributes-charset"操作属性の値を'utf-8'に設定しなければならない。

オプションの"detailed-status-message"操作属性は，操作に関する付加的なより詳細の技術的及び実装特有の情報を提供する。"detailed-status-message"属性の構文は"text(MAX)"であって，最大長は1023オクタットとする(4.1.1参照)。Printerオブジェクトが"detailed-status-message"操作属性をサポートする場合，Printerは，システム管理者又は他の経験ある技術者による使用を意図しているので，メッセージを現地化する必要はない。現地化は，これらメッセージの技術的な意味を不明瞭にするかもしれない。クライアントは，この属性の値の構文解析を試みてはいけない。プログラムが処理できる付加的なエラーに関しては，"document-access-error"操作属性(3.1.6.4)を参照のこと。

このオプションの操作属性は，Print-URI(3.2.2)操作又はSend-URI(3.3.1)操作に応答を返却する前に，Printerが出会うあらゆる文書アクセスエラーに関する追加情報を提供する。'http:'又は'ftp:'といった"document-uri"操作属性のURIスキーマが識別するプロトコルのエラーに対して，エラーコードは，URIの前に括弧に入れて返却される。例えば次のとおり。

   (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf

Unsupported Attributesグループは，操作でサポートされない属性を含む。このグループは，第一にジョブ生成操作のためのものだが，すべての操作は，このグループを返すことができる。

Printerオブジェクトは，状態コードが，'successful-ok-ignored-or-substituted-attributes'，'successful-ok-conflicting-attributes'，'client-error-attributes-or-values-not-supported'又は'client-error-conflicting-attributes'のうちの一つの場合，応答にUnsupported Attributesグループを含めなければならない。

状態コードがこれら四つのうちの一つの場合，Unsupported Attributesグループは，次の属性のすべて及びそれだけを含まなければならない。

詳細は，次の未サポート属性の3分類を参照すること。

状態コードが，3.1.6.1の表に中の一つとなる場合，Unsupported Attributesグループは，その表の中で示される未サポートのパラメタ又は属性を含む必要はない。

Printerオブジェクトが応答でUnsupported Attributesを全く返さない場合，Printerオブジェクトは，空のグループを送るのでなく，Group 2を省略するほうがよい。しかし，クライアントは，空のグループを受諾できなければならない。

未サポート属性は，次の三つに分類される。

未サポート属性名の場合，Printerオブジェクトは，クライアントが供給する属性に'unsupported'の値を代入して返す。この値の構文型は，"範囲外"("out-of-band")であって，その符号化は，"符号化及びトランスポート"規定[RFC2910]で示す"範囲外"("out-of-band")の値のための特別規則によって定義される。その値は，属性それ自体に対してはサポートしないことを示す(4.1の始めの部分を参照)。

一つ以上の未サポートな属性構文又は値をともなった属性をサポートする場合，Printerオブジェクトは，クライアントが供給した属性を，クライアントが供給したとおりに，未サポートな属性構文又は値と共に返す。これは，その属性のサポートは示すのだが，その特別な属性構文又は値はサポートしないことを示す。クライアントが複数の値をもつ多重値属性を供給し，Printerオブジェクトがその属性をサポートしているのだが，クライアント供給の属性構文又は値の部分集合だけをサポートする場合，Printerオブジェクトは，未サポートのこれらの属性構文又は値だけを返さなければならない。

(それぞれは独立にサポートされているが，同じジョブ内で一緒に要求する場合に相反する値をもつ)互いに相反する二つ(以上)のサポートされた属性値の場合，Printerオブジェクトは，この相反を解決するために，無視する値又は置き換える値すべてを返却しなければならないが，使用する値は返却してはならない。相反を解決する方法それ自体の選択は，実装依存とする。3.2.1.2及び附属書D参照すること。例としては，実装者ガイド[IPP-IIG]を参照すること。

各操作の要求及び応答は，"version-number"パラメタを伴う。"version-number"のそれぞれの値は，"X.Y"の形式とし，Xを主版数，Yを副版数とする。クライアント要求に版数を含めることで，クライアントは，どのIPPの版を使用することに関心があるかを識別できる。この版とは，Printerに依存して，クライアントが満足するほうがよいかもしれない適合性要件の版のことである。

IPPオブジェクトがクライアントによって供給される主版数をサポートしない場合，すなわち，"version-number"パラメタの主版数がPrinterの"ipp-versions-supported"(4.4.14参照)の値のいずれとも一致しない場合，IPPオブジェクトは，サポートされる最も近い版数とともに'server-error-version-not-supported'の状態コードで応答しなければならない(13.1.5.4参照)。主版数はサポートされているが副版数がサポートされていない場合は，IPPオブジェクトは，要求を受諾し実行すること試みることが望ましいが，操作がサポートされていない場合には，拒否するほうがよい。そうでない場合には，要求を拒否し，'server-error-version-not-supported'状態コードを返す。すべての場合で，IPPオブジェクトは，要求においてクライアントが供給する版数に最も近くてサポートする"version-number"を返さなければならない。

版の折衝それ自体は存在しない。しかし，IPPオブジェクトから'server-error-version-not-supported'状態コードを受け取った後は，クライアントは異なる版数で再び試みることが望ましい。クライアントは，附属書Eに適合するディレクトリからか，又はどの版がサポートされているかを決定するためにPrinterオブジェクトの"ipp-versions-supported"属性(4.4.14参照)を問い合わせることによってか，のいずれかで，サポートされている版を決定してもよい。

IPPオブジェクトの実装は，版1.1をサポートしなければならない。すなわち，この規定及びRFC2910で規定されるとおりのIPP/1.1のための適合性要件を満たさなければならない。IPPオブジェクトの実装は，主版数が'1'のあらゆる要求を受諾する。ただし，操作がサポートされていない場合は，その要求を拒否する。

"version number"の概念は唯一つとし，これだけで，IPPモデル及びIPPプロトコルの両方の変更を示す。そこで版数は，モデル及び機能定義(この規定)の新版，又は"符号化及びトランスポート"[RFC2910]の新版が出版されるときに，変更されなければならない。

主版数の変更は，構造又は構文上の変更を示し，IPPクライアント及びPrinterオブジェクトの古い版が，新しい又は変更された属性，操作及び応答を，正しく構文解析し正しく処理することが不可能な変更とする。主版数が変更された場合，副版数は，ゼロに設定される。例えば，必す(須)の"ipp-attribute-fidelity"属性を(これが'1.1'版にないとして)'1.1'版に追加した場合，主版数の変更が要求されることになる。これは，IPP/1.0のPrinterは，未知の"ipp-attribute-fidelity"属性を含む正しいセマンティクスをもつ要求を処理しないことによる。主版数の変更に影響を与えるかもしれない項目は，モデル及び機能定義(この規定)又は"符号化及びトランスポート"[RFC2910]のそれ自体の変更を含む。この変更項目は，次による。

• 順序付き属性及び属性集合の再順序付け。
• 既存の属性の構文の変更。
• (IPPオブジェクトがサポートする)必す(須)操作属性グループの追加。
• 既存の必す(須)操作属性への値の追加。
• 必す(須)操作の追加。

副版数の変更は，すべてのIPPオブジェクトは理解しないかもしれないが，理解しない場合は無視可能な新しい機能，属性及び属性値の追加を示す。副版数の変更に影響を及ぼすかもしれない項目は，符号化及びトランスポートの規則[RFC2910]ではなく，モデルオブジェクト及び属性への変更(ただし，属性構文の追加は除く。)を含む。変更項目の例は，次による。

• 旧版に含まれないすべての拡張を新版でグループ化。
• 新しい属性値の追加。
• 新しいオブジェクト属性の追加。
• (IPPオブジェクトがサポートする)オプションの操作属性(すなわち，クライアントの混乱なしにIPPオブジェクトが無視できる属性)の追加。
• (IPPオブジェクトがサポートする)オプションの操作属性グループ(すなわち，クライアントの混乱なしにIPPオブジェクトが無視できる属性)の追加。
• 新しい属性構文の追加。
• オプションの操作の追加。
• Job Description属性又はPrinter Description属性のオプションから必す(須)への，又はその逆への変更。
• オプションの属性構文の既存の属性への追加。

"version-number"の符号化は，(主又は副のいずれの)いかなる版数でも変更してはならない。この規則によって，すべての将来の版が，(少なくとも"version-number"を検査する)すべての旧版の後方互換になることを保証する。さらに，ある版から次の版に引き継がれないあらゆるプロトコル要素(属性，エラーコード，タグなど)は，新しいセマンティクスで再利用されないために，非推奨とする。

ある版をサポートする実装は，すべての旧版をサポートする必要はない。(新しい規定の公表を通して)新版がそれぞれ定義されるごとに，主版数が，規定に準拠した実装では，どの旧版をサポートしなければならないか，及びどの版をサポートするのが望ましいか，を指定する。

"印刷ジョブを提出する"，及び新規Jobオブジェクトを生成するために，クライアントは，生成要求を発行する。生成要求は，次の三つの操作要求のいずれか一つとする。

Print-Job Request

一つの文書だけを伴う印刷ジョブを提出しようとするクライアントは，Print-Job操作を使用する。この操作は，クライアントが要求それ自体の中に文書データを含めることによって，Printerオブジェクトにその文書データを"押し込む(push)"ことを可能とする。

Print-URI Request

一つの文書だけを伴う印刷ジョブを提出したいクライアントは，Print-URI操作を使用する。ここで，Printerオブジェクトは，クライアントがPrinterオブジェクトへ文書データを"押し込む(push)"代わりに，文書データを(URI参照先から)"引き出す(pull)"。この場合，クライアントは，要求に，(文書データそれ自体でなく)文書データへのURI参照だけを含む。

Create-Job Request

複数文書を伴う印刷ジョブを提出するクライアントは，Create-Job操作を使用する。この操作の後で，(新しく生成されたJobオブジェクトに対して他の文書を生成するごとに，)Send-Document操作及び/又はSend-URI操作を任意回数実行する。Send-Document操作は，要求に文書データを含み，クライアントは，文書データをプリンタに"押し込む"。Send-URI操作は，要求に文書データへのURI参照を含み，Printerは，参照位置から文書データを"引き出す"。与えられたJobオブジェクトに対する最後のSend-Document要求又はSend-URI要求は，これが最後の要求であることを示す'true'と設定された"last-document"操作属性を含む。

このモデル規定を通して，"生成要求"という用語は，これら三つの操作要求のいずれかを参照するために使用する。

ただ一つのSend-Document操作が続くCreate-Job操作は，Print-Job操作と意味的には等価とする。しかし，性能的な理由から，クライアントは，すべての単独文書を伴うジョブに対しては，Print-Job操作を使用するほうがよい。さらに，Print-Jobは，必す(須)操作(すべての実装がサポートしなければならない操作)とする。一方，Create-Jobは，オプションとする。そこで，実装によってはこの操作をサポートしないかもしれない。

ジョブ提出時点(又はジョブ提出時刻)(¹)は，クライアントが生成要求を発行する時点とする。すべてのJobオブジェクトの初期状態は，'pending'状態，'pending-held'状態又は'processing'状態とする(4.3.7参照)。

注1　この規定では，各種イベントの発生時を，より抽象的には"時点"と呼び，より具体的には"時刻"と呼ぶこととするが，概念的には同じものを指していることに注意。特に，4.3.12では，3.1.9で規定する各種の発生時点を具体的に示す属性を規定するので，"時刻"と呼ぶ。

Printerオブジェクトが印刷ジョブの処理を開始するとき，Jobオブジェクトの状態は'processing'に移る。これを，ジョブ処理時点(又はジョブ処理時刻)とする。ジョブ提出時点に行わなくてはならないものとして有効性確認検査がある。ジョブ処理時点に行われなければならないものも存在する。

Job提出時点及びValidate-Job操作を受信した時点で，Printerは，次を行わなければならない。

ジョブ提出時点に，Printerオブジェクトは，供給した属性，属性構文及び値と，Printerオブジェクトの対応する"xxx-supported"属性とを照合することによって，それらがサポートされるかどうかを確認しなければならない。詳細は，3.1.7を参照すること。[IPP-IIG]は，IPPオブジェクトが任意の要求を受諾又は拒否するための段階の案を示し，さらに，生成要求処理の付加的な段階を示す。

ジョブ提出時点には，Printerオブジェクトは，次に示すジョブ処理時点のために予約済みの有効性確認検査を行う必要はない。

ジョブ提出時点には，これら付加的なジョブ処理時点有効性確認検査は，本質的には無意味となる。これは，実際に文書データの構文解析及び解釈を要求するためであって，100%の正確さを保証はできない。さらに，再度，ジョブ処理時点に検査を行われなければならない。URIの場合には，ジョブ提出時点での利用可能性の検査は，ジョブ処理時点での利用可能性を保証もしない。さらに，ジョブ処理時点に，Printerオブジェクトは，ジョブ提出時点に探知できなかった次の条件のいずれかを発見するかもしれない。

• 文書データの実行時エラー。
• 未サポートフォーマットでの入れ子の文書データ。
• もはや有効ではないURI参照(すなわち，文書をホストするサーバが停止しているかもしれない。)。
• 他のあらゆるジョブ処理エラー。

ジョブ提出時点に，Printerオブジェクト，特にスプールをしないPrinterは，十分な空きをもたないままジョブを受諾してもよい。その場合，Printerオブジェクトは，無期限にクライアントからのデータ読込みを中止してもよい。クライアントは，無期限にブロックするための書込み操作の準備をしておかなくてはならない(5.1 クライアント適合性要件を参照)。

Printerオブジェクトが新しいジョブを開始するには空きが小さ過ぎる場合，新しい生成要求を拒否してもよい。この場合，Printerオブジェクトは，'server-error-busy'(C.1.5.8参照)の状態コードをもつ応答を(要求拒否の返答として)返さなくてはならず，操作のすべてのbyteを受け取る前に接続を閉じてもよい。Printerは，"printer-state-reasons"属性に'spool-space-full'値を設定し他のジョブを受諾できる場合にはその値を削除することによって，ジョブを一時的に受諾できないと指示することが望ましい(4.4.12を参照)。

'server-error-busy'状態コードを操作応答で受け取った場合，クライアントは，クライアントが(特にPrint-Job操作のための)そのデータのすべてを送る前に，Printerオブジェクトが接続を閉じる準備をしておかなければならない。クライアントは，IPP Printerオブジェクトが生成要求を受諾するまで，生成要求の提出を保持する準備をしなければならない。

ジョブ処理時点では，Printerオブジェクトは，生成要求の応答において，成功状態コード付きで既に応答してしまっているので，Printerオブジェクトがエラーを検出した場合，Printerオブジェクトは，エンドユーザに操作状態コードでエラーを知らせることができない。この場合，エラーに依存して，Printerは，後の問合せに正しいジョブ状態を報告可能とするために，ジョブオブジェクトの"job-state"属性, "job-state-reasons"属性又は"job-state-message"属性を適当な値に設定することができる。

備考　イベントの非同期通知は，この規定の範囲外とする。

すべてのPrinter操作は，Printerオブジェクトに向けて行われる。クライアントは，操作の正しい対象を識別するために"printer-uri"操作属性を常に供給しなければならない。

この必す(須)操作は，クライアントが，一つだけの文書をもつ印刷ジョブを提出すること及び(文書データへの参照ではなく)その文書データの供給することを可能にする。生成操作処理，そのOperation属性及びJob Template属性に関しては，附属書Dを参照すること。

次に示す属性のグループ(Group)は，Print-Job Requestの一部として供給される。

Group 1: Operation Attributes

Natural Language及びCharacter Set

3.1.4.1で示すとおりの"attributes-charset"属性及び"attributes-natural-language"属性。Printerオブジェクトは，この値を4.3.19及び4.3.20で示す対応するJob Description属性にコピーしなければならない。

Target

3.1.5で示すとおりのこの操作の対象となる"printer-uri" (uri)操作属性。

Requesting User Name

"requesting-user-name" (name(MAX))属性は，8.3で示すとおりに，クライアントが供給することが望ましい。

"job-name" (name(MAX))

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。これは，クライアントが供給するJob名を含む。クライアントがこの属性を供給する場合，その値は，新しく生成されたJobオブジェクトの"job-name"属性のために使用される。クライアントは，文書からの情報を伴ったアプリケーションプログラムの名前，文書名，文書の題名，ソースファイル名などの，エンドユーザがジョブを区別するのために役に立つ情報を自動的に含めてもよい。クライアントがこの属性を供給しない場合，Printerは，新しく生成されたJobオブジェクトの"job-name"属性で用いる名前を生成する(4.3.5参照)。

"ipp-attribute-fidelity" (boolean)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。値'true'は，クライアントが供給するJob Template属性及び値の総合的な忠実性を示す。そうでない場合は，Printerオブジェクトは，Print-Job要求を拒否しなければならない。値'false'は，Jobオブジェクトを印刷する正当な試みが容認されることを示し，Printerオブジェクトは，Print-job要求を受諾しなければならない。供給されない場合は，Printerオブジェクトは，値を'false'と仮定する。すべてのPrinterオブジェクトは，ジョブ処理の両方の型をサポートしなければならない。"ipp-attribute-fidelity"，及び他の属性，特にPrinterオブジェクトの"pdl-override-supported"属性，との関係の完全な記述に関しては，附属書Dを参照すること。

"document-name" (name(MAX))

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。これは，クライアントが供給する文書名を含む。文書名は，Job名とは異なってもよい。通常，クライアントソフトウェアは，ファイル名又はアプリケーションが生成する名前を用いて，エンドユーザの代わりに文書名を自動的に供給する。この属性が供給される場合は，その値は，各実装によって定義された方法で使用できる。使用例としては，Jobと共に行う(ジョブ開始シート，ページ装飾などの)印刷，課金又は資源追跡管理ツールによる使用，又は文書レベル属性として文書と共に行う格納がある。IPP/1.1は，文書レベル属性の概念をサポートしない。

"compression" (type3 keyword)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性及び"compression-supported"属性をサポートしなければならない(4.4.32参照)。クライアントが供給する"compression"操作属性は，文書データに用いる圧縮アルゴリズムを識別する。次の場合が存在する。

a)	クライアントがこの属性を省略する場合，Printerオブジェクトは，データが圧縮されないと仮定する。すなわち，Printerは，クライアントが"compression"属性の値を'none'として供給したものとして，以下の規則に従う。
b)	クライアントがこの属性を供給するが，Printerオブジェクトがその値をサポートしない場合，すなわち，その値がPrinterオブジェクトの"compression-supported"属性の値の一つではない場合，Printerオブジェクトは，要求を拒否し，'client-error-compression-not-supported'状態コードを返さなければならない。未サポート属性及び値の返却については，3.1.7を参照すること。
c)	クライアントが属性を供給し，Printerオブジェクトが属性値をサポートする場合，Printerオブジェクトは，文書データに対応する伸張アルゴリズムを用いる。
d)	Printerが操作応答を返す前に伸張アルゴリズムが失敗する場合，Printerオブジェクトは要求を拒否し，'client-error-compression-error'状態コードを返さなければならない。
e)	Printerオブジェクトが操作応答を返した後に伸張アルゴリズムが失敗する場合，Printerは，ジョブを異常終了し，'compression-error'値をジョブの"job-state-reasons"属性に追加しなければならない。
f)	伸張アルゴリズムが成功する場合，文書データは，ジョブの"document-format"属性(q.v.)が指定するフォーマットをもたなければならない。

"document-format" (mimeMediaType)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。この属性の値は，供給された文書データのフォーマットを識別する。次の場合がある。

a)	クライアントがこの属性を供給しない場合，Printerオブジェクトは，文書データがPrinterオブジェクトの"document-format-default"属性で定義するフォーマットと仮定する。すなわち，Printerは，クライアントがプリンタのデフォルト値と等しい値をもつ"document-format"属性を供給したものとして，以下の規則に従う。
b)	クライアントはこの属性を供給するが，Printerオブジェクトがその値をサポートしない場合，すなわち，その値がPrinterオブジェクトの"document-format-supported"属性の値の一つではない場合，Printerオブジェクトは，要求を拒否し，'client-error-document-format-not-supported'状態コードを返さなくてはならない。
c)	クライアントが属性を供給し，その値が'application/octet-stream'であって(すなわち，自動検出されることになる。4.1.9.1参照)，フォーマットはPrinterが自動検出できるdocument-formatの一つではなく，この検査がPrinterの操作応答の返却前に発生する場合，Printerは，要求を拒否し，'client-error-document-format-not-supported'状態コードを返さなければならない。
d)	クライアントがこの属性を供給し，その値がPrinterオブジェクトでサポートされる場合，Printerは，文書データを解釈できる。
e)	文書データの解釈が，Printerが操作応答を返す前に失敗する場合は，Printerオブジェクトは，要求を拒否し，'client-error-document-format-error'状態コードを返さなくてはならない。
f)	文書データの解釈が，Printerが操作応答を返した後に失敗する場合は，Printerオブジェクトは，ジョブを異常終了し，'document-format-error'値をジョブの"job-state-reasons"属性に追加しなければならない。

"document-natural-language" (naturalLanguage)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をオプションでサポートする。この属性は，あいまい性なく文書を表示するために自然言語の指定を要求する文書フォーマットに対して，その文書の自然言語を指定する。Printerオブジェクトがサポートすることを要求される特別な値は存在しない。

"job-k-octets" (integer(0:MAX))

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性及び"job-k-octets-supported"属性(4.4.33参照)をオプションでサポートする。クライアントが供給する"job-k-octets-supported"属性は，キロオクテット単位で提出される文書の全体サイズを識別する(完全なセマンティクスは，4.3.15.1を参照)。クライアントが属性を供給し，Printerオブジェクトがこの属性をサポートする場合，属性の値は，Jobオブジェクトの"job-k-octets" Job Description属性に入れるために使用される。

この属性及びこの属性に続く二つの属性("job-impressions"及び"job-media-sheets")について，クライアントが属性を供給し，Printerオブジェクトがその属性をサポートしない場合，Printerオブジェクトは，client-supplied値を無視する。クライアントが属性を供給し，Printerがその属性をサポートし，値が対応するPrinterオブジェクトの"xxx-supported"属性の範囲内である場合，Printerオブジェクトは，その値をJobオブジェクトの"xxx"属性に入れるために使用しなければならない。クライアントが属性を供給し，Printerが属性をサポートするが，値が対応するPrinterオブジェクトの"xxx-supported"属性の範囲外である場合，Printerオブジェクトは，属性及びその値をUnsupported Attributes応答グループにコピーし，要求を拒絶し，'client-error-attributes-or-values-not-supported'状態コードを返さなければならない。クライアントが属性を供給しない場合，Printerオブジェクトは，その属性をサポートし，正しい値を計算又は識別できるかどうかに依存して，対応するJobオブジェクト属性の使用を選択してもよい。

"job-impressions" (integer(0:MAX))

クライアントは，この属性をオプションとして供給する。Printerオブジェクトは，この属性及び"job-impressions-supported"属性をオプションとしてサポートする(4.4.34参照)。クライアントが供給する"job-impressions"操作属性は，提出されている文書の刷り数の総数を識別する。
"job-k-octets"の備考を参照すること。

"job-media-sheets" (integer(0:MAX))

クライアントは，この属性をオプションとして供給する。Printerオブジェクトは，この属性及び"job-media-sheets-supported"属性をオプションとしてサポートする(4.4.35参照)。クライアントが供給する"job-imedia-sheets"操作属性は，このジョブのために生成されるメディアシートの総数を識別する(完全なセマンティクスに関しては，4.3.15.3を参照)。
"job-k-octets"の備考を参照すること。

Group 2: Job Template Attributes

クライアントは，4.2で定義するJob Template属性の集合をオプションで供給する。クライアントが要求でJob Template属性を供給していない場合，クライアントは，空のグループを送るのでなく，Group 2を省略するほうがよい。しかし，Printerオブジェクトは，空のグループを受諾できなければな らない。

Group 3: Document Content

クライアントは，処理するための文書データを供給しなければならない。

備考　最も簡単なPrint-Job Requestは，あらゆる操作要求に要求される必す(須)パラメタに加えて，"attributes-charset"操作属性及び"attributes-natural-language"操作属性，"printer-uri"対象操作属性及び文書コンテンツだけから構成される。この簡単な場合には，Printerオブジェクトは，次のことを行う。

• 新しいJobオブジェクト生成する。このJobオブジェクトは，一つの文書を含む。
• 要求された自然言語及びcharsetを使用して，生成されたJob名を"job-name"属性に記憶する(3.1.4.1参照)。ただし，これは，要求された自然言語及びcharsetがサポートされる場合とする。サポートされない場合には，Printerオブジェクトのデフォルトの自然言語及びcharsetを使用する。
• ジョブ処理時点で，IPP属性又は文書データに埋め込まれた命令として，クライアントが供給しいないサポート済みJob Template属性に対しては，対応するデフォルト値属性を使用する。

Printerオブジェクトは，クライアントにPrint-Job Responseの一部として，次の属性の集合を返さなければならない。

Group 1: Operation Attributes

Status Message

あらゆる応答で返される必す(須)状態コードに加えて，応答は，附属書B及び3.1.6で示す"status-message" (text(MAX))及び/又は"detailed-status-message" (text(MAX))操作属性をオプションで含む。クライアントが，未サポート又は相容れない，Job Template属性又は値を供給する場合，Printerオブジェクトは，クライアントが"ipp-attribute-fidelity"操作属性に'true'又は'false'の値のどちらを与えるかに依存して，Print-Job要求を拒否又は受諾しなければならない。生成要求を処理するために提案された手順の完全な記述に関しては，実装者ガイド[IPP-IIG]を参照すること。

Natural Language及びCharacter Set

3.1.4.2に示すとおりの"attributes-charset"属性及び"attributes-natural-language"属性。

Group 2: Unsupported Attributes

Unsupported Attributeの返却に関する詳細については，3.1.7を参照すること。

クライアントが供給する"ipp-attribute-fidelity"の値は，Printerオブジェクトがこのグループでどの属性を返すかに影響を与えない。"ipp-attribute-fidelity"の値は，Print-Job操作が受諾されるか又は拒否されるかだけに影響する。ジョブが受諾される場合，クライアントは，どの属性が無視されたか(すなわち，Jobオブジェクトに記憶されなかったか)及びどの属性が他の(置き換えられた)値で記憶されたかを知るために，生成応答で返された未サポート属性を要求するGet-Job-Attributes操作を使用してジョブに問い合わせてもよい。

Group 3: Job Object Attributes

"job-uri" (uri)

Printerオブジェクトは，必す(須)"job-uri"Jobオブジェクト属性の内容を返すことによって，JobオブジェクトのURIを返さなければならない。クライアントは，Jobオブジェクトに向けて操作を行うときに，そのJobオブジェクトのURIを使用する。Printerオブジェクトは，新しいURIの生成するときには，常に，構成されたセキュリティ方針を使用する。しかし，Printerオブジェクトが複数のURIをサポートする場合には，Printerオブジェクトは，新しいURIを生成するためにPrint-Job RequestでどのURIを使用したかについての情報も使用する。これによって，新しいURIが正しいアクセスチャネルを参照することになる。言い換えると，Print-Job Requestが安全なチャネル上で到着する場合，Printerオブジェクトもその安全なチャネルを使用するJob URIを生成しなければならない。

"job-id" (integer(1:MAX))

Printerオブジェクトは，必す(須)"job-id"Jobオブジェクト属性を返すことでJobオブジェクトのJob IDを返さなければならない。クライアントは，Printerオブジェクトに向けてJob操作を行うときに，Print-Job Requestで使用する"printer-uri"属性と関連するこの"job-id"属性を使用する。

"job-state" (type1 enum)

Printerオブジェクトは，Jobオブジェクトの必す(須)の"job-state"属性を返さなければならない。(次の属性である"job-state-reasons"の値と共に，)この属性の値は，PrinterオブジェクトがPrint-Job Requestを受信する時点とPrinterオブジェクトが応答を返す時点との間の，(実装定義の)ある意味のある時点での新しいJobオブジェクトの"スナップショット"から抽出される。

"job-state-reasons" (1set0f type2 keyword)

Printerオブジェクトは，Jobオブジェクトの必す(須)の"job-state-reasons"属性を返さなければならない。

"job-state-message" (text(MAX))

Printerオブジェクトは，Jobオブジェクトのオプションの"job-state-message"属性を，オプションとして返す。Printerオブジェクトがこの属性をサポートする場合は，応答で返されなければならない。この属性が応答で返されない場合は，クライアントは，"job-state-message"属性がサポートされていないと仮定でき，その後のJobオブジェクトの問合せで返されることはない｡

"number-of-intervening-jobs" (integer(0:MAX))

Printerオブジェクトは，Jobオブジェクトのオプションの"number-of-intervening-jobs"属性を，オプションとして返す。Printerオブジェクトがこの属性をサポートする場合は，応答で返さなければならない。この属性が応答で返されない場合は，クライアントは，"number-of-intervening-jobs"属性がサポートされていないと仮定でき，その後のJobオブジェクトの問合せで返されることはない｡

備考　 Jobの状態に影響を与えるプリンタ状態情報は，"job-state"属性及び"job-state-reasons"属性に反映されるので，これらの属性だけを返せば十分であって，特別なプリンタ状態属性を返す必要はない。

備考　最も簡単な応答は，あらゆる操作応答に対して要求される必す(須)のパラメタに加えて，"attributes-charset"操作属性及び"attributes-natural-language"操作属性，並びに"job-uri", "job-id"及び"job-state"の各Job Object Attributesから構成される。この簡単な場合には，状態コードは'successful-ok'となり，"status-message"操作属性は存在しない。

このオプションの操作は，文書データ自体を含むのではなく，(Group 1における)"document-uri" (uri)操作属性を使用することによって文書データへのURI参照をクライアントが供給すること以外は，Print-Job操作(3.2.1参照)と同じとする。応答を返す前に，Printerは，URIによって暗黙的に示される検索方法(例えばhttp, ftpなど)をPrinterがサポートすることを確認し，妥当なURI構文の検査をしなければならない。client-supplied URI方式がサポートされていない場合，すなわち，値がPrinterオブジェクトの"referenced-uri-scheme-supported"属性に存在しない場合，Printerオブジェクトは，要求を拒絶し，'client-error-uri-scheme-not-supported'状態コードを返さなければならない。

IPP Printerは，操作又はそれに続くものの一部としての文書のアクセス可能性を確認してもよい。Printerが操作応答を返す前にアクセス可能性に問題があると断定する場合は，要求を拒絶し，'client-error-document-access-error'状態コードを返す。Printerは，"document-access-error"操作属性を使って，特定の文書アクセスエラーコードを返してもよい(3.1.6.4参照)。

Printerが要求を受諾し，成功状態コードの一つをもつ応答を返した後で，文書アクセス可能性に問題があると断定する場合には，Printerは，'document-access-error'値を，ジョブの"job-state-reasons"属性に追加し，ジョブの"job-document-access-errors" Job Description属性(4.3.11参照)を組み込んでもよい。提案する追加検査については，実装者ガイド[IPP-IIG]を参照すること。

Printerオブジェクトがこの操作をサポートする場合，"reference-uri-schemes-supported" Printer属性をサポートしなければならない(4.4.27参照)。

URIを解釈し，そのURI文字列によって参照されるソースから文書"引き出す"のは，IPPオブジェクトの責任とする。

この必す(須)操作は，クライアントが，文書データを供給せずPrinterが資源を割り付けない(すなわち，新しいJobオブジェクトを生成しない)こと以外は，Print-Job操作(3.2.1参照)に類似する。この操作は，Validate-Job要求でクライアントによって供給される属性の如何によらず，プリンタオブジェクトの能力を検証するためだけに使用する。Validate-Job操作を使用することで，クライアントは，(文書データをもつ)同等のPrint-Job操作が受諾されることを確認できる。Validate-Job操作は，Print-Job操作と同じセキュリティ折衝も実行する(8.参照)。その結果，クライアントは，Print-Job操作を実行する前に，クライアント及びPrinterオブジェクトのセキュリティ要件を見合うものにできることを検査可能とする。

同じPrint-URI操作が受諾されることを，クライアントに検査可能とするために，Validate-Job操作は，"document-uri"属性を受諾しない。これは，クライアントが，Print-URI操作を用いてデータを送信しないことによる。クライアントは，単に，Print-URI要求を発行することが望ましい。

Printerオブジェクトは，Print-Job操作と同じ状態コード，同じOperation Attributes(Group 1)及び同じUnsupported Attributes(Group 2)を返す。しかし，Jobオブジェクトは生成されないので，Job Object Attributes(Group 3)は返さない。

このオプションの操作は，クライアントが，Create-Job要求において，文書データも文書データへの参照も供給しないこと以外は，Print-Job操作(3.2.1参照)に類似する。さらに，クライアントは，"document-name"，"document-format"，"compression"及び"document-natural-language"の操作属性のいずれも供給しない。この操作には，複数のSend-Document操作又はSend-URI操作が続く。これら操作要求のそれぞれにおいて，クライアントは，複数文書Jobオブジェクトでの各文書に対して，"document-name"属性，"document-format"属性及び"document-natural-language"属性をオプションで供給する。

PrinterオブジェクトがCreate-Job操作をサポートする場合，Send-Document操作もサポートしなければならず，Send-URI操作をサポートしてもよい。

Printerオブジェクトがこの操作をサポートする場合，"multiple-operation-time-out" Printer属性(4.4.31参照)をサポートしなければならない。

Printerオブジェクトがこの操作をサポートする場合，"multiple-document-jobs-supported" Printer Description属性をサポートし，複数文書ジョブをサポートするかどうかを示さなければならない。

Printerオブジェクトがこの操作をサポートし，ジョブで複数文書をサポートする場合，少なくとも一つの値をもつ"multiple-document-handling" Job Template Printer属性(4.2.4参照)，並びに"multiple-document-handling-default"及び"multiple-document-handling-supported"の各Job Template Printer属性をサポートしなければならない。

Create-Job操作が完了した後，"job-state"属性の値は，たとえ文書データが到着しなくても，Print-Jobの後の"job-state"の値と似ている。Printerは，ジョブの"job-state-eason"属性の'job-data-insufficient'値を，十分なデータが到着するまでは処理を開始できないことを示すために，設定してもよいし，"job-state"を'pending'又は'pending-held'に設定してもよい。'pending'ジョブ状態を実装しないスプールしないプリンタは，処理するデータがまだ存在しなくても，"job-state"を'processing'に設定してもよい。4.3.7及び 4.3.8を参照すること。

この必す(須)操作は，クライアントがPrinterオブジェクトの属性の値を要求することを可能にする。要求において，クライアントは，要求者が着目するPrinter属性名及び/又は属性グループ名の集合を供給する。応答において，Printerオブジェクトは，適当な属性値をもつ対応する属性の集合を返す。

Printerオブジェクトに対する属性グループの可能な名前を次に示す｡

'job-template'

Job Template属性の部分集合であって，Printerオブジェクトのために実装がサポートするPrinterオブジェクト(4.2の表10の最後の二つの欄)に適用される。

'printer-description'

4.4で示される属性の部分集合であって，Printerオブジェクトのために実装がサポートする。

'all'

特別グループ'all'であって，Printerオブジェクトのために実装がサポートするすべての属性を含む。

クライアントは特定の属性又は名前付けされたグループを要求してもよいので，幾つかの重複がでる可能性がある。例えば，クライアントが'printer-name'及び'all'を要求する場合，クライアントは，実際には"printer-name"属性を2回要求している。すなわち，一度は明示的に，もう一度は'all'グループに含まれることによってである。この場合，たとえ複数回の要求があっても，Printerオブジェクトは応答で属性ごとに返す必要はなく，一度だけでよい。クライアントは同じ属性を複数の方法で要求しないことが望ましい。

Printerオブジェクトがグループに属するすべての属性をサポートすることは必す(須)とはしない。(これは，幾つかの属性はオプションのためとする。)しかし，各Printerオブジェクトは，すべてのグループ名をサポートすることは必す(須)とする｡

Group 1: Operation Attributes

Natural Language及びCharacter Set

3.1.4.1で示すとおりの"attributes-charset"及び"attributes-natural-language"属性。

Target

3.1.5で示すとおりのこの操作の対象となる"printer-uri" (uri)操作属性。

Requesting User Name

"requesting-user-name" (name(MAX))属性は，8.3で示すとおりに，クライアントによって供給されることが望ましい。

"requested-attributes" (1setOf keyword)

クライアントは，オプションで，要求者が関心をもつ値で属性名及び/又は属性グループ名を供給する。Printerオブジェクトは，この属性をサポートしなければならない。クライアントがこの属性を省略する場合，Printerは，この属性が'all'の値で供給されたものとして応答しなければならない。

"document-format" (mimeMediaType)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。この属性は，Printerオブジェクトが，要求された文書フォーマットに関係するサポート済み属性値の集合をサポートするのに有用となる。Printerオブジェクトは，この文書フォーマットが供給される生成操作又はValidate-Job操作のジョブの妥当性を確認するために使用する属性及び値を返さなければならない。Printerオブジェクトは，指定されたフォーマットに対してサポートされる属性，及び指定された文書に対してサポートされる属性値，だけを返す。文書フォーマットを指定することで，クライアントは，特定の文書フォーマットに対してサポートされない属性及び値を消去するために，Printerオブジェクトを得ることができる。例えば，Printerオブジェクトは，'application/postscript'(PostScript用)及び'text/plain'(テキスト用)の両方の文書をサポートするために，複数のインタプリタをもつかもしれない。しかし，これらインタプリタの一つだけに対して，Printerオブジェクトは，'1', '2'及び'4'の値をもつ"number-up"をサポートをできるかもしれない。他のインタプリタに対しては，'1'の値の"number-up"をサポートするだけかもしれない。そこでクライアントは，生成ジョブ操作を受諾又は拒否するのに使用する属性及び値を獲得するために，Get-Printer-Attributes操作を使うことができる。

Printerオブジェクトが，生成操作及びValidate-Job操作でジョブの妥当性を確認するときに異なる文書ごとにサポート済み値の異なる集合を区別しない場合，Get-Printer-Attributes操作で異なる文書フォーマットを区別してはならない。Printerオブジェクトが，クライアントによって指定される異なる文書フォーマットごとにサポート済み値の異なる集合を区別をする場合，この特殊化は，次に示すPrinterオブジェクト属性だけに適用される。

• Job Template属性(4.2の表10で"xxx-default"，"xxx-supported"及び"xxx-ready")であるPrinter属性。
• "pdl-override-supported"
• "compression-supported"
• "job-k-octets-supported"
• "job-impressions-supported"
• "job-media-sheets-supported"
• "printer-driver-installer",
• "color-supported"
• "reference-uri-schemes-supported"

("document-format-supported"を含む)他のすべてのPrinterオブジェクト属性の値は，クライアントが供給した文書フォーマットに関しては不変のままとする。(ただし，6.2に従い登録された新しいPrinter記述属性を除く。)

クライアントがこの"document-format"操作属性を省略する場合，Printerオブジェクトは，その属性がPrinterオブジェクトの"document-format-default"属性の値で供給されたものとして応答しなければならない。クライアントは，"document-format"に対する値を常に供給するほうがよい。これは，Printerオブジェクトの"document-format-default"が'application/octet-stream'となっているかもしれず，その場合には返される属性及び値は，Printerが自動的に検出できる文書フォーマットの合併となってしまうからである。詳細は，4.1.9の'mimeMediaType'属性構文の記述を参照すること。

クライアントが，Printerによってサポートされない，ずなわち，Printerオブジェクトの"document-format-supported"属性の中にない"document-format" Operation属性に対して値を供給する場合，Printerオブジェクトは，その操作を拒否し，'client-error-document-format-not-supported'状態コードを返さなくてはならない。

Printerオブジェクトは，Get-Printer-Attributes Responseの一部として次の集合を返す。

Group 1: Operation Attributes

Status Message

すべての応答で返す必す(須)状態コードに加えて，応答は，附属書B及び3.1.6に示すとおりの"status-message" (text(255))及び/又は"detailed-status-message"(text(MAX))操作属性をオプションで含む。

Natural Language及びCharacter Set

3.1.4.2で示すとおりの"attributes-charset"及び"attributes-natural-language"属性。

Group 2: Unsupported Attributes

Unsupported Attributesの返却の詳細は，3.1.7参照すること。

応答は，クライアントが要求しIPPオブジェクトがサポートしない供給された値(属性keywords)をもつ"requested-attributes"操作属性を含む必要はない。Printerオブジェクトが"requested-attributes"操作属性で参照される未サポート属性を返し，その属性が'all'などのグループ名を含んでいた場合，その未サポート属性は，この規定で示されるが実装によってサポートされない属性を含んではならない。

Group 3: Printer Object Attributes

これは，必す(須)属性及びその現在値の集合とする。Printerオブジェクトは，サポートされていないあらゆる要求された属性を無視する(すなわち，応答しない)。Printerオブジェクトは，実施中の安全方針に依存して，サポート済みの属性及び値の部分集合で応答してもよい。しかし，Printerオブジェクトは，Printerオブジェクトが値を知らない(すべての必す(須)属性を含む)あらゆるサポート済み属性に対して，'unknown'値で応答しなければならない。さらに，Printerオブジェクトは，システム管理者が値を構成していない(すべての必す(須)属性を含む)あらゆるサポート済み属性に対して，'no-value'で応答しなければならない。"out-of-band"値の記述は，4.1の最初を参照すること。

この必す(須)操作は，クライアントが対象Printerオブジェクトに属するJobオブジェクトのリストを検索するのを可能にする。クライアントは，Job属性名及び/又は属性グループ名のリストを供給してもよい。Jobオブジェクト属性のグループは，返された各Jobオブジェクトに対して，返される。

この操作は，Get-Job-Attributes操作と類似している。ただし，Get-Jobs操作は，複数のオブジェクトからの属性を返す可能性があることは異なっている。

クライアントは，Get-Jobs要求をPrinterオブジェクトに提出する。

次の属性のグループは，Get-Jobs Requestの一部とする。

Group 1: Operation Attributes

Natural Language及びCharacter Set

3.1.4.1で示すとおりの"attributes-charset"及び"attributes-natural-language"属性。

Target

3.1.5で示すとおりにこの操作の対象となる"printer-uri" (uri)操作属性。

Requesting User Name

"requesting-user-name" (name(MAX))属性は，8.3に示すとおりに，クライアントによって供給されることが望ましい。

"limit" (integer(1:MAX))

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。この属性は整数値であって，たとえ"which-jobs"又は"my-jobs"がどちらのジョブが返されるかを制限するとしても，この属性が，クライアントがPrinterから受け取るジョブの最大数を決定する。制限は，クライアントが供給したのが'N'の場合は，最初の'N'ジョブだけがGet-Jobs Responseで返されるという意味で，"状態のない制限(stateless limit)"とする。最初の'N'ジョブの後に次の'M'ジョブを許す機構は存在しない。クライアントがこの属性を供給しない場合，Printerオブジェクトは，すべての適用可能なジョブで応答する。

"requested-attributes" (1setOf type2 keyword)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは, この属性をサポートしなければならない。この属性は，要求者が関心をもつ値であるJob属性名及び/又は属性グループ名の集合とする。この属性の集合は，返される各Jobオブジェクトに対して返される。許容される属性グループ名は，3.3.4のGet-Job-Attributes操作で定義したものと同じとする。クライアントがこの属性を供給しない場合，Printerは，クライアントが'job-uri'及び'job-id'の二つの値でこの属性を供給したものとして応答しなければならない。

"which-jobs" (keyword)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。この属性は，どのJobオブジェクトがPrinterオブジェクトによって返されなければならないか示す。この属性の値を，次に示す。

'completed'

これは，状態が'completed'，'canceled'又は'aborted'任意のJobオブジェクトを含む。

'not-completed'

これは，状態が'pending'，'processing'，'processing-stopped'又は'pending-held'である任意のJobオブジェクトを含む。

Printerオブジェクトは，両方の値をサポートしなければならない。しかし，実装が'completed'，'canceled'及び'aborted'状態でジョブを保持しない場合は，'completed'値が供給されたとき，ジョブなしと応答する。

クライアントが何か他の値を供給する場合，Printerオブジェクトは，属性及び未サポート値をUnsupported Attributes応答グループにコピーし，'client-error-attributes-or-values-not-supported'状態コードを返さなければならない。

クライアントがこの属性を供給しない場合，Printerオブジェクトは，クライアントが'not-completed'の値をもつ属性を供給したものとして応答しなければならない。

"my-jobs" (boolean)

クライアントは，この属性をオプションで供給する。Printerオブジェクトは，この属性をサポートしなければならない。この属性は，すべてのユーザからのジョブ，又はこの要求の要求ユーザが提出するジョブだけのいずれが，Printerオブジェクトによって返されなければならないかを示す。クライアントがこの属性を供給しない場合，Printerオブジェクトは，'false'の値，すなわち，すべてのユーザからのジョブであることを示す値，をもつ属性をクライアントが供給したものとして応答しなければならない。要求ユーザを認証しジョブを照合する方法は，8.に示す。

Printerオブジェクトは，要求でクライアントが供給する属性値によって定義される基準に合致する"limit"属性指定の数になるまで，すべてのJobオブジェクトを返す。文字どおりJobオブジェクトがPrinterに存在しないかもしれないし，又はクライアントが供給する基準に合致するJobオブジェクトが存在しないかもしれないので，Jobオブジェクトが返されないこともある。クライアントが何らかのJob属性を要求する場合は，各Jobオブジェクトに対して返されるJob Object Attributesの集合が存在する。

Printerが0ジョブを返すのはエラーではない。基準に合致するジョブが存在しないので応答が0ジョブを返し，基準に合致するジョブが存在すれば応答が'successful-ok'の状態コードで一つ以上のジョブを返したであろうという場合には，0ジョブの状態コードは，'successful-ok'でなければならない。

Group 1: Operation Attributes

Status Message

すべての応答で返される必す(須)状態コードに加えて，応答は，附属書B及び3.1.6に示す"status-message" (text(255))及び/又は"detailed-status-message"(text(MAX))操作属性をオプションで含む。

Natural Language及びCharacter Set

3.1.4.2に示すとおりの"attributes-charset"及び"attributes-natural-language"属性。

Group 2: Unsupported Attributes

Unsupported Attributesの返却に関する詳細については，3.1.7参照すること。

応答は，クライアントが要求しIPPオブジェクトがサポートしない，供給された値(属性keywords)をもつ"requested-attributes"操作属性を含む必要はない。Printerオブジェクトが"requested-attributes"操作属性で参照される未サポート属性を返し，その属性が'all'などのグループ名を含んでいた場合，未サポート属性は，この規定で示されるが実装でサポートされない属性を含んではならない。

Groups 3 to N: Job Object Attributes

Printerオブジェクトは，Jobオブジェクト返却の度にJob Object Attributesの一つに集合をもって応答する。Printerオブジェクトは，要求するユーザがジョブを提出したユーザ(ジョブ発信ユーザ)であるか，そうでないか(8.参照)，によらずということを含め，サポートされていない又は実施中の安全方針で制約されている要求された属性又は値を無視する(すなわち，応答しない)。しかし，Printerオブジェクトは，安全方針に違反しない場合は，Printerオブジェクトが値を知らない(必す(須)属性を含む)あらゆるサポート済み属性に'unknown'値で応答しなければならない。4.1の最初にある"out-of-band"値の詳細を参照すること。

Jobは，次の順番で返される。

• クライアントがすべての'completed'Job('completed'，'aborted'又は'canceled'の各状態にあるJob)を要求する場合，Jobは，(実際の完了時間に関して)最新のものから古いものへと返される。
• クライアントが，すべての'not-completed'Job('pending'，'processing'，'pending-held'及び'processing-stopped'の各状態にあるJob)を要求する場合，(いかなるスケジューリングアルゴリズムがPrinterオブジェクトに対して構成されようともそれに基づいて，)Jobは，相対的な完了予想時間の時間順に返される。

このオプションの操作は，クライアントがPrinterオブジェクトにすべてのデバイスに関するジョブをスケジューリングするのを停止することを可能にする。実装に依存して，Pause-Printer操作は，Printerに，(一般に複数個の)現ジョブの処理も停止させてもよい。現在印刷中のジョブは，実装に依存して，実装が許す限りすぐに停止するか，又は最後まで完了する。Printerオブジェクトは，そのまま，新しいジョブ生成の生成操作を受諾しなければならないが，いかなるジョブも'processing'状態に入ることは禁止しなければならない。

Pause-Printer操作がサポートされる場合，Resume-Printer操作はサポートされなければならず，その逆も成立しなければならない。

IPP Printerは，実装が許す限り即座に，'processing'状態又は'processing-stopped'状態にあったデバイス上の現ジョブを停止する。実装が停止のための適切な時間をとる場合は，IPP Printerは，'moving-to-paused'値をPrinterオブジェクトの"printer-state-reasons"属性に追加する(4.4.12参照)。デバイスすべてが停止したとき，IPP Printerは，Printerオブジェクトを'stopped'状態に移行し，存在する場合には'moving-to-paused'値を取り除き，'paused'値をPrinterオブジェクトの"printer-state-reasons"属性に追加する。

'processing'状態にあった現ジョブが完了した場合，IPP Printerは，それを'completed'状態に移行する。現'processing'状態にあったジョブが処理中に停止した場合，IPP Printerは，それを'processing-stopped'状態に移行し，'printer-stopped'値をジョブの"job-state-reasons"属性に追加する。

'pending'又は'pending-held'にあるジョブに対しては，ジョブの"job-state-reasons"属性の'printer-stopped'値も適用される。しかし，IPP Printerは，これらのジョブの"job-state-reasons"属性を更新する必要はなく，これらジョブが問い合わせられた場合に'printer-stopped'値を返すことだけを必要とする。(これを，"遅延評価(lazy evaluation)"という。)

Pause-Printer操作が，IPPを用いてIPP Printerオブジェクトに提出されたジョブに影響するのと同じ方法で，IPP Printerオブジェクト以外の他のソースからデバイスに提出されたジョブに影響するかどうかは，実装依存とする。すなわち，一般管理プロトコルとしてIPPプロトコルが用いられているか, 又はIPPジョブを管理するためだけに使用されているか，に依存する。

IPP Printerは，どんな状態であってもこの要求を受諾し，応答を返す前に，Printerを表4のとおりに示された新しい"printer-state"に遷移させなければならない。

アクセス権について。この操作を行う認証済みユーザ(8.3参照)は，Printerオブジェクトの操作者又は管理者でなければならない(1.及び8.5参照)。そうでない場合は，IPP Printerは操作を拒否し，'client-error-forbidden'，'client-error-not-authenticated'又は'client-error-not-authorized'を適切に返さなければならない。

次の属性のグループは，Pause-Printer Requestの一部とする。

Group 1: Operation Attributes

Natural Language及びCharacter Set

3.1.4.1に示すとおりの"attributes-charset"及び"attributes-natural-language"属性。

Target

3.1.5に示すとおりのこの操作の対象となる"printer-uri" (uri)操作属性。

Requesting User Name

"requesting-user-name" (name(MAX))属性は，8.3に示すとおりに，クライアントが供給することが望ましい。

次の属性のグループは，Pause-Printer Responseの一部とする。

Group 1: Operation Attributes

Status Message

すべての応答で返される必す(須)状態コードに加えて，応答は，附属書B及び3.1.6に示す"status-message" (text)操作属性をオプションで含む。

Natural Language及びCharacter Set

3.1.4.2に示すとおりの"attributes-charset"及び"attributes-natural-language"属性。

Group 2: Unsupported Attributes

Unsupported Attributesの返却の詳細については，3.1.7を参照すること。

この操作は，クライアントが，Printerオブジェクトに対してその全デバイス上のジョブのスケジューリングジョブを再開させることを可能にする。Printerオブジェクトは，存在する場合には，Printerオブジェクトの"printer-state-reasons"属性から，'paused'値及び'moving-to-paused'値を取り除かなければならない。(media-jamなどの)デバイスを停止する他の理由が存在しない場合，IPP Printerは，それ自体を，処理する必要があるジョブの存在する又は存在しないに依存して，それぞれ'processing'状態又は'idle'状態へと遷移し，デバイスはジョブの処理を再開する。

Pause-Printer操作がサポートされている場合は，Resume-Printer操作もサポートされなければならず，その逆も成立しなければならない。

IPP Printerは，そのPrinterに含まれるあらゆるジョブの"job-state-reasons"属性から，'printer-stopped'値を取り除く。

IPP Printerは，どんな状態であっても要求を受諾し，Printerオブジェクトを表5で示される新しい状態へ遷移しなければならない。

アクセス権について。この操作を行う認証済みユーザ(8.3参照)は，Printerオブジェクトの操作者又は管理者でなければならない(1.及び8.5参照)。そうでない場合は，IPP Printerは操作を拒否し，'client-error-forbidden'，'client-error-not-authenticated'又は'client-error-not-authorized'を適切に返さなければならない。

Resume-Printer Request及びResume-Printer Responseは，Pause-Printer操作と同じ属性グループ及び属性をもつ(3.2.7.1及び3.2.7.2参照)。

このオプションの操作は，ジョブ状態に関わらず，クライアントがPrinterオブジェクトのJob Historyの中のジョブを含むすべてのジョブをIPP Printerオブジェクトから削除することを可能にする(4.3.7.1参照)。Purge-Jobs操作が行われた後，Printerオブジェクトは，それに続くGet-Job-Attributes応答及びGet-Jobs応答で，(新らしいジョブが提出されるまでは，)ジョブなしを返さなければならない。

Purge-Jobs(及びGet-Jobs)操作が，Purge-Jobs操作がIPPを用いてIPP Printerに提出されたジョブに影響するのと同じ方法で，IPP Printerオブジェクト以外の他のソースからデバイスに提出されたジョブに影響するかどうかは，実装依存とする。すなわち，一般管理プロトコルとしてIPPプロトコルが使用されているのか，又はIPPジョブを管理するだけに使用されているのか，に依存する。

備考　操作者がJob Historyを消し去ることなしにすべてのジョブをキャンセルしたい場合は，操作者は，Purge-Job操作を用いる代わりに，各ジョブごとにCancel-Jobを使用する。

Printerオブジェクトは，どんな状態であってもこの操作を受諾し，Printerオブジェクトを'idle'状態に遷移させなければならない。

アクセス権について。この操作を行う認証済みユーザ(8.3参照)は，Printerオブジェクトの操作者又は管理者でなければならない(1.及び8.5参照)。そうでない場合は，IPP Printerは操作を拒否し，'client-error-forbidden'，'client-error-not-authenticated'又は'client-error-not-authorized'を適切に返さなければならない。

Purge-Jobs Request及びPurge-Jobs Responseは，Pause-Printer操作と同じ属性グループ及び属性をもつ(3.2.7.1及び3.2.7.2を参照)。

すべてのJob操作は，Jobオブジェクトに対して行なう。操作の正しい対象を特定するするために，クライアントは，Jobオブジェクトを特定する手段を常に提供しなければならない。ジョブの特定は，単一のJob URIであってもよいし，Printer URIとJob IDとの組合せであってもよい。IPPオブジェクトの実装は，すべてのジョブに対して両方の形式による特定をサポートしなければならない。

このオプション操作によって，クライアントは複数文書Jobオブジェクトを "empty"という初期状態(文書を含んでいない状態)で生成する。Create-Job応答で，PrinterオブジェクトはJobオブジェクトのURI("job-uri"属性)及びJobオブジェクトの32ビット識別子("job-id"属性)を返す。クライアントが追加を望む新たな文書それぞれに対して，クライアントはSend-Document操作を使用する。それぞれのSend-Document Requestは一つの文書に対する文書データのストリーム全体を含む。

Printerがこの操作をサポートするが，一つのジョブでの複数文書をサポートしない場合，Printerはデータと共に用いられる後続するSend-Document操作を拒絶し，'server-error-multiple-document-jobs-not-supported'を返さなければならない。しかし，Printerは，"last-document"操作属性(以下を参照)の値が'true'又は'false'となっている最初の文書を受理しなくてはならない。その結果，クライアントは単一文書ジョブを，最初のSend-Documentで"last-document"の値を'false'として，(データを伴わない)2番目のSend-Documentで"last-document"の値を'true'として提出してもよい。

Create-Job及びそれに後続する送信操作(Send-Document又はSend-URI操作)は，特定のジョブに対して任意の長い時間間隔で発生する可能性があるので，クライアントはそのジョブに対する前回の要求の受信の後，IPP Printerが定義する最小時間間隔内で，別の送信操作を送信しなければならない。Printerオブジェクトが複数文書ジョブをサポートする場合，Printerオブジェクトは"multiple-operation-time-out"属性(4.4.31参照)をサポートしなければならない。この属性は，Printerオブジェクトが何らかの回復動作をとる前に，次回の送信操作を待つ最小の秒数を指示する。

Printerオブジェクトの"multiple-operation-time-out"属性が指定する最小時間間隔の経過後，送信操作を供給しない誤ったクライアントからIPPオブジェクトは回復しなければならない。回復には次に示す動作を行なってもよいし，他の回復動作を行なってもよい。

独自の方針，文書が追加されたか否か，実装がジョブをスプールするか否か，及び/又は他の利用可能な情報に基づいて，それぞれの実装は最適な動作を自由に決めることができる。Jobオブジェクトを中断することを選択する場合，Jobオブジェクトがメディアシートページが印刷された時点まで処理が進んでいてもよい。

アクセス権について。この操作を行なう認証済ユーザ(8.3参照)は，(Create-Job操作で決まる)ジョブ所有者，操作者又はPrinterオブジェクトの管理者(1.及び8.5参照)のいずれかでなければならない。そうでない場合は，IPPオブジェクトはその操作を拒絶し，'client-error-forbidden', 'client-error-not-authenticated'又は'client-error-not-authorized'の中の適当なものを返さなければならない。

次の属性集合は，Send-Document Requestの一部とする。

Group 1: Operation Attributes

Natural Language及びCharacter Set

3.1.4.1に記述されている"attributes-charset"属性及び"attributes-natural-language"属性。

Target

3.1.5に記述するとおりに，この操作の対象を定義する"printer-uri" (uri)と"job-id" (integer(1:MAX))との組，又は"job-uri" (uri)操作属性。

Requesting User Name

8.3で記述するとおりに，"requesting-user-name" (name(MAX))属性をクライアントは供給した方がよい。

"document-name" (name(MAX))

クライアントはこの属性を供給してもよい。Printerオブ ジェクトはこの属性をサポートしなければならない。この属性はクライアントが供給する文書名を含む。文書名はJob名と異なってもよい。同一Job 内の文書で一意である必要はないが，一意とすることは有用かもしれない。典型的には, クライアントソフトウェアがエンドユーザに代わって，ファイル名又はアプリケーションが生成した名前を用いて，文書名を自動的に生成する。この属性に関してより多くの情報を得るには，Print-Job Request(3.2.1.1参照)の"document-name"操作属性の記述を参照すること。

"compression" (type3 keyword)

3.2.1.1のPrint-Job操作の"compression"の記述を参照。

"document-format" (mimeMediaType)

3.2.1.1のPrint-Job操作の"document-format"の記述を参照。

"document-natural-language" (naturalLanguage)

クライアントは，この属性をオプションとして供給する。Printerオブジェクトのこの属性のサポートは，オプションとする。文書をあいまい性なくイメージするために自然言語の指定が必要な文書フォー マットのために，この属性は文書の自然言語を指定する。Printerオブジェクトがサポートする必要のある特別な値はない。

"last-document" (boolean)

クライアントは，この属性を供給しなければならない。Printerオブジェクトは，この属性をサポートしなければならない。この属性は論理値のフラグで，Jobの最後の文書であれば'true'に，そうでない場合は'false'に設定される。

Group 2: Document Content

"last-document"フラグが'false'に設定されている場合，クライアントは，文書データを供給しなければならない。しかし，クライアントは，Send-Document(又はSend-URI)操作で送信した前回の文書が最後の文書であったか(つまり，"last-document"属性が'false'に設定されていたか)否かを知ることができないかも知れないので，文書データをもたないSend-Document要求を，"last-document"フラグを'true'に設定して送信してもよい。その要求は，ジョブに実際の文書が追加されたわけではないので，Jobオブジェクトの"number-of-documents"属性を増加させてはならない。クライアントが実際の文書データなしで提出すること，すなわち，文書データなしで'true'に設定された"last-document"操作属性をもつ唯一つのCreat-Job及びSend-Documentの要求を提出することは，エラーとしない。

次の属性集合はSend-Document Responseの一部とする。

Group 1: Operation Attributes

Status Message

すべての応答で返される必す(須)の状態コードに加えて，応答は附属書B及び3.1.6で記述する"status-message" (text)操作属性を含んでもよい。

Natural Language及びCharacter Set

3.1.4.2で記述する"attributes-charset"属性及び"attributes-natural-language"属性。

Group 2: Unsupported Attributes

Unsupported Attributeの戻し方に関する詳細は3.1.7参照。

Group 3: Job Object Attributes

Print-Job応答で記述したのと同じ属性集合(3.2.1.2参照)。

このオプション操作は，クライアントが文書データそのものではなくURI参照("document-uri"操作属性)を供給しなければならないという点を除いて， Send-Document操作(3.3.1参照)と同一とする。Printerオブジェクトがこの操作をサポートする場合，既存の複数文書Jobオブジェクトに新たな文書を追加するために，クライアントはSend-URI操作又はSend-Document操作の両方を使用できる。しかし，クライアントが前回のSend-URI又はSend-Documentが最後の文書であったことを指示する必要がある場合，クライアントはSend-Document操作を，文書データがなく"last-document"フラグが 'true'に設定された状態で("document-uri"操作属性をもたないSend-URI操作を使用するのではなく)使用しなければならない。

Printerオブジェクトがこの操作をサポートする場合，Print-URI操作(3.2.2参照)もサポートしなければならない。

PrinterオブジェクトはPrint-URI操作の場合と同様に，供給されたURIの構文及びURI方式を，応答を返す前に検証しなければならない。IPP Printerは，操作の一部として又はそれに続くものとして，文書のアクセス可能性の妥当性検証を行ってもよい(3.2.2参照)。

この必す(須)操作は，ジョブが生成された時点から，それが完了，取消し又は中断される時点までの間で，クライアントがPrint Jobを取消すことを可能にする。Cancel-Jobを受信した時点でJobはすでに印刷されているかもしれないので，ジョブが実際に終了する前にメディアシートページが何枚か印刷されることもある。

IPPオブジェクトは，ジョブの現在の状態に基づいて要求を受理又は拒絶し，ジョブを次に示す新たな状態に移行させなければならない。

規則1　ジョブ状態が'processing'又は'processing-stopped'であるジョブを取消すのに，計測できる程度の時間を実装が要する場合，IPPオブジェクトはそのジョブの"job-state-reasons"属性に'processing-to-stop-point'値を加え，処理が終了した時にジョブを'canceled'状態に移行させなければならない(4.3.8参照)。

規則2　Jobオブジェクトが既に"job-state-reasons"属性に'processing-to-stop-point'値をもっていれば，Printerオブジェクトは Cancel-Job操作を拒絶しなければならない。

アクセス権について。この操作を行う認証済ユーザ(8.3参照)は，ジョブ所有者，操作者又はPrinterオブジェクトの管理者のいずれかでなければならない(1.及び8.5参照)。そうでない場合，IPPオブジェクトは操作を拒絶し，'client-error-forbidden', 'client-error-not-authenticated'又は'client-error-not-authorized'の適当なものを返さなければならない。

次の属性のグループはCancel-Job Requestの一部とする。

Group 1: Operation Attributes

Natural Language and Character Set

3.1.4.1に記述されている"attributes-charset"属性及び"attributes-natural-language"属性。

Target

3.1.5に記述するとおり，この操作の対象を定義する"printer-uri" (uri)と"job-id" (integer(1:MAX))との組，又は"job-uri" (uri)操作属性。

Requesting User Name

8.3で記述するとおり，"requesting-user-name" (name(MAX))属性をクライアントは供給した方がよい。

"message" (text(127))

クライアントはこの属性を供給してもよい。Printerオブジェクトはこの属性をサポートしてもよい。この属性は操作者へのメッセージとする。この"message"属性は"job-message-from-operator"属性とは異なる。"job-message-from-operator"属性は，操作者からその属性を要求した エンドユーザにメッセージを伝えるために使用する。この"message"操作属性は，クライアントから操作要求にしたがって操作者にメッセージを送信するのに使用する。操作者へのメッセージを表示するとすれば，どのようにどこに表示するかは実装が決定する。

次の属性の集合はCancel-Job Responseの一部とする。

Group 1: Operation Attributes

Status Message

すべての応答で返される必す(須)の状態コードに加えて，応答は附属書B及び3.1.6で記述する"status-message" (text)操作属性を含んでもよい。

Natural Language及びCharacter Set

3.1.4.2で記述する"attributes-charset"属性及び "attributes-natural-language"属性。

Group 2: Unsupported Attributes

Unsupported Attributeの戻し方に関する詳細は3.1.7参照。

一度成功応答が送信されれば，Jobは'canceled'状態に結局は至ることを実装は保証する。Cancel-Job操作が受理された時点から，ジョブが'canceled'ジョブ状態(4.3.7参照)に至るまでの間は，"job-state-reasons"属性が'processing-to-stop-point'値を含むことが望ましい。その値は後の問い合わせに対して，Jobは'processing'状態であるかもしれないが，結局は'completed'状態ではなく'canceled'状態に至ることを示す。

この必す(須)操作は，クライアントがJobオブジェクトの属性の値を要求することを許し，Get-Printer-Attributes操作(3.2.5参照)とほぼ同一とする。違いは，操作がPrinterオブジェクトではなくJobオブジェクトに向けられること，Jobオブジェクトに問合わせる時に"document-format"操作属性は使われないこと，及び返される属性グループはPrinterオブジェクトの属性の集合ではなく，Jobオブジェクトの属性の集合であるということになる。

Jobsの可能な属性グループの名前は次のとおりとする。

'job-template'

Jobオブジェクトに適用されるJob Template属性の部分集合(4.2の表10の最初の列)で，実装がJobオブジェクトにサポートするもの。

'job-description'

4.3で指定するJob Description属性の部分集合で，実装がJobオブジェクトにサポートするもの。

'all'

特別なグループ'all'は，実装がJobオブジェクトにサポートするす べての属性を含む。

クライアントは特定の属性又は名前付きグループを要求してもよいので，ある程度の重なりがある可能性がある。例えば，クライアントが'job-name'及び'job-description'を要求した場合，クライアントは，実際には"job-name"属性を，その名前によって明示的に一度要求し，'job-description'グループに含まれることによってもう一度要求することになる。この場合, Printerオブジェクトは，複数回要求された属性に対して，応答の中で返す属性を一つだけに絞る必要はない。クライアントは同一の属性を複数の方法で要求しないことが望ましい。

Jobオブジェクトは，グループに属する属性すべてをサポートする必要はない。これは，幾つかの属性はオプションであることによる。しかし，それぞれのJobオブジェクトは，グループ名すべてをサポートしなければならない。

要求がJobオブジェクトに向けられた場合，次の属性のグループは，Get-Job-Attributes Requestの一部とする。

Group 1: Operation Attributes

Natural Language及びCharacter Set

3.1.4.1に記述されている"attributes-charset"属性及び"attributes-natural-language"属性。

Target

3.1.5に記述するとおり，この操作の対象を定義する"printer-uri" (uri)と"job-id" (integer(1:MAX))との組，又は"job-uri" (uri)操作属性。

Requesting User Name

8.3で記述するとおり，"requesting-user-name" (name(MAX)) 属性を クライアントは供給した方がよい。

"requested-attributes" (1setOf keyword)

クライアントはこの属性を供給してもよい。IPPオブジェクトはこの属性をサポートしなければならない。この属性は，送信元が関心をもつ属性名及び/又は属性グループ名の集合とする。クライアントがこの属性を省略した場合，IPPオブジェクトは，'all'値をもつこの属性が供給されたものとして応答しなければならない。

Printerオブジェクトは，次の属性の集合をGet-Job-Attributes Responseの一部として返す。

Group 1: Operation Attributes

Status Message

すべての応答で返される必す(須)の状態コードに加えて，応答は，附属書B及び3.1.6で記述する"status-message" (text(255))及び/又は"detailed-status-message"(text(MAX))操作属性を含んでもよい。

Natural Language及びCharacter Set

3.1.4.2で記述する"attributes-charset"属性及び"attributes-natural-language"属性。"attributes-natural-language"は，要求された自然言語ではなくJobオブジェクトの自然言語でもよい。

Group 2: Unsupported Attributes

Unsupported Attributesの戻し方に関する詳細は3.1.7参照。
応答の"requested-attributes"操作属性の値として，クライアントが要求したがIPPオブジェクトはサポートしない値(属性keywords)を含む必要はない。Printerが"requested-attributes"で参照される未サポート属性を含み，その未サポート属性が'all'などのグループ名を含む場合，未サポート属性は, この規定で記述されているが実装でサポートされない属性を含んではならない。

Group 3: Job Object Attributes

これが要求された属性及びその現在の値の集合とする。IPPオブジェクトは，サポートしないか又は効力をもつセキュリティ方針で制限されている属性又は値を無視する(応答しない)。これは，要求したユーザがジョブを提出したユーザ(ジョブ開始ユーザ)であってもなくても無関係とする(8.参照)。しかしセキュリティ方針に違反しない限り，IPPオブジェクトはサポートしている任意の属性(すべての必す(須)属性を含む)の'unknown'値には応答しなけ ればならない。4.1の冒頭の"範囲外"("out-of-band")値の記述を参照すること。

このオプション操作によって，キューの中で待機中のジョブをクライアントが保留にし，スケジューリングの対象から外すことを可能にする。Hold-Job操作をサポートしている場合は，Release-Job操作もサポートしなければならない。Release-Job操作をサポートしている場合は，Hold-Job操作サポートしなければならない。オプションの"job-hold-until"操作属性をクライアントがサポートしている場合は，ジョブを不定期間保留するのか，指定した時間だけ保留するのかを指定できる。

IPPオブジェクトは，ジョブの現在の状態に基づいて要求を受理又は拒絶し，ジョブを表7に示す新たな状態に移行させなければならない。

規則1　ジョブが'pending-held'状態にいる複数の理由を実装がサポートしていれば，IPPオブジェクトはそのジョブの"job-state-reasons"属性に'job-hold-until-specified'値を加えなければならない。

規則2　IPPオブジェクトが"job-hold-until"操作属性をサポートしている場合，その値として指定された時間がすでに経過していて(又は'no-hold'値をもっていて)，そのジョブを保留する理由が他にないならば，IPPオブジェクトはそのジョブを'pending'状態に移して，処理の候補とすることを即座に行わなければならない(4.2.2参照)。

備考　Hold-Job操作を単純に保つために，ジョブが'processing'状態又は'processing-stopped'状態にある時には，ジョブ保留要求は拒絶される。これらの状態にある時にジョブ保留操作が必要とされる場合は，Hold-Job操作を再定義するのではなく，新たな操作として追加されるであろう。そうすればクライアントにとって，Printerオブジェクトの"operations-supported"属性(4.4.15参照)及びJobオブジェクトの"job-state"属性(4.3.7参照)を問い合わせることで，どの操作が可能なのかが明確になる。

アクセス権について。この操作を行う認証済ユーザ(8.3参照)は，ジョブ所有者，操作者又はPrinterオブジェクトの管理者のいずれかでなければならない(1.及び8.5参照)。そうでない場合，IPPオブジェクトは操作を拒絶し，'client-error-forbidden', 'client-error-not-authenticated'又は'client-error-not-authorized'の適当なものを返さなければならない。

グループ及び操作属性はCancel-Job要求(3.3.3.1参照)と同じであるが，次のGroup 1 Operation属性を追加する。

"job-hold-until" (type3 keyword | name(MAX))

クライアントはこのOperation属性を供給してもよい。IPPオブジェクトは，生成操作で"job-hold-until" Jobテンプレート属性をサポートする場合は， Hold-Job要求でこの操作属性をサポートしなければならない。4.2.2を参照のこと。IPPオブジェクトは，Hold-Job操作をサポートする場合は，ジョブ生成操作で少なくとも'indefinite'値を使用するために，"job-hold-until" Job Template属性をサポートすることが望ましい。そうでない場合は，クライアントは，ジョブを生成し即座にそれを保留する(値として使用できるサポートされている期間を選択することなく)ことができない。
Printerの"job-hold-until-supported"属性が供給及びサポートされている場合は，IPPオブジェクトは供給された操作属性をJobオブジェクトにコピーし，存在する場合には，ジョブの古い"job-hold-until"属性を置換し，供給された名前付き期間の間，ジョブをスケジューリングの候補とする。
"job-hold-until"属性が供給されても，"job-hold-until" Operation属性それ自体，又は供給された値がサポートされていない場合，IPPオブジェクトは要求を受理し，3.1.7に従ってUnsupported Attributes Groupの中にサポートしない属性又は値を返し，'successful-ok-ignored-or-substituted-attribute'を返し，クライアントが引き続きRelease-Job操作を行うまでジョブを不定期間保留する。
次が成立する場合，クライアントは，IPPオブジェクトは操作を受理し，ジョブを処理の候補に即座にしなければならない(4.2.2参照)。

a)	クライアントが，すでに経過している期間を指定した値又は'no-hold'値(ジョブを保留しないことを意味する。)を供給している。
b)	IPPオブジェクトが，"job-hold-until"操作属性をサポートし，ジョブを保留する他の理由がない。

クライアントが"job-hold-until" Operation属性を要求で供給しない場合，IPPオブジェクトは，'indefinite'値をもつ"job-hold-until"属性をジョブオブジェクトに与え(IPPオブジェクトが"job-hold-until"属性をサポートする場合は)，クライアントがRelease-Job操作を行うまでジョブを不定期間保留しなければならない。

グループ及び属性は，Cancel-Job応答(3.3.3.2参照)と同じとする。

このオプション操作によって，クライアントは以前に保留していたジョブを解放し，再びスケジューリングの対象にすることができる。Hold-Job操作がサポートされている場合は，Release-Job操作もサポートしなければならない。Release-Job操作がサポートされている場合は，Hold-Job操作もサポートしなければならない。

この操作は，生成操作又は直近のHold-Job若しくはRestart-Job操作で供給されたジョブオブジェクトに対して，"job-hold-until"ジョブ属性がもし存在すれば破棄し，ジョブに対するその影響を取り除く。

IPPオブジェクトはジョブの"job-state-reasons"属性がもし存在すれば，それから'job-hold-until-specified'値を破棄しなければならない。4.3.8を参照。

IPPオブジェクトは，ジョブの現在の状態に基づいて要求を受理又は拒絶し，ジョブを表8に示す新たな状態に移行させなければならない。

規則1　 'resources-are-not-ready'のとおり，ジョブを'pending-held'状態に留める他の理由があれば，ジョブは'pending-held'状態に留まる。したがって，'pending-held'状態は，'job-hold-until'が適用されたジョブに対してだけではなく，'resources-are-not-ready'のとおりジョブをスケジューリング及び処理の候補から外す任意の理由のためのものとする。"job-hold-until"属性(4.2.2)を参照のこと。

アクセス権について。この操作を行う認証済ユーザ(8.3参照)は，ジョブ所有者，操作者又はPrinterオブジェクトの管理者のいずれかでなければならない(1.及び8.5参照)。そうでない場合，IPPオブジェクトは操作を拒絶し，'client-error-forbidden', 'client-error-not-authenticated'又は'client-error-not-authorized' の適当なものを返さなければならない。

Release-Job Request及びRelease-Job Responseは，Cancel-Job操作(3.3.3.1及び3.3.3.2参照)と同じ属性グループ及び属性をもつ。

このオプション操作によって，処理が完了した後，キューに保管されていたジョブをクライアントが再始動できる(4.3.7.2参照)。

ジョブは'pending'ジョブ状態に移り，同じIPP Printerオブジェクトの上で同じ属性値で再始動する。ジョブにおけるあらゆる文書が参照によって渡された場合(Print-URI又はSend-URI)，Restart-JobのセマンティクスがすべてのJob処理を繰り返すほうがよいとしているので，Printerは，データを再取得しなければならない。"job-impressions-completed", "job-media-sheets-completed"及び"job-k-octets-processed"などのジョブの進行を計算するJob Description属性は0に再設定されるので，再始動の時点からジョブの正確な記録を与える。ジョブオブジェクトは同じ"job-uri"及び"job-id"属性値を使い続けなければならない。

備考　ジョブの進捗属性を再設定しない操作が将来もし必要になれば，ジョブの複製を作成し，その複製に新たな"job-uri"及び"job-id"を割り当て，複製のジョブの進捗属性だけを再設定する新たな操作が定義されるだろう。

IPPオブジェクトは，ジョブの現在の状態に基づいて要求を受諾又は拒絶し，ジョブを表9に示す新たな状態に移行させなければならない。

規則1　この状態のジョブのJob Retention Periodが満了している場合は，IPPオブジェクトは，操作を拒絶する。4.3.7.1を参照。

備考　ユーザが不注意に途中でジョブを再始動しないように，ジョブが'processing'状態又は'processing-stopped'状態にあるときは，Restart-Job要求は拒絶される。これらの状態にある時にジョブを保留又は再始動する操作が将来もし必要になれば，Restart-Job操作を再定義するのではなく，新たな操作が追加され，ユーザが現在のジョブを完了させない意図をもつことが明確にされるであろう。

アクセス権について。この操作を行う認証済ユーザ(8.3参照)は，ジョブ所有者，操作者又はPrinterオブジェクトの管理者のいずれかでなければならない(1.及び8.5参照)。そうでない場合，IPPオブジェクトは操作を拒絶し，'client-error-forbidden', 'client-error-not-authenticated'又は'client-error-not-authorized'の適当なものを返さなければならない。

グループ及び属性はCancel-Job要求(3.3.3.1参照)と同じとするが，次のGroup 1 Operation属性を追加する。

"job-hold-until" (type3 keyword | name(MAX))

クライアントはこの属性を供給してもよい。IPPオブジェクトは，生成操作で"job-hold-until" Job Template属性をサポートする場合は，Restart-Job要求でこのOperation属性をサポートしなければならない。4.2.2を参照のこと。そうでない場合には，IPPオブジェクトは，Restart-Job要求で"job-hold-until" Operation属性をサポートする必要はない。

Printerの"job-hold-until-supported"属性が供給及びサポートされている場合は，IPPオブジェクトは供給された操作属性をJobオブジェクトにコピーし，存在する場合には，ジョブの古い"job-hold-until"属性を置換し，供給された名前付き期間の間，ジョブをスケジューリングの候補とする。4.2.2を参照。

"job-hold-until"属性が供給されても，供給された値がサポートされていない場合，IPPオブジェクトは要求を受理し，3.1.7に従ってUnsupported Attributes Groupの中にサポートしない属性又は値を返し，'successful-ok-ignored-or-substituted-attribute'状態コードを返し，クライアントが引き続きRelease-Job操作を行うまでジョブを不定期間保留する。

"job-hold-until"属性が供給されても，"job-hold-until" Operation属性そのものがサポートされていない場合，IPPオブジェクトは要求を受理し，3.1.7に従って，Unsupported Attributes Groupの中で範囲外の'unsupported'値を返し，'successful-ok-ignored-or-substituted-attribute'状態コードを返し，ジョブを再始動する。つまり，"job-hold-until"属性を無視する。

次が成立する場合，IPPオブジェクトはジョブを即座に処理の候補にする(4.2.2参照)。

a)	クライアントが，すでに開始している期間を指定した値，又は'no-hold'値(ジョブを保留しないことを意味する)を供給している。
b)	IPPオブジェクトが"job-hold-until"操作属性をサポートし，ジョブを保留する他の理由がない。

クライアントが"job-hold-until"操作属性を要求で供給しない場合，IPPオブジェクトは，"job-hold-until"属性が存在する場合にはジョブから除去する。ジョブを保留する他の理由がない場合には，Restart-Job操作がジョブを即座に処理の候補にする(4.2.2参照)。

グループ及び属性は，Cancel-Job応答(3.3.3.2参照)と同じとする。

備考　将来，オプションのModify-Job操作が指定され，再始動したジョブを起動する前に他の属性をクライアントが修正可能になるかもしれない。

IPPモデルの一部である属性を対応する属性構文及び値と共に4.で定義する。オブジェクト及びそれに関連する，このプロトコルの適用範囲に含まれる属性を4.で規定する。これらの属性の多くは，他の関連する規定に由来する。

• Document Printing Application (DPA) [ISO10175]
• RFC1759 Printer MIB [RFC1759]

この文書では，それぞれの属性は，属性の名前である"keyword"(附属書A.2.1参照)を用いて一意に特定する。キーワードはその属性を記述する節の見出しに含まれる。

備考　キーワードは属性を特定するために使われるだけでなく，次に記述する属性構文の一つが"keyword"であって，キーワード値をもつ属性は幾つか存在する。したがって，これらの属性はキーワードの集合である属性構文をもつと定義される。

すべてのクライアント及びIPPオブジェクトがそれぞれ応答中及び要求中で受理しなければならない基本属性構文型を4.1で定義する。3.及び3.3.5のそれぞれの属性記述は，見出しに(括弧で括って)属性構文の名前を含む。属性の適合実装は，属性構文のセマンティクスを指定どおりに含まなければならない。6.3では新たな属性構文でプロトコルを拡張する方法を記述する。

属性構文は4.1の箇条で，属性構文のキーワード名を単一引用符で囲んだものを見出しとして規定する。操作要求及び応答でそれぞれの属性値は，その属性に対する箇条の見出しで指定された属性構文の一つとして表現しなければならない。さらに応答中の属性値(要求中ではない。)は，特別な符合化規則が"符号化及びトランスポート"規定[RFC2910]で定義された，"範囲外"("out-of-band")の値の一つでもよい。標準的な範囲外の値を次に示す。

'unknown'

その属性はIPPオブジェクトがサポートしているが，何らかの理由でその値がわからない。

'unsupported'

その属性はIPPオブジェクトがサポートしていない。この値は，Unsupported Attributes Groupの属性の値だけとして返すことができる。

'no-value'

その属性はPrinterオブジェクトがサポートしているが，管理者がまだ値を設定していない。

要求中の属性はすべて，4.2〜4.4で定義する一つ以上の値をもたなければならない。クライアントは"out-of-band"値を属性に供給してはならない。応答中の属性はすべて，4.2〜4.4で定義する一つ以上の値，又は単一の"out-of-band"値をもたなければならない。

大部分の属性は単一の属性構文をもつ。しかし，少数の属性(例えば，"job-sheet", "media", "job-hold-until"など)は，値に依存する幾つかの属性構文をもつ。これら複数の属性構文は，選択を示すために箇条の見出しの中で"|"文字で区切られている。それぞれの値は，このプロトコルの属性構文に従ってタグ付けしなければならないので，単一値の属性インスタンスはその可能な属性構文の任意の一つをもってよいし，複数値の属性インスタンスはその可能な属性構文の混合をもってもよい。

テキスト属性とは，最大で1023('MAX')オクテットに符号化された0個以上の文字の列を値としてもつ属性とする。MAXは任意のテキスト属性のそれぞれの値の最大長とする。しかしある属性が，MAXより大幅に短い長さの値しか含まない場合は，その属性の値の最大長を定義する修飾子を含んでもよい。例えば，"printer-location"属性が"printer-location(text(127))"と定義される。この場合，"printer-location"のテキスト値は127オクテットを超えてはならない。外部インタフェースから(すなわち，プロトコル以外から)より長いテキスト列が供給された場合，実装はテキスト列をこの長さの上限値に切り詰めてよい。

この規定では，テキスト属性はすべて'text'構文を使って定義する。しかし 'text'は単に簡潔さのためだけに使う。'text'の公式な解釈は'textWithoutLanguage | textWithLanguage'とする。'text'属性構文を用いてこの規定で定義されている任意の属性のために，すべてのIPPオブジェクト及びクライアントは'textWithoutLanguage'及び'textWithLanguage'属性構文の両方をサポートしなければならない。しかし実際の使用及びプロトコルの実行では，オブジェクト及びクライアントは一つの属性につき二つの構文のうちの一方だけを受理及び返信する。構文'text'は"on-the-wire"には決して出現しない。

'textWithoutLanguage' 及び 'textWithLanguage' は両方とも，人のコミュニケーションの基盤として，異なった自然言語を用いているサイト及びシステムの間での相互運用性を実際に確保したいという要求をサポートするために必要である。一般に，ある一つの要求又は応答中のすべてのテキスト属性で一つの資源言語が使われる。その言語は，3.1.4の"attributes-natural-language"操作属性，又は4.3.18で定義する"attributes-natural-language"ジョブ属性で指示される。値に値をという原則でそれぞれのテキスト列で自然言語を特定する必要はない。これらの場合，属性構文'textWithoutLanguage'がテキスト属性に使用される。他の場合，要求または応答中で残りのテキスト値とは異なる自然言語によるテキスト値をクライアントが供給するか，又はPrinterオブジェクトが返す必要がある。この場合，クライアント又はPrinterオブジェクトは属性構文'textWithLanguage'をテキスト属性に使用する(これは3.1.4で記述するNatural Language Override機構である。)。

'textWithoutLanguage' 及び 'textWithLanguage' 属性構文は以下の節でより詳しく記述する。

'textWithoutLanguage'構文は，0個以上の文字の列である値を指す。テキスト列は幾つかのcharsetの規則を用いて符号化される。PrinterオブジェクトはUTF-8 charset[RFC2279]をサポートする必要があって，IANA[IANA-CS]に登録されていれば他のcharsetも'text'値を表現するためにサポートしてよい。'charset'属性構文の規定(制限されたセマンティクス及びcharsetの例を含む)は4.1.7を参照のこと。

'textWithLanguage'属性構文は，次の二つの部分からなる複合属性構文とする。一つは'textWithoutLanguage'部で，もう一つは自然言語を強制的に上書きする付加的な'naturalLanguage'(4.1.8参照)部とする。'naturalLanguage'部は値のテキスト部分だけに適用される。任意のテキスト属性について，'textWithoutLanguage'部はその属性に定義された最大長に限定されるが，'naturalLanguage'部は常に63オクテットに限定される。通常の'textWithoutLanguage'構文ではなく'textWithLanguage'属性構文を使うことはNatural Language Override機構と呼ばれ，すべてのIPPオブジェクト及びクライアントがサポートしなければならない。

属性が複数値(1setOf text)の場合は，自然言語を上書きする必要のある属性値それぞれに対して，'textWithLanguage'属性構文を使用しなければならない。要求又は応答中の複数値の'text'属性の他の値は，操作属性の自然言語になる。

生成要求では，Printerオブジェクトは， "attributes-natural-language"操作属性の任意の自然言語(Printerオブジェクトがその自然言語をサポートしていてもいなくても)を受理しJobオブジェクトに保存しなければならない。さらにPrinterオブジェクトは，任意の'textWithLanguage'属性値を，Printerオブジェクトがその自然言語をサポートしていてもいなくても受理及び保存しなければならない。これらの要求事項は，クライアントが適用してもよい"ipp-attribute-fidelity"操作属性の値とは独立とする。

例　 クライアントが"attributes-natural-language"操作属性に'en'値を供給して英語を指示しても，"job-name"属性の値がフランス語である場合は，クライアントは'textWithLanguage'属性構文に次の二つの値を使用しなければならない。

'fr'

フランス語を指示するNatural Language Override

'Rapport Mensuel'

フランス語でのジョブ名

'textWithLanguage'属性構文の詳細な例は，"符号化及びトランスポート"文書[RFC2910]の附属書A，二つの部分の符号化に関しては，3.9を参照すること。

この構文型は，例えばPrinter名のように，人にとって識別子より意味があるユーザになじみの深い文字列に使われる。名前は他の自然言語には決して翻訳されない。'name'属性構文は本質的には'text'と同じで，UTF-8のサポートも必須とする。ただし'name'では，符号化された形式で255 (MAX)オクテットを超えてはならないという点が異なる。

'text'と同様に，'name'も実際には'nameWithoutLanguage'又は'nameWithLanguage'を指す省略記法とする。つまりすべてのIPPオブジェクト及びクライアントは，'nameWithoutLanguage'及び'nameWithLanguage'属性構文をサポートしなければならない。しかし実際の使用及びプロトコルの実行では，オブジェクト及びクライアントは一つの属性につき二つの構文のうちの一方だけを受理及び返信する。構文'name'は"on-the-wire"には決して出現しない。

'text' 及び 'name' 属性構文だけが Natural Language Override機構を許す。

幾つかの属性は'type3 keyword | name'と定義される。これらの属性はtype3 keyword又はnameのいずれかの値をサポートする。この二重構文機構は，サイト管理者がこれらの属性を拡張して，サイト管理者がローカルに定義した値を合法的に含めることを可能にする。この名前は, IANAには登録されない。

'nameWithoutLanguage'構文は，最大長255(MAX)オクテットで符号化されて0個以上の文字の列である値を指す。

'nameWithLanguage'属性構文は，次の二つの部分からなる複合属性構文とする。一つは最大長1023(MAX)オクテットで符号化された'nameWithoutLanguage'部で，もう一つは自然言語を強制的に上書きする付加的な'naturalLanguage'(4.1.8参照)部とする。'naturalLanguage'部はname値だけに適用される自然言語を明示的に特定する。すべての与えられたテキスト属性に対して，'textWithoutLanguage'の部分は，その'text'属性のために定義された最大長に制限され，'naturalLanguage'の部分は，常に，(付加的な)63オクテットに制限される。通常の'textWithoutLanguage'構文ではなく'textWithLanguage'属性構文を使うことは，いわゆる自然言語上書き(Natural Language Override)機構であって，すべてのIPPオブジェクト及びクライアントにサポートされなければならない。

'nameWithLanguage'属性構文は'textWithLanguage'構文と同様に振る舞う。通常の'textWithoutLanguage'構文ではなく'textWithLanguage'属性構文を使うことは，いわゆる自然言語上書き(Natural Language Override)機構であって，すべてのIPPオブジェクト及びクライアントによってサポートされなければならない。名前がオブジェクト又は操作の他の部分と異なる言語で表現されている場合，共通の'nameWithoutLanguage'構文ではなく'nameWithLanguage'構文を用いる。

属性が複数の値(1set0f text)の場合，自然言語が上書きされることが必要となる各属性値を明示的に指定するために，'nameWithLanguage'属性構文が使用されなければならない。

要求又は応答における複数値の'name'属性の他の値は，操作属性の自然言語に帰属する。

生成要求において，Printerオブジェクトは，"attributes-natural-Language"操作属性のあらゆる自然言語を，その自然言語をサポートするかどうかにかかわらず，Jobオブジェクトとともに受諾し格納しなければならない。さらに，Printerオブジェクトは，あらゆる'nameWithLanguage'属性値を，その自然言語をサポートするかどうかにかかわらず，受諾し格納しなければならない。これらの要件は，クライアントが供給してもよい"ipp-attribute-fidelity"操作属性の値に独立とする。

例　 クライアントが"attributes-natural-language"操作属性に'en'値を供給して英語を指示しても，"printer-name"属性の値がドイツ語である場合には，クライアントは'nameWithLanguage'属性構文を次のとおりに使用しなければならない。

'de'

ドイツ語を示すNatural Language Override

'Farbdrucker'

ドイツ語でのPrinter名

二つの部分の符号化に関しては，"符号化及びトランスポート"規定[RFC2910]の3.9を，'namehLanguage'属性構文の詳細な例に関しては，附属書Aを参照すること。

ジョブ検証(クライアントが属性"xxx"に供給した値が，Printerオブジェクトの対応する属性"xxx-supported"の値の一つであるか調べること)のとおりに，二つの'name'属性値がマッチするかどうかを調べるには，次のマッチ規則を適用する。

'keyword'属性構文は文字の列で，長さは1から255の間，US-ASCII[ASCII]で符号化された小文字("a" - "z")，数字("0" - "9")，ハイフン("-")，ドット(".")，及び下線("_")だけを含むものとする。最初の文字は小文字でなければならない。さらに，キーワードはアメリカ英語でなければならない。

この構文型は，抽象プロトコルの中の実体，つまりこの規定で特定される実体のセマンティクス的な識別子を列挙するのに使う。キーワードは属性名及び属性の値として使用する。'text'及び'name'属性値とは異なり，'keyword'値は常にUS-ASCII及びアメリカ英語を使わなければならないので，Natural Language Override機構を使ってはならない。

キーワードはプロトコルで使われる。ユーザインタフェースが，プロトコルのキーワードと，ユーザになじみの深い単語や句(ユーザの自然言語で表現される)との変換を行なうことになるであろう。ユーザインタフェースはこの文書の適用範囲外なので，この文書で指定したキーワードをアメリカ英語を使用するユーザに表示してもよいし，アメリカ英語の他の単語に変換してもよい。

この構文型のそれぞれの属性の定義で，その属性に対して定義されたキーワード値がすべて列挙される。

キーワードが属性(の名前)を表現するために使われるとき，そのキーワードはすべてのIPPオブジェクト及び属性のなかで一意でなければならない。キーワードが属性の値を表現するために使われるとき，そのキーワードはその属性の中で一意でなければならない。つまり，一つの属性の中で，二つの異なった意味を表現するために同じキーワードを二つの値として使ってはならない。しかし，二つ以上の属性にまたがって，それぞれの属性で別の意味を表現するために同じキーワードを使ってもよい。6.1で，新たなキーワード値でプロトコルを拡張する方法を記述する。属性名キーワードの例を次に示す。

• "job-name"
• "attributes-charset"

備考　この規定では，"type1"，"type2"及び"type3"の接頭辞を"keyword"基本構文に付けて，拡張のためのレビューの異なる水準を示めす(6.1参照)。

'enum' 属性構文は，1〜2**31-1(MAX)の範囲にある列挙型整数値とする。各値は，関連する'keyword'名をもつ。この構文型の各属性の定義に，その属性のための可能な値の完全な集合がリストされる。この構文型は，SNMP MIBなどの他の規定によって割り当てられた列挙値のための属性に使用され，この規定のかなりの属性列挙値は，他の規定[RFC1759]の対応する属性にも使用されている。この構文型は，管理者が値を割り当ててよい属性には使用されない。6.1では，いかにプロトコルが新しい列挙値にて拡張されるかを記述する。

列挙値は，プロトコルで使用する。ユーザインタフェースは，プロトコルの列挙値とユーザの自然言語に現地対応された表示可能なユーザに親和性のある単語及び語句との対応付けを提供する。この規定で指定される列挙シンボルは，自然言語がアメリカ英語であるユーザに表示されてよいが，ユーザインタフェースはこの規定の適用範囲外であるので，アメリカ英語ユーザのために他のアメリカ英単語にマップされてもよい。

備考1　SNMP MIBは，IPPの"out-of-band"値の'unknown'に対応する'2'を'unknown'に使用する。4.1の冒頭の"out-of-band"値の記述を参照。それゆえ，型'enum'の属性は'3'から始まる。

備考2　この規定は，拡張のための異なるレベルの審議を示すために，"enum"の基本構文に"type1"，"type2"及び"type3"の接頭辞を使用する(6.1参照)。

'uri'の属性構文は，何か有効なUniform Resource Identifier又はURI[RFC2396]とする。たいていの場合，URIは単にUniform Resource Locator 又はURLとする。IPP属性の値として使われるURIの最大長は，1023オクテットとする。ほとんどのIPP属性の構文型は，小文字の値だけ使用できる，この属性の構文型は，[RFC2396]で指定する大文字・小文字を区別する規則及び大文字・小文字を区別しない規則に適合する。URIに関しては，[IPP-IIG]参照。

'uriScheme'の属性構文は，RFC2396[RFC2396]に従って， URI方式を示す文字の列とする。RFC2396は，値は大文字・小文字を区別しないことを要求しているが，IPPは，IPPクライアント及びPrinterオブジェクトによって，比較することを単純化するために，すべての小文字による値をIPP属性に要求している。この構文型の標準値は，次のキーワードとする。

'http'

HTTP方式のURIため(例えば，"http:...")

'https'

HTTPS方式のURIでの使用のため(例えば，"https:...") (IETF規定トラックにない。)

'ftp'

FTP方式のURIのため(例えば, "ftp:...")

'mailto'

SMTP方式のURIのため(例えば, "mailto:...")

'file'

ファイル方式のURIのため(例えば, "file:...")

Printerオブジェクトは，IANA [IANA-MT]に登録されているどんなURI 'scheme'をもサポートしてよい。 IPP属性値を示すのに使用されるURI 'scheme'値の最大長は，63オクテットとする。

'charset'の属性構文は，charsetの標準識別子とする。charsetとは,符号化された文字集合及び符号化方式とする。charsetは，ある特定の文書の内容並びに'text'及び'name'の属性値にラベル付けするに使用される。この属性構文の構文及びセマンティックスはRFC2046[RFC2046]で記述され，IANA手順[RFC2278]に従って，IANA character-set Registry[IANA-CS]に含まれる。 RFC2046は,値が大文字・小文字を区別しないUS-ASCIIであることを要求しているが，IPPは，IPPクライアント及びPrinterオブジェクトによって，比較することを単純化するために，すべての小文字による値をIPP属性に要求している。IPPはIANAレジストリ内の文字集合が一つより多くの名前(別名)をもつ場合，"(preferred MIME name)"とラベルされた名前が存在する場合，その名前を使用しなければならない。

IPP属性を示すのに使用する'charset'値の最大長は，63オクテットとする。

例

'utf-8'

US-ASCIIが, 部分集合CharsetのUTF-8[RFC2279]伝送符号化方式として示されるISO 10646 Universal Multiple-Octet Coded Character Set (UCS)。

'us-ascii'

情報交換のための7ビット米国規格符号(ASCII), ANSI X3.4-1986[ASCII]。その規格は, US-ASCIIを定義するが，RFC2045[RFC2045]はMIME及びIPPでの適合性使用からたいていの制御文字を削除している。

'iso-8859-1'

8ビットのOne-Byte Coded Character Set，Latin Alphabet Nr 1 [ISO8859-1]。その規格は，西半球及び西ヨーロッパのラテン言語によって使用されている符号化文字集合を定義している。US-ASCIIは，部分集合のcharsetとする。

幾つかの属性の記述は，使用されるかもしれないcharset値に，サポートされなくてはならない必す(須)の値，又はcharsetがUS-ASCIIを部分集合charsetにする条件などの追加制限を加わえてもよい。

'naturalLanguage'の属性構文は，自然言語，及びオプションとして国の標準識別子である。この構文型の値は，RFC1766[RFC1766]によって定義されている。RFC1766は，値が大文字・小文字を区別しないUS-ASCIIであることを要求しているが，IPPは，IPPクライアント及びPrinterオブジェクトによって，比較することを単純化するために，すべての小文字による値をIPP属性に要求している。

例

'en'

英語

'en-us'

アメリカ英語

'fr'

フランス語

'de'

ドイツ語

IPP属性を示すに使用する'naturalLanguage'値の最大長は，63オクテットとする。

'mimeMediaType'の属性構文は，RFC2046[RFC2046]で定義されるInternet Media Type (MIME型ともいう)であり，文書フォーマットを識別するRFC2048[RFC2048]の手順に従って登録されている。値は，IANA Registry[IANA-MT]のMedia Typeの仕様によって，charsetパラメタを含んでもよい。ほとんどの他のIPP構文型は小文字の値だけ認められているが，この構文型は大文字・小文字を区別しない大文字・小文字混在の値を認めている。

例

'text/html'

HTML文書

'text/plain'

US-ASCIIのプレーンテキスト文書(RFC2046は，charsetパラメタが存在しない場合，単に指定されていないというよりUS-ASCIIを意味しなければならないということを記述している)[RFC2046]。

'text/plain; charset=US-ASCII'

US-ASCIIのプレインテキスト文書[52, 56]

'text/plain; charset=ISO-8859-1'

ISO 8859-1 (Latin 1) [ISO8859-1]のテキスト文書。

'text/plain; charset=utf-8'

UTF-8[RFC2279]として示すISO 10646のプレインテキスト文書。

'application/postscript'

PostScript文書[RFC2046]

'application/vnd.hp-PCL'

PCL文書[IANA-MT](文書データに組み込まれたcharsetエスケープシーケンス)

'application/pdf'

Portable Document Format - IANA MIME Media Type レジストリ参照

'application/octet-stream'

自動検知 - 次を参照。

IPP属性値を表現する'mimeMediaType'値の最大長は，255オクテットとする。

'dateTime'の属性構文は，RFC1903[RFC1903]で定義する"DateAndTime"構文の規定で固定長の11オクテットの表現とする。 RFC1903は，"DateAndTime"値の8オクテット表現をも識別するが，IPPオブジェクトは，11オクテット表現を使用しなければならない。ユーザインタフェースは，プロトコルのdateTime値と，タイムゾーンを含むユーザのデータフォーマット及び自然言語に現地対応化された表示可能なユーザ親和性のある単語又は提示値及び語句との間の対応付けを提供する。

'resolution'の属性構文は，表示ユニットでの2次元の解像度を指定する。これは，三つの値から構成される：主走査方向の解像度(正の整数値)，副走査方向の解像度(正の整数値)，及びユニットの値。この三つの構成要素のセマンティクスは，Printer MIB[RFC1759]の推奨値から引用される。すなわち，主走査方向の解像度構成要素は，Printer MIBのprtMarkerAddressabilityXFeedDirオブジェクトと同じであって，副走査方向の構成要素は，Printer MIBのprtMarkerAddressabilityFeedDirと同じで，ユニットの構成要素は，Printer MIBのprtMarkerAddressabilityUnitオブジェクトと同じとする('3'はインチあたりのドット数，'4'はセンチメートル当りのドット数を示す。)。すべての三つの値は，最初の二つの値が同じであるとしても，示されなければならない。例えば，'300', '600', '3' は，'3'はインチ当りのドット数(dpi)を示すので，300dpiは主走査方向の解像度，600dpiは副走査方向の解像度となる。

'1setOf X'属性構文は，属性構文型Xの一つ以上の値とする。この構文型は，多重値属性のために使用する。構文型の名称は，単に'setOf'ではなくて，むしろ'1setOf'とする。これは，値の集合が，空(すなわち，大きさ0の集合)であってはならないことを示すためとする。集合は，通常は順序付けられでいない。しかし，この型の各属性記述は，その値がその属性に対する特定の順序をもっていなければならないことを指定するかもしれない。

Job Template属性は，ジョブ処理の振る舞いを記述する。PrinterオブジェクトによるJob Template属性のサポートは，オプションとする。(オプション属性に対するサポートの記述は，附属書A.2.3を参照。) クライアントは，生成要求におけるJob Template属性をオプションとして供給する。

Job Template属性は，"xxx"と呼ぶ各Job Template属性に対して，次の規則に適合する。

アプリケーションが，そこから選択するサポート済み値のリストを末端ユーザに提供しようとする場合，サポート済み値属性に対してPrinterオブジェクトに問い合わせることが望ましい。アプリケーションは，デフォルト値属性も問い合わせるほうがよい。アプリケーションが選択可能な値をサポート済み値だけに制限する場合，生成要求の中でクライアントが供給する値がすべて，Printerにおいてサポート済み値の集合内に入ることを，アプリケーションは保証できる。Printerに問い合わせる場合，クライアントは，Get-Printer-Attributes要求の中で名前によって各属性を列挙してもよいし，単に，サポート済み属性の完全な集合(サポート済み属性及びデフォルト属性の両方)を得るために，"job-template"グループに名前を付けてもよい。

"finishings"属性は，Job Template属性の例とする。これは，'staple'，'punch'及び/又は'cover'の値の集合上で値を取ることができる。クライアントは，"finishings-supported"属性及び"finishings-default"属性についてPrinterオブジェクトに問合せできる。サポート済み属性は，サポート済み値の集合を含む。クライアントが生成要求において"finishings"属性を供給せず，文書が対応する仕上げ命令を含まない場合，デフォルト値属性は，新しいJobのために使用する仕上げ値を含む。クライアントが生成要求において"finishings"属性を供給する場合，IPPオブジェクトは，その値の有効性を確認し，その値が，Printerオブジェクトの"finishings-supported"属性で識別されるサポート済み値の部分集合となることを確実にする。3.1.7を参照。

表10に，Job Template属性に対する名前及び関係を示す。("Job属性"とラベル付けされた)表の最初の欄は，Jobオブジェクトにおける各Job Template属性に対する名前及び構文を示す。これらは，生成要求においてクライアントがオプションで供給可能な属性とする。("Printer: デフォルト値属性"及び"Printer: サポート済み値属性"とラベル付けされた)残りの二つの欄は，Printerオブジェクトにおける各Job Template属性(デフォルト値属性及びサポート済み値属性)に対する名前及び構文を示す。表における"No"は，Printerがその属性をサポートしてはならないこと(すなわち，その属性は単に適用可能ではないこと)を意味する。簡単のために，表10では，'text'及び'name'のエントリは，各属性に対する最大長を示さない。

この属性は，Jobをスケジュールするための優先度を指定する。大きな値ほど高い優先度を指定する。値1は，可能な最低の優先度を示す。値100は，可能な最高の優先度を示す。印刷の準備ができているジョブにおいて，Printerは，すべてのnに対して，n-1の優先度をもつジョブを印刷する前に，nの優先度をもつジョブをすべて印刷しなければならない。

Printerオブジェクトがこの属性をサポートする場合，常に，1〜100のすべての領域をサポートしなければならない。管理上の制限は認めない。これによって，末端ユーザは，常に，あらゆるPrinterオブジェクトに対して全領域をすべて使用可能となる。特権的なジョブをIPP/1.1の外部で実装する場合は，末端ユーザが利用可能な領域を制限するのではなく，そのジョブに100よりも高い優先度を与えなければならない。

クライアントがこの属性を供給せず，Printerオブジェクトがこの属性をサポートしない場合，Printerオブジェクトは，(必要ならばジョブ処理時に使用する大部分のJob Template属性とは違い，)ジョブ処理時にPrinterオブジェクトの"job-priority-default"の値を使用してはならない。

"job-priority-supported"の構文も，integer(1:100)とする。この単一の整数値は，サポートする優先度水準の個数を示す。Printerオブジェクトは，クライアントが供給する値を取り，それを，次の公式を使って，1〜100の領域上に等分に分布するn個の整数値の並びの中の最も近い整数に対応付けなければならない。

     roundToNearestInt((100x+50)/n)

例を次に示す。

• n=1の場合，値の並びは，50。
• n=2の場合，値の並びは，25及び75。
• n=3の場合，値の並びは，17，50及び83。
• n=10の場合，値の並びは，5，15，25，45，55，65，75，85及び95。
• n=100の場合，値の並びは，1，2，3，...，100。

Printerオブジェクトの"job-priority-supported"の値が10であって，クライアントが領域1〜10の中の値を供給した場合は，Printerオブジェクトはそれを5に，クライアントが領域11〜20の中の値を供給した場合は，Printerオブジェクトはそれを15に，対応付ける。

この属性は，Jobが印刷対象の候補となる予定の名前付き時間区分を指定する。

名前付き時間区分に対する標準のキーワードの値は，次による。

'no-hold'

ジョブを保持する他の理由が存在しない場合は，直ちに印刷する。

'indefinite'

クライアントがRelease-Job(3.3.6参照)を実行するまで，ジョブをいつまでも保持する。

'day-time'

昼間。

'evening'

夕刻。

'night'

夜。

'weekend'

週末。

'second-shift'

交代制の遅番時。(通常業務終了後のこと。)

'third-shift'

交代制の明け番時。(真夜中以降のこと。)

管理者は，(このIPP/1.1規定の適用範囲以外の方法で，)可能な印刷時間を名前付き時間区分に関連付けなければならない。管理者には，時間区分の型を示唆する名前を採用することが望まれる。管理者は，実装に依存して，'name'属性又は'keyword'属性の構文を使用した付加的な値を定義してもよい。

この属性の値が将来における時間区分を指定する場合，Printerは，'job-hold-until-specified'値をジョブの"job-state-reasons"属性に追加することが望ましく，そのジョブを'pending-held'状態に移動しなければならず，指定した時間区分になるまで，そのジョブを印刷のためにスケジュールしてはならない。指定した時間区分になった場合は，Printerは，存在すれば，ジョブの"job-state-reason"属性から'job-hold-until-specified'値を取り除かなければならない。そのジョブを'pending-held'状態に保持しておく他のジョブ状態理由が存在しない場合には，Printerは，そのジョブを'pending'状態に移動することによって，処理候補とみなさなければならない。

このジョブ属性値が名前付きの値'no-hold'であるか，又は指定した時間区分が既に開始している場合には，そのジョブは直ちに処理をする候補としなければならない。

クライアントがこの属性を供給せず，Printerオブジェクトがこの属性をサポートしている場合には，Printerオブジェクトは，(必要に応じてジョブ処理時に使用する大部分のJob Template属性とは違って，)Printerオブジェクトの"job-hold-until-default"の値をジョブ処理時に使用しなければならない。

この属性は，ジョブ開始シート及び/又はジョブ仕上げシートが存在する場合に，それらのどれをジョブと共に印刷するかを決定する。

標準のキーワード値は，次による。

'none'

ジョブシートを印刷しない。

'standard'

一つ以上のサイト固有の標準ジョブシートを印刷する。例えば，開始シートを一枚，又は開始シート及び仕上げシートの両方を印刷する。

管理者は，実装に依存して，'name'属性又は'keyword'属性の構文を使用した付加的な値を定義してもよい。

複数文書をもつジョブのに関するこの属性の効果は，ジョブシートのセマンティクスに依存して，"multiple-document-handling"ジョブ属性(4.2.4参照)による影響を受けてもよい。

この属性は，ジョブが二つ以上の文書から構成される場合に有効となる。Printerがジョブごとに複数の文書をサポートする場合(3.2.4及び3.3.1参照)に，この属性を少なくとも一つの値でサポートしなければならない。属性は，仕上げ操作，並びに複数の印刷ストリームページの刷り及びメディアシートへの配置を制御する。"copies"属性の値が1を超える場合，文書処理から生じる印刷部数を生成する順番も制御する。ここでの規定のために，次の記法を使用する。すなわち，"a"で文書データのインスタンスを表現する場合，文書中のそのデータ"a"の処理結果を，"a(*)"で表現するメディアシートの列とする。

標準のキーワード値は，次による。

'single-document'

Jobオブジェクトが，例えばその文書データをa及びbと呼ぶ複数の文書をもつ場合，その文書データ(a及びその次にb)を処理した結果は，仕上げ操作に対して，メディアシートの一つの列として取り扱わなければならない。すなわち，仕上げは，列a(*)及びb(*)の連結上で実行される。Printerオブジェクトは，各文書インスタンスにおけるデータに，新しい印刷ストリームページへのフォーマット化も新しいメディアシート上での新しい刷りの開始も強制してはならない。部数を2部以上作成する場合，その文書の処理結果から生じるメディアシートの集合の順番は，a(*), b(*), a(*), b(*), ...でなければならず，Printerオブジェクトは，各コピー(a(*),b(*))に，新しいメディアシート上での開始を強制しなければならない。

'separate-documents-uncollated-copies'

Jobオブジェクトが，例えばその文書データをa及びbと呼ぶ複数の文書をもつ場合，各文書インスタンスにおけるデータを処理した結果は，仕上げ操作に対して，メディアシートの一つの列として取り扱わなければならない。すなわち，集合a(*)及びb(*)は，それぞれ，別々に仕上げする。Printerオブジェクトは，一つの文書におけるデータの処理結果の各コピーに，新しいメディアシート上での開始を強制しなければならない。部数を2部以上作成する場合，文書データの処理結果から生じるメディアシートの集合の順番は，a(*), a(*), ..., b(*), b(*), ...でなければならない。

'separate-documents-collated-copies'

Jobオブジェクトが，例えばその文書データをa及びbと呼ぶ複数の文書をもつ場合，各文書インスタンスにおけるデータの処理結果は，仕上げ操作に対して，メディアシートの一つの列として取り扱わなければならない。すなわち，集合a(*)及びb(*)は，それぞれ，別々に仕上げする。Printerオブジェクトは，一つの文書におけるデータの処理結果から生じる各コピーに，新しいメディアシート上での開始を強制しなければならない。部数を2部以上作成する場合，文書データの処理結果から生じるメディアシートの集合の順番は，a(*), b(*), a(*), b(*), ...でなければならない。

'single-document-new-sheet'

Printerオブジェクトが，ジョブの中の各文書インスタンスの最初の刷りを確実に新しいメディアシートに置くこと以外は，'single-document'と同じ。この値によって，複数の文書を，各文書が新しいシート上で開始する個所でステープル止めすることを可能にする。

'single-document'値は，印刷ストリームページに関して 'separate-documents-collated-copies'と同じだが，メディア生成に関しては同じではない。これは次による。すなわち，'single-document'は，ジョブに対して一つの文書の印刷ページが奇数となる場合，次の文書の最初のページをシートの裏面に置くが，'single-document-new-sheet'は，常に，次の文書又は文書コピーを新しいシート上に強制的に置く。さらに，"finishings"属性が'staple'を指定する場合，'single-document'では，新しいシートを考慮しないので，文書a及びbを一つの文書としていっしょにステープル止めし，'single-document-new-sheet'では，文書a及びbを，文書bを新しいシート上で開始して，一つの文書としていっしょにステープル止めするが，'separate-documents-uncollated-copies'及び'separate-documents-collated-copies'では，文書a及びbを別々にステープル止めする。

備考　これら値は，いずれも，一つの文書内でページ照合せずにシートを生成する手段を提供しない。すなわち，シートnの複数のコピーは，同じ文書のシートn+1より前に生成される。

この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

この属性は，印刷するコピーの部数を指定する。

多くの装置では，ページ照合して出力できるコピー部数は，その装置の物理的な排紙棚の数で制限され，サポート可能なページ照合しないコピー部数とは違っているかもしれない。

備考　複数の文書をもつジョブでのこの属性の効果は，"multiple-document-handling"ジョブ属性(4.2.4参照)によって制御される。この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

この属性は，Jobにおける各印刷された文書の各コピーに対してPrinterが使用する仕上げ操作を識別する。複数の文書をもつJobに対しては，"multiple-document-handling"属性が，仕上げの目的での"コピー"を構成するものを決定する。

標準の列挙値は，表11のとおり。

表12の値は，より特殊なものとする。これらは，文書を用紙縦使い文書(表の下を参照)であるものとして，隅又は端を指示する。

'staple-xxx'の値は，文書を用紙縦使い文書であるものとして，その文書に関して指定する。文書が実際は用紙横使い文書又は逆用紙横使い文書の場合は，クライアントが適切な変換値を供給する。例えば，用紙横使い文書の上左隅にステープルを置くためには，クライアントは，'staple-bottom-left'値を供給する。これは，用紙横使いが，用紙縦使いから+90度回転したもの，すなわち反時計回りに90度回転したもの，として定義されることによる。一方，逆用紙横使い文書の上左隅にステープルを置くためには，クライアントは，'staple-top-right'値を供給する。これは，逆用紙横使いが，用紙縦使いから-90度回転したもの，すなわち時計回りに90度回転したもの，として定義されることによる。

文書に付ける各ステープルの角度を示す三つ組み(上下方向，水平方向，角度)は，実装に依存し，そこで，属性の値に依存してもよい。

備考　複数文書をもつジョブでのこの属性の効果は，"multiple-document-handling"ジョブ属性(4.2.4参照)によって制御される。この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

クライアントが値の任意の他の組合せと共に'none'の値を供給する場合，それは，その値の他の組合せだけが供給されたことと同じとする。すなわち，'none'値は効果を及ぼさない。

この属性は，Printerオブジェクトが印刷する各文書の各コピーに対して使用する印刷ストリームページの範囲を識別する。文書の中に存在しないと識別されるページに対しては，何も印刷されない。範囲は，例えば，1-3，5-7，15-19などの降順でなければならず，重なってはならない。そこでスプールしていないPrinterオブジェクトは，単一パスでジョブを処理できる。範囲が降順でない，又は重なっている場合は，IPPオブジェクトは要求を拒否し，'client-error-bad-request'状態コードを返さなければならない。この属性は，印刷ストリームページに関連しており，アプリケーションが番号付けするページ(例えば，ワードプロセサアプリケーションが付けるヘッダ及びフッタにあるページ番号)とは関連しない。

複数文書をもつJobに対しては，"multiple-document-handling"属性が，指定したページ範囲の目的での"コピー"を構成するものを決定する。"multiple-document-handling"が'single-document'の場合，Printerオブジェクトは，供給されたページ範囲それぞれを，一度に印刷ストリームページの連結に適用する。例えば，それぞれ10ページの文書が八つ存在する場合，ページ範囲'41:60'は，5番目及び6番目の文書におけるページを一つの文書として印刷する。"multiple-document-handling"が'separate-documents-uncollated-copies'又は'separate-documents-collated-copies'の場合，Printerオブジェクトは，供給されたページ範囲をそれぞれ各文書のコピーに繰返し適用する。同じ名前のジョブに対しては，ページ範囲'1:3, 10:10'は，Jobの中の8文書それぞれを別々の文書として，それら文書の最初の3ページ及び10番目のページを印刷する。

大部分の場合，印刷する正確なページ数は，デバイスドライバが生成し，この属性は要求されない。しかし，既にフォーマットされている書庫にある文書を印刷する場合には，末端ユーザは，文書に含まれるページの一部だけを選択して印刷してもよい。この場合，page-range = n.mを指定したら，印刷する最初のページはページnとなる。文書のこれに続くページは，ページmを含むまで連続的に印刷される。

"page-ranges-supported"は，プリンタがページ範囲の印刷をサポートできるかどうかを示す論理値とする。この能力は，PDLごとに違っていてもよい。"page-ranges-default"属性は存在しない。"page-ranges"属性をクライアントが供給しない場合は，文書のすべてのページを印刷する。

備考　 数の文書をもつジョブにおけるこの属性の効果は，"multiple-document-handling"ジョブ属性(4.2.4参照)によって制御される。この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

この属性は，印刷ストリームページを選択したメディアインスタンスの表及び裏の面にどのように刷るか，すなわち，刷りを指定する。

標準のキーワード値を次に示す。

'one-sided'

連続する印刷ストリームページを連続する媒体シートの同じ面に刷る。

'two-sided-long-edge'

印刷ストリームページの連続する対を連続するメディアシートの表及び裏の面に刷る。ただし，印刷ストリームページの各対のメディア上での方向は，(メディアの)長い方の端を束ねた場合にこの印刷物の読者にとって自然なものとする。この刷りを，'duplex'又は'head-to-head'ということがある。

'two-sided-short-edge'

印刷ストリームページの連続する対を連続するメディアシートの表及び裏の面に刷る。ただし，印刷ストリームページの各対のメディア上での方向は，(メディアの)短い方の端を束ねた場合にこの印刷物の読者にとって自然なものとする。この刷りを，'tumble'又は'head-to-toe'ということがある。

'two-sided-long-edge'，'two-sided-short-edge'，'tumble'及び'duplex'のすべては，用紙縦使い又は用紙横使いに対して適用される。しかし，'head-to-toe'は，用紙縦使いでは'tumble'とし，用紙横使いでは'duplex'とする。'head-to-head'は，用紙縦使いモード及び用紙横使いモードを使用している場合，'duplex'及び'tumble'を切り替えることもする。

備考　複数の文書をもつジョブにおけるこの属性の効果は，"multiple-document-handling" ジョブ属性(4.2.4参照)によって制御される。この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

この属性は，選択したメディアインスタンスの一つの面に刷る印刷ストリームページの数を指定する。例を表13に示す。

この属性は，基本的に，印刷ストリームページの変換，スケール化及び回転を制御する。

備考　複数の文書をもつジョブにおけるこの属性の効果は，"multiple-document-handling"ジョブ属性(4.2.4参照によって制御される。この属性と文書処理を制御する他の属性との関係は，附属書 D.3で示す。

この属性は，印刷された印刷ストリームページに対する望ましい方向を指定する。クライアントが供給する印刷ストリームページの方向は記述しない。

('application/postscript'などの)幾つかの文書フォーマットに対しては，印刷ストリームページの望ましい方向は文書データ内で指定する。この情報は，印刷ジョブの提供に先立ってデバイスドライバが生成する。('text/plain'などの)それ以外の文書は，望ましい方向の情報を文書データ内には含まない。この場合，文書データが提供された後で，Printerオブジェクトが，そのデータに望ましい方向を結合することができる。Printerオブジェクトは，例えば，'text/plain'，'text/html'などの文書フォーマットだけに"orientations-requested"をサポートし，例えば，'application/postscript'などの文書フォーマットにはサポートしないと，予想される。このことは，他のJob Template属性と異なっているわけではない。それは，4.2で，Printerオブジェクトは，クライアントが供給する文書フォーマットに基づきJob Template属性をサポートしてもしなくてもよい，としているからとする。しかし，ここで特別に注意を喚起したのは，Printerオブジェクトが，サポートしている文書フォーマットの一部だけに対して"orientation-requested"をサポートしていることが非常に多いことによる。

標準の列挙値を，表14に示す。

備考　複数の文書をもつジョブにおけるこの属性の効果は，"multiple-document-handling"ジョブ属性(4.2.4参照)によって制御される。この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

この属性は，PrinterがJobのすべての刷りに対して使用するメディアを識別する。

"media"の値は，メディア名(medium-names)，メディアサイズ(medium-sizes)，給紙トレー(input-trays)及び電子的形式を含み，一つの属性でメディアを指定する。Printerオブジェクトがこの属性の値としてのメディア名をサポートする場合，そのメディア名は，暗黙的に，その指定されたメディアを含む給紙トレーを選択する。Printerオブジェクトがこの属性の値としてのメディアサイズをサポートする場合，そのメディアサイズが，暗黙的に，メディア名を選択し，さらに暗黙的に，指定したサイズのメディアを含む給紙トレーを選択する。Printerオブジェクトがこの属性の値として給紙トレーをサポートする場合，その給紙トレーは，暗黙的に，ジョブが印刷する際にその給紙トレーにあるメディアを選択する。この場合，手差しの給紙トレーのこともある。Printerオブジェクトがこの属性の値としての電子的形式をサポートする場合，その電子的形式は，暗黙的に，メディア名を選択し，さらに暗黙的に，その電子的形式が指定するメディアを含む給紙トレーを選択する。電子的形式は，Printerが，各ページに文書データと一緒に印刷しなければならない画像も，暗黙的に選択する。

標準のキーワード値は，附属書Cで示す。これは，ISO DPA及び Printer MIBから採用した。管理者は，実装に依存して，'name'属性又は'keyword'属性の構文を使い，付加的な値を定義してもよい。

"media-ready" という名前の付加的なPrinter属性も存在する。これは，"media-supported"とは異なる。"media-ready"の方は，その正当な値が，"media-supported"の部分集合であって，物理的にロードされており，操作介入の必要なしに印刷のために使用できるものとする。IPPオブジェクトが"media-supported"をサポートする場合，"media-ready"をサポートする必要はない。

この属性と文書処理を制御する他の属性との関係は，附属書D.3で示す。

この属性は，PrinterがJobに対して使用する解像度を識別する。

この属性は，PrinterがJobに対して使用する印刷品質を指定する。

標準の列挙値を表15に示す。

4.3での属性群は，"job-description"と呼ぶ属性グループを形成する。表16は，この属性群を示す。3番目の欄は，属性がPrinterオブジェクトによってサポートされなければならない必す(須)属性かどうかを示す。必す(須)と示されていない場合は，オプションとする。'text'属性及び'name'属性のオクテットの最大サイズは，括弧内に示す。

この必す(須)属性は，ジョブのURIを含む。Printerオブジェクトは，新しいジョブを受け付けると，その新しいジョブを識別するURIを生成する。Printerオブジェクトは，"job-uri"属性のその値を生成要求の応答の一部として返却する。Job URIの形式の詳細は，実装依存とする。Printerオブジェクトが二つ以上のURIをサポートし，新しく生成されたJob URIとPrinterオブジェクトのURIとの間に何らかの関係が存在する場合には，Printerオブジェクトは，生成要求でクライアントが供給したPrinter URIを使用する。例えば，生成要求が安全保護されたチャネルから来る場合，新しいJob URIは，同じ安全保護されたチャネルを使用しなければならない。これは，PrinterオブジェクトがJob URIを生成する責任をもち，生成要求で使用されたPrinter URIと同様にそのセキュリティの構成及び方針を認識しているので，保証される。

この属性の規定，並びにこの属性と"job-id"属性及び"job-printer-uri"属性との関係に関しては，2.4"オブジェクトの識別性"を参照すること。

この必す(須)属性は，ジョブの識別子IDを含む。Printerオブジェクトは，新しいジョブを受け付けると，そのPrinterにおけるその新しいジョブを識別するIDを生成する。Printerは，"job-id"属性のその値を生成要求の応答の一部として返却する。値0は，可能な値には含めない。これは，同じく0を可能とはしないSNMPインデクス値との互換性のためとする。

この属性の規定，並びにこの属性と"job-uri"属性及び"job-printer-uri"属性との関係に関しては，2.4"オブジェクトの識別性"を参照すること。

この必す(須)属性は，このJobオブジェクトを生成したPrinterオブジェクトを識別する。PrinterオブジェクトがJobオブジェクトを生成する際に，Printerオブジェクトは，この属性を生成要求で使用されたPrinterオブジェクトURIに設定する。JobオブジェクトのURIだけをクライアントが利用可能な場合，クライアントは，この属性によって，Jobオブジェクトを生成したPrinterオブジェクトを識別できる。クライアントは，このJobに対してサポートされている言語，charset及び操作を知るために，そのJobを生成したPrinterオブジェクトに問い合わせる。

この属性の規定，並びにこの属性と"job-uri"属性及び"job-id"属性との関係に関しては，2.4"オブジェクトの識別性"を参照すること。

この属性は，"printer-more-info"と同様に，Jobオブジェクトに関する追加情報をもった資源，恐らくそのJobに関する情報を含むHTMLページ，を参照するURIを含む。

この必す(須)属性は，ジョブの名前とする。これは，"job-uri"属性値よりもユーザが使いやすい名前とする。複数のJobの間で一意でなくともよい。Jobの"job-uri"属性は，生成要求(3.2.1.1参照)における"job-name"操作属性で，クライアントが供給する値の集合とする。しかし，クライアントが生成要求において"job-name"操作属性を供給しない場合には，Printerオブジェクトは，Jobを生成する際に，名前を生成しなければならない。プリンタは，値を生成する次のソースの最初の方からJobの"job-name"属性の値を生成することが望ましい。

a)	最初(又は唯一)の文書の"document-name"操作属性。
b)	最初(又は唯一)の文書の"document-URI"属性。
c)	Job固有情報及び/又は文書内容情報のa)及びb)以外の任意の断片。

この必す(須)属性は，プリントジョブを提出したエンドユーザの名前を含む。 Printerオブジェクトは，IPP操作が受信された認証サービスから得ることができる最も確証のある印字可能な名前に，この属性を設定する。それらの名前が利用可能でない場合に限り，Printerオブジェクトは，生成操作における"requesting-user-name"操作属性でクライアントが供給する値を使用する(8.参照)。

備考　 Printerオブジェクトは，ある形式での，典型的な例としては当事者の信任状としての，発信元ユーザ識別子をJobオブジェクトと共に保持する必要がある。これらの内部属性は実装依存であってクライアントには関心が無いので，Job Description属性としては規定しない。この発信元ユーザ識別子は，(存在する場合は)後続のすべての操作の認証検査のために使用する。

この必す(須)属性は，ジョブの現在の状態を識別する。IPPプロトコルはジョブ状態に七つの値(及び範囲外の'unknown'値。4.を参照。)を定義するのだが，実装は，特定の実装に対して適切な状態だけをサポートする必要がある。換言すると，Printerは，出力装置が実装しPrinterオブジェクト実装に利用可能なジョブ状態だけをサポートする。

標準の列挙値を，表17に示す。

この属性の最終値は，Printerがジョブを削除する前には，'completed'，'canceled'又は'aborted'の一つでなければならない。ジョブが'canceled'，'aborted'及び'completed'の状態に留まる時間の長さは，実装に依存する。4.3.7.2を参照。

図3は，ジョブの正常処理の場合の状態遷移を示す。

図3　ジョブの正常処理の状態遷移図

正常の場合，ジョブの進捗は，図の左から右へと進む。他の状態遷移はほとんど生じないが，禁止されているわけではない。'pending'，'pending-held'及び'processing-stopped'の各状態から'canceled'状態への遷移は，示してない。

ジョブは，出力メディアの積重ねを含むすべての活動を完了した後には，三つの終了状態，'completed'，'canceled'又は'aborted'の一つに到達し，すべてのジョブ状況属性は，そのジョブの最終値に到達する。

他のIPPすべての属性と同様に，実装がこの属性に対して正しい値を決定できない場合には，恐らく正しくない値を推定しエンドユーザにJobオブジェクトの状態について間違った印象を与えるよりはむしろ，範囲外の値'unknown'(4.1を参照)を与えて応答したほうがよい。例えば，実装がある印刷システムの単なるゲートウェイであって，その印刷システムから通常は状況を得られるだが，一時的にそれができない場合，実装は'unknown'値を返すほうがよい。しかし，実装が，印刷ジョブに関する詳細な状況を決して提供しない印刷システムへのゲートウェイの場合，その実装がジョブの"job-state-reasons"属性に'queued-in-device'値の設定もしていれば(4.3.8を参照)，その実装は，IPP Jobオブジェクトの状態を'completed'に設定してもよい。

4.3.7.2では，七つのジョブ状態を，ジョブ未完了(Job Not Completed)，ジョブ保持(Job Retention)，ジョブ履歴(Job History)及びジョブ削除(Job Removal)の段階に区分けする。さらに，Restart-Job操作と共に使用する"job-state-reasons" Job Description属性の'job-restartable'値を使う方法も示す。

ジョブ未完了

ジョブが，'pending'，'pending-held'，'processing'又は'processing-stopped'状態にある場合，ジョブは完了していない。

ジョブ保持

ジョブが三つの終了ジョブ状態，'completed'，'canceled'又は'aborted' の一つに入る場合，IPP Printerオブジェクトは，実装定義の時間間隔で，再び開始可能な状態にジョブを"保持"してもよい。この時間間隔は，ゼロ秒でもよいし，終了ジョブ状態に依存してもよい。この段階を，ジョブ保持という。ジョブ保持の段階にある間，ジョブの文書データは保持され，クライアントは，Restart-Job操作を使ってジョブを再び開始してもよい。IPPオブジェクトがRestart-Job操作をサポートしている場合，ジョブ保持段階にある間に，ジョブの"job-state-reasons"属性(4.3.8参照)に'job-restartable'値を追加することによって，ジョブが再び開始可能なことを示すほうがよい。

ジョブ履歴

一つのジョブに対するジョブ保持段階が終了した後で，Printerオブジェクトは，そのジョブのための文書データを削除し，ジョブはジョブ履歴の一部となる。Printerオブジェクトは，幾つかのジョブ属性も削除してよい。ジョブはもはや再び開始可能ではないので，Printerオブジェクトは，存在する場合には，ジョブの"job-state-reasons"属性から'job-restartable'値を取り除かなければならない。

ジョブ削除

ジョブ数が固定の数を超えた場合，(ゼロ秒でもよい)固定の時間間隔の後など，ジョブが実装定義の時間の間ジョブ履歴に留まった後，IPP Printerは，システムからジョブを取り除く。

Get-Jobs操作を使用し，"which-jobs"操作属性に'not-completed'値を供給して，クライアントは，ジョブ未完了段階にあるジョブを要求する。Get-Jobs操作を使用し，"which-jobs"操作属性に'completed'値を供給して，クライアントは，ジョブ保持段階にあるジョブ及びジョブ履歴段階にあるジョブを要求する。Get-JobーAttributes操作を使用して，クライアントは，ジョブ削除以外の任意の段階にあるジョブを要求する。ジョブ削除の後，Get-Job-Attributes操作及びGet-Jobs操作は，もはやジョブについてのいかなる情報を返すこともできない。

この必す(須)の属性は，ジョブの現在の状態についての付加的な情報，すなわち，ジョブの"job-state"属性の値をより詳細にする情報を提供する。

これらの値を，理由が意味をもつジョブの状態とともに使用してもよい。これら値定義の幾つかは，適合性要件を示しており，残りはオプションとする。さらに，実装する場合は，Jobの"job-state"属性の値が変わっても変わらなくても，Printerは，理由が適用される場合にこれらの値を返さなければならず，理由がもはや適用されない場合には，これらの値を返してはならない。Jobが現在の状態にあることにいかなる理由もない場合には，Jobの"job-state-reasons"の値は，'none'でなければならない。

備考："job-state"の値を受け取る動作を行うクライアントに影響を与えることなしに，値を'job-state'属性に追加できない場合に，そのクライアントに影響を与えることなく，付加的な"job-state-reasons"の値を定義でき登録できることを意図している。換言すると，"job-state-reasons"属性は，拡張可能であることを意図している。

標準のキーワード値を次に定義する。理解を容易にするために，値は，'job-incoming'値で開始して，(実装されている場合に)理由が発生しやすい順番に示す。

'none'

ジョブの現在の状態に対する理由は存在しない。この状態理由は，値をもたない"job-state-reasons"と意味的には等価であって，他の値が存在しない場合に使用しなければならない。これは，1setOf属性構文は，少なくとも一つの値を要求することによる。

'job-incoming'

Create-Job操作が，Printerによって受諾されたが，Printerは付加的なSend-Document操作及び/又はSend-URI操作を期待している。さらに，文書データをアクセス又は受諾している場合もある。

'job-data-insufficient'

Create-Job操作が，Printerによって受諾されたが，Printerがそのジョブを'processing'状態に移すことができる前に，付加的な文書データを必要としている。Printerがすべてのデータを受信する前に処理を開始する場合は，Printerは，'job-data-insufficient'理由を削除するが，'job-incoming'はそのままとする。Printerがすべてのデータを受信した後で処理を開始する場合は，Printerは，同時に，'job-data-insufficient'理由及び'job-incoming'理由を削除する。

'document-access-error'

Print-URI要求又はSend-URI要求を受諾した後で，Printerは，参照によって渡された一つ以上の文書にアクセスできなかった。この理由は，ファイルが存在しない，アクセス制御のためにアクセスが拒否されたなどを含む任意のファイルアクセスの問題に対応することを意図している。Printerがジョブを異常終了し，そのジョブを'aborted'ジョブ状態に移すか，又はアクセス可能なすべての文書を印刷し，そのジョブを'completed'ジョブ状態に移し，'completed-with-errors'値をジョブの"job-state-reasons"属性に追加するかどうかは，実装及び/又はサイトの方針に依存する。

'submission-interrupted'

ジョブは，予期しない理由のために完全には提出されなかった。予期しない理由は，例えば次による。

a)	クライアントがジョブを終了する前に，Printerがクラッシュした。
b)	文書データがすべてPrinterに転送される前に，Printer又は文書転送機構が，回復不可能な方法でクラッシュした。
c)	タイムアウトの前に，クライアントがクラッシュしたか，ジョブを終了することに失敗した。

4.4.31を参照すること。

'job-outgoing'

Printerは，出力装置にジョブを転送している。

'job-hold-until-specified'

ジョブの"job-hold-until"属性の値が，まだ到達していない時間間隔に指定された。ジョブは，この理由が取り除かれ，そのジョブを保持する他の理由が存在しなくなるまでは，処理の候補としてはならない。この値は，"job-hold-until"のJob Template属性がサポートされる場合，サポートされることが望ましい。

'resources-are-not-ready'

メディア，フォント，資源オブジェクトなどのジョブが必要とする資源の少なくとも一つが，そのジョブを処理候補とする物理的なプリンタのいずれかで準備可能となっていない。この条件は，実装に依存して，ジョブを受諾した時，又はそれに続くジョブが処理待ち又は処理中の時点で検出されてもよい。実装及び/又はジョブスケジュール方針に依存して，ジョブは現在の状態に留まるか，'pending-held'状態に移行するかしてよい。

'printer-stopped-partly'

Printerの"printer-state-reasons"属性が，値'stopped-partly'を含む。

'printer-stopped'

Printerの"printer-state"属性の値が，'stopped'。

'job-interpreting'

ジョブは'processing'状態にあるが，もっと特定すると，Printerが文書データを解釈中。

'job-queued'

ジョブは'processing'状態にあるが，より特定すると，Printerが文書データをキューに積んだ。

'job-transforming'

ジョブは'processing'状態にあるが，より特定すると，Printerが文書データを解釈し，他の電子的な表現を生成している。

'job-queued-for-marker'

ジョブは，'pending-held'状態，'pending'状態又は'processing'状態のいずれかにあるが，より特定すると，Printerがマーク付けを開始できる程度に文書の処理を完了し，ジョブはマーカを待っている。Release-Job操作を使ってジョブを解放するために人間の介入を要求するシステムは，ジョブを'pending-held'ジョブ状態におく。自動的にジョブにマーク付け開始を選択させるシステムでは，実装に依存して，ジョブを'pending'ジョブ状態におくか，又はマーカを待つ間はジョブを'processing'に留めておくかする。マーク付けが開始されたときには，すべての実装で，ジョブを'processing'状態におく。

'job-printing'

出力装置がメディアにマーク付けしている。この値は，次の場合で処理に時間がかかっているPrinterにとって役に立つ。

a)	マーク付けが無くなっており，現在マーク付けが出現中であることを示したい場合。
b)	'processing'状態中のジョブがキャンセル又は異常終了の処理にある場合であって，マーク付けはまだ停止しておらず，刷り又はシート数えがそのジョブに対してまだ続いている場合。

'job-canceled-by-user'

ジョブは，Cancel-Job要求を使ってそのジョブの所有者によってキャンセルされた。ここで，ジョブの所有者とは，認証される識別性がJobオブジェクトを生成したユーザの値と同じであるユーザ，又はこの意味でのジョブ所有者のセキュリティグループのメンバなどの他の認められたエンドユーザのこととする。この値は，サポートされることが望ましい。

'job-canceled-by-operator'

ジョブは，Cancel-Job要求を使って操作者によってキャンセルされた。ここで，操作者とは，(局所的又は大域的に関係なく，)操作する特権をもつとして認証済みユーザのこととする。セキュリティ方針が，任意の人が任意の人のジョブをキャンセル可能としている場合には，ジョブの所有者以外の人がジョブをキャンセルするときに，この値を使用してもよい。そのセキュリティ方針に対しては，実効的には，IPPのジョブのキャンセルに関する限り，すべての人が操作者となる。この値は，実装がジョブの所有者以外によるキャンセルを認める場合に，サポートされることが望ましい。

'job-canceled-at-device'

ジョブは，不特定の局所的ユーザ，すなわち，関係する装置のコンソールにいるユーザによってキャンセルされた。この値は，実装がコンソールにおいてジョブをキャンセルすることをサポートする場合に，サポートされることが望ましい。

'aborted-by-system'

ジョブは，次のいずれかの状態にある。

a)	異常処理中。
b)	システムによって異常処理されて，'aborted'状態におかれた。
c)	システムによって異常処理されて，'pending-held'状態におかれた。そこで，ユーザ又は操作者が，人手によって，ジョブを再開できる。この値は，サポートされることが望ましい。

'unsupported-compression'

Printerが文書データの圧縮を解凍しようとして，その圧縮が，実際には，Printerがサポートしている圧縮ではないと分かったので，ジョブがシステムによって異常終了された。この値は，"compression"が必す(須)の操作属性なので，サポートされなければならない。

'compression-error'

Printerが，文書データの圧縮を解凍中に，文書データ内でエラーに出会ったので，ジョブがシステムによって異常終了された。Printerがこの理由を知らせる場合，文書データは，既に，"job-state-reasons"属性の'unsupported-compression'値を生じる可能性がある任意の試験には合格している。

'unsupported-document-format'

文書データの文書フォーマットが，Printerがサポートするものではないために，ジョブがシステムによって異常終了された。クライアントが文書フォーマットを'application/octet-stream'として指定する場合，そのフォーマットが，"document-format-supported"プリンタ属性のメンバであっても，自動検出文書フォーマットではないので，プリンタは，ジョブを異常終了し，この理由を発行してもよい。この値は，"document-format"が必す(須)の操作属性なで，サポートされなければならない。

'document-format-error'

Printerが文書データを処理中に文書データ内でエラーに出会ったので，ジョブがシステムによって異常終了された。Printerがこの理由を知らせる場合，その文書データは，既に，"job-state-reasons"属性の'unsupported-document-format'値を生じる可能性がある任意の試験には合格している。

'processing-to-stop-point'

要求者がCancel-Job操作を発行したか，Printerオブジェクトがジョブを異常終了した。しかし，Prinerは，指定された停止点まで又はジョブ終了及び削除が完了するまで，ジョブに対して何らかの動作を実行している。

実装が'processing'又は'processing-stopped'のジョブ状態のジョブをキャンセルするために多少の測定可能な時間を要求する場合，IPPオブジェクトは，Printerオブジェクトが'processing'状態又は'processing-stopped'状態でジョブが残っている間に，幾つかの動作をまだ実行していることを示すために，この値を使わなければならない。 ジョブのすべてのジョブ記述属性が追加を停止した後で，Printerオブジェクトは，ジョブを'processing'状態から'canceled'状態又は'aborted'状態に移す。

'service-off-line'

Printerはオフライン状態で，ジョブを受諾しない。すべての'pending'ジョブは，'pendeing-held'状態におかれる。サービスの入力又は文書転送の入力が損傷している又は壊れている場合に，この状況は真となるだろう。

'job-completed-successfully'

ジョブは，成功終了した。 この値はサポートされることが望ましい。

'job-completed-with-warnings'

ジョブは，警告を出して終了した。 この値は，実装が警告を検知する場合に，サポートされることが望ましい。

'job-completed-with-errors'

ジョブは，エラーを(及び恐らくは警告も)出して終了した。この値は，実装がエラーを検知する場合に，サポートされることが望ましい。

'job-restartable'

このジョブは保留(4.3.7.2参照)されており，Restart-Job操作(3.3.7参照)を使って現在再び開始可能となっている。'job-restartable'がジョブの"job-state-reasons"属性の値となっている場合，IPPオブジェクトは，そのジョブに対してRestrat-Job操作を受諾しなければならない。この値は，Restart-Job操作がサポートされる場合に，サポートされることが望ましい。

'queued-in-device'

ジョブは，状況を送り戻すことができない装置又は印刷システムに転送された。Printerは，Printerがそのジョブについての付加的な情報をもたず，これ以上の情報ももたないだろうことを示すために，ジョブの"job-state"属性を'completed'に設定し，'queued-in-device'値をジョブの"job-state-reasons"属性に追加する。4.3.7.1参照のこと。

この属性は，人間が読むことが可能なテキスト形式での，"job-state"属性及び"job-state-reasons"属性についての情報を指定する。Printerオブジェクトがこの属性をサポートする場合，そのPrinterオブジェクトは，そのオブジェクトの"generated-natural-language-supported"属性(3.1.4.1で規定する"attributes-natural-language"操作属性を参照)が特定する自然言語のいずれかでこのメッセージを生成できなければならない。

ジョブ状態メッセージの値は，"job-state"属性及び"job-states-reasons"属性の値に含まれない，インタプリタエラー情報などの付加的な情報を含まないことが望ましい。そうしないと，アプリケーションプログラムは，その局所化したテキストを構文解析しようとするかもしれない。アプリケーションプログラム処理のための解釈エラーとか特定の文書アクセスエラーなどの付加的情報に対しては，新しい属性をキーワード値と共に開発し登録する必要がある。

この属性は，ジョブに関する付加的な詳細技術情報を指定する。メッセージはシステム管理者又は他の経験ある技術者によって使用されることを意図しているので，Printerはメッセージを現地化しなくてよい。現地化は，それらメッセージの技術的な意味を不明瞭にするかもしれない。クライアントは，この属性値を構文解析をしようとしてはならない。プログラムが処理できる付加的なエラーに関しては，この規定の"job-document-access-errors"(4.3.11)参照すること。

      (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf

この属性は，ジョブにおける文書の数を示す。この文書の数とは，文書データがPrinterオブジェクトに到達したかどうかとは関係なく，Printerがジョブに対して受諾したSend-Document操作，Send-URI操作，Print-Job操作又はPrint-URI操作の数とする。

オプションのCreate-Job操作，Send-Document操作又はSend-URI操作をサポートする実装は，クライアントが各ジョブにおける文書の数を問い合わせられるように，この属性をサポートすることが望ましい。

この属性は，Printerオブジェクトがジョブに割り当てた出力装置を識別する。出力装置が埋め込まれたPrinterオブジェクトを実装している場合，Printerオブジェクトは，この属性を設定する必要はない。印刷サーバがPrinterオブジェクトを実装している場合，Printerオブジェクトが出力装置をジョブに割り当てるまでは，その値は空(長さゼロの文字列)であったり，値が返却されなくてもよい。一つのPrinterオブジェクトが複数の装置をサポートする場合(いわゆる"fan-out"の場合。2.1参照。)，この値は特に役に立つ。

4.3.14では，あるイベントがジョブに対して発生する時点(又はより具体的な場合には時刻)を示すJob Description属性を定義する。ジョブイベントがまだ発生していない場合，IPPオブジェクトは，'no-value'範囲外値(4.1)の最初を参照)を返さなければならない。"time-at-xxx(integer)"属性は，デバイスが電源投入されてからの秒数(これを，通称としては，"時間刻み(time ticks)"と呼ぶ。)を表現する'integer'として，時間を表す。"date-time-at-xxx(dateTime)"属性は，UTCからのオフセットを含む日付及び時間を表現する'dateTime'として，時間を表す。

これらの属性を組み込むために，Printerオブジェクトは，イベントが発生する時に，次に示すPrinter Description属性の値をコピーする。

備考　Printerは，電源投入時には，いかなる"date-time-at-xxx(dateTime)"ジョブ属性の値をも変更しない。

この必す(須)属性は，Jobオブジェクトが生成された時刻を示す。

この必す(須)属性は，Jobオブジェクトが処理を始めた時刻を示す。ジョブがまだ'processing'状態にない場合は，範囲外を示す'no-value'値を返す(4.1の最初を参照)。

この必す(須)属性は，Jobオブジェクトが完了した(又はキャンセル若しくは異常終了された)時刻を示す。ジョブがまだ完了していない，キャンセルされていない，又は異常終了されていない場合は，範囲外を示す'no-value'値を返す(4.1の最初を参照)。

この必す(須)Job Description属性は，Printer実装が立ち上がり動き出す時間の総量を(秒単位で)示す。この属性は，"printer-up-time" Printer Description属性(4.4.29を参照)に対する別名とする。

IPP Printerが'integer'属性構文を使って時間属性を返す場合，ユーザにその時間属性を表示するために，クライアントは，Get-Job-Attributes要求又はGet-Jobs要求においてこの属性を要求し，他の要求されるEvent Time Job Description属性との組合せの形式で返却される値を使用する。この属性の値と"time-at-xxx"属性の'integer'値との差だけ，"time-at-xxx"イベントが以前に発生したことを示す。クライアントは，クライアントのもつ時計の時刻からこの差を引くことによって，"time-at-xxx"イベントが発生した時刻を計算できる。

この属性は，Jobオブジェクトが生成された日時を示す。

この属性は，完了予想時刻の相対的な時間順序で(すなわち，現在のスケジュールされた順序で)，このジョブに"先行する"ジョブの数を示す。効率化のために，この属性を要求する操作が実行される場合だけに，この値を計算することが望ましい。

この属性は，エンドユーザにジョブに対してとる修正又はそれ以外の管理のための理由を示すために，操作者，すなわち，システム管理者又は"知的な"プロセスからのメッセージを提供する。

4.3.17では，ジョブのサイズを記述するジョブ属性を定義する。これらの属性は，カウンタではなく，知っていれば役に立つ経路選択及びスケジュールの情報となることを意図している。これらの属性に対して，Printerオブジェクトは，生成要求でそれら属性の値が供給されない場合，その値を計算しようとしてもよい。クライアントが生成要求においてこれら三つの属性の値を供給する場合であっても，Printerオブジェクトがクライアントの供給した値よりも正確に値を計算できるときには，Printerオブジェクトはその値を変更することを選択してもよい。Printerオブジェクトは，ジョブ提出時又はその後の任意の時点のいずれかで，これら属性の正しい値を決定可能となっていてもよい。

この属性は，提出された文書の刷りの数での全サイズを指定する。附属書A.2.5での刷りの定義を参照すること。

"job-k-octets"と同様に，この値は，装置がジョブ又は文書データに関して複数パスの処理を行わずに複数部数を処理できるかどうかに依存せず，さらに出力がページ揃えをするかどうかに依存せず，"copies"属性が指定する部数に寄与する乗法因子を含めてはならない。そこで，値は，実装には依存せず，コピー部数に依存しない刷りで測った文書のサイズを示す。

"job-k-octets"と同様に，この値は，文書データに埋め込まれた部数命令による乗法因子も含めてはならない。文書データが実際にはその文書データの複製を含む場合，この値はこの複製を含む。換言すると，この値は，常に元となる文書データの刷りの数であって，ジョブが生成する刷りの数を測るものではない。

この属性は，このジョブが生成するメディアシートの全数を指定する。

"job-k-octets"属性及び"job-impressions"属性とは異なり，この値は，"copies"属性が指定する部数及び(存在する場合は)文書データに埋め込まれた 'number of copies'に寄与する乗法因子を含めなければならない。この差によって，システム管理者は次の両方のサイズの下限及び上限を制御できる。

a)	"job-k-octets-supported"及び"job-impressions-supported"をもつ文書のサイズ。
b)	"job-media-sheets-supported"をもつジョブのサイズ。

4.3.18では，ジョブの進捗を記述するジョブ属性を定義する。これらの属性は，カウンタとして機能する。すなわち，処理を開始していないジョブに対する値は，0でなければならない。ジョブの"job-state"が'processing'又は'processing-stopped'の場合には，この値は，属性が要求された時点まで処理されたジョブの総量を含むことになる。ジョブが'completed'状態，'canceled'状態又は'aborted'状態に入る場合には，これらの値は，ジョブの最終値となる。

この属性は，キロオクテット単位で，すなわち，1024オクテット単位で，今までに処理されたオクテットの全サイズを指定する。値は，次のとおりに丸められなければならない。すなわち，例えば，1オクテット〜1024オクテットのジョブは1と，1025〜2048は2と，示さなければならない。

データに関して単一パスだけの解釈で複数の部数を生成する実装では，最終値は，"job-k-octets"属性の値と等しくなければならない。各部数ごとにデータを処理することで複数部数を生成する実装では，最終値は，"job-k-octets"属性の値の倍数でなければならない。

このジョブ属性は，ジョブに対して，今までに完了した刷りの数を指定する。印刷装置に対しては，完了した刷りとは，解釈，マーク付け及び出力の積重ねを含む。

このジョブ属性は，マーク付け及びメディアシートの積重ねを，ジョブ全体に対して今までのところ完了したメディアシートを指定する。ただし，これらのシートは，片面又は両面のいずれで処理されているかに依らないものとする。

この必す(須)属性は，生成要求においてクライアントが供給した"attributes-charset"属性の値を使用して指定する。これは，生成要求でクライアントが供給した，属性構文が'text'及び'name'である任意のJob属性で使用するcharset(符号化文字集合及び符号化方法)を識別する。"attributes-charset"操作属性の完全な記述に関しては，3.1.4を参照すること。

この属性は，'text'値及び'name'値をJobオブジェクトで内部的に格納する際のcharsetを示さない。内部のcharsetは，実装定義とする。IPPオブジェクトは，内部charsetが何であっても，それから3.1.4で規定するとおりの操作において要求されているcharsetに変換しなければならない。

この必す(須)属性は，生成要求においてクライアントが供給した"attributes-natural-language"属性の値を使用して指定する。これは，生成要求でクライアントが供給した，属性構文が'text'及び'name'である任意のJob属性で使用する自然言語を識別する。"attributes-natural-language"操作属性の完全な記述に関しては，3.1.4を参照すること。"attributes-natural-language"属性が識別する値とは異なる自然言語の上書きを，各'text'属性値及び'name'属性値に対して明示的に供給する方法については，4.1.1.2及び4.1.2.2を参照すること。

これらの属性は，"printer-description"と呼ばれる属性グループを形成する。表18は，これらの属性，その構文，その属性がPrinterオブジェクトによってサポートされなければならない必す(須)属性かどうかを示す。必す(須)と示されていない場合は，オプションとする。'text'属性及び'name'属性のオクテットの最大サイズは，括弧内に示す。

備考　これらが管理者によってどのように設定されるかは，IPP/1.1規定の範囲外とする。

この必す(須)のPrinter属性は，Printerオブジェクトに対して少なくとも一つのURIを含む。それは，オプションで，Printerオブジェクトに対して複数のURIを含む。管理者は，PrinterオブジェクトのURIを決定し，このIPP/1.1規定の範囲外である何らかの手段で，それらのURIを含むようにこの属性を設定する。このURIの正確な形式は，実装依存とし，プロトコルに依存する。"uri-security-supported"属性及び"uri-authentication-supported"属性については，4.4.2及び4.4.3を参照すること。この二つは両方とも，この"printer-uri-supported"属性に付随する必す(須)属性とする。詳細については，Printerオブジェクト識別に関する2.4,並びにセキュリティ及びURIに関する8.2を 参照すること。

この必す(須)のPrinter属性は，"printer-uri-supported"属性と同じ基数(同じ数の値)をもたなければならない。この属性は，"printer-uri-supported"属性に列挙される個々のURIに関連するクライアント認証機構を識別する。 Printerオブジェクトは，認証ユーザ(8.3を参照)を識別する指定された機構をしようする。"uri-authentication-supported"のi番目の値は，"printer-uri-supported"のi番目の値に対応し，そのURIによってアクセスされたとき，そのPrinterによって使用される認証機構を記述する。クライアント認証の詳細については，[RFC2910]を参照すること。

標準のキーワード値を次に定義する。

'none'

URIに関連付けられた認証機構はない。Printerオブジェクトは認証済ユーザを"匿名"と仮定する。

'requesting-user-name'

クライアントが，URIを対象とする操作を実行するとき，Printerオブジェクトは，認証済みユーザは"requesting-user-name"操作属性(8.3を参照)で指定されたと仮定する。"requesting-user-name"属性が，要求内に無い場合，Printerオブジェクトは認証ユーザを"匿名"と仮定する。

'basic'

クライアントが，URIを対象とする操作を実行するとき，Printerオブジェクトは，HTTP基本認証でクライアントを試す。Printerオブジェクトは，認証済ユーザは基本認証機構を介して受け取った名前であると仮定する。

'digest'

クライアントが，URIを対象とする操作を実行するとき，Printerオブジェクトは，HTTPダイジェスト認証でクライアントを試す。Printerオブジェクトは，認証済みユーザはダイジェスト認証機構を介して受け取った名前であると仮定する。

'certificate'

クライアントが，URIを対象とする操作を実行するとき，Printerオブジェクトは，クライアントが証明証を提供することを期待する。Printerオブジェクトは，認証済みユーザは証明証に含まれるテキストでの名前であると仮定する。

この必す(須)のPrinter属性は，"printer-uri-supported"属性と同じ基数(同じ個数の値)をもたなければならない。この属性は，"printer-uri-supported"属性に列挙される個々のURIに関連するセキュリティ機構を識別する。Printerオブジェクトは，認証ユーザ(8.3を参照)を識別する指定された機構をしようする。"uri-security-supported"の"i番目の"値は，"printer-uri-supported"の"i番目の"値に対応し，そのURIでPrinterオブジェクトにアクセスするときに使用されるセキュリティ機構を記述する。セキュリティ機構に関する詳細については，[RFC2910]を参照すること。

標準のキーワード値を次に定義する。

'none'

与えられるURIに対して使われる安全なセキュリティ通信チャネルプロトコルはない。

'ssl3'

与えられるURIに対して使われる安全なセキュリティ通信チャネルプロトコルはSSL3 [SSL]とする。

'tls' 与えられるURIに対して使われる安全なセキュリティ通信チャネルプロトコルはTLS [RFC2246]とする。

この属性は，クライアント認証機構の指定と直交する。特に，'none'はクライアント認証を排除しない。4.4.2を参照すること。

次の例を考える。単一のPrinterオブジェクトに対して，管理者は, 次のとおりに"printer-uri-supported"属性，"uri-authentication-supported"属性及び"uri-security-supported"属性を設定する。

"printer-uri-supported": 'xxx://acme.com/open-use-printer', 'xxx://acme.com/restricted-use-printer', 'xxx://acme.com/private-printer'

"uri-authentication-supported": 'none', 'digest', 'basic'

"uri-security-supported": 'none', 'none', 'tls'

備考　 'xxx'は有効な方式ではない。オブジェクト対象の属性において使用される実際のURIの方式については，IPP/1.1 "符号化及びトランスポート"規定[IPP-PRO]を参照すること。

この場合，一つのPrinterオブジェクトは三つのURIをもつ。

• 最初のURI'xxx://acme.com/open-use-printer'に対して，"uri-security-supported"の値'none'は，HTTPの下で稼動するよう設定された安全なチャネルプロトコルはないことを示す。"uri-authentication-supported"の値'none'は，すべてのユーザが'anonymous'であることを示す。試行はなく，Printerは"requesting-user-name"を無視する。
• 2番目のURI'xxx://acme.com/restricted-use-printer'に対して，"uri-security-supported"の値'none'は，HTTPの下で稼動するよう設定された安全なチャネルプロトコルはないことを示す。"uri-authentication-supported"の値'digest'は，Printerが試行を発行し，Printerが認証済ユーザを決定するためにダイジェスト機構によって供給される名前を使用することを示す。
• 3番目のURI'xxx://acme.com/private-printer'に対して，"uri-security-supported"の値'tls'は，チャネルを保護するためにTLSが使用されていることを示す。クライアントは，Printerオブジェクトと通信している間に使用する受付け可能な暗号化スイートを折衝するために，TLSのフレーム化を使用できるように準備されなければならない。この場合，その名前は安全な通信チャネルの使用を暗黙的に示すが，"uri-security-supported"の値'tls'が存在することによってそれが明示される。クライアントは，どのセキュリティ機構が暗黙的に示されているかを判断するために命名規則に従ったり，URIを構文解析したりすることによって，どのセキュリティを使用するのがよいかを理解しようとする必要はない。"uri-authentication-supported"の値'basic'は，Printerが試行を発行し，Printerが認証済ユーザを決定するためにダイジェスト機構によって供給される名前を使用することを示す(8.3参照)。この試行はtlsセションで起こるので，チャンネルは安全とする。

多くのIPP Printerオブジェクトは，ただ一つのチャンネル(TLSアクセスを使用するように設定されるかされないか)及びただ一つの認証機構をサポートするように設定されることが予期される。それらのPrinterオブジェクトは，"printer-uri-supported"属性に列挙される一つのURIをもっているだけとする。Printerオブジェクトの設定にかかわらず(それがただ一つのURIをもっていようと複数のURIをもっていようと)，クライアントは，対象となる"printer-uri"操作属性の中のただ一つのURIを供給しなければならない。

この必す(須)のPrinter属性はPrinterオブジェクトの名前を含む。それは，URIよりもエンドユーザにわかりやすい名前とする。管理者は，プリンタの名前を決定し，その名前に対してこの属性を設定する。この名前は，プリンタのURIの最後の部分かもしれず，関連がないかもしれない。非US-Englishロケールでは，名前はURIでは許されていない文字を含むかもしれない。

このPrinter属性は，装置の位置を識別する。これには "in Room 123A, second floor of building XYZ"(XYZ号棟の2階，123A号室)などのものを含められるであろう。

このPrinter属性は，このPrinterオブジェクトに関する記述的情報を識別する。これは"This printer can be used for printing color transparencies for HR presentations(このプリンタは，HRプレゼンテーション用のカラー透過印刷に使用できます。)"，"Out of courtesy for others, please print only small (1-5 page) jobs at this printer(他の方のために，このプリンタでは，1ページ〜5ページの小さいジョブだけを印刷してください。)"，又は"This printer is going away on July 1, 1997, please find a new printer(このプリンタは1997年7月１日に撤去されます。新しいプリンタを探してください。)"という記述さえも含むかもしれない。

このPrinter属性は，この特定のPrinterオブジェクトに関する詳細な情報を得るために使用されるURIを含む。例えば，これはウェブブラウザでアクセス可能なHTMLページを参照する，HTTPなどのURIかもしれない。このURIから得られる情報は，エンドユーザが利用することを意図したものとする。情報は，このプリンタのインスタンス及び所内固有のサービス(例えば，ジョブの価格付け，提供されるサービス，エンドユーザ援助など)となるよう意図されている。装置製造者は最初からこの属性を含めるかもしれない。

このPrinter属性は，このPinterオブジェクトに対するドライバインストーラを位置を特定するために使用されるURIを含む。この属性は，オートマトンが利用することを意図するものとする。プリンタドライバのインストールは，このIPP/1.1規定の範囲外とする。装置製造者は最初からこの属性を含めるかもしれない。

このPrinter属性は，装置の製造及びモデルを識別する。装置製造者は最初からこの属性を含めるかもしれない。

このPrinter属性は，この型の装置に関する詳細情報を得るために使用されるURIを含む。このURIから得られる情報は，エンドユーザが利用することを意図したものとする。IPPの範囲外の機能は，このURIからアクセスできる(例えば，最新のファームウェア，更新，印刷ドライバ，利用可能はオプション機能，カラーサポートに関する詳細)。情報は，所内に特定な修正やサービスとは関係無く，このプリンタと関係のあるものとして意図されている。

この必す(須)のPrinter属性は，装置の現在の状態を識別する。"printer-state reasons"属性は，与えられたプリンタの状態にあるPrinterに関する詳細情報を与えるために"printer-state"属性を補う。

Printerオブジェクトは，この属性を要求する操作に応答する前にこの属性を更新するだけでよい。Printerオブジェクトは，非同期事象の通知はIPP/1.1には含まれないので，継続的にこの属性を更新する必要はない。Printerは，属性が与えられた実装に対して適用されないなら，それらをすべて実装する必要はない。

表19に標準の列挙値を定義する。

'spool-area-full'及び'stopped-partly'といった"printer-state-reasons"の値を，追加情報を提供するために使用してもよい。

この必す(須)のPrinter属性は，装置の状態に関する追加の詳細を提供する。

個々のキーワード値は，重大性のレベルを示す接尾辞をもってよい。三つのレベルは，報告(最も重大性が低い)，警告，エラー(最も重大性が高い)とする。

'-report'

この接尾辞は，理由が報告("report")であることを示す。実装は，幾つか又はすべての報告を省略するかもしれない。幾つかの報告はプリンタの状態に関して粒度の細かい情報を指定する。他のものは，警告の前兆として働く。報告は，印刷される出力に影響を与えうるものを含んではならない。

'-warning'

この接尾辞は，理由が"警告"であることを示す。実装が,幾つか又はすべての警告を省略することを選択するかもしれない。警告はエラーの前兆として働く。ある場合，出力の質が低いものとなっても，警告は，ジョブの完了を妨げるものを含んではならない。

'-error'

この接尾辞は，理由が"エラー"であることを示す。実装は，すべてのエラーを含まなければならない。この属性が，一つ又は複数のエラーを含む場合，プリンタは停止状態にならなければならない。

実装が，三つの接頭辞のいずれも含まない場合，理由は"エラー"であると仮定しなければならない。

Printerオブジェクトが複数の出力装置を制御する場合，この属性の個々の値は一つ又は複数の出力装置に適用してよい。Printerオブジェクトを完全に停止しない一つの出力装置でのエラーは，Printerの"printer-state-reasons attribute"において警告として現れてよい。これらのPrinterに対する"printer-state"が'stopped'値をもつ場合，"printer-state-reasons"属性中の値の中からのエラーの理由でなければならない。

標準のキーワード値を次に定義する。

'other'

装置が，この規定に列挙されたものではないエラーを検出した。

'none'

理由がない。この状態の理由は，値のない"printer-state-reasons"と意味的に等価とし，1setOf属性構文は少なくとも一つの値を必要とするので，使用されなければならない。

'media-needed'

トレーに用紙がなくなった。

'media-jam'

装置で用紙の紙詰まりがある。

'moving-to-paused'

誰かがPause-Printer操作(3.2.7を参照)又は他の方法を使ってPrinterオブジェクトを一時停止したが，装置が停止までにかなりの時間がかかっている。後で，すべての出力が停止したときに，"printer-state"は'stopped'となり，"printer-state-reasons"属性において，'paused'値が'moving-to-paused'値を置き換える。この値は，Pause-Printer操作がサポートされ，実装がある環境下でデバイスを停止するために無視できない時間がかかる場合に，サポートされなければならない。

'paused'

Pause-Printer操作(3.2.7を参照)又は他の方法を使ってPrinterオブジェクトを一時停止した者がいて，Printeオブジェクトの"printer-state"が'stopped'になる。この状態では，Printerは印刷出力を生成してはならないが，クライアントによって要求される他の操作を実行しなければならない。Printerが一時停止したときにそのPrinterがジョブを印刷していた場合，そのPrinterは，Printerが一時停止状態でなくなったときにそのジョブを再開しなければならず，その一時停止の印刷出力に痕跡を残してはならない。この値は，Pause-Printer操作がサポートされる場合に，サポートされなければならない。

'shutdown'

誰かがサービスからPrinterオブジェクトを除去し，装置の電源が落とされた，又は，物理的に除去されたかもしれない。この状態では，Printerは印刷出力を生成してはならず，依然として活動状態にある印刷サーバによってPrinterオブジェクトが実現されなければ，Printerオブジェクトは，この値を返すことを含め，クライアントによて要求される他の操作を実行してはならない。Printerオブジェクトがシャットダウンされたとき，そのPrinterがジョブを印刷していた場合，Printerは，シャットダウン状態でなくなったときにそのジョブの印刷を再開する必要はない。Printerがこれらのジョブを再開する場合，このシャットダウンの痕跡が印刷出力に残るかもしれない。例えば，シャットダウンの前に印刷された一部が，シャットダウン状態から復帰後に再度印刷されるかもしれない。

'connecting-to-device'

Printerオブジェクトが，出力装置においてジョブをスケジュールし，共有ネットワーク出力装置に接続する処理中である(ネットワーク上の他のサーバによる出力装置の使用に依存して，不定の長い時間，ジョブの印刷を実際に開始することができないかもしれない)。

'timed-out'

サーバが出力装置に接続できた(又は，いつも接続されている)が，出力装置から応答を得ることができなかった。

'stopping'

Printerオブジェクトが装置を停止する処理中であり，しばらくすれば停止する。装置が停止した場合，PrinterオブジェクトはPrinterオブジェクトの状態を'stopped'に変える。理由'stopping-warning'は，単一の出力装置をもつPrinterに対してさえも，決してエラーではない。出力装置がジョブの受諾を止めた場合，Printerは，出力装置が印刷を完了する間，この理由をもつ。

'stopped-partly'

Printerオブジェクトが複数の出力装置を制御する場合，この理由は，一つ又は複数の出力装置が停止したことを示す。理由が報告なら，出力装置の半分以下が停止している。理由が警告なら出力装置のすべてではないが，それ以下の数の装置が停止している。

'toner-low'

装置のトナーが少なくなった。

'toner-empty'

装置にトナーがなくなった。

'spool-area-full'

スプールのために割り当てられた永続的な記憶装置の限界に到達した。Printerは，一時的に，より多くのジョブを受諾できない。Printerは，より多くのジョブを受諾できる場合には，この値を取り除く。この値は，一つ又は少数のジョブを一度に受諾するだけのスプール機能のないPrinterか，又はスプール空間が一杯になったスプール機能付きPrinterによって使われることが望ましい。

'cover-open'

装置の一つ又は複数のカバーが開いている。

'interlock-open'

プリンタの一つ又は複数の内部ロック装置がロックされていない。

'door-open'

装置の一つ又は複数のドアが開いている。

'input-tray-missing'

一つ又は複数の給紙トレーが装置にない。

'media-low'

少なくとも一つの入力トレーの用紙が少なくなった。

'media-empty'

少なくとも一つの入力トレーが空である。

'output-tray-missing'

一つ又は複数の排紙トレーが装置にない。

'output-area-almost-full'

一つ又は複数の排紙領域[例えばトレー，スタッカ，コレータ(ページ揃え器)など]が，ほとんど一杯である。

'output-area-full'

一つ又は複数の排紙領域(例えばトレー，スタッカ，コレータなど)が，一杯である。

'marker-supply-low'

装置の少なくとも一つのマーカ供給(例えばトナー，インク，リボンなど)が少ない。

'marker-supply-empty

装置の少なくとも一つのマーカ供給品(例えばトナー，インク，リボンなど)が正常に機能していない。

'marker-waste-almost-full'

装置のマーカ供給品の廃棄物容器がほとんど一杯である。

'marker-waste-full'

装置のマーカ供給品の廃棄物容器が一杯である。

'fuser-over-temp'

溶解器の温度が通常より高い。

'fuser-under-temp'

溶解器の温度が通常より低い。

'opc-near-eol'

光学フォトコンダクタの寿命が近づいた。

'opc-life-over'

光学フォトコンダクタがもはや機能しない。

'developer-low'

装置の現像薬が少なくなった。

'developer-empty

装置の現像薬がなくなった。

'interpreter-resource-unavailable'

インタプリタの資源(すなわち，フォント，フォームなど)が利用できない。

このPrinter属性は，人が読めるテキストでプリンタ状態及びプリンタ状態理由に関する追加情報を指定する。Printerオブジェクトがこの属性をサポートする場合，PrinterオブジェクトはPrinterの"generated-natural-language-supported"属性によって識別される自然言語の任意のものでこのメッセージを生成できなければならない(3.1.4.1で指定される"attributes-natural-language"操作属性を参照)。

この必す(須)の属性は，このPrinterがサポートする主版及び副版を含むIPPプロトコルの版，すなわち，Printer実装が適合性要件を満たす版数を識別する。版数の有効性確認に関しては，Printerが，この属性の(US-ASCII)キーワード値をもつ各要求(3.1.1及び3.1.8を参照)においてクライアントが供給する(2オクテットの2進数の)"version-number"パラメタとマッチする。

標準のキーワード値を次に定義する。

'1.0'

6.に従って登録されたあらゆる拡張，及び存在する場合には，この版又は"version-number"パラメタが'1.0'のときの規則に従う，IPPの"モデル及び機能定義"又は"符号化及びトランスポート"の規定のあらゆる将来の版で定義されるあらゆる拡張を含んだ，RFC2566[RFC2566]及びRFC2565[RFC2565]で定義されるIPPの版1.0の適合性要件を満たす。

'1.1'

6.に従って登録されたあらゆる拡張及び存在する場合には，"version-number"パラメタが'1.1'のときの規則に従う，IPPの"モデル及び機能定義"又は"符号化及びトランスポート"の規定のあらゆる将来の版で定義されるあらゆる拡張を含んだ，この規定及び[RFC2910]で規定されるとおりのIPPの版1.1の適合性要件を満たす。

この必す(須)のPrinter属性は，このPrinterオブジェクト及び含まれる Jobオブジェクトに対してサポートされる操作の集合を指定する。

この属性は，[IPP-PRO] に従う任意の他の列挙属性構文として32ビットで符号化される。しかし，この属性に対するすべての32ビットのenum値は，0x00008FFFを超えてはならない。これは，実行されている操作を示すための二つの高位のオクテットを省略した個々のProtocol要求における，"operation-id"パラメタ(3.1.1参照)において，これらと同じ値が2オクテットで渡されることによる([RFC2910])。

表20に，標準のenum及び"operation-id"(3.1.2を参照)の値を定義する。

このPrinter属性は，Printerがジョブごとに複数の文書をサポートするかしないか，つまり，文書データと共に複数Send-Document操作又はSend-Data操作をサポートするかしないかを示す。PrinterがCreate-Job操作及びSend-Document操作(3.2.4及び3.3.1)をサポートする場合，Printerは，この属性をサポートしなければならない。

この必す(須)のPrinter属性は，操作者，システム管理者又は製造者によって設定されるPrinter属性'text'及び'name'，すなわち，"printer-name" (name)，"printer-location"(text)，"printer-info" (text)及び"printer-make-and-model" (text)を表現するためにPrinterオブジェクトが設定したcharsetを識別する。したがって，Printerオブジェクトの"charset-configured"属性の値は，Printerオブジェクトの"charset-supported"属性の値の中に含まれていなければならない。

この必す(須)属性は，Printer及び含まれるJobオブジェクトが属性構文'text'及び'name'をもつ属性でサポートするcharsetを識別する。 IPPオブジェクトはUTF-8 [RFC2279] charsetをサポートしなければならないので，少なくとも，値'utf-8'は存在しなければならない。Printerオブジェクトがあるcharsetをサポートする場合，それは，構文'text'及び'name'のすべての属性に対して，IPPオブジェクトが，必要に応じて要求でそのcharsetを受諾し，応答でその文字集合を返さなければならない(１)ことを意味する。

UTF-8より多くのcharsetがサポートされる場合，IPPオブジェクトは，3.1.4.2で説明されるcharset間のcharset変換を実行しなければならない。

この必す(須)のPrinter属性は，操作員，システム管理者，又は製造者によって設定されるPrinter属性'text'及び'name'，すなわち，"printer-name" (name)，"printer-location"(text)，"printer-info" (text)及び"printer-make-and-model" (text)を表現するためにPrinterオブジェクトが設定した自然言語を識別する。これらのPrinterオブジェクトを返す場合，Printerオブジェクトは，"attributes-natural-language"操作属性でクライアントによって要求される自然言語のかわりに，このPrinter属性で指定される設定された自然言語で，それらを返してもよい。オプションの複数の自然言語サポートの指定に関しては3.1.4.1を参照すること。したがって，Printerオブジェクトの"natural-language-configured"属性の値は，Printerオブジェクトの"generated-natural-language-supported"属性の値に入ってい なければならない。

この必す(須)のPrinter属性は，Printerオブジェクト及び含まれるJobオブジェクトが，属性構文'text'及び'name'をもつ属性でサポートする自然言語を識別する。サポートされる自然言語は，実装及び/又は設定に依存する。charsetと違い，IPPオブジェクトは，その自然言語がサポートされているかどうかに関わりなく，任意の自然言語又は任意のNatural Language Overrideをもつ要求を受諾しなければならない。

Printerオブジェクトが自然言語をサポートする場合，それは，Printerオブジェクト又はJobオブジェクトが，操作応答の中でメッセージ，すなわち，"job-state-message"及び"printer-state-message"属性及び操作メッセージ(3.1.5を参照)を生成する任意の属性に対して，Printerオブジェクト及びJobオブジェクトが，Printerのサポートされる任意の自然言語でメッセージを生成しなければならないことを意味する。

備考　複数の自然言語をサポートするPrinterオブジェクトは，しばしば，個々の自然言語に対して一つずつ独立したメッセージのカタログをもっている。

この必す(須)のPrinter属性は，クライアントが，文書データを供給する任意の操作要求で"document-format"操作属性を供給しないことを仮定するためにPrinterオブジェクトが設定する文書フォーマットを識別する。この属性の標準値は，インタネットメディア型(しばしばMIME型とも呼ばれる)とする。詳細については，4.1.9の'mimeMediaType'属性構文の説明を参照すること。

この必す(須)のPrinter属性は，Printerオブジェクト及び含まれるJobオブジェクトがサポートする文書フォーマットの集合を識別する。詳細については，4.1.9の'mimeMediaType'属性の説明を参照すること。

この必す(須)のPrinter属性は，プリンタが現在ジョブを受諾できるかどうか，つまり，Print-Job要求，Print-URI要求，及びCreate-Job要求を受諾しているかどうかを示す。値が'true'の場合，プリンタはジョブを受諾している。値が'false'の場合，Printerオブジェクトは，現在それに対して提出される任意のジョブを拒否している。この場合，Printerオブジェクトは，'server-error-not-accepting-jobs'状態コードを返す。

備考　この値は，現在のジョブではなく，将来のジョブに影響するので，"printer-state"属性及び"printer-state-reasons"属性とは独立とする。"printer-state"が'idle'の場合，この属性によって，Printerがジョブを拒否することがあり，"printer-state"が'stopped'の場合，この属性によって，Printerがジョブを受諾することがある。

この必す(須)のPrinter属性は，'pending'，'processing'，'pending-held'又は'processing-stopped'のいずれかであるジョブ数のカウントを含み， Printerオブジェクトによって設定される。

このPrinter属性は，エンドユーザに，なぜプリンタが使用できないのか，いつ使用可能になるのかなど，プリンタの情報又は状態を示すために操作者，システム管理者又は"知的な"プロセスから出されるメッセージを提供する。

このPrinter属性は，装置が，強調色を含め，何らかのカラー印刷が可能かどうかを識別する。色を使って実行されなければならない文書の指示のすべては，文書PDLに埋め込まれる。それらは，IPP/1.1の外部IPP属性ではない。

備考　エンドユーザは，"printer-more-info-manufacturer"Printer属性を問合せすることによって色サポートの性質及び詳細を決定することができる。

このPrinter属性は，Print-URI操作又はSend-URI操作の"document-uri"操作属性での使用のために，どのURIの方式がサポートされているかを指定する。Printerオブジェクトが，これらのオプションの操作をサポートする場合，少なくとも次のURIのスキームの値をもつPrinter属性"reference-uri-schemes-supported"をサポートしなければならない。

'ftp'

Printerオブジェクトは，[RFC2396]及び[RFC2316]によって定義されるFTP URL を使用してRFC2228[RFC2228]で定義されるFTP 'get'操作を使用する。

Printerオブジェクトは，オプションで，他のURIの方式をサポートしてよい(4.1.6参照)。

この必す(須)のPrinter属性は，文書データ命令をIPP属性で上書きする，又はしないよう試みるために，特定のPrinter実装の能力を表現する。

この属性のとる値は，次による。

'attempted'

この値は，Printerオブジェクトが，IPP属性の値が文書データに埋め込まれた命令よりも優先されるよう試みるが，その保証はないことを示す。

'not-attempted'

この値は，Printerオブジェクトが，IPP属性の値が文書データに埋め込まれた命令よりも優先されるよう試みないことを示す。

附属書Dには，この属性が他のIPP属性，特に"ipp-attribute-fidelity"属性とどのように相互動作するか及び影響を与えるかに関する完全な説明がある。

この必す(須)のPrinter属性は，このPrinterインスタンスが立ち上がってから動作している時間(秒)を示す。値は，Printerオブジェクトが開始された(初期化，起動など)時刻を1とし，そこから開始して単調に増加する値とする。この値は，Event Time Job Description属性の，"time-at-creation"，"time-at-processing"及び"time-at-completed"を組み込むために使用される(4.3.14を参照)。

Printerオブジェクトが，ある値'n'で停止し，復帰する場合，実装は，次ことを行ってよい。

a)	どのくらいの時間停止しているかを知り，'n'より大きいある値で再開する。
b)	1から再び開始する。

言いかえれば，そのデバイス又はPrinterオブジェクトが表現しているデバイスが再開始されるか，又は循環的に電源が投入された場合，Printerオブジェクトは，実装に依存して，この値を数え続けてもよいし，この値を1に再設定してもよい。しかし，Printerオブジェクトソフトウェアが動作を停止し，"printer-up-time"の最後の値を知らずに再開始する場合，実装は，この値を1に再設定しなければならない。この値が再設定され，実装が永続的なジョブをもっている場合，Printerは，"time-at-xxx(integer)"のEvent Time Job Description属性を，4.3.14に従って再設定しなければならない。実装は，冷起動又は暖起動に依存して，それぞれ，実装方式を選択して使用してもよい。

このPrinter属性は，現在の日付及び時刻を示す。この値は，"date-time-at-creation"，"date-time-at-processing"及び"date-time-at-completed"のEvent Time Job Description属性を組み込むために使用される(4.3.14を参照)。

日付及び時刻は，"最善"を尽くして得られ，実際に稼動するためにはそれほど正確である必要はない。Printerの実装は，ネットワーク時間サーバから値を得る，製造時点で初期化する，又は管理者が設定するなど，何らかの実装依存の方法を用いて日付及び時刻を得ることによってこの属性の値を設定する。例については，[IPP-IIG]を参照すること。実装がこの値をサポートし，実装が，正確な時間にまだ設定されていないことを知っている場合，実装は設定されていないことを意味する範囲外の値'no-value'を使用してこの属性の値を返さなければならない。4.1の最初を参照されたい。

この属性の時間帯は，Printerオブジェクト又は装置の近くに位置する人によって使用される時間帯である必要はない。クライアントは，受け取る任意の'dateTime'値がクライアントの時間帯又はプリンタの近くに位置する人の時間帯にあることを期待してはならない。

クライアントは，'dateTime'属性構文を使用する属性でPrinterによって返される時間帯を使用するのではなく，サーバによって返却される'dateTime'値をクライアントの時間帯に変換することによって，クライアントの現地時間で，ユーザに任意のdateTime属性を表示しなければならない。

このPrinter属性は，Printerオブジェクトが，3.3.1で示される何らかの回復動作をとる前に，まだ開いている複数文書(still-open multi-document)Jobオブジェクトに続く，追加のSend-Document操作又はSend-URI操作を待つ最小時間を(秒単位で)識別する。Printerオブジェクトが，Create-Job操作及びSend-Document操作(3.2.4及び3.3.1参照)をサポートする場合，この属性をサポートしなければならない。

ベンダはこの属性に対して60秒から240秒までの値を供給することが望ましい。実装は，システム管理者が(このIPP/1.1規定外の手段で)この属性を設定することを許してよい。その場合，システム管理者は，この範囲外の値を設定することができてよい。

この必す(須)のプリンタ属性は，サポートされている文書データの圧縮アルゴリズムの集合を識別する。圧縮は，文書データに適用されるだけとし，圧縮は，IPP操作自体の符号化には適用されない。サポートされる値は，Print-Job要求，Send-Document要求及びSend-URI要求におけるクライアントが供給する"圧縮"操作属性を確認するために使用される。

標準の値は次とする。

'none'

圧縮は使用されない。

'deflate'

ZIPパブリックドメイン圧縮技術

'gzip'

RFC1952[RFC1952]に記述されているGNU zip圧縮技術

'compress'

UNIX圧縮技術 ([RFC1977])

このPrinter属性は，キロオクテットでの，すなわち，1024オクテットの単位での，ジョブの合計サイズの上限及び下限を指定する。サポートされている値は，作成要求においてクライアントの供給する"job-k-octets"操作属性を確認するために使用される。対応するジョブ記述属性"job-k-octets"は，4.3.17.1に定義する。

このPrinter属性は，ジョブごとの刷りの数の上限及び下限を指定する。サポートされている値は，作成要求においてクライアントの供給する"job-impressions"操作属性を確認するために使用される。対応するジョブ記述属性"job-impressions"は，4.3.17.2に定義する。

このPrinter属性は，ジョブごとのメディアシートの数の上限及び下限を指定する。サポートされている値は，作成要求においてクライアントの供給する"job-media-sheets"操作属性を検証するために使用される。対応するジョブ記述属性"job-media-sheets"は，4.3.17.3に定義する。

このPrinter属性は，分ごとのページ数の公称値を，このプリンタによって生成されるであろう最も近い整数で指定する(例えば，片面，白黒)。この属性は参考であり，サービスの保証ではない。一般に，装置を記述するための宣伝用印刷物で使用される値とする。

値0は，1ページを処理するために2分以上かかる装置を示す。

このPrinter属性は，カラー印刷の場合の，分ごとのページ数の公称値を，このプリンタによって生成されるであろう最も近い整数で指定する(例えば，片面，カラー)。この属性の目的のため，"color"(カラー)は，"color-supported"属性のためと同じものを意味する。すなわち，装置は，強調色を含め，何らかのカラー印刷を行うことができる。この属性は情報であり，サービスの保証ではない。一般に，この装置のカラー能力を記述するための宣伝用印刷物で使用される値とする。

値0は，1ページを処理するために2分以上かかる装置を示す。

備考　カラー装置が幾つかのカラーモードをもつ場合，それは最高の数を生成するモードに対応する分ごとのページ数をこの属性の値としてを使用してよい。

白黒だけのプリンタは，この値をサポートしてはならない。この属性が存在する場合，"color-supported"Printer記述属性が存在し，値'true'をもたなければならない。

　 Get-Printer-Attributes操作によって返されるこれらの二つの属性の値は，Get-Printer-Attributes要求においてクライアントによって供給される"document-format"属性によって影響されてよい。言い換えれば，実装は，処理される文書フォーマットに依存して，異なる速さをもってよい。3.2.5.1 Get-Printer-Attributesを参照すること。

5.は，適合性の課題及び要件を示す。この規定は，オブジェクト，操作，属性，属性構文及び属性値などのモデル実体を導入する。これらの適合性の節は，これらのモデル実体に適用される適合性要件を規定する。

5.1は，次のいずれかの場合における，クライアント(2.1を参照)に関する適合性要件を規定する。

適合するクライアントは，この規定が定義するすべての必す(須)操作をサポートしなければならない。操作要求に含まれる個々の属性に対して，適合するクライアントは，その型及び値の構文が，3.及び4.で指定されるモデル文書の要件に適合する値を供給しなければならない。適合するクライアントは，6.の要件に合致している限り，操作要求におけるどのような登録された拡張及び/又はベンダ拡張をも供給してよい。

そうでない場合，IPPクライアント又はそれらのアプリケーションによって提供されるユーザインタフェースに対する適合要件はない。例えば，あるアプリケーションは，他のものが許しても，エンドユーザがジョブごとに複数の文書を送るのを許さないかもしれない。あるアプリケーションは，サポートされ値及びデフォルト値をもつ図形ユーザインタフェース(GUI)のダイアログボックスを供給するために，最初にPrinterオブジェクトを問い合せるかもしれないが，別の実装はそうしないかもしれない。

要求を送るとき，IPPクライアントは，クライアントによってオプションで供給されると示されるどのような属性をも供給する必要はない。

クライアントは，Printerオブジェクトからの応答において返却されるかもしれない, 4.1で定義されるどのような属性構文をも，その全範囲を含め，受諾しなければならない。特に，クライアントがサポートし，その属性構文が'text'である個々の属性に対して，クライアントは，'textWithoutLanguage'形式及び'textWithLanguage'形式の両方を受諾し，処理しなければならない。同様に，クライアントがサポートし，その属性構文が'name'である個々の属性に対して，クライアントは，'nameWithoutLanguage'形式及び'nameWithLanguage'形式の両方を受諾し，処理しなければならない。表示のためには，長い属性値の切り捨ては推奨されない。推奨のアプローチは，クライアント実装が，ユーザに長い属性値をスクロールすることを許すこととする。

応答は，クライアントが予期しない属性グループ，属性及び値を含んでよい。したがって，クライアント実装は，上手にそれらの応答を処理しなければならず，6.に適合する属性グループ，属性，属性構文，属性値，状態コード及び範囲外属性値を含む，IETF標準化過程の拡張又はベンダの拡張を返している適合Printerとの相互運用を拒否してはならない。クライアントは，理解できないどのようなパラメタ，属性及び値をも無視することを選択してよい。

クライアントがデータをプリンタに送っている間，"用紙切れ"又は"前のジョブが十分なメモリを解放していない"などの何らかの理由でチャネルがブロックされる(つまり，フロー制御がオフになる)とき，チャネルが下位層によって閉塞されるのを防ぐために，クライアントは，最善を尽くさなければならない。しかし，プリントの提出を行った層(例えばエンドユーザ)は，ジョブを取り消すために,そのチャネルを閉じてよい。クライアントがチャネルを閉じるとき，Printerは，文書の受け取った部分のすべて又は一部を印刷してよい。詳細は,"符号化及びトランスポート"の規定[RFC2910]を参照されたい。

クライアントは，IPP/1.1の符号化及びトランスポートの規定 [RFC2910]で定義されるクライアント認証をサポートしなければならないか，サポートした方がよい (領域ディレクタとの相談による。)。クライアントは，IPP/1.1符号化及びトランスポートの規定[RFC2910]で定義される操作プライバシ及びサーバ認証をサポートしなければならない。この規定の8.も参照すること。

5.2では，IPPオブジェクト(2.参照)の適合実装に対する適合性要件を規定する。これらの要件は，IPPオブジェクトが次のいずれかの場合に，IPPオブジェクトに適用する。

a)	IPP要求を受諾しデバイスを制御する，(埋込み)デバイスの構成要素
b)	IPP要求を受諾する印刷サーバの構成要素。ただし，印刷サーバは，IPP又は他のプロトコルを使用して，一つ以上のネットワークで接続されたデバイスを制御する。

適合する実装は，この規定の次に示す節で定義するモデルオブジェクトのすべてを実装しなければならない。

  2.1 - Printerオブジェクト
  2.2 - Jobオブジェクト

適合するIPPオブジェクト実装は，必す(須)の応答を含め，この規定の次に示す節で定義する必す(須)のモデル操作のすべてを実装しなければならない。

適合するIPPオブジェクトは，すべての必す(須)操作属性，及び規定の中で示されるそれらの属性すべての値をサポートしなければならない。適合するIPPオブジェクトは，要求で受け取られた，サポートされていない又は知られていない操作属性又は操作属性グループを無視しなければならないが，サポートされない値を含むサポートされる操作属性から成る要求を拒否しなければならない。

適合するIPPオブジェクトは，属性グループ，属性名，属性構文，属性値，及びこの規定の拡張である状態コードから成る操作応答を返却してよい。追加の属性グループは，どのような順序でも出現してよい。

オブジェクト属性に関する次の5.2.3は，オブジェクト属性に必要なサポートを規定する。

適合するIPPオブジェクトは，この規定の該当の節で定義される必す(須)のオブジェクト属性のすべてをサポートしなければならない。

オブジェクトが属性をサポートする場合，それは，この規定で指定される値だけ，又は5.2.4で規定される拡張機構による属性だけをサポートしなければならない。それは，これらの値の空でないどのような部分集合をもサポートしてよい。つまり，指定された値の少なくとも一つをサポートしなければならず，最大ですべてをサポートしなければならない。

IPP/1.1クライアントは，この規定及び[RFC2910]で定義されるクライアントに対する適合性要件を満たさなければならない。IPP/1.1クライアントは，'1.1'という値をもつ"version-number"パラメタを含む要求を送信しなければならない。

IPP/1.1のPrinterオブジェクト及びJobオブジェクトは，この規定及び[RFC2910]で規定されるIPPオブジェクトに対する適合性要求を満たさなければならない。IPP/1.1オブジェクトは，'1.1'という値をもつ"version-number"パラメタを含む要求を受諾しなければならない。ただし，操作がサポートされていない場合には，その要求を拒否しなければならない。）

以前の版との適合性を保つことは，この規定の適用範囲外とする。しかし，IPP/1.1は，以前の版を容易にサポートするために入念に設計された。この規定の原規定を作成したとき(1999)には，IPP/1.1 Printerの実装に次を期待していた。

• IPP/1.0又は1.1のフォーマットのすべての有効な要求を理解する。
• 要求でクライアントによって使用された同じ"version-number"のパラメタ値を含む応答に適切に応答する。

さらに，IPP/1.1のクライアントには次を期待する。

• IPP/1.0又は1.1のフォーマットのすべての有効な応答を理解する。

適合するIPPオブジェクトは，6.で指定された要件に適合する限り，登録された拡張及びベンダ拡張をサポートしてよい。

操作応答に含まれる各属性に関して，適合するIPPオブジェクトは，その型及び値の構文が, 3.及び4.で指定されるモデル文書の要件に適合する値を返却しなければならない。

IPPオブジェクトは，クライアントが属性を供給してもよく，又は(このIPP/1.1の規定の適用範囲外の方法で)システム管理者が属性を構成してもよいどのような操作においても，4.1が定義するどのような属性構文をもその全範囲を含め受け付けなければならない。特に，IPPオブジェクトがサポートし，その属性構文が'text'である各属性に関して，IPPオブジェクトは，'textWithoutLanguage'形式及び'textWithLanguage'形式の両方を受諾し，処理しなければならない。同様に，IPPオブジェクトがサポートし，その属性構文が'name'である各属性に関して，IPPオブジェクトは，'nameWithoutLanguage'形式及び'nameWithLanguage'形式の両方を受諾し，処理しなければならない。さらに，IPPオブジェクトは，クライアントによって前もって供給される場合の全範囲を含め，4.1で指定される構文に適合する操作応答において，クライアントに属性を返却しなければならない。

IPPプリンタの実装は，IPP/1.1の符号化及びトランスポートの規定[RFC2910]で定義されるクライアント認証のためのサポートを含まなければならないか, 含んだ方がよい(領域ディレクタとの相談による。)。Printer実装は，管理者に対して，ユーザのすべて又は何人かが認証されたり，ユーザの誰もが認証されなくするPrinter設定を可能にしてよい。この規定の8.も参照されたい。

IPPのPrinter実装は，IPP/1.1の符号化及びトランスポートの規定[RFC2910]が定義される操作プライバシ及びサーバ認証のサポートを含む方がよい。Printer実装は，管理者に対して, 操作プライバシ及びサーバ認証に関するサポートの程度を設定することを可能にしてよい。この規定の8.も参照されたい。

セキュリティは，クライアントが要求において'version-number'パラメタのより低い値を供給する場合，危険にさらされてはいけない。例えば，IPP/1.1の適合Printerオブジェクトが，版'1.0'要求を受諾し，Digest Authenticationを強制するように構成されている場合，そのPrinterオブジェクトは，版'1.0'の要求に対するのと同じことをしなければならない。

すべてのクライアント及びIPPオブジェクトは，4.1.7で定義する'utf-8'charsetをサポートしなければならない。

IPPオブジェクトは，自然言語がIPPオブジェクトによってサポートされてもされなくても，任意の個々の属性への自然言語上書き機能又は"attributes-natural-language"操作属性を正しく使用するどのようなクライアント要求をも受諾可能でなければならない。IPPオブジェクトが自然言語をサポートする場合，それは, すべての生成される 'text'属性の値又は'name'属性の値を, サポートされる言語の一つに(おそらく表検索によって)翻訳できなければならない(3.1.4を参照)。つまり，自然言語をサポートするIPPオブジェクトは，クライアントによって供給されるどのような任意の'text'値又は'name'値をも自然言語にする一般用翻訳装置である必要はない。しかし，オブジェクトは，それ自体の属性値及びメッセージのいずれをもその自然言語に翻訳(自動生成)できなければならない。

6.は，この規定へのIETF標準過程の拡張及びベンダ拡張のためのセマンティクスを定義する手続きを示す。

IPP/1.1で使用するために登録された拡張は，クライアント及びIPPオブジェクトのIPP/1.1モデル指定に対する適合性のためのオプションとする。

これらの拡張手続きは，IESG [IANA-CON]が定める指針に沿う。11.は，新しい登録をどのように考慮対象として提案するかを規定している。IANAは，要求される情報をもたない登録提案，又は11.が規定する適切な形式に従わない登録提案を拒否する。IPP/1.1は，これらの拡張のどれをも指定する適切なRFCによって拡張されてもよい。

IPPは，'keyword'及び'enum'の拡張を許す(4.1.2.3及び4.1.4を参照)。この規定は，その名前によってそれを読む者に拡張の意味を伝えるために，'keyword'及び'enum'の基本属性構文型に対して，接頭辞を使用する。この拡張情報は，クライアント又はPrinterオブジェクトには重要ではないので，プロトコルでは表現されない。次に示す一覧は，接頭辞及びその意味を規定する。

"type1"

このIPP規定(又はこの規定を補う他のIETF標準化過程の規定)は，新規のキーワード又は新規のenumを追加するためには，更新されなければならない。ベンダ定義のキーワード又はenumは，許されない。

"type2"

実装者は，いつでも，IANA(iana@iana.org)に全規定を提案することによって新規のキーワード又はenum値を追加できる。

IANAは，IPP指定の専門化に登録提案を転送する。その専門家は, そのために用意されたメーリングリストを使って提案をレビューする。はじめは，そのリストは，IPP WGが[IANA-CON]の許可によって解散した後も用いているメーリングリスト(ipp@pwg.org)になるであろう。

IPP指定の専門化は，[IANA-CON]に従って，IPPを担当するIESG領域ディレクタによって任命される。

type2キーワード又はenumが承認されると，IPP指定の専門化は，その登録に関して必要とされる将来のすべての保守の窓口となる。

"type3"

実装者は，いつでも，Type2の場合と同様に，IANAに全規定を送ることによって新規のキーワード又はenum値を追加でき，IANAは，その提案をIPP指定の専門化に転送する。追加の技術的検討が必要でなければ，IPP指定の専門化は，その裁量で，type2の登録と同じメーリングリストにその提案を送付して助言及びコメントを求めてよい。

type3キーワード又はenumがIPP指定の専門化によって承認されると，元の提案者は，その登録に関して必要とされる将来のすべての保守の窓口となる。

type2及びtype3のキーワードについては，提案者は登録の提案のキーワードの名前を含み, その名前は技術的検討の一部となる。

type2及びtype3のenum指定が承認された後，IPP指定の専門化は， IANAと相談しながら,各enum値に関して次に利用可能なenum番号を割り当てる。

IANAは，承認されたtype2及びtype3のキーワード並びにenum属性値の登録規定を次の中で公開する。

     ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt

ここで，xxxは，初期値を指定する属性名とし，yyy.txtは，同時に承認された一つ又は複数のenum又はキーワードを含む記述的ファイル名とする。例えば，ステープル止めのための幾つかの追加のenumが，"finishings"属性(並びに"finishings-default"属性及び"finishings-supported"属性)と共に使用するために承認される場合，IANAは，追加の値を次のファイルにおいて公開する。

     ftp.isi.edu/iana/assignments/ipp/attribute-values/finishings/stapling.txt

備考　幾つかの属性は, 'type3 keywords' | 'name'として定義される。それは，管理者定義の名前をもつサイト管理者によって属性値を拡張することを可能にする。その名前は, IANAには登録されない。

定義では，これらの三つの型のいずれも，拡張を有効なものとするために，何らかの登録処理又は検討処理を必要とする。レベル(1, 2, 3)の数はそれが大きくこなるほど，それぞれ減少的に前のレベルよりも厳格でなくなる。したがって，どのようなtypeNの値も，typeM(MはNより小さい。)に関する処理を使用して登録されてもよいが，その登録は必す(須)ではない。例えば, type3の値は，(IPP規定の将来の版に含まれることによって)type1の方法で登録されてもよいが，必す(須)ではない。

この規定は，type3キーワードを含めて，これらのすべての型に関するキーワード及びenumの値を定義する。

ベンダのキーワードの拡張に関しては，実装者は，"xxx-"などの，適切な区別のつく接頭辞をもつキーワードを使用するのが望ましい。ここで，xxxは，キーワード（4.1.3参照）の構文規則に従い，ドメイン名[RFC1035]で使用するためにIANAで登録された，(小文字の)完全に限定された会社名とする。例えば，XYZ Corp.という会社がドメイン名"XYZ.com"を獲得した場合，ベンダのキーワード'abc'は，'xyz.com-abc'となる。

備考　 RFC1035[RFC1035]は，大文字及び小文字はドメイン名に使用できるが，大文字・小文字の区別に特に意味がないことを示す。つまり，同じ綴りをもち，大文字・小文字が異なる二つの名前は，同じものとして扱われる。ドメイン名におけるラベルは，ARPANETホスト名の規則に従わなければならない。それらは，文字で始まり，文字又は数字で終わらなければならず，それらの間の文字としては，文字，数字及びハイフンだけをもつ。ラベルは，63個以下の文字でなければならない。ラベルは，"."文字で分離される。

ベンダのenum拡張に関しては，実装者は，2**30〜2**31-1の予約済み整数範囲の値を使用しなければならない。

属性名（4.1.3参照）は，type2キーワードとする。したがって，新しい属性は，登録されてよく， type2拡張規則に従って，この規定の属性と同じ状態をもつ。ベンダの属性拡張については，実装者は，6.1に規定される適切な区別のつく接頭辞をもつキーワードを使用しなければならない。

IANAは，次の別ファイルとして，承認された属性登録規定を公開する。

     ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt

ここで，"xxx-yyy"は，新しい属性名とする。

新規のPrinterオブジェクト属性が定義され，その値が特定の文書フォーマットによって影響を受け得る場合，その規定は次の文を含む必要がある。

  "The value of this attribute returned in a Get-Printer-
  Attributes response MAY depend on the "document-format"
  attribute supplied (see Section 3.2.5.1)."

規定がこの文を含まない場合，Get-Printer-Attributes応答のその値は，要求で供給される"document-format"に依存してはならない。新規のジョブテンプテート属性が登録される場合，Printer属性の値は,その表示が不可欠である規定をもたない要求で供給される"document-format"によって変化してもよい。

属性構文(4.1参照)は，type2のenumに似ている。したがって，新規の属性構文は，登録されてもよく，6.1に規定されるtype2拡張規則に従って，この規定の属性構文と同じ状態をもってもよい。各属性構文を識別する最初の値コードは，ベンダ使用のために指定された範囲を含め，"符号化及びトランスポート"の規定[RFC2910]で割り当てられる。

属性構文に関しては，IPP指定の専門化は， IANAと相談しながら, [RFC2910]で規定される適切な範囲内で，次の属性構文コードを割り当てる。IANAは，次に示す別ファイルとして，承認された属性構文登録規定を公開する。

     ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt

ここで，'xxx-yyy'は，新規の属性構文名とする。

主要な新規の操作はこの規定を拡張する新規の標準化トラック RFCによって行われるのが普通であるが，操作は, 6.1に規定されるtype2の手続きに従って登録されてもよい。ベンダの操作の拡張に関しては，実装者は，4.4.15サポートされる操作 ("operations-supported")のPrinter属性に規定される要求の中の"operation-id"の範囲を使用しなければならない。

操作に関しては，IPP指定の専門化は，IANAと相談しながら, 4.4.15に規定される次のoperation-idコードを割り当てる。IANAは，次に示す別ファイルで，承認された操作登録規定を公開する。

     ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt

ここで，"Xxx-Yyy"は新規の操作名とする。

要求及び応答で渡される属性グループ(3.1.3参照)には，6.1に規定されるtype2の手続きに従って登録されてもよい。属性グループタグの初期の集合は，ベンダ拡張のために指定された範囲を含む，"符号化及びトランスポート"規定[RFC2910]で割り当てられていた。

属性グループに関しては，IPP指定の専門化は，IANAと相談しながら, [RFC2910]に規定される適切な範囲内で，次の属性グループのタグコードを割り当てる。IANAは，次に示す別ファイルで，承認された属性グループ登録規定を公開する。

     ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
     tag.txt

ここで，'xxx-yyy-tag'は，新規の属性グループのタグ名とする。

操作状態コード(3.1.6.1)参照は，6.1に規定されるtype2の手続きに従って登録されてもよい。状態コードに関する値は，次に示す各状態コードクラスに対して附属書Cに規定される範囲の中に割り当てられる。

"informational"

処理を続けながら受け取られる要求。

"successful"

アクションが成功裏に受け取られ，理解され，受諾された。

"redirection"

要求を完了するために, さらにアクションをとられなければならない。

"client-error"

要求が悪い構文をもつか，又は達成できない。

"server-error"

IPPオブジェクトが，明らかに有効な要求を達成できなかった。

ベンダの操作状態コード拡張に関して，実装者は，附属書Bに規定される各範囲の最上位のものを使用しなければならない。

操作状態コードに関して，IPP指定の専門化は，IANAと相談しながら, 附属書Bに規定される適切なクラスの範囲内で，次の状態コードを割り当てる。IANAは，次に示す別ファイルとして，承認された状態コード登録規定を公開する。

ここで，"xxx-yyy"は，新規の操作状態コードキーワードとする。

要求及び応答で渡される範囲外属性値(4.1の最初を参照)は，この規定6.1で示されるtype2手続きに従って登録されてもよい。範囲外属性値タグの初期集合は，"符号化及びトランスポート"[RFC2910]で割り当てられた。

範囲外属性値のタグに対しては，IANAとの協議で指名されたIPP専門家が，[RFC2910]で指定されるとおりに適切な範囲に範囲外属性値のタグコードを割り当てる。IANAは，次の分離されたファイルとして，範囲外属性値のタグ登録規定を承認し公開する。

	ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-tags/xxx-yyy-tag.txt

"document-format"属性の構文は，'mimeMediaType'とする。これは，有効な値がインタネットメディア型(4.1.9を参照)であることを意味する。RFC2045[RFC2045]は，有効なインタネットメディア型の構文を定義する。IANAは，すべてのインタネットメディア型の登録機関とする。

"attributes-charset"属性の構文は, 'charset'とする。これは，有効な値は，charsetの名前であることを示す。IANA登録のcharsetが複数の名前 (別名)をもつ場合，"(preferred MIME name)"というラベルのついた名前(もしあれば) が使用されなければならない(4.1.7を参照)。IANAは, [RFC2278]の手続きに従ったcharsetの登録機関である。

幾つかの属性は，機械ではなく人に理解できることを意図して，文字列及び名前の値をもつ('text'及び'name'の属性構文については4.1.1及び4.1.2参照)。

それぞれの操作要求で，クライアントは，次のことを行う。

• 与えられた'text'及び'name'属性値に影響する，要求のcharset及び自然言語を識別する。
• 操作応答のIPPオブジェクトによって返される属性のためのcharset及び自然言語を要求する(3.1.4.1参照)。

さらに，クライアントは，それぞれ4.1.1.2又は4.1.2.2に規定されている'textWithLanguage'又は'nameWithLanguage'の手法を用いて，供給された'text'又は'name'属性のNatural Language Overrideを個別に識別してもよい。

すべてのIPPオブジェクトは，サポートするすべての'text'及び'name'の属性で，UTF-8 [RFC2279] charsetをサポートしなければならない。IPPオブジェクトが，UTF-8 [RFC2279]より多くのcharsetをサポートする場合，そのオブジェクトは，3.1.4.2に従って要求されたcharsetをクライアントへ返すために，それらのcharsetの間で変換をしなければならない。IPPオブジェクトが一つより多くの自然言語をサポートする場合，そのオブジェクトは，Printerによって生成された値である要求された自然言語で'text'及び'name'の値を返すことが望ましい(3.1.4.1参照)。

複数のcharset及び/又は複数の自然言語を'text'及び'name'の属性としてサポートするPrinterでは，charset及び/又は自然言語の異なる別のジョブが提出されたかもしれない。すべての応答は，クライアントに要求されたcharsetで返されなくてはならない。しかし，Get-Jobs操作は，それぞれの返されるジョブ属性で，異なる自然言語を識別するために，'textWithLanguage'及び'nameWithLanguage'の機構を使用する。

Printerオブジェクトは，設定されたcharset及び自然言語の属性もつ。クライアントは，Printerオブジェクトによってサポートされているcharset及び自然言語のリストを決めるため，並びにPrinterオブジェクトが設定している値が何であるかを決めるため，Printerオブジェクトに問い合わせることができる。詳細については，"charset-configured", "charset-supported", "natural-language-configured"及び"generated-natural-language-supported"のPrinter記述属性を参照。

"charset-supported"属性は，サポートされるcharsetを識別する。あるcharsetがサポートされている場合，IPPオブジェクトは，そのcharsetから，他のサポートされているcharsetへ変換できなければならない。多くの場合，IPPオブジェクトは，一つだけcharsetをサポートし，それは，UTF-8 charsetでなければならない。

"charset-configured"属性は，IPPオブジェクトの現在の設定(管理者が定義)として与えられる原charsetである，一つのサポートされているcharsetを識別する。

"generated-natural-language-supported"属性は，生成されるメッセージのための自然言語の集合を識別する。すなわち，クライアントが与える'text'及び'name'に対して受け付けられなければならない自然言語の集合とは関連がない。クライアントが供給する'text'及び'name'に対しては，IPPオブジェクトは，すべての供給された自然言語を受け付けなければならない。Printerオブジェクトが現在'en-us'に設定されていることは，クライアントが'fr-ca'のジョブ名を与えた場合にジョブを拒絶するのがよいということは意味しない。

"natural-language-configured"属性は，IPPオブジェクトの現在の設定(管理者が定義)として与えられる，原自然言語である，生成されるメッセージのためにサポートされる，一つの自然言語を識別する。

'text'型及び'name'型の属性は，異なるソースから出される。これらの属性は，(属性の送信元によって)次のグループに分類できる。

この規定のこの版において記される'text'及び'name'属性を，表23に示す。属性の追加は，6.に示した手続きに従って登録される。

規則1　これらのメッセージはシステム管理者又は他の経験ある技術者によって利用されるものと意図されているので，Printer及びクライアントは，これらのメッセージを現地化しない。

存在するかも知れないセキュリティ上の危険を，IPPが使われるすべての環境において予測することは難しい。例えば，一つの企業内の私的なネットワークでIPPが使われる場合，露出する文書データの危険は充分に少ないであろうから，その企業はそのデータを暗号化しないことを選択するであろう。しかし，クライアント及びIPPオブジェクトが，公開のネットワークで接続される場合には，クライアントは，ネットワーク内を伝送中の情報内容を暗号化して保護することを望むかもしれない。

しかも，印刷される情報の価値は，IPP環境ごとに異なるかもしれない。例えば，給与小切手を印刷することは，公開情報を印刷することとは価値が異なるであろう。印刷資源に対するサービス否認攻撃もあり得るが，印刷資源に対するサービス否認攻撃は理解されていないし，このシナリオに関しての先例の記録がない。

要求者の認証された識別性がIPPオブジェクトに一度供給されたならば，そのIPPオブジェクトは，適当であろう認定方針を実施するために，その識別性を使用する。例えば，あるサイトの方針は，ジョブの所有者だけに，そのジョブの取消しを許可するものであるかもしれない。特定のアクセス制御方針を設定するための詳細及び機構は，IPP/1.1の一部ではなく，別の管理の枠組み又はアクセス制御の枠組みによって確立されなければならない。ただし，IPPオブジェクトに対する何らかのアクセス制御違反となり得ることに関しては，IPPサーバがクライアントに情報を返信することを許す，操作状態コードが存在する。

生成操作において，クライアントの識別性は, 実装定義の属性のJobオブジェクトに記録される。この情報は，効果的であろう何らかのアクセス制御方針を実施するために，このJobオブジェクトへの後続の操作において，クライアントの識別性を検証するために使用できる。詳細を，8.3に示す。

IPPシステム管理者が憂慮するかもしれないセキュリティレベル又は特定の脅威は予測できないので，IPPは，個々の設置に要求される，異なるセキュリティ機構及びセキュリティ方針と共に実行されなければならない。セキュリティ方針は，多様であり，非常に強いかもしれないし，非常に弱いかもしれないし，なしかもしれない。それらに対応したセキュリティ機構が要求される。

IPP環境での特定のセキュリティ攻撃について次に示す。幾つかの例が示されるが，これらは環境の例示であって，すべての環境を記述している訳ではない。IPPの初期の実装では，これらの環境のすべてについて，必ずしも扱われるわけではない。

この環境は，従来のオフィス作業者が個人で使うアプリケーションの出力を共有作業グループプリンタに印刷する，又はバッチアプリケーションが出力を大規模プリンタに印刷する，典型的な構内ネットワークになる。この環境においてユーザの識別性は信頼されているかもしれないが，あるユーザは，盗み見，再生，勝手にいじるなどの攻撃に対して，文書内容を保護したいかもしれない。

この環境の例は，クライアントによって作成された文書を，印刷店などの広く一般に利用可能なプリンタに印刷すること，又は文書を取引先のプリンタに遠隔に印刷することを含む。後者の操作は，ファクシミリで取引先に文書を送信することと機能的に等価になる。異なるセキュリティ領域に属するPrinterへの機密扱いの情報の印刷は，強いセキュリティ尺度を要求する。この環境では，印刷資源の認定されていない使用からの保護と共に，プリンタの認証が要求される。文書は，複数のセキュリティ領域にまたがっているので，盗み見及び勝手にいじることからの保護も要求される。この環境では，"スパム"及び悪意のある文書内容からのPrinterの保護も重要である。

文書がクライアントに保持されていないとき，参照によって印刷できる。すなわち，印刷要求は，実文書の代わり，文書への参照又はポインタを含むことができる(3.2.2及び3.3.2参照)。遠隔実体が第三者に要求を転送するためのクライアントの信任状を"横取り"するための標準的な方法は現在存在しない。Print-By-Reference(参照による印刷)が"公開"文書にアクセスするために使われることとは予期されるが，"代理人"を認証する洗練された方法は, この規定では扱われない。

"printer-uri-supported"属性は，PrinterオブジェクトのURIを含む。それに付随する属性である"uri-security-supported"は，"printer-uri-supported"属性にリストされている各URIに使用されるセキュリティ機構を識別する。それぞれのPrinter操作属性において，クライアントは，"printer-uri"操作属性に含まれるただ一つのURIを供給しなければならない。別の言い方をすれば，Printerが複数のURIをサポートするとしても，クライアントは，その一つのURIだけによって相互に作用する。この二元性は，Jobオブジェクトには必要ではない。それは，Prinerオブジェクトは，Jobオブジェクトを製造するところであり，そのPrinterオブジェクトのセキュリティ設定に依存して，新しいJobオブジェクトに対して正しいURIを生成することに基づく。

それぞれのURIは関連した認証機構をもつ。URIが"printer-uri-supported"のi番目の要素である場合，認証機構は"uri-authentication-supported"の"i番目の"要素になる。可能な認証機構の一覧については，4.4.2を参照のこと。

Printerオブジェクトは，ユーザが操作を実行する名前を決めるため，認証機構を使用する。このユーザを"認証済みユーザ"と呼ぶ。認証の信頼性は，user.s名を取得するためにPrinterが使用する機構に依存する。認証機構が@none@の場合，すべての認証済みユーザは"匿名"となる。

ジョブ生成操作中に，Printerは，"job-originating-user-name"属性の値を初期化して，認証済みユーザとなる。認証済みユーザは，この場合"job-owner"と呼ばれる。

実装が，複数の認証機構をサポートする構成をとることができる場合，異なる認証機構を通して認証される認証済みユーザ名の同等性を決めるための規約を実装しなければならない。一つの可能性のある方針は，異なる機構によって認証された同一の名前は，異なるものであるとすることとする。例えば，あるユーザが，Cancel-Job及びPrint-Jobの両方おいて，同じ認証機構を使ったときだけ，そのユーザのジョブが取消しできるとする。もう一つの方針は，異なる機構によって認証された同一の名前は，後の操作の認証機構が先のジョブ生成操作の認証機構より弱くないときだけ，同一のものであるとすることとする。例えば，あるユーザが，同じ又はより強い認証機構を使ったときだけ，そのユーザのジョブが取消しできるとする。この2番目の方針では，'requesting-user-name'認証で提出されたジョブは，'digest'認証を通して取り消せるであろう。最初の方針では，ジョブはこの方法によっては取り消せないであろう。

クライアントは，ジョブを生成するのに使用される認証機構を決めることができる。これは，Printer.sの"uri-authentication-supported"(4.4.2を参照)のi番目の値であり，iは，job.sの"job-printer-uri"(4.3.3を参照)属性と等価なPrinter.sの"printer-uri-supported"，4.4.1を参照) のインデクスとする。

多くのIPP操作では，クライアントは，応答で返される属性の一覧を供給する。セキュリティ上の理由によって，IPPオブジェクトは，クライアントが要求したすべての属性(又は，すべての値)は返さない構成に設定されているかもしれない。返されるジョブ属性は，要求したユーザがそのジョブを提出したユーザと同一であるかどうかに依存してもよい。IPPオブジェクトは，要求された属性のいずれも返さなくてもよい。この場合には，返される状態は，オブジェクトがすべての要求した属性を返した場合と同一とする。クライアントは，この応答によって，要求した属性がそのオブジェクトに存在するのか否かを知ることはできない。

3つのプリンタ操作，Pause-Printer, Resume-Printer及びPurge-Jobs(3.2.7, 3.2.8及び3.2.9参照)については，要求しているユーザは，そのPrinterオブジェクトの操作者又は管理者になるはずとする(1.参照)。ジョブに対する操作については，要求しているユーザは，ジョブ所有者になるはずであり, そのPrinterオブジェクトの操作者又は管理者になってもよい。Printerオブジェクトの操作者又は管理者を認定する方法は，この規定では扱わない。

IPPプリンタである装置が，IPPに加えてその他のジョブ提出プロトコルを使用したジョブを受諾することができる場合，これらの実装が, 少なくともGet-Jobsが'unknown'として返した"job-id"及び"job-uri"を使って，問合された"IPP以外の"ジョブを許すことが，望まれる。これらの実装は，IPPジョブとしてのIPPジョブ属性と同じものをすべてサポートする必要はない。IPPオブジェクトは，IPPジョブにはサポートされているが，IPP以外のジョブにはサポートされていないIPP以外のジョブの要求された属性のために，'unknown'領域外の値を返す。

さらに，これらの"IPP以外のジョブ"に対しての"job-id"及び"job-uri"の値をIPP Printerが生成することが望ましく，可能であれば，Get-Job-Attribute及びCancel-Jobなどの他のIPP操作のターゲットとなるかもしれない。これらの実装は，これらのIPP以外のジョブの認証の問題を処理する必要もある。一つの取り組み方は，すべてのIPP以外のジョブを，IPPクライアントのユーザではないユーザに属させる取扱いであろう。もう一つの取り組み方は，IPP以外のジョブを'anonymous'に属させることであろう。IPP Printerオブジェクトの操作者又は管理者として認証されているIPPクライアントである場合だけ，IPP以外のジョブはIPP要求によって問合せできるであろう。セキュリティ方針が他のユーザのジョブに問合せすることを許可している場合には，Get-Jobs及びGet-Job-Attributesを使用したエンドユーザのIPPクライアントに対して，IPP以外のジョブが見えるようになろう。

[ASME-Y14.1M]

Metric Drawing Sheet Size and Format, ASME Y14.1M-1995. This standard defines metric sheet sizes and formats for engineering drawings.

[ASCII]

Coded Character Set - 7-bit American Standard Code for Information Interchange (ASCII), ANSI X3.4-1986. This standard is the specification of the US-ASCII charset.

[BCP-11]

Bradner S., Hovey R., "The Organizations Involved in the IETF Standards Process", 1996/10/29 (RFC2028)

[HTPP]

J. Barnett, K. Carter, R. DeBry, "Initial Draft - Hypertext Printing Protocol - HTPP/1.0", October 1996, ftp://ftp.pwg.org/pub/ pwg/ipp/historic/htpp/overview.ps.gz

[IANA-CON]

Narte, T. and Alvestrand, H.T.: Guidelines for Writing an IANA Considerations Section in RFCs, Work in Progress, draft-iesg-iana- considerations-04.txt, May 21, 1998.

[IANA-CS]

IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-n otes/iana/assignments/character-sets

[IANA-MT]

IANA Registry of Media Types: ftp://ftp.isi.edu/in-not es/iana/assignments/media-types/

[IPP-IIG]

Hastings, T., Manros, C., Kugler, C., Holst, H., and P. Zehler, "Internet Printing Protocol/1.1: draft-ietf- ipp-implementers-guide-v11-01.txt, work in progress, May 30, 2000.

[ISO10646-1]

ISO/IEC 10646-1:1993, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, JTC1/SC2."
JIS X 0221[国際符号化文字集合(UCS)-第1部 体系及び基本多言語面]-1995が, この規格に三つの附属書を追加したものである。

[ISO8859-1]

ISO/IEC 8859-1:1987, "Information technology -- 8-bit One-Byte Coded Character Set - Part 1: Latin Alphabet Nr 1", 1987, JTC1/SC2.

[ISO10175]

ISO/IEC 10175 Document Printing Application (DPA), June 1996.

[LDPA]

T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P. Zehler, "LDPA - Lightweight Document Printing Application", October 1996, ftp://ftp.pwg.org/pub/pw g/ipp/historic/ldpa/ldpa8.pdf.gz

[P1387.4]

Kirk, M. (editor), POSIX System Administration - Part 4: Printing Interfaces, POSIX 1387.4 D8, 1994.

[PSIS]

Herriot, R. (editor), X/Open A Printing System Interoperability Specification (PSIS), August 1995.

[PWG]

Printer Working Group, http://www.pwg.org.

[RFC1035]

P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987.

[RFC1179]

McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC1179, August 1990.

[RFC1759]

Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC1759, March 1995.

[RFC1766]

H. Alvestrand, "Tags for the Identification of Languages", RFC1766, March 1995.

[RFC1951]

Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3 ", RFC1951, May 1996.

[RFC1952]

P. Deutsch, "GZIP file format specification version 4.3", RFC1952, May 1996.

[RFC1977]

Schryver, V., "PPP BSD Compression Protocol", RFC1977, August 1996.

[RFC2026]

S. Bradner, "The Internet Standards Process -- Revision 3", RFC2026, October 1996.

[RFC2045]

N. Fried, N. Borenstein, ", Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies " RFC2045, November 1996.

[RFC2046]

Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521, RFC1522, RFC1590), RFC2046.

[RFC2048]

N. Freed, J. Klensin & J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures". RFC2048, November 1996.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119 , March 1997

[RFC2228]

M. Horowitz, S. Lunt, "FTP Security Extensions", RFC2228, October 1997.

[RFC2246]

T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, January 1999.

[RFC2277]

H. Alvestrand, "IETF Policy on Character Sets and Languages" RFC2277, January 1998.

[RFC2278]

N. Freed, J. Postel: "IANA CharSet Registration Procedures", RFC2278, January 1998.

[RFC2279]

F. Yergeau , "UTF-8, a transformation format of ISO 10646", RFC2279. January 1998.

[RFC2316]

S. Bellovin , "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.

[RFC2396]

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

[RFC2565]

Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC2565, April 1999.

[RFC2566]

deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC2566, April 1999.

[RFC2567]

Wright, D., "Design Goals for an Internet Printing Protocol", RFC2567, April 1999.

[RFC2568]

Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC2568, April 1999.

[RFC2569]

Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC2569, April 1999.

[RFC2579]

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

[RFC2616]

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

[RFC2617]

Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC2617, June 1999.

[RFC2639]

Hastings, T. and C. Manros, "Internet Printing Protocol/1.0: Encoding and Transport", RFC2639, July 1999.

[RFC2910]

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

[SSL]

Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.

[SWP]

P. Moore, B. Jahromi, S. Butler, "Simple Web Printing SWP/1.0", May 7, 1997, ftp://ftp.pwg.org/pub/pwg/ipp/n ew_PRO/swp9705.pdf

     
   Scott A. Isaacson, Editor
   Novell, Inc.
   122 E 1700 S
   Provo, UT   84606

   Phone: 801-861-7366
   Fax:   801-861-2517
   EMail: sisaacson@novell.com


   Tom Hastings
   Xerox Corporation
   737 Hawaii St.  ESAE 231
   El Segundo, CA   90245

   Phone: 310-333-6413
   Fax:   310-333-5514
   EMail: hastings@cp10.es.xerox.com


   Robert Herriot
   Xerox Corp.
   3400 Hill View Ave, Building 1
   Palo Alto, CA 94304

   Phone: 650-813-7696
   Fax:  650-813-6860
   EMail: robert.herriot@pahv.xerox.com


   Roger deBry
   Utah Valley State College
   Orem, UT 84058

   Phone: (801) 222-8000
   EMail: debryro@uvsc.edu


   Patrick Powell
   Astart Technologies
   9475 Chesapeake Dr., Suite D
   San Diego, CA  95123

   Phone: (619) 874-6543
   Fax:   (619) 279-8424
   EMail: papowell@astart.com

     
     IPPウェブページ:  http://www.pwg.org/ipp/
     IPPメーリングリスト:  ipp@pwg.org

IPPメーリングリストに申込むために，次のようにE-メールを送ってください。
     1) majordomo@pwg.orgに送る。
     2) 主題を空白行で離す。
     3) メッセージ本体に次のように2つの行を加える。
		subscribe ipp
		end

この規定の実装者には，課題を明確にする議論に参加し，属性及び値の追加のための登録提案審議に参加するために，IPPメーリングリストに登録することを薦める。

原規定の協力者

     
   Chuck Adams - Tektronix             
   Shivaun Albright - HP
   Stefan Andersson - Axis             
   Jeff Barnett - IBM
   Ron Bergman - Hitachi Koki Imaging Systems
   Dennis Carney - IBM
   Keith Carter - IBM                  
   Angelo Caruso - Xerox
   Rajesh Chawla - TR Computing Solutions       
   Nancy Chen - Okidata
   Josh Cohen - Microsoft              
   Jeff Copeland - QMS
   Andy Davidson - Tektronix           
   Roger deBry - IBM
   Maulik Desai - Auco                 
   Mabry Dozier - QMS
   Lee Farrell - Canon Information Systems    
   Satoshi Fujitami - Ricoh
   Steve Gebert - IBM                  
   Sue Gleeson - Digital
   Charles Gordon - Osicom             
   Brian Grimshaw - Apple
   Jerry Hadsell - IBM                 
   Richard Hart - Digital
   Tom Hastings - Xerox                
   Henrik Holst - I-data
   Stephen Holmstead                   
   Zhi-Hong Huang - Zenographics
   Scott Isaacson - Novell             
   Babek Jahromi - Microsoft
   Swen Johnson - Xerox                
   David Kellerman - Northlake Software
   Robert Kline - TrueSpectra          
   Charles Kong - Panasonic
   Carl Kugler - IBM                   
   Dave Kuntz - Hewlett-Packard
   Takami Kurono - Brother             
   Rick Landau - Digital
   Scott Lawrence - Agranot Systems    
   Greg LeClair - Epson
   Dwight Lewis - Lexmark              
   Harry Lewis - IBM
   Tony Liao - Vivid Image             
   Roy Lomicka - Digital
   Pete Loya - HP                      
   Ray Lutz - Cognisys
   Mike MacKay - Novell, Inc.          
   David Manchala - Xerox
   Carl-Uno Manros - Xerox             
   Jay Martin - Underscore
   Stan McConnell - Xerox              
   Larry Masinter - Xerox
   Sandra Matts - Hewlett Packard      
   Peter Michalek - Shinesoft
   Ira McDonald - High North Inc.      
   Mike Moldovan - G3 Nova
   Tetsuya Morita - Ricoh              
   Yuichi Niwa - Ricoh
   Pat Nogay - IBM                     
   Ron Norton - Printronics
   Hugo Parra, Novell                  
   Bob Pentecost - Hewlett-Packard
   Patrick Powell - Astart Technologies            
   Jeff Rackowitz - Intermec
   Eric Random - Peerless              
   Rob Rhoads - Intel
   Xavier Riley - Xerox                
   Gary Roberts - Ricoh
   David Roach - Unisys                
   Stuart Rowley - Kyocera
   Yuji Sasaki - Japan Computer Industry     
   Richard Schneider - Epson
   Kris Schoff - HP                    
   Katsuaki Sekiguchi - Canon
   Bob Setterbo - Adobe                
   Gail Songer - Peerless
   Hideki Tanaka - Cannon              
   Devon Taylor - Novell
   Mike Timperman - Lexmark            
   Atsushi Uchino - Epson
   Shigeru Ueda - Canon                
   Bob Von Andel - Allegro Software
   William Wagner - NetSilicon/DPI     
   Jim Walker - DAZEL
   Chris Wellens - Interworking Labs   
   Trevor Wells - Hewlett Packard
   Craig Whittle - Sharp Labs          
   Rob Whittle - Novell, Inc.
   Jasper Wong - Xionics               
   Don Wright - Lexmark
   Michael Wu - Heidelberg Digital     
   Rick Yardumian - Xerox
   Michael Yeung - Toshiba             
   Lloyd Young - Lexmark
   Atsushi Yuki - Kyocera              
   Peter Zehler - Xerox
   William Zhang- Canon Information Systems 
   Frank Zhao - Panasonic
   Steve Zilles - Adobe                
   Rob Zirnstein - Canon Information Systems

IPPの拡張を提案するには，提案者は，iana@iana.org宛てに電子メールで送ることによって，又はIANAのウェブページ(http://www.iana.org)にあるフォームに記入することによって，申請書をIANAに提出しなければならない。11.では，6.に規定している次の項目について，IPPの拡張の登録の提案をする場合に要求される情報及び様式について規定する。

• type2 'keyword' 属性値
  
• type3 'keyword' 属性値
  
• type2 'enum' 属性値
  
• type3 'enum' 属性値
  
• 属性
  
• 属性構文
  
• 操作
  
• 状態コード
  
• 範囲外の属性値

Type of registration: type2 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model Section 4.1.2.3):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型:type2キーワード属性値
このキーワードの規定が追加される属性の名前:
このキーワード値の推奨キーワード名:
このキーワード値の規定(4.1.2.3の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　type2キーワードについては，登録規定の保守が必要な場合，指名された専門家が，承認された登録規定についての連絡先となる。

Type of registration: type3 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model Section 4.1.2.3):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型: type3キーワード属性値
このキーワードの規定が追加される属性の名前:
このキーワード値の推奨キーワード名:
このキーワード値の規定(4.1.2.3の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　type3キーワードについては，登録規定の保守が必要な場合，提案者が，承認された登録規定についての連絡先となる。

Type of registration: type2 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Specification of this enum value (follow the style of IPP Model Section 4.1.4):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型:type2列挙属性値
この列挙型の規定が追加される属性の名前:
この列挙値のキーワード名:
番号(指名されたIPP専門家が，IANAと協議の上，割り当てる。):
この列挙値の規定(4.1.4の形式に従うこと):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　type2列挙については，登録規定の保守が必要な場合，指名された専門家が，承認された登録規定についての連絡先となる。

Type of registration: type3 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Specification of this enum value (follow the style of IPP Model Section 4.1.4):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型:type3列挙属性値
この列挙型の規定が追加される属性の名前:
この列挙値のキーワード名:
番号(指名されたIPP専門家が，IANAと協議の上，割り当てる。):
この列挙値の規定(4.1.4の形式に従うこと。):
提案者の住所:
提案者の電子メールアドレス:

備考　 type3列挙については，登録規定の保守が必要な場合，提案者が，承認された登録規定についての連絡先となる。

Type of registration: attribute
Proposed keyword name of this attribute:
Types of attribute (Operation, Job Template, Job Description, Printer Description):
Operations to be used with if the attribute is an operation attribute:
Object (Job, Printer, etc. if bound to an object):
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
If this is a Printer attribute, MAY the value returned depend on "document-format" (See Section 6.2):
If this is a Job Template attribute, how does its specification depend on the value of the "multiple-document-handling" attribute:
Specification of this attribute (follow the style of IPP Model Section 4.2):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型:属性
この属性の推奨する名前:
属性の型(Operation, Job Template, Job Description又はPrinter Description):
操作属性の場合，使用される操作(オブジェクトへの境界の場合，Job, Printerなど。):
属性構文(4.2の1setOf及びrangeを含む。):
属性構文が'keyword'又は'enum'の場合, type2又はtype3のどちらか:
Printer属性の場合, "document-format"に応じて返される値を書いてもよい(6.2参照):
Job Template属性の場合，"multiple-document-handling"属性の値への依存方法:
この属性の規定(4.2の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　属性については，登録規定の保守が必要な場合，指名されたIPP専門家が，承認された登録規定についての連絡先となる。

Type of registration: attribute syntax
Proposed name of this attribute syntax:
Type of attribute syntax (integer, octetString, character-string, see [RFC2910]):
Numeric tags according to [RFC2910](to be assigned by the IPP Designated Expert in consultation with IANA):
Specification of this attribute (follow the style of IPP Model Section 4.1):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の種類:属性構文
この属性構文の推奨する名前:
属性構文の型(integer, octetString又はcharacter-string。[RFC2910]参照。):
[RFC2910]に従う番号タグ(指名されたIPP専門家が，IANAと協議の上，割り当てる。):
この属性の規定(4.1の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　属性構文については，登録規定の保守が必要な場合，指名されたIPP専門家が，承認された登録規定についての連絡先となる。

Type of registration: operation
Proposed name of this operation:
Numeric operation-id value according to section 4.4.15(to be assigned by the IPP Designated Expert in consultation with IANA):
Object Target (Job, Printer, etc. that operation is upon):
Specification of this attribute (follow the style of IPP Model Section 3):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の種類:操作
この操作の推奨する名前:
4.4.15に従う操作id番号(指名されたIPP専門家が，IANAと協議の上，割り当てる。):
Object Traget(操作がなされるJob, Printerなど。):
この属性の規定(3.の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　操作については，登録規定の保守が必要な場合，指名されたIPP専門家が，承認された登録規定についての連絡先となる。

Type of registration: attribute group
Proposed name of this attribute group:
Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA):
Operation requests and group number for each operation in which the attribute group occurs:
Operation responses and group number for each operation in which the attribute group occurs:
Specification of this attribute group (follow the style of IPP Model Section 3):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型:属性グループ
この属性グループの推奨する名前:
この列挙値のキーワード名:
[RFC2910]に従う数値タグ(指名されたIPP専門家が，IANAと協議の上，割り当てる。):
属性グループが存在する操作要求の操作の操作要求及びグループ番号:
属性グループが存在する操作要求の操作の操作応答及びグループ番号:
この属性グループの規定(3.の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　属性グループについては，登録規定の保守が必要な場合，指名されたIPP専門家が，承認された登録規定についての連絡先となる。

Type of registration: status code
Keyword symbolic name of this status code value:
Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA):
Operations that this status code may be used with:
Specification of this status code (follow the style of IPP Model Section 13 APPENDIX B: Status Codes and Suggested Status Code Messages):
Name of proposer:
Address of proposer:
Email address of proposer:

参考　各項目の意味は，次のとおり。

登録の型:状態コード
この状態コード値のキーワード名:
番号(指名されたIPP専門家が，IANAと協議の上，割り当てる。):
この状態コードが使用されるかもしれない操作:
この状態コードの規定(附属書B状態コード及び推奨状態コードメッセージの形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　状態コードについては，登録規定の保守が必要な場合，指名されたIPP専門家が，承認された登録規定についての連絡先となる。

Type of registration: out-of-band attribute value
Proposed name of this out-band attribute:
Numeric tag according to [RFC2910] (to be assigned by the IPP Designated Expert in consultation with IANA):
Operations that this out-of-band attribute value may be used with:
Attributes that this out-of-band attribute value may be used with:
Specification of this out-of-band attribute value (follow the style of the beginning of IPP Model Section 4.1):
Name of proposer:
Address of proposer:
Email address of proposer:

登録の型:範囲外属性値
この範囲外属性値の提案される名前:
[RFC2910]に従う数値タグ(IANAとの協議で指名されたIPP専門家が割り当てる。):
範囲外属性値が使用される操作:
範囲外属性値が使用される属性:
この範囲外属性値の規定(4.1の最初の形式に従うこと。):
提案者の氏名:
提案者の住所:
提案者の電子メールアドレス:

備考　範囲外属性値に対しては，登録規定の維持管理が必要な場合，指名されたIPP専門家が，承認された登録規定についての連絡先となる。