[要約] RFC 2565は、インターネット印刷プロトコル/1.0のエンコーディングとトランスポートに関する仕様です。このRFCの目的は、インターネット上での印刷サービスのエンコーディングとトランスポートの方法を定義することです。
Network Working Group R. Herriot, Ed.
Request for Comments: 2565 Xerox Corporation
Category: Experimental S. Butler
Hewlett-Packard
P. Moore
Microsoft
R. Turner
Sharp Labs
April 1999
Internet Printing Protocol/1.0: Encoding and Transport
インターネット印刷プロトコル/1.0：エンコーディングとトランスポート
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
IESG Note
IESGノート
This document defines an Experimental protocol for the Internet community. The IESG expects that a revised version of this protocol will be published as Proposed Standard protocol. The Proposed Standard, when published, is expected to change from the protocol defined in this memo. In particular, it is expected that the standards-track version of the protocol will incorporate strong authentication and privacy features, and that an "ipp:" URL type will be defined which supports those security measures. Other changes to the protocol are also possible. Implementors are warned that future versions of this protocol may not interoperate with the version of IPP defined in this document, or if they do interoperate, that some protocol features may not be available.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。IESGは、このプロトコルの改訂版が提案された標準プロトコルとして公開されることを期待しています。提案された標準は、公開された場合、このメモで定義されているプロトコルから変更されると予想されます。特に、プロトコルの標準トラックバージョンには、強力な認証とプライバシーの機能が組み込まれ、「IPP：」URLタイプがこれらのセキュリティ対策をサポートする「URLタイプ」が定義されることが予想されます。プロトコルの他の変更も可能です。実装者は、このプロトコルの将来のバージョンが、このドキュメントで定義されているIPPのバージョンと相互運用しない可能性があること、または相互運用を行う場合、一部のプロトコル機能が利用できない可能性があることを警告されています。
The IESG encourages experimentation with this protocol, especially in combination with Transport Layer Security (TLS) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP.
IESGは、このプロトコルの実験、特に輸送層セキュリティ（TLS）[RFC 2246]と組み合わせて、IPPのセキュリティ層としてTLSを効果的に使用する方法を判断するのに役立ちます。
Abstract
概要
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp".
このドキュメントは一連のドキュメントの1つであり、新しいインターネット印刷プロトコル（IPP）のすべての側面を一緒に説明しています。IPPは、インターネットツールとテクノロジーを使用した分散印刷に使用できるアプリケーションレベルのプロトコルです。このドキュメントでは、IPP操作とIPP属性を「Application/IPP」と呼ばれる新しいインターネットMIMEメディアタイプにエンコードするためのルールを定義しています。このドキュメントでは、コンテンツタイプが「アプリケーション/IPP」であるメッセージ本文をHTTPで輸送するためのルールも定義しています。
The full set of IPP documents includes:
IPPドキュメントの完全なセットには以下が含まれます。
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport (this
document)
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
ドキュメント「インターネット印刷プロトコルの設計目標」は、分散した印刷機能を幅広く見ています。また、インターネットの印刷プロトコルに含める必要がある機能を明確にするのに役立つ実生活のシナリオを列挙します。エンドユーザー、オペレーター、および管理者の3種類のユーザーの要件を特定します。IPP/1.0で満たされているエンドユーザー要件のサブセットを呼び出します。オペレーターと管理者の要件は、バージョン1.0の範囲外です。
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.
ドキュメント「インターネット印刷プロトコルの構造とモデルおよびプロトコルの理論的根拠」は、高レベルのビューからのIPPを説明し、IPP仕様のスイートを形成するさまざまなドキュメントのロードマップを定義し、IETFの背景と根拠を提供しますワーキンググループの主要な決定。
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
ドキュメント「インターネット印刷プロトコル/1.0：モデルとセマンティクス」は、抽象的なオブジェクト、その属性、およびエンコードと輸送に依存しない操作を備えた単純化されたモデルについて説明しています。プリンターとジョブオブジェクトを紹介します。ジョブオブジェクトは、オプションでジョブごとの複数のドキュメントをサポートします。また、セキュリティ、国際化、およびディレクトリの問題にも対処します。
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
このドキュメント「インターネット印刷プロトコル/1.0：実装者ガイド」は、IPPクライアントとIPPオブジェクトの実装者にアドバイスを提供します。
The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
ドキュメント「LPDとIPPプロトコル間のマッピング」は、IPPとLPD（Line Printer Daemon）の実装の間のゲートウェイの実装者にアドバイスを提供します。
Table of Contents
目次
1. Introduction.....................................................4
2. Conformance Terminology..........................................4
3. Encoding of the Operation Layer.................................4
3.1 Picture of the Encoding.....................................5
3.2 Syntax of Encoding..........................................7
3.3 Version-number..............................................9
3.4 Operation-id................................................9
3.5 Status-code.................................................9
3.6 Request-id..................................................9
3.7 Tags.......................................................10
3.7.1 Delimiter Tags.........................................10
3.7.2 Value Tags.............................................11
3.8 Name-Length................................................13
3.9 (Attribute) Name...........................................13
3.10 Value Length...............................................16
3.11 (Attribute) Value..........................................16
3.12 Data.......................................................18
4. Encoding of Transport Layer.....................................18
5. Security Considerations.........................................19
5.1 Using IPP with SSL3........................................19
6. References......................................................20
7. Authors' Addresses..............................................22
8. Other Participants:.............................................24
9. Appendix A: Protocol Examples...................................25
9.1 Print-Job Request..........................................25
9.2 Print-Job Response (successful)............................26
9.3 Print-Job Response (failure)...............................27
9.4 Print-Job Response (success with attributes ignored).......28
9.5 Print-URI Request..........................................30
9.6 Create-Job Request.........................................31
9.7 Get-Jobs Request...........................................31
9.8 Get-Jobs Response..........................................32
10. Appendix C: Registration of MIME Media Type Information for
"application/ipp"..............................................35
11. Full Copyright Statement.......................................37
This document contains the rules for encoding IPP operations and describes two layers: the transport layer and the operation layer.
このドキュメントには、IPP操作をエンコードするためのルールが含まれており、輸送層と動作層の2つの層について説明します。
The transport layer consists of an HTTP/1.1 request or response. RFC 2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports.
輸送層は、HTTP/1.1要求または応答で構成されています。RFC 2068 [RFC2068]はHTTP/1.1を説明しています。このドキュメントは、IPP実装がサポートするHTTPヘッダーを指定します。
The operation layer consists of a message body in an HTTP request or response. The document "Internet Printing Protocol/1.0: Model and Semantics" [RFC2566] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2566] is henceforth referred to as the "IPP model document"
操作層は、HTTP要求または応答のメッセージ本文で構成されています。ドキュメント「インターネット印刷プロトコル/1.0：モデルとセマンティクス」[RFC2566]は、そのようなメッセージ本文とサポート値のセマンティクスを定義します。このドキュメントは、IPP操作のエンコードを指定します。前述のドキュメント[RFC2566]は、以降、「IPPモデルドキュメント」と呼ばれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
「必須」、「必須」、「必須」、「必要」、「必要はない」、「推奨」、「5月」、および「オプション」は、RFC 2119で説明されているように解釈されます[RFC2119]。
The operation layer MUST contain a single operation request or operation response. Each request or response consists of a sequence of values and attribute groups. Attribute groups consist of a sequence of attributes each of which is a name and value. Names and values are ultimately sequences of octets
操作層には、単一の操作要求または操作応答が含まれている必要があります。各リクエストまたは応答は、一連の値と属性グループで構成されています。属性グループは、それぞれが名前と値である一連の属性で構成されています。名前と値は、最終的にオクテットのシーケンスです
The encoding consists of octets as the most primitive type. There are several types built from octets, but three important types are integers, character strings and octet strings, on which most other data types are built. Every character string in this encoding MUST be a sequence of characters where the characters are associated with some charset and some natural language. A character string MUST be in "reading order" with the first character in the value (according to reading order) being the first character in the encoding. A character string whose associated charset is US-ASCII whose associated natural language is US English is henceforth called a US-ASCII-STRING. A character string whose associated charset and natural language are specified in a request or response as described in the model document is henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP model document order" with the first octet in the value (according to the IPP model document order) being the first octet in the encoding Every integer in this encoding MUST be encoded as a signed integer using two's-complement binary encoding with big-endian format (also known as "network order" and "most significant byte first"). The number of octets for an integer MUST be 1, 2 or 4, depending on usage in the protocol. Such one-octet integers, henceforth called SIGNED-BYTE, are used for the version-number and tag fields. Such two-byte integers, henceforth called SIGNED-SHORT are used for the operation-id, status-code and length fields. Four byte integers, henceforth called SIGNED-INTEGER, are used for values fields and the sequence number.
エンコーディングは、最も原始的なタイプとしてオクテットで構成されています。オクテットから構築されたいくつかのタイプがありますが、3つの重要なタイプは整数、文字列、オクテット文字列で、他のほとんどのデータ型が構築されています。このエンコーディングのすべての文字列は、文字が何らかのチャーセットと自然言語に関連付けられている一連のキャラクターでなければなりません。文字文字列は「読み取り順序」でなければなりません。値の最初のキャラクター（読書順序に従って）がエンコードの最初のキャラクターです。関連するチャーセットは、関連する自然言語が米国英語である米国ASCIIであるキャラクター文字列は、以降、US-ASCII-stringと呼ばれています。モデルドキュメントで説明されているように、関連するチャーセットと自然言語がリクエストまたは応答で指定されている文字文字列は、今後ローカライズされた弦と呼ばれます。オクテット文字列は「IPPモデルドキュメントオーダー」にある必要があります。最初のオクテット（IPPモデルドキュメント順序に従って）が、このエンコードのすべての整数のエンコードの最初のオクテットである必要があります。ビッグエンディアン形式での補完バイナリエンコーディング（「ネットワーク注文」と「最初の最も重要なバイト」とも呼ばれます）。整数のオクテットの数は、プロトコルの使用に応じて1、2、または4でなければなりません。このような1オクテットの整数は、以降、signed-byteと呼ばれるもので、バージョン番号とタグフィールドに使用されます。このような2バイトの整数、以降、署名番号と呼ばれる整数は、Operation-ID、ステータスコード、および長さフィールドに使用されます。これ以降、Signed-Integerと呼ばれる4バイトの整数が、値フィールドとシーケンス番号に使用されます。
The following two sections present the operation layer in two ways
次の2つのセクションは、2つの方法で動作層を示しています
- informally through pictures and description - formally through Augmented Backus-Naur Form (ABNF), as specified by RFC 2234 [RFC2234]
- 写真と説明を通じて非公式に - RFC 2234 [RFC2234]で指定されているように、拡張されたバックスノーフォーム（ABNF）を通じて正式に
The encoding for an operation request or response consists of:
操作リクエストまたは応答のエンコーディングは次のとおりです。
-----------------------------------------------
| 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
-----------------------------------------------
The xxx-attributes-tag and xxx-attribute-sequence represents four different values of "xxx", namely, operation, job, printer and unsupported. The xxx-attributes-tag and an xxx-attribute-sequence represent attribute groups in the model document. The xxx-attributes-tag identifies the attribute group and the xxx-attribute-sequence contains the attributes.
XXX-Attributes-TagおよびXXX-Attribute-sequenceは、「XXX」の4つの異なる値、つまり操作、ジョブ、プリンター、およびサポートされていないものを表します。xxx-attributes-tagとxxx-aTtribute-sevecenceは、モデルドキュメントの属性グループを表します。xxx-attributes-tagは属性グループを識別し、xxx-attribute-sevecenceには属性が含まれます。
The expected sequence of xxx-attributes-tag and xxx-attribute-sequence is specified in the IPP model document for each operation request and operation response.
XXX-Attributes-TAGおよびXXX-Attribute-seaveenceの予想シーケンスは、各操作要求と操作応答のIPPモデルドキュメントで指定されています。
A request or response SHOULD contain each xxx-attributes-tag defined for that request or response even if there are no attributes except for the unsupported-attributes-tag which SHOULD be present only if the unsupported-attribute-sequence is non-empty. A receiver of a request MUST be able to process as equivalent empty attribute groups:
リクエストまたは応答には、サポートされていないアトリビュートのシーケンスが空でない場合にのみ存在する必要があるサポートされていないアトリビュートタグを除いて属性がない場合でも、その要求または応答に対して定義された各XXX-ATTRIBUTES-TAGを含める必要があります。リクエストの受信者は、同等の空の属性グループとして処理できる必要があります。
a) an xxx-attributes-tag with an empty xxx-attribute-sequence, b) an expected but missing xxx-attributes-tag.
a) 空のxxx-aTtribute-sevesenceを備えたxxx-attributes-tag、b）予想されるが欠落しているxxx-attributes-tag。
The data is omitted from some operations, but the end-of-attributes-tag is present even when the data is omitted. Note, the xxx-attributes-tags and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx-attribute-sequence, shown above may consist of 0 bytes, according to the rule below.
データは一部の操作から省略されていますが、データが省略されている場合でも、アトリビュートの終了タグが存在します。XXX-Attributes-TagsとAttributes-Tagのタグは「Delimiter-Tags」と呼ばれます。注：上記のルールによると、上記のXXX-Attribute-seavecenceは0バイトで構成されている場合があります。
An xxx-attributes-sequence consists of zero or more compound-attributes.
XXX-Attributes-sequenceは、ゼロ以上の化合物属性で構成されています。
-----------------------------------------------
| compound-attribute | s bytes - 0 or more
-----------------------------------------------
A compound-attribute consists of an attribute with a single value followed by zero or more additional values.
化合物アトリブは、単一の値を持つ属性で構成され、その後にゼロ以上の追加値が続きます。
Note: a 'compound-attribute' represents a single attribute in the model document. The 'additional value' syntax is for attributes with 2 or more values.
注：「Compound-Attribute」は、モデルドキュメントの単一の属性を表します。「追加値」構文は、2つ以上の値を持つ属性用です。
Each attribute consists of:
各属性は以下で構成されています。
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is v) | 2 bytes
-----------------------------------------------
| value | v bytes
-----------------------------------------------
An additional value consists of:
付加価値は次のとおりです。
-----------------------------------------------------------
| value-tag | 1 byte |
----------------------------------------------- |
| name-length (value is 0x0000) | 2 bytes |
----------------------------------------------- |-0 or more
| value-length (value is w) | 2 bytes |
----------------------------------------------- |
| value | w bytes |
-----------------------------------------------------------
Note: an additional value is like an attribute whose name-length is 0.
注：付加値は、名前の長さが0の属性のようなものです。
From the standpoint of a parsing loop, the encoding consists of:
解析ループの観点から、エンコードは次のとおりです。
-----------------------------------------------
| 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
-----------------------------------------------
The value of the tag determines whether the bytes following the tag are:
タグの値は、タグに続くバイトが次のかどうかを決定します。
- attributes - data - the remainder of a single attribute where the tag specifies the type of the value.
- 属性 - データ - タグが値のタイプを指定する単一の属性の残りの部分。
The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be case sensitive. For example 'a' means lower case 'a' and not upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented as '%x' values which show their range of values.
以下の構文は、「リテラルの文字列」がケースに敏感でなければならないことを除いて、ABNF [RFC2234]です。たとえば、「a」とは、「a」を意味し、上品な「a」ではありません。さらに、署名されたバイトと署名されたショートフィールドは、値の範囲を示す「％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 ; initially %d1
minor-version-number = SIGNED-BYTE ; initially %d0
operation-id = SIGNED-SHORT ; mapping from model defined below
status-code = SIGNED-SHORT ; mapping from model defined below
request-id = SIGNED-INTEGER ; whose value is > 0
compound-attribute = attribute *additional-values attribute = value-tag name-length name value-length value additional-values = value-tag zero-name-length value-length value
Complear-Attribute = attribute *追加値属性=値タグ名name name length-length値追加値=値ゼロネーム長値長値
name-length = SIGNED-SHORT ; number of octets of 'name'
name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
value-length = SIGNED-SHORT ; number of octets of 'value'
value = OCTET-STRING
data = OCTET-STRING
zero-name-length = %x00.00 ; name-length of 0
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
end-of-attributes-tag = %x03 ; tag of 3
value-tag = %x10-FF
SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE
SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" to "9"
LALPHA = %x61-7A ; "a" to "z"
BYTE = %x00-FF
OCTET-STRING = *BYTE
The syntax allows an xxx-attributes-tag to be present when the xxx-attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
構文により、XXX-Attributes-Tagが存在するようになります。構文はこの方法で定義されており、いくつかの職務objectsの属性が返されないget-jobsの応答を可能にします。属性がない場合は送信者がxxx-attributes-tagを送信しないことをお勧めしますが（先ほど言及したGet-Jobs応答を除く）、受信者はそのような構文をデコードできる必要があります。
The version-number MUST consist of a major and minor version-number, each of which MUST be represented by a SIGNED-BYTE. The protocol described in this document MUST have a major version-number of 1 (0x01) and a minor version-number of 0 (0x00). The ABNF for these two bytes MUST be %x01.00.
バージョン番号は、メジャーバージョンとマイナーバージョンの数で構成されている必要があります。それぞれが署名付きバイトで表現する必要があります。このドキュメントで説明したプロトコルには、メジャーバージョン番号1（0x01）と0（0x00）のマイナーバージョン番号が必要です。これら2つのバイトのABNFは％x01.00でなければなりません。
Operation-ids are defined as enums in the model document. An operation-ids enum value MUST be encoded as a SIGNED-SHORT.
Operation-IDは、モデルドキュメントの列挙として定義されます。Operation-IDS列挙値は、署名付きショートとしてエンコードする必要があります。
Note: the values 0x4000 to 0xFFFF are reserved for private extensions.
注：値0x4000〜0xffffは、プライベートエクステンション用に予約されています。
Status-codes are defined as enums in the model document. A status-code enum value MUST be encoded as a SIGNED-SHORT.
ステータスコードは、モデルドキュメントの列挙として定義されます。ステータスコードの列挙値は、署名付きショートとしてエンコードする必要があります。
The status-code is an operation attribute in the model document. In the protocol, the status-code is in a special position, outside of the operation attributes.
ステータスコードは、モデルドキュメントの操作属性です。プロトコルでは、ステータスコードは操作属性の外にある特別な位置にあります。
If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 (successful-ok). With any other HTTP Status-Code value, the HTTP response MUST NOT contain an IPP message-body, and thus no IPP status-code is returned.
IPPステータスコードが返される場合、HTTPステータスコードは200（成功したOK）でなければなりません。他のHTTPステータスコード値では、HTTP応答にIPPメッセージボディを含める必要があるため、IPPステータスコードは返されません。
The request-id allows a client to match a response with a request. This mechanism is unnecessary in HTTP, but may be useful when application/ipp entity bodies are used in another context.
リクエストIDを使用すると、クライアントは応答をリクエストと一致させることができます。このメカニズムはHTTPでは不要ですが、アプリケーション/IPPエンティティボディが別のコンテキストで使用される場合に役立つ場合があります。
The request-id in a response MUST be the value of the request-id received in the corresponding request. A client can set the request-id in each request to a unique value or a constant value, such as 1, depending on what the client does with the request-id returned in the response. The value of the request-id MUST be greater than zero.
応答のリクエストIDは、対応するリクエストで受信したリクエストIDの値でなければなりません。クライアントは、各リクエストのリクエストIDを、クライアントが応答で返されたことでクライアントが何をするかに応じて、1などの一定の値または一定の値に設定できます。request-idの値はゼロより大きくなければなりません。
There are two kinds of tags:
タグには2種類あります。
- delimiter tags: delimit major sections of the protocol, namely attributes and data - value tags: specify the type of each attribute value
- 区切り文字：プロトコルの主要セクション、つまり属性とデータ - 値タグ：各属性値のタイプを指定する
The following table specifies the values for the delimiter tags:
次の表には、区切り文字の値を指定します。
Tag Value (Hex) Delimiter
タグ値（六角）デリミッター
0x00 reserved
0x01 operation-attributes-tag
0x02 job-attributes-tag
0x03 end-of-attributes-tag
0x04 printer-attributes-tag
0x05 unsupported-attributes-tag
0x06-0x0e reserved for future delimiters
0x0F reserved for future chunking-end-of-attributes-
tag
When an xxx-attributes-tag occurs in the protocol, it MUST mean that zero or more following attributes up to the next delimiter tag are attributes belonging to group xxx as defined in the model document, where xxx is operation, job, printer, unsupported.
XXX-ATTRIBUTES-TAGがプロトコルで発生した場合、次のデリミタータグに続くゼロ以上の属性が、XXXが操作、ジョブ、プリンター、サポートされていないモデルドキュメントで定義されているグループXXXに属する属性であることを意味する必要があります。
Doing substitution for xxx in the above paragraph, this means the following. When an operation-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are operation attributes as defined in the model document. When an job-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are job attributes or job template attributes as defined in the model document. When a printer-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are printer attributes as defined in the model document. When an unsupported-attributes-tag occurs in the protocol, it MUST mean that the zero or more following attributes up to the next delimiter tag are unsupported attributes as defined in the model document.
上記の段落でxxxの代替を行うと、これは以下を意味します。プロトコルでOperation-Attributes-Tagが発生した場合、次のデリミタータグまでのゼロ以上の属性がモデルドキュメントで定義されている操作属性であることを意味する必要があります。プロトコルでジョブアトリビュートタグが発生した場合、次のデリミタータグまでのゼロ以上のフォロー属性が、モデルドキュメントで定義されているジョブ属性またはジョブテンプレート属性であることを意味する必要があります。プロトコルでプリンターアトリブタグが発生した場合、次のデリミタータグまでのゼロ以上のフォロー属性が、モデルドキュメントで定義されているプリンター属性であることを意味する必要があります。サポートされていないアトリビュートタグがプロトコルで発生する場合、次のデリミタータグまでのゼロ以上のフォロー属性が、モデルドキュメントで定義されているサポートされていない属性であることを意味する必要があります。
The operation-attributes-tag and end-of-attributes-tag MUST each occur exactly once in an operation. The operation-attributes-tag MUST be the first tag delimiter, and the end-of-attributes-tag MUST be the last tag delimiter. If the operation has a document-content group, the document data in that group MUST follow the end-of-attributes-tag.
Operation-Attributes-TagおよびAttributes-Tagのタグは、それぞれ操作で正確に1回発生する必要があります。Operation-Attributes-Tagは最初のタグ区切り文字でなければならず、Attributes-Tagの終了は最後のタグ区切り文字でなければなりません。操作にドキュメントコンテンツグループがある場合、そのグループのドキュメントデータは、アトリビュートの終了タグに従う必要があります。
Each of the other three xxx-attributes-tags defined above is OPTIONAL in an operation and each MUST occur at most once in an operation, except for job-attributes-tag in a Get-Jobs response which may occur zero or more times.
上記で定義された他の3つのXXX-Attributes-Tagはそれぞれ操作でオプションであり、ゼロ以上に発生する可能性のあるGet-Attributes-Tagを除き、それぞれが操作でせいぜい1回発生する必要があります。
The order and presence of delimiter tags for each operation request and each operation response MUST be that defined in the model document. For further details, see section 3.9 "(Attribute) Name" and section 9 "Appendix A: Protocol Examples".
各操作要求のデリミッタータグの順序と存在と各操作応答は、モデルドキュメントで定義されている必要があります。詳細については、セクション3.9 "（属性）"およびセクション9「付録A：プロトコルの例」を参照してください。
A Printer MUST treat the reserved delimiter tags differently from reserved value tags so that the Printer knows that there is an entire attribute group that it doesn't understand as opposed to a single value that it doesn't understand.
プリンターは、予約済みの値タグとは異なる方法で処理する必要があります。そのため、プリンターは、理解できない単一の値とは対照的に理解していない属性グループ全体があることを知っています。
The remaining tables show values for the value-tag, which is the first octet of an attribute. The value-tag specifies the type of the value of the attribute. The following table specifies the "out-of-band" values for the value-tag.
残りのテーブルには、属性の最初のオクテットである値タグの値が表示されます。値タグは、属性の値のタイプを指定します。次の表は、値タグの「帯域外」値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x10 unsupported
0x11 reserved for future 'default'
0x12 unknown
0x13 no-value
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x14-0x1F reserved for future "out-of-band" values.
0x14-0x1f将来の「帯域外」値のために予約されています。
The "unsupported" value MUST be used in the attribute-sequence of an error response for those attributes which the printer does not support. The "default" value is reserved for future use of setting value back to their default value. The "unknown" value is used for the value of a supported attribute when its value is temporarily unknown. The "no-value" value is used for a supported attribute to which no value has been assigned, e.g. "job-k-octets-supported" has no value if an implementation supports this attribute, but an administrator has not configured the printer to have a limit.
「サポートされていない」値は、プリンターがサポートしていない属性のエラー応答の属性シーケンスに使用する必要があります。「デフォルト」値は、将来の設定値をデフォルト値に戻すために予約されています。「未知の」値は、その値が一時的に不明である場合、サポートされた属性の値に使用されます。「価値のない」値は、値が割り当てられていないサポートされている属性に使用されます。「Job-K-Octets-Supported」には、実装がこの属性をサポートしている場合は価値がありませんが、管理者はプリンターに制限を設定するように構成していません。
The following table specifies the integer values for the value-tag:
次の表は、値タグの整数値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x20 reserved
0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F reserved for future integer types
NOTE: 0x20 is reserved for "generic integer" if it should ever be needed.
注：0x20は、必要な場合は「ジェネリック整数」に予約されています。
The following table specifies the octetString values for the value-tag:
次の表は、値タグのオクテットストリング値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x30 octetString with an unspecified format
0x31 dateTime
0x32 resolution
0x33 rangeOfInteger
0x34 reserved for collection (in the future)
0x35 textWithLanguage
0x36 nameWithLanguage
0x37-0x3F reserved for future octetString types
The following table specifies the character-string values for the value-tag:
次の表は、値タグの文字弦値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x40 reserved
0x41 textWithoutLanguage
0x42 nameWithoutLanguage
0x43 reserved
0x44 keyword
0x45 uri
0x46 uriScheme
0x47 charset
0x48 naturalLanguage
Tag Value (Hex) Meaning
0x49 mimeMediaType 0x4A-0x5F reserved for future character string types
0x49 Mimemediatype 0x4a-0x5f将来の文字列タイプ用に予約されています
NOTE: 0x40 is reserved for "generic character-string" if it should ever be needed.
注：0x40は、必要な場合は「一般的なキャラクターストリング」用に予約されています。
NOTE: an attribute value always has a type, which is explicitly specified by its tag; one such tag value is "nameWithoutLanguage". An attribute's name has an implicit type, which is keyword.
注：属性値には常にタイプがあり、タグで明示的に指定されています。そのようなタグ値の1つは「namewithoutlanguage」です。属性の名前には、キーワードである暗黙のタイプがあります。
The values 0x60-0xFF are reserved for future types. There are no values allocated for private extensions. A new type MUST be registered via the type 2 registration process [RFC2566].
値0x60-0xffは、将来のタイプ用に予約されています。プライベートエクステンションに割り当てられた値はありません。タイプ2の登録プロセス[RFC2566]を介して、新しいタイプを登録する必要があります。
The tag 0x7F is reserved for extending types beyond the 255 values available with a single byte. A tag value of 0x7F MUST signify that the first 4 bytes of the value field are interpreted as the tag value. Note, this future extension doesn't affect parsers that are unaware of this special tag. The tag is like any other unknown tag, and the value length specifies the length of a value which contains a value that the parser treats atomically. All these 4 byte tag values are currently unallocated except that the values 0x40000000- 0x7FFFFFFF are reserved for experimental use.
タグ0x7Fは、単一のバイトで利用可能な255の値を超えて拡張されるために予約されています。0x7Fのタグ値は、値フィールドの最初の4バイトがタグ値として解釈されることを示す必要があります。この将来の拡張機能は、この特別なタグを知らないパーサーには影響しません。タグは他の未知のタグに似ており、値の長さは、パーサーが原子的に扱う値を含む値の長さを指定します。これらの4バイトのタグ値はすべて、値0x40000000- 0x7ffffffffが実験用に予約されていることを除いて、現在解釈されていません。
The name-length field MUST consist of a SIGNED-SHORT. This field MUST specify the number of octets in the name field which follows the name-length field, excluding the two bytes of the name-length field.
名前の長さのフィールドは、署名されたショートで構成されている必要があります。このフィールドは、名前の長さフィールドの2バイトを除く名前のフィールドに続く名前フィールドのオクテットの数を指定する必要があります。
If a name-length field has a value of zero, the following name field MUST be empty, and the following value MUST be treated as an additional value for the preceding attribute. Within an attribute-sequence, if two attributes have the same name, the first occurrence MUST be ignored. The zero-length name is the only mechanism for multi-valued attributes.
名前の長さのフィールドの値がゼロの場合、次の名前フィールドは空でなければならず、以前の属性の追加値として次の値を扱う必要があります。属性シーケンス内で、2つの属性が同じ名前を持っている場合、最初の発生は無視する必要があります。ゼロ長の名前は、多値の属性の唯一のメカニズムです。
Some operation elements are called parameters in the model document [RFC2566]. They MUST be encoded in a special position and they MUST NOT appear as an operation attributes. These parameters are:
一部の操作要素は、モデルドキュメント[RFC2566]のパラメーターと呼ばれます。それらは特別な位置にエンコードする必要があり、操作属性として表示されてはなりません。これらのパラメーターは次のとおりです。
- "version-number": The parameter named "version-number" in the IPP model document MUST become the "version-number" field in the operation layer request or response.
- 「バージョン番号」：IPPモデルドキュメントの「バージョン番号」という名前のパラメーターは、操作レイヤー要求または応答の「バージョン番号」フィールドにする必要があります。
- "operation-id": The parameter named "operation-id" in the IPP model document MUST become the "operation-id" field in the operation layer request. - "status-code": The parameter named "status-code" in the IPP model document MUST become the "status-code" field in the operation layer response. - "request-id": The parameter named "request-id" in the IPP model document MUST become the "request-id" field in the operation layer request or response.
- 「Operation-ID」：IPPモデルドキュメントの「Operation-ID」という名前のパラメーターは、操作レイヤー要求の「Operation-ID」フィールドにする必要があります。 - 「ステータスコード」：IPPモデルドキュメントの「ステータスコード」という名前のパラメーターは、操作レイヤー応答の「ステータスコード」フィールドにする必要があります。 - "request-id"：IPPモデルドキュメントの「リクエストID」という名前のパラメーターは、操作レイヤー要求または応答の「リクエストID」フィールドにする必要があります。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. The notion of a URI is a useful concept, however, until the notion of URI is more stable (i.e., defined more completely and deployed more widely), it is expected that the URIs used for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.
すべてのプリンターおよびジョブオブジェクトは、均一なリソース識別子（URI）[RFC2396]によって識別されるため、それらは永続的かつ明確に参照できるようにします。しかし、URIの概念は有用な概念ですが、URIの概念がより安定している（つまり、より完全に定義され、より広く展開される）まで、IPPオブジェクトに使用されるURIは実際にURL [RFC1738] [RFC1738] [RFC1808]。すべてのURLはURIの特殊な形式であるため、このドキュメントの残りの部分でURIがより一般的に使用されていても、その使用は、より具体的なURLの概念をカバーすることを目的としています。
Some operation elements are encoded twice, once as the request-URI on the HTTP Request-Line and a second time as a REQUIRED operation attribute in the application/ipp entity. These attributes are the target URI for the operation:
一部の操作要素は、HTTPリクエストラインのリクエスト-URIとして1回、アプリケーション/IPPエンティティの必要な操作属性として2回エンコードされます。これらの属性は、操作のターゲットURIです。
- "printer-uri": When the target is a printer and the transport is HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined in each operation in the IPP model document MUST be an operation attribute called "printer-uri" and it MUST also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level. - "job-uri": When the target is a job and the transport is HTTP or HTTPS (for SSL3), the target job-uri of each operation in the IPP model document MUST be an operation attribute called "job-uri" and it MUST also be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level.
- 「プリンター-URI」：ターゲットがプリンターであり、トランスポートがHTTPまたはHTTPS（SSL3 [SSL]の場合）の場合、IPPモデルドキュメントの各操作で定義されたターゲットプリンター-RIは、「プリンター - 」と呼ばれる操作属性でなければなりません。URI」と、HTTPレベルでのリクエストラインのリクエスト-URIとして、操作レイヤーの外側にも指定する必要があります。 - "Job-uri"：ターゲットがジョブであり、トランスポートがHTTPまたはHTTPS（SSL3の場合）の場合、IPPモデルドキュメントの各操作のターゲットジョブURIは、「Job-uri」と呼ばれる操作属性でなければなりません。また、HTTPレベルでのリクエストラインのリクエスト-URIとして、操作レイヤーの外側で指定する必要があります。
Note: The target URI is included twice in an operation referencing the same IPP object, but the two URIs NEED NOT be literally identical. One can be a relative URI and the other can be an absolute URI. HTTP/1.1 allows clients to generate and send a relative URI rather than an absolute URI. A relative URI identifies a resource with the scope of the HTTP server, but does not include scheme, host or port. The following statements characterize how URLs should be used in the mapping of IPP onto HTTP/1.1:
注：ターゲットURIは、同じIPPオブジェクトを参照する操作に2回含まれていますが、2つのURIは文字通り同一である必要はありません。1つは相対的なURIであり、もう1つは絶対的なURIにすることができます。HTTP/1.1を使用すると、クライアントは絶対URIではなく相対URIを生成および送信できます。相対的なURIは、HTTPサーバーの範囲を持つリソースを識別しますが、スキーム、ホスト、またはポートは含まれません。以下のステートメントは、http/1.1へのIPPのマッピングでURLを使用する方法を特徴付けています。
1. Although potentially redundant, a client MUST supply the target of the operation both as an operation attribute and as a URI at the HTTP layer. The rationale for this decision is to maintain a consistent set of rules for mapping application/ipp to possibly many communication layers, even where URLs are not used as the addressing mechanism in the transport layer. 2. Even though these two URLs might not be literally identical (one being relative and the other being absolute), they MUST both reference the same IPP object. 3. The URI in the HTTP layer is either relative or absolute and is used by the HTTP server to route the HTTP request to the correct resource relative to that HTTP server. The HTTP server need not be aware of the URI within the operation request. 4. Once the HTTP server resource begins to process the HTTP request, it might get the reference to the appropriate IPP Printer object from either the HTTP URI (using to the context of the HTTP server for relative URLs) or from the URI within the operation request; the choice is up to the implementation. 5. HTTP URIs can be relative or absolute, but the target URI in the operation MUST be an absolute URI.
1. 潜在的に冗長ですが、クライアントは操作のターゲットを操作属性として、およびHTTPレイヤーのURIとして提供する必要があります。この決定の理論的根拠は、輸送層のアドレス指定メカニズムとしてURLが使用されていない場合でも、アプリケーション/IPPをおそらく多くの通信層にマッピングするための一貫した一連のルールを維持することです。2.これらの2つのURLは文字通り同一ではない場合がありますが（1つは相対的であり、もう1つは絶対的です）、両方とも同じIPPオブジェクトを参照する必要があります。3. HTTPレイヤーのURIは相対または絶対のいずれかであり、HTTPサーバーで使用されて、HTTP要求をそのHTTPサーバーに比べて正しいリソースにルーティングします。HTTPサーバーは、操作要求内のURIに注意する必要はありません。4. HTTPサーバーリソースがHTTP要求の処理を開始すると、HTTP URI（相対URLのHTTPサーバーのコンテキストに）または操作内のURIから適切なIPPプリンターオブジェクトへの参照を取得する可能性があります。リクエスト;選択は実装次第です。5. http urisは相対的または絶対的である可能性がありますが、操作のターゲットURIは絶対的なURIでなければなりません。
The model document arranges the remaining attributes into groups for each operation request and response. Each such group MUST be represented in the protocol by an xxx-attribute-sequence preceded by the appropriate xxx-attributes-tag (See the table below and section 9 "Appendix A: Protocol Examples"). In addition, the order of these xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST be the same as in the model document, but the order of attributes within each xxx-attribute-sequence MUST be unspecified. The table below maps the model document group name to xxx-attributes-sequence:
モデルドキュメントでは、操作要求と応答ごとに残りの属性をグループに配置します。そのような各グループは、適切なXXX-Attributes-Tagが先行するXXX-Attribute-seaveenceによってプロトコルで表現する必要があります（以下の表を参照し、セクション9「付録A：プロトコル例」を参照）。さらに、これらのXXX-Attributes-Tagsの順序とプロトコルのXXX-Attribute-seavecencesは、モデルドキュメントと同じでなければなりませんが、各XXX-Attribute-seevence内の属性の順序は特定されていない必要があります。以下の表は、モデルドキュメントグループ名をxxx-attributes-sequenceにマッピングします。
Model Document Group xxx-attributes-sequence
モデルドキュメントグループxxx-attributes-sevecence
Operation Attributes operations-attributes-sequence
Job Template Attributes job-attributes-sequence
Job Object Attributes job-attributes-sequence
Unsupported Attributes unsupported-attributes-sequence
Requested Attributes job-attributes-sequence
Get-Job-Attributes)
Requested Attributes printer-attributes-sequence
Get-Printer-Attributes)
Document Content in a special position as described
above
If an operation contains attributes from more than one job object (e.g. Get-Jobs response), the attributes from each job object MUST be in a separate job-attribute-sequence, such that the attributes from the ith job object are in the ith job-attribute-sequence. See Section 9 "Appendix A: Protocol Examples" for table showing the application of the rules above.
操作に複数のジョブオブジェクト（Get-Jobs応答など）からの属性が含まれている場合、各ジョブオブジェクトからの属性が別のジョブアトリビューションシーケンスである必要があり、ITHジョブオブジェクトからの属性がITHジョブにあるようにする必要があります。-Attribute-sevesence。上記のルールの適用を示す表については、セクション9「付録A：プロトコルの例」を参照してください。
Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST specify the number of octets in the value which follows this length, exclusive of the two bytes specifying the length.
各属性値の前には、署名されたショートが付いている必要があります。これは、長さを指定する2バイトを除く、この長さに続く値のオクテットの数を指定する必要があります。
For any of the types represented by binary signed integers, the sender MUST encode the value in exactly four octets.
バイナリ署名された整数で表されるタイプのいずれかについて、送信者は正確に4オクテットで値をエンコードする必要があります。
For any of the types represented by character-strings, the sender MUST encode the value with all the characters of the string and without any padding characters.
キャラクターストリングで表されるタイプのいずれかについて、送信者は、文字列のすべての文字とパディング文字なしで値をエンコードする必要があります。
If a value-tag contains an "out-of-band" value, such as "unsupported", the value-length MUST be 0 and the value empty. The value has no meaning when the value-tag has an "out-of-band" value. If a client receives a response with a nonzero value-length in this case, it MUST ignore the value field. If a printer receives a request with a nonzero value-length in this case, it MUST reject the request.
バリュータグに「サポートされていない」などの「バンド外」値が含まれている場合、値長は0で値が空でなければなりません。バリュータグに「バンド外」値がある場合、値には意味がありません。この場合、クライアントがゼロ以外の値の長さで応答を受信した場合、値フィールドを無視する必要があります。この場合、プリンターがゼロ以外の値の長さでリクエストを受信した場合、リクエストを拒否する必要があります。
The syntax types and most of the details of their representation are defined in the IPP model document. The table below augments the information in the model document, and defines the syntax types from the model document in terms of the 5 basic types defined in section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
構文タイプとその表現の詳細のほとんどは、IPPモデルドキュメントで定義されています。以下の表は、モデルドキュメントの情報を強化し、セクション3「操作層のエンコード」で定義されている5つの基本タイプの観点からモデルドキュメントの構文タイプを定義します。5つのタイプは、US-ASCII-STRING、ローカライズされた弦、署名整数、署名されたショート、サインバイト、オクテットストリングです。
Syntax of Attribute Encoding Value
属性エンコード値の構文
textWithoutLanguage, LOCALIZED-STRING. nameWithoutLanguage
TextWithOutLanguage、ローカライズされた弦。namewithoutlanguage
textWithLanguage OCTET_STRING consisting of 4 fields: a) a SIGNED-SHORT which is the number of octets in the following field b) a value of type natural-language, c) a SIGNED-SHORT which is the number of octets in the following field, d) a value of type textWithoutLanguage.
4つのフィールドで構成されるtextwithlanguage occet_string：a）次のフィールドのオクテットの数b）型自然言語の値、c）次のフィールドのオクテットの数である署名済みショート、d）TextWithOutLanguageのタイプの値。
The length of a textWithLanguage value MUST be 4 + the value of field a + the value of field c.
テキストの長さの値は4でなければなりません4フィールドの値aフィールドcの値。
nameWithLanguage OCTET_STRING consisting of 4 fields: a) a SIGNED-SHORT which is the number of octets in the following field b) a value of type natural-language, c) a SIGNED-SHORT which is the number of octets in the following field d) a value of type nameWithoutLanguage.
namewithlanguage occet_string 4つのフィールドで構成される：a）次のフィールドのオクテットの数b）タイプの自然言語の値、c）次のフィールドDのオクテットの数である署名済みショートd）namewithOutlanguageの型の値。
The length of a nameWithLanguage value MUST be 4 + the value of field a + the value of field c.
名前のある名前の長さは4でなければなりません4フィールドの値aフィールドcの値。
charset, US-ASCII-STRING. naturalLanguage, mimeMediaType, keyword, uri, and uriScheme
charset、us-ascii-string。naturallanguage、mimemediatype、キーワード、uri、およびurischeme
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 'true'.
0x00が「false」であり、0x01が「True」であるBoolean Signed-byte。
Syntax of Attribute Encoding Value
属性エンコード値の構文
integer and enum a SIGNED-INTEGER.
整数と列挙された署名整数。
dateTime OCTET-STRING consisting of eleven octets whose contents are defined by "DateAndTime" in RFC 2579 [RFC2579].
RFC 2579 [RFC2579]の「dateandtime」によって内容が定義されている11のオクテットで構成されるDateTimeオクテットストリング。
resolution OCTET_STRING consisting of nine octets of 2 SIGNED-INTEGERs followed by a SIGNED-BYTE. The first SIGNED-INTEGER contains the value of cross feed direction resolution. The second SIGNED-INTEGER contains the value of feed direction resolution. The SIGNED-BYTE contains the units value.
解像度Octet_Stringは、署名された2つの整数の9オクテットで構成され、その後に署名されたバイトが続きます。最初の署名されたintegerには、クロスフィード方向解像度の値が含まれています。2番目の署名されたintegerには、フィード方向解像度の値が含まれています。署名されたバイトには、ユニット値が含まれています。
rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. The first SIGNED-INTEGER contains the lower bound and the second SIGNED-INTEGER contains the upper bound.
2つの署名された整数で構成される範囲の8オクテット。最初の署名されたintegerには下限が含まれ、2番目の署名されたIntegerには上限が含まれています。
1setOf X Encoding according to the rules for an attribute with more than 1 value. Each value X is encoded according to the rules for encoding its type.
1値を超える属性のルールに従ってxセットxエンコード。各値xは、そのタイプをエンコードするためのルールに従ってエンコードされます。
octetString OCTET-STRING
OctetString Octet-String
The type of the value in the model document determines the encoding in the value and the value of the value-tag.
モデルドキュメントの値のタイプは、値タグの値と値のエンコードを決定します。
The data part MUST include any data required by the operation
データ部分には、操作に必要なデータを含める必要があります
HTTP/1.1 [RFC2068] is the transport layer for this protocol.
HTTP/1.1 [RFC2068]は、このプロトコルの輸送層です。
The operation layer has been designed with the assumption that the transport layer contains the following information:
操作層は、輸送層に次の情報が含まれているという仮定で設計されています。
- the URI of the target job or printer operation - the total length of the data in the operation layer, either as a single length or as a sequence of chunks each with a length.
- ターゲットジョブまたはプリンター操作のURI - 単一の長さまたは長さのチャンクのシーケンスとして、操作層のデータの全長。
It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over some other port as well. In addition, a printer may have to support another port for privacy (See Section 5 "Security Considerations").
プリンターの実装は、他のポートでもHTTPをサポートする場合がありますが、有名なポート631（IPPデフォルトポート）を割り当てたIANA上のプリンター実装をサポートする必要があります。さらに、プリンターはプライバシーのために別のポートをサポートする必要がある場合があります（セクション5「セキュリティ上の考慮事項」を参照）。
Note: even though port 631 is the IPP default, port 80 remains the default for an HTTP URI. Thus a URI for a printer using port 631 MUST contain an explicit port, e.g. "http://forest:631/pinetree". An HTTP URI for IPP with no explicit port implicitly reference port 80, which is consistent with the rules for HTTP/1.1. Each HTTP operation MUST use the POST method where the request-URI is the object target of the operation, and where the "Content-Type" of the message-body in each request and response MUST be "application/ipp". The message-body MUST contain the operation layer and MUST have the syntax described in section 3.2 "Syntax of Encoding". A client implementation MUST adhere to the rules for a client described for HTTP1.1 [RFC2068]. A printer (server) implementation MUST adhere the rules for an origin server described for HTTP1.1 [RFC2068].
注：ポート631がIPPデフォルトである場合でも、ポート80はHTTP URIのデフォルトのままです。したがって、ポート631を使用するプリンターのURIには、明示的なポートが含まれている必要があります。「http：//森：631/pinetree」。明示的なポートを持たないIPPのHTTP URIは、HTTP/1.1のルールと一致する、暗黙的に参照ポート80を参照します。各HTTP操作は、リクエスト-URIが操作のオブジェクトターゲットであり、各リクエストと応答のメッセージボディの「コンテンツタイプ」が「アプリケーション/IPP」でなければならないPOSTメソッドを使用する必要があります。メッセージボディには操作レイヤーが含まれている必要があり、セクション3.2「エンコードの構文」で説明されている構文が必要です。クライアントの実装は、HTTP1.1 [RFC2068]について説明されているクライアントのルールを順守する必要があります。プリンター（サーバー）の実装は、HTTP1.1 [RFC2068]について説明されているオリジンサーバーのルールを遵守する必要があります。
An IPP server sends a response for each request that it receives. If an IPP server detects an error, it MAY send a response before it has read the entire request. If the HTTP layer of the IPP server completes processing the HTTP headers successfully, it MAY send an intermediate response, such as "100 Continue", with no IPP data before sending the IPP response. A client MUST expect such a variety of responses from an IPP server. For further information on HTTP/1.1, consult the HTTP documents [RFC2068].
IPPサーバーは、受信する各リクエストの応答を送信します。IPPサーバーがエラーを検出した場合、リクエスト全体を読み取る前に応答を送信する場合があります。IPPサーバーのHTTPレイヤーがHTTPヘッダーの処理を正常に完了すると、IPP応答を送信する前にIPPデータがない「100 Continue」などの中間応答が送信される場合があります。クライアントは、IPPサーバーからこのようなさまざまな応答を期待する必要があります。HTTP/1.1の詳細については、HTTPドキュメント[RFC2068]を参照してください。
The IPP Model document defines an IPP implementation with "privacy" as one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3 is not an IETF standards track specification. SSL3 meets the requirements for IPP security with regards to features such as mutual authentication and privacy (via encryption). The IPP Model document also outlines IPP-specific security considerations and should be the primary reference for security implications with regards to the IPP protocol itself.
IPPモデルドキュメントは、「プライバシー」を持つIPP実装を安全なソケットレイヤーバージョン3（SSL3）を実装するものとして定義します。注：SSL3は、IETF標準の追跡仕様ではありません。SSL3は、相互認証やプライバシーなどの機能（暗号化を介して）に関して、IPPセキュリティの要件を満たしています。IPPモデルドキュメントは、IPP固有のセキュリティに関する考慮事項の概要も概説しており、IPPプロトコル自体に関するセキュリティへの影響の主要な参照である必要があります。
The IPP Model document defines an IPP implementation with "authentication" as one that implements the standard way for transporting IPP messages within HTTP 1.1. These include the security considerations outlined in the HTTP 1.1 standard document [RFC2068] and Digest Access Authentication extension [RFC2069].
IPPモデルドキュメントでは、「認証」を備えたIPP実装をHTTP 1.1内でIPPメッセージを輸送する標準的な方法を実装するものとして定義します。これらには、HTTP 1.1標準ドキュメント[RFC2068]およびDigest Access Authentication Extension [RFC2069]で概説されているセキュリティに関する考慮事項が含まれます。
The current HTTP infrastructure supports HTTP over TCP port 80. IPP server implementations MUST offer IPP services using HTTP over the IANA assigned Well Known Port 631 (the IPP default port). IPP server implementations may support other ports, in addition to this port.
現在のHTTPインフラストラクチャは、TCPポート80を超えるHTTPをサポートしています。IPPサーバーの実装は、有名なポート631（IPPデフォルトポート）を割り当てられたIANAを介してHTTPを使用してIPPサービスを提供する必要があります。IPPサーバーの実装は、このポートに加えて、他のポートをサポートする場合があります。
See further discussion of IPP security concepts in the model document [RFC2566].
モデルドキュメント[RFC2566]のIPPセキュリティ概念の詳細については、詳細を参照してください。
An assumption is that the URI for a secure IPP Printer object has been found by means outside the IPP printing protocol, via a directory service, web site or other means.
仮定は、安全なIPPプリンターオブジェクトのURIが、ディレクトリサービス、Webサイト、またはその他の手段を介して、IPP印刷プロトコルの外側の手段によって見つかったことです。
IPP provides a transparent connection to SSL by calling the corresponding URL (a https URI connects by default to port 443). However, the following functions can be provided to ease the integration of IPP with SSL during implementation:
IPPは、対応するURLを呼び出すことによりSSLへの透明な接続を提供します（デフォルトでポート443に接続するHTTPS URI）。ただし、実装中にIPPとSSLとの統合を容易にするために、次の機能を提供できます。
connect (URI), returns a status
Connect（URI）、ステータスを返します
"connect" makes an https call and returns the immediate status of the connection as returned by SSL to the user. The status values are explained in section 5.4.2 of the SSL document [ssl].
「Connect」はHTTPSコールを作成し、SSLがユーザーに返した接続の即時ステータスを返します。ステータス値は、SSLドキュメント[SSL]のセクション5.4.2で説明されています。
A session-id may also be retained to later resume a session. The SSL handshake protocol may also require the cipher specifications supported by the client, key length of the ciphers, compression methods, certificates, etc. These should be sent to the server and hence should be available to the IPP client (although as part of administration features).
セッションIDは、後でセッションを再開するために保持される場合があります。SSLハンドシェイクプロトコルには、クライアントがサポートする暗号仕様、暗号のキー長、圧縮方法、証明書などが必要になる場合があります。これらはサーバーに送信する必要があるため、IPPクライアントが利用できるはずです（ただし、管理の一部として特徴）。
disconnect (session)
切断（セッション）
to disconnect a particular session.
特定のセッションを切断します。
The session-id available from the "connect" could be used.
「接続」から利用可能なセッションIDを使用できます。
resume (session)
履歴書（セッション）
to reconnect using a previous session-id.
以前のセッションIDを使用して再接続します。
The availability of this information as administration features are left for implementers, and need not be specified at this time.
管理機能としてのこの情報の可用性は、実装者向けに残されており、現時点では指定する必要はありません。
[RFC2278] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.
[RFC2278] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2278、1998年1月。
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[DPA] ISO/IEC 10175ドキュメント印刷アプリケーション（DPA）、1996年6月。
[iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
[IANA]コード化された文字セットのIANAレジストリ：ftp：//ftp.isi.edu/in-notes/iana/assignments/character-sets。
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0: Implementer's Guide", Work in Progress.
[IPP-IIG] Hastings、Tom、et al。、「Internet Printing Protocol/1.0：実装者ガイド」、作業進行中。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569] Herriot、R.、Hastings、T.、Jacobs、N。およびJ. Martin、「LPDとIPPプロトコルのマッピング」、RFC 2569、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] Debry、R.、Hastings、T.、Herriot、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2566、1999年4月。
[RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565] Herriot、R。、Butler、S.、Moore、P.、Tuner、R。、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S。、「インターネット印刷プロトコルの構造とモデルとプロトコルの理論的根拠」、RFC 2568、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567] Wright、D。、「インターネット印刷プロトコルの設計目標」、RFC 2567、1999年4月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC 1179, August 1990.
[RFC1179] McLaughlin、L。III、（編集者）、「Line Printer Daemon Protocol」RFC 1179、1990年8月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759]スミス、R。、ライト、F。、ヘイスティングス、T。、Zilles、S。、およびJ. Gyllenskog、「プリンターMIB」、RFC 1759、1995年3月。
[RFC1766] Alvestrand, H., " Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RFC1808]フィールディング、R。、「相対均一な資源ロケーター」、RFC 1808、1995年6月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2048] Freed, N., Klensin J. and J. Postel. Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048] Freed、N.、Klensin J.およびJ. Postel。多目的インターネットメールエクステンション（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2068、1997年1月。
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[RFC2069] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A.、Sink、E。and L. Stewart、「HTTPの拡張：消化アクセス認証」、RFC 2069、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[RFC2184] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、および継続」、RFC 2184、1997年8月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234. November 1997.
[RFC2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC2234。1997年11月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Robert Herriot（編集者）Xerox Corporation 3400 Hillview Ave.、Bldg＃1 Palo Alto、CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
電話：650-813-7696ファックス：650-813-6860メール：rherriot@pahv.xerox.com
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd. Boise, ID 83714
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd.ボイジー、ID 83714
Phone: 208-396-6000 Fax: 208-396-3457 EMail: sbutler@boi.hp.com Paul Moore Microsoft One Microsoft Way Redmond, WA 98053
電話：208-396-6000 FAX：208-396-3457メール：sbutler@boi.hp.com Paul Moore Microsoft One Microsoft Way Redmond、WA 98053
Phone: 425-936-0908 Fax: 425-93MS-FAX EMail: paulmo@microsoft.com
電話：425-936-0908ファックス：425-93msファックスメール：paulmo@microsoft.com
Randy Turner Sharp Laboratories 5750 NW Pacific Rim Blvd Camas, WA 98607
Randy Turner Sharp Laboratories 5750 NW Pacific Rim Blvd Camas、WA 98607
Phone: 360-817-8456 Fax: 360-817-8436 EMail: rturner@sharplabs.com
電話：360-817-8456ファックス：360-817-8436メール：rturner@sharplabs.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
8. Other Participants:
8. 他の参加者：
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 - High North Inc.
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard
Charles Gordon - Osicom Patrick Powell - Astart
Technologies
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
The following is an example of a Print-Job request with job-name, copies, and sides specified. The "ipp-attribute-fidelity" attribute is set to 'true' so that the print request will fail if the "copies" or the "sides" attribute are not supported or their values are not supported.
以下は、ジョブ名、コピー、および指定された側面を含む印刷ジョブリクエストの例です。「IPP-Attribute-Fidelity」属性は「True」に設定されているため、「コピー」または「サイド」属性がサポートされていないか、その値がサポートされていない場合、印刷要求が失敗します。
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0002 Print-Job operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x001A value-length
http://forest: printer pinetree value
631/pinetree
0x42 nameWithoutLanguage type value-tag
0x0008 name-length
job-name job-name name
0x0006 value-length
foobar foobar value
0x22 boolean type value-tag
0x16 name-length
ipp-attribute- ipp-attribute-fidelity name
fidelity
0x01 value-length
0x01 true value
0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x44 keyword type value-tag
0x0005 name-length
sides sides name
0x0013 value-length
two-sided- two-sided-long-edge value
long-edge
0x03 end-of-attributes end-of-attributes-tag
%!PS... <PostScript> data
Here is an example of a successful Print-Job response to the previous Print-Job request. The printer supported the "copies" and "sides" attributes and their supplied values. The status code returned is ' successful-ok'.
以下は、以前の印刷ジョブリクエストに対する印刷ジョブの応答が成功した例です。プリンターは、「コピー」と「サイド」属性とその提供された値をサポートしました。返されるステータスコードは「成功した」です。
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0000 successful-ok status-code
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
natural-language language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
Octets Symbolic Value Protocol field
job-id job-id name
0x0004 value-length
147 147 value
0x45 uri type value-tag
0x0007 name-length
job-uri job-uri name
0x001E value-length
http://forest:63 job 123 on pinetree value
1/pinetree/123
0x42 nameWithoutLanguage type value-tag
0x0009 name-length
job-state job-state name
0x0004 value-length
0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag
Here is an example of an unsuccessful Print-Job response to the previous Print-Job request. It fails because, in this case, the printer does not support the "sides" attribute and because the value '20' for the "copies" attribute is not supported. Therefore, no job is created, and neither a "job-id" nor a "job-uri" operation attribute is returned. The error code returned is 'client-error-attributes-or-values-not-supported' (0x040B).
以下は、以前の印刷ジョブリクエストに対する印刷とジョブの応答に失敗した例です。この場合、プリンターは「サイド」属性をサポートしておらず、「コピー」属性の値「20」がサポートされていないために失敗します。したがって、ジョブは作成されず、「ジョブID」も「ジョブURI」操作属性も返されません。返されるエラーコードは、「クライアントエラーアトトリビュースターまたはバリュー - サポートされていない」（0x040b）です。
Octets Symbolic Value Protocol field
オクテットシンボリック値プロトコルフィールド
0x0100 1.0 version-number
0x040B client-error-attributes-or- status-code
values-not-supported
0x00000001 1 request-id
0x01 start operation-attributes operation-attribute tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
Octets Symbolic Value Protocol field
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status- status-message name
message
0x002F value-length
client-error- client-error-attributes-or- value
attributes- values-not-supported
or-values-
not-supported
0x05 start unsupported-attributes unsupported-attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x03 end-of-attributes end-of-attributes-tag
Here is an example of a successful Print-Job response to a Print-Job request like the previous Print-Job request, except that the value of 'ipp-attribute-fidelity' is false. The print request succeeds, even though, in this case, the printer supports neither the "sides" attribute nor the value '20' for the "copies" attribute. Therefore, a job is created, and both a "job-id" and a "job-uri" operation attribute are returned. The unsupported attributes are also returned in an Unsupported Attributes Group. The error code returned is ' successful-ok-ignored-or-substituted-attributes' (0x0001).
「IPP-Attribute-Fideity」の値が虚偽であることを除いて、以前の印刷ジョブ要求のような印刷ジョブ要求に対する印刷ジョブの応答が成功した例を次に示します。この場合、プリンターは「コピー」属性の「側面」属性も「20」属性もサポートしていない場合でも、印刷要求が成功します。したがって、ジョブが作成され、「ジョブID」と「job-uri」操作属性の両方が返されます。サポートされていない属性は、サポートされていない属性グループでも返されます。返されたエラーコードは、「成功したOK-Inored-or-Stituted-aTtributes」（0x0001）です。
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0001 successful-ok-ignored-or- status-code
substituted-attributes
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
Octets Symbolic Value Protocol field
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
natural-language language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x002F value-length
successful-ok- successful-ok-ignored-or- value
ignored-or- substituted-attributes
substituted-
attributes
0x05 start unsupported- unsupported-attributes
attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x45 uri type value-tag
0x0007 name-length
job-uri job-uri name
0x001E value-length
http://forest:63 job 123 on pinetree value
1/pinetree/123
0x42 nameWithoutLanguage type value-tag
0x0009 name-length
job-state job-state name
0x0004 value-length
0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag
The following is an example of Print-URI request with copies and job-name parameters:
以下は、コピーとジョブ名のパラメーターを使用した印刷物リクエストの例です。
Octets Symbolic Value Protocol field
オクテットシンボリック値プロトコルフィールド
0x0100 1.0 version-number
0x0100 1.0バージョン番号
Octets Symbolic Value Protocol field
0x0003 Print-URI operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x001A value-length
http://forest printer pinetree value
:631/pinetree
0x45 uri type value-tag
0x000C name-length
document-uri document-uri name
0x11 value-length
ftp://foo.com ftp://foo.com/foo value
/foo
0x42 nameWithoutLanguage type value-tag
0x0008 name-length
job-name job-name name
0x0006 value-length
foobar foobar value
0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000001 1 value
0x03 end-of-attributes end-of-attributes-tag
The following is an example of Create-Job request with no parameters and no attributes:
以下は、パラメーターも属性もないCreate-Job要求の例です。
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0005 Create-Job operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
Octets Symbolic Value Protocol field
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x001A value-length
http://forest: printer pinetree value
631/pinetree
0x03 end-of-attributes end-of-attributes-tag
The following is an example of Get-Jobs request with parameters but no attributes:
以下は、パラメーターを使用したGet-Jobsリクエストの例ですが、属性はありません。
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x000A Get-Jobs operation-id
0x00000123 0x123 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
Octets Symbolic Value Protocol field
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x001A value-length
http://forest:6 printer pinetree value
31/pinetree
0x21 integer type value-tag
0x0005 name-length
limit limit name
0x0004 value-length
0x00000032 50 value
0x44 keyword type value-tag
0x0014 name-length
requested- requested-attributes name
attributes
0x0006 value-length
job-id job-id value
0x44 keyword type value-tag
0x0000 additional value name-length
0x0008 value-length
job-name job-name value
0x44 keyword type value-tag
0x0000 additional value name-length
0x000F value-length
document-format document-format value
0x03 end-of-attributes end-of-attributes-tag
The following is an of Get-Jobs response from previous request with 3 jobs. The Printer returns no information about the second job (because of security reasons):
以下は、3つのジョブを含む以前のリクエストからのGet-Jobsの応答です。プリンターは、2番目のジョブに関する情報を返しません（セキュリティ上の理由により）：
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed
back)
0x01 start operation-attributes operation-attribute-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x000A value-length
ISO-8859-1 ISO-8859-1 value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes (1st job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x000C value-length
0x0005 sub-value-length
fr-ca fr-CA value
0x0003 sub-value-length
fou fou name
0x02 start job-attributes (2nd job-attributes-tag
object)
0x02 start job-attributes (3rd job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
Octets Symbolic Value Protocol field
148 148 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x0012 value-length
0x0005 sub-value-length
de-CH de-CH value
0x0009 sub-value-length
isch guet isch guet name
0x03 end-of-attributes end-of-attributes-tag
10. Appendix C: Registration of MIME Media Type Information for "application/ipp"
10. 付録C：「アプリケーション/IPP」のMIMEメディアタイプ情報の登録
This appendix contains the information that IANA requires for registering a MIME media type. The information following this paragraph will be forwarded to IANA to register application/ipp whose contents are defined in Section 3 "Encoding of the Operation Layer" in this document:
この付録には、IANAがMIMEメディアタイプを登録するために必要な情報が含まれています。この段落に続く情報は、このドキュメントのセクション3「操作レイヤーのエンコード」で内容が定義されているアプリケーション/IPPを登録するためにIANAに転送されます。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: ipp
MIMEサブタイプ名：IPP
A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.0, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2565], and whose semantics are described in [RFC2566].
「アプリケーション/IPP」のコンテンツタイプは、インターネット印刷プロトコルメッセージ本文（リクエストまたは応答）を示します。現在、1つのバージョンがあります。IPP/1.0の構文は、[RFC2565]のセクション3「動作層のエンコード」で説明されており、セマンティクスは[RFC2566]で説明されています。
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations:
考慮事項のエンコード：
IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
IPP/1.0プロトコル要求/応答には、長い行が含まれており、常にバイナリデータ（属性値の長さなど）が含まれている場合があります。
Security considerations:
セキュリティ上の考慮事項：
IPP/1.0 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2566] as well as protocol encoding rules in [RFC2565] are complete and unambiguous.
IPP/1.0プロトコル要求/応答は、基礎となる輸送プロトコルにまだ固有のセキュリティリスクを導入しません。[RFC2566]のプロトコルの混合バージョンインターワーキングルールと、[RFC2565]のプロトコルエンコードルールは完全かつ明確です。
Interoperability considerations:
相互運用性の考慮事項：
IPP/1.0 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2566] and [RFC2565]. Protocol encoding rules specified in [RFC2565] are comprehensive, so that interoperability between conforming implementations is guaranteed (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP/1.0 attribute values which are a LOCALIZED-STRING are explicit within IPP protocol requests/responses (without recourse to any external information in HTTP, SMTP, or other message transport headers).
IPP/1.0リクエスト（クライアントによって生成）および応答（サーバーによって生成）は、規範的仕様[RFC2566]および[RFC2565]によって課されるすべての適合要件に準拠する必要があります。[RFC2565]で指定されたプロトコルエンコードルールは包括的であるため、適合実装間の相互運用性が保証されます（ただし、特定のオプション機能のサポートは保証されていません）。ローカライズされたストリングであるすべてのIPP/1.0属性値の「charset」と「natural-language」の両方は、IPPプロトコル要求/応答内で明示的です（HTTP、SMTP、またはその他のメッセージトランスポートヘッダーの外部情報に頼ることなく）。
Published specification:
公開された仕様：
[RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics" RFC 2566, April 1999.
[RFC2566] Isaacson、S.、Debry、R.、Hastings、T.、Herriot、R。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」RFC 2566、1999年4月。
[RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565] Herriot、R。、Butler、S.、Moore、P.、Tuner、R。、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Internet Printing Protocol (IPP) print clients and print servers, communicating using HTTP/1.1 (see [RFC2565]), SMTP/ESMTP, FTP, or other transport protocol. Messages of type "application/ipp" are self-contained and transport-independent, including "charset" and "natural-language" context for any LOCALIZED-STRING value.
インターネット印刷プロトコル（IPP）印刷クライアントと印刷サーバー、HTTP/1.1（[RFC2565]を参照）、SMTP/ESMTP、FTP、またはその他の輸送プロトコルを使用して通信します。タイプ「Application/IPP」のメッセージは、ローカライズされた弦の値に対する「Charset」および「自然言語」コンテキストを含む、自己完結型および輸送に依存しません。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606
Scott A. Isaacson Novell、Inc。122 E 1700 S Provo、UT 84606
Phone: 801-861-7366 Fax: 801-861-4025 Email: sisaacson@novell.com
電話：801-861-7366ファックス：801-861-4025メール：sisaacson@novell.com
or
または又はそれとも若しくは乃至或るいは
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Robert Herriot（編集者）Xerox Corporation 3400 Hillview Ave.、Bldg＃1 Palo Alto、CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
電話：650-813-7696ファックス：650-813-6860メール：rherriot@pahv.xerox.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。