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