この標準情報(TR)は，1998年6月にInternet Engineering Task Force (IETF)から公表された Internet Printing Protocol 1.0: Encoding and Transport (Internet-Draft)を翻訳し， 技術的内容を変更することなく作成した標準情報(TR)である。
この標準情報(TR)は，IPP操作の符号化規則を含み，トランスポート層及び操作層の2層を規定する。
トランスポート層は，HTTP/1.1の要求(request)及び応答(response)から成る。RFC 2068[rfc2068]が， HTTP/1.1を規定する。この標準情報(TR)は，IPP実装がサポートするHTTPヘッダを規定する。
操作層は，HTTPの要求又は応答におけるメッセージ本体から成る。 規定"インタネット印刷プロトコル/1.0:モデル及びセマンティクス"[ipp-mod]は， そのメッセージ本体のセマンティクス及びサポートされる値を定義する。 この標準情報(TR)は，IPP操作の符号化を規定する。前述の規定[ipp-mod]を，以降で"IPPモデル規定"と呼ぶ。
この標準情報(TR)におけるキーワードの"でなければならない(MUST)"，"してはならない(MUST NOT)"， "必要な(REQUIRED)"，"であることが望ましい(SHOULD)"，"でないことが望ましい(SHOULD NOT)"， "推奨の(RECOMMENDED)"，"してよい(MAY)"及び"オプションの(OPTIONAL)"は， RFC 2119[rfc2119]に示すとおりに規定する。
操作層は，単一の操作要求又は操作応答を含まなければならない。各要求又は各応答は，値及び属性グループの列を含む。 属性グループは，いずれも名前及び値である属性の列から成る。 名前及び値は，最終的にはオクテット列となる。
符号化は，最もプリミティブな型としてのオクテットから成る。オクテットから構成される幾つかの型があるが， 三つの重要な型は，整数，文字列及びオクテット列であって，これらを用いて他のほとんどのデータ型が構成される。 この符号化におけるすべての文字列は，文字が幾つかの文字集合及び幾つかの自然言語に関連付けられる文字の列でなければならない。 文字列は，(読出し順に従った)値の先頭文字が符号化の先頭文字となる"読出し順"でなければならない。 関連するcharsetがUS-ASCIIであって，関連する自然言語が英語である文字列は，以降，US-ASCII-STRINGと呼ぶ。 関連するcharset及び自然言語が，IPPモデル規定に示すとおりに，要求又は応答の中で指定される文字列は， LOCALIZED-STRINGと呼ぶ。オクテット列は，IPPモデル規定で示された順に従った値における先頭文字が符号化の先頭文字となる "IPPモデル規定順"でなければならない。この符号化の各整数は，2の補数のバイナリ符号化による符号付き整数として， ビッグエンディアンフォーマットで符号化しなければならない。これは，"ネットワーク順"及び"最上位バイト先頭"とも呼ぶ。 一つの整数のオクテット数は，プロトコル中での使用に応じて，1，2又は４とする。以降SIGNED-BYTEと呼ぶ1オクテット整数は， 版番号及びタグのフィールドで用いる。以降SIGNED-SHORTと呼ぶ2バイト整数は，operation-id, status-code及びlength のフィールドで用いる。以降SIGNED-INTEGERと呼ぶ4バイト整数は，値のフィールド及びシーケンス番号で用いる。
以降の二つの節では，次の二つの方法で操作層を表現する。
操作の要求及び応答の符号化は，図3.1のとおりに構成される。
----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------------------- | xxx-attributes-tag | 1 byte | ----------------------------------------------- |-0 or more | xxx-attribute-sequence | n bytes | ----------------------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | q bytes - optional ----------------------------------------------- 図3.1 操作の要求及び応答の符号化 １
xxx-attributes-tag及びxxx-attribute-sequenceは，操作(operation)，ジョブ(job)，プリンタ(printer)及び未サポート(unsupported) となる"xxx"の四つの異なる値を表す。xxx-attributes-tag及びxxx-attribute-sequenceは，モデル規定における属性グループを表す。 xxx-attributes-tagは，属性グループを識別し，xxx-attribute-sequenceは，属性を含む。
xxx-attributes-tag及びxxx-attribute-sequenceの見込まれているシーケンスは，各操作要求及び操作応答についてIPPモデル規定で規定する。
要求又は応答は，たとえunsupported-attributes-tag以外の属性がなくても，その要求又は応答について定義される各xxx-attributes-tag を含む。unsupported-attributes-tagは，unsupported-attribute-sequenceがnon-emptyのときだけ，存在しなければならない。 要求の受信側は，次の等価な空の属性グループとして処理できなければならない。
データは，幾つかの操作からは省略されるが，end-of-attributes-tagは，データが省略されたときも存在する。 xxx-attributes-tags及びend-of-attributes-tagを`delimiter-tags'と呼ぶことに注意されたい。
備考 前述のxxx-attribute-sequenceは，次の規則に従って0バイトで構成されてもよい。
xxx-attributes-sequenceは，0個以上のcompound-attributesから成る。
----------------------------------------------- | compound-attribute | s bytes - 0 or more ----------------------------------------------- 図3.2 compound-attributeの符号化
compound-attributesは，0個以上の追加の値が後に続く，単一の値をもつ属性から成る。
備考 `compound-attribute'は，IPPモデル規定の中の単一の属性を表す。 `additional value'の構文は，2個以上の値をもつ属性のためのものとする。
各属性は，図3.3のとおりに構成される。
----------------------------------------------- | 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.3 属性の符号化
追加の値は，図3.4のとおりに構成される。
----------------------------------------------------------- | value-tag | 1 byte | ----------------------------------------------- | | name-length (value is 0x0000) | 2 bytes | ----------------------------------------------- |-0 or more | value-length (value is w) | 2 bytes | ----------------------------------------------- | | value | w bytes | ----------------------------------------------------------- 図3.4 追加の値の符号化
備考 追加の値は，name-lengthが0となる属性に似ている。
構文解析ループの観点から，符号化は図3.5のとおりに構成される。
----------------------------------------------- | 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 | 2 bytes - required ----------------------------------------------- | data | y bytes - optional ----------------------------------------------- 図3.5 操作の要求及び応答の符号化 ２タグの値は，そのタグに続くバイトが次のものかどうかを決定する。
次の構文は，`strings of literals'が大文字と小文字とを区別しなければならないことを除いて， ABNF [rfc2234]とする。例えば，`a'は小文字の`a'を意味し，大文字の`A'ではない。 さらに，SIGNED-BYTE及びSIGNED-SHORTのフィールドは，値の範囲を示す`%x'値として表現される。
ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id
*(xxx-attributes-tag xxx-attribute-sequence) end-of-attributes-tag data
ipp-response = version-number status-code request-id
*(xxx-attributes-tag xxx-attribute-sequence) end-of-attributes-tag data
xxx-attribute-sequence = *compound-attribute
xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
printer-attributes-tag / unsupported-attributes-tag
version-number = major-version-number minor-version-number
major-version-number = SIGNED-BYTE ; 初期値は，%d1
minor-version-number = SIGNED-BYTE ; 初期値は，%d0
operation-id = SIGNED-SHORT ; 以降で定義するモデルから対応付ける
status-code = SIGNED-SHORT ; 以降で定義するモデルから対応付ける
request-id = SIGNED-INTEGER ; 値は正の数
compound-attribute = attribute *additional-values
attribute = value-tag name-length name value-length value
additional-values = 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
operation-attributes-tag = %x01 ; 1のタグ
job-attributes-tag = %x02 ; 2のタグ
printer-attributes-tag = %x04 ; 4のタグ
unsupported- attributes-tag = %x05 ; 5のタグ
end-of-attributes-tag = %x03 ; 3のタグ
value-tag = %x10-FF
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
DIGIT = %x30-39 ; "0"〜"9"
LALPHA = %x61-7A ; "a"〜"z"
BYTE = %x00-FF
OCTET-STRING = *BYTE
構文は，xxx-attributes-tagに続くxxx-attribute-sequenceが空のときに，xxx-attributes-tagが存在することを許容する。 構文は，job-objectsに関して属性が返されないGet-Jobsの応答について，この方法を許容することを規定する。 (Get-Jobsの応答の場合を除き)属性がなければ送信側はxxx-attributes-tagを送出しないことが推奨されるが， 受信側はその構文を復号できなくてはならない。
版番号は，主版番号及び副版番号から成り，それらはいずれもSIGNED-BYTEによって表現される。 この規定が示すプロトコルは，主版番号1(0x01)及び副版番号0(0x00)をもつ。これらの2バイトのABNFは，%x01.00でなければならない。
操作idは，IPPモデル規定の中で列挙として定義される。操作id列挙値は，SIGNED-SHORTとして符号化されなければならない。
備考 0x4000〜0xFFFFの値は，私的な拡張のために予約する。
状態コードは，IPPモデル規定の中で列挙として定義される。状態コード列挙値は，SIGNED-SHORTとして符号化しなければならない。
状態コードは，IPPモデル規定における操作属性とする。プロトコルにおいては，状態コードは操作属性の外の特別な位置に存在する。
IPP状態コードが返される場合は，HTTP状態コードは200(OK)でなければならない。それ以外のHTTP状態コード値の場合，HTTP応答は， IPP message-bodyを含んではならない。そこで，IPP状態コードは返されない。
要求idは，クライアントに対して応答を要求にマッチさせる。HTTPにおいてこの機構は不要であるが， application/ipp実体本体が別の文脈で使われるときに，有効となる。
応答における要求idは，対応する要求において受信した要求idの値でなければならない。 クライアントは，クライアントが応答で返された要求idと共に行う処理に応じて， 一意な値又は一定な値(例えば 1)に，各要求における要求idを設定できる。要求idの値は，0より大きくなければならない。
タグには，二つの種類が存在する。
表3.1は，区切り子タグに対する値を規定する。
| タグ値(16進数) | 区切り子 |
| 0x00 | 予約済み |
| 0x01 | operation-attributes-tag | 0x02 | job-attributes-tag |
| 0x03 | end-of-attributes-tag |
| 0x04 | printer-attributes-tag |
| 0x05 | unsupported-attributes-tag |
| 0x06-0x0e | 将来の区切り子のために予約済み |
| 0x0F | 将来のchunking-end-of-attributes-tagのために予約済み |
xxx-attributes-tagがプロトコルに出現した場合は，次の区切り子タグまでのゼロ以上の続く属性が， IPPモデル規定で定義されるとおりにグループxxxに属する属性となることを意味する。 ここで，xxxは，operation(操作)，job(ジョブ)，printer(プリンタ)又はunsupported(未サポート)とする。
このxxxに対する代入は，次を意味する。 operation-attributes-tagがプロトコルに出現する場合は，次の区切り子タグまでのゼロ以上の続く属性を， IPPモデル規定で定義するとおりに，操作属性とすることを意味しなければならない。 job-attributes-tagがプロトコルに出現する場合は，次の区切り子タグまでのゼロ以上の続く属性を， IPPモデル規定で定義するとおりに，ジョブ属性とすることを意味しなければならない。 printer-attributes-tagがプロトコルに出現する場合は，次の区切り子タグまでのゼロ以上の続く属性を， IPPモデル規定で定義するとおりに，プリンタ属性とすることを意味しなければならない。 unsupported-attributes-tagがプロトコルに出現する場合は，次の区切り子タグまでのゼロ以上の続く属性を， IPPモデル規定で定義するとおりに，未サポート属性とすることを意味する。
operation-attributes-tag及びend-of-attributes-tagは，それぞれ，ちょうど1回だけ一つの操作内に出現しなければならない。 operation-attributes-tagは，最初のタグ区切り子でなければならず，end-of-attributes-tagは，最後のタグ区切り子でなければならない。 操作がdocument-contentグループをもつ場合は，そのグループ内の文書データには，end-of-attributes-tagが続かなければならない。
ここで定義する他の三つのxxx-attributes-tagは，それぞれ，一つの操作内ではオプションとし， 各々，一つの操作内に多くとも1回だけ出現しなければならない。 ただし，Get-Jobs応答におけるjob-attributes-tagは例外とする。この場合は，ゼロ回以上出現してもよい。
各操作要求及び各操作応答に対する区切り子タグの順番及び存在は，IPPモデル規定で定義するものでなければならない。 詳細は，3.9"属性名"及び"附属書A プロトコル例"を参照すること。
Printerは，Printerが理解しない一つの値が存在するのではなく，理解しない属性グループが全体として存在すると分かるために， 予約された値タグとは違う方法で予約された区切り子タグを処理しなければならない。
以降の幾つかの表は，属性の最初のオクテットとなるvalues-tagに対する値を示す。 values-tagは，属性の値の型を指定する。表3.2は，values-tagに対する"out-of-band"値を規定する。
| タグ値(16進数) | 意味 |
| 0x10 | unsupported(未サポート) |
| 0x11 | 将来の`default'のために予約済み |
| 0x12 | unknown(未知) |
| 0x13 | no-value(値無し) |
| 0x14-0x1F | 将来の"out-of-band"値のために予約済み |
"unsopported"値は，プリンタがサポートしない属性に対するエラー応答のattribute-sequence内で使用しなければならない。 "default"値は，デフォルト値に値を設定する将来の使用のために予約する。"unknown"値は，サポートする属性に対して， その値が一時的に未知の場合に，使用する。"no-value"値は，値が割り当てられていないサポートする属性に対して使用する。 例えば，"job-k-octets-supported"は，実装がこの属性をサポートするが，管理者がプリンタが限界をもつと構成していない場合には， 値をもたない。
表3.3は，value-tagに対する整数型値を規定する。
| タグ値(16進数) | 意味 |
| 0x20 | 予約済み |
| 0x21 | integer |
| 0x22 | boolean |
| 0x23 | enum |
| 0x24-0x2F | 将来の整数型のために予約済み |
備考 0x20は，必要とされるかもしれない"一般整数型(generic integer)"のために予約する。
表3.4は，value-tagに対するoctetString値を規定する。
| タグ値(16進数) | 意味 |
| 0x30 | フォーマットを指定しないoctetString |
| 0x31 | dateTime |
| 0x32 | resolution |
| 0x33 | rangeOfInteger |
| 0x34 | (将来における)collectionのために予約済み |
| 0x35 | textWithLanguage |
| 0x36 | nameWithLanguage |
| 0x37-0x3F | 将来のoctetString型のために予約済み |
表3.5は，value-tagに対するcharacter-string値を規定する。
| タグ値(16進数) | 意味 |
| 0x40 | 予約済み |
| 0x41 | textWithoutLanguage |
| 0x42 | nameWithoutLanguage |
| 0x43 | 予約済み |
| 0x44 | キーワード |
| 0x45 | uri |
| 0x46 | uriScheme |
| 0x47 | charset |
| 0x48 | naturalLanguage |
| 0x49 | mimeMediaType |
| 0x4A-0x5F | 将来の文字列型のために予約済み |
備考 1 0x40は，必要とされるかもしれない"一般文字列(generic character-string)" のために予約する。
備考 2 属性値は，常に，タグによって明示的に指定される型をもつ。 タグ値"nameWithoutLanguage"は，その例とする。属性名は，キーワードである暗黙的な型をもつ。
値0x60-0xFFは，将来の型のために予約する。私的な拡張のために割り付けられた値は存在しない。 新しい型は，タイプ2のプロセスを通じて，登録しなければならない。
タグ0x7Fは，1バイトで可能な255の値を超えて型を拡張するために予約する。 0x7Fのタグ値は，値フィールドの最初の4バイトをタグ値として解釈することを意味しなければならない。 この将来の拡張は，この特殊なタグを意識しないパーサに影響を与えないことに注意。 そのタグは，他の未知のタグと同様となり，その値の長さフィールドには，パーサが一度に処理する値を含む値の長さを指定する。 これら4バイトのタグ値すべては，現在，実験的な使用に対して，値0x40000000-0x7FFFFFFFが予約されている以外は， 割り付けられていない。
name-lengthフィールドは，SIGNED-SHORTから構成されなければならない。 このフィールドは，name-lengthフィールドに続くnameフィールド内のオクテット数を指定する。 ただし，name-lengthフィールドの2バイトは含めない。
name-lengthフィールドがゼロの値をもつ場合は，それに続くnameフィールドは，空でなければならず， それに続くvalueは，先行する属性に対する付加的な値として処理しなければならない。 attribute-sequenceにおいて，二つの属性が同じ名前をもつ場合は，最初に出現したものを無視しなければならない。 長さゼロのnameは，複数値属性に対する機構だけとする。
操作要素の中には，IPPモデル規定[ipp-mod]ではパラメタと呼ばれているものがある。 それらは，特定の位置で符号化しなければならず，操作属性として出現してはならない。 これらのパラメタには，次がある。
すべてのPrinterオブジェクト及びJobオブジェクトは，資源一様識別子(Uniform Resource Identifier，以降URI)[rfc1630] によって識別され，その結果として，永続的に及びあいまい性なく参照できる。URIの概念は役に立つ概念だが， その概念がより安定するまで(つまり，より完全に定義され，より広く配備されるまで)， IPPオブジェクトのために使用されるURIは，実際のところは，URL[rfc1738][rfc1808]になるものと予想される。 URLは，すべて，URIの特殊化した形式なので，より一般的な用語URIをこの文書の残りで使用するが，その使用法が， URLというより特殊な概念にも同様に適用されることを意図している。
操作要素の中には，HTTP Request-Lineにおけるrequest-URIとして1回， application/ipp実体におけるREQUIRED操作属性としてもう1回，すなわち， 2回符号化するものがある。これらの属性は，操作に対するターゲットURIとする。
備考 ターゲットURIは，一つの操作に2回含まれるので，潜在的には，これら二つの値は， 同じIPPオブジェクトを参照することになる。しかし，文字どおりに同じというわけではない。 一つは相対的URIであって，他方は絶対的URIということが可能となる。HTTP/1.1では， クライアントが，絶対的URIよりもむしろ相対的URIを生成し送ることを可能とする。 相対的URIは，HTTPサーバの適用範囲において，資源を識別するが，スキーム，ホスト又は ポートは含まない。次は，URLをIPPからHTTP/1.1への対応付けにおいて使用する望ましい 方法を特徴付ける。
IPPモデル規定は，残りの属性を，各操作要求及び操作応答に対するグループに整理している。 これらグループはそれぞれ，適切なxxx-attibutes-tagに先行されるxxx-attribute-sequence によって，プロトコルで表現されなければならない。表3.6及び"附属書A プロトコル例"を参照すること。 さらに，プロトコル内のこれらxxx-attributes-tags及びxxx-attribute-sequenceの順番は， IPPモデル規定のものと同じでなければならない。 ただし，各xxx-attribute-sequence内の属性の順番は，指定してはならない。 表3.6は，モデル規定のグループ名をxxx-attribute-sequenceへと対応付ける。
| モデル規定グループ | xxx-attributes-sequence |
| Operation属性 | operations-attributes-sequence |
| Job Template属性 | job-attributes-sequence |
| Job Object属性 | job-attributes-sequence |
| Unsupported属性 | unsupported- attributes-sequence |
| Requested属性(Get-Job-Attributes) | job-attributes-sequence |
| Requested属性(Get-Printer-Attributes) | printer-attributes-sequence |
| Document Content | 先に示した特殊な位置において |
操作が二つ以上のジョブオブジェクトからの属性(例えば，Get-Jobs応答)を含む場合は， 各ジョブオブジェクトからの属性は，別々のjob-attribute-sequenceに存在しなければならない。 例えば，i番目のジョブオブジェクトからの属性は，i番目のjob-attribute-sequenceに存在する，などとする。 この規則の適用を示す表に関しては，"附属書A プロトコル例"を参照すること。
各属性値は，値の長さに続く値に存在するオクテットの数を指定しなければならないSIGNED-SHORTによって先行されなければならない。 ただし，オクテットの数に，長さを指定する2バイトは含めない。
2進の符号付き整数によって表現される任意の型に対して，送信側は，ちょうど4オクテットで値を符号化しなければならない。
文字列によって表現される任意の型に対して，その値を，送信側は，その文字列のすべての文字を含み， いかなるパディング文字も含まないものとして符号化する。
value-tagが"unsupported"などの"out-of-band"値を含む場合は，value-lengthは，0でなければならず，値は，空とする。 すなわち，value-tagが"out-of-band"値をもつ場合には，その値は意味をもたない。 この場合，クライアントがゼロでないvalue-lengthをもつ応答を受信したときには，クライアントは， その値フィールドを無視しなければならない。 さらにこの場合，プリンタがゼロでないvalue-lengthをもつ要求を受信したときには， プリンタは，その要求を拒否しなければならない。
構文型及びそれらの表現の詳細の大部分は，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"によって定義される，七つのオクテットから構成される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を，このプロトコルのトランスポート層とする。
操作層は，トランスポート層が次の情報を含むことを仮定して設計された。
プリンタの実装が，IANAが割り当てた既知ポート631(IPPのデフォルトポート)上のHTTPをサポートすることが要求される。 ただし，プリンタの実装が，他のポート上でのHTTPを追加でサポートしてもよい。 さらに，プリンタは，プライバシ保護のために他のポートをもたなければならない場合があるかもしれない。 (5."セキュリティへの配慮"を参照すること。）
備考 1 ポート631がIPPのデフォルトであったとしても，ポート80は，HTTP URIのためのデフォルトのままとする。 したがって，ポート631を使用するプリンタのためのURIは，例えば"http://forest:631/pinetree"のように， 明示的なポートを含まなければならない。
備考 2 RFC 2068(HTTP/1.1)に整合して，IPPに対するHTTP URIは，暗黙のうちにポート80を参照する。 URIが他のポートを参照する場合は，ポート番号を明示的にURI内で指定しなければならない。
各々のHTTP操作は，request-URIが操作のオブジェクトターゲットであって， 各々の要求及び応答のメッセージ本体の"Content-Type"が"application/ipp"でなければならない場合には， POSTメソッドを使用しなければならない。メッセージ本体は，操作層を含まなければならず， 3.2 "符号化の構文"で示された構文をもっていなければならない。 クライアントの実装は，RFC 2068[rfc2068]で示されたクライアントの規則に従わなければならない。 プリンタ(サーバ)の実装は，RFC 2068で示された(プリントジョブの)送信元サーバの規則に従わなければならない。
IPP層は，チャンク化を扱う必要はない。CGIスクリプトの文脈で，HTTP層は，受信したデータ内の任意のチャンク情報を除去する。
クライアントは，すべての要求を送ってしまうまで，IPPサーバからの応答を期待してはならない。 しかし，クライアントは，IPPサーバがすべてのデータを受信する前に送信するかもしれないエラー応答を待ち受けてもよい。 この場合，クライアントは，データをチャンク化する場合には，すべてのデータを送信する前に要求を終了させるために， 未完成の長さ0のチャンクを送信できる。要求が何らかの理由で停止する場合，クライアントは， サーバに問い合わせるために他の接続を開始して，停止の理由を決定してもよい。
4.1〜4.4では，IPPクライアント又はIPPサーバで使用するすべてのHTTPヘッダの表を示す。 次に，これらの表の各欄の説明を示す。
"要求ヘッダ"のための表は，応答の欄をもたず，"応答ヘッダ"のための表は，要求の欄をもたない。
次に，"要求クライアント"及び"クライアント"，並びに"応答サーバ"及び"サーバ"の各欄の値の説明を示す。
次に，"応答クライアント"及び"クライアント"，並びに"要求サーバ"及び"サーバ"の各欄の値の説明を示す。
一般ヘッダを，表4.1に示す。
| 一般ヘッダ | 要求クライアント | 要求サーバ | 応答サーバ | 応答クライアント | 値及び条件 | Chache-Control | must | not | must | not | "no-cache"だけ。 |
| Connection | must-if | must | must-if | must | "close"だけ。クライアント及びサーバの両方が，操作の並びの持続期間中，接続を保持することが望ましい。 クライアント及びサーバは，その並びに，最後の操作のヘッダを含まなければならない。 |
| Date | may | may | must | may | RFC 2068で参照されるRFC 1123[rfc1123]に従う。 |
| Pragma | must | not | must | not | "no-cache" だけ。 |
| Transfer-Encoding | must-if | must | must-if | must | "chunked"だけ。ヘッダは，Content-Lengthがない場合，存在しなければならない。 |
| Upgrade | not | not | not | not | |
| Via | not | not | not | not |
要求ヘッダを，表4.2に示す。
| 要求ヘッダ | クライアント | サーバ | 値及び条件 |
| Accept | may | must | "application/ipp"だけ。この値は，クライアントがそれを省略した場合，デフォルトとなる。 |
| Accept-Charset | not | not | Charset情報は，application/ipp実体の中に存在する。 |
| Accept-Encoding | may | must | RFC 2068[rfc2068]及びcontent-codingsのIANA登録に従う，並びに空。 |
| Accept-Language | not | not | 言語情報は，application/ipp実体の中に存在する。 |
| Authorization | must-if | must | RFC 2068に従う。クライアントは，401 "Unauthorized"応答を受信し "Proxy-Authenticate"ヘッダを受信しない場合にこのヘッダを送信する。 |
| From | not | not | RFC 2068に従う。RFCでは，このヘッダをユーザの承認付きで送信することを勧めているので，それほどは有効ではない。 |
| Host | must | must | RFC 2068に従う。 |
| If-Match | not | not | |
| If-Modified-Since | not | not | |
| If-None-Match | not | not | |
| If-Range | not | not | |
| If-Unmodified-Since | not | not | |
| Max-Forwards | not | not | |
| Proxy-Authorization | must-if | not | RFC 2068に従う。クライアントは，401 "Unauthorized"応答及び"Proxy-Authenticate"ヘッダを受信した場合， このヘッダを送信しなければならない。 |
| Range | not | not | |
| Referer | not | not | |
| User-Agent | not | not |
応答ヘッダを，表4.3に示す。
| 応答ヘッダ | サーバ | クライアント | 応答の値及び条件 | Accept-Ranges | not | not |
| Age | not | not | |
| Location | must-if | may | RFC 2068に従う。URIがリダイレクションを必要とする場合。 |
| Proxy-Authenticate | not | must | RFC 2068に従う。 |
| Public | may | may | RFC 2068に従う。 |
| Retry-After | may | may | RFC 2068に従う。 |
| Server | not | not | |
| Vary | not | not | |
| Warning | may | may | RFC 2068に従う。 |
| WWW-Authenticate | must-if | must | RFC 2068に従う。サーバがクライアントを認証する必要がある場合。 |
実体ヘッダを，表4.4に示す。
| 実体ヘッダ | 要求クライアント | 要求サーバ | 応答サーバ | 応答クライアント | 値及び条件 |
| Allow | not | not | not | not | |
| Content-Base | not | not | not | not | |
| Content-Encoding | may | must | must | must | RFC 2068及び内容の符号化に関するIANA登録に従う。 |
| Content-Language | not | not | not | not | Application/ippは，言語を操作する。 |
| Content-Length | must-if | must | must-if | must | RFC 2068に従ったmessage-bodyの長さ。ヘッダは，Transfer-Encodingが存在しない場合，存在しなければならない。 |
| Content-Location | not | not | not | not | |
| Content-MD5 | may | may | may | may | RFC 2068に従う。 |
| Content-Range | not | not | not | not | |
| Content-Type | must | must | must | must | "application/ipp"だけ。 |
| ETag | not | not | not | not | |
| Expires | not | not | not | not | |
| Last-Modified | not | not | not | not |
IPPモデル規定は，トランスポート層セキュリティ(TLS)バージョン1.0を実装するものとして， "プライバシ"をもつIPP実装を定義する。
TLSは，(暗号化を通しての)プライバシ及び相互認証のような特徴に関して，IPPセキュリティのための要件を満たす。
IPPモデル規定は，同様にIPP固有のセキュリティへの配慮の概要を示し， IPPプロトコル自体に関するセキュリティ示唆のための主要な参照となることが望ましい。
IPPモデル規定は，HTTP 1.1の中でIPPメッセージを転送することに対して，標準的な方法で実装するものとして， "認証"をもつIPP実装を定義する。これらはHTTP 1.1の規定[rfc2068]及びダイジェスト認証の拡張[rfc2069] で示されるセキュリティへの配慮を含む。
現在のHTTPインフラストラクチャは，TCPポート80上でHTTPをサポートする。IPPサーバ実装は，IANAが割り当てた既知ポート631 (IPPデフォルトポート)上で，HTTPを用いたIPPサービスを提供しなければならない。 IPPサーバ実装は、このポートに加えて他のポートをサポートしてもよい。
IPPモデル規定の中のIPPセキュリティ概念の詳細な記述を参照されたい。
[rfc822] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", RFC 822, August 1982.
[rfc1123] Braden, S., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October, 1989,
[rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol" RFC 1179, August 1990.
[rfc1630] T. Berners-Lee, "Universal Resource Identifiers in WWW:
A Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the Word-Wide Web", RFC 1630,
June 1994.
[rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and
Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
[rfc1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform
Resource Locators (URL)", RFC 1738, December, 1994.
[rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543,
October 1993.
[rfc1766] H. Alvestrand, " Tags for the Identification of
Languages", RFC 1766, March 1995.
[rfc1808] R. Fielding, "Relative Uniform Resource Locators",
RFC1808, June 1995 [rfc1903} J. Case, et al. "Textual
Conventions for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1903, January 1996.
[rfc2046] N. Freed & N. Borenstein, Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types. November 1996.
(Obsoletes RFC1521, RFC1522, RFC1590), RFC 2046.
[rfc2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet
Mail Extension (MIME) Part Four: Registration Procedures.
November 1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521,
RFC1522, RFC1590) (Also BCP0013), RFC 2048.
[rfc2068] R Fielding, et al, "Hypertext Transfer Protocol "
HTTP/1.1" RFC 2068, January 1997
[rfc2069] J. Franks, et al, "An Extension to HTTP: Digest Access
Authentication" RFC 2069, January 1997
[rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 , March 1997
[rfc2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Continuations",
RFC 2184, August 1997,
[rfc2234] D. Crocker et al., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234. November 1997.
[char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work
in Progress (draft-freed-charset-reg-02.txt).
[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
[ipp-lpd] Herriot, R., Hastings, T., Jacobs, N., Martin, J.,
"Mapping between LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-
map-04.txt, June 1998.
[ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R.,
Powell, P., "Internet Printing Protocol/1.0: Model and
Semantics" draft-ietf-ipp-mod-10.txt, June, 1998.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp-
pro-06.txt, June, 1998.
[ipp-rat] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", draft-ietf-ipp-
rat-03.txt, June, 1998.
[ipp-req] Wright, D., "Design Goals for an Internet Printing
Protocol", draft-ietf-ipp-req-02.txt, June, 1998.
Robert Herriot (editor) Paul Moore Sun Microsystems Inc. Microsoft 901 San Antonio Road, MPK-17 One Microsoft Way Palo Alto, CA 94303 Redmond, WA 98053 Phone: 650-786-8995 Phone: 425-936-0908 Fax: 650-786-7077 Fax: 425-93MS-FAX Email: robert.herriot@eng.sun.com Email: paulmo@microsoft.com Sylvan Butler Randy Turner Hewlett-Packard Sharp Laboratories 11311 Chinden Blvd. 5750 NW Pacific Rim Blvd Boise, ID 83714 Camas, WA 98607 Phone: 208-396-6000 Phone: 360-817-8456 Fax: 208-396-3457 Fax: : 360-817-8436 Email: sbutler@boi.hp.com Email: rturner@sharplabs.com IPPメーリングリスト： ipp@pwg.org IPPメーリングリスト申込み： ipp-request@pwg.org IPPウェブページ： http://www.pwg.org/ipp/
Chuck Adams - Tektronix Harry Lewis - IBM
Ron Bergman - Dataproducts Tony Liao - Vivid Image
Keith Carter - IBM David Manchala - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Jeff Copeland - QMS Jay Martin - Underscore
Roger Debry - IBM Larry Masinter - Xerox
Lee Farrell - Canon Ira McDonald, Xerox
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard
Charles Gordon - Osicom Patrick Powell - SDSU
Brian Grimshaw - Apple Jeff Rackowitz - Intermec
Jerry Hadsell - IBM Xavier Riley - Xerox
Richard Hart - Digital Gary Roberts - Ricoh
Tom Hastings - Xerox Stuart Rowley - Kyocera
Stephen Holmstead Richard Schneider - Epson
Zhi-Hong Huang - Zenographics Shigern Ueda - Canon
Scott Isaacson - Novell Bob Von Andel - Allegro Software
Rich Lomicka - Digital William Wagner - Digital Products
David Kellerman - Northlake Jasper Wong - Xionics
Software
Robert Kline - TrueSpectra Don Wright - Lexmark
Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox
Takami Kurono - Brother Lloyd Young - Lexmark
Rich Landau - Digital Peter Zehler - Xerox
Greg LeClair - Epson Frank Zhao - Panasonic
Steve Zilles - Adobe