標準情報(TR)  TR X 0017:2002

インタネット印刷プロトコル 1.1: 符号化及びトランスポート

Internet Printing Protocol 1.1: Encoding and Transport



序文

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

1. 適用範囲

この標準情報(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になったに過ぎない。

2. 定義

この標準情報(TR)におけるキーワードの"でなければならない(MUST)","してはならない(MUST NOT)","必要な(REQUIRED)","であることが望ましい(SHOULD)","でないことが望ましい(SHOULD NOT)","推奨の(RECOMMENDED)","してよい(MAY)"及び"オプションの(OPTIONAL)"は,RFC 2119[RFC2119]に示すとおりに規定する。

3. 操作層の符号化

操作層は,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 符号化の図式

3.1.1 要求及び応答

操作の要求又は応答は,図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"フィールドが存在するかどうかに拘わらず,各操作の要求及び応答を規定している。

3.1.2 属性グループ(attribute group)

各"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"と呼ばれる。

3.1.3 属性(attribute)

"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"フィールドで符号化される。

3.1.4 単一値をもつ属性(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"フィールドは,五つの下位フィールドで符号化される。

3.1.5 付加値(additional-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"は,四つの下位フィールドに符号化される

3.1.6 要求又は応答の符号化の代替図式

"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"の各型の後にどのフィールドを期待するかを,次に示す。

3.2 符号化の構文

次の構文は,'リテラルの文字列'が大文字と小文字とを区別しなければならないことを除いて,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のタグ

3.3 属性グループ(attribute-group)

各"attribute-group"フィールドは,0個以上の"attribute"下位フィールドが続く"begin-attribute-group-tag"フィールドと一緒に符号化されなければならない。

表3.1は,モデル規定でのグループ名を"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"フィールドは,キューの中にあること以外は情報を利用可能ではないジョブがキューにあることを,受け手に伝える。

3.4 必須パラメタ

幾つかの操作要素は,モデル規定[RFC2911]の中で,パラメタと呼ばれている。それらは,特別な位置で符号化されなければならず,操作属性としては現れてはならない。これらのパラメタは,3.4.1以降で示される。

3.4.1 版番号(version-number)

"version-number"フィールドは,主版番号及び副版番号から成り,それらはいずれもSIGNED-BYTEによって表現されなければならない。主版番号は,符号化の最初のバイトであって,副版番号は,符号化の2番目のバイトでなければならない。この規定が示すプロトコルは,主版番号1(0x01)及び副版番号1(0x01)をもたなければならない。これらの2バイトのABNFは,%x01.01でなければならない。

3.4.2 操作ID(operation-id)

"operation-id"フィールドは,モデル規定の中で定義される操作ID(operation-id)値を含まなければならない。その値は,SIGNED-SHORTとして符号化されなければならず,操作要求の符号化の3番目及び4番目のバイトに存在しなければならない。

3.4.3 状態コード(status-code)

"status-code"フィールドは,モデル規定の中で定義される状態コード(status-code)値を含まなければならない。その値は,SIGNED-SHORTとして符号化されなければならず,操作応答の符号化の3番目及び4番目のバイトに存在しなければならない。

状態コードは,モデル規定では操作属性になっている。プロトコルにおいては,状態コードは操作属性の外の特別な位置に存在する。

IPP状態コードが返される場合,HTTP Status-Codeは,200(successful-ok)でなければならない。それ以外のHTTP Status-Code値の場合には,HTTP応答は,IPPのメッセージ本体を含んではならない。そこで,IPP状態コードは返されない。

3.4.4 要求ID(request-id)

"request-id"フィールドは,モデル規定で定義されるとおりの要求ID(request-id)値を含まなければならない。その値は,SIGNED-INTEGERとして符号化されなければならず,符号化の5番目〜8番目のバイトに存在しなければならない。

3.5 タグ

タグには,次の二つの種類が存在する。

区切り子タグ
プロトコルの主要な部分,すなわち,属性及びデータ,を区切る。
値タグ
各属性値の型を指定する。

3.5.1 区切り子タグ

表3.2は,区切り子タグに対する値を規定する。

表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.5.2 値タグ

表3.3表3.6は,属性の最初のオクテットである"values-tag"フィールドに対する値を示す。"values-tag"フィールドは,属性の値の型を指定する。

表3.3は,"values-tag"フィールドに対する"out-of-band"値を規定する。

表3.3 out-of-bandの値タグ

タグ値(16進数) 意味
0x10 unsupported(未サポート)
0x11 将来のIETF規定における定義に対する'default'のために予約済み
0x12 unknown(未知)
0x13 no-value(値なし)
0x14-0x1F 将来のIETF規定における"out-of-band"値のために予約済み

表3.4は,"value-tag"フィールドに対する整数値を規定する。

表3.4 整数値の値タグ

タグ値(16進数) 意味
0x20 将来のIETF規定における定義のために予約済み
0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F 将来のIETF規定における定義に対する整数型のために予約済み

備考 0x20は,必要とされるかもしれない"一般整数型(generic integer)"のために予約する。

表3.5は,"value-tag"フィールドに対するoctetString値を規定する。

表3.5 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値を規定する。

表3.6 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の値は,ベンダ拡張のために予約済みとする。

3.6 名前長(name-length)

"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の名前は,多値属性だけに対する機構とする。

3.7 (属性)名[(attribute) name]

"name"フィールドは,属性の名前を含まなければならない。モデル規定[RFC2911]は,それら名前を規定している。

3.8 値の長さ(value length)

"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"は空とする。)が成立する。

3.9 (属性)値[(attribute) value]

構文型(これは,"value-tag"フィールドで指定する。)及び属性値の表現の詳細の大部分は,IPPモデル規定で定義される。表3.7は,モデル規定における情報を補強し,3. "操作層の符号化"で定義する六つの基本型を使って,モデル規定の構文型を定義する。ここで,六つの型とは,US-ASCII-STRING,LOCALIZED-STRING,SIGNED-INTEGER,SIGNED-SHORT,SIGNED-BYTE及びOCTET-STRINGとする。

表3.7 属性値の構文及びその符号化

属性値の構文 符号化
textWithoutLanguage, nameWithoutLanguage LOCALIZED-STRING
textWithLanguage 次の四つのフィールドから構成されるOCTET-STRING
  • フィールドa フィールドbにおけるオクテットの数を示すSIGNED-SHORT
  • フィールドb 型natural-languageの値
  • フィールドc フィールドdにおけるオクテットの数を示すSIGNED-SHORT
  • フィールドd 型textWithoutLanguageの値
textWithoutLanguage値の長さは,4,フィールドaの値及びフィールドcの値を加えたものでなければならない。
nameWithLanguage 次の四つのフィールドから構成されるOCTET-STRING
  • フィールドa フィールドbにおけるオクテットの数を示すSIGNED-SHORT
  • フィールドb 型natural-languageの値
  • フィールドc フィールドdにおけるオクテットの数を示すSIGNED-SHORT
  • フィールドd 型nameWithuoutLanguageの値
nameWithoutLanguage値の長さは,4,フィールドaの値及びフィールドcの値を加えたものでなければならない。
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"の値を決定する。

3.10 データ(data)

"data"フィールドは,操作によって要求されるあらゆるデータを含まなければならない。


4. トランスポート層の符号化

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の不適合実装との矛盾を起こし得る。

4.1 プリンタURI及びジョブURI

すべての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がどのように用いられるかを特徴付ける。

5. IPP 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. IANAへの考慮

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によって拡張してもよい。

7. 国際化への考慮

国際化に関する情報については, 規定"Internet Printing Protocol/1.1: Model and Semantics"[RFC2911]の"Internationalization Considerations"(国際化への考慮)の節を参照されたい。 この規定は, 追加の課題を加えていない。

8. セキュリティへの考慮

IPPモデル及び機能定義の規定[RFC2911]は, 高水準のセキュリティ要求(クライアント認証, サーバ認証及び操作プライバシ)を示す。 クライアント認証は, クライアントが安全な方法でその身元確認をサーバに対して証明する機構とする。 サーバ認証は, サーバが安全な方法でその身元確認をクライアントに対して証明する機構とする。 操作プライバシは、盗聴から操作を保護するための機構として定義される。

8.1 セキュリティ適合性の要件

8.1は, IPPクライアント及びIPPオブジェクトのためのセキュリティ要件を規定する。

8.1.1 ダイジェスト認証

IPPクライアントは, 次をサポートしなければならない。

 ダイジェスト認証[RFC2617]

  MD5及びMD5-sessが, 実装されサポートされなければならない。

  Message Integrity機能は, 使う必要がない。

IPPプリンタは, 次をサポートすることが望ましい。  

 ダイジェスト認証[RFC2617]

  MD5及びMD5-sessが, 実装されサポートされなければならない。
  Message Integrity機能は, 使う必要がない。

IPPプリンタがダイジェスト認証をサポート(しなければならないのではなく)することが望ましい理由を, 次に示す。

8.1.2 トランスポート層セキュリティ

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]をサポートしてもよい。 これは, この規定で要求されるセキュリティに追加される。

8.2 TLSを用いたIPPの使用

IPP/1.1は, "Upgrading to TLS Within HTTP/1.1"機構[RFC2817]を用いる。 初期のIPP要求は, 決してTLSを使わない。 サーバが, HTTP応答において合意する限り, クライアントは, HTTP "Upgrade"ヘッダを用いることによって, 安全なTLSコネクションを要求する。TLSへの切替えが生じるのは, サーバがTLSに昇格するためにクライアントの要求を承諾すること, 又はサーバはその応答においてTLSへの切替え依頼することのどちらかによる。 安全な通信は,TLSへ切り替えるためのサーバの応答で始まる。

9. IPP/1.0実装との相互接続

前の版との適合性を指示することは, この規定の適用範囲外である。しかし, IPP/1.1は, 慎重に設計されており, 前の版をサポートすることを容易にしている。 この規定を作成する時点(1999)で, IPP/1.0のプリンタ実装が次のとおりであることを期待することは, 注目に値する。

IPP/1.1クライアントが次のとおりであることも期待される。

9.1 版番号パラメタ

"version-number"パラメタに関する規則を次に示す(3.3参照)。

9.2 セキュリティ及びURL方式

ターゲットの属性及び応答で提供されるセキュリティ, "version-number"パラメタ及びURL方式に関する規則を次に示す。


10. 引用規定


   [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.

11. 原規定の著者

   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


12. 原規定の協力者


   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