[要約] RFC 2910は、インターネット印刷プロトコル（IPP）のエンコーディングとトランスポートに関する仕様です。このRFCの目的は、IPPのデータのエンコードとネットワークトランスポートの方法を定義し、異なるプラットフォーム間での印刷データの交換を可能にすることです。
Network Working Group R. Herriot, Editor
Request for Comments: 2910 Xerox Corporation
Obsoletes: 2565 S. Butler
Category: Standards Track Hewlett-Packard
P. Moore
Peerless Systems Networking
R. Turner
2wire.com
J. Wenn
Xerox Corporation
September 2000
Internet Printing Protocol/1.1: Encoding and Transport
インターネット印刷プロトコル/1.1：エンコーディングとトランスポート
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over Hypertext Transfer Protocol (HTTP) a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
このドキュメントは一連のドキュメントの1つであり、新しいインターネット印刷プロトコル（IPP）のすべての側面を一緒に説明しています。IPPは、インターネットツールとテクノロジーを使用した分散印刷に使用できるアプリケーションレベルのプロトコルです。このドキュメントでは、IPP操作とIPP属性を「Application/IPP」と呼ばれる新しいインターネットMIMEメディアタイプにエンコードするためのルールを定義しています。このドキュメントでは、コンテンツタイプが「アプリケーション/IPP」であるメッセージ本文を超テキスト転送プロトコル（HTTP）を輸送するためのルールも定義しています。このドキュメントでは、IPPプリンターとジョブを識別するための「IPP」という名前の新しいスキームを定義しています。
The full set of IPP documents includes:
IPPドキュメントの完全なセットには以下が含まれます。
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport (this
document)
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.1. A few OPTIONAL operator operations have been added to IPP/1.1.
ドキュメント「インターネット印刷プロトコルの設計目標」は、分散した印刷機能を幅広く見ています。また、インターネットの印刷プロトコルに含める必要がある機能を明確にするのに役立つ実生活のシナリオを列挙します。エンドユーザー、オペレーター、および管理者の3種類のユーザーの要件を特定します。IPP/1.1で満たされているエンドユーザー要件のサブセットを呼び出します。IPP/1.1にいくつかのオプションのオペレーター操作が追加されています。
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
ドキュメント「インターネット印刷プロトコルの構造とモデルおよびプロトコルの根拠」は、高レベルのビューからのIPPを説明し、IPP仕様ドキュメントのスイートを形成するさまざまなドキュメントのロードマップを定義し、IETFワーキンググループの主要な決定。
The document, "Internet Printing Protocol/1.1: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
ドキュメント「インターネット印刷プロトコル/1.1：モデルとセマンティクス」は、抽象的なオブジェクト、その属性、およびエンコードと輸送に依存しない操作を備えた単純化されたモデルを説明しています。プリンターとジョブオブジェクトを紹介します。ジョブオブジェクトは、オプションでジョブごとの複数のドキュメントをサポートします。また、セキュリティ、国際化、およびディレクトリの問題にも対処します。
The document "Internet Printing Protocol/1.1: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
ドキュメント「インターネット印刷プロトコル/1.1：実装者ガイド」は、IPPクライアントとIPPオブジェクトの実装者にアドバイスを提供します。
The document "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
ドキュメント「LPDとIPPプロトコル間のマッピング」は、IPPとLPD（Line Printer Daemon）の実装の間のゲートウェイの実装者にアドバイスを提供します。
Table of Contents
目次
1. Introduction ...................................................4
2. Conformance Terminology ........................................4
3. Encoding of the Operation Layer ...............................4
3.1 Picture of the Encoding ...................................6
3.1.1 Request and Response...................................6
3.1.2 Attribute Group........................................6
3.1.3 Attribute..............................................7
3.1.4 Picture of the Encoding of an Attribute-with-one-value.7
3.1.5 Additional-value.......................................8
3.1.6 Alternative Picture of the Encoding of a Request Or a
Response...............................................9
3.2 Syntax of Encoding ........................................9
3.3 Attribute-group ..........................................11
3.4 Required Parameters ......................................12
3.4.1 Version-number........................................12
3.4.2 Operation-id..........................................12
3.4.3 Status-code...........................................12
3.4.4 Request-id............................................13
3.5 Tags .....................................................13
3.5.1 Delimiter Tags........................................13
3.5.2 Value Tags............................................14
3.6 Name-Length ..............................................16
3.7 (Attribute) Name .........................................16
3.8 Value Length .............................................16
3.9 (Attribute) Value ........................................17
3.10 Data .....................................................18
4. Encoding of Transport Layer ...................................18
4.1 Printer-uri and job-uri ..................................19
5. IPP URL Scheme ................................................20
6. IANA Considerations ...........................................22
7. Internationalization Considerations ...........................23
8. Security Considerations .......................................23
8.1 Security Conformance Requirements ........................23
8.1.1 Digest Authentication.................................23
8.1.2 Transport Layer Security (TLS)........................24
8.2 Using IPP with TLS .......................................25
9. Interoperability with IPP/1.0 Implementations .................25
9.1 The "version-number" Parameter ...........................25
9.2 Security and URL Schemes .................................26
10. References ...................................................27
11. Authors' Addresses ...........................................29
12. Other Participants: ..........................................31
13. Appendix A: Protocol Examples ................................33
13.1 Print-Job Request ........................................33
13.2 Print-Job Response (successful) ..........................34
13.3 Print-Job Response (failure) .............................35
13.4 Print-Job Response (success with attributes ignored) .....36
13.5 Print-URI Request ........................................38
13.6 Create-Job Request .......................................39
13.7 Get-Jobs Request .........................................40
13.8 Get-Jobs Response ........................................41
14. Appendix B: Registration of MIME Media Type Information for
"application/ipp".............................................42
15. Appendix C: Changes from IPP/1.0 .............................44
16. Full Copyright Statement .....................................45
This document contains the rules for encoding IPP operations and describes two layers: the transport layer and the operation layer.
このドキュメントには、IPP操作をエンコードするためのルールが含まれており、輸送層と動作層の2つの層について説明します。
The transport layer consists of an HTTP/1.1 request or response. RFC 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports.
輸送層は、HTTP/1.1要求または応答で構成されています。RFC 2616 [RFC2616]はHTTP/1.1を説明しています。このドキュメントは、IPP実装がサポートするHTTPヘッダーを指定します。
The operation layer consists of a message body in an HTTP request or response. The document "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2911] is henceforth referred to as the "IPP model document" or simply "model document".
操作層は、HTTP要求または応答のメッセージ本文で構成されています。ドキュメント「インターネット印刷プロトコル/1.1：モデルとセマンティクス」[RFC2911]は、このようなメッセージ本文とサポート値のセマンティクスを定義します。このドキュメントは、IPP操作のエンコードを指定します。前述のドキュメント[RFC2911]は、以降、「IPPモデルドキュメント」または単に「モデルドキュメント」と呼ばれます。
Note: the version number of IPP (1.1) and HTTP (1.1) are not linked. They both just happen to be 1.1.
注：IPP（1.1）とHTTP（1.1）のバージョン数はリンクされていません。どちらもたまたま1.1です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
「必須」、「必須」、「必須」、「「ははは」、「そうはない」、「推奨」、「5月」、および「オプション」は、RFC 2119で説明されているように解釈されます[RFC2119]。
The operation layer 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 and some natural language. A character string MUST be in "reading order" with the first character in the value (according to reading order) being the first character in the encoding. A character string whose associated charset is US-ASCII whose associated natural language is US English is henceforth called a US-ASCII-STRING. A character string whose associated charset and natural language are specified in a request or response as described in the model document is henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP model document order" with the first octet in the value (according to the IPP model document order) being the first octet in the encoding. Every integer in this encoding MUST be encoded as a signed integer using two's-complement binary encoding with big-endian format (also known as "network order" and "most significant byte first"). The number of octets for an integer MUST be 1, 2 or 4, depending on usage in the protocol. Such one-octet integers, henceforth called SIGNED-BYTE, are used for the version-number and tag fields. Such two-byte integers, henceforth called SIGNED-SHORT are used for the operation-id, status-code and length fields. Four byte integers, henceforth called SIGNED-INTEGER, are used for value fields and the request-id.
エンコーディングは、最も原始的なタイプとしてオクテットで構成されています。オクテットから構築されたいくつかのタイプがありますが、3つの重要なタイプは整数、文字列、オクテット文字列で、他のほとんどのデータ型が構築されています。このエンコーディングのすべての文字列は、文字が何らかのチャーセットと自然言語に関連付けられている一連のキャラクターでなければなりません。文字文字列は「読み取り順序」でなければなりません。値の最初のキャラクター（読書順序に従って）がエンコードの最初のキャラクターです。関連するチャーセットは、関連する自然言語が米国英語である米国ASCIIであるキャラクター文字列は、以降、US-ASCII-stringと呼ばれています。モデルドキュメントで説明されているように、関連するチャーセットと自然言語がリクエストまたは応答で指定されている文字文字列は、今後ローカライズされた弦と呼ばれます。オクテット文字列は「IPPモデルドキュメントオーダー」にある必要があり、値の最初のオクテット（IPPモデルドキュメント順序による）がエンコードの最初のオクテットである必要があります。このエンコードのすべての整数は、ビッグエンディアン形式（「ネットワーク注文」と「最も重要なバイト」とも呼ばれる）で2つの補完バイナリエンコードを使用して、署名整合整数としてエンコードする必要があります。整数のオクテットの数は、プロトコルの使用に応じて1、2、または4でなければなりません。このような1オクテットの整数は、以降、signed-byteと呼ばれるもので、バージョン番号とタグフィールドに使用されます。このような2バイトの整数、以降、署名番号と呼ばれる整数は、Operation-ID、ステータスコード、および長さフィールドに使用されます。以降、Signed-Integerと呼ばれる4バイトの整数が、値フィールドとリクエストIDに使用されます。
The following two sections present the encoding of the operation layer in two ways:
次の2つのセクションでは、2つの方法で操作層のエンコードを示します。
- informally through pictures and description - formally through Augmented Backus-Naur Form (ABNF), as specified by RFC 2234 [RFC2234]
- 写真と説明を通じて非公式に - RFC 2234 [RFC2234]で指定されているように、拡張されたバックスノーフォーム（ABNF）を通じて正式に
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
-----------------------------------------------
The first three fields in the above diagram contain the value of attributes described in section 3.1.1 of the Model document.
上記の図の最初の3つのフィールドには、モデルドキュメントのセクション3.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 document). The IPP model document specifies the required attribute groups and their order for each operation request and response.
4番目のフィールドは「属性グループ」フィールドであり、0回以上発生します。各「属性グループ」フィールドは、操作属性グループまたはジョブ属性グループなどの単一の属性グループを表します（モデルドキュメントを参照）。IPPモデルドキュメントは、必要な属性グループと、各操作要求と応答の注文を指定します。
The "end-of-attributes-tag" field is always present, even when the "data" is not present. The Model document specifies for each operation request and response whether the "data" field is present or absent.
「データ」が存在しない場合でも、「アトリビュートの終了タグ」フィールドは常に存在します。モデルドキュメントは、各操作要求に対して「データ」フィールドが存在するか存在しないかどうかを指定します。
Each "attribute-group" field is encoded as follows:
各「属性グループ」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| begin-attribute-group-tag | 1 byte
----------------------------------------------------------
| attribute | p bytes |- 0 or more
----------------------------------------------------------
The "begin-attribute-group-tag" field marks the beginning of an
"attribute-group" field and its value identifies the type of
attribute group, e.g. Operations Attributes group versus a Job
Attributes group. The "begin-attribute-group-tag" field also marks
the end of the previous attribute group except for the "begin-
attribute-group-tag" field in the first "attribute-group" field of a
request or response. The "begin-attribute-group-tag" field acts as
an "attribute-group" terminator because an "attribute-group" field
cannot nest inside another "attribute-group" field.
An "attribute-group" field contains zero or more "attribute" fields.
「属性グループ」フィールドには、ゼロ以上の「属性」フィールドが含まれます。
Note, the values of the "begin-attribute-group-tag" field and the "end-of-attributes-tag" field are called "delimiter-tags".
注意してください。「Begin-Attribute-Group-Tag」フィールドと「Attributes-Tag-Tagの終了」フィールドの値は「Delimiter-Tags」と呼ばれます。
An "attribute" field is encoded as follows:
「属性」フィールドは次のようにエンコードされます。
-----------------------------------------------
| attribute-with-one-value | q bytes
----------------------------------------------------------
| additional-value | r bytes |- 0 or more
----------------------------------------------------------
When an attribute is single valued (e.g. "copies" with 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つの値（例えば、「片面」の値だけで「側面がサポートする」）で多値（例：「片面」だけ）をエンコードします。-one-value "フィールド。属性がn値（例えば、「片面」と「両面長端」との値が付いた「側面がサポートする」）でマルチ値になっている場合、「1つの価値のある属性のある属性でエンコードされています「フィールドに続いて、n-1」の追加価値フィールドが続きます。
Each "attribute-with-one-value" field is encoded as follows:
それぞれの「属性と価値のある」フィールドは、次のようにエンコードされます。
-----------------------------------------------
| value-tag | 1 byte
-----------------------------------------------
| name-length (value is u) | 2 bytes
-----------------------------------------------
| name | u bytes
-----------------------------------------------
| value-length (value is v) | 2 bytes
-----------------------------------------------
| value | v bytes
-----------------------------------------------
An "attribute-with-one-value" field is encoded with five subfields:
The "value-tag" field specifies the attribute syntax, e.g. 0x44 for the attribute syntax 'keyword'.
「バリュータグ」フィールドは、属性構文を指定します。属性構文「キーワード」の0x44。
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".
「名前の長さ」フィールドは、バイトの「名前」フィールドの長さを指定します。上記の図のuまたは「側面がサポートする」という名前の15。
The "name" field contains the textual name of the attribute, e.g. "sides-supported".
「名前」フィールドには、属性のテキスト名が含まれています。「サイドサポート」。
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'.
「値」フィールドは、バイトの「値」フィールドの長さを指定します。v上記の図のvまたは（キーワード）値「片面」の値。
The "value" field contains the value of the attribute, e.g. the textual value 'one-sided'.
「値」フィールドには、属性の値が含まれています。テキスト値「片側」。
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
-----------------------------------------------
An "additional-value" is encoded with four subfields:
「追加の価値」は、4つのサブフィールドでエンコードされます。
The "value-tag" field specifies the attribute syntax, e.g. 0x44 for the attribute syntax 'keyword'.
「バリュータグ」フィールドは、属性構文を指定します。属性構文「キーワード」の0x44。
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).
「名前の長さ」フィールドの値は、「追加の価値」であることを示すために0の値を持っています。「名前の長さ」フィールドの値は、「追加の値」フィールド（「名前の長さ」は0）を「1つの価値のある属性」フィールド（「name-length」は0ではありません）を区別します。
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'.
「値」フィールドは、バイトの「値」フィールドの長さを指定します。w上記の図のw（キーワード）値「両面長端」の値。
The "value" field contains the value of the attribute, e.g. the textual value 'two-sided-long-edge'.
「値」フィールドには、属性の値が含まれています。テキスト値「双方向長い端」。
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
-----------------------------------------------
The following show what fields the parser would expect after each type of "tag":
次のことは、各タイプの「タグ」の後にパーサーが期待するフィールドを示しています。
- "begin-attribute-group-tag": expect zero or more "attribute" fields - "value-tag": expect the remainder of an "attribute-with-one-value" or an "additional-value". - "end-of-attributes-tag": expect that "attribute" fields are complete and there is optional "data"
- 「Begin-Attribute-Group-Tag」：ゼロ以上の「属性「フィールド」 - 「Value-Tag」：「Value-One-Value」または「付加価値」の残りの属性を期待します。 - 「アトリビュートの終了タグ」：「属性」フィールドが完成し、オプションの「データ」があることを期待してください
The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be case sensitive. For example 'a' means lower case 'a' and not upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented as '%x' values which show their range of values.
以下の構文は、「リテラルの文字列」がケースに敏感でなければならないことを除いて、ABNF [RFC2234]です。たとえば、「a」とは、「a」を意味し、上品な「a」ではありません。さらに、署名されたバイトと署名されたショートフィールドは、値の範囲を示す「％x」値として表されます。
ipp-message = ipp-request / ipp-response ipp-request = version-number operation-id request-id *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-of-response = version-number code request-id *属性 - グループaTtributes-tag-tagデータ
attribute-group = begin-attribute-group-tag *attribute
属性-Group = begin-attribute-group-tag *属性
version-number = major-version-number minor-version-number major-version-number = SIGNED-BYTE minor-version-number = SIGNED-BYTE
バージョン番号=メジャーバージョン番号マイナーバージョン番号メジャーバージョン番号=署名付きマイナーバージョン番号
operation-id = SIGNED-SHORT ; mapping from model defined below
status-code = SIGNED-SHORT ; mapping from model defined below
request-id = SIGNED-INTEGER ; whose value is > 0
attribute = attribute-with-one-value *additional-value
属性=属性 - 1つの価値 *追加価値
attribute-with-one-value = value-tag name-length name value-length value additional-value = value-tag zero-name-length value-length value
属性with-one-value = value-tag name-length name name length値
name-length = SIGNED-SHORT ; number of octets of 'name'
name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
value-length = SIGNED-SHORT ; number of octets of 'value'
value = OCTET-STRING
data = OCTET-STRING
zero-name-length = %x00.00 ; name-length of 0
value-tag = %x10-FF ;see section 3.7.2
begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1
end-of-attributes-tag = %x03 ; tag of 3
; see section 3.7.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
The syntax below defines additional terms that are referenced in this document. This syntax provides an alternate grouping of the delimiter tags.
以下の構文は、このドキュメントで参照されている追加の用語を定義します。この構文は、区切りタグの代替グループ化を提供します。
delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1
end-of-attributes-tag
delimiter-tag = %x00-0F ; see section 3.7.1
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / %x06-0F
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
Each "attribute-group" field MUST be encoded with the "begin-attribute-group-tag" field followed by zero or more "attribute" sub-fields.
各「属性グループ」フィールドは、「begin-aTtribute-group-tag」フィールドと続いてゼロ以上の「属性」サブフィールドをエンコードする必要があります。
The table below maps the model document group name to value of the "begin-attribute-group-tag" field:
以下の表は、モデルドキュメントグループ名を「Begin-Attribute-Group-Tag」フィールドの値にマッピングします。
Model Document Group "begin-attribute-group-tag" field values
モデルドキュメントグループ「BEGIN-ATTRIBUTE-GROUP-TAG」フィールド値
Operation Attributes "operations-attributes-tag" Job Template Attributes "job-attributes-tag" Job Object Attributes "job-attributes-tag" Unsupported Attributes "unsupported-attributes-tag" Requested Attributes "job-attributes-tag" (Get-Job-Attributes) Requested Attributes "printer-attributes-tag" (Get-Printer-Attributes) Document Content in a special position as described above
操作属性「Operations-Attributes-Tag」ジョブテンプレート属性「ジョブアトリビュートタグタグ」属性「ジョブオブジェクト属性」属性「ジョブアトトリュートタグ」属性 "サポートされていない属性" "unsupported-attributes-tag-"要求された属性 "ジョブアトリューツタグ"（get-Job-aTtributes）要求された属性「プリンターアトリビューツタグ」（get-printer-aTtributes）ドキュメントコンテンツは、上記のように特別な位置にあります
For each operation request and response, the model document prescribes the required and optional attribute groups, along with their order. Within each attribute group, the model document prescribes the required and optional attributes, along with their order.
操作要求と応答ごとに、モデルドキュメントは、必要な属性グループとその注文を規定しています。各属性グループ内で、モデルドキュメントは、注文とともに必要な属性とオプションの属性を規定しています。
When the Model document 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 document, the Unsupported Attributes Group SHOULD be present only if the unsupported attributes group contains at least one attribute.
モデルドキュメントがリクエストまたは応答で属性グループを必要とし、属性グループにゼロ属性が含まれている場合、リクエストまたは応答は、属性グループを「begin-aTtribute-group-tag」フィールドに続いてゼロ「属性」フィールドをエンコードする必要があります。たとえば、クライアントがGet-Printer-Attributes操作で1つのサポートされていない属性を要求する場合、プリンターは「属性」フィールドを返す必要があり、プリンター属性グループの「begin-aTtribute-group-tag」フィールドを返す必要があります。。サポートされていない属性グループはそのような例ではありません。モデル文書によると、サポートされていない属性グループが、サポートされていない属性グループに少なくとも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) 「begin-aTtribute-Group-TAG」フィールドは、「属性」フィールドがゼロのフィールドです。
b) An expected but missing "begin-attribute-group-tag" field.
b) 予想されるが欠落している「begin-aTtribute-group-tag」フィールド。
When the Model document 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, for 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つの「begin-aTtribute-group-tag」フィールドを含める必要があります。ゼロ「属性」サブフィールド。たとえば、Get-Jobsの操作では、一部のジョブでゼロ属性を返す場合があります。「BEGIN-ATTRIBUTE-GROUP-TAG」フィールドに続いてゼロ「属性」フィールドは、「キューに入手できない」というキューに仕事がないことを受信者に伝えます。
Some operation elements are called parameters in the model document [RFC2911]. They MUST be encoded in a special position and they MUST NOT appear as operation attributes. These parameters are described in the subsections below.
一部の操作要素は、モデルドキュメント[RFC2911]のパラメーターと呼ばれます。それらは特別な位置にエンコードする必要があり、操作属性として表示されてはなりません。これらのパラメーターは、以下のサブセクションで説明されています。
The "version-number" field MUST consist of a major and minor version-number, each of which MUST be represented by a SIGNED-BYTE. The major version-number MUST be the first byte of the encoding and the minor version-number MUST be the second byte of the encoding. The protocol described in this document MUST have a major version-number of 1 (0x01) and a minor version-number of 1 (0x01). The ABNF for these two bytes MUST be %x01.01.
「バージョン番号」フィールドは、メジャーバージョンとマイナーバージョンの数で構成されている必要があります。メジャーバージョン番号はエンコードの最初のバイトであり、マイナーバージョン番号はエンコードの2番目のバイトでなければなりません。このドキュメントで説明したプロトコルには、メジャーバージョン番号1（0x01）と1（0x01）のマイナーバージョン番号が必要です。これら2つのバイトのABNFは％x01.01でなければなりません。
The "operation-id" field MUST contain an operation-id value defined in the model document. The value MUST be encoded as a SIGNED-SHORT and it MUST be in the third and fourth bytes of the encoding of an operation request.
「Operation-ID」フィールドには、モデルドキュメントで定義されたOperation-ID値を含める必要があります。値は署名されたショートとしてエンコードする必要があり、操作リクエストのエンコードの3番目と4番目のバイトにある必要があります。
The "status-code" field MUST contain a status-code value defined in the model document. The value MUST be encoded as a SIGNED-SHORT and it MUST be in the third and fourth bytes of the encoding of an operation response.
「ステータスコード」フィールドには、モデルドキュメントで定義されたステータスコード値を含める必要があります。値は署名されたショートとしてエンコードする必要があり、操作応答のエンコードの3番目と4番目のバイトでなければなりません。
The status-code is an operation attribute in the model document. In the protocol, the status-code is in a special position, outside of the operation attributes.
ステータスコードは、モデルドキュメントの操作属性です。プロトコルでは、ステータスコードは操作属性の外にある特別な位置にあります。
If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 (successful-ok). With any other HTTP Status-Code value, the HTTP response MUST NOT contain an IPP message-body, and thus no IPP status-code is returned.
IPPステータスコードが返される場合、HTTPステータスコードは200（成功したOK）でなければなりません。他のHTTPステータスコード値では、HTTP応答にIPPメッセージボディを含める必要があるため、IPPステータスコードは返されません。
The "request-id" field MUST contain a request-id value as defined in the model document. The value MUST be encoded as a SIGNED-INTEGER and it MUST be in the fifth through eighth bytes of the encoding.
「Request-ID」フィールドには、モデルドキュメントで定義されているリクエストID値を含める必要があります。値は署名されたintegerとしてエンコードする必要があり、エンコードの5番目から8番目のバイトでなければなりません。
There are two kinds of tags:
タグには2種類あります。
- delimiter tags: delimit major sections of the protocol, namely attributes and data - value tags: specify the type of each attribute value
- 区切り文字：プロトコルの主要セクション、つまり属性とデータ - 値タグ：各属性値のタイプを指定する
The following table specifies the values for the delimiter tags:
次の表には、区切り文字の値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x00 reserved for definition in a future IETF
standards track document
0x01 "operation-attributes-tag"
0x02 "job-attributes-tag"
0x03 "end-of-attributes-tag"
0x04 "printer-attributes-tag"
0x05 "unsupported-attributes-tag"
0x06-0x0f reserved for future delimiters in IETF
standards track documents
When a "begin-attribute-group-tag" field occurs in the protocol, it means that zero or more following attributes up to the next delimiter tag MUST be 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 MUST be members of the Operations Attributes group.
プロトコルで「begin-aTtribute-Group-TAG」フィールドが発生する場合、次のデリミタータグまでのゼロ以上の属性が「begin-aTtribute--」の値によって指定された属性グループに属する属性でなければならないことを意味します。グループタグ "。たとえば、「Begin-Attribute-Group-Tag」の値が0x01の場合、次の属性はOperations属性グループのメンバーでなければなりません。
The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an operation. It MUST be the last "delimiter-tag". If the operation has a document-content group, the document data in that group MUST follow the "end-of-attributes-tag".
「aTtributes-tagの終了」（値0x03）は、操作で正確に1回発生する必要があります。それは最後の「デリミタータグ」でなければなりません。操作にドキュメントコンテンツグループがある場合、そのグループのドキュメントデータは「アトリビュートの終了タグ」に従う必要があります。
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 document. For further details, see section 3.7 "(Attribute) Name" and 13 "Appendix A: Protocol Examples".
各操作要求の「属性グループ」フィールド（開始は「begin-aTtribute-group-tag」サブフィールドでマークされている）の順序と存在と、各操作応答はモデルドキュメントで定義されている必要があります。詳細については、セクション3.7 "（属性）"および13 "付録A：プロトコルの例"を参照してください。
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 that there is an entire attribute group that it doesn't understand as opposed to a single value that it doesn't understand.
プリンターは、「値タグ」（値タグ」（0x10〜0xffの値）とは異なる方法で「デリミタータグ」（0x00〜0x0Fの値）を扱う必要があります。そうすることで、プリンターは理解できない属性グループ全体があることを知っています。理解していない単一の価値とは対照的に。
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.
残りのテーブルには、属性の最初のオクテットである「バリュータグ」フィールドの値が表示されます。「バリュータグ」フィールドは、属性の値のタイプを指定します。
The following table specifies the "out-of-band" values for the "value-tag" field.
次の表は、「バリュータグ」フィールドの「バンド外」値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x10 unsupported
0x11 reserved for 'default' for definition in a future
IETF standards track document
0x12 unknown
0x13 no-value
0x14-0x1F reserved for "out-of-band" values in future IETF
standards track documents.
The following table specifies the integer values for the "value-tag" field:
次の表は、「バリュータグ」フィールドの整数値を指定します。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x20 reserved for definition in a future IETF
standards track document
0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F reserved for integer types for definition in
future IETF standards track documents
NOTE: 0x20 is reserved for "generic integer" if it should ever be needed.
注：0x20は、必要な場合は「ジェネリック整数」に予約されています。
The following table specifies the octetString values for the "value-tag" field:
次の表は、「バリュータグ」フィールドのオクテットストリング値を指定しています。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x30 octetString with an unspecified format
0x31 dateTime
0x32 resolution
0x33 rangeOfInteger
0x34 reserved for definition in a future IETF
standards track document
0x35 textWithLanguage
0x36 nameWithLanguage
0x37-0x3F reserved for octetString type definitions in
future IETF standards track documents
The following table specifies the character-string values for the "value-tag" field:
次の表は、「バリュータグ」フィールドのキャラクターストリング値を指定しています。
Tag Value (Hex) Meaning
タグ値（ヘックス）の意味
0x40 reserved for definition in a future IETF
standards track document
0x41 textWithoutLanguage
0x42 nameWithoutLanguage
0x43 reserved for definition in a future IETF
standards track document
0x44 keyword
0x45 uri
0x46 uriScheme
0x47 charset
0x48 naturalLanguage
0x49 mimeMediaType
0x4A-0x5F reserved for character string type definitions
in future IETF standards track documents
NOTE: 0x40 is reserved for "generic character-string" if it should ever be needed.
注：0x40は、必要な場合は「一般的なキャラクターストリング」用に予約されています。
NOTE: an attribute value always has a type, which is explicitly specified by its tag; one such tag value is "nameWithoutLanguage". An attribute's name has an implicit type, which is keyword.
注：属性値には常にタイプがあり、タグで明示的に指定されています。そのようなタグ値の1つは「namewithoutlanguage」です。属性の名前には、キーワードである暗黙のタイプがあります。
The values 0x60-0xFF are reserved for future type definitions in IETF standards track documents.
値0x60-0xffは、IETF標準の追跡ドキュメントの将来のタイプ定義のために予約されています。
The tag 0x7F is reserved for extending types beyond the 255 values available with a single byte. A tag value of 0x7F MUST signify that the first 4 bytes of the value field are interpreted as the tag value. Note this future extension doesn't affect parsers that are unaware of this special tag. The tag is like any other unknown tag, and the value length specifies the length of a value, which contains a value that the parser treats atomically. Values from 0x00 to 0x37777777 are reserved for definition in future IETF standard track documents. The values 0x40000000 to 0x7FFFFFFF are reserved for vendor extensions.
タグ0x7Fは、単一のバイトで利用可能な255の値を超えて拡張されるために予約されています。0x7Fのタグ値は、値フィールドの最初の4バイトがタグ値として解釈されることを示す必要があります。この将来の拡張機能は、この特別なタグを知らないパーサーには影響しません。タグは他の未知のタグと同じで、値の長さは値の長さを指定します。これには、パーサーが原子的に処理する値が含まれます。0x00から0x37777777の値は、将来のIETF標準トラックドキュメントの定義のために予約されています。値0x40000000〜0x7fffffffは、ベンダー拡張機能用に予約されています。
The "name-length" field MUST consist of a SIGNED-SHORT. This field MUST specify 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.
「名前の長さ」フィールドは、署名されたショートで構成されている必要があります。このフィールドは、「名前」フィールドに続く直後のオクテットの数を指定する必要があります。このフィールドの値は、「名前の長さ」フィールドの2バイトを除外します。たとえば、「名前」フィールドに「側面」が含まれている場合、このフィールドの値は5です。
If a "name-length" field has a value of zero, the following "name" field MUST be empty, and the following value MUST be treated as an additional value for the 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 mal-formed (see [RFC2911] section 3.1.3). The zero-length name is the only mechanism for multi-valued attributes.
「名前の長さ」フィールドにゼロの値がある場合、次の「名前」フィールドが空でなければならず、次の値は、最寄りの「属性のある属性とエンコードされた属性の追加値」として扱わなければなりません。値 "フィールド。属性グループ内で、2つ以上の属性が同じ名前を持っている場合、属性グループはmal形成されます（[rfc2911]セクション3.1.3を参照）。ゼロ長の名前は、多値の属性の唯一のメカニズムです。
The "name" field MUST contain the name of an attribute. The model document [RFC2911] specifies such names.
「名前」フィールドには、属性の名前が含まれている必要があります。モデルドキュメント[RFC2911]は、そのような名前を指定します。
The "value-length" field MUST consist of a SIGNED-SHORT. This field MUST specify 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 (text) value 'one-sided', the value of this field is 9.
「値の長さ」フィールドは、署名されたショートで構成されている必要があります。このフィールドは、「Value」フィールドに続く直後のオクテットの数を指定する必要があります。このフィールドの値は、「値長」フィールドの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 character-strings, the sender MUST encode the value with all the characters of the string and without any padding characters.
キャラクターストリングで表されるタイプのいずれかについて、送信者は、文字列のすべての文字とパディング文字なしで値をエンコードする必要があります。
For "out-of-band" "value-tag" fields 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、「値」が空でなければなりません。「値」には、「バリュータグ」がこれらの「帯域外」値の1つを持っている場合、意味はありません。将来の「帯域外」「バリュータグ」フィールドの場合、定義が「値の長さ」が非ゼロであり、「値」が空でない可能性があることを明示的に述べていない限り、同じルールが保持されます。
The syntax types (specified by the "value-tag" field) and most of the details of the representation of attribute values are defined in the IPP model document. The table below augments the information in the model document, and defines the syntax types from the model document in terms of the 5 basic types defined in section 3, "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
構文タイプ（「値タグ」フィールドで指定）と属性値の表現の詳細のほとんどは、IPPモデルドキュメントで定義されています。以下の表は、モデルドキュメントの情報を強化し、セクション3「操作層のエンコード」で定義されている5つの基本タイプの観点からモデルドキュメントの構文タイプを定義します。5つのタイプは、US-ASCII-STRING、ローカライズされた弦、署名整数、署名されたショート、サインバイト、オクテットストリングです。
Syntax of Attribute Encoding Value
属性エンコード値の構文
textWithoutLanguage, LOCALIZED-STRING. nameWithoutLanguage
TextWithOutLanguage、ローカライズされた弦。namewithoutlanguage
textWithLanguage OCTET-STRING consisting of 4 fields: a. a SIGNED-SHORT which is the number of octets in the following field b. a value of type natural-language, c. a SIGNED-SHORT which is the number of octets in the following field, d. a value of type textWithoutLanguage. The length of a textWithLanguage value MUST be 4 + the value of field a + the value of field c.
4つのフィールドで構成されるテキストとオクテットストリング：a。次のフィールドのオクテットの数である署名済みショートb。タイプの自然言語の値、c。次のフィールドのオクテットの数である署名されたショート、d。TextWithOutLanguageのタイプの値。テキストの長さの値は4でなければなりません4フィールドの値aフィールドcの値。
nameWithLanguage OCTET-STRING consisting of 4 fields: a. a SIGNED-SHORT which is the number of octets in the following field b. a value of type natural-language, c. a SIGNED-SHORT which is the number of octets in the following field d. a value of type nameWithoutLanguage. The length of a nameWithLanguage value MUST be 4 + the value of field a + the value of field c.
4つのフィールドで構成されるoccet-stringをnamewithlanguage：a。次のフィールドのオクテットの数である署名済みショートb。タイプの自然言語の値、c。次のフィールドd。namewithoutlanguageのタイプの値。名前のある名前の長さは4でなければなりません4フィールドの値aフィールドcの値。
charset, US-ASCII-STRING. naturalLanguage, mimeMediaType, keyword, uri, and uriScheme Syntax of Attribute Encoding Value
charset、us-ascii-string。naturallanguage、mimemediatype、キーワード、URI、およびurischeme属性エンコード値の構文
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 'true'.
0x00が「false」であり、0x01が「True」であるBoolean Signed-byte。
integer and enum a SIGNED-INTEGER.
整数と列挙された署名整数。
dateTime OCTET-STRING consisting of eleven octets whose contents are defined by "DateAndTime" in RFC 1903 [RFC1903].
RFC 1903 [RFC1903]の「dateandtime」によって内容が定義されている11のオクテットで構成されるDateTimeオクテットストリング。
resolution OCTET-STRING consisting of nine octets of 2 SIGNED-INTEGERs followed by a SIGNED-BYTE. The first SIGNED-INTEGER contains the value of cross feed direction resolution. The second SIGNED-INTEGER contains the value of feed direction resolution. The SIGNED-BYTE contains the units
解像度のオクテットストリングは、署名された2つの署名者の9オクテットで構成され、その後に署名されたバイトが続きます。最初の署名されたintegerには、クロスフィード方向解像度の値が含まれています。2番目の署名されたintegerには、フィード方向解像度の値が含まれています。署名されたバイトにはユニットが含まれています
rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. The first SIGNED-INTEGER contains the lower bound and the second SIGNED-INTEGER contains the upper bound.
2つの署名された整数で構成される範囲の8オクテット。最初の署名されたintegerには下限が含まれ、2番目の署名されたIntegerには上限が含まれています。
1setOf X Encoding according to the rules for an attribute with more than 1 value. Each value X is encoded according to the rules for encoding its type.
1値を超える属性のルールに従ってxセットxエンコード。各値xは、そのタイプをエンコードするためのルールに従ってエンコードされます。
octetString OCTET-STRING
OctetString Octet-String
The 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 [RFC2616] is the transport layer for this protocol.
HTTP/1.1 [RFC2616]は、このプロトコルの輸送層です。
The operation layer has been designed with the assumption that the transport layer contains the following information:
操作層は、輸送層に次の情報が含まれているという仮定で設計されています。
- the URI of the target job or printer operation - the total length of the data in the operation layer, either as a single length or as a sequence of chunks each with a length.
- ターゲットジョブまたはプリンター操作のURI - 単一の長さまたは長さのチャンクのシーケンスとして、操作層のデータの全長。
It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over some other port as well.
プリンターの実装は、他のポートでもHTTPをサポートする場合がありますが、有名なポート631（IPPデフォルトポート）を割り当てたIANA上のプリンター実装をサポートする必要があります。
Each HTTP operation MUST use the POST method where the request-URI is the object target of the operation, and where the "Content-Type" of the message-body in each request and response MUST be "application/ipp". The message-body MUST contain the operation layer and MUST have the syntax described in section 3.2 "Syntax of Encoding". A client implementation MUST adhere to the rules for a client described for HTTP1.1 [RFC2616]. A printer (server) implementation MUST adhere the rules for an origin server described for HTTP1.1 [RFC2616].
各HTTP操作は、リクエスト-URIが操作のオブジェクトターゲットであり、各リクエストと応答のメッセージボディの「コンテンツタイプ」が「アプリケーション/IPP」でなければならないPOSTメソッドを使用する必要があります。メッセージボディには操作レイヤーが含まれている必要があり、セクション3.2「エンコードの構文」で説明されている構文が必要です。クライアントの実装は、HTTP1.1 [RFC2616]について説明されているクライアントのルールを順守する必要があります。プリンター（サーバー）の実装は、HTTP1.1 [RFC2616]について説明されているOrigin Serverのルールを遵守する必要があります。
An IPP server sends a response for each request that it receives. If an IPP server detects an error, it MAY send a response before it has read the entire request. If the HTTP layer of the IPP server completes processing the HTTP headers successfully, it MAY send an intermediate response, such as "100 Continue", with no IPP data before sending the IPP response. A client MUST expect such a variety of responses from an IPP server. For further information on HTTP/1.1, consult the HTTP documents [RFC2616].
IPPサーバーは、受信する各リクエストの応答を送信します。IPPサーバーがエラーを検出した場合、リクエスト全体を読み取る前に応答を送信する場合があります。IPPサーバーのHTTPレイヤーがHTTPヘッダーの処理を正常に完了すると、IPP応答を送信する前にIPPデータがない「100 Continue」などの中間応答が送信される場合があります。クライアントは、IPPサーバーからこのようなさまざまな応答を期待する必要があります。HTTP/1.1の詳細については、HTTPドキュメント[RFC2616]を参照してください。
An HTTP server MUST support chunking for IPP requests, and an IPP client MUST support chunking for IPP responses according to HTTP/1.1 [RFC2616]. Note: this rule causes a conflict with non-compliant implementations of HTTP/1.1 that don't support chunking for POST methods, and this rule may cause a conflict with non-compliant implementations of HTTP/1.1 that don't support chunking for CGI scripts.
HTTPサーバーはIPP要求のチャンキングをサポートする必要があり、IPPクライアントはHTTP/1.1 [RFC2616]に従ってIPP応答のチャンキングをサポートする必要があります。注：このルールは、ポストメソッドのチャンキングをサポートしないHTTP/1.1の非準拠の実装との競合を引き起こします。このルールは、CGIのチャンキングをサポートしないHTTP/1.1の非準拠の実装との競合を引き起こす可能性がありますスクリプト。
All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is intended to cover the more specific notion of URL as well.
すべてのプリンターおよびジョブオブジェクトは、均一なリソース識別子（URI）[RFC2396]によって識別されるため、それらは永続的かつ明確に参照できるようにします。すべてのURLはURIの特殊な形式であるため、このドキュメントの残りの部分でURIがより一般的に使用されていても、その使用は、より具体的なURLの概念をカバーすることを目的としています。
Some operation elements are encoded twice, once as the request-URI on the HTTP Request-Line and a second time as a REQUIRED operation attribute in the application/ipp entity. These attributes are the target URI for the operation and are called printer-uri and job-uri. Note: The target URI is included twice in an operation referencing the same IPP object, but the two URIs NEED NOT be literally identical. One can be a relative URI and the other can be an absolute URI. HTTP/1.1 allows clients to generate and send a relative URI rather than an absolute URI. A relative URI identifies a resource with the scope of the HTTP server, but does not include scheme, host or port. The following statements characterize how URLs should be used in the mapping of IPP onto HTTP/1.1:
一部の操作要素は、HTTPリクエストラインのリクエスト-URIとして1回、アプリケーション/IPPエンティティの必要な操作属性として2回エンコードされます。これらの属性は、操作のターゲットURIであり、プリンター-URIとjob-uriと呼ばれます。注：ターゲットURIは、同じIPPオブジェクトを参照する操作に2回含まれていますが、2つのURIは文字通り同一である必要はありません。1つは相対的なURIであり、もう1つは絶対的なURIにすることができます。HTTP/1.1を使用すると、クライアントは絶対URIではなく相対URIを生成および送信できます。相対的なURIは、HTTPサーバーの範囲を持つリソースを識別しますが、スキーム、ホスト、またはポートは含まれません。以下のステートメントは、http/1.1へのIPPのマッピングでURLを使用する方法を特徴付けています。
1. Although potentially redundant, a client MUST supply the target of the operation both as an operation attribute and as a URI at the HTTP layer. The rationale for this decision is to maintain a consistent set of rules for mapping application/ipp to possibly many communication layers, even where URLs are not used as the addressing mechanism in the transport layer. 2. Even though these two URLs might not be literally identical (one being relative and the other being absolute), they MUST both reference the same IPP object. However, a Printer NEED NOT verify that the two URLs reference the same IPP object, and NEED NOT take any action if it determines the two URLs to be different. 3. The URI in the HTTP layer is either relative or absolute and is used by the HTTP server to route the HTTP request to the correct resource relative to that HTTP server. The HTTP server need not be aware of the URI within the operation request. 4. Once the HTTP server resource begins to process the HTTP request, it might get the reference to the appropriate IPP Printer object from either the HTTP URI (using to the context of the HTTP server for relative URLs) or from the URI within the operation request; the choice is up to the implementation. 5. HTTP URIs can be relative or absolute, but the target URI in the operation MUST be an absolute URI.
1. 潜在的に冗長ですが、クライアントは操作のターゲットを操作属性として、およびHTTPレイヤーのURIとして提供する必要があります。この決定の理論的根拠は、輸送層のアドレス指定メカニズムとしてURLが使用されていない場合でも、アプリケーション/IPPをおそらく多くの通信層にマッピングするための一貫した一連のルールを維持することです。2.これらの2つのURLは文字通り同一ではない場合がありますが（1つは相対的であり、もう1つは絶対的です）、両方とも同じIPPオブジェクトを参照する必要があります。ただし、プリンターは、2つのURLが同じIPPオブジェクトを参照していることを確認する必要はなく、2つのURLが異なると判断した場合、アクションを実行する必要はありません。3. HTTPレイヤーのURIは相対または絶対のいずれかであり、HTTPサーバーで使用されて、HTTP要求をそのHTTPサーバーに比べて正しいリソースにルーティングします。HTTPサーバーは、操作要求内のURIに注意する必要はありません。4. HTTPサーバーリソースがHTTP要求の処理を開始すると、HTTP URI（相対URLのHTTPサーバーのコンテキストに）または操作内のURIから適切なIPPプリンターオブジェクトへの参照を取得する可能性があります。リクエスト;選択は実装次第です。5. http urisは相対的または絶対的である可能性がありますが、操作のターゲットURIは絶対的なURIでなければなりません。
The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL that identifies either an IPP printer object or an IPP job object. The IPP attributes using the 'ipp' scheme are specified below. Because the HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP headers. The mapping is simple because the 'ipp' scheme implies all of the same protocol semantics as that of the 'http' scheme
IPP/1.1ドキュメントは、新しいスキーム「IPP」を、IPPプリンターオブジェクトまたはIPPジョブオブジェクトのいずれかを識別するURLの値として定義します。「IPP」スキームを使用したIPP属性を以下に指定します。HTTPレイヤーは「IPP」スキームをサポートしていないため、クライアントは「IPP」URLを「HTTP」URLにマッピングする必要があり、HTTP [RFC2616] [RFC2617]リクエストラインとHTTPヘッダーを構築するためのルールに従います。「IPP」スキームは、「HTTP」スキームと同じプロトコルセマンティクスのすべてを意味するため、マッピングは簡単です。
[RFC2616], except that it represents a print service and the implicit (default) port number that clients use to connect to a server is port 631.
[RFC2616]は、印刷サービスと、クライアントがサーバーに接続するために使用する暗黙の（デフォルト）ポート番号を表すことを除いて、ポート631です。
In the remainder of this section the term 'ipp-URL' means a URL whose scheme is 'ipp' and whose implicit (default) port is 631. The term 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' means a URL whose scheme is 'https',
このセクションの残りの部分では、「IPP-url」という用語は、スキームが「IPP」であり、暗黙の（デフォルト）ポートが631であるURLを意味します。「https-url」という用語は、スキームが「https」であるURLを意味します。
A client and an IPP object (i.e. the server) MUST support the ipp-URL value in the following IPP attributes. job attributes: job-uri job-printer-uri printer attributes: printer-uri-supported operation attributes: job-uri printer-uri Each of the above attributes identifies a printer or job object. The ipp-URL is intended as the value of the attributes in this list, and for no other attributes. 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オブジェクト（つまり、サーバー）は、次のIPP属性でIPP-URL値をサポートする必要があります。ジョブ属性：Job-URI Job-Printer-URIプリンター属性：プリンター-RIサポート操作属性：Job-URIプリンター-URI上記の属性のそれぞれは、プリンターまたはジョブオブジェクトを識別します。IPP-URLは、このリストの属性の値として、また他の属性を意図していません。これらの属性はすべて「URI」の構文タイプがありますが、「IPP」スキームを使用しない「URI」の構文タイプの属性があります。「Job-More-info」。
If a printer registers its URL with a directory service, the printer MUST register an ipp-URL.
プリンターがディレクトリサービスでURLを登録する場合、プリンターはIPP-URLを登録する必要があります。
User interfaces are beyond the scope of this document. But if software exposes the ipp-URL values of any of the above five attributes to a human user, it is REQUIRED that the human see the ipp-URL as is.
ユーザーインターフェイスは、このドキュメントの範囲を超えています。しかし、ソフトウェアが上記の5つの属性のいずれかのIPP-URL値を人間のユーザーに公開する場合、人間がIPP-URLをそのまま見ることが必要です。
When a client sends a request, it MUST convert a target ipp-URL to a target http-URL for the HTTP layer according to the following rules:
クライアントがリクエストを送信する場合、次のルールに従って、ターゲットIPP-URLをHTTPレイヤーのターゲットHTTP-URLに変換する必要があります。
1. change the 'ipp' scheme to 'http' 2. add an explicit port 631 if the URL does not contain an explicit port. Note: port 631 is the IANA assigned Well Known Port for the 'ipp' scheme.
1. 「IPP」スキームを「HTTP」に変更します2. URLに明示的なポートが含まれていない場合は、明示的なポート631を追加します。注：ポート631は、「IPP」スキームによく知られているポートを割り当てられたIANAです。
The client MUST use the target http-URL in both the HTTP Request-Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] . However, the client MUST use the target ipp-URL 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-URL for the value of the "printer-uri", "job-uri" or "printer-uri-supported" attributes within the application/ipp body of the response.
クライアントは、HTTP [RFC2616] [RFC2617]で指定されているように、HTTPリクエストラインヘッダーとHTTPヘッダーの両方でターゲットHTTP-URLを使用する必要があります。ただし、クライアントは、リクエストのアプリケーション/IPPボディ内の「プリンターURI」または「ジョブURI」操作属性の値にターゲットIPP-URLを使用する必要があります。サーバーは、応答のアプリケーション/IPP本体内の「プリンター-RI」、「ジョブURI」、または「プリンター-RIサポート」属性の値にIPP-URLを使用する必要があります。
For example, when an IPP client sends a request directly (i.e. no proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP connection to port 631 (the ipp implicit port) on the host "myhost.com" and sends the following data:
たとえば、IPPクライアントがリクエストを直接（つまり、プロキシなし）IPP-url「ipp：//myhost.com/myprinter/myqueue」に送信すると、ポート631（IPP暗黙のポート）へのTCP接続を開きます。ホスト「myhost.com」と次のデータを送信します。
POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in application/ipp message body) ...
post/myprinter/myqueue http/1.1ホスト：myhost.com：631 content-type：application/ipp transfer-encoding：chunked ... "" printer-uri "" ipp：//myhost.com/myprinter/myqueue "（エンコード付きアプリケーション/IPPメッセージ本文）...
As another example, when an IPP client sends the same request as above via a proxy "myproxy.com", it opens a TCP connection to the proxy port 8080 on the proxy host "myproxy.com" and sends the following data:
別の例として、IPPクライアントがプロキシ「myproxy.com」を介して上記と同じリクエストを送信すると、プロキシホスト「myproxy.com」のプロキシポート8080へのTCP接続が開き、次のデータを送信します。
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Content-type: application/ipp Transfer-Encoding: chunked ... "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in application/ipp message body) ...
投稿http://myhost.com:631/myprinter/myqueue http/1.1ホスト：myhost.com：631 content-type：application/ipp転送エンコード：チャンク... "printer-uri" "ipp：// myhost.com/myprinter/myqueue "（アプリケーション/ippメッセージ本文でエンコード）...
The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above.
次に、プロキシは、上記の「プロキシなし」の例と同じヘッダーを持つIPP Originサーバーに接続します。
This section describes the procedures for allocating encoding for the following IETF standards track extensions and vendor extensions to the IPP/1.1 Encoding and Transport document:
このセクションでは、次のIETF標準にエンコードを割り当てる手順について説明します。IPT/1.1エンコーディングおよびトランスポートドキュメントに拡張機能とベンダー拡張機能を追跡します。
1. attribute syntaxes - see [RFC2911] section 6.3 2. attribute groups - see [RFC2911] section 6.5 3. out-of-band attribute values - see [RFC2911] section 6.7
1. 属性構文 - [RFC2911]セクション6.3を参照2.属性グループ - [RFC2911]セクション6.5を参照3.帯域外属性値 - [RFC2911]セクション6.7を参照
These extensions follow the "type2" registration procedures defined in [RFC2911] section 6. Extensions registered for use with IPP/1.1 are OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding and Transport document.
これらの拡張機能は、[RFC2911]セクション6で定義されている「Type2」登録手順に従います。IPP/1.1で使用するために登録されている拡張機能は、IPP/1.1エンコードおよびトランスポートドキュメントにクライアントとIPPオブジェクトの適合性にオプションです。
These extension procedures are aligned with the guidelines as set forth by the IESG [IANA-CON]. The [RFC2911] Section 11 describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in [RFC2911] Section 11. The IPP/1.1 Encoding and Transport document may also be extended by an appropriate RFC that specifies any of the above extensions.
これらの拡張手順は、IESG [IANA-CON]によって定められたガイドラインと一致しています。[RFC2911]セクション11では、検討のために新しい登録を提案する方法について説明します。IANAは、必要な情報を除外する登録提案を拒否します。または、[RFC2911]セクション11で説明されている適切な形式に従わないことを拒否します。IPP/1.1エンコーディングおよびトランスポートドキュメントは、上記の拡張機能のいずれかを指定する適切なRFCによって拡張される場合があります。
See the section on "Internationalization Considerations" in the document "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] for information on internationalization. This document adds no additional issues.
国際化に関する情報については、ドキュメント「インターネット印刷プロトコル/1.1：モデルとセマンティクス」[RFC2911]の「インターネット印刷プロトコル/1.1：モデルとセマンティクス」のセクションを参照してください。このドキュメントは、追加の問題を追加しません。
The IPP Model and Semantics document [RFC2911] 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モデルとセマンティクスドキュメント[RFC2911]は、高レベルのセキュリティ要件（クライアント認証、サーバー認証、および操作プライバシー）について説明しています。クライアント認証は、クライアントが安全な方法でサーバーに対するIDを証明するメカニズムです。サーバー認証は、サーバーが安全な方法でクライアントに対するアイデンティティを証明するメカニズムです。オペレーションプライバシーは、盗聴から運用を保護するためのメカニズムとして定義されます。
This section defines the security requirements for IPP clients and IPP objects.
このセクションでは、IPPクライアントとIPPオブジェクトのセキュリティ要件を定義します。
IPP clients MUST support:
IPPクライアントはサポートする必要があります：
Digest Authentication [RFC2617].
消化認証[RFC2617]。
MD5 and MD5-sess MUST be implemented and supported.
MD5およびMD5-SESSを実装およびサポートする必要があります。
The Message Integrity feature NEED NOT be used.
メッセージの整合性機能を使用する必要はありません。
IPP Printers SHOULD support:
IPPプリンターはサポートする必要があります。
Digest Authentication [RFC2617].
消化認証[RFC2617]。
MD5 and MD5-sess MUST be implemented and supported.
MD5およびMD5-SESSを実装およびサポートする必要があります。
The Message Integrity feature NEED NOT be used.
メッセージの整合性機能を使用する必要はありません。
The reasons that IPP Printers SHOULD (rather than MUST) support Digest Authentication are:
IPPプリンターが（必須ではなく）消化認証をサポートすべき理由は次のとおりです。
1. While Client Authentication is important, there is a certain class of printer 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 and could potentially stall the adoption of the standard.
1. クライアント認証は重要ですが、意味をなさない特定のクラスのプリンターデバイスがあります。具体的には、ROMスペースが限られており、紙のスループットが低いローエンドデバイスは、クライアント認証を必要としない場合があります。このクラスのデバイスでは、通常、ファームウェア設計者がプロトコルと機能の間でトレードオフを行い、可能な限り低コストのソリューションに到達する必要があります。設計者の決定に因数分解されたのは、コードのサイズだけでなく、顧客に配信される各機能のテスト、メンテナンス、有用性、市場までの影響もあります。IPP/1.1の適合性を主張するために、このようなローエンドのデバイスがセキュリティを提供するように強制することは、ビジネスに意味がなく、標準の採用を妨げる可能性があります。
2. Print devices that have high-volume throughput and have available ROM space have a compelling argument to provide support for Client Authentication that safeguards the device from unauthorized access. These devices are prone to a high loss of consumables and paper if unauthorized access should occur.
2. 大量のスループットを持ち、利用可能なROMスペースを持つ印刷デバイスには、不正アクセスからデバイスを保護するクライアント認証をサポートする説得力のある引数があります。これらのデバイスは、許可されていないアクセスが発生する場合、消耗品や紙の損失が大きくなりがちです。
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for Server Authentication and Operation Privacy. IPP Printers MAY also support TLS for Client Authentication. If an IPP Printer supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 [RFC2617]) for Client Authentication if the channel is secure. TLS with the above mandated cipher suite can provide such a secure channel.
IPPプリンターは、サーバー認証と操作プライバシーのために、トランスポートレイヤーセキュリティ（TLS）[RFC2246]をサポートする必要があります。IPPプリンターは、クライアント認証のためにTLSをサポートする場合があります。IPPプリンターがTLSをサポートする場合、RFC 2246 [RFC2246]が義務付けているように、TLS_DHE_DSS_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_EDE_CBC_SHA CIPHER SUITEをサポートする必要があります。他のすべての暗号スイートはオプションです。IPPプリンターは、チャネルが安全な場合、クライアント認証のために基本認証（HTTP/1.1 [RFC2617]で説明）をサポートする場合があります。上記の義務付けられた暗号スイートを備えたTLSは、このような安全なチャネルを提供できます。
If a IPP client supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
IPPクライアントがTLSをサポートする場合、RFC 2246 [RFC2246]が義務付けているように、TLS_DHE_DSS_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_WITH_SYをサポートする必要があります。他のすべての暗号スイートはオプションです。
The IPP Model and Semantics document 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 should be the primary reference for security implications with regard to the IPP protocol itself. For backward compatibility with IPP version 1.0, IPP clients and printers may also support SSL3 [ssl]. This is in addition to the security required in this document.
IPPモデルとセマンティクス文書は、クライアントがプリンターのセキュリティポリシーを発見するために使用できる2つのプリンター属性（「URI-Authentication-Supported」および「URI-Security-Supported」）を定義します。このドキュメントは、IPP固有のセキュリティに関する考慮事項の概要も概説しており、IPPプロトコル自体に関するセキュリティへの影響の主要な参照である必要があります。IPPバージョン1.0との後方互換性については、IPPクライアントとプリンターもSSL3 [SSL]をサポートする場合があります。これは、このドキュメントで必要なセキュリティに追加されます。
IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817]. An initial IPP request never uses TLS. 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/1.1は、「HTTP/1.1内のTLSへのアップグレード」メカニズム[RFC2817]を使用します。最初のIPP要求はTLSを使用しません。クライアントは、HTTP「アップグレード」ヘッダーを使用してセキュアTLS接続を要求し、サーバーはHTTP応答で一致します。TLSへの切り替えは、サーバーがTLSにアップグレードするというクライアントの要求を許可するか、サーバーが応答でTLSに切り替えるように要求するために発生します。安全な通信は、TLSへの切り替えに対するサーバーの応答から始まります。
It is beyond the scope of this specification to mandate conformance with previous versions. IPP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1999), we would expect IPP/1.1 Printer implementations to:
この仕様の範囲を超えて、以前のバージョンへの適合を義務付けています。ただし、IPP/1.1は、以前のバージョンのサポートを簡単にするために意図的に設計されました。この仕様（1999）を作成した時点で、IPP/1.1プリンターの実装が次のと期待することは注目に値します。
understand any valid request in the format of IPP/1.0, or 1.1;
IPP/1.0または1.1の形式で有効なリクエストを理解します。
respond appropriately with a response containing the same "version-number" parameter value used by the client in the request.
リクエストでクライアントが使用する同じ「バージョン番号」パラメーター値を含む応答で適切に応答します。
And we would expect IPP/1.1 clients to:
そして、IPP/1.1クライアントには次のようになります。
understand any valid response in the format of IPP/1.0, or 1.1.
IPP/1.0または1.1の形式で有効な応答を理解します。
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 a '1.1' value and SHOULD try supplying alternate version numbers if they receive a 'server-error-version-not-supported' error return in a response.
1. クライアントは、「1.1」値を持つ「バージョン番号」パラメーターを含むリクエストを送信する必要があり、「サーバーエラーバージョンのサポートされていない」エラーリターンを受信した場合、代替バージョン番号を提供する必要があります。
2. IPP objects 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. It is recommended that IPP objects accept any request with the major version '1' (or reject the request for reasons other than 'server-error-version-not-supported'). See [RFC2911] "versions" sub-section.
3. IPPオブジェクトは、メジャーバージョン「1」でリクエストを受け入れることをお勧めします（または、「サーバーエラーバージョンなし」以外の理由でリクエストを拒否します）。[RFC2911]「バージョン」サブセクションを参照してください。
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/1.1 conforming Printer object accepts version '1.0' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.0' request.
4. いずれにせよ、クライアントがリクエストに低い「バージョン番号」パラメーターを提供する場合、セキュリティを妥協してはなりません。たとえば、IPP/1.1の適合プリンターオブジェクトがバージョン '1.0'リクエストを受け入れ、ダイジェスト認証を強制するように構成されている場合、バージョン '1.0'リクエストでも同じことを行う必要があります。
The following are rules regarding security, the "version-number" parameter, and the URL scheme supplied in target attributes and responses:
以下は、セキュリティ、「バージョン番号」パラメーター、およびターゲット属性と応答で提供されるURLスキームに関するルールです。
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. クライアントがリクエストを提供する場合、「プリンター-URI」または「ジョブURI」ターゲット操作属性は、「プリンター-RIがサポートする」プリンター属性の値の1つに示されているスキームと同じスキームを持つ必要があります。
2. When the server returns the "job-printer-uri" or "job-uri" Job Description attributes, it SHOULD return the same scheme ('ipp', 'https', 'http', 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 server 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」、「HTTPS」、「HTTP」など）を返す必要があります。ジョブが作成されたときに使用されるスキームではなく、get-job-aTtributesまたはget-jobsリクエストの「プリンタウリ」または「ジョブURI」ターゲット操作属性。ただし、クライアントがget-job-attributesまたはget-jobs操作を使用してジョブ属性を要求する場合、サーバーが返すジョブとジョブの属性は次のものに依存します。（1）ジョブが作成されたときに有効なセキュリティ、（2）クエリリクエストで有効なセキュリティ、および（3）有効なセキュリティポリシー。
3. It is recommended that if a server registers a non-secure ipp-URL with a directory service (see [RFC2911] "Generic Directory Schema" Appendix), then it also register an http-URL for interoperability with IPP/1.0 clients (see section 9).
3. サーバーがディレクトリサービスを使用して非セキュアIPP-URLを登録する場合（[RFC2911]「一般的なディレクトリスキーマ」付録を参照）、IPP/1.0クライアントとの相互運用性のためにHTTP-URLを登録することをお勧めします（セクションを参照9）。
4. In any case, security MUST NOT be compromised when a client supplies an 'http' or other non-secure URL scheme in the target "printer-uri" and "job-uri" operation attributes in a request.
4. いずれにせよ、クライアントがターゲット「プリンター-URI」および「ジョブURI」操作に「HTTP」またはその他の非セキュアURLスキームをリクエストに属する場合、セキュリティを妥協してはなりません。
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[DPA] ISO/IEC 10175ドキュメント印刷アプリケーション（DPA）、1996年6月。
[iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
[IANA]コード化された文字セットのIANAレジストリ：ftp：//ftp.isi.edu/in-notes/iana/assignments/character-sets。
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-CON] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: Implementer's Guide", Work in Progress.
[IPP-IIG] Hastings、Tom、et al。、「Internet Printing Protocol/1.1：実装ガイド」、作業進行中。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October, 1989.
[RFC1123] Braden、S。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol", RFC 1179, August 1990.
[RFC1179] McLaughlin、L。III、（編集者）、「Line Printer Daemon Protocol」、RFC 1179、1990年8月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759]スミス、R。、ライト、F。、ヘイスティングス、T。、Zilles、S。、およびJ. Gyllenskog、「プリンターMIB」、RFC 1759、1995年3月。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RFC1808]フィールディング、R。、「相対均一な資源ロケーター」、RFC 1808、1995年6月。
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「シンプルネットワーク管理プロトコル（SNMPV2）のバージョン2のテキストコンベンション」、RFC 1903、1996年1月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048] Freed、N.、Klensin、J。、J。Postel、「多目的インターネットメール拡張（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[RFC2184] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、および継続」、RFC 2184、1997年8月。
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP.全体的に、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246. January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコル」、RFC 2246。1999年1月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565] Herriot、R。、Butler、S.、Moore、P。、およびR. Turner、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] Debry、R.、Hastings、T.、Herriot、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2566、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC2567, April 1999.
[RFC2567] Wright、D。、「インターネット印刷プロトコルの設計目標」、RFC2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S。、「インターネット印刷プロトコルの構造とモデルとプロトコルの理論的根拠」、RFC 2568、1999年4月。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569] Herriot、R.、Hastings、T.、Jacobs、N。およびJ. Martin、「LPDとIPPプロトコルのマッピング」、RFC 2569、1999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners -Lee、 "Hypertext Transfer Protocol -HTTP/1.1"、RFC2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R。およびS. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910] Herriot、R。、Butler、S.、Moore、P.、Turner、R。、およびJ. Wenn、「インターネット印刷プロトコル/1.1：エンコーディングとトランスポート」、RFC 2910、2000年9月。
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
[RFC2911] Hastings、T.、Herriot、R.、Debry、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.1：モデルとセマンティクス」、RFC 2911、2000年9月。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
[SSL] Netscape、The SSLプロトコル、バージョン3、（テキストバージョン3.02）、1996年11月。
Robert Herriot, Editor Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Robert Herriot、編集者Xerox Corporation 3400 Hillview Ave.、Bldg＃1 Palo Alto、CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: robert.herriot@pahv.xerox.com
電話：650-813-7696ファックス：650-813-6860メール：robert.herriot@pahv.xerox.com
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd. Boise, ID 83714
Sylvan Butler Hewlett-Packard 11311 Chinden Blvd.ボイジー、ID 83714
Phone: 208-396-6000 Fax: 208-396-3457 EMail: sbutler@boi.hp.com
電話：208-396-6000ファックス：208-396-3457メール：sbutler@boi.hp.com
Paul Moore Peerless Systems Networking 10900 NE 8th St #900 Bellevue, WA 98004
Paul Moore Peerless Systems Networking 10900 NE 8th St＃900 Bellevue、WA 98004
Phone: 425-462-5852 EMail: pmoore@peerless.com Randy Turner 2Wire, Inc. 694 Tasman Dr. Milpitas, CA 95035
電話：425-462-5852メール：pmoore@peerless.com Randy Turner 2wire、Inc。694 Tasman Dr. Milpitas、CA 95035
Phone: 408-546-1273
電話：408-546-1273
John Wenn Xerox Corporation 737 Hawaii St El Segundo, CA 90245
John Wenn Xerox Corporation 737 Hawaii St El Segundo、CA 90245
Phone: 310-333-5764 Fax: 310-333-5514 EMail: jwenn@cp10.es.xerox.com
電話：310-333-5764 FAX：310-333-5514メール：jwenn@cp10.es.xerox.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email: 1) send it to majordomo@pwg.org 2) leave the subject line blank 3) put the following two lines in the message body: subscribe ipp end
IPPメーリングリストを購読するには、次のメールを送信します。1）majordomo@pwg.orgに送信します2）件名を空白のままにしてください3）次の2行をメッセージ本文に入れます：ipp endを購読する
12. Other Participants:
12. 他の参加者：
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Information Systems
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Systems
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Canon Information Lloyd Young - Lexmark
Systems
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang - Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems
The following is an example of a Print-Job request with job-name, copies, and sides specified. The "ipp-attribute-fidelity" attribute is set to 'true' so that the print request will fail if the "copies" or the "sides" attribute are not supported or their values are not supported.
以下は、ジョブ名、コピー、および指定された側面を含む印刷ジョブリクエストの例です。「IPP-Attribute-Fidelity」属性は「True」に設定されているため、「コピー」または「サイド」属性がサポートされていないか、その値がサポートされていない場合、印刷要求が失敗します。
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0002 Print-Job operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- name
natural- attributes-natural-language
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x42 nameWithoutLanguage type value-tag
0x0008 name-length
job-name job-name name
0x0006 value-length
foobar foobar value
0x22 boolean type value-tag
0x0016 name-length
ipp-attribute- ipp-attribute-fidelity name
fidelity
0x0001 value-length
0x01 true value
Octets Symbolic Value Protocol field
0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x44 keyword type value-tag
0x0005 name-length
sides sides name
0x0013 value-length
two-sided- two-sided-long-edge value
long-edge
0x03 end-of-attributes end-of-attributes-tag
%!PS... <PostScript> data
Here is an example of a successful Print-Job response to the previous Print-Job request. The printer supported the "copies" and "sides" attributes and their supplied values. The status code returned is 'successful-ok'.
以下は、以前の印刷ジョブリクエストに対する印刷ジョブの応答が成功した例です。プリンターは、「コピー」と「サイド」属性とその提供された値をサポートしました。返されるステータスコードは「成功した」です。
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0000 successful-ok status-code
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
natural-language language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
Octets Symbolic Value Protocol field
successful-ok successful-ok value
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
0x0019 value-length
ipp://forest/ job 123 on pinetree value
pinetree/123
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).
以下は、以前の印刷ジョブリクエストに対する印刷とジョブの応答に失敗した例です。この場合、プリンターは「サイド」属性をサポートしておらず、「コピー」属性の値「20」がサポートされていないために失敗します。したがって、ジョブは作成されず、「ジョブID」も「ジョブURI」操作属性も返されません。返されるエラーコードは、「クライアントエラーアトトリビュースターまたはバリュー - サポートされていない」（0x040b）です。
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- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
Octets Symbolic Value Protocol field
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status- status-message name
message
0x002F value-length
client-error- value
attributes- values-not-supported
or-values- client-error-attributes-or-
not-supported
0x05 start unsupported-attributes unsupported-attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x03 end-of-attributes end-of-attributes-tag
Here is an example of a successful Print-Job response to a Print-Job request like the previous Print-Job request, except that the value of 'ipp-attribute-fidelity' is false. The print request succeeds, even though, in this case, the printer supports neither the "sides" attribute nor the value '20' for the "copies" attribute. Therefore, a job is created, and both a "job-id" and a "job-uri" operation attribute are returned. The unsupported attributes are also returned in an Unsupported Attributes Group. The error code returned is 'successful-ok-ignored-or-substituted-attributes' (0x0001).
「IPP-Attribute-Fideity」の値が虚偽であることを除いて、以前の印刷ジョブ要求のような印刷ジョブ要求に対する印刷ジョブの応答が成功した例を次に示します。この場合、プリンターは「コピー」属性の「側面」属性も「20」属性もサポートしていない場合でも、印刷要求が成功します。したがって、ジョブが作成され、「ジョブID」と「job-uri」操作属性の両方が返されます。サポートされていない属性は、サポートされていない属性グループでも返されます。返されたエラーコードは、「成功したOK-Inored-or-Stituted-aTtributes」（0x0001）です。
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0001 successful-ok-ignored-or- status-code
Octets Symbolic Value Protocol field
substituted-attributes
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
natural-language language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x002F value-length
successful-ok- successful-ok-ignored-or- value
ignored-or- substituted-attributes
substituted-
attributes
0x05 start unsupported- unsupported-attributes
attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x45 uri type value-tag
0x0007 name-length
job-uri job-uri name
0x0019 value-length
ipp://forest/ job 123 on pinetree value
pinetree/123
Octets Symbolic Value Protocol field
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:
以下は、コピーとジョブ名のパラメーターを使用した印刷物リクエストの例です。
Octets Symbolic Value Protocol field
オクテットシンボリック値プロトコルフィールド
0x0101 1.1 version-number
0x0003 Print-URI operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x45 uri type value-tag
0x000C name-length
document-uri document-uri name
0x0011 value-length
ftp://foo.com ftp://foo.com/foo value
Octets Symbolic Value Protocol field
/foo
0x42 nameWithoutLanguage type value-tag
0x0008 name-length
job-name job-name name
0x0006 value-length
foobar foobar value
0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000001 1 value
0x03 end-of-attributes end-of-attributes-tag
The following is an example of Create-Job request with no parameters and no attributes:
以下は、パラメーターも属性もないCreate-Job要求の例です。
Octets Symbolic Value Protocol field
オクテットシンボリック値プロトコルフィールド
0x0101 1.1 version-number
0x0005 Create-Job operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
Octets Symbolic Value Protocol field
オクテットシンボリック値プロトコルフィールド
inetree
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
0x0101 1.1 version-number
0x000A Get-Jobs operation-id
0x00000123 0x123 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x21 integer type value-tag
0x0005 name-length
limit limit name
0x0004 value-length
0x00000032 50 value
0x44 keyword type value-tag
0x0014 name-length
requested- requested-attributes name
attributes
0x0006 value-length
Octets Symbolic Value Protocol field
job-id job-id value
0x44 keyword type value-tag
0x0000 additional value name-length
0x0008 value-length
job-name job-name value
0x44 keyword type value-tag
0x0000 additional value name-length
0x000F value-length
document-format document-format value
0x03 end-of-attributes end-of-attributes-tag
The following is an of Get-Jobs response from previous request with 3 jobs. The Printer returns no information about the second job (because of security reasons):
以下は、3つのジョブを含む以前のリクエストからのGet-Jobsの応答です。プリンターは、2番目のジョブに関する情報を返しません（セキュリティ上の理由により）：
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed
back)
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x000A value-length
ISO-8859-1 ISO-8859-1 value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes (1st job-attributes-tag
Octets Symbolic Value Protocol field
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x000C value-length
0x0005 sub-value-length
fr-ca fr-CA value
0x0003 sub-value-length
fou fou name
0x02 start job-attributes (2nd job-attributes-tag
object)
0x02 start job-attributes (3rd job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
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
14. Appendix B: Registration of MIME Media Type Information for "application/ipp"
14. 付録B：「アプリケーション/IPP」のMIMEメディアタイプ情報の登録
This appendix contains the information that IANA requires for registering a MIME media type. The information following this paragraph will be forwarded to IANA to register application/ipp whose contents are defined in Section 3 "Encoding of the Operation Layer" in this document:
この付録には、IANAがMIMEメディアタイプを登録するために必要な情報が含まれています。この段落に続く情報は、このドキュメントのセクション3「操作レイヤーのエンコード」で内容が定義されているアプリケーション/IPPを登録するためにIANAに転送されます。
MIME type name: application
MIMEタイプ名：アプリケーション
MIME subtype name: ipp A Content-Type of "application/ipp" indicates an Internet Printing Protocol message body (request or response). Currently there is one version: IPP/1.1, whose syntax is described in Section 3 "Encoding of the Operation Layer" of [RFC2910], and whose semantics are described in [RFC2911].
MIMEサブタイプ名：IPP「Application/IPP」のコンテンツタイプは、インターネット印刷プロトコルメッセージ本文（リクエストまたは応答）を示します。現在、1つのバージョンがあります。IPP/1.1。その構文は[RFC2910]のセクション3「動作層のエンコード」で説明されており、セマンティクスは[RFC2911]で説明されています。
Required parameters: none
必要なパラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations:
考慮事項のエンコード：
IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS contain binary data (for example attribute value lengths).
IPP/1.1プロトコル要求/応答には、長い行が含まれており、常にバイナリデータ（属性値の長さなど）が含まれている場合があります。
Security considerations:
セキュリティ上の考慮事項：
IPP/1.1 protocol requests/responses do not introduce any security risks not already inherent in the underlying transport protocols. Protocol mixed-version interworking rules in [RFC2911] as well as protocol encoding rules in [RFC2910] are complete and unambiguous.
IPP/1.1プロトコル要求/応答は、基礎となる輸送プロトコルにまだ固有のセキュリティリスクを導入しません。[RFC2911]のプロトコルの混合バージョンインターワーキングルールと、[RFC2910]のプロトコルエンコードルールは完全かつ明確です。
Interoperability considerations:
相互運用性の考慮事項：
IPP/1.1 requests (generated by clients) and responses (generated by servers) MUST comply with all conformance requirements imposed by the normative specifications [RFC2911] and [RFC2910]. Protocol encoding rules specified in [RFC2910] are comprehensive, so that interoperability between conforming implementations is guaranteed (although support for specific optional features is not ensured). Both the "charset" and "natural-language" of all IPP/1.1 attribute values which are a LOCALIZED-STRING are explicit within IPP protocol requests/responses (without recourse to any external information in HTTP, SMTP, or other message transport headers).
IPP/1.1リクエスト（クライアントによって生成）および応答（サーバーによって生成）は、規範的仕様[RFC2911]および[RFC2910]によって課されるすべての適合要件に準拠する必要があります。[RFC2910]で指定されたプロトコルエンコードルールは包括的であるため、適合実装間の相互運用性が保証されます（ただし、特定のオプション機能のサポートは保証されていません）。ローカライズされたストリングであるすべてのIPP/1.1属性値の「charset」と「natural-language」の両方は、IPPプロトコル要求/応答内で明示的です（HTTP、SMTP、またはその他のメッセージトランスポートヘッダーの外部情報に頼ることなく）。
Published specifications:
公開された仕様：
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
[RFC2911] Hastings、T.、Herriot、R.、Debry、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.1：モデルとセマンティクス」、RFC 2911、2000年9月。
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2910] Herriot、R。、Butler、S.、Moore、P.、Turner、R。、およびJ. Wenn、「インターネット印刷プロトコル/1.1：エンコーディングとトランスポート」、RFC 2910、2000年9月。
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Internet Printing Protocol (IPP) print clients and print servers, communicating using HTTP/1.1 (see [RFC2910]), SMTP/ESMTP, FTP, or other transport protocol. Messages of type "application/ipp" are self-contained and transport-independent, including "charset" and "natural-language" context for any LOCALIZED-STRING value.
インターネット印刷プロトコル（IPP）は、クライアントと印刷サーバーを印刷し、HTTP/1.1（[RFC2910]を参照）、SMTP/ESMTP、FTP、またはその他の輸送プロトコルを使用して通信します。タイプ「Application/IPP」のメッセージは、ローカライズされた弦の値に対する「Charset」および「自然言語」コンテキストを含む、自己完結型および輸送に依存しません。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Tom Hastings Xerox Corporation 737 Hawaii St. ESAE-231 El Segundo, CA
トムヘイスティングスゼロックスコーポレーション737ハワイセントエサエ231エルセグンド、カリフォルニア
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
電話：310-333-6413ファックス：310-333-5514メール：hastings@cp10.es.xerox.com
or
または又はそれとも若しくは乃至或るいは
Robert Herriot Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Robert Herriot Xerox Corporation 3400 Hillview Ave.、Bldg＃1 Palo Alto、CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: robert.herriot@pahv.xerox.com
電話：650-813-7696ファックス：650-813-6860メール：robert.herriot@pahv.xerox.com
Intended usage:
意図された使用法：
COMMON
一般
IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
IPP/1.1は、IPP/1.0 [RFC2565]と同一です。
1. Attributes values that identify a printer or job object use a new 'ipp' scheme. The 'http' and 'https' schemes are supported only for backward compatibility. See section 5.
1. プリンターまたはジョブオブジェクトを識別する属性値は、新しい「IPP」スキームを使用します。「HTTP」および「HTTPS」スキームは、後方互換性のためにのみサポートされています。セクション5を参照してください。
2. Clients MUST support of Digest Authentication, IPP Printers SHOULD support Digest Authentication. See Section 8.1.1
2. クライアントはダイジェスト認証をサポートする必要があり、IPPプリンターはダイジェスト認証をサポートする必要があります。セクション8.1.1を参照してください
3. TLS is recommended for channel security. In addition, SSL3 may be supported for backward compatibility. See Section 8.1.2
3. TLSはチャネルセキュリティに推奨されます。さらに、SSL3は後方互換性のためにサポートされる場合があります。セクション8.1.2を参照してください
4. It is recommended that IPP/1.1 objects accept any request with major version number '1'. See section 9.1.
4. IPP/1.1オブジェクトは、メジャーバージョン番号「1」でリクエストを受け入れることをお勧めします。セクション9.1を参照してください。
5. IPP objects SHOULD return the URL scheme requested for "job-printer-uri" and "job-uri" Job Attributes, rather than the URL scheme used to create the job. See section 9.2.
5. IPPオブジェクトは、ジョブを作成するために使用されるURLスキームではなく、「ジョブプリンター-RI」および「ジョブURI」ジョブ属性の要求されたURLスキームを返す必要があります。セクション9.2を参照してください。
6. The IANA and Internationalization sections have been added. The terms "private use" and "experimental" have been changed to "vendor extension". The reserved allocations for attribute group tags, attribute syntax tags, and out-of-band attribute values have been clarified as to which are reserved to future IETF standards track documents and which are reserved to vendor extension. Both kinds of extensions use the type2 registration procedures as defined in [RFC2911].
6. IANAおよび国際化セクションが追加されました。「プライベート使用」と「実験的」という用語は、「ベンダー拡張」に変更されました。属性グループタグ、属性構文タグ、および帯域外の属性値の予約された割り当ては、将来のIETF標準の追跡ドキュメントに予約され、ベンダー拡張に予約されているものについて明確にされています。両方の種類の拡張機能は、[RFC2911]で定義されているタイプ2登録手順を使用します。
7. Clarified that future "out-of-band" value definitions may use the value field if additional information is needed.
7. 追加情報が必要な場合、将来の「バンド外」値の定義が値フィールドを使用する可能性があることを明らかにしました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。