[要約] RFC 8010は、Internet Printing Protocol/1.1のエンコーディングとトランスポートに関する仕様です。このRFCの目的は、プリンターとクライアント間の通信を効率的かつセキュアに行うためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) M. Sweet
Request for Comments: 8010 Apple Inc.
Obsoletes: 2910, 3382 I. McDonald
Category: Standards Track High North, Inc.
ISSN: 2070-1721 January 2017
Internet Printing Protocol/1.1: Encoding and Transport
Internet Printing Protocol / 1.1：エンコーディングとトランスポート
Abstract
概要
The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The IPP data model and operation semantics are described in "Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).
インターネット印刷プロトコル（IPP）は、インターネットツールとテクノロジを使用した分散印刷のためのアプリケーションレベルのプロトコルです。このドキュメントでは、IPP操作、属性、および値を "application / ipp"と呼ばれるインターネットMIMEメディアタイプにエンコードするためのルールを定義します。また、HTTPやHTTPSを介してContent-Typeが「application / ipp」であるメッセージ本文を転送するためのルールも定義します。 IPPデータモデルと操作のセマンティクスについては、「インターネット印刷プロトコル/1.1：モデルとセマンティクス」（RFC 8011）で説明しています。
This document obsoletes RFCs 2910 and 3382.
このドキュメントはRFC 2910および3382を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8010.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8010で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Printing Terminology . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Encoding of the Operation Layer . . . . . . . . . . . . . . . 6
3.1. Picture of the Encoding . . . . . . . . . . . . . . . . . 8
3.1.1. Request and Response . . . . . . . . . . . . . . . . 8
3.1.2. Attribute Group . . . . . . . . . . . . . . . . . . . 9
3.1.3. Attribute . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Attribute-with-one-value . . . . . . . . . . . . . . 10
3.1.5. Additional-value . . . . . . . . . . . . . . . . . . 11
3.1.6. Collection Attribute . . . . . . . . . . . . . . . . 12
3.1.7. Member Attributes . . . . . . . . . . . . . . . . . . 13
3.1.8. Alternative Picture of the Encoding of a Request or a
Response . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Syntax of Encoding . . . . . . . . . . . . . . . . . . . 15
3.3. Attribute-group . . . . . . . . . . . . . . . . . . . . . 16
3.4. Required Parameters . . . . . . . . . . . . . . . . . . . 18
3.4.1. "version-number" . . . . . . . . . . . . . . . . . . 18
3.4.2. "operation-id" . . . . . . . . . . . . . . . . . . . 18
3.4.3. "status-code" . . . . . . . . . . . . . . . . . . . . 19
3.4.4. "request-id" . . . . . . . . . . . . . . . . . . . . 19
3.5. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. "delimiter-tag" Values . . . . . . . . . . . . . . . 19
3.5.2. "value-tag" Values . . . . . . . . . . . . . . . . . 20
3.6. "name-length" . . . . . . . . . . . . . . . . . . . . . . 23
3.7. (Attribute) "name" . . . . . . . . . . . . . . . . . . . 23
3.8. "value-length" . . . . . . . . . . . . . . . . . . . . . 23
3.9. (Attribute) "value" . . . . . . . . . . . . . . . . . . . 24
3.10. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. Encoding of Transport Layer . . . . . . . . . . . . . . . . . 26
4.1. Printer URI, Job URI, and Job ID . . . . . . . . . . . . 26
5. IPP URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Internationalization Considerations . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Conformance Requirements . . . . . . . . . . . . 31
8.1.1. Digest Authentication . . . . . . . . . . . . . . . . 32
8.1.2. Transport Layer Security (TLS) . . . . . . . . . . . 32
8.2. Using IPP with TLS . . . . . . . . . . . . . . . . . . . 33
9. Interoperability with Other IPP Versions . . . . . . . . . . 33
9.1. The "version-number" Parameter . . . . . . . . . . . . . 34
9.2. Security and URI Schemes . . . . . . . . . . . . . . . . 34
10. Changes since RFC 2910 . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Protocol Examples . . . . . . . . . . . . . . . . . 40
A.1. Print-Job Request . . . . . . . . . . . . . . . . . . . . 40
A.2. Print-Job Response (Successful) . . . . . . . . . . . . . 41
A.3. Print-Job Response (Failure) . . . . . . . . . . . . . . 42
A.4. Print-Job Response (Success with Attributes Ignored) . . 43
A.5. Print-URI Request . . . . . . . . . . . . . . . . . . . . 45
A.6. Create-Job Request . . . . . . . . . . . . . . . . . . . 46
A.7. Create-Job Request with Collection Attributes . . . . . . 46
A.8. Get-Jobs Request . . . . . . . . . . . . . . . . . . . . 48
A.9. Get-Jobs Response . . . . . . . . . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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 request and response. All IPP implementations support HTTP/1.1, the relevant parts of which are described in the following RFCs:
トランスポート層は、HTTP要求と応答で構成されます。すべてのIPP実装はHTTP / 1.1をサポートしており、その関連部分は次のRFCで説明されています。
o Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing [RFC7230]
o ハイパーテキスト転送プロトコル（HTTP / 1.1）：メッセージの構文とルーティング[RFC7230]
o Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [RFC7231]
o ハイパーテキスト転送プロトコル（HTTP / 1.1）：セマンティクスとコンテンツ[RFC7231]
o Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests [RFC7232]
o ハイパーテキスト転送プロトコル（HTTP / 1.1）：条件付きリクエスト[RFC7232]
o Hypertext Transfer Protocol (HTTP/1.1): Caching [RFC7234]
o ハイパーテキスト転送プロトコル（HTTP / 1.1）：キャッシュ[RFC7234]
o Hypertext Transfer Protocol (HTTP/1.1): Authentication [RFC7235]
o ハイパーテキスト転送プロトコル（HTTP / 1.1）：認証[RFC7235]
o The 'Basic' HTTP Authentication Scheme [RFC7617]
o 「基本」HTTP認証スキーム[RFC7617]
o HTTP Digest Access Authentication [RFC7616]
o HTTPダイジェストアクセス認証[RFC7616]
IPP implementations can support HTTP/2, which is described in the following RFCs:
IPP実装は、次のRFCで説明されているHTTP / 2をサポートできます。
o Hypertext Transfer Protocol Version 2 (HTTP/2) [RFC7540]
o ハイパーテキスト転送プロトコルバージョン2（HTTP / 2）[RFC7540]
o HPACK - Header Compression for HTTP/2 [RFC7541]
o HPACK-HTTP / 2のヘッダー圧縮[RFC7541]
This document specifies the HTTP headers that an IPP implementation supports.
このドキュメントは、IPP実装がサポートするHTTPヘッダーを指定します。
The operation layer consists of a message body in an HTTP request or response. The "Internet Printing Protocol/1.1: Model and Semantics" document [RFC8011] and subsequent extensions (collectively known as the IPP Model) define the semantics of such a message body and the supported values. This document specifies the encoding of an IPP request and response message.
操作レイヤーは、HTTP要求または応答のメッセージ本文で構成されます。 「インターネット印刷プロトコル/1.1：モデルとセマンティクス」ドキュメント[RFC8011]およびその後の拡張（まとめてIPPモデルと呼ばれる）は、そのようなメッセージ本文のセマンティクスとサポートされる値を定義します。このドキュメントは、IPP要求と応答メッセージのエンコーディングを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Client: Initiator of outgoing IPP session requests and sender of outgoing IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230] User Agent).
クライアント：発信IPPセッション要求の発信者と発信IPP操作要求の送信者（ハイパーテキスト転送プロトコル-HTTP / 1.1 [RFC7230]ユーザーエージェント）。
Document: An object created and managed by a Printer that contains description, processing, and status information. A Document object may have attached data and is bound to a single Job.
ドキュメント：説明、処理、およびステータス情報を含む、プリンターによって作成および管理されるオブジェクト。 Documentオブジェクトにはデータが添付されている場合があり、単一のジョブにバインドされます。
'ipp' URI: An IPP URI as defined in [RFC3510].
'ipp' URI：[RFC3510]で定義されているIPP URI。
'ipps' URI: An IPPS URI as defined in [RFC7472].
'ipps' URI：[RFC7472]で定義されているIPPS URI。
Job: An object created and managed by a Printer that contains description, processing, and status information. The Job also contains zero or more Document objects.
ジョブ：説明、処理、およびステータス情報を含む、プリンターによって作成および管理されるオブジェクト。ジョブには0個以上のDocumentオブジェクトも含まれます。
Logical Device: A print server, software service, or gateway that processes Jobs and either forwards or stores the processed Job or uses one or more Physical Devices to render output.
論理デバイス：ジョブを処理し、処理したジョブを転送または保存するか、1つ以上の物理デバイスを使用して出力をレンダリングするプリントサーバー、ソフトウェアサービス、またはゲートウェイ。
Model: The semantics of operations, attributes, values, and status-codes used in the Internet Printing Protocol as defined in the Internet Printing Protocol/1.1: Model and Semantics document [RFC8011] and subsequent extensions.
モデル：Internet Printing Protocol / 1.1：Model and Semanticsドキュメント[RFC8011]とその後の拡張で定義されている、インターネット印刷プロトコルで使用される操作、属性、値、およびステータスコードのセマンティクス。
Output Device: A single Logical or Physical Device.
出力デバイス：単一の論理デバイスまたは物理デバイス。
Physical Device: A hardware implementation of an endpoint device, e.g., a marking engine, a fax modem, etc.
物理デバイス：マーキングエンジン、ファックスモデムなどのエンドポイントデバイスのハードウェア実装。
Printer: Listener for incoming IPP session requests and receiver of incoming IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230] Server) that represents one or more Physical Devices or a Logical Device.
プリンター：1つ以上の物理デバイスまたは論理デバイスを表す、着信IPPセッション要求のリスナーおよび着信IPP操作要求の受信者（ハイパーテキスト転送プロトコル-HTTP / 1.1 [RFC7230]サーバー）。
ABNF: Augmented Backus-Naur Form [RFC5234]
ABNF：拡張バッカスナウアフォーム[RFC5234]
ASCII: American Standard Code for Information Interchange [RFC20]
ASCII：情報交換のためのアメリカ標準コード[RFC20]
HTTP: Hypertext Transfer Protocol [RFC7230]
HTTP：ハイパーテキスト転送プロトコル[RFC7230]
HTTPS: HTTP over TLS [RFC2818]
HTTPS：HTTP over TLS [RFC2818]
IANA: Internet Assigned Numbers Authority
IANA：Internet Assigned Numbers Authority
IEEE: Institute of Electrical and Electronics Engineers
IEEE：Institute of Electrical and Electronics Engineers
IESG: Internet Engineering Steering Group
IESG：Internet Engineering Steering Group
IPP: Internet Printing Protocol (this document and [PWG5100.12])
IPP：Internet Printing Protocol（このドキュメントと[PWG5100.12]）
ISTO: IEEE Industry Standards and Technology Organization
ISTO：IEEE業界標準および技術組織
LPD: Line Printer Daemon Protocol [RFC1179]
LPD：Line Printer Daemon Protocol [RFC1179]
PWG: IEEE-ISTO Printer Working Group
PWG：IEEE-ISTOプリンターワーキンググループ
RFC: Request for Comments
RFC：コメントのリクエスト
TCP: Transmission Control Protocol [RFC793]
TCP：伝送制御プロトコル[RFC793]
TLS: Transport Layer Security [RFC5246]
TLS：トランスポート層セキュリティ[RFC5246]
URI: Uniform Resource Identifier [RFC3986]
うり： うにふぉｒｍ れそうｒせ いでんちふぃえｒ 「ＲＦＣ３９８６」
URL: Uniform Resource Locator [RFC3986]
URL：Uniform Resource Locator [RFC3986]
UTF-8: Unicode Transformation Format - 8-bit [RFC3629]
UTF-8：Unicode Transformation Format-8-bit [RFC3629]
The operation layer is the message body part of the HTTP request or response and it MUST contain a single IPP operation request or IPP 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.
操作層は、HTTP要求または応答のメッセージ本文部分であり、単一のIPP操作要求またはIPP操作応答を含める必要があります。各要求または応答は、一連の値と属性グループで構成されます。属性グループは、それぞれが名前と値である一連の属性で構成されます。名前と値は、最終的にはオクテットのシーケンスです。
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 [RFC2978] 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 and 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 is henceforth called a LOCALIZED-STRING. An octet string MUST be in "Model order" with the first octet in the value (according to the Model 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. A one-octet integer, henceforth called a SIGNED-BYTE, is used for the version-number and tag fields. A two-byte integer, henceforth called a SIGNED-SHORT, is used for the operation-id, status-code, and length fields. A four-byte integer, henceforth called a SIGNED-INTEGER, is used for value fields and the request-id.
エンコーディングは、最もプリミティブなタイプとしてのオクテットで構成されています。オクテットから構築されるいくつかの型がありますが、3つの重要な型は整数、文字列、およびオクテット文字列であり、その上に他のほとんどのデータ型が構築されます。このエンコーディングのすべての文字列は、文字がいくつかの文字セット[RFC2978]といくつかの自然言語に関連付けられている一連の文字である必要があります。文字列は「読み取り順序」である必要があり、値の最初の文字は（読み取り順序に従って）エンコードの最初の文字になります。関連する文字セットがUS-ASCIIであり、関連する自然言語が米国英語である文字列は、以降US-ASCII-STRINGと呼ばれます。関連する文字セットと自然言語がモデルで説明されているように要求または応答で指定されている文字列は、以後LOCALIZED-STRINGと呼ばれます。オクテット文字列は、「モデル順」である必要があり、値の最初のオクテット（モデル順による）は、エンコーディングの最初のオクテットです。このエンコーディングのすべての整数は、ビッグエンディアン形式の「2の補数」バイナリエンコーディング（「ネットワーク順序」および「最上位バイトファースト」とも呼ばれる）を使用して、符号付き整数としてエンコードする必要があります。整数のオクテット数は、プロトコルでの使用に応じて、1、2、または4でなければなりません。 1オクテット整数（以降、SIGNED-BYTEと呼ばれる）は、バージョン番号とタグフィールドに使用されます。 2バイト整数（以降、SIGNED-SHORTと呼ばれる）は、operation-id、status-code、およびlengthフィールドに使用されます。値フィールドとrequest-idには、以降SIGNED-INTEGERと呼ばれる4バイト整数が使用されます。
The following two sections present the encoding of the operation layer in two ways:
次の2つのセクションでは、操作レイヤーのエンコーディングを2つの方法で示します。
o informally through pictures and description
o 写真と説明を通して非公式に
o formally through Augmented Backus-Naur Form (ABNF), as specified by RFC 5234 [RFC5234]
o RFC 5234 [RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）を介して正式に
An operation request or response MUST use the encoding described in these two sections.
操作の要求または応答では、これらの2つのセクションで説明されているエンコーディングを使用する必要があります。
An operation request or response is encoded as follows:
操作の要求または応答は、次のようにエンコードされます。
-----------------------------------------------
| 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
-----------------------------------------------
Figure 1: IPP Message Format
図1：IPPメッセージ形式
The first three fields in the above diagram contain the value of attributes described in Section 4.1.1 of the Model and Semantics document [RFC8011].
上の図の最初の3つのフィールドには、モデルとセマンティクスのドキュメント[RFC8011]のセクション4.1.1で説明されている属性の値が含まれています。
The fourth field is the "attribute-group" field, and it occurs 0 or more times. Each "attribute-group" field represents a single group of attributes, such as an Operation Attributes group or a Job Attributes group (see the Model). The Model specifies the required attribute groups and their order for each operation request and response.
4番目のフィールドは「属性グループ」フィールドであり、0回以上発生します。各「属性グループ」フィールドは、操作属性グループやジョブ属性グループなどの属性の単一グループを表します（モデルを参照）。モデルは、各操作の要求と応答に必要な属性グループとその順序を指定します。
The "end-of-attributes-tag" field is always present, even when the "data" is not present. The Model specifies whether the "data" field is present for each operation request and response.
「data-」が存在しない場合でも、「end-of-attributes-tag」フィールドは常に存在します。モデルは、各操作要求と応答に対して「データ」フィールドが存在するかどうかを指定します。
Each "attribute-group" field is encoded as follows:
各「属性グループ」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| begin-attribute-group-tag | 1 byte
----------------------------------------------------------
| attribute | p bytes |- 0 or more
----------------------------------------------------------
Figure 2: Attribute Group Encoding
図2：属性グループのエンコード
An "attribute-group" field contains zero or more "attribute" fields.
「属性グループ」フィールドには、0個以上の「属性」フィールドが含まれます。
Note that the values of the "begin-attribute-group-tag" field and the "end-of-attributes-tag" field are called "delimiter-tags".
「begin-attribute-group-tag」フィールドと「end-of-attributes-tag」フィールドの値は「delimiter-tags」と呼ばれることに注意してください。
An "attribute" field is encoded as follows:
「属性」フィールドは次のようにエンコードされます。
-----------------------------------------------
| attribute-with-one-value | q bytes
----------------------------------------------------------
| additional-value | r bytes |- 0 or more
----------------------------------------------------------
Figure 3: Attribute Encoding
図3：属性のエンコード
When an attribute is single valued (e.g., "copies" with a value of 10) or multi-valued with one value (e.g., "sides-supported" with just the value 'one-sided'), it is encoded with just an "attribute-with-one-value" field. When an attribute is multi-valued with n values (e.g., "sides-supported" with the values 'one-sided' and 'two-sided-long-edge'), it is encoded with an "attribute-with-one-value" field followed by n-1 "additional-value" fields.
属性が単一値（たとえば、値が10の「コピー」）または1つの値を持つ複数値（たとえば、「片面」のみの値を持つ「サイドサポート」）の場合、属性は「attribute-with-one-value」フィールド。属性がn個の値を持つ複数値の場合（たとえば、「sides-supported」の値が「one-sided」と「two-sided-long-edge」の場合）、「attribute-with-one- 「値」フィールドの後にn-1個の「追加の値」フィールドが続きます。
Each "attribute-with-one-value" field is encoded as follows:
各「1つの値を持つ属性」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is v) | 2 bytes
-----------------------------------------------
| value | v bytes
-----------------------------------------------
Figure 4: Single Value Attribute Encoding
図4：単一値属性エンコーディング
An "attribute-with-one-value" field is encoded with five subfields:
「1つの値を持つ属性」フィールドは、5つのサブフィールドでエンコードされます。
o The "value-tag" field specifies the attribute syntax, e.g., 0x44 for the attribute syntax 'keyword'.
o 「値タグ」フィールドは、属性構文を指定します。たとえば、属性構文「キーワード」の0x44です。
o The "name-length" field specifies the length of the "name" field in bytes, e.g., u in the above diagram or 15 for the name "sides-supported".
o 「name-length」フィールドは、「name」フィールドの長さをバイトで指定します。たとえば、上の図のuまたは「sides-supported」の名前の場合は15です。
o The "name" field contains the textual name of the attribute, e.g., "sides-supported".
o 「name」フィールドには、「sides-supported」などの属性のテキスト名が含まれます。
o The "value-length" field specifies the length of the "value" field in bytes, e.g., v in the above diagram or 9 for the (keyword) value 'one-sided'.
o 「value-length」フィールドは、「value」フィールドの長さをバイト単位で指定します。たとえば、上の図のvまたは（keyword）値「one-sided」の場合は9です。
o The "value" field contains the value of the attribute, e.g., the textual value 'one-sided'.
o 「値」フィールドには、属性の値が含まれます（例：テキスト値「片側」）。
Each "additional-value" field is encoded as follows:
各「追加値」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| value-length (value is w) | 2 bytes
-----------------------------------------------
| value | w bytes
-----------------------------------------------
Figure 5: Additional Attribute Value Encoding
図5：追加の属性値エンコーディング
An "additional-value" is encoded with four subfields:
「追加の値」は、4つのサブフィールドでエンコードされます。
o The "value-tag" field specifies the attribute syntax, e.g., 0x44 for the attribute syntax 'keyword'.
o 「値タグ」フィールドは、属性構文を指定します。たとえば、属性構文「キーワード」の0x44です。
o The "name-length" field has the value of 0 in order to signify that it is an "additional-value". The value of the "name-length" field distinguishes an "additional-value" field ("name-length" is 0) from an "attribute-with-one-value" field ("name-length" is not 0).
o 「name-length」フィールドは、「追加の値」であることを示すために値0を持っています。 「name-length」フィールドの値は、「additional-value」フィールド（「name-length」は0）と「attribute-with-one-value」フィールド（「name-length」は0ではない）を区別します。
o The "value-length" field specifies the length of the "value" field in bytes, e.g., w in the above diagram or 19 for the (keyword) value 'two-sided-long-edge'.
o 「value-length」フィールドは、「value」フィールドの長さをバイトで指定します。たとえば、上図のwまたは（キーワード）値「two-sided-long-edge」の場合は19です。
o The "value" field contains the value of the attribute, e.g., the textual value 'two-sided-long-edge'.
o 「値」フィールドには、属性の値が含まれます。たとえば、テキスト値「two-sided-long-edge」です。
Collection attributes create a named group containing related "member" attributes. The "attribute-with-one-value" field for a collection attribute is encoded as follows:
コレクション属性は、関連する「メンバー」属性を含む名前付きグループを作成します。コレクション属性の「attribute-with-one-value」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| value-tag (value is 0x34) | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is 0x0000) | 2 bytes
-----------------------------------------------------------
| member-attribute | q bytes |-0 or more
-----------------------------------------------------------
| end-value-tag (value is 0x37) | 1 byte
-----------------------------------------------
| end-name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| end-value-length (value is 0x0000) | 2 bytes
-----------------------------------------------
Figure 6: Collection Attribute Encoding
図6：コレクション属性のエンコード
Collection attribute is encoded with eight subfields:
コレクション属性は、8つのサブフィールドでエンコードされます。
o The "value-tag" field specifies the start attribute syntax: 0x34 for the attribute syntax 'begCollection'.
o 「value-tag」フィールドは、属性構文「begCollection」の開始属性構文0x34を指定します。
o The "name-length" field specifies the length of the "name" field in bytes, e.g., u in the above diagram or 9 for the name "media-col". Additional collection attribute values use a name length of 0x0000.
o 「name-length」フィールドは、「name」フィールドの長さをバイト単位で指定します。たとえば、上の図のuまたは「media-col」という名前の場合は9です。追加のコレクション属性値は、名前の長さ0x0000を使用します。
o The "name" field contains the textual name of the attribute, e.g., "media-col".
o 「name」フィールドには、「media-col」などの属性のテキスト名が含まれます。
o The "value-length" field specifies a length of 0x0000.
o 「value-length」フィールドは0x0000の長さを指定します。
o The "member-attribute" field contains member attributes encoded as defined in Section 3.1.7.
o 「メンバー属性」フィールドには、セクション3.1.7で定義されているようにエンコードされたメンバー属性が含まれます。
o The "end-value-tag" field specifies the end attribute syntax: 0x37 for the attribute syntax 'endCollection'.
o 「end-value-tag」フィールドは、属性構文「endCollection」の終了属性構文0x37を指定します。
o The "end-name-length" field specifies a length of 0x0000.
o 「end-name-length」フィールドは0x0000の長さを指定します。
o The "end-value-length" field specifies a length of 0x0000.
o 「end-value-length」フィールドは0x0000の長さを指定します。
Each "member-attribute" field is encoded as follows:
各「メンバー属性」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| value-tag (value is 0x4a) | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| value-length (value is w) | 2 bytes
-----------------------------------------------
| value (member-name) | w bytes
-----------------------------------------------
| member-value-tag | 1 byte
-----------------------------------------------
| name-length (value is 0x0000) | 2 bytes
-----------------------------------------------
| member-value-length (value is x) | 2 bytes
-----------------------------------------------
| member-value | x bytes
-----------------------------------------------
Figure 7: Member Attribute Encoding
図7：メンバー属性のエンコード
A "member-attribute" is encoded with eight subfields:
「メンバー属性」は、8つのサブフィールドでエンコードされます。
o The "value-tag" field specifies 0x4a for the attribute syntax 'memberAttrName'.
o 「value-tag」フィールドは、属性構文「memberAttrName」に0x4aを指定します。
o The "name-length" field has the value of 0 in order to signify that it is a "member-attribute" contained in the collection.
o コレクションに含まれる「メンバー属性」であることを示すために、「name-length」フィールドの値は0です。
o The "value-length" field specifies the length of the "value" field in bytes, e.g., w in the above diagram or 10 for the member attribute name 'media-type'. Additional member attribute values are specified using a value length of 0.
o 「value-length」フィールドは、「value」フィールドの長さをバイト単位で指定します。たとえば、上の図のwまたはメンバー属性名「media-type」の場合は10です。追加のメンバー属性値は、値の長さ0を使用して指定されます。
o The "value" field contains the name of the member attribute, e.g., the textual value 'media-type'.
o 「値」フィールドには、メンバー属性の名前が含まれます（例：テキスト値「メディアタイプ」）。
o The "member-value-tag" field specifies the attribute syntax for the member attribute, e.g., 0x44 for the attribute syntax 'keyword'.
o 「メンバー値タグ」フィールドは、メンバー属性の属性構文を指定します。たとえば、属性構文「キーワード」の0x44です。
o The second "name-length" field has the value of 0 in order to signify that it is a "member-attribute" contained in the collection.
o 2番目の「name-length」フィールドの値は0で、これがコレクションに含まれる「メンバー属性」であることを示します。
o The "member-value-length" field specifies the length of the member attribute value, e.g., x in the above diagram or 10 for the value 'stationery'.
o 「member-value-length」フィールドは、メンバー属性値の長さを指定します。たとえば、上の図のxまたは値 'stationery'の場合は10。
o The "member-value" field contains the value of the attribute, e.g., the textual value 'stationery'.
o 「メンバー値」フィールドには、テキストの値「ステーショナリー」などの属性の値が含まれます。
From the standpoint of a parser that performs an action based on a "tag" value, 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 | 1 byte - required
-----------------------------------------------
| data | y bytes - optional
-----------------------------------------------
Figure 8: Encoding Based on Value Tags
図8：値タグに基づくエンコード
The following shows what fields the parser would expect after each type of "tag":
以下は、各タイプの「タグ」の後にパーサーが予期するフィールドを示しています。
o "begin-attribute-group-tag": expect zero or more "attribute" fields
o "begin-attribute-group-tag"：0個以上の "attribute"フィールドが必要です
o "value-tag": expect the remainder of an "attribute-with-one-value" or an "additional-value"
o 「値タグ」：「1つの値を持つ属性」または「追加の値」の残りを期待する
o "end-of-attributes-tag": expect that "attribute" fields are complete and there is optional "data"
o 「end-of-attributes-tag」：「attribute」フィールドが完全であり、オプションの「data」があることを期待
The ABNF [RFC5234] syntax for an IPP message is shown in Figure 9.
IPPメッセージのABNF [RFC5234]構文を図9に示します。
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
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 *属性グループの属性終了タグデータ
version-number = major-version-number minor-version-number major-version-number = SIGNED-BYTE minor-version-number = SIGNED-BYTE
バージョン番号=メジャーバージョン番号マイナーバージョン番号メジャーバージョン番号= SIGNED-BYTEマイナーバージョン番号= SIGNED-BYTE
operation-id = SIGNED-SHORT ; mapping from model
status-code = SIGNED-SHORT ; mapping from model
request-id = SIGNED-INTEGER ; whose value is > 0
attribute-group = begin-attribute-group-tag *attribute 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
attribute-group = begin-attribute-group-tag * attribute attribute = attribute-with-one-value * additional-value attribute-with-one-value = value-tag name-length name value-length value additional-value = value -タグゼロ名前長さ値長さ値
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
value-tag = %x10-ff ; see Section 3.5.2
begin-attribute-group-tag = %x00-02 / %x04-0f ; see Section 3.5.1
end-of-attributes-tag = %x03 ; tag of 3
; see Section 3.5.1
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
Figure 9: ABNF of IPP Message Format
図9：IPPメッセージ形式のABNF
Figure 10 defines additional terms that are referenced in this document and provides an alternate grouping of the delimiter tags.
図10は、このドキュメントで参照される追加の用語を定義し、区切りタグの代替グループを提供します。
delimiter-tag = begin-attribute-group-tag / ; see Section 3.5.1
end-of-attributes-tag
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / future-group-tags
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
end-of-attributes-tag = %x03 ; tag of 3
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
future-group-tags = %x06-0f ; future extensions
Figure 10: ABNF for Attribute Group Tags
図10：属性グループタグのABNF
Each "attribute-group" field MUST be encoded with the "begin-attribute-group-tag" field followed by zero or more "attribute" sub-fields.
各「属性グループ」フィールドは、「開始属性グループタグ」フィールドの後に0個以上の「属性」サブフィールドを続けてエンコードする必要があります。
Table 1 maps the Model group name to value of the "begin-attribute-group-tag" field:
表1は、モデルグループ名を「begin-attribute-group-tag」フィールドの値にマップします。
+----------------+--------------------------------------------------+
| Model Document | "begin-attribute-group-tag" field values |
| Group | |
+----------------+--------------------------------------------------+
| Operation | "operations-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Job Template | "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Job Object | "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Unsupported | "unsupported-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Requested | (Get-Job-Attributes) "job-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Requested | (Get-Printer-Attributes)"printer-attributes-tag" |
| Attributes | |
+----------------+--------------------------------------------------+
| Document | in a special position at the end of the message |
| Content | as described in Section 3.1.1. |
+----------------+--------------------------------------------------+
Table 1: Group Values
表1：グループ値
For each operation request and response, the Model prescribes the required and optional attribute groups, along with their order. Within each attribute group, the Model prescribes the required and optional attributes, along with their order.
各操作の要求と応答について、モデルは必須およびオプションの属性グループとその順序を規定します。各属性グループ内で、モデルは必須およびオプションの属性とその順序を規定します。
When the Model requires an attribute group in a request or response and the attribute group contains zero attributes, a request or response SHOULD encode the attribute group with the "begin-attribute-group-tag" field followed by zero "attribute" fields. For example, if the Client requests a single unsupported attribute with the Get-Printer-Attributes operation, the Printer MUST return no "attribute" fields, and it SHOULD return a "begin-attribute-group-tag" field for the Printer Attributes group. The Unsupported Attributes group is not such an example. According to the Model, the Unsupported Attributes group SHOULD be present only if the Unsupported Attributes group contains at least one attribute.
モデルがリクエストまたはレスポンスで属性グループを必要とし、属性グループにゼロの属性が含まれる場合、リクエストまたはレスポンスは、「begin-attribute-group-tag」フィールドの後にゼロの「attribute」フィールドが続く属性グループをエンコードする必要があります。たとえば、クライアントがGet-Printer-Attributes操作でサポートされていない単一の属性を要求した場合、プリンターは「属性」フィールドを返さない必要があり、プリンター属性グループの「begin-attribute-group-tag」フィールドを返す必要があります（SHOULD）。 。 Unsupported Attributesグループはそのような例ではありません。モデルによれば、サポートされていない属性グループは、サポートされていない属性グループに少なくとも1つの属性が含まれている場合にのみ存在する必要があります。
A receiver of a request MUST be able to process the following as equivalent empty attribute groups:
リクエストの受信者は、以下を同等の空の属性グループとして処理できる必要があります：
a. A "begin-attribute-group-tag" field with zero following "attribute" fields.
a. 「属性」フィールドに続くゼロの「開始属性グループタグ」フィールド。
b. A missing, but expected, "begin-attribute-group-tag" field.
b. 「begin-attribute-group-tag」フィールドが欠落していますが、予期されています。
When the Model requires a sequence of an unknown number of attribute groups, each of the same type, the encoding MUST contain one "begin-attribute-group-tag" field for each attribute group, even when an "attribute-group" field contains zero "attribute" sub-fields. For example, the Get-Jobs operation may return zero attributes for some Jobs and not others. The "begin-attribute-group-tag" field followed by zero "attribute" fields tells the recipient that there is a Job in queue for which no information is available except that it is in the queue.
モデルが、同じタイプの未知の数の属性グループのシーケンスを必要とする場合、「属性グループ」フィールドが含まれている場合でも、エンコーディングには各属性グループに対して「開始属性グループタグ」フィールドが1つ含まれている必要があります。 「属性」サブフィールドはゼロ。たとえば、Get-Jobs操作は、一部のジョブではゼロの属性を返し、他のジョブでは返さない場合があります。 「begin-attribute-group-tag」フィールドの後にゼロの「attribute」フィールドが続くと、受信者に、キュー内にあることを除いて、利用可能な情報がないジョブがキュー内にあることが通知されます。
Some operation elements are called parameters in the Model. They MUST be encoded in a special position and they MUST NOT appear as operation attributes. These parameters are described in the subsections below.
一部の操作要素は、モデルではパラメーターと呼ばれます。これらは特別な位置にエンコードする必要があり、操作属性として表示してはなりません。これらのパラメーターについては、以下のサブセクションで説明します。
The "version-number" field consists of a major and minor version-number, each of which is represented by a SIGNED-BYTE. The major version-number is the first byte of the encoding and the minor version-number is the second byte of the encoding. The protocol described in [RFC8011] has a major version-number of 1 (0x01) and a minor version-number of 1 (0x01). The ABNF for these two bytes is %x01.01.
「バージョン番号」フィールドは、メジャーバージョン番号とマイナーバージョン番号で構成され、それぞれがSIGNED-BYTEで表されます。メジャーバージョン番号はエンコードの最初のバイトで、マイナーバージョン番号はエンコードの2番目のバイトです。 [RFC8011]で説明されているプロトコルには、メジャーバージョン番号1（0x01）とマイナーバージョン番号1（0x01）があります。これらの2バイトのABNFは％x01.01です。
Note: See Section 9 for more information on the "version-number" field and IPP version numbers.
注：「バージョン番号」フィールドとIPPバージョン番号の詳細については、セクション9を参照してください。
The "operation-id" field contains an operation-id value as defined in the Model. The value is encoded as a SIGNED-SHORT and is located in the third and fourth bytes of the encoding of an operation request.
「operation-id」フィールドには、モデルで定義されたoperation-id値が含まれます。値はSIGNED-SHORTとしてエンコードされ、操作要求のエンコードの3番目と4番目のバイトにあります。
The "status-code" field contains a status-code value as defined in the Model. The value is encoded as a SIGNED-SHORT and is located in the third and fourth bytes of the encoding of an operation response.
「ステータスコード」フィールドには、モデルで定義されているステータスコード値が含まれています。値はSIGNED-SHORTとしてエンコードされ、操作応答のエンコードの3番目と4番目のバイトにあります。
If an IPP status-code is returned, then the HTTP status-code MUST be 200 (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" field contains the request-id value as defined in the Model. The value is encoded as a SIGNED-INTEGER and is located in the fifth through eighth bytes of the encoding.
「request-id」フィールドには、モデルで定義されているrequest-id値が含まれています。値はSIGNED-INTEGERとしてエンコードされ、エンコードの5番目から8番目のバイトにあります。
There are two kinds of tags:
タグには次の2種類があります。
o delimiter tags: delimit major sections of the protocol, namely attribute groups and data
o 区切りタグ：プロトコルの主要セクション、つまり属性グループとデータを区切ります
o value tags: specify the type of each attribute value
o 値タグ：各属性値のタイプを指定します
Tags are part of the IANA IPP registry [IANA-IPP]
タグはIANA IPPレジストリの一部です[IANA-IPP]
Table 2 specifies the values for the delimiter tags defined in this document. These tags are registered, along with tags defined in other documents, in the "Attribute Group Tags" registry.
表2は、このドキュメントで定義されている区切りタグの値を示しています。これらのタグは、他のドキュメントで定義されたタグとともに、「属性グループタグ」レジストリに登録されます。
+-----------------+------------------------------+
| Tag Value (Hex) | Meaning |
+-----------------+------------------------------+
| 0x00 | Reserved |
| 0x01 | "operation-attributes-tag" |
| 0x02 | "job-attributes-tag" |
| 0x03 | "end-of-attributes-tag" |
| 0x04 | "printer-attributes-tag" |
| 0x05 | "unsupported-attributes-tag" |
+-----------------+------------------------------+
Table 2: "delimiter-tag" Values
表2：「区切りタグ」の値
When a "begin-attribute-group-tag" field occurs in the protocol, it means that zero or more following attributes up to the next group tag are attributes belonging to the attribute group specified by the value of the "begin-attribute-group-tag". For example, if the value of "begin-attribute-group-tag" is 0x01, the following attributes are members of the Operations Attributes group.
「begin-attribute-group-tag」フィールドがプロトコルで発生する場合、次のグループタグまでの0個以上の後続の属性は、「begin-attribute-group」の値で指定された属性グループに属する属性であることを意味します-鬼ごっこ"。たとえば、「begin-attribute-group-tag」の値が0x01の場合、次の属性は操作属性グループのメンバーです。
The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an operation and MUST be the last "delimiter-tag". If the operation has a document-data group, the Document data in that group follows the "end-of-attributes-tag".
「end-of-attributes-tag」（値0x03）は、操作で1回だけ発生し、最後の「delimiter-tag」でなければなりません（MUST）。操作にdocument-dataグループがある場合、そのグループのDocumentデータは「end-of-attributes-tag」の後に続きます。
The order and presence of "attribute-group" fields (whose beginning is marked by the "begin-attribute-group-tag" subfield) for each operation request and each operation response MUST be that defined in the Model.
各操作要求および各操作応答の「属性グループ」フィールド（先頭が「begin-attribute-group-tag」サブフィールドでマークされている）の順序と存在は、モデルで定義されたものでなければなりません。
A Printer MUST treat a "delimiter-tag" (values from 0x00 through 0x0f) differently from a "value-tag" (values from 0x10 through 0xff) so that the Printer knows there is an entire attribute group as opposed to a single value.
プリンターは、「区切りタグ」（0x00から0x0fまでの値）を「値タグ」（0x10から0xffまでの値）とは異なる方法で処理して、単一の値ではなく属性グループ全体が存在することをプリンターに認識させる必要があります。
The remaining tables show values for the "value-tag" field, which is the first octet of an attribute. The "value-tag" field specifies the type of the value of the attribute.
残りの表は、属性の最初のオクテットである「値タグ」フィールドの値を示しています。 「value-tag」フィールドは、属性の値のタイプを指定します。
Table 3 specifies the "out-of-band" values for the "value-tag" field defined in this document. These tags are registered, along with tags defined in other documents, in the "Out-of-Band Attribute Value Tags" registry.
表3は、このドキュメントで定義されている「value-tag」フィールドの「out-of-band」値を示しています。これらのタグは、他のドキュメントで定義されたタグとともに、「帯域外属性値タグ」レジストリに登録されます。
+-----------------+-------------+
| Tag Value (Hex) | Meaning |
+-----------------+-------------+
| 0x10 | unsupported |
| 0x12 | unknown |
| 0x13 | no-value |
+-----------------+-------------+
Table 3: Out-of-Band Values
表3：帯域外の値
Table 4 specifies the integer values defined in this document for the "value-tag" field; they are registered in the "Attribute Syntaxes" registry.
表4は、このドキュメントで「value-tag」フィールドに定義されている整数値を示しています。 「属性構文」レジストリに登録されています。
+----------------+--------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+----------------+--------------------------------------------------+
| 0x20 | Unassigned integer data type (see IANA IPP |
| | registry) |
| 0x21 | integer |
| 0x22 | boolean |
| 0x23 | enum |
| 0x24-0x2f | Unassigned integer data types (see IANA IPP |
| | registry) |
+----------------+--------------------------------------------------+
Table 4: Integer Tags
表4：整数タグ
Table 5 specifies the octetString values defined in this document for the "value-tag" field; they are registered in the "Attribute Syntaxes" registry.
表5は、このドキュメントで「value-tag」フィールドに定義されているoctetString値を示しています。 「属性構文」レジストリに登録されています。
+---------------+---------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+---------------+---------------------------------------------------+
| 0x30 | octetString with an unspecified format |
| 0x31 | dateTime |
| 0x32 | resolution |
| 0x33 | rangeOfInteger |
| 0x34 | begCollection |
| 0x35 | textWithLanguage |
| 0x36 | nameWithLanguage |
| 0x37 | endCollection |
| 0x38-0x3f | Unassigned octetString data types (see IANA IPP |
| | registry) |
+---------------+---------------------------------------------------+
Table 5: octetString Tags
表5：octetStringタグ
Table 6 specifies the character-string values defined in this document for the "value-tag" field; they are registered in the "Attribute Syntaxes" registry.
表6は、このドキュメントで「value-tag」フィールドに定義されている文字列値を示しています。 「属性構文」レジストリに登録されています。
+---------------+---------------------------------------------------+
| Tag Value | Meaning |
| (Hex) | |
+---------------+---------------------------------------------------+
| 0x40 | Unassigned character-string data type (see IANA |
| | IPP registry) |
| 0x41 | textWithoutLanguage |
| 0x42 | nameWithoutLanguage |
| 0x43 | Unassigned character-string data type (see IANA |
| | IPP registry) |
| 0x44 | keyword |
| 0x45 | uri |
| 0x46 | uriScheme |
| 0x47 | charset |
| 0x48 | naturalLanguage |
| 0x49 | mimeMediaType |
| 0x4a | memberAttrName |
| 0x4b-0x5f | Unassigned character-string data types (see IANA |
| | IPP registry) |
+---------------+---------------------------------------------------+
Table 6: String Tags
表6：文字列タグ
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 type definitions in Standards Track documents.
値0x60-0xffは、Standards Trackドキュメントの将来のタイプ定義用に予約されています。
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 four 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. Values from 0x00000000 to 0x3fffffff are reserved for definition in future Standards Track documents. The values 0x40000000 to 0x7fffffff are reserved for vendor extensions.
タグ0x7fは、1バイトで使用できる255の値を超えて型を拡張するために予約されています。タグ値0x7fは、値フィールドの最初の4バイトがタグ値として解釈されることを示している必要があります。この将来の拡張は、この特別なタグを認識しないパーサーには影響しません。このタグは他の不明なタグと同様であり、値の長さは値の長さを指定します。これには、パーサーがアトミックに処理する値が含まれます。 0x00000000から0x3fffffffの値は、将来のStandards Trackドキュメントでの定義のために予約されています。 0x40000000〜0x7fffffffの値は、ベンダー拡張用に予約されています。
The "name-length" field consists of a SIGNED-SHORT and specifies the number of octets in the immediately following "name" field. The value of this field excludes the two bytes of the "name-length" field. For example, if the "name" field contains 'sides', the value of this field is 5.
「name-length」フィールドはSIGNED-SHORTで構成され、直後の「name」フィールドのオクテット数を指定します。このフィールドの値は、「name-length」フィールドの2バイトを除外します。たとえば、「name」フィールドに「sides」が含まれている場合、このフィールドの値は5です。
If a "name-length" field has a value of zero, the following "name" field is empty and the following value is treated as an additional value for the attribute encoded in the nearest preceding "attribute-with-one-value" field. Within an attribute group, if two or more attributes have the same name, the attribute group is malformed (see [RFC8011]). The zero-length name is the only mechanism for multi-valued attributes.
「name-length」フィールドの値がゼロの場合、次の「name」フィールドは空で、次の値は直前の「attribute-with-one-value」フィールドでエンコードされた属性の追加値として扱われます。属性グループ内で、2つ以上の属性が同じ名前である場合、属性グループの形式が正しくありません（[RFC8011]を参照）。長さがゼロの名前は、多値属性の唯一のメカニズムです。
The "name" field contains the name of an attribute. The Model specifies such names.
「名前」フィールドには、属性の名前が含まれます。モデルはそのような名前を指定します。
The "value-length" field consists of a SIGNED-SHORT, which specifies the number of octets in the immediately following "value" field. The value of this field excludes the two bytes of the "value-length" field. For example, if the "value" field contains the keyword (string) value 'one-sided', the value of this field is 9.
「value-length」フィールドは、直後の「value」フィールドのオクテット数を指定するSIGNED-SHORTで構成されています。このフィールドの値は、「value-length」フィールドの2バイトを除外します。たとえば、「値」フィールドにキーワード（文字列）値「片側」が含まれている場合、このフィールドの値は9です。
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 binary signed bytes, e.g., the boolean type, the sender MUST encode the value in exactly one octet.
バイナリー符号付きバイトで表されるタイプ（ブール型など）の場合、送信者は値を正確に1オクテットにエンコードする必要があります。
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.
文字列で表されるタイプの場合、送信者は文字列のすべての文字を含み、埋め込み文字を含まない値をエンコードする必要があります。
For "out-of-band" values for the "value-tag" field defined in this document, such as 'unsupported', the "value-length" MUST be 0 and the "value" empty; the "value" has no meaning when the "value-tag" has one of these "out-of-band" values. For future "out-of-band" "value-tag" fields, the same rule holds unless the definition explicitly states that the "value-length" MAY be non-zero and the "value" non-empty
このドキュメントで定義されている「値タグ」フィールドの「帯域外」値（「サポートされていない」など）の場合、「値の長さ」は0で、「値」は空でなければなりません。 「value-tag」がこれらの「out-of-band」値の1つを持っている場合、「value」は意味を持ちません。将来の「帯域外」「値タグ」フィールドでは、「値の長さ」がゼロ以外であり、「値」が空ではない可能性があると明確に定義されていない限り、同じルールが適用されます
The syntax types (specified by the "value-tag" field) and most of the details of the representation of attribute values are defined in the Model. Table 7 augments the information in the Model and defines the syntax types from the Model in terms of the five basic types defined in Section 3. The five types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
構文タイプ（「value-tag」フィールドで指定）および属性値の表現の詳細のほとんどは、モデルで定義されています。表7は、モデルの情報を補足し、セクション3で定義された5つの基本タイプに関してモデルの構文タイプを定義します。5つのタイプは、US-ASCII-STRING、LOCALIZED-STRING、SIGNED-INTEGER、SIGNED-SHORT、 SIGNED-BYTE、およびOCTET-STRING。
+----------------------+--------------------------------------------+
| Syntax of Attribute | Encoding |
| Value | |
+----------------------+--------------------------------------------+
| textWithoutLanguage, | LOCALIZED-STRING |
| nameWithoutLanguage | |
+----------------------+--------------------------------------------+
| textWithLanguage | OCTET-STRING consisting of four fields: a |
| | SIGNED-SHORT, which is the number of |
| | octets in the following field; a value of |
| | type natural-language; a SIGNED-SHORT, |
| | which is the number of octets in the |
| | following field; and a value of type |
| | textWithoutLanguage. The length of a |
| | textWithLanguage value MUST be 4 + the |
| | value of field a + the value of field c. |
+----------------------+--------------------------------------------+
| nameWithLanguage | OCTET-STRING consisting of four fields: a |
| | SIGNED-SHORT, which is the number of |
| | octets in the following field; a value of |
| | type natural-language; a SIGNED-SHORT, |
| | which is the number of octets in the |
| | following field; and a value of type |
| | nameWithoutLanguage. The length of a |
| | nameWithLanguage value MUST be 4 + the |
| | value of field a + the value of field c. |
+----------------------+--------------------------------------------+
| charset, | US-ASCII-STRING |
| naturalLanguage, | |
| mimeMediaType, | |
| keyword, uri, and | |
| uriScheme | |
+----------------------+--------------------------------------------+
| boolean | SIGNED-BYTE where 0x00 is 'false' and 0x01 |
| | is 'true' |
+----------------------+--------------------------------------------+
| integer and enum | a SIGNED-INTEGER |
+----------------------+--------------------------------------------+
| dateTime | OCTET-STRING consisting of eleven octets |
| | whose contents are defined by |
| | "DateAndTime" in RFC 2579 [RFC2579] |
+----------------------+--------------------------------------------+
| resolution | OCTET-STRING consisting of nine octets of |
| | two 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. |
+----------------------+--------------------------------------------+
| rangeOfInteger | Eight octets consisting of two SIGNED- |
| | INTEGERs. The first SIGNED-INTEGER |
| | contains the lower bound and the second |
| | SIGNED-INTEGER contains the upper bound. |
+----------------------+--------------------------------------------+
| 1setOf X | Encoding according to the rules for an |
| | attribute with more than one value. Each |
| | value X is encoded according to the rules |
| | for encoding its type. |
+----------------------+--------------------------------------------+
| octetString | OCTET-STRING |
+----------------------+--------------------------------------------+
| collection | Encoding as defined in Section 3.1.6. |
+----------------------+--------------------------------------------+
Table 7: Attribute Value Encoding
表7：属性値のエンコード
The attribute syntax type of the value determines its encoding and the value of its "value-tag".
値の属性構文タイプは、そのエンコーディングとその「値タグ」の値を決定します。
The "data" field MUST include any data required by the operation.
「データ」フィールドには、操作に必要なすべてのデータを含める必要があります。
HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol.
HTTP / 1.1 [RFC7230]は、このプロトコルに必要なトランスポート層です。 HTTP / 2 [RFC7540]は、このプロトコルのオプションのトランスポート層です。
The operation layer has been designed with the assumption that the transport layer contains the following information:
オペレーションレイヤーは、トランスポートレイヤーに次の情報が含まれていることを前提に設計されています。
o the target URI for the operation; and
o 操作のターゲットURI。そして
o 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.
o 操作レイヤー内のデータの全長（単一の長さまたはそれぞれ長さのあるチャンクのシーケンスとして）
Printer implementations MUST support HTTP over the IANA-assigned well-known port 631 (the IPP default port), although a Printer implementation can support HTTP over some other port as well.
プリンターの実装は、IANAが割り当てた既知のポート631（IPPデフォルトポート）を介してHTTPをサポートする必要がありますが、プリンターの実装は他のポートを介してHTTPをサポートすることもできます。
Each HTTP operation MUST use the POST method where the request-target 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 HTTP [RFC7230]. A Printer (server) implementation MUST adhere to the rules for an origin server described for HTTP [RFC7230].
各HTTP操作はPOSTメソッドを使用する必要があります。ここで、request-targetは操作のオブジェクトターゲットであり、各リクエストとレスポンスのメッセージ本文の「Content-Type」は「application / ipp」でなければなりません。メッセージ本文には操作層が含まれている必要があり、また、セクション3.2「エンコーディングの構文」で説明されている構文が必要です。クライアントの実装は、HTTP [RFC7230]について記述されたクライアントのルールに準拠しなければなりません（MUST）。プリンター（サーバー）の実装は、HTTP [RFC7230]について記述されているオリジンサーバーのルールに準拠しなければなりません（MUST）。
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, consult the HTTP documents [RFC7230].
IPPサーバーは、受信した各要求に対して応答を送信します。 IPPサーバーがエラーを検出した場合、要求全体を読み取る前に応答を送信する場合があります。 IPPサーバーのHTTP層がHTTPヘッダーの処理を正常に完了した場合、IPP応答を送信する前に、IPPデータなしで「100続行」などの中間応答を送信する場合があります。クライアントは、IPPサーバーからのこのようなさまざまな応答を期待する必要があります。 HTTPの詳細については、HTTPドキュメント[RFC7230]を参照してください。
An HTTP/1.1 server MUST support chunking for IPP requests, and an IPP Client MUST support chunking for IPP responses according to HTTP/1.1 [RFC7230].
HTTP / 1.1サーバーはIPP要求のチャンクをサポートしなければならず（MUST）、IPPクライアントはHTTP / 1.1 [RFC7230]に従ってIPP応答のチャンクをサポートしなければなりません（MUST）。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC3986] so that they can be persistently and unambiguously referenced. Jobs can also be identified by a combination of Printer URI and Job ID.
すべてのプリンターオブジェクトとジョブオブジェクトは、Uniform Resource Identifier（URI）[RFC3986]によって識別されるため、永続的かつ明確に参照できます。ジョブは、プリンターURIとジョブIDの組み合わせによっても識別できます。
Some operation elements are encoded twice, once as the request-target on the HTTP request-line and a second time as a REQUIRED operation attribute in the application/ipp entity. These attributes are the target for the operation and are called "printer-uri" and "job-uri".
一部の操作要素は2回エンコードされます。1回目はHTTPリクエストラインのrequest-targetとして、もう1回はapplication / ippエンティティのREQUIRED操作属性としてエンコードされます。これらの属性は操作のターゲットであり、「printer-uri」および「job-uri」と呼ばれます。
Note: The target URI is included twice in an operation referencing the same IPP object, but the two URIs can be different. For example, the HTTP request-target can be relative while the IPP request URI is absolute.
注：ターゲットURIは、同じIPPオブジェクトを参照する操作に2回含まれていますが、2つのURIは異なる場合があります。たとえば、IPPリクエストURIが絶対であるのに対し、HTTPリクエストターゲットは相対である場合があります。
HTTP 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 URIs are used in the mapping of IPP onto HTTP:
HTTPを使用すると、クライアントは絶対URIではなく相対URIを生成して送信できます。相対URIは、HTTPサーバーのスコープを持つリソースを識別しますが、スキーム、ホスト、またはポートは含みません。次のステートメントは、HTTPへのIPPのマッピングでURIがどのように使用されるかを示しています。
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 URIs are not used as the addressing mechanism in the transport layer.
1. 冗長である可能性もありますが、クライアントは、操作のターゲットを操作属性とHTTP層のURIの両方として提供する必要があります。この決定の根拠は、URIがトランスポート層のアドレス指定メカニズムとして使用されていない場合でも、 "application / ipp"を多くの通信層にマッピングするための一貫したルールセットを維持することです。
2. Even though these two URIs might not be literally identical (one being relative and the other being absolute), they MUST both reference the same IPP object.
2. これらの2つのURIは文字通り同一ではないかもしれませんが（一方は相対で、もう一方は絶対です）、どちらも同じIPPオブジェクトを参照する必要があります。
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.
3. HTTPレイヤーのURIは相対または絶対のいずれかであり、HTTPサーバーがHTTP要求をそのHTTPサーバーに関連する正しいリソースにルーティングするために使用されます。
4. Once the HTTP server resource begins to process the HTTP request, it can get the reference to the appropriate IPP Printer object from either the HTTP URI (using to the context of the HTTP server for relative URIs) or from the URI within the operation request; the choice is up to the implementation.
4. HTTPサーバーリソースがHTTPリクエストの処理を開始すると、HTTP URI（相対URIのHTTPサーバーのコンテキストを使用）または操作リクエスト内のURIから適切なIPPプリンターオブジェクトへの参照を取得できます。選択は実装次第です。
5. HTTP URIs can be relative or absolute, but the target URI in the IPP operation attribute MUST be an absolute URI.
5. HTTP URIは相対または絶対にできますが、IPP操作属性のターゲットURIは絶対URIでなければなりません。
The IPP URI schemes are 'ipp' [RFC3510] and 'ipps' [RFC7472]. Clients and Printers MUST support the ipp-URI value in the following IPP attributes:
IPP URIスキームは 'ipp' [RFC3510]および 'ipps' [RFC7472]です。クライアントとプリンターは、次のIPP属性のipp-URI値をサポートする必要があります。
o Job attributes:
o ジョブ属性：
* job-uri
* job-uri
* job-printer-uri
* じょｂーｐりんてｒーうり
o Printer attributes:
o プリンター属性：
* printer-uri-supported
* printer-uri-supported
o Operation attributes:
o 操作属性：
* job-uri
* じょbーうり
* printer-uri
* ｐりんてｒーうり
Each of the above attributes identifies a Printer or Job. The ipp-URI and ipps-URI are intended as the value of the attributes in this list. All of these attributes have a syntax type of 'uri', but there are attributes with a syntax type of 'uri' that do not use the 'ipp' scheme, e.g., "job-more-info".
上記の各属性は、プリンターまたはジョブを識別します。 ipp-URIおよびipps-URIは、このリストの属性の値として意図されている。これらのすべての属性の構文タイプは「uri」ですが、「ipp」スキームを使用しない構文タイプ「uri」の属性があります（例：「job-more-info」）。
If a Printer registers its URI with a directory service, the Printer MUST register an ipp-URI or ipps-URI.
プリンターがそのURIをディレクトリサービスに登録する場合、プリンターはipp-URIまたはipps-URIを登録する必要があります。
When a Client sends a request, it MUST convert a target ipp-URI to a target http-URL (or ipps-URI to a target https-URI) for the HTTP layer according to the following steps:
クライアントがリクエストを送信するとき、次の手順に従って、HTTPレイヤーのターゲットipp-URIをターゲットhttp-URL（またはipps-URIからターゲットhttps-URI）に変換する必要があります。
1. change the 'ipp' scheme to 'http' or 'ipps' scheme to 'https'; and
1. 「ipp」スキームを「http」または「ipps」スキームを「https」に変更します。そして
2. add an explicit port 631 if the ipp-URL or ipps-URL does not contain an explicit port. Note that port 631 is the IANA-assigned well-known port for the 'ipp' and 'ipps' schemes.
2. ipp-URLまたはipps-URLに明示的なポートが含まれていない場合は、明示的なポート631を追加します。ポート631は、IANAが割り当てた 'ipp'および 'ipps'スキームの既知のポートであることに注意してください。
The Client MUST use the target http-URL or https-URL in both the HTTP request-line and HTTP headers, as specified by HTTP [RFC7230]. However, the Client MUST use the target ipp-URI or ipps-URI for the value of the "printer-uri" or "job-uri" operation attribute within the application/ipp body of the request. The server MUST use the ipp-URI or ipps-URI for the value of the "printer-uri", "job-uri", or "printer-uri-supported" attributes within the application/ipp body of the response.
クライアントは、HTTP [RFC7230]で指定されているように、HTTPリクエストラインとHTTPヘッダーの両方でターゲットのhttp-URLまたはhttps-URLを使用する必要があります。ただし、クライアントは、リクエストのapplication / ipp本文内の「printer-uri」または「job-uri」操作属性の値に、ターゲットipp-URIまたはipps-URIを使用する必要があります。サーバーは、応答のapplication / ipp本文内の「printer-uri」、「job-uri」、または「printer-uri-supported」属性の値にipp-URIまたはipps-URIを使用する必要があります。
For example, when an IPP Client sends a request directly, i.e., no proxy, to an ipp-URI "ipp://printer.example.com/ipp/print/myqueue", it opens a TCP connection to port 631 (the IPP implicit port) on the host "printer.example.com" and sends the following data:
たとえば、IPPクライアントがipp-URI "ipp：//printer.example.com/ipp/print/myqueue"にリクエストを直接（つまりプロキシなしで）送信すると、ポート631へのTCP接続（ホストの「printer.example.com」上のIPP暗黙ポート）、次のデータを送信します。
POST /ipp/print/myqueue HTTP/1.1 Host: printer.example.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" 'ipp://printer.example.com/ipp/print/myqueue' (encoded in application/ipp message body) ...
POST / ipp / print / myqueue HTTP / 1.1 Host：printer.example.com:631 Content-type：application / ipp Transfer-Encoding：chunked ... "printer-uri" 'ipp：//printer.example.com/ ipp / print / myqueue '（application / ippメッセージ本文にエンコード）...
Figure 11: Direct IPP Request
図11：直接IPP要求
As another example, when an IPP Client sends the same request as above via a proxy "myproxy.example.com", it opens a TCP connection to the proxy port 8080 on the proxy host "myproxy.example.com" and sends the following data:
別の例として、IPPクライアントがプロキシ "myproxy.example.com"を介して上記と同じリクエストを送信すると、プロキシホスト "myproxy.example.com"のプロキシポート8080へのTCP接続が開かれ、以下が送信されます。データ：
POST http://printer.example.com:631/ipp/print/myqueue HTTP/1.1 Host: printer.example.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" 'ipp://printer.example.com/ipp/print/myqueue' (encoded in application/ipp message body) ...
POST http://printer.example.com:631/ipp/print/myqueue HTTP / 1.1 Host：printer.example.com:631 Content-type：application / ipp Transfer-Encoding：chunked ... "printer-uri" 'ipp：//printer.example.com/ipp/print/myqueue'（application / ippメッセージ本文にエンコード）...
Figure 12: Proxied IPP Request
図12：プロキシされたIPPリクエスト
The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above.
次に、プロキシは、上記の「プロキシなし」の例と同じヘッダーを持つIPPオリジンサーバーに接続します。
The IANA-PRINTER-MIB [RFC3805] has been updated to reference this document; the current version is available from <http://www.iana.org>.
IANA-PRINTER-MIB [RFC3805]は、このドキュメントを参照するように更新されました。現在のバージョンは<http://www.iana.org>から入手できます。
See the IANA Considerations in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC8011] for information on IANA considerations for IPP extensions. IANA has updated the existing
IPP拡張機能に関するIANAの考慮事項については、「インターネット印刷プロトコル/1.1：モデルとセマンティクス」[RFC8011]のIANAに関する考慮事項を参照してください。 IANAは既存の
'application/ipp' media type registration (whose contents are defined in Section 3 "Encoding of the Operation Layer") with the following information.
'application / ipp'メディアタイプ登録（内容はセクション3「オペレーションレイヤーのエンコーディング」で定義されています）に以下の情報が含まれています。
Type name: application
タイプ名：アプリケーション
Subtype name: ipp
サブタイプ名：ipp
Required parameters: N/A
必須パラメーター：なし
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: IPP requests/responses MAY contain long lines and ALWAYS contain binary data (for example, attribute value lengths).
エンコードに関する考慮事項：IPP要求/応答には長い行が含まれる場合があり、常にバイナリデータ（たとえば、属性値の長さ）が含まれる場合があります。
Security considerations: IPP requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC8011] as well as protocol-encoding rules in this document are complete and unambiguous. See also the security considerations in this document and [RFC8011].
セキュリティに関する考慮事項：IPP要求/応答は、基礎となるトランスポートプロトコルにまだ固有ではないセキュリティリスクをもたらしません。 [RFC8011]のプロトコル混合バージョンインターワーキングルール、およびこのドキュメントのプロトコルエンコーディングルールは完全で明確です。このドキュメントのセキュリティに関する考慮事項と[RFC8011]も参照してください。
Interoperability considerations: IPP requests (generated by Clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC8011] and this document. Protocol-encoding rules specified in RFC 8010 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 attribute values that are a LOCALIZED-STRING are explicit within IPP requests/responses (without recourse to any external information in HTTP, SMTP, or other message transport headers).
相互運用性に関する考慮事項：IPP要求（クライアントによって生成）および応答（サーバーによって生成）は、規範的仕様[RFC8011]およびこのドキュメントによって課されるすべての適合要件に準拠する必要があります。 RFC 8010で指定されているプロトコルエンコーディングルールは包括的であるため、準拠する実装間の相互運用性が保証されます（ただし、特定のオプション機能のサポートは保証されません）。 LOCALIZED-STRINGであるすべてのIPP属性値の「charset」と「natural-language」は、IPP要求/応答内で明示的です（HTTP、SMTP、またはその他のメッセージトランスポートヘッダーの外部情報に頼ることはありません）。
Published specifications: RFCs 8010 and 8011
公開された仕様：RFC 8010および8011
Applications that use this media type: Internet Printing Protocol (IPP) print clients and print servers that communicate using HTTP/ HTTPS or other transport protocols. Messages of type "application/ ipp" are self-contained and transport independent, including "charset" and "natural-language" context for any LOCALIZED-STRING value.
このメディアタイプを使用するアプリケーション：HTTP / HTTPSまたはその他のトランスポートプロトコルを使用して通信するインターネット印刷プロトコル（IPP）印刷クライアントおよび印刷サーバー。タイプ「application / ipp」のメッセージは自己完結型で、トランスポートに依存しません。LOCALIZED-STRING値の「charset」および「natural-language」コンテキストが含まれます。
Fragment identifier considerations: N/A Additional information:
フラグメント識別子の考慮事項：N / A追加情報：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
ISTO PWG IPP Workgroup <ipp@pwg.org>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: ISTO PWG IPP Workgroup <ipp@pwg.org>
Change controller: ISTO PWG IPP Workgroup <ipp@pwg.org>
Provisional registration? (standards tree only): No
仮登録？ （標準ツリーのみ）：いいえ
See the section on "Internationalization Considerations" in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC8011] for information on internationalization. This document adds no additional issues.
国際化の詳細については、「インターネット印刷プロトコル/1.1：モデルとセマンティクス」[RFC8011]の「国際化に関する考慮事項」のセクションを参照してください。このドキュメントは追加の問題を追加しません。
The IPP Model and Semantics document [RFC8011] discusses high-level security requirements (Client Authentication, Server Authentication, and Operation Privacy). Client Authentication is the mechanism by which the Client proves its identity to the server in a secure manner. Server Authentication is the mechanism by which the server proves its identity to the Client in a secure manner. Operation Privacy is defined as a mechanism for protecting operations from eavesdropping.
IPPモデルとセマンティクスのドキュメント[RFC8011]では、高レベルのセキュリティ要件（クライアント認証、サーバー認証、操作プライバシー）について説明しています。クライアント認証は、クライアントがそのアイデンティティを安全な方法でサーバーに証明するメカニズムです。サーバー認証は、サーバーが安全な方法でクライアントにIDを証明するメカニズムです。操作プライバシーは、操作を盗聴から保護するメカニズムとして定義されています。
Message Integrity is addressed in the document "Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme" [RFC7472].
メッセージの整合性は、ドキュメント「HTTPSトランスポートバインディングを介したインターネット印刷プロトコル（IPP）と「ipps」URIスキーム」[RFC7472]で扱われています。
This section defines the security requirements for IPP Clients and IPP objects.
このセクションでは、IPPクライアントとIPPオブジェクトのセキュリティ要件を定義します。
IPP Clients and Printers SHOULD support Digest Authentication [RFC7616]. Use of the Message Integrity feature (qop="auth-int") is OPTIONAL.
IPPクライアントとプリンターは、ダイジェスト認証[RFC7616]をサポートする必要があります（SHOULD）。メッセージの整合性機能（qop = "auth-int"）の使用はオプションです。
Note: Previous versions of this specification required support for the MD5 algorithms; however, [RFC7616] makes SHA2-256 mandatory to implement and deprecates MD5, only allowing its use for backwards compatibility reasons. IPP implementations that support Digest Authentication MUST support SHA2-256 and SHOULD support MD5 for backwards compatibility.
注：この仕様の以前のバージョンでは、MD5アルゴリズムのサポートが必要でした。ただし、[RFC7616]はSHA2-256を実装してMD5を廃止することを必須にし、下位互換性の理由でのみ使用を許可します。ダイジェスト認証をサポートするIPP実装は、下位互換性のためにSHA2-256をサポートする必要があり、MD5をサポートする必要があります（SHOULD）。
Note: The reason that IPP Clients and Printers SHOULD (rather than MUST) support Digest Authentication is that there is a certain class of Output Devices where it does not make sense. Specifically, a low-end device with limited ROM space and low paper throughput may not need Client Authentication. This class of device typically requires firmware designers to make trade-offs between protocols and functionality to arrive at the lowest-cost solution possible. Factored into the designer's decisions is not just the size of the code, but also the testing, maintenance, usefulness, and time-to-market impact for each feature delivered to the customer. Forcing such low-end devices to provide security in order to claim IPP/1.1 conformance would not make business sense. Print devices that have high-volume throughput and have available ROM space will typically provide support for Client Authentication that safeguards the device from unauthorized access because these devices are prone to a high loss of consumables and paper if unauthorized access occurs.
注：IPPクライアントとプリンターがダイジェスト認証をサポートする必要があるのは（必須ではなく）SHOULDである理由は、意味のない特定のクラスの出力デバイスがあるためです。具体的には、ROMスペースが限られていて紙のスループットが低いローエンドデバイスでは、クライアント認証が不要な場合があります。このクラスのデバイスでは、通常、可能な限り最も低コストのソリューションを実現するために、ファームウェア設計者がプロトコルと機能のトレードオフを行う必要があります。設計者の決定には、コードのサイズだけでなく、テスト、メンテナンス、有用性、および顧客に提供される各機能の市場投入までの影響も含まれます。そのようなローエンドデバイスにIPP / 1.1への準拠を主張するためのセキュリティを強制することは、ビジネス上意味がありません。大量のスループットがあり、ROMスペースが利用可能な印刷デバイスは、通常、クライアント認証をサポートします。これにより、不正なアクセスが発生した場合、これらのデバイスは消耗品や紙を大量に失う傾向があるため、不正なアクセスからデバイスを保護します。
IPP Clients and Printers SHOULD support Transport Layer Security (TLS) [RFC5246] [RFC7525] for Server Authentication and Operation Privacy. IPP Printers MAY also support TLS for Client Authentication. IPP Clients and Printers MAY support Basic Authentication [RFC7617] for User Authentication if the channel is secure, e.g., IPP over HTTPS [RFC7472]. IPP Clients and Printers SHOULD NOT support Basic Authentication over insecure channels.
IPPクライアントとプリンターは、サーバー認証と操作プライバシーのためにトランスポート層セキュリティ（TLS）[RFC5246] [RFC7525]をサポートする必要があります（SHOULD）。 IPPプリンターは、クライアント認証のためにTLSもサポートする場合があります。 IPPクライアントとプリンターは、チャネルがセキュアな場合、ユーザー認証のために基本認証[RFC7617]をサポートする場合があります（IPP over HTTPS [RFC7472]など）。 IPPクライアントとプリンターは、安全でないチャネルでの基本認証をサポートしてはなりません（SHOULD NOT）。
The IPP Model and Semantics document [RFC8011] defines two Printer attributes ("uri-authentication-supported" and "uri-security-supported") that the Client can use to discover the security policy of a Printer. That document also outlines IPP-specific security considerations and is the primary reference for security implications with regard to the IPP itself.
IPPモデルとセマンティクスのドキュメント[RFC8011]は、クライアントがプリンターのセキュリティポリシーを検出するために使用できる2つのプリンター属性（「uri-authentication-supported」と「uri-security-supported」）を定義しています。このドキュメントは、IPP固有のセキュリティに関する考慮事項の概要も示しており、IPP自体に関するセキュリティへの影響の主要なリファレンスです。
Note: Because previous versions of this specification did not require TLS support, this version cannot require it for IPP/1.1. However, since printing often involves a great deal of sensitive or private information (medical reports, performance reviews, banking information, etc.) and network monitoring is pervasive ([RFC7258]), implementors are strongly encouraged to include TLS support.
注：この仕様の以前のバージョンはTLSサポートを必要としなかったため、このバージョンはIPP / 1.1でTLSサポートを必要としません。ただし、印刷には多くの機密情報や個人情報（医療レポート、パフォーマンスレビュー、銀行情報など）が含まれることが多く、ネットワークモニタリングが普及しているため（[RFC7258]）、実装者はTLSサポートを含めることを強くお勧めします。
Note: Because IPP Printers typically use self-signed X.509 certificates, IPP Clients SHOULD support Trust On First Use (defined in [RFC7435]) in addition to traditional X.509 certificate validation.
注：IPPプリンターは通常、自己署名X.509証明書を使用するため、IPPクライアントは、従来のX.509証明書の検証に加えて、（[RFC7435]で定義されている）初回使用時信頼をサポートする必要があります（SHOULD）。
IPP uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817] for 'ipp' URIs. The Client requests a secure TLS connection by using the HTTP "Upgrade" header while the server agrees in the HTTP response. The switch to TLS occurs either because the server grants the Client's request to upgrade to TLS or a server asks to switch to TLS in its response. Secure communication begins with a server's response to switch to TLS.
IPPは、「ipp」URIに対して「HTTP / 1.1内のTLSへのアップグレード」メカニズム[RFC2817]を使用します。サーバーがHTTP応答に同意する間、クライアントはHTTP "Upgrade"ヘッダーを使用して安全なTLS接続を要求します。 TLSへの切り替えは、サーバーがクライアントのTLSへのアップグレード要求を許可するか、サーバーが応答でTLSへの切り替えを要求するために発生します。安全な通信は、TLSに切り替えるサーバーの応答から始まります。
IPP uses the "HTTPS: HTTP over TLS" mechanism [RFC2818] for 'ipps' URIs. The Client and server negotiate a secure TLS connection immediately and unconditionally.
IPPは「ipps」URIに「HTTPS：HTTP over TLS」メカニズム[RFC2818]を使用します。クライアントとサーバーは、安全なTLS接続を即座に無条件にネゴシエートします。
It is beyond the scope of this specification to mandate conformance with versions of IPP other than 1.1. IPP was deliberately designed, however, to make supporting other versions easy. IPP objects (Printers, Jobs, etc.) SHOULD:
1.1以外のバージョンのIPPへの準拠を義務付けることは、この仕様の範囲外です。ただし、IPPは他のバージョンのサポートを容易にするために意図的に設計されました。 IPPオブジェクト（プリンター、ジョブなど）は、
o understand any valid request whose major "version-number" is greater than 0; and
o メジャーな「バージョン番号」が0より大きい有効なリクエストを理解します。そして
o respond appropriately with a response containing the same "version-number" parameter value used by the Client in the request (if the Client-supplied "version-number" is supported) or the highest "version-number" supported by the Printer (if the Client-supplied "version-number" is not supported).
o リクエストでクライアントが使用する同じ「バージョン番号」パラメーター値を含む応答で適切に応答します（クライアント提供の「バージョン番号」がサポートされている場合）、またはプリンターでサポートされている最も高い「バージョン番号」（クライアント提供の「バージョン番号」はサポートされていません）。
IPP Clients SHOULD:
IPPクライアントは：
o understand any valid response whose major "version-number" is greater than 0.
o メジャーな「バージョン番号」が0より大きい有効な応答を理解します。
The following are rules regarding the "version-number" parameter (see Section 3.3):
以下は、「バージョン番号」パラメーターに関するルールです（セクション3.3を参照）。
1. Clients MUST send requests containing a "version-number" parameter with the highest supported value, e.g., '1.1', '2.0', etc., and SHOULD try supplying alternate version numbers if they receive a 'server-error-version-not-supported' error return in a response. For example, if a Client sends an IPP/2.0 request that is rejected with the 'server-error-version-not-supported' error and an IPP/1.1 "version-number", it SHOULD retry by sending an IPP/1.1 request.
1. クライアントは、サポートされている最も高い値（「1.1」、「2.0」など）を含む「バージョン番号」パラメーターを含むリクエストを送信する必要があり、「server-error-version-not」を受け取った場合は代替バージョン番号の提供を試みる必要があります。 -supported 'エラーが応答で返されます。たとえば、クライアントが「server-error-version-not-supported」エラーとIPP / 1.1「バージョン番号」エラーで拒否されたIPP / 2.0要求を送信した場合、IPP / 1.1要求を送信して再試行する必要があります（SHOULD） 。
2. IPP objects (Printers, Jobs, etc.) MUST accept requests containing a "version-number" parameter with a '1.1' value (or reject the request for reasons other than 'server-error-version-not-supported').
2. IPPオブジェクト（プリンター、ジョブなど）は、「バージョン番号」パラメーターに「1.1」の値を含む要求を受け入れる必要があります（または「サーバーエラーバージョン非サポート」以外の理由で要求を拒否する必要があります）。
3. IPP objects SHOULD either accept requests whose major version is greater than 0 or reject such requests with the 'server-error-version-not-supported' status-code. See Section 4.1.8 of [RFC8011].
3. IPPオブジェクトは、メジャーバージョンが0より大きいリクエストを受け入れるか、「server-error-version-not-supported」ステータスコードでそのようなリクエストを拒否する必要があります（SHOULD）。 [RFC8011]のセクション4.1.8をご覧ください。
4. In any case, security MUST NOT be compromised when a Client supplies a lower "version-number" parameter in a request. For example, if an IPP/2.0 conforming Printer accepts version '1.1' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.1' request.
4. いずれにせよ、クライアントがリクエストでより低い「バージョン番号」パラメータを提供する場合、セキュリティが損なわれてはいけません。たとえば、IPP / 2.0準拠のプリンターがバージョン '1.1'要求を受け入れ、ダイジェスト認証を強制するように構成されている場合、バージョン '1.1'要求に対しても同じことを行わなければなりません（MUST）。
The following are rules regarding security, the "version-number" parameter, and the URI scheme supplied in target attributes and responses:
以下は、セキュリティ、「バージョン番号」パラメーター、およびターゲットの属性と応答で提供されるURIスキームに関するルールです。
1. When a Client supplies a request, the "printer-uri" or "job-uri" target operation attribute MUST have the same scheme as that indicated in one of the values of the "printer-uri-supported" Printer attribute.
1. クライアントがリクエストを提供するとき、「printer-uri」または「job-uri」ターゲット操作属性は、「printer-uri-supported」プリンター属性の値のいずれかで示されているものと同じスキームを持つ必要があります。
2. When the Printer returns the "job-printer-uri" or "job-uri" Job Description attributes, it SHOULD return the same scheme ('ipp', 'ipps', etc.) that the Client supplied in the "printer-uri" or "job-uri" target operation attributes in the Get-Job-Attributes or Get-Jobs request, rather than the scheme used when the Job was created. However, when a Client requests Job attributes using the Get-Job-Attributes or Get-Jobs operations, the Jobs and Job attributes that the Printer returns depends on: (1) the security in effect when the Job was created, (2) the security in effect in the query request, and (3) the security policy in force.
2.プリンターが「job-printer-uri」または「job-uri」のジョブの説明属性を返す場合、クライアントが「プリンター」で提供したのと同じスキーム（「ipp」、「ipps」など）を返す必要があります。ジョブの作成時に使用されたスキームではなく、Get-Job-AttributesまたはGet-Jobsリクエスト内の-uri "または" job-uri "ターゲット操作属性。ただし、クライアントがGet-Job-AttributesまたはGet-Jobsオペレーションを使用してジョブ属性をリクエストする場合、プリンターが返すジョブおよびジョブ属性は、（1）ジョブが作成されたときに有効なセキュリティ、（2）クエリ要求で有効なセキュリティ、および（3）有効なセキュリティポリシー。
3. The Printer MUST enforce its security and privacy policies based on the owner of the IPP object and the URI scheme and/or credentials supplied by the Client in the current request.
3. プリンターは、IPPオブジェクトの所有者と、現在のリクエストでクライアントによって提供されたURIスキームおよび/または資格情報に基づいて、セキュリティとプライバシーポリシーを実施する必要があります。
The following changes have been made since the publication of RFC 2910:
RFC 2910の公開以降、次の変更が行われました。
o Added references to current IPP extension specifications.
o 現在のIPP拡張仕様への参照を追加しました。
o Added optional support for HTTP/2.
o HTTP / 2のオプションのサポートを追加しました。
o Added collection attribute syntax from RFC 3382.
o RFC 3382からコレクション属性構文を追加しました。
o Fixed typographical errors.
o 誤植を修正しました。
o Now reference TLS/1.2 and no longer mandate the TLS/1.0 MTI ciphersuites.
o 現在はTLS / 1.2を参照し、TLS / 1.0 MTI暗号スイートを強制しなくなりました。
o Updated all references.
o すべての参照を更新しました。
o Updated document organization to follow current style.
o 現在のスタイルに従うようにドキュメントの構成を更新。
o Updated example ipp: URIs to follow guidelines in RFC 7472.
o RFC 7472のガイドラインに従うようにサンプルipp：URIを更新しました。
o Updated version compatibility for all versions of IPP.
o IPPのすべてのバージョンのバージョン互換性を更新しました。
o Updated HTTP Digest Authentication to optional for Clients.
o クライアントのHTTPダイジェスト認証をオプションに更新しました。
o Removed references to (Experimental) IPP/1.0 and usage of http:/https: URLs.
o （実験的）IPP / 1.0への参照とhttp：/ https：URLの使用を削除しました。
[PWG5100.12] Sweet, M. and I. McDonald, "IPP Version 2.0, 2.1, and 2.2", October 2015, <http://ftp.pwg.org/pub/pwg/standards/ std-ipp20-20151030-5100.12.pdf>.
[PWG5100.12] Sweet、M。およびI. McDonald、「IPPバージョン2.0、2.1、および2.2」、2015年10月、<http://ftp.pwg.org/pub/pwg/standards/ std-ipp20-20151030 -5100.12.pdf>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <http://www.rfc-editor.org/info/rfc2579>.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、DOI 10.17487 / RFC2579、April 1999、<http ：//www.rfc-editor.org/info/rfc2579>。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, <http://www.rfc-editor.org/info/rfc2817>.
[RFC2817] Khare、R。およびS. Lawrence、「HTTP / 1.1内のTLSへのアップグレード」、RFC 2817、DOI 10.17487 / RFC2817、2000年5月、<http://www.rfc-editor.org/info/rfc2817> 。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>.
[RFC2978] Freed、N。およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2978、DOI 10.17487 / RFC2978、2000年10月、<http://www.rfc-editor.org/info/rfc2978> 。
[RFC3510] Herriot, R. and I. McDonald, "Internet Printing Protocol/1.1: IPP URL Scheme", RFC 3510, DOI 10.17487/RFC3510, April 2003, <http://www.rfc-editor.org/info/rfc3510>.
[RFC3510] Herriot、R。およびI. McDonald、「Internet Printing Protocol / 1.1：IPP URL Scheme」、RFC 3510、DOI 10.17487 / RFC3510、2003年4月、<http://www.rfc-editor.org/info/ rfc3510>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<http://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme", RFC 7472, DOI 10.17487/RFC7472, March 2015, <http://www.rfc-editor.org/info/rfc7472>.
[RFC7472]マクドナルド、I。およびM.スウィート、「HTTPSトランスポートバインディングを介したインターネット印刷プロトコル（IPP）および「ipps」URIスキーム」、RFC 7472、DOI 10.17487 / RFC7472、2015年3月、<http：// www。 rfc-editor.org/info/rfc7472>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<http：// www.rfc-editor.org/info/rfc7540>。
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <http://www.rfc-editor.org/info/rfc7541>.
[RFC7541] Peon、R。およびH. Ruellan、「HPACK：HTTP / 2のヘッダー圧縮」、RFC 7541、DOI 10.17487 / RFC7541、2015年5月、<http://www.rfc-editor.org/info/rfc7541 >。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D。、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<http：//www.rfc- editor.org/info/rfc7616>。
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.
[RFC7617] Reschke、J。、「The 'Basic' HTTP Authentication Scheme」、RFC 7617、DOI 10.17487 / RFC7617、2015年9月、<http://www.rfc-editor.org/info/rfc7617>。
[RFC8011] Sweet, M. and I. McDonald, "Internet Printing Protocol/1.1: Model and Semantics", RFC 8011, DOI 10.17487/RFC8011, January 2017, <http://www.rfc-editor.org/info/rfc8011>.
[RFC8011] Sweet、M。およびI. McDonald、「Internet Printing Protocol / 1.1：Model and Semantics」、RFC 8011、DOI 10.17487 / RFC8011、2017年1月、<http://www.rfc-editor.org/info/ rfc8011>。
[IANA-IPP] IANA, "Internet Printing Protocol (IPP) Registry", <http://www.iana.org/assignments/ipp-registrations/>.
[IANA-IPP] IANA、「インターネット印刷プロトコル（IPP）レジストリ」、<http://www.iana.org/assignments/ipp-registrations/>。
[PWG5100.3] Ocke, K. and T. Hastings, "Internet Printing Protocol (IPP): Production Printing Attributes - Set1", Candidate Standard 5100.3-2001, February 2001, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippprodprint10-20010212-5100.3.pdf>.
[PWG5100.3] Ocke、K。およびT. Hastings、「インターネット印刷プロトコル（IPP）：Production Printing Attributes-Set1」、Candidate Standard 5100.3-2001、2001年2月、<http://ftp.pwg.org/pub /pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf>。
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, DOI 10.17487/RFC1179, August 1990, <http://www.rfc-editor.org/info/rfc1179>.
[RFC1179]マクラフリン、L。、「ラインプリンターデーモンプロトコル」、RFC 1179、DOI 10.17487 / RFC1179、1990年8月、<http://www.rfc-editor.org/info/rfc1179>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
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 is not supported or their values are not supported.
以下は、「job-name」、「copies」、および「sides」が指定されたPrint-Jobリクエストの例です。 「ipp-attribute-fidelity」属性は「true」に設定されているため、「copies」または「sides」属性がサポートされていないか、それらの値がサポートされていない場合、印刷要求は失敗します。
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x0002 Print-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x42 nameWithoutLanguage value-tag type 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x22 boolean type value-tag 0x0016 name-length ipp-attribute-fidelity ipp-attribute- name fidelity 0x0001 value-length 0x01 true value 0x02 start job-attributes job-attributes-
0x0101 1.1バージョン番号0x0002 Print-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf- 8 UTF-8値0x48自然言語値タグタイプ0x001b名前長属性-自然言語属性-自然名言語0x0005値長en-us en-US値0x45 uriタイプ値タグ0x000b名前長プリンター-uri printer-uri name 0x002c value-length ipp：//printer.example.com/ipp/ printer pinetree value print / pinetree 0x42 nameWithoutLanguage value-tag type 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x22 boolean type value-tag 0x0016 name-length ipp-attribute-fidelity ipp-attribute- name fidelity 0x0001 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-long-edge two-sided-long-edge value 0x03 end-of-attributes end-of-attributes-tag %!PDF... <PDF Document> data
タグ0x21整数型value-tag 0x0006名前長コピーコピー名0x0004値長0x00000014 20値0x44キーワードタイプ値タグ0x0005名前長サイド名0x0013値長両面ロングエッジ両面ロング-edge value 0x03 end-of-attributes end-of-attributes-tag％！PDF ... <PDFドキュメント>データ
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'.
以下は、前のPrint-Jobリクエストに対する成功したPrint-Jobレスポンスの例です。プリンターは、「コピー」および「サイド」属性とそれらの提供された値をサポートしていました。返されるステータスコードは「成功」です。
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x0000 successful-ok status-code 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes- name natural-language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguag value-tag e type 0x000e name-length status-message status-message name 0x000d value-length successful-ok successful-ok value 0x02 start job- job-attributes-
0x0101 1.1バージョン番号0x0000成功-okステータスコード0x00000001 1リクエストID 0x01開始操作-操作属性属性タグ0x47文字セットタイプ値タグ0x0012名前の長さ属性-文字セット属性-文字セット名0x0005値-長さutf- 8 UTF-8値0x48自然言語値タグタイプ0x001b名前長属性-自然言語属性-名前自然言語0x0005値長さen-us en-US値0x41 textWithoutLanguag値タグeタイプ0x000e名前長さstatus-message status-message name 0x000d value-length successful-ok successful-ok value 0x02 start job- job-attributes-
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 0x0030 value-length ipp://printer.example.com/ipp/pr job 147 on value int/pinetree/147 pinetree 0x23 enum 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
属性タグ0x21整数値タグ0x0006名前長ジョブIDジョブID名前0x0004値長147147値0x45 URIタイプ値タグ0x0007名前長ジョブURIジョブURI名前0x0030値長ipp：// printer.example.com/ipp/pr job 147 on value int / pinetree / 147 pinetree 0x23 enum 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).
これは、前のPrint-Job要求に対する失敗したPrint-Job応答の例です。この場合、プリンターは「sides」属性をサポートしておらず、「copies」属性の値「20」がサポートされていないため、失敗します。したがって、ジョブは作成されず、「job-id」も「job-uri」操作属性も返されません。返されるエラーコードは「client-error-attributes-or-values-not-supported」（0x040b）です。
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x040b client-error-attributes-or- status-code values-not-supported 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length attributes-natural-language attributes-natural-language name 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000e name-length status-message status-message name 0x002f value-length client-error-attributes-or- client-error-attributes-or- value values-not-supported values-not-supported 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 0x03 end-of-attributes end-of-attributes-tag
0x0101 1.1 version-number 0x040b client-error-attributes-or- status-code values-not-supported 0x00000001 1 request-id 0x01 start operation-attributes operation-attributes tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes -charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length attributes-natural-language attributes-natural-language name 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage type value-tag 0x000e name-length status-message status-message name 0x002f value-length client-error-attributes-or- client-error-attributes-or- value values-not-supported values-not-supported 0x05 start unsupported- unsupported-attributes属性タグ0x21整数型value-tag 0x0006名前の長さのコピーコピーname 0x0004 value-length 0x00000014 20値0x10サポートされていない（type）value-tag 0x0005名前の長さの側面side名前0x0000値の長さ0x03属性の終わり属性終了タグ
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).
次の例は、前のPrint-Jobリクエストと同様に、Print-Jobリクエストに対する正常なPrint-Jobレスポンスの例です。ただし、「ipp-attribute-fidelity」の値は「false」です。この場合、プリンターは「sides」属性も「copies」属性の値「20」もサポートしていませんが、印刷要求は成功します。したがって、ジョブが作成され、「job-id」と「job-uri」の両方の操作属性が返されます。サポートされていない属性も、サポートされていない属性グループに返されます。返されるエラーコードは、「成功-OK-無視-または置換-属性」（0x0001）です。
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 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-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length attributes-natural- attributes-natural-language name 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-ignored-or- successful-ok-ignored-or- value 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 0x0030 value-length ipp://printer.example.com/ job 147 on pinetree value ipp/print/pinetree/147 0x23 enum 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
0x0101 1.1バージョン番号0x0001成功-無視-または-ステータスコード置換属性0x00000001 1要求ID 0x01開始操作-属性操作-属性-タグ0x47文字セットタイプ値-タグ0x0012名前-長さ-属性-文字セット-属性charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length attributes-natural- attributes-natural-language name 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-ignored-or- successful-ok-ignored-or-value代入された属性代入された属性0x05開始サポートされない-サポートされていない属性属性タグ0x21整数型値タグ0x0006名前長コピーコピー名0x0004値長0x00000014 20値0x10サポートされていない（タイプ）値タグ0x0005名前長サイドサイド名0x0000値長0x02ジョブ属性の開始ジョブ属性タグ0x21整数値-t ag 0x0006 name-length job-id job-id name 0x0004 value-length 147147 value 0x45 uri type value-tag 0x0007 name-length job-uri job-uri name 0x0030 value-length ipp：//printer.example.com/ pinetreeのジョブ147の値ipp / print / pinetree / 147 0x23 enum 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:
以下は、 "copies"および "job-name"パラメータを指定したPrint-URIリクエストの例です。
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x0003 Print-URI operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x45 uri type value-tag 0x000c name-length document-uri document-uri name 0x0019 value-length ftp://foo.example.com/foo ftp://foo.example.co value m/foo 0x42 nameWithoutLanguage value-tag type 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
0x0101 1.1バージョン番号0x0003 Print-URI operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf- 8 UTF-8値0x48自然言語値タグタイプ0x001b名前長属性-自然言語属性-自然名言語0x0005値長en-us en-US値0x45 uriタイプ値タグ0x000b名前長プリンター-uri printer-uri name 0x002c value-length ipp：//printer.example.com/ipp/ printer pinetree value print / pinetree 0x45 uri type value-tag 0x000c name-length document-uri document-uri name 0x0019 value-length ftp ：//foo.example.com/foo ftp://foo.example.co value m / foo 0x42 nameWithoutLanguage value-tag type 0x0008 name-length job-name job-name name 0x0006 value-length foobar foobar value 0x02 start job -attributes job-attributes-tag 0x21整数型value-tag 0x0006名前の長さのコピー名前0x0004値の長さ0x00000001 1値0x03属性の終わり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
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x03 end-of-attributes end-of-attributes-tag
0x0101 1.1 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf- 8 UTF-8値0x48自然言語値タグタイプ0x001b名前長属性-自然言語属性-自然名言語0x0005値長en-us en-US値0x45 uriタイプ値タグ0x000b名前長プリンター-uri printer-uri name 0x002c value-length ipp：//printer.example.com/ipp/ printer pinetree value print / pinetree 0x03 end-of-attributes end-of-attributes-tag
The following is an example of Create-Job request with the "media-col" collection attribute [PWG5100.3] with the value "media-size={x-dimension=21000 y-dimension=29700} media-type='stationery'":
以下は、「media-col」コレクション属性[PWG5100.3]と値「media-size = {x-dimension = 21000 y-dimension = 29700} media-type = 'stationery」を指定したCreate-Jobリクエストの例です。 '"：
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/pinetree 0x34 begCollection value-tag 0x0009 9 name-length media-col media-col name 0x0000 0 value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000a 10 value-length media-size media-size value (member-name) 0x34 begCollection member-value-tag 0x0000 0 name-length 0x0000 0 member-value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000b 11 value-length x-dimension x-dimension value (member-name) 0x21 integer member-value-tag 0x0000 0 name-length 0x0004 4 member-value-length 0x00005208 21000 member-value 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000b 11 value-length y-dimension y-dimension value (member-name)
0x0101 1.1 version-number 0x0005 Create-Job operation-id 0x00000001 1 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf- 8 UTF-8値0x48自然言語値タグタイプ0x001b名前長属性-自然言語属性-自然名言語0x0005値長en-us en-US値0x45 uriタイプ値タグ0x000b名前長プリンター-uri printer-uri name 0x002c value-length ipp：//printer.example.com/ipp/ printer pinetree value print / pinetree 0x34 begCollection value-tag 0x0009 9 name-length media-col media-col name 0x0000 0 value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000a 10 value-length media-size media-size value（member-name）0x34 begCollection member-value-tag 0x0000 0 name-length 0x0000 0 member-value-length 0x4a memberAttrName value-タグ0x0000 0 name-length 0x000b 11 value-length x-dimension x-dimension value（member-name） 0x21 integer member-value-tag 0x0000 0 name-length 0x0004 4 member-value-length 0x00005208 21000 member-value 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000b 11 value-length y-dimension y-dimension value（member-name ）
0x21 integer member-value-tag 0x0000 0 name-length 0x0004 4 member-value-length 0x00007404 29700 member-value 0x37 endCollection end-value-tag 0x0000 0 end-name-length 0x0000 0 end-value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000a 10 value-length media-type media-type value (member-name) 0x44 keyword member-value-tag 0x0000 0 name-length 0x000a 10 member-value-length stationery stationery member-value 0x37 endCollection end-value-tag 0x0000 0 end-name-length 0x0000 0 end-value-length 0x03 end-of-attributes end-of-attributes-tag
0x21 integer member-value-tag 0x0000 0 name-length 0x0004 4 member-value-length 0x00007404 29700 member-value 0x37 endCollection end-value-tag 0x0000 0 end-name-length 0x0000 0 end-value-length 0x4a memberAttrName value-tag 0x0000 0 name-length 0x000a 10 value-length media-type media-type value（member-name）0x44 keyword member-value-tag 0x0000 0 name-length 0x000a 10 member-value-length stationery stationery member-value 0x37 endCollection end- value-tag 0x0000 0 end-name-length 0x0000 0 end-value-length 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
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x000a Get-Jobs operation-id 0x0000007b 123 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language value-tag type 0x001b name-length attributes-natural-language attributes-natural- name language 0x0005 value-length en-us en-US value 0x45 uri type value-tag 0x000b name-length printer-uri printer-uri name 0x002c value-length ipp://printer.example.com/ipp/ printer pinetree value print/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-attributes requested-attributes name 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
0x0101 1.1バージョン番号0x000a Get-Jobs operation-id 0x0000007b 123 request-id 0x01 start operation- operation-attributes attributes-tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf- 8 UTF-8値0x48自然言語値タグタイプ0x001b名前長属性-自然言語属性-自然名言語0x0005値長en-us en-US値0x45 uriタイプ値タグ0x000b名前長プリンター-uri printer-uri name 0x002c value-length ipp：//printer.example.com/ipp/ printer pinetree value print / pinetree 0x21 integer type value-tag 0x0005 name-length limit limit name 0x0004 value-length 0x00000032 50 value 0x44 keywordタイプ値タグ0x0014名前の長さ要求された属性要求された属性名0x0006値の長さジョブIDジョブID値0x44キーワードタイプ値タグ0x0000追加の値名前の長さ0x0008値長ジョブ名ジョブ名値0x44キーワードタイプ値タグ0x0000追加値名前長さ0x000f value-length document-format document-format value 0x03 end-of-attributes end-of-attributes-tag
The following is an example of a Get-Jobs response from a previous request with three Jobs. The Printer returns no information about the second Job (because of security reasons):
以下は、3つのジョブを含む前の要求からのGet-Jobs応答の例です。プリンターは2番目のジョブに関する情報を返しません（セキュリティ上の理由により）。
Octets Symbolic Value Protocol field
Octets Symbolic Value Protocolフィールド
0x0101 1.1 version-number 0x0000 successful-ok status-code 0x0000007b 123 request-id (echoed back) 0x01 start operation- operation-attributes-attributes tag 0x47 charset type value-tag 0x0012 name-length attributes-charset attributes-charset name 0x0005 value-length utf-8 UTF-8 value 0x48 natural-language type value-tag 0x001b name-length attributes-natural- attributes-natural- name language language 0x0005 value-length en-us en-US value 0x41 textWithoutLanguage value-tag type 0x000e name-length status-message status-message name 0x000d value-length successful-ok successful-ok value 0x02 start job-attributes job-attributes-tag (1st 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 job-attributes-tag (2nd object) 0x02 start job-attributes job-attributes-tag (3rd object) 0x21 integer type value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 148 149 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
0x0101 1.1バージョン番号0x0000成功-okステータスコード0x0000007b 123リクエストID（エコーバック）0x01開始操作-操作属性-属性タグ0x47文字セットタイプ値-タグ0x0012名前長属性-文字セット属性-文字セット名0x0005値-length utf-8 UTF-8値0x48自然言語タイプ値タグ0x001b名前長属性-自然-属性-自然-名前言語言語0x0005値-長さen-us en-US値0x41 textWithoutLanguage値タグタイプ0x000e name-length status-message status-message name 0x000d value-length successful-ok successful-ok value 0x02 start job-attributes job-attributes-tag（1st 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名前0x02ジョブ属性の開始ジョブ属性タグ（2番目のオブジェクト）0x02ジョブ属性の開始utes job-attributes-tag（3番目のオブジェクト）0x21整数型value-tag 0x0006 name-length job-id job-id name 0x0004 value-length 148149 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
Acknowledgements
謝辞
The authors would like to acknowledge the following individuals for their contributions to the original IPP/1.1 specifications:
著者は、元のIPP / 1.1仕様への貢献に対して以下の個人に感謝します。
Sylvan Butler, Roger deBry, Tom Hastings, Robert Herriot (the original editor of RFC 2910), Paul Moore, Kirk Ocke, Randy Turner, John Wenn, and Peter Zehler.
Sylvan Butler、Roger deBry、Tom Hastings、Robert Herriot（RFC 2910の最初の編集者）、Paul Moore、Kirk Ocke、Randy Turner、John Wenn、およびPeter Zehler。
Authors' Addresses
著者のアドレス
Michael Sweet Apple Inc. 1 Infinite Loop MS 111-HOMC Cupertino, CA 95014 United States of America
Michael Sweet Apple Inc. 1 Infinite Loop MS 111-HOMC Cupertino、CA 95014アメリカ合衆国
Email: msweet@apple.com
Ira McDonald High North, Inc. PO Box 221 Grand Marais, MI 49839 United States of America
Ira McDonald High North、Inc. PO Box 221 Grand Marais、MI 49839アメリカ合衆国
Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com