この標準情報(TR)は，2000年9月にInternet Engineering Task Force (IETF)から公表されたInternet Printing Protocol 1.1: Encoding and Transport (RFC 2910)を翻訳し，技術的内容を変更することなく作成した標準情報(TR)である。
この標準情報(TR)は，IPP操作の符号化規則を含み，トランスポート層及び操作層の2層を規定する。
トランスポート層は，HTTP/1.1の要求(request)及び応答(response)から成る。RFC 2616[RFC2616]が，HTTP/1.1を規定する。この標準情報(TR)は，IPP実装がサポートするHTTPヘッダを規定する。
操作層は，HTTPの要求又は応答におけるメッセージ本体から成る。規定"インタネット印刷プロトコル/1.1: モデル及び機能定義"[RFC2911]は，そのメッセージ本体の機能定義及びサポートされる値を定義する。この標準情報(TR)は，IPP操作の符号化を規定する。前述の規定[RFC2911]を，以降では"IPPモデル規定"又は簡単に"モデル規定"と呼ぶ。
備考 IPP/1.1及びHTTP/1.1の版番号は，関連がない。両方が，偶然に，1.1になったに過ぎない。
この標準情報(TR)におけるキーワードの"でなければならない(MUST)"，"してはならない(MUST NOT)"，"必要な(REQUIRED)"，"であることが望ましい(SHOULD)"，"でないことが望ましい(SHOULD NOT)"，"推奨の(RECOMMENDED)"，"してよい(MAY)"及び"オプションの(OPTIONAL)"は，RFC 2119[RFC2119]に示すとおりに規定する。
操作層は，HTTP要求又はHTTP応答のメッセージ本体部分であって，単一のIPP操作要求又はIPP操作応答を含まなければならない。 各要求又は各応答は，値及び属性グループの列から成る。属性グループは，それぞれが名前及び値となる属性の列から成る。名前及び値は，最終的にはオクテット列とする。
符号化は，最もプリミティブな型としてのオクテットから成る。オクテットから構成される幾つかの型があるが，三つの重要な型は，整数，文字列及びオクテット列であって，これらを用いて他のほとんどのデータ型が構成される。この符号化におけるすべての文字列は，文字がある文字集合(charset)及びある自然言語に関連付けられている文字の列でなければならない。文字列は，(読み出す順番に従った)値の先頭文字が符号化の先頭文字となる"読出し順"になっていなければならない。関連するcharsetがUS-ASCIIであって，関連する自然言語が英語である文字列は，以降，US-ASCII-STRINGと呼ぶ。関連するcharset及び自然言語が，IPPモデル規定に示すとおりに要求又は応答の中で指定される文字列は，以降，LOCALIZED-STRINGと呼ぶ。オクテット列は，(IPPモデル規定で示された順に従った)値における先頭オクテットが符号化の先頭オクテットとなる"IPPモデル規定順"でなければならない。この符号化の各整数は，2の補数の2進符号化による符号付き整数として，ビッグエンディアン(big-endian)フォーマットで符号化しなければならない。ビッグエンディアンは，"ネットワーク順"及び"最上位バイト先頭"とも呼ぶ。一つの整数のオクテット数は，プロトコル中での使用に応じて，1，2又は4とする。以降SIGNED-BYTEと呼ぶ1オクテット整数は，版番号及びタグのフィールドで用いる。以降SIGNED-SHORTと呼ぶ2バイト整数は，operation-id, status-code及びlengthのフィールドで用いる。以降SIGNED-INTEGERと呼ぶ4バイト整数は，値のフィールド及びrequest-idで用いる。
3.1及び3.2では，次の二つの方法で操作層の符号化を示す。
操作要求又は操作応答は，3.1及び3.2で示す符号化を用いなければならない。
操作の要求又は応答は，図3.1のとおりに符号化される。
----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------- | attribute-group | n bytes - 0 or more ----------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | q bytes - optional ----------------------------------------------- 図3.1 操作の要求及び応答の符号化
この図にある最初の三つのフィールドは，モデル規定の3.1.1に示す属性の値を含む。
4番目のフィールドは，"attribute-group"フィールドであって，0回以上出現する。各"attribute-group"フィールドは，Operation Attributesグループ又はJob Attributesグループ(これらについてはモデル規定を参照。)といった，属性の単一グループを表現する。IPPモデル規定は，必須の属性グループ，並びに各操作要求及び操作応答に対するそれら属性グループの順番を規定する。
"end-of-attributes-tag"フィールドは，"data"が存在しない場合であっても，常に存在する。モデル規定は，"data"フィールドが存在するかどうかに拘わらず，各操作の要求及び応答を規定している。
各"attribute-group"フィールドは，図3.2のとおりに符号化される。
----------------------------------------------- | begin-attribute-group-tag | 1 byte ---------------------------------------------------------- | attribute | p bytes |- 0 or more ---------------------------------------------------------- 図3.2 属性グループ(attribute-group)の符号化
"begin-attribute-group-tag"フィールドは，"attribute-group"フィールドの最初に記され，その値は，例えば，Operations Attributesグループ対Job Attributesジョブ属性グループといった，属性グループの型を識別する。"begin-attribute-group-tag"フィールドは，要求又は応答の最初の"attribute-group"フィールドにある"begin-attribute-group-tag"フィールドを除く以前の属性グループの後ろにも記される。"begin-attribute-group-tag"フィールドは，"attribute-group"フィールドを他の"attribute-group"フィールドの内に入れ子にできないために，"attribute-group"終端子として振る舞う。
"attribute-group"フィールドは，0個以上の"attribute"フィールドを含む。
備考 "begin-attribute-group-tag"フィールド及び"end-of-attributes-tag"フィールドの値は，"delimiter-tags"と呼ばれる。
"attribute"フィールドは，図3.3のとおりに符号化される。
----------------------------------------------- | attribute-with-one-value | q bytes ---------------------------------------------------------- | additional-value | r bytes |- 0 or more ---------------------------------------------------------- 図3.3 属性(attribute)の符号化
属性が単一値(例えば，値10をもつ"copies")又は一つの値をもつ多値(例えば，値'one-sided'だけをもつ"sides-supported")の場合，一つの"attribute-with-one-value"フィールドだけで符号化される。属性がn値をもつ多値(例えば，値'one-sided'及び'two-sided-long-edge'もつ"sides-supported")の場合，後ろにn-1個の"additional-value"フィールドが続く"attribute-with-one-value"フィールドで符号化される。
各"attribute-with-one-value"フィールドは，図3.4のとおりに符号化される。
----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is u) | 2 bytes ----------------------------------------------- | name | u bytes ----------------------------------------------- | value-length (value is v) | 2 bytes ----------------------------------------------- | value | v bytes ----------------------------------------------- 図3.4 単一値をもつ属性(attribute-with-one-value)の符号化
"attribute-with-one-value"フィールドは，五つの下位フィールドで符号化される。
各"additional-value"フィールドは，図3.5のとおりに符号化される。
----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is 0x0000) | 2 bytes ----------------------------------------------- | value-length (value is w) | 2 bytes ----------------------------------------------- | value | w bytes ----------------------------------------------- 図3.5 付加値(additional-value)の符号化
"additional-value"は，四つの下位フィールドに符号化される
"tag"値に基づく動作を実行するパーサの見地からは，符号化は，図3.6のとおりに構成される。
----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------------------- | tag (delimiter-tag or value-tag) | 1 byte | ----------------------------------------------- |-0 or more | empty or rest of attribute | x bytes | ----------------------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | y bytes - optional ----------------------------------------------- 図3.6 代替図式
パーサが"tag"の各型の後にどのフィールドを期待するかを，次に示す。
次の構文は，'リテラルの文字列'が大文字と小文字とを区別しなければならないことを除いて，ABNF[RFC2234]に従うものとする。例えば，'a'という記述は，小文字の'a'を意味し，大文字の'A'ではない。さらに，SIGNED-BYTEフィールド及びSIGNED-SHORTフィールドは，値の範囲を示す'%x'値として表現される。
ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id
*attribute-group end-of-attributes-tag data
ipp-response = version-number status-code request-id
*attribute-group end-of-attributes-tag data
attribute-group = begin-attribute-group-tag *attribute
version-number = major-version-number minor-version-number
major-version-number = SIGNED-BYTE
minor-version-number = SIGNED-BYTE
operation-id = SIGNED-SHORT ; 以降で定義するモデルから対応付ける
status-code = SIGNED-SHORT ; 以降で定義するモデルから対応付ける
request-id = SIGNED-INTEGER ; 値は正とする
attribute = attribute-with-one-value *additional-value
attribute-with-one-value = value-tag name-length name
value-length value
additional-value = value-tag zero-name-length value-length value
name-length = SIGNED-SHORT ; 'name'のオクテット数
name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
value-length = SIGNED-SHORT ; 'value'のオクテット数
value = OCTET-STRING
data = OCTET-STRING
zero-name-length = %x00.00 ; 0のname-length
value-tag = %x10-FF ; 3.5.2参照
begin-attribute-group-tag = %x00-02 / %04-0F ; 3.5.1参照
end-of-attributes-tag = %x03 ; 3のタグ
; 3.5.1参照
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" 〜 "9"
LALPHA = %x61-7A ; "a" 〜 "z"
BYTE = %x00-FF
OCTET-STRING = *BYTE
次に示す構文は，この規定で参照する付加的な用語を定義する。この構文は，区切り子タグの代替グループ化を提供する。
delimiter-tag = begin-attribute-group-tag / ; 3.1.2参照
end-of-attributes-tag
delimiter-tag = %x00-0F ; 3.5.1参照
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / %x06-0F
operation-attributes-tag = %x01 ; 1のタグ
job-attributes-tag = %x02 ; 2のタグ
printer-attributes-tag = %x04 ; 4のタグ
unsupported-attributes-tag = %x05 ; 5のタグ
各"attribute-group"フィールドは，0個以上の"attribute"下位フィールドが続く"begin-attribute-group-tag"フィールドと一緒に符号化されなければならない。
表3.1は，モデル規定でのグループ名を"begin-attribute-group-tag"フィールドの値に対応付ける。
| モデル規定でのグループ名 | "begin-attribute-group-tag"値 |
| Operation Attributes | "operations-attributes-tag" |
| Job Template Attributes | "job-attributes-tag" |
| Job Object Attributes | "job-attributes-tag" |
| Unsupported Attributes | "unsupported-attributes-tag" |
| Requested Attributes
(Get-Job-Attributes) |
"job-attributes-tag" |
| Requested Attributes
(Get-Printer-Attributes) |
"printer-attributes-tag" |
| Document Content | 先に示したとおりの特別な位置 |
各操作の要求及び応答に対して，モデル規定は，必須属性グループ及びオプション属性グループを，それらの順番とともに，規定する。各属性グループ内で，モデル規定は，必須属性及びオプション属性を，それらの順番とともに，規定する。
モデル規定が要求又は応答の中に属性グループを要求し，その属性グループが0個の属性を含む(属性を含まない)場合，要求及び応答は，0個の"attribute"が続く"begin-attribute-group-tag"フィールドをもつ属性グループを符号化をすることが望ましい。例えば，クライアントが，Get-Printer-Attributes操作を用いて一つの未サポート属性を要求する場合，Printerは，"attribute"フィールドを返してはならず，Printer Attributesグループのための"begin-attribute-group-tag"フィールドを返すことが望ましい。Unsupported Attributesグループは，この例とは異なる。モデル規定によれば，Unsupported Attributesグループは，未サポート属性グループが少なくとも一つの属性を含む場合にだけ，存在することが望ましい。
モデル規定が，個数が分からない属性グループの列，ただしそれぞれは同じ型，を要求する場合，符号化は，"attribute-group"フィールドが0個の"attribute"下位フィールドを含む場合であっても，各属性グループに対して一つの"begin-attribute-group-tag"フィールドを含まなければならない。例えば，Get-Jobs操作に対して，幾つかのジョブのために0個の属性だけが返ってもよい。0個の"attribute"が続く"begin-attribute-group-tag"フィールドは，キューの中にあること以外は情報を利用可能ではないジョブがキューにあることを，受け手に伝える。
幾つかの操作要素は，モデル規定[RFC2911]の中で，パラメタと呼ばれている。それらは，特別な位置で符号化されなければならず，操作属性としては現れてはならない。これらのパラメタは，3.4.1以降で示される。
"version-number"フィールドは，主版番号及び副版番号から成り，それらはいずれもSIGNED-BYTEによって表現されなければならない。主版番号は，符号化の最初のバイトであって，副版番号は，符号化の2番目のバイトでなければならない。この規定が示すプロトコルは，主版番号1(0x01)及び副版番号1(0x01)をもたなければならない。これらの2バイトのABNFは，%x01.01でなければならない。
"operation-id"フィールドは，モデル規定の中で定義される操作ID(operation-id)値を含まなければならない。その値は，SIGNED-SHORTとして符号化されなければならず，操作要求の符号化の3番目及び4番目のバイトに存在しなければならない。
"status-code"フィールドは，モデル規定の中で定義される状態コード(status-code)値を含まなければならない。その値は，SIGNED-SHORTとして符号化されなければならず，操作応答の符号化の3番目及び4番目のバイトに存在しなければならない。
状態コードは，モデル規定では操作属性になっている。プロトコルにおいては，状態コードは操作属性の外の特別な位置に存在する。
IPP状態コードが返される場合，HTTP Status-Codeは，200(successful-ok)でなければならない。それ以外のHTTP Status-Code値の場合には，HTTP応答は，IPPのメッセージ本体を含んではならない。そこで，IPP状態コードは返されない。
"request-id"フィールドは，モデル規定で定義されるとおりの要求ID(request-id)値を含まなければならない。その値は，SIGNED-INTEGERとして符号化されなければならず，符号化の5番目〜8番目のバイトに存在しなければならない。
タグには，次の二つの種類が存在する。
- 区切り子タグ
- プロトコルの主要な部分，すなわち，属性及びデータ，を区切る。
- 値タグ
- 各属性値の型を指定する。
表3.2は，区切り子タグに対する値を規定する。
| タグ値(16進数) | 区切り子 |
| 0x00 | 将来のIETF規定の定義のために予約済み |
| 0x01 | operation-attributes-tag | 0x02 | job-attributes-tag |
| 0x03 | end-of-attributes-tag |
| 0x04 | printer-attributes-tag |
| 0x05 | unsupported-attributes-tag |
| 0x06-0x0f | IETF規定の将来の区切り子のために予約済み |
"begin-attributes-group-tag"フィールドがプロトコルに出現した場合は，次の区切り子タグまでの後続の0個以上の属性が，"begin-attribute-group-tag"の値によって指定される属性グループに属する属性でなければならないことを意味する。例えば，"begin-attribute-group-tag"の値が0x01の場合，後続の属性は，Operations Attributesグループのメンバでなければならない
"end-of-attributes-tag"(値0x03)は，一つの操作の中で正確に一度出現しなければならない。これは，最終の区切り子タグ("delimiter-tag")でなければならない。操作が文書内容グループをもつ場合，そのグループの中の文書データは，"end-of-attributes-tag"に続かなければならない。
各操作要求及び各操作応答のための"attribute-group"フィールド(その開始は"begin-attribute-group-tag"下位フィールドで記される。)の順番及び存在は，モデル規定で定義されたものでなければならない。更なる詳細については，3.7 "(属性)名"及び附属書A "プロトコル例"を参照すること。
Printerは，"delimiter-tag"(0x00〜0x0Fまでの値)を"value-tag"(0x10〜0xFFの値)とは異なるとして取り扱わなければならない。これによって，Printerが理解しない一つの値とは異なり，理解しない属性グループが全体として存在することが分かる。
表3.3〜表3.6は，属性の最初のオクテットである"values-tag"フィールドに対する値を示す。"values-tag"フィールドは，属性の値の型を指定する。
表3.3は，"values-tag"フィールドに対する"out-of-band"値を規定する。
| タグ値(16進数) | 意味 |
| 0x10 | unsupported(未サポート) |
| 0x11 | 将来のIETF規定における定義に対する'default'のために予約済み |
| 0x12 | unknown(未知) |
| 0x13 | no-value(値なし) |
| 0x14-0x1F | 将来のIETF規定における"out-of-band"値のために予約済み |
表3.4は，"value-tag"フィールドに対する整数値を規定する。
| タグ値(16進数) | 意味 |
| 0x20 | 将来のIETF規定における定義のために予約済み |
| 0x21 | integer |
| 0x22 | boolean |
| 0x23 | enum |
| 0x24-0x2F | 将来のIETF規定における定義に対する整数型のために予約済み |
備考 0x20は，必要とされるかもしれない"一般整数型(generic integer)"のために予約する。
表3.5は，"value-tag"フィールドに対するoctetString値を規定する。
| タグ値(16進数) | 意味 |
| 0x30 | 未指定フォーマットのoctetString |
| 0x31 | dateTime |
| 0x32 | resolution |
| 0x33 | rangeOfInteger |
| 0x34 | 将来のIETF規定における定義のために予約済み |
| 0x35 | textWithLanguage |
| 0x36 | nameWithLanguage |
| 0x37-0x3F | 将来のIETF規定におけるoctetString型の定義のために予約済み |
表3.6は，"value-tag"フィールドに対するcharacter-string値を規定する。
| タグ値(16進数) | 意味 |
| 0x40 | 将来のIETF規定における定義のために予約済み |
| 0x41 | textWithoutLanguage |
| 0x42 | nameWithoutLanguage |
| 0x43 | 将来のIETF規定における定義のために予約済み |
| 0x44 | keyword(キーワード) |
| 0x45 | uri |
| 0x46 | uriScheme |
| 0x47 | charset |
| 0x48 | naturalLanguage |
| 0x49 | mimeMediaType |
| 0x4A-0x5F | 将来のIETF規定における文字列型の定義のために予約済み |
備考1 0x40は，必要とされるかもしれない"一般文字列(generic character-string)"のために予約する。
備考2 属性値は，常に，タグによって明示的に指定される型をもつ。タグ値"nameWithoutLanguage"は，その例とする。属性名は，キーワードである暗黙的な型をもつ。
値0x60〜0xFFは，IETF規定における将来の型定義のために予約する。
タグ0x7Fは，1バイトで利用可能な255個の値を超えて型を拡張するために予約する。0x7Fのタグ値は，値フィールドの最初の4バイトをタグ値として解釈することを示さなければならない。この将来用の拡張は，この特殊なタグを認識しないパーサに影響を与えないことに注意すること。そのタグは，他の未知のタグと同様であって，その値の長さフィールドには，パーサが一度に処理する値を含む，値の長さを指定する。0x00〜0x37777777の値は，将来のIETF規定における定義のために予約済みとする。0x40000000〜0x7FFFFFFFの値は，ベンダ拡張のために予約済みとする。
"name-length"フィールドは，SIGNED-SHORTから構成されなければならない。このフィールドは，すぐ後に続く"name"フィールドの中のオクテット数を指定しなければならない。このフィールドの値は，"name-length"フィールドの2バイトを含めない。例えば，"name"フィールドが"sides"を含むとき，このフィールドの値は5となる。
"name-length"フィールドが0の値をもつ場合は，それに続く"name"フィールドは，空でなければならず，それに続く値は，すぐ前の先行する"attribute-with-one-value"フィールドの中で符号化される属性に対する付加的な値として処理しなければならない。属性グループ内で，二つ以上の属性が同じ名前をもつ場合，その属性グループは，正しくない形式(mal-formed)をしている([RFC2911]の3.1.3を参照)。長さ0の名前は，多値属性だけに対する機構とする。
"name"フィールドは，属性の名前を含まなければならない。モデル規定[RFC2911]は，それら名前を規定している。
"value-length"フィールドは，SIGNED-SHORTから構成されなければならない。このフィールドは，すぐ後に続く"value"フィールドの中のオクテット数を指定しなければならない。このフィールドの値は，"value-length"フィールドの2バイトを含めない。例えば，"value"フィールドが，keyword(text)値の'one-sided'を含む場合，このフィールドの値は9になる。
2進の符号付き整数によって表現されるあらゆる型に対しては，送信側は，正確に4オクテットでその値を符号化しなければならない。
文字列によって表現されるあらゆる型に対しては，送信側は，その文字列のすべての文字を含み，いかなるパディング文字も含まないものとして，その値を符号化しなければならない。
この規定で定義される"value-tag"が"unsupported"などの"out-of-band"値の場合，"value-length"は0とし，"value"は空としなければならない。すなわち，"value-tag"が"out-of-band"値の一つをもつ場合，"value"は意味をもたない。"value-tag"フィールドが将来使用するために予約されている"out-of-band"値の場合，"value-length"は0でなく，"value"は空でなくともよいと，その定義が明確に示していないときには，同じ規則("value-length"は0とし，"value"は空とする。)が成立する。
構文型(これは，"value-tag"フィールドで指定する。)及び属性値の表現の詳細の大部分は，IPPモデル規定で定義される。表3.7は，モデル規定における情報を補強し，3. "操作層の符号化"で定義する六つの基本型を使って，モデル規定の構文型を定義する。ここで，六つの型とは，US-ASCII-STRING，LOCALIZED-STRING，SIGNED-INTEGER，SIGNED-SHORT，SIGNED-BYTE及びOCTET-STRINGとする。
| 属性値の構文 | 符号化 |
| textWithoutLanguage, nameWithoutLanguage | LOCALIZED-STRING |
| textWithLanguage | 次の四つのフィールドから構成されるOCTET-STRING
|
| nameWithLanguage | 次の四つのフィールドから構成されるOCTET-STRING
|
| charset, naturalLanguage, mimeMediaType, keyword, uri及びuriScheme | US-ASCII-STRING |
| boolean | 0x00を'false'及び0x01を'true'とするSIGNED-BYTE |
| integer及びenum | SIGNED-INTEGER |
| dateTime | 内容がRFC1903[RFC1903]の"DateAndTime"によって定義される，11個のオクテットから構成されるOCTET-STRING。 |
| resolution | 二つのSIGNED-INTEGERに一つのSIGNED-BYTEが続く九つのオクテットから構成されるOCTET-STRING。最初のSIGNED-INTEGERは，行方向の解像度の値を含む。2番目のSIGNED-INTEGERは，行送り方向の解像度の値を含む。SIGNED-BYTEは，単位の値を含む。 |
| rangeOfInteger | 二つのSIGNED-INTEGERから構成される八つのオクテット。最初のSIGNED-INTEGERは，下限値を含み，2番目のSIGNED-INTEGERは，上限値を含む。 |
| 1setOf X | 二つ以上の値をもつ属性のための規則に従った符号化。各値Xは，その型を符号化するための規則に従って符号化される。 |
| octetString | OCTET-STRING |
値の属性構文型が，符号化及び"value-tag"の値を決定する。
"data"フィールドは，操作によって要求されるあらゆるデータを含まなければならない。
HTTP/1.1[RFC2616]を，このプロトコルのトランスポート層とする。
操作層は，トランスポート層が次の情報を含むことを仮定して設計された。
プリンタの実装が，IANAが割り当てた既知ポート631(IPPのデフォルトポート)上のHTTPをサポートすることが要求される。 ただし，プリンタの実装が，他のポート上でのHTTPをサポートしてもよい。
各々のHTTP操作は，request-URIが操作のオブジェクトターゲットであって， 各々の要求及び応答のメッセージ本体の"Content-Type"が"application/ipp"でなければならない場合には， POSTメソッドを使用しなければならない。メッセージ本体は，操作層を含まなければならず， 3.2 "符号化の構文"で示された構文をもっていなければならない。 クライアントの実装は，HTTP1.1 [RFC2616]について示されるクライアントの規則に従わなければならない。 プリンタ(サーバ)の実装は， HTTP1.1 [RFC2616]について示される(プリントジョブの)送信元サーバの規則に従わなければならない。
IPPサーバは、受信する要求のための応答を返す。 IPPサーバがエラーを検出するとき, 要求全体を読む前に応答を返してもよい。 IPPサーバのHTTP層がHTTPヘッダを成功裏に処理し終えたとき, それは, IPP応答を送る前のIPPデータを伴わずに, "100 Continue"などの応答をすぐに送ってよい。 クライアントは, IPPサーバからのそれらの多様な応答を予期しなければならない。 HTTP/1.1に関する詳細情報は, HTTP規定[RFC2616]を参照されたい。
HTTPサーバは, IPP要求のためのチャンク化をサポートしなければならない。 IPPクライアントは, HTTP/1.1[RFC2616]に従ってIPP応答のためのチャンク化をサポートしなければならない。
備考 この規則は, POSTメソッドのためのチャンク化をサポートしないHTTP/1.1の不適合実装との矛盾を起こす。 この規則は, CGIスクリプトのためのチャンク化をサポートしないHTTP/1.1の不適合実装との矛盾を起こし得る。
すべてのPrinterオブジェクト及びJobオブジェクトは, 統一資源識別子(URI)[RFC2396]によって識別されるので, 永続して曖昧さなしに参照できる。 すべてのURLはURIの特定の形式であるので, もっと共通性の高い用語であるURIが, この規定の以降において用いられる。しかし, URIの使用は, さらに固有性の高いURLの概念をもカバーすることを意図している。
操作要素には, 2回符号化されるものがある。 1回は, HTTP Request-Lineでのrequest-URIとして符号化され, 2回目は, application/ipp実体の中のREQUIRED操作属性として符号化される。 これらの属性は, 操作のためのターゲットURIであり, printer-uri及びjob-uriと呼ばれる。
備考 ターゲットURIは, 同じIPPオブジェクトを参照する操作の中に, 2回含まれる。しかし, これらの二つのURIは, 厳密に同一でなくてもよい。 一つが相対URIであり, 他が絶対URIであることができる。 HTTP/1.1においては, クライアントは, 絶対URIでなく相対URIを生成し送信することができる。 相対URIは, HTTPサーバの範囲内で資源を識別するが, 方式, ホスト又はポートは含まない。 次の記述は, IPPのHTTP/1.1への対応付けの中で, URLがどのように用いられるかを特徴付ける。
IPP/1.1の規定は, IPP printerオブジェクト又はIPP jobオブジェクトのどちらかを識別するURLの値として, 新方式"ipp"を規定する。 "ipp"方式を用いるIPP属性を, 次に示す。 HTTP層は"ipp"方式をサポートしないので, クライアントは, "ipp"URLを"http"URLにマッピングして, それから Request-Line及びHTTPヘッダを構成するためのHTTP[RFC2616][RFC2617]規則に従わなければならない。 そのマップピングが簡単であるのは, 次の理由による。つまり, "ipp"方式が, "http"方式[RFC2616]のそれと同じプロトコル機能定義のすべてを意味する。ただし, それが印刷サービスを表し, サーバに接続するためにクライアントが用いる暗黙的な(デフォルトの)ポート番号がポート631であることを除く。
5.の以降においては, "ipp-URL"という用語は, 方式が"IPP"であり, 暗黙的な(デフォルトの)ポートが631であるURLを意味する。用語"http-URL"は, 方式が"http"であるURLを意味し, 用語"https-URL"は, 方式が"https"であるURLを意味する。
クライアント及びIPPオブジェクト(つまりサーバ)は, 次のIPP属性におけるipp-URL値をサポートしなければならない。
job attributes:
job-uri
job-printer-uri
printer attributes:
printer-uri-supported
operation attributes:
job-uri
printer-uri
これらの属性のいずれも, printerオブジェクト又はjobオブジェクトを識別する。 ipp-URLは, このリストにおける属性の値として意図されていて, それ以外の属性用ではない。 これらすべての属性は, "uri"の構文型をもつが, "job-more-info"などの"ipp"方式を用いない"uri"の構文型をもつ属性がある。
プリンタがディレクトリサービスを使ってそのURLを登録するとき, プリンタは, ipp-URLを登録しなければならない。
ユーザインタフェースは, この規定の適用範囲外とする。しかし, ソフトウェアが人のユーザに前述の五つの属性のどのipp-URL値を表しても, 人がipp-URLをあるがままに見ることが要求される。
クライアントが要求を送るとき, それは, 次の規則に従って, ターゲットipp-URLをHTTP層のためにターゲットhttp-URLに変換しなければならない。
クライアントは, HTTP[RFC2616] [RFC2617]が規定するとおり, HTTP Request-Line及びHTTPヘッダのどちらにもターゲットhttp-URLを用いなければならない。 しかし, クライアントは, 要求のapplication/ipp本体の中で, "printer-uri"又は"job-uri"操作属性の値のために, ターゲットipp-URLを用いなければならない。 サーバは, 応答のapplication/ipp本体の中で, "printer-uri", "job-uri"又は"printer-uri-supported"属性の値のために, ipp-URLを用いなければならない。
たとえば, IPPクライアントが, ipp-URL "ipp://myhost.com/myprinter/myqueue"に対して直接に(つまりプロキシなしで)要求を送るとき, それは, ホスト"myhost.com"の上のポート631(ipp明示的ポート)にTCPコネクションを開設し, 次のデータを送る。
POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...
別の例では, IPPクライアントが, 前述と同じ要求をプロキシ"myproxy.com"を介して送るとき, それは, プロキシホスト"myhost.com"の上のプロキシポート8080にTCPコネクションを開設し, 次のデータを送る。
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...
それでプロキシは, 前述の"no-proxy"の例と同じヘッダをもつIPP原サーバに接続する。
6. は, IPP/1.1 符号化及びトランスポート規定の, 次に示すIETFの標準手続き拡張及びベンダ拡張のための符号化割当ての手続きを規定する。
これらの拡張は, [RFC2911]の6.が規定する"type2"登録手続きに従う。 IPP/1.1と共に利用する登録済み拡張は, IPP/1.1 符号化及びトランスポート規定に対するクライアント及びIPPオブジェクトの適合性に関するオプションとする。
これらの拡張手続きは, IESG [IANA-CON]が示すガイドラインと連携している。 [RFC2911] 11.は, 検討のために新しい登録を提案する方法を示す。 IANAは, 必要な情報を抜けていたり, [RFC2911]の11.に示す適切なフォーマットに従わない登録要求を拒否するであろう。 IPP/1.1 符号化及びトランスポート規定は, 前述の拡張のどれかを指定する適切なRFCによって拡張してもよい。
国際化に関する情報については, 規定"Internet Printing Protocol/1.1: Model and Semantics"[RFC2911]の"Internationalization Considerations"(国際化への考慮)の節を参照されたい。 この規定は, 追加の課題を加えていない。
IPPモデル及び機能定義の規定[RFC2911]は, 高水準のセキュリティ要求(クライアント認証, サーバ認証及び操作プライバシ)を示す。 クライアント認証は, クライアントが安全な方法でその身元確認をサーバに対して証明する機構とする。 サーバ認証は, サーバが安全な方法でその身元確認をクライアントに対して証明する機構とする。 操作プライバシは、盗聴から操作を保護するための機構として定義される。
8.1は, IPPクライアント及びIPPオブジェクトのためのセキュリティ要件を規定する。
IPPクライアントは, 次をサポートしなければならない。
ダイジェスト認証[RFC2617]
MD5及びMD5-sessが, 実装されサポートされなければならない。
Message Integrity機能は, 使う必要がない。
IPPプリンタは, 次をサポートすることが望ましい。
ダイジェスト認証[RFC2617]
MD5及びMD5-sessが, 実装されサポートされなければならない。
Message Integrity機能は, 使う必要がない。
IPPプリンタがダイジェスト認証をサポート(しなければならないのではなく)することが望ましい理由を, 次に示す。
IPPプリンタは, サーバ認証及び操作プライバシのために, トランスポート層セキュリティ(TLS)[RFC2246]をサポートすることが望ましい。 IPPプリンタは, クライアント認証のためにTLSをサポートしてもよい。 プリンタがTLSをサポートするとき, それは, RFC 2246 [RFC2246]によって必す(須)とされるTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 暗号スイートをサポートしなければならない。 他の暗号スイートはすべて, オプションとする。 IPPプリンタは, チャネルがセキュアであれば, クライアント認証のために基本認証(HTTP/1.1 [RFC2617]に示される。)をサポートしてもよい。 これらの必す(須)の暗号スイートをもつTLSは, このようなセキュアチャネルを提供できる。
IPPクライアントがTLSをサポートするとき, それは, RFC 2246 [RFC2246]によって必す(須)とされるTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 暗号スイートをサポートしなければならない。 他の暗号スイートはすべて, オプションとする。
IPP モデル及び機能定義の規定は, クライアントがプリンタのセキュリティ方針を見出すために利用できる二つのプリンタ属性("uri-authentication-supported"及び"uri-security-supported")を定義する。 IPPモデル規定は, IPP固有のセキュリティへの配慮の輪郭をも描き, IPPプロトコル自体に関するセキュリティの暗示への主要な参照であることが望ましい。 IPP 1.0との後方互換のために, IPPクライアント及びIPPプリンタは, SSL3 [ssl]をサポートしてもよい。 これは, この規定で要求されるセキュリティに追加される。
IPP/1.1は, "Upgrading to TLS Within HTTP/1.1"機構[RFC2817]を用いる。 初期のIPP要求は, 決してTLSを使わない。 サーバが, HTTP応答において合意する限り, クライアントは, HTTP "Upgrade"ヘッダを用いることによって, 安全なTLSコネクションを要求する。TLSへの切替えが生じるのは, サーバがTLSに昇格するためにクライアントの要求を承諾すること, 又はサーバはその応答においてTLSへの切替え依頼することのどちらかによる。 安全な通信は，TLSへ切り替えるためのサーバの応答で始まる。
前の版との適合性を指示することは, この規定の適用範囲外である。しかし, IPP/1.1は, 慎重に設計されており, 前の版をサポートすることを容易にしている。 この規定を作成する時点(1999)で, IPP/1.0のプリンタ実装が次のとおりであることを期待することは, 注目に値する。
IPP/1.1クライアントが次のとおりであることも期待される。
"version-number"パラメタに関する規則を次に示す(3.3参照)。
ターゲットの属性及び応答で提供されるセキュリティ, "version-number"パラメタ及びURL方式に関する規則を次に示す。
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[iana] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets.
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:
Implementer's Guide", Work in Progress.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October, 1989.
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol", RFC 1179, August 1990.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
1808, June 1995.
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997.
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246.
January 1999.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, 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", RFC 2568,
April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, 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", RFC 2616, 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",
RFC 2617, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
備考 これは，TR X 0024:2001 インタネット印刷プロトコル 1.1:
モデル及び機能定義，に一致している。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version
3.02), November 1996.
Robert Herriot, Editor
Xerox Corporation
3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
EMail: robert.herriot@pahv.xerox.com
Sylvan Butler
Hewlett-Packard
11311 Chinden Blvd.
Boise, ID 83714
Phone: 208-396-6000
Fax: 208-396-3457
EMail: sbutler@boi.hp.com
Paul Moore
Peerless Systems Networking
10900 NE 8th St #900
Bellevue, WA 98004
Phone: 425-462-5852
EMail: pmoore@peerless.com
Randy Turner
2Wire, Inc.
694 Tasman Dr.
Milpitas, CA 95035
Phone: 408-546-1273
John Wenn
Xerox Corporation
737 Hawaii St
El Segundo, CA 90245
Phone: 310-333-5764
Fax: 310-333-5514
EMail: jwenn@cp10.es.xerox.com
IPPウェブページ : http://www.pwg.org/ipp/
IPPメーリングリスト: ipp@pwg.org
IPPメーリングリストへ申込むには, 次の電子メールを送ること。
1) majordomo@pwg.orgへ送る。
2) 題名の行は, 空にする。
3) メッセージ本体に次の2行を入れる。
subscribe ipp
end
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
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 Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Information Systems
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Systems
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 - Canon Information Lloyd Young - Lexmark
Systems
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang - Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems