Network Working Group T. Hastings
Request for Comments: 3196 C. Manros
Obsoletes: 2639 P. Zehler
Category: Informational Xerox Corporation
C. Kugler
IBM Printing Systems Co
H. Holst
i-data Printing Systems
November 2001
Internet Printing Protocol/1.1: Implementor's Guide
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).
この文書は、一緒に新しいインターネット印刷プロトコル（IPP）のすべての側面を記述した文書のセットの1つです。
Table of Contents
目次
1 Introduction................................................... 4
1.1 Conformance language........................................ 5
1.2 Other terminology........................................... 6
1.3 Issues Raised from Interoperability Testing Events.......... 6
2 IPP Objects.................................................... 6
3 IPP Operations................................................. 7
3.1 Common Semantics............................................ 7
3.1.1 Summary of Operation Attributes............................ 8
3.1.2 Suggested Operation Processing Steps for IPP Objects....... 16
3.1.2.1 Suggested Operation Processing Steps for all Operations. 17
3.1.2.1.1 Validate version number............................... 18
3.1.2.1.2 Validate operation identifier......................... 20
3.1.2.1.3 Validate the request identifier....................... 20
3.1.2.1.4 Validate attribute group and attribute presence and
order................................................. 20
3.1.2.1.4.1 Validate the presence and order of attribute groups. 20
3.1.2.1.4.2 Ignore unknown attribute groups in the expected
position............................................ 21
3.1.2.1.4.3 Validate the presence of a single occurrence of
required Operation attributes....................... 21
3.1.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................ 29
3.1.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................ 33
3.1.2.2 Suggested Additional Processing Steps for Operations
that Create/Validate Jobs and Add Documents............. 37
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
3.1.2.2.3 Validate the values of the Job Template attributes.... 38
3.1.2.3 Algorithm for job validation............................ 39
3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
3.1.2.3.2 Decide whether to REJECT the request.................. 46
3.1.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes.................................. 48
3.1.2.3.4 Create the Job object with attributes to support...... 48
3.1.2.3.5 Return one of the success status codes................ 50
3.1.2.3.6 Accept appended Document Content...................... 50
3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
3.1.2.3.8 Completing the Job.................................... 50
3.1.2.3.9 Destroying the Job after completion................... 51
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
3.1.2.3.11 Character set code conversion support................. 51
3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?....... ....................... 52
3.1.2.3.13 Natural Language Override (NLO)....................... 53
3.1.3 Status codes returned by operation......................... 55
3.1.3.1 Printer Operations...................................... 55
3.1.3.1.1 Print-Job............................................. 55
3.1.3.1.2 Print-URI............................................. 58
3.1.3.1.3 Validate-Job.......................................... 58
3.1.3.1.4 Create-Job............................................ 58
3.1.3.1.5 Get-Printer-Attributes................................ 59
3.1.3.1.6 Get-Jobs.............................................. 60
3.1.3.1.7 Pause-Printer......................................... 61
3.1.3.1.8 Resume-Printer........................................ 62
3.1.3.1.8.1 What about Printers unable to change state due to
an error condition?................................. 63
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
3.1.3.1.9 Purge-Printer......................................... 63
3.1.3.2 Job Operations.......................................... 64
3.1.3.2.1 Send-Document......................................... 64
3.1.3.2.2 Send-URI.............................................. 65
3.1.3.2.3 Cancel-Job............................................ 65
3.1.3.2.4 Get-Job-Attributes.................................... 67
3.1.3.2.5 Hold-Job.............................................. 68
3.1.3.2.6 Release-Job........................................... 69
3.1.3.2.7 Restart-Job........................................... 69
3.1.3.2.7.1 Can documents be added to a restarted job?.......... 69
3.1.4 Returning unsupported attributes in Get-Xxxx responses
(Issue 1.18)............................................... 70
3.1.5 Sending empty attribute groups............................. 70
3.2 Printer Operations.......................................... 71
3.2.1 Print-Job operation........................................ 71
3.2.1.1 Flow controlling the data portion of a Print-Job
request (Issue 1.22).................................... 71
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
3.2.2 Get-Printer-Attributes operation........................... 72
3.2.3 Get-Jobs operation......................................... 72
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
(Issue 1.39)?.......................................... 72
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
operation?.............................................. 73
3.2.4 Create-Job operation....................................... 73
3.3 Job Operations.............................................. 74
3.3.1 Validate-Job............................................... 74
3.3.2 Restart-Job................................................ 74
4 Object Attributes.............................................. 74
4.1 Attribute Syntax's.......................................... 74
4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
4.2 Job Template Attributes..................................... 76
4.2.1 multiple-document-handling(type2 keyword).................. 76
4.2.1.1 Support of multiple document jobs....................... 76
4.3 Job Description Attributes.................................. 76
4.3.1 Getting the date and time of day........................... 76
4.4 Printer Description Attributes.............................. 77
4.4.1 queued-job-count (integer(0:MAX)).......................... 77
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
4.4.1.2 Is "queued-job-count" a good measure of how busy a
printer is (Issue 1.15)?................................ 77
4.4.2 printer-current-time (dateTime)............................ 78
4.4.3 Printer-uri................................................ 78
4.5 Empty Jobs.................................................. 79
5 Directory Considerations....................................... 79
5.1 General Directory Schema Considerations..................... 79
5.2 IPP Printer with a DNS name................................. 79
6 Security Considerations........................................ 80
6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32)........................... 80
7 Encoding and Transport......................................... 81
7.1 General Headers............................................. 83
7.2 Request Headers............................................ 84
7.3 Response Headers............................................ 86
7.4 Entity Headers............................................. 87
7.5 Optional support for HTTP/1.0............................... 88
7.6 HTTP/1.1 Chunking........................................... 88
7.6.1 Disabling IPP Server Response Chunking..................... 88
7.6.2 Warning About the Support of Chunked Requests.............. 88
8 References..................................................... 89
9 Authors' Addresses............................................. 91
10 Description of the Base IPP Documents.......................... 94
11 Full Copyright Statement....................................... 96
Tables
テーブル
Table 1 - Summary of Printer operation attributes that sender MUST
supply ................................................. 8
Table 2 - Summary of Printer operation attributes that sender MAY
supply ................................................. 10
Table 3 - Summary of Job operation attributes that sender MUST
supply.................................................. 12
Table 4 - Summary of Job operation attributes that sender MAY
supply.................................................. 14
Table 5 - Printer operation response attributes................... 16
Table 6 - Examples of validating IPP version...................... 19
Table 7 - Rules for validating single values X against Z.......... 40
IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. It is intended to help implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may assist them in the design of their client and/or IPP object implementation. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
IPPは、インターネットツールと技術を使用して、分散印刷のために使用することができるアプリケーションレベルのプロトコルです。この文書では、IPPモデルと意味論[RFC2911]とIPP交通エンコーディング[RFC2910]の文書を補足する情報が含まれています。実装がIPP / 1.1と同様に、IPP / 1.0 [RFC2565、RFC2566]、そして彼らのクライアントおよび/またはIPPオブジェクト実装のデザインでそれらを支援することが検討事項のいくつかを理解するためのものです。例えば、処理要求の典型的な順序は、エラー・チェックを含む、与えられます。仕様決定のいくつかのための動機も含まれています。
This document obsoletes RFC 2639 which was the Implementor's Guide for IPP/1.0. The IPP Implementor's Guide (IIG) (this document) contains information that supplements the IPP Model and Semantics [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. This document is just one of a suite of documents that fully define IPP. The base set of IPP documents includes:
この文書では、IPP / 1.0のための開発者のためのガイドだったRFC 2639を廃止します。 IPP開発者のためのガイド（IIG）（本書）は、IPPモデルと意味論[RFC2911]とIPP交通エンコーディング[RFC2910]の文書を補足する情報が含まれています。この文書では、ちょうど完全にIPPを定義する文書のスイートのひとつです。 IPP文書の基本セットが含まれています：
Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568]
インターネット印刷プロトコル[RFC2568]のための構造とモデルとプロトコルのためのインターネット印刷プロトコル[RFC2567]原理の設計目標
Internet Printing Protocol/1.1: Model and Semantics [RFC2911] Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] Internet Printing Protocol/1.1: Implementor's Guide (this document) Mapping between LPD and IPP Protocols [RFC2569]
インターネット印刷プロトコル/ 1.1：モデルと意味論[RFC2911]インターネット印刷プロトコル/ 1.1：コード化と輸送[RFC2910]インターネット印刷プロトコル/ 1.1：開発者のためのガイド（本書）LPDとIPPプロトコル[RFC2569]の間のマッピング
See section 10 for a description of these base IPP documents. Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order.
これらのベースIPPドキュメントの説明については、セクション10を参照してください。初めてこれらの文書を読んで誰もが強く、上記の順序でIPP文書を読むことを奨励しています。
As such the information in this document is not part of the formal specification of IPP/1.1. Instead information is presented to help implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565, RFC2566], including some of the motivation for decisions taken by the committee in developing the specification. Some of the implementation considerations are intended to help implementers design their client and/or IPP object implementations. If there are any contradictions between this document and [RFC2911] or [RFC2910], those documents take precedence over this document.
この文書に記載されているような情報としてはIPP / 1.1の正式な仕様の一部ではありません。代わりに、情報は、実装者が仕様を開発する際に委員会によって行われた決定のための動機の一部を含め、IPP / 1.1と同様に、IPP / 1.0 [RFC2565、RFC2566]を理解するために提示されます。実装上の考慮事項の一部は、実装が彼らのクライアントおよび/またはIPPオブジェクト実装の設計を支援することを意図しています。このドキュメントと[RFC2911]か[RFC2910]の間に何らかの矛盾がある場合は、それらの文書は、この文書に優先します。
Platform-specific implementation considerations will be included in this guide as they become known.
彼らは、既知になるようなプラットフォーム固有の実装の考慮事項は、このガイドに含まれます。
Note: In order to help the reader of the IIG and the IPP Model and Semantics document, the sections in this document parallel the corresponding sections in the Model document and are numbered the same for ease of cross reference. The sections that correspond to the IPP Transport and Encoding are correspondingly offset.
注：IIGとIPPモデル及びセマンティクス文書の読者を助けるために、このドキュメントのセクションでは、モデルドキュメントの対応するセクションに平行であり、相互参照を容易にするために同じ番号が付されています。 IPP輸送とエンコーディングに対応セクションが相応にオフセットされています。
Usually, this document does not contain the terminology MUST, MUST NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, when those terms do appear in this document, their intent is to repeat what the [RFC2911] and [RFC2910] documents require and allow, rather than specifying additional conformance requirements. These terms are defined in section 12 on conformance terminology in [RFC2911], most of which is taken from RFC 2119 [RFC2119].
通常、MUSTは、NOT MUST用語、MAYが含まれていないこの文書では、SHOULD、SHOULD、REQUIRED、およびオプションではない、する必要はありません。それらの用語は、本文書に表示されないときしかし、彼らの意図ではなく、追加の適合性要件を指定するよりも、[RFC2911]と[RFC2910]の文書が必要で何を繰り返してできるようにすることです。これらの用語は[RFC2911]に順応用語のセクション12で定義され、そのほとんどは、RFC 2119 [RFC2119]から取られます。
Implementers should read section 12 (APPENDIX A) in [RFC2911] in order to understand these capitalized words. The words MUST, MUST NOT, and REQUIRED indicate what implementations are required to support in a client or IPP object in order to be conformant to [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed as an implementer option. The verbs SHOULD and SHOULD NOT indicate suggested behavior, but which is not required or disallowed, respectively, in order to conform to the specification.
実装は、これらの大文字の単語を理解するために[RFC2911]セクション12（付録A）を読んでください。言葉は、NOT MUST MUST、およびREQUIREDは、[RFC2911]と[RFC2910]に準拠するために、クライアントやIPPオブジェクトでサポートするために必要なものを実装を示しています。 MAYは、必要はなく、オプションは単に実装オプションとして許可されたことを示します。動詞はと提案行動を示しすべきでないが、仕様に準拠するためには、それぞれ、必須または禁止されていません。
This document uses other terms, such as "attributes", "operation", and "Printer" as defined in [RFC2911] section 12. In addition, the term "sender" refers to the client that sends a request or an IPP object that returns a response. The term "receiver" refers to the IPP object that receives a request and to a client that receives a response.
また、[RFC2911]セクション12で定義されるように、この文書は、「属性」、「操作」として、他の用語を使用し、「プリンタ」という用語は、「送信者」はその要求またはIPPオブジェクトを送信するクライアントを指し応答を返します。用語「受信機」は、要求を受信し、応答を受信したクライアントにIPPオブジェクトを指します。
The IPP WG has conducted three open Interoperability Testing Events. The first one was held in September 1998, the second one was held in March 1999, and the third one was held in October 2000. See the summary reports in:
IPP WGは、3つのオープン相互運用性テストイベントを実施しています。最初の1は、1998年9月に開催された、二つ目は、中サマリーレポートを参照してください。1999年3月に開催された、そして3つ目は2000年10月に開催されました：
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
ｆｔｐ：／／ｆｔｐ。ｐｗｇ。おｒｇ／ぷｂ／ｐｗｇ／いっｐ／ねｗ＿てＳ／
The issues raised from the first Interoperability Testing Event are numbered 1.n in this document and have been incorporated into "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and Transport" [RFC2565] documents. However, some of the discussion is left here in the Implementor's Guide to help understanding.
最初の相互運用性テストイベントから提起された問題は、この文書で1.nの番号が付けられていますし、「IPP / 1.0モデルと意味論」[RFC2566]および「IPP / 1.0コード化とTransport」[RFC2565]の文書に組み込まれています。しかし、議論のいくつかは、理解を助けるためにここに開発者のためのガイドで残されています。
The issues raised from the second Interoperability Testing Event are numbered 2.n in this document have been incorporated into "IPP/1.1 Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and Transport" [RFC2910] documents. However, some of the discussion is left here in the Implementor's Guide to help understanding.
二相互運用性テストイベントから提起された問題は、この文書の2.nは、「IPP / 1.1モデルと意味論」[RFC2911]および「IPP / 1.1コード化とTransport」[RFC2910]の文書に組み込まれている番号が付けられています。しかし、議論のいくつかは、理解を助けるためにここに開発者のためのガイドで残されています。
The issues raised from the third Interoperability Testing Event are numbered 3.n in this document and are described in:
第三相互運用性テストイベントから提起された問題は、この文書で3.nの番号が付けられていますし、中に記述されています。
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf
ｆｔｐ：／／ｆｔｐ。ｐｗｇ。おｒｇ／ぷｂ／ｐｗｇ／いっｐ／いっすえｓ／いっすえｓーらいせｄーあｔーばけーおっｆ３。ｐｄｆ
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc
ｆｔｐ：／／ｆｔｐ。ｐｗｇ。おｒｇ／ぷｂ／ｐｗｇ／いっｐ／いっすえｓ／いっすえｓーらいせｄーあｔーばけーおっｆ３。どｃ
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
ｆｔｐ：／／ｆｔｐ。ｐｗｇ。おｒｇ／ぷｂ／ｐｗｇ／いっｐ／いっすえｓ／いっすえｓーらいせｄーあｔーばけーおっｆ３。ｔｘｔ
The term "client" in IPP is intended to mean any client that issues IPP operation requests and accepts IPP operation responses, whether it be a desktop or a server. In other words, the term "client" does not just mean end-user clients, such as those associated with desktops.
IPPにおける用語「クライアント」は、それはデスクトップやサーバであるかどうか、IPP操作要求を発行し、IPP操作応答を受け入れるすべてのクライアントを意味することを意図しています。言い換えれば、用語「クライアント」、まさにそのようなデスクトップに関連するものとして、エンドユーザクライアントを意味するものではありません。
The term "IPP Printer" in IPP is intended to mean an object that accepts IPP operation requests and returns IPP operation responses, whether implemented in a server or a device. An IPP Printer object MAY, if implemented in a server, turn around and forward received jobs (and other requests) to other devices and print servers/services, either using IPP or some other protocol.
IPPにおける用語「IPPプリンタは、」IPP操作要求を受け取り、サーバーまたはデバイスに実装するかどうか、IPP操作応答を返すオブジェクトを意味することを意図しています。 IPP PrinterオブジェクトMAYは、サーバーに実装されている場合、振り向くと、他のデバイスとプリントサーバー/サービスを受けたジョブ（および他の要求）を転送し、いずれかのIPPまたはいくつかの他のプロトコルを使用して。
3 IPP Operations
3つのIPP事業
This section corresponds to Section 3 "IPP Operations" in the IPP/1.1 Model and Semantics document [RFC2911].
このセクションでは、IPP / 1.1モデルとセマンティクス文献[RFC2911]に「IPP操作」第3章に対応します。
This section discusses semantics common to all operations.
このセクションでは、すべての操作に共通の意味を説明します。
Table 1 - Summary of Printer operation attributes that sender MUST supply
表1 - プリンタ操作の概要は、送信者が指定する必要のある属性
Printer Operations
プリンタの操作
Requests Responses Operation PJ, PU CJ GPA GJ PP, All Attributes VJ (O) (O) (R) (R) RP, Operations (R) PP (O+)
要求応答操作PJ、PU CJ GPA GJ PP、すべてVJ属性（O）（O）（R）（R）RP、オペレーション（R）PP（O +）
Operation parameters--REQUIRED to be supplied by the sender:
動作パラメータ - 送信者によって供給する必要が：
operation-id R R R R R R
操作ID R R R R R R
status-code R
ステータスコードR
request-id R R R R R R R
要求ID R R R R R R R
version-number R R R R R R R
バージョン番号R R R R R R R
Operation attributes--REQUIRED to be supplied by the sender:
操作属性 - 送信者によって供給する必要が：
attributes- R R R R R R R charset
属性 - R R R R R R R文字セット
attributes- R R R R R R R natural-language
属性 - R R R R R R R自然言語
document-uri R
文書-URI R
job-id*
ジョブID *
job-uri*
仕事-URI *
Printer Operations
プリンタの操作
Requests Responses
要求応答
Operation PJ, PU CJ GPA GJ PP, All Attributes VJ (O) (O) (R) (R) RP, Operations (R) PP (O+) last-document
操作PJ、PU CJ GPA GJ PP、すべてVJ（O）（O）（R）（R）RP、オペレーション（R）PP（O +）最後の文書属性
printer-uri R R R R R R
プリンタ・ウリP P P P P P
Operation attributes--RECOMMENDED to be supplied by the sender:
操作属性 - 送信者によって供給されるように推奨します：
job-name R R R
ジョブ名のR R R
requesting-user- R R R R R R name
要求-USER- R R R R R R名
Legend:
伝説：
PJ, VJ: Print-Job, Validate-Job PU: Print-URI CJ: Create-Job GPA: Get-Printer-Attributes GJ: Get-Jobs PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP.
PJ、VJ：印刷ジョブ、検証-仕事PU：印刷-URI CJ：作成-仕事GPAます。Get-プリンタ-属性GJます。Get-ジョブズPP、RP、PP：一時停止、プリンター、再開、プリンタ、パージ、プリンタRはIPPオブジェクト（プリンタまたはジョブ）によってサポートされなければならない必要な操作を示しています。属性の場合、Rは属性が関連付けられた動作をサポートIPPオブジェクトがサポートしなければならないことを示しています。 OはIPPオブジェクト（プリンタまたはジョブ）によってサポートされるかもしれ任意のオペレーションや属性を示します。 +は、これがIPP / 1.0の機能ではありませんが、唯一のIPP / 1.1とIPPの将来のバージョンの一部であることを示しています。
Table 2 - Summary of Printer operation attributes that sender MAY supply
表2 - プリンタ操作の概要は、送信者が供給してもよいことを属性
Printer Operations
プリンタの操作
Requests Respon-ses Operation Attributes PJ, PU CJ GPA GJ PP, All VJ (O) (O) (R) (R) RP, Opera (R) PP tions (O+)
要求Respon-SES操作はPJ、PU CJ GPA GJ PP、すべてVJ（O）（O）（R）（R）RP属性、オペラ（R）のPPション（O +）
Operation attributes--OPTIONAL to be supplied by the sender:
操作属性 - オプションは、送信者によって供給されます。
status-message O
ステータスメッセージO
detailed-status- O message
メッセージの詳細、ステータス -
document-access- O** error
文書-access- O **エラー
compression R R
圧縮R R
document-format R R R
文書フォーマットR R R
document-name O O
文書名O O
document-natural- O O language
文書-自然なO O言語
ipp-attribute- R R R fidelity
IPP-attribute- R R R忠実
job-impressions O O O
仕事インプレッションO O O
job-k-octets O O O
じょｂーｋーおｃてｔｓ お お お
job-media-sheets O O O
じょｂーめぢあーしぇえｔｓ お お お
Printer Operations
プリンタの操作
Requests Respon-ses Operation Attributes PJ, PU CJ GPA GJ PP, All VJ (O) (O) (R) (R) RP, Opera (R) PP tions (O+)
要求Respon-SES操作はPJ、PU CJ GPA GJ PP、すべてVJ（O）（O）（R）（R）RP属性、オペラ（R）のPPション（O +）
limit R
リミットR
message
メッセージ
my-jobs R
私-ジョブR
requested-attributes R R
R Rは、要求されたアトリビュート
which-jobs R
- ジョブR
Legend:
伝説：
PJ, VJ: Print-Job, Validate-Job PU: Print-URI CJ: Create-Job GPA: Get-Printer-Attributes GJ: Get-Jobs PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP. * "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED. ** "document-access-error" applies to the Print-URI response only.
PJ、VJ：印刷ジョブ、検証-仕事PU：印刷-URI CJ：作成-仕事GPAます。Get-プリンタ-属性GJます。Get-ジョブズPP、RP、PP：一時停止、プリンター、再開、プリンタ、パージ、プリンタRはIPPオブジェクト（プリンタまたはジョブ）によってサポートされなければならない必要な操作を示しています。属性の場合、Rは属性が関連付けられた動作をサポートIPPオブジェクトがサポートしなければならないことを示しています。 OはIPPオブジェクト（プリンタまたはジョブ）によってサポートされるかもしれ任意のオペレーションや属性を示します。 +は、これがIPP / 1.0の機能ではありませんが、唯一のIPP / 1.1とIPPの将来のバージョンの一部であることを示しています。 *「ジョブID」は、対象のジョブを識別するために、「プリンタ-URI」と一緒に使用する場合にのみ必要です。そうでない場合は、「ジョブ-URI」が必要です。 **「ドキュメント・アクセス・エラーが」印刷-URI応答にのみ適用されます。
Table 3 - Summary of Job operation attributes that sender MUST supply
表3 - 仕事の操作の概要は、送信者が指定する必要のある属性
Job Operations
ジョブの操作
Requests Responses Operation SD SU CJ GJA HJ All Attributes (O) (O) (R) (R) RJ, RJ Opera-(O+) tions
要求応答操作SD SU CJ GJA HJすべての属性（O）（O）（R）（R）RJ、RJ Opera-（O +）ション
Operation parameters--REQUIRED to be supplied by the sender:
動作パラメータ - 送信者によって供給する必要が：
operation-id R R R R R
操作ID R R R R R
status-code R
ステータスコードR
request-id R R R R R R
要求ID R R R R R R
version-number R R R R R R
バージョン番号R R R R R R
Operation attributes--REQUIRED to be supplied by the sender:
操作属性 - 送信者によって供給する必要が：
attributes-charset R R R R R R
R R R R R R-文字セット属性
attributes-natural- R R R R R R language
属性は、自然なR R R R R R言語
document-uri R
文書-URI R
job-id* R R R R R
ジョブID * R R R R R
job-uri* R R R R R
仕事-URI * R R R R R
last-document R R
最後に、文書R R
printer-uri R R R R R
プリンタ・ウリP P P P P
Operation attributes--RECOMMENDED to be supplied by the sender:
操作属性 - 送信者によって供給されるように推奨します：
job-name
職種名
Job Operations
ジョブの操作
Requests Responses
要求応答
Operation SD SU CJ GJA HJ All Attributes (O) (O) (R) (R) RJ, RJ Opera-(O+) tions
操作SD SU CJ GJA HJすべての属性（O）（O）（R）（R）RJ、RJ Opera-（O +）ション
requesting-user- R R R R R name
R R R R R名-USER-を要求
Legend:
伝説：
SD: Send-Document SU: Send-URI CJ: Cancel-Job GJA: Get-Job-Attributes HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP. * "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED.
SD：送信-ドキュメントSU：送信-URI CJを：キャンセル-仕事GJA：HJ、RJ、RJは、Get-ジョブ・属性：ホールドジョブ、リリース-仕事を、再起動-求人RはでサポートしなければならないREQUIRED操作を示しIPPオブジェクト（プリンタまたはジョブ）。属性の場合、Rは属性が関連付けられた動作をサポートIPPオブジェクトがサポートしなければならないことを示しています。 OはIPPオブジェクト（プリンタまたはジョブ）によってサポートされるかもしれ任意のオペレーションや属性を示します。 +は、これがIPP / 1.0の機能ではありませんが、唯一のIPP / 1.1とIPPの将来のバージョンの一部であることを示しています。 *「ジョブID」は、対象のジョブを識別するために、「プリンタ-URI」と一緒に使用する場合にのみ必要です。そうでない場合は、「ジョブ-URI」が必要です。
Table 4 - Summary of Job operation attributes that sender MAY supply
表4 - ジョブの動作の概要は、送信者が供給してもよいことを属性
Job Operations
ジョブの操作
Requests Responses
要求応答
Operation SD SU CJ GJA HJ, SD All Attributes (O) (O) (R) (R) RJ, (O) Opera-RJ tions (O+)
操作SD SU CJ GJA HJ、SDすべての属性（O）（O）（R）（R）RJ（O）オペラ-RJのション（O +）
Operation attributes--OPTIONAL to be supplied by the sender:
操作属性 - オプションは、送信者によって供給されます。
status-message O
ステータスメッセージO
detailed-status- O message
メッセージの詳細、ステータス -
document-access- O** error
文書-access- O **エラー
compression R R
圧縮R R
document-format R R
文書フォーマットR R
document-name O O
文書名O O
document-natural- O O language
文書-自然なO O言語
ipp-attribute-fidelity
IPP属性忠実度
job-impressions
仕事インプレッション
job-k-octets
ジョブKオクテット
job-media-sheets
ジョブメディアシート
Job Operations
ジョブの操作
Requests Responses
要求応答
Operation SD SU CJ GJA HJ, SD All Attributes (O) (O) (R) (R) RJ, (O) Opera-RJ tions (O+)
操作SD SU CJ GJA HJ、SDすべての属性（O）（O）（R）（R）RJ（O）オペラ-RJのション（O +）
limit
限定
message O O O
メッセージO O O
job-hold-until R
ジョブホールドまでのR
my-jobs
私、仕事
requested- R attributes
requested- R属性
which-jobs
これは、ジョブ
Legend:
伝説：
SD: Send-Document SU: Send-URI CJ: Cancel-Job GJA: Get-Job-Attributes HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP. * "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED. ** "document-access-error" applies to the Send-URI operation only
SD：送信-ドキュメントSU：送信-URI CJを：キャンセル-仕事GJA：HJ、RJ、RJは、Get-ジョブ・属性：ホールドジョブ、リリース-仕事を、再起動-求人RはでサポートしなければならないREQUIRED操作を示しIPPオブジェクト（プリンタまたはジョブ）。属性の場合、Rは属性が関連付けられた動作をサポートIPPオブジェクトがサポートしなければならないことを示しています。 OはIPPオブジェクト（プリンタまたはジョブ）によってサポートされるかもしれ任意のオペレーションや属性を示します。 +は、これがIPP / 1.0の機能ではありませんが、唯一のIPP / 1.1とIPPの将来のバージョンの一部であることを示しています。 *「ジョブID」は、対象のジョブを識別するために、「プリンタ-URI」と一緒に使用する場合にのみ必要です。そうでない場合は、「ジョブ-URI」が必要です。 **「ドキュメント・アクセス・エラー」の送信-URI操作にのみ適用
Table 5 - Printer operation response attributes
表5 - プリンタの操作レスポンス属性
Printer Operations
プリンタの操作
Response
応答
Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP, Attributes SD (O) SU (O) (R) RP, PP (O+)
操作PJ（R）VJ（R）PU（O）CJ（O）GPA GJ（R）PPは、属性SD（O）SU（O）（R）RP、PP（O +）
job-uri R R R
仕事-URI R R R
job-id R R R
ジョブID R R R
job-state R R R
ジョブの状態R R R
job-state- R+ R+ R+ reasons
ジョブ状態 - R + R + R +の理由
number-of- O O O intervening-jobs
数オブO O O介在-仕事
document- O access-error+
document- Oアクセスエラー
Legend:
伝説：
PJ, SJ: Print-Job, Send-Document VJ: Validate-Job PU, SU: Print-URI, Send-URI CJ: Create-Job GPA: Get-Printer-Attributes GJ: Get-Jobs PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job).
PJ、SJ：印刷ジョブ、送信-ドキュメントVJ：検証・ジョブPU、SU：印刷-URI、送信-URI CJを：GPA-ジョブの作成：GJを取得し、プリンタが-属性：ゲット・ジョブズPP、RP、PP： 、プリンタ一時停止、再開、プリンタ、パージ・プリンタRはIPPオブジェクト（プリンタまたはジョブ）によってサポートされなければならない必要な操作を示しています。属性の場合、Rは属性が関連付けられた動作をサポートIPPオブジェクトがサポートしなければならないことを示しています。 OはIPPオブジェクト（プリンタまたはジョブ）によってサポートされるかもしれ任意のオペレーションや属性を示します。
This section suggests the steps and error checks that an IPP object MAY perform when processing requests and returning responses. An IPP object MAY perform some or all of the error checks. However, some implementations MAY choose to be more forgiving than the error checks shown here, in order to be able to accept requests from non-conforming clients. Not performing all of these error checks is a so-called "forgiving" implementation. On the other hand, clients that successfully submit requests to IPP objects that do perform all the error checks will be more likely to be able to interoperate with other IPP object implementations. Thus an implementer of an IPP object needs to decide whether to be a "forgiving" or a "strict" implementation. Therefore, the error status codes returned may differ between implementations. Consequentially, client SHOULD NOT expect exactly the error code processing described in this section.
このセクションでは、IPPオブジェクトは要求を処理し、応答を返すときに実行できるステップと、エラーチェックを示唆しています。 IPPオブジェクトは、エラーチェックの一部または全部を行ってもよいです。しかし、いくつかの実装は、非準拠のクライアントからの要求を受け入れることができるようにするために、ここに示すエラーチェックよりも寛容であることを選ぶかもしれません。これらのエラーチェックのすべてを実行しないことは、いわゆる「寛容」の実装です。一方、成功したすべてのエラーチェックを実行行うIPPオブジェクトに要求を提出するクライアントは、他のIPPオブジェクト実装と相互運用できるようにする可能性が高くなります。したがって、IPPオブジェクトの実装は、「寛容」または「厳格な」実装するかどうかを決定する必要があります。したがって、エラーステータスコードは実装間で異なることができる返さ。結果的に、クライアントは、まさにこのセクションで説明したエラーコードの処理を期待すべきではありません。
When an IPP object receives a request, the IPP object either accepts or rejects the request. In order to determine whether or not to accept or reject the request, the IPP object SHOULD execute the following steps. The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request.
IPPオブジェクトは、要求を受信した場合、IPPオブジェクトは、要求を受け入れるか、または拒否のいずれか。要求を受け入れるか拒否するか否かを決定するために、IPPオブジェクトは、以下のステップを実行する必要があります。ステップの順序は再配列及び/又は要求を介して1つの又は複数のパスを作るなど、組み合わせてもよいです。
A client MUST supply requests that would pass all of the error checks indicated here in order to be a conforming client. Therefore, a client SHOULD supply requests that are conforming, in order to avoid being rejected by some IPP object implementations and/or risking different semantics by different implementations of forgiving implementations. For example, a forgiving implementation that accepts multiple occurrences of the same attribute, rather than rejecting the request might use the first occurrences, while another might use the last occurrence. Thus such a non-conforming client would get different results from the two forgiving implementations.
クライアントは、準拠クライアントであるために、ここで示されたエラーチェックのすべてを通過する要求を供給しなければなりません。そのため、クライアントは、いくつかのIPPオブジェクト実装によって拒絶および/または寛容な実装の異なる実装によって異なる意味を危険にさらすされるのを避けるために、適合している要求を提供する必要があります。別の最後の発生を使用する可能性がありますしながら、例えば、寛容同じ属性の複数の発生を受け入れ、実装ではなく、要求を拒否するには、最初の発生を使用する場合があります。したがって、このような非準拠のクライアントは、2寛大な実装は異なる結果になるだろう。
In the following, processing continues step by step until a "RETURNS the xxx status code ..." statement is encountered. Error returns are indicated by the verb: "REJECTS". Since clients have difficulty getting the status code before sending all of the document data in a Print-Job request, clients SHOULD use the Validate-Job operation before sending large documents to be printed, in order to validate whether the IPP Printer will accept the job or not.
「XXXのステータスコードを返します...」文が検出されるまで、以下では、処理は、ステップバイステップを続けています。 「拒否する」：エラーリターンは動詞で示されています。クライアントは困難印刷ジョブ要求に文書データのすべてを送信する前にステータスコードを取得していますので、クライアントは、IPPプリンタがジョブを受け入れるかどうかを検証するために、印刷する大規模な文書を送信する前に検証ジョブ操作を使用すべきですか否か。
It is assumed that security authentication and authorization has already taken place at a lower layer.
セキュリティ認証と認可が既に下層に行われているものとします。
This section is intended to apply to all operations. The next section contains the additional steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations that create jobs, adds documents, and validates jobs.
このセクションでは、すべての操作に適用されるものとします。次のセクションでは、印刷ジョブ、検証、仕事のための追加の手順が含まれている印刷-URI、-ジョブの作成、-文書を送信し、雇用を創出事業を-URIに送信し、文書を追加し、ジョブを検証します。
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v err
3.1.2.1.1 <Validate version> --> server-error-version-not-
supported
ok|
v err
3.1.2.1.2 <Validate operation> --> server-error-operation-not-
supported
ok|
v err
3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
3.1.2.1.4.2 <of attributes>
ok|
v err
3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
<of operation attr>
ok|
v err
3.1.2.1.5 <Validate values of> --> client-error-bad-request
<operation attrs> client-error-request-value-
too-long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.1.5 <Validate values> --> client-error-bad-request
<with supported values> client-error-charset-not-
supported
ok| client-error-attributes-or-
values-
| not-supported
v err
3.1.2.1.6 <Validate optionally> --> client-error-bad-request
<operation attr> client-error-natural-language-
not-supported
| client-error-request-value-
too-long
| client-error-attributes-or-
values-not-supported
Every request and every response contains the "version-number" attribute. The value of this attribute is the major and minor version number of the syntax and semantics that the client and IPP object is using, respectively. The "version-number" attribute remains in a fixed position across all future versions so that all clients and IPP object that support future versions can determine which version is being used. The IPP object checks to see if the major version number supplied in the request is supported. If not, the Printer object REJECTS the request and RETURNS the 'server-error-version-not-supported' status code in the response. The IPP object returns in the "version-number" response attribute the major and minor version for the error response. Thus the client can learn at least one major and minor version that the IPP object supports. The IPP object is encouraged to return the closest version number to the one supplied by the client.
すべてのリクエストとレスポンスのたびは、「バージョン番号」属性が含まれています。この属性の値は、クライアントとIPPオブジェクトは、それぞれ、使用される構文とセマンティクスのメジャーバージョンとマイナーバージョン番号です。将来のバージョンをサポートしているすべてのクライアントとIPPオブジェクトが使用されているバージョンを確認することができるように、「バージョン番号」属性は、すべての将来のバージョン間で固定された位置に留まります。 IPPオブジェクトは、要求で供給されるメジャーバージョン番号がサポートされているかどうかを確認します。そうでない場合、Printerオブジェクトは、要求を拒否し、それに応答して「サーバー・エラー・バージョン、サポートされていない」ステータスコードを返します。 「バージョン番号」応答におけるIPPオブジェクトを返しますが、エラー応答のためのメジャーとマイナーバージョン属性。したがって、クライアントは、IPPオブジェクトがサポートしている少なくとも一つのメジャーバージョンとマイナーバージョンを学ぶことができます。 IPPオブジェクトは、クライアントによって提供されるものに最も近いバージョン番号を返すように奨励されています。
The checking of the minor version number is implementation dependent, however if the client-supplied minor version is explicitly supported, the IPP object MUST respond using that identical minor version number. If the major version number matches, but the minor version number does not, the Printer SHOULD accept and attempt to process the request, or MAY reject the request and return the 'server-error-version-not-supported' status code. In all cases, the Printer MUST return the nearest version number that it supports. For example, suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'. The following responses are conforming:
マイナーバージョン番号のチェックは、クライアントが提供するマイナーバージョンが明示的にサポートされている場合しかし、IPPオブジェクトはその同じマイナーバージョン番号を使用して応答しなければならない、実装に依存します。メジャーバージョン番号が一致しますが、マイナーバージョン番号がない場合、プリンタは受け入れ、要求を処理しようとし、または要求を拒否し、「サーバー・エラー・バージョン、サポートされていない」ステータスコードを返してもよいべきです。すべての場合において、プリンタは、それがサポートする最も近いバージョン番号を返さなければなりません。例えば、IPP / 1.2プリンタはバージョン「1.1」と「1.2」をサポートしていることとします。以下の応答が準拠しています：
Table 6 - Examples of validating IPP version
表6 - IPPバージョンを検証する例
Client supplies Printer Accept Request? Printer returns
クライアント用品プリンタが要求を受け入れますか？プリンタのリターン
It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, so that they can interoperate with either client implementations. Some implementations may allow an Administrator to explicitly disable support for one or the other by setting the "ipp-versions-supported" Printer description attribute.
彼らはどちらかのクライアント実装と相互運用できるように、プリンタが、IPP / 1.1とIPP / 1.0の両方をサポートすることが有利です。一部の実装では、管理者が明示的に「IPP-のバージョンでサポートされている」プリンタ記述属性を設定することで、どちらか一方のサポートを無効にすることを可能にします。
Likewise, it is advantageous for clients to support both versions to allow interoperability with new and legacy Printers.
クライアントは新旧プリンタとの相互運用性を可能にするために、両方のバージョンをサポートするために同様に、それが有利です。
The Printer object checks to see if the "operation-id" attribute supplied by the client is supported as indicated in the Printer object's "operations-supported" attribute. If not, the Printer REJECTS the request and returns the 'server-error-operation-not-supported' status code in the response.
Printerオブジェクトの「操作サポート」属性で示されているように、クライアントによって提供される「操作-id」属性がサポートされている場合、プリンタオブジェクトかどうかを確認します。そうでない場合、プリンタは要求を拒否し、それに応答して「サーバー・エラー・操作 - サポートされていない」ステータスコードを返します。
The Printer object SHOULD NOT check to see if the "request-id" attribute supplied by the client is in range: between 1 and 2**31 - 1 (inclusive), but copies all 32 bits.
すべての32ビット（これを含む）1が、コピー - ** 1及び2の間に31：Printerオブジェクトは、クライアントによって供給された「リクエストID」属性が範囲内にあるかどうかを確認すべきではありません。
Note: The "version-number", "operation-id", and the "request-id" parameters are in fixed octet positions in the IPP/1.1 encoding. The "version-number" parameter will be the same fixed octet position in all versions of the protocol. These fields are validated before proceeding with the rest of the validation.
注：「バージョン番号」、「操作ID」、および「要求ID」のパラメータは、IPP / 1.1符号化における固定オクテットの位置にあります。 「バージョン番号」パラメータは、プロトコルのすべてのバージョンで同じ固定オクテット位置であろう。これらのフィールドは、検証の残りの部分に進む前に検証されます。
The order of the following validation steps depends on implementation.
次の検証ステップの順序は実装に依存します。
Client requests and IPP object responses contain attribute groups that Section 3 requires to be present and in a specified order. An IPP object verifies that the attribute groups are present and in the correct order in requests supplied by clients (attribute groups without an * in the following tables).
クライアントの要求とIPPオブジェクト応答は第3節が存在し、指定された順序であることを要求する属性グループが含まれています。 IPPオブジェクトは、属性グループが存在し、クライアント（以下の表の*のない属性グループ）から供給されたリクエストで正しい順序になっていることを確認します。
If an IPP object receives a request with (1) required attribute groups missing, or (2) the attributes groups are out of order, or (3) the groups are repeated, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code. For example, it is an error for the Job Template Attributes group to occur before the Operation Attributes group, for the Operation Attributes group to be omitted, or for an attribute group to occur more than once, except in the Get-Jobs response.
IPPオブジェクトは、（1）必要な属性グループが存在しない、または（2）の属性グループが故障している、または（3）グループが繰り返され、IPPオブジェクトは、要求を拒否し、「クライアント・エラーを返すと、要求を受信した場合-bad要求」ステータスコード。例えば、それは操作がグループが省略される属性、または属性グループのためには、Get-ジョブの応答を除いて、複数回発生するジョブテンプレートは、操作はグループ属性の前に発生するグループ属性のエラーです。
Since this kind of attribute group error is most likely to be an error detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attribute group was in error in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all attribute group errors before returning this error.
属性グループのこの種のエラーは、クライアント開発者によってではなく、顧客によって検出された誤りである可能性が最も高いので、IPPオブジェクトは、属性グループがサポートされていない属性グループまたはステータスメッセージのいずれかでエラーが発生したかの表示を返す必要はありません。また、IPPオブジェクトは、このエラーを返す前に、すべての属性グループのエラーを見つける必要はありません。
Future attribute groups may be added to the specification at the end of requests just before the Document Content and at the end of response, except for the Get-Jobs response, where it maybe there or before the first job attributes returned. If an IPP object receives an unknown attribute group in these positions, it ignores the entire group, rather than returning an error, since that group may be a new group in a later minor version of the protocol that can be ignored. (If the new attribute group cannot be ignored without confusing the client, the major version number would have been increased in the protocol document and in the request). If the unknown group occurs in a different position, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code.
将来の属性グループは、多分そこか属性が返された最初の仕事の前には、Get-ジョブズの応答を除き、単にドキュメントコンテンツの前にリクエストの最後に、応答の終わり仕様に追加することができます。 IPPオブジェクトは、これらの位置での未知の属性グループを受信した場合、そのグループは無視することができ、プロトコルの以降のマイナーバージョンで新しいグループかもしれないので、それは、むしろエラーを返すよりも、グループ全体を無視します。 （新しい属性グループは、クライアントを混乱させずに無視することができない場合は、メジャーバージョン番号はプロトコルドキュメントで、要求が増加されていたであろう）。未知のグループが別の位置に発生した場合、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求のステータスコードを返します。
Clients also ignore unknown attribute groups returned in a response.
また、クライアントは応答で返さ未知の属性グループを無視します。
Note: By validating that requests are in the proper form, IPP objects force clients to use the proper form which, in turn, increases the chances that customers will be able to use such clients from multiple vendors with IPP objects from other vendors.
注意：リクエストが適切な形であることを検証することにより、IPPは、順番に、顧客はIPPは、他のベンダーからのオブジェクトと複数のベンダーから、このようなクライアントを使用することができます可能性が高くなり、適切なフォームを使用するように強制クライアントオブジェクト。
3.1.2.1.4.3 Validate the presence of a single occurrence of required Operation attributes
3.1.2.1.4.3必要な操作属性の1回の発生の有無を検証します
Client requests and IPP object responses contain Operation attributes that [RFC2911] Section 3 requires to be present. Attributes within a group may be in any order, except for the ordering of target, charset, and natural languages attributes. These attributes MUST be first, and MUST be supplied in the following order: charset, natural language, and then target. An IPP object verifies that the attributes that Section 4 requires to be supplied by the client have been supplied in the request (attributes without an * in the following tables). An asterisk (*) indicates groups and Operation attributes that the client may omit in a request or an IPP object may omit in a response.
クライアントの要求とIPPオブジェクト応答は、操作は[RFC2911]セクション3が存在することが必要であることを属性が含まれています。グループ内の属性は、ターゲット、文字セット、および自然言語属性の順序を除き、任意の順序であってもよいです。これらの属性は最初でなければならない、と次の順序で供給されなければならない。そして、文字セット、自然言語、およびターゲット。 IPPオブジェクトは、第4節は、クライアントによって供給される必要があり、属性が要求（以下の表の*なし属性）に供給されていることを確認します。アスタリスク（*）がグループを示し、操作は、クライアントが要求または応答では省略することもIPPオブジェクトに省略することが属性。
If an IPP object receives a request with required attributes missing or repeated from a group or in the wrong position, the behavior of the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible implementations are:
IPPオブジェクトが存在しないか、またはグループからか、間違った位置に繰り返して必要な属性を持つ要求を受信した場合、IPPオブジェクトの振る舞いは実装依存です。可能な実装のいくつかは以下のとおりです。
REJECTS the request and RETURNS the 'client-error-bad-request' status code accepts the request and uses the first occurrence of the attribute no matter where it is
要求を拒否し、「クライアント誤り悪い要求のステータスコードは、要求を受け入れ、関係なく、それがどこにある属性の最初の発生を使用していないRETURNS
accepts the request and uses the last occurrence of the attribute no matter where it is
要求を受け入れ、関係なく、それがどこにある属性の最後の発生を使用していません
accept the request and assume some default value for the missing attribute
要求を受け入れ、不足している属性のためのいくつかのデフォルト値を仮定
Therefore, client MUST send conforming requests, if they want to receive the same behavior from all IPP object implementations. For example, it is an error for the "attributes-charset" or "attributes-natural-language" attribute to be omitted in any operation request, or for an Operation attribute to be supplied in a Job Template group or a Job Template attribute to be supplied in an Operation Attribute group in a create request. It is also an error to supply the "attributes-charset" attribute twice.
彼らはすべてのIPPオブジェクト実装から同じ動作を受信したい場合はそのため、クライアントは、適合要求を送らなければなりません。 「-文字セット属性」または「属性自然言語」いずれかの操作要求では省略することにする属性を、OR演算のためには、にジョブテンプレートグループまたはジョブテンプレート属性で供給される属性のために例えば、それは誤りであります作成リクエストで操作属性グループに供給すること。また、二回「属性-のcharset」属性を供給するとエラーになります。
Since these kinds of attribute errors are most likely to be detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attribute was in error in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all attribute errors before returning this error.
属性エラーこれらの種類は、クライアント開発者によってではなく、顧客によって検出される可能性が最も高いので、IPPオブジェクトはサポートされていない属性グループまたはステータスメッセージのいずれかでエラーがあった属性の表示を返す必要はありません。また、IPPオブジェクトは、このエラーを返す前に、すべての属性のエラーを発見する必要はありません。
The following tables list all the attributes for all the operations by attribute group in each request and each response. The order of the groups is the order that the client supplies the groups as specified in [RFC2911] Section 3. The order of the attributes within a group is arbitrary, except as noted for some of the special operation attributes (charset, natural language, and target). The tables below use the following notation:
以下の表は、各要求と各応答における属性グループによってすべての操作のすべての属性をリストします。グループの順序は、[RFC2911]セクション3で指定されたグループ内の属性の順序が特別な操作属性（文字セット、自然言語の一部について述べたように除いて、任意で、クライアントがグループを供給するようにするためでありますそしてターゲット）。以下の表は、次の表記を使用します。
R indicates a REQUIRED attribute or operation that an IPP object MUST support O indicates an OPTIONAL attribute or operation that an IPP object NEED NOT support * indicates that a client MAY omit the attribute in a request and that an IPP object MAY omit the attribute in a response. The absence of an * means that a client MUST supply the attribute in a request and an IPP object MUST supply the attribute in a response. + indicates that this is not a IPP/1.0 operation, but is only a part of IPP/1.1 and future versions of IPP.
RはOをサポートしなければならないIPPオブジェクトはIPPオブジェクトが*サポートし、クライアントがリクエストに属性を省略するかもしれないこととIPPオブジェクトがで属性を省略する可能性があることを示す必要はありませんOPTIONAL属性や操作を示しREQUIRED属性や操作を示し応答。 *の不在は、クライアントがリクエストに属性を供給しなければなりませんし、IPPオブジェクトが応答で属性を供給しなければならないことを意味します。 +は、これがIPP / 1.0操作ではなく、唯一のIPP / 1.1とIPPの将来のバージョンの一部であることを示しています。
Operation Requests
操作要求
The tables below show the attributes in their proper attribute groups for operation requests:
以下の表は、操作要求のための彼らの適切な属性グループの属性を示しています。
Note: All operation requests contain "version-number", "operation-id", and "request-id" parameters.
注：すべての操作要求は、「バージョン番号」、「操作-ID」、および「要求-ID」パラメータが含まれています。
Print-Job Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see [RFC2911] Section 4.2) Group 3: Document Content (R) <document content>
印刷ジョブ要求（R）：グループ1：操作（R）属性は、属性、文字セット（R）は、属性の自然言語（R）プリンタ-uriの（R）を要求するユーザー名（R *）ジョブ名を（R *）IPP属性忠実度（R *）、文書名（R *）ドキュメント・フォーマット（R *）ドキュメント自然言語（O *）圧縮（R *）ジョブK-オクテット（Oの*）job-感想（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（R *が）<ジョブテンプレート属性>（O *）（参照[RFC2911]セクション4.2）グループ3：ドキュメントコンテンツ（R）<文書の内容>
Validate-Job Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see [RFC2911] Section 4.2)
検証・ジョブ要求（R）：グループ1：操作属性（R）属性 - 文字セット（R）は属性 - 自然言語を（R）プリンタ-uriの（R）を要求するユーザー名（Rの*）ジョブ名（R *）IPP属性忠実度（R *）、文書名（R *）ドキュメント・フォーマット（R *）ドキュメント自然言語（O *）圧縮（R *）ジョブK-オクテット（Oの*）job-感想（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（Rの*）<ジョブテンプレート属性>（O *）（参照[RFC2911]セクション4.2）
Print-URI Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) document-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see (see [RFC2911] Section 4.2)
印刷-URI要求（O）：グループ1：操作（R）属性は、属性、文字セット（R）属性 - 自然言語（R）プリンタ-uriの（R）文書-uriの（R）を要求するユーザー名（R * ）ジョブ名（R *）IPP属性忠実度（R *）、文書名（R *）ドキュメント・フォーマット（R *）ドキュメント自然言語（O *）圧縮（R *）ジョブKオクテット（O *）ジョブ感想（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（R *が）<ジョブテンプレート属性>（O *）（参照（参照[RFC2911]セクション4.2）
Create-Job Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see (see [RFC2911] Section 4.2)
グループ1：操作は（R）属性は、属性、文字セット（R）属性 - 自然言語（R）プリンタ-uriの（R）を要求するユーザー名（R *）ジョブ名（Rリクエスト（O）を、仕事に作成します。 *）IPP属性忠実度（Rの*）ジョブKオクテット（O *）ジョブ感想（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（Rの*）<ジョブテンプレート属性>（O *）（参照（参照[RFC2911]セクション4.2）
Get-Printer-Attributes Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) requested-attributes (R*) document-format (R*)
リクエスト（R） - プリンタ - 属性の取得：グループ1：操作（R）属性は、（R） - 文字セット属性属性 - 自然言語を（R）プリンタ-uriの（R）を要求するユーザー名（R *）要求、属性（R *）ドキュメントフォーマット（R *）
Get-Jobs Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) limit (R*) requested-attributes (R*) which-jobs (R*) my-jobs (R*)
ゲット・ジョブズ要求（R）を：グループ1：操作（R）属性は、（R） - 文字セット属性属性 - 自然言語を（R）プリンタ-uriの（R）を要求するユーザー名（R *）リミット（R *）要求された-属性（R *） - ジョブ（R *）私の-ジョブ（R *）
Send-Document Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) last-document (R) requesting-user-name (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) Group 2: Document Content (R*) <document content>
グループ1：リクエスト（O） - ドキュメントの送信操作属性（R）属性 - 文字セット（R）は、属性の自然言語（R）（プリンタ-URI＆ジョブIDを）|仕事-URI（R）最後のドキュメント（R）を要求するユーザー名（R *）、文書名（R *）ドキュメント・フォーマット（R *）ドキュメント自然言語（O *）圧縮（R *）グループ2：ドキュメントコンテンツ（R *）<文書の内容>
Send-URI Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) last-document (R) document-uri (R) requesting-user-name (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*)
グループ1：リクエスト（O） - URIの送信操作属性（R）属性 - 文字セット（R）は、属性の自然言語（R）（プリンタ-URI＆ジョブIDを）|仕事-URI（R）最後のドキュメント（R）文書-uriの（R）を要求するユーザー名（R *）、文書名（R *）ドキュメント・フォーマット（Rの*）ドキュメント自然言語（Oの*）圧縮（R *）
Cancel-Job Request (R): Release-Job Request (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) requesting-user-name (R*) message (O*)
キャンセル・ジョブ要求（R）：リリース・ジョブリクエスト（O +）：グループ1：操作の属性（R）は属性-文字セット（R）は、属性の自然言語（R）（プリンタ-URI＆ジョブIDを）|仕事-URI（R）を要求するユーザー名（R *）メッセージ（Oの*）
Get-Job-Attributes Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) requesting-user-name (R*) requested-attributes (R*)
ゲット・ジョブ・属性要求（R）：グループ1：操作の属性（R）は属性-文字セット（R）は、属性の自然言語（R）（プリンタ-URI＆ジョブIDを）|仕事-URI（R）を要求するユーザー名（R *）要求-属性（R *）
Pause-Printer Request (O+): Resume-Printer Request (O+): Purge-Printer Request (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*)
一時停止・プリンタ・リクエスト（O +）を：-再開プリンタ要求（O +）：パージ・プリンター要求（O +）：グループ1：操作属性（R）の属性、文字セット（R）は属性 - 自然言語を（R）プリンタ-URI（ R）を要求するユーザー名（Rの*）
Hold-Job Request (O+): Restart-Job Request (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) requesting-user-name (R*) job-hold-until (R*) message (O*)
ホールドジョブリクエスト（O +）を：-再起動ジョブ要求（O +）：グループ1：操作属性（R）の属性は、文字セット（R）は、属性の自然言語（R）（プリンタ-URI＆ジョブIDを）|仕事-URI（R）を要求するユーザー名（R *）ジョブホールドまで（R *）メッセージ（Oの*）
Operation Responses
操作レスポンス
The tables below show the response attributes in their proper attribute groups for responses.
以下の表は、応答が応答のために彼らの適切な属性グループ内の属性を示しています。
Note: All operation responses contain "version-number", "status-code", and "request-id" parameters.
注：すべての操作の応答が「バージョン番号」、「ステータス・コード」、および「要求-ID」パラメータが含まれています。
Print-Job Response (R): Create-Job Response (O): Send-Document Response (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 3) n <unsupported attributes> (R*) Group 3: Job Object Attributes(R*) (see Note 2) job-uri (R) job-id (R) job-state (R) job-state-reasons (O* | R+) job-state-message (O*) number-of-intervening-jobs (O*)
印刷ジョブレスポンス（R）：作成-仕事レスポンス（O）：送信-ドキュメント応答（O）：グループ1：操作（R）属性は、属性、文字セット（R）属性 - 自然言語（R）のステータスメッセージ（ O *）の詳細なステータスメッセージ（O用*）グループ2：サポートされない属性（R *）（注3参照）は、n <サポートされない属性>（R *）グループ3：ジョブオブジェクト属性（R *）（注2参照）仕事-URI（R）ジョブID（R）ジョブの状態（R）ジョブ状態の理由（O * | R +）のジョブ状態メッセージ（O *）数の--ジョブを介在（O *）
Validate-Job Response (R): Cancel-Job Response (R): Hold-Job Response (O+): Release-Job Response (O+): Restart-Job Response (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 3) <unsupported attributes> (R*)
検証・ジョブレスポンス（R）：キャンセル-仕事レスポンス（R）：ホールドジョブレスポンス（O +）を：リリース-仕事レスポンス（O +）を：再起動-仕事レスポンス（O +）：グループ1：操作属性（R）の属性 - 文字セット（R）は、属性の自然言語（R）のステータスメッセージ（O *）詳細なステータス・メッセージ（Oの*）グループ2：サポートされていない属性（R *）（注3参照）<サポートされていない属性>（R *）
Print-URI Response (O): Send-URI Response (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) document-access-error (O*) Group 2: Unsupported Attributes (R*) (see Note 3) <unsupported attributes> (R*) Group 3: Job Object Attributes(R*) (see Note 2) job-uri (R) job-id (R) job-state (R) job-state-reasons (O* | R+) job-state-message (O*) number-of-intervening-jobs (O*)
印刷-URIレスポンス（O）：送信-URIレスポンス（O）：グループ1：操作（R）属性は、属性、文字セット（R）属性 - 自然言語（R）のステータスメッセージ（O *）詳細なステータスメッセージ（O *）ドキュメント・アクセス・エラー（O *）グループ2：サポートされていない属性（R *）（注3参照）<サポートされていない属性>（R *）グループ3：ジョブオブジェクトの属性（R *）（注2参照）仕事-URI（R）ジョブID（R）ジョブの状態（R）ジョブ状態の理由（O * | R +）のジョブ状態メッセージ（O *）数の--ジョブを介在（O *）
Get-Printer-Attributes Response (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 4) <unsupported attributes> (R*) Group 3: Printer Object Attributes(R*) (see Note 2) <requested attributes> (R*)
レスポンス（R）を取得します - プリンタ - 属性：グループ1：操作（R）属性は、（R） - 文字セット属性属性 - 自然言語（R）のステータスメッセージ（O *）詳細なステータス・メッセージ（O *）グループ2 ：サポートされていない属性（R *）（注4参照）<サポートされていない属性>（R *）グループ3：プリンタオブジェクトの属性（R *）（注2参照）<要求された属性>（Rの*）
Get-Jobs Response (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 4) <unsupported attributes> (R*) Group 3: Job Object Attributes(R*) (see Note 2, 5) <requested attributes> (R*)
ゲット・ジョブズレスポンス（R）：グループ1：操作（R）属性は、（R） - 文字セット属性属性 - 自然言語（R）のステータスメッセージ（O *）詳細なステータス・メッセージ（O *）グループ2：サポートされていません属性（R *）（注4参照）<サポートされていない属性>（R *）グループ3：ジョブオブジェクトの属性は、（R *）（注2参照、5）<要求された属性>（R *）
Get-Job-Attributes Response (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 4) <unsupported attributes> (R*) Group 3: Job Object Attributes(R*) (see Note 2) <requested attributes> (R*)
ゲット・仕事・属性応答（R）：グループ1：操作の属性（R）は属性-文字セット（R）は、属性の自然言語（R）のステータスメッセージ（O *）詳細なステータス・メッセージ（O *）グループ2を：サポートされていない属性（R *）（注4参照）<サポートされていない属性>（R *）グループ3：ジョブオブジェクトの属性（R *）（注2参照）<要求された属性>（Rの*）
Pause-Printer Response (O+): Resume-Printer Response (O+): Purge-Printer Response (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 4) <unsupported attributes> (R*)
一時停止 - プリンタ応答（O +）を：（O +） - 再開プリンタ応答：パージ・プリンタ応答（O +）：グループ1：操作属性（R）属性 - 文字セット（R）は、（R）のステータスメッセージ（自然言語属性O *）の詳細なステータスメッセージ（O用*）グループ2：サポートされない属性（R *）（注4参照）<サポートされない属性>（R *）
Note 2 - the Job Object Attributes and Printer Object Attributes are returned only if the IPP object returns one of the success status codes.
注2 - ジョブオブジェクトの属性とプリンタオブジェクト属性はIPPオブジェクトが成功ステータスコードのいずれかを返す場合にのみ返されます。
Note 3 - the Unsupported Attributes Group is present only if the client included some Operation and/or Job Template attributes or values that the Printer doesn't support whether a success or an error return.
3注 - サポートされていないグループは、クライアントがプリンタがサポートしていないいくつかの操作、および/またはジョブテンプレート属性または値が含まれている場合にのみ存在する属性の成功またはエラーリターンするかどうか。
Note 4 - the Unsupported Attributes Group is present only if the client included some Operation attributes that the Printer doesn't support whether a success or an error return.
注4 - サポートされていないグループは、クライアントは、いくつかの操作は、プリンタでサポートされていない属性が含まれている場合にのみ存在する属性の成功またはエラーリターンするかどうか。
Note 5: for the Get-Jobs operation the response contains a separate Job Object Attributes group 3 to N containing requested-attributes for each job object in the response.
注5：応答は別々のジョブオブジェクトが含まれています。Get-ジョブ操作のためには、応答の各ジョブオブジェクトのために要求され、属性を含むNにグループ3属性。
An IPP object validates the values supplied by the client of the REQUIRED Operation attribute that the IPP object MUST support. The next section specifies the validation of the values of the OPTIONAL Operation attributes that IPP objects MAY support.
IPPオブジェクトは、必要な操作のクライアントによって供給された値は、IPPオブジェクトがサポートしなければならないという属性を検証します。次のセクションでは、任意のオペレーションの値の検証はIPPオブジェクトがサポートするかもしれないことに属性を指定します。
The IPP object performs the following syntactic validation checks of each Operation attribute value:
IPPオブジェクトは、各操作属性値の次の構文の妥当性チェックを実行します。
a) that the length of each Operation attribute value is correct for the attribute syntax tag supplied by the client according to [RFC2911] Section 4.1,
A）各操作属性値の長さは、[RFC2911]セクション4.1に従ってクライアントによって供給された属性構文タグに正しいこと
b) that the attribute syntax tag is correct for that Operation attribute according to [RFC2911] Section 3,
B）属性構文タグは、[RFC2911]セクション3に係るその操作属性の正しいこと
c) that the value is in the range specified for that Operation attribute according to [RFC2911] Section 3,
C）値は、[RFC2911]セクション3に係るその操作属性に指定された範囲内にあること
d) that multiple values are supplied by the client only for operation attributes that are multi-valued, i.e., that are 1setOf X according to [RFC2911] Section 3.
D）複数の値のみ1setOf Xは[RFC2911]セクション3に記載されている多値ある操作属性、即ち、のためにクライアントによって供給されていること。
If any of these checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request-value-too-long' status code. Since such an error is most likely to be an error detected by a client developer, rather than by an end-user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
これらのチェックのいずれかが失敗した場合、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求」または「クライアント誤り要求値-長すぎる」ステータスコードを返します。このようなエラーがクライアントの開発者ではなく、エンドユーザが検出されたエラーである可能性が最も高いので、IPPオブジェクトはサポートされていないが、グループ属性やステータスメッセージのいずれかのエラーを持っていた属性の表示を返す必要はありません。これらの構文チェックのそれぞれについての説明は、明示的に次の表の最初のIF文で表現されます。
In addition, the IPP object checks each Operation attribute value against some Printer object attribute or some hard-coded value if there is no "xxx-supported" Printer object attribute defined. If its value is not among those supported or is not in the range supported, then the IPP object REJECTS the request and RETURNS the error status code indicated in the table by the second IF statement. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails.
加えて、IPPオブジェクトチェック各操作は、いくつかのプリンタオブジェクト属性または定義された「XXX-サポート」プリンタオブジェクト属性が存在しない場合、いくつかのハードコーディングされた値に対して属性値。その値がサポートされているものの中ではないか、またはサポートされている範囲内にない場合、IPPオブジェクトは、要求を拒否し、第二のIF文により、表に示されたエラーステータスコードを返します。 Printerオブジェクトの「XXX-サポート」属性の値が「は、値が」されていない場合（システム管理者が値を設定していないので）、チェックはいつも失敗します。
-----------------------------------------------
attributes-charset (charset)
属性は、文字セット（文字セット）
IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の非空の「文字セット」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが63オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "charset-supported" attribute, REJECT/RETURN "client-error-charset-not-supported".
Printerオブジェクトの "文字セット・サポート" 属性で、/ RETURNをREJECTていない場合は、 "クライアント・エラー-charsetが-サポートされていません"。
attributes-natural-language(naturalLanguage)
属性 - 自然言語（自然言語）
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の非空の「自然言語」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが63オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
ACCEPT the request even if not a member of the set in the Printer object's "generated-natural-language-supported" attribute. If the supplied value is not a member of the Printer object's "generated-natural-language-supported" attribute, use the Printer object's "natural-language- configured" value.
要求してもいない場合はPrinterオブジェクトの「生成された自然言語サポート」属性にセットのメンバーを受け入れます。指定された値がPrinterオブジェクトの「生成された自然言語サポート」属性のメンバーでない場合、Printerオブジェクトの「自然、言語構成された」値を使用します。
requesting-user-name
要求元のユーザー名
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「name」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF the IPP object can obtain a better-authenticated name, use it instead.
IPPオブジェクトは、より良い認証名を取得できた場合は、代わりにそれを使用しています。
job-name(name)
ジョブ名（名前）
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「name」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT supplied by the client, the Printer object creates a name from the document-name or document-uri.
クライアントによって提供されていない場合、Printerオブジェクトは、文書名や文書-URIから名前を作成します。
document-name (name)
文書名（名前）
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「name」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
ipp-attribute-fidelity (boolean)
IPP属性忠実度（ブール値）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'.
シングル「真」NORシングル「偽」「ブールNEITHER場合、クライアント誤り悪い要求」「値、/ RETURN REJECT」を。
IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client-error-request-value-too-long'
値の長さは1つのオクテットに等しいされていない場合は、/ RETURN「クライアント誤り要求値-長すぎる」REJECT
IF NOT supplied by the client, the IPP object assumes the value 'false'.
クライアントによって提供されていない場合、IPPオブジェクトは「偽」の値をとります。
document-format (mimeMediaType)
ドキュメント・フォーマット（mimeMediaType）
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の非空の「mimeMediaType」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "document-format-supported" attribute, REJECT/RETURN 'client-error-document-format-not-supported'
Printerオブジェクトの「ドキュメント・フォーマットをサポートする」属性で、REJECTされていない場合/ RETURN「クライアント誤りドキュメント形式 - - サポートされていません」
IF NOT supplied by the client, the IPP object assumes the value of the Printer object's "document-format-default" attribute.
クライアントによって提供されていない場合、IPPオブジェクトは、Printerオブジェクトの「ドキュメント形式デフォルト」属性の値をとります。
document-uri (uri)
リンクドキュメント（S）
IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の非空の「URI」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 1023 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが1023オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-request'.
URIの構文が有効でない場合、/ RETURN「クライアント誤り悪い要求」を拒否します。
If the client-supplied URI scheme is not supported, i.e., the value is not in the Printer object's referenced-uri-scheme-supported" attribute, the Printer object MUST reject the request and return the 'client-error-uri-scheme-not-supported' status code. The Printer object MAY check to see if the document exists and is accessible. If the document is not found or is not accessible, REJECT/RETURN 'client-error-not found'.
クライアントが提供するURIスキームがサポートされていない場合、すなわち、値がPrinterオブジェクトの参照-URI-スキーム・サポート」属性ではありません、Printerオブジェクトは、要求を拒否し、「クライアント・エラー-URI-scheme-を返さなければなりません - サポートされていない」ステータスコード。Printerオブジェクトは、文書が存在し、アクセス可能であるかどうかを確認するかもしれません。文書が見つからないか、アクセスできませんされている場合は、RETURN / REJECT 『クライアント誤りではない』になっています。
last-document (boolean)
最後のドキュメント（ブール値）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'.
シングル「真」NORシングル「偽」「ブールNEITHER場合、クライアント誤り悪い要求」「値、/ RETURN REJECT」を。
IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client-error-request-value-too-long'
値の長さは1つのオクテットに等しいされていない場合は、/ RETURN「クライアント誤り要求値-長すぎる」REJECT
job-id (integer(1:MAX))
ジョブID（整数（1：MAX））
IF NOT an single 'integer' value equal to 4 octets AND in the range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
4つのオクテットに等しい単一の「整数」の値でない場合にはMAXの範囲1において、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-error-not-found' or 'client-error-gone' status code, if keep track of recently deleted jobs.
最近削除されたジョブを追跡する場合は、既存のジョブオブジェクトのIF NOTジョブIDは、/ RETURN「クライアント誤り-が見つからない」または「クライアント誤り行って」ステータスコードを拒否します。
requested-attributes (1setOf keyword)
要求された-属性（1setOfキーワード）
IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は1以上の「キーワード」値は、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
Ignore unsupported values, which are the keyword names of unsupported attributes. Don't bother to copy such requested (unsupported) attributes to the Unsupported Attribute response group since the response will not return them.
サポートされていない属性のキーワード名ですサポートされていない値を、無視します。 （サポートされていない）、このような要求をコピーするために気にしないでください応答がそれらを返さないので、サポートされていない属性応答グループに属性。
which-jobs (type2 keyword)
・ジョブ（TYPE2キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NEITHER 'completed' NOR 'not-completed', copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN 'client-error-attributes-or-values-not-supported'.
IF NEITHER「完了」NOR「-完了していない」、属性をコピーして、サポートされていないにサポートされていない値は、応答グループの属性と/ RETURN「クライアント誤り属性 - または - 値は-サポートされていません」REJECT。
Note: a Printer still supports the 'completed' value even if it keeps no completed/canceled/aborted jobs: by returning no jobs when so queried.
注意：プリンタはまだそれが完了/キャンセル/中止されたジョブを保持していない場合でも、「完了」の値をサポートしていますので、照会時にどんな仕事を返さないことで。
IF NOT supplied by the client, the IPP object assumes the 'not-completed' value.
クライアントによって提供されていない場合、IPPオブジェクトは、「未完」の値をとります。
my-jobs (boolean)
私-ジョブ（ブール値）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'.
シングル「真」NORシングル「偽」「ブールNEITHER場合、クライアント誤り悪い要求」「値、/ RETURN REJECT」を。
IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client-error-request-value-too-long'
値の長さは1つのオクテットに等しいされていない場合は、/ RETURN「クライアント誤り要求値-長すぎる」REJECT
IF NOT supplied by the client, the IPP object assumes the 'false' value.
クライアントによって提供されていない場合、IPPオブジェクトは「偽」の値をとります。
limit (integer(1:MAX))
限界（整数（1：MAX））
IF NOT a single 'integer' value equal to 4 octets AND in the range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
4つのオクテットに等しい単一の「整数」の値でない場合にはMAXの範囲1において、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT supplied by the client, the IPP object returns all jobs, no matter how many.
クライアントによって提供されていない場合、IPPオブジェクトは、どんなに多くの、すべてのジョブを返しません。
-----------------------------------------------
OPTIONAL Operation attributes are those that an IPP object MAY support. An IPP object validates the values of the OPTIONAL attributes supplied by the client. The IPP object performs the same syntactic validation checks for each OPTIONAL attribute value as in Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request-value-too-long' status code.
任意のオペレーション属性はIPPオブジェクトがサポートするかもしれないものです。 IPPオブジェクトは、クライアントによって提供されるオプション属性の値を検証します。 IPPオブジェクトは、セクション3.1.2.1.5のように各オプションの属性値に対して同じ構文検証チェックを行います。セクション3.1.2.1.5のように、いずれかが失敗した場合、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求」または「クライアント誤り要求値-長すぎる」ステータスコードを返します。
In addition, the IPP object checks each Operation attribute value against some Printer attribute or some hard-coded value if there is no "xxx-supported" Printer attribute defined. If its value is not among those supported or is not in the range supported, then the IPP object REJECTS the request and RETURNS the error status code indicated in the table. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails.
加えて、IPPオブジェクトチェック各操作は、いくつかのプリンタ属性または定義された「XXX-サポート」プリンタ属性が存在しない場合、いくつかのハードコードされた値に対して属性値。その値がサポートされているものの中ではないか、またはサポートされている範囲内にない場合、IPPオブジェクトは、要求を拒否し、表に示されたエラーステータスコードを返します。 Printerオブジェクトの「XXX-サポート」属性の値が「は、値が」されていない場合（システム管理者が値を設定していないので）、チェックはいつも失敗します。
If the IPP object doesn't recognize/support an attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see the last row in the table below).
IPPオブジェクトは/認識属性をサポートしていない場合、IPPオブジェクトが未知の、または、サポートされない属性として属性を（以下の表の最後の行を参照）を扱います。
-----------------------------------------------
document-natural-language (naturalLanguage)
ドキュメント自然言語（自然言語）
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の非空の「自然言語」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが63オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT a value that the Printer object supports in document formats, (no corresponding "xxx-supported" Printer attribute), REJECT/RETURN 'client-error-natural-language-not-supported'.
そうでない場合は、プリンタオブジェクトがドキュメント形式に対応していること値、（ノー対応する「XXX-サポート」Printer属性）、RETURN「クライアント誤り自然言語-サポートされていません」/ REJECT。
compression (type3 keyword)
圧縮（TYPE3キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "compression-supported" attribute, REJECT/RETURN 'client-error-compression-not-supported'.
Printerオブジェクトの「圧縮サポート」属性にされていない場合、/ RETURN「クライアント誤り圧縮-サポートされていません」REJECT。
Note to IPP/1.0 implementers: Support for the "compression" attribute was optional in IPP/1.0 and was changed to REQUIRED in IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the "compression" attribute being present and reject the create request, if they don't support "compression". Not checking is a bug, since the data will be unintelligible.
IPP / 1.0実装者への注意：「圧縮」属性のサポートは、IPP / 1.0にはオプションでしたし、IPP / 1.1で必要に変更されました。しかし、IPP / 1.0オブジェクトは、少なくとも「圧縮」属性が存在しているかどうかを確認すべきであると彼らは「圧縮」をサポートしていない場合は、作成要求を拒否します。チェックしていないデータが判読不能になるため、バグです。
job-k-octets (integer(0:MAX))
ジョブ-K-オクテット（整数（0：MAX））
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は4つのオクテットに等しい単一の「整数」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the range of the Printer object's "job-k-octets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN 'client-error-attributes-or-values-not-supported'.
Printerオブジェクトのの範囲内で「仕事-K-オクテット・サポート」されていない場合、属性、属性およびサポートされていない属性応答グループにサポートされていない値をコピーし、REJECT / RETURN「クライアント誤り属性-または値-not- 」サポートされています。
job-impressions (integer(0:MAX))
ジョブ感想（整数（0：MAX））
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は4つのオクテットに等しい単一の「整数」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the range of the Printer object's "job-impressions-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN 'client-error-attributes-or-values-not-supported'.
Printerオブジェクトのの範囲内で「ジョブ・感想・サポート」されていない場合、属性、属性およびサポートされていない属性応答グループにサポートされていない値をコピーし、/ RETURN REJECT「クライアント誤り属性-または値を-サポートされていません」 。
job-media-sheets (integer(0:MAX))
ジョブメディアシート（整数（0：MAX））
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は4つのオクテットに等しい単一の「整数」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the range of the Printer object's "job-media-sheets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN 'client-error-attributes-or-values-not-supported'.
Printerオブジェクトのの範囲内で、「ジョブメディアシート・サポート」されていない場合、属性、属性およびサポートされていない属性応答グループにサポートされていない値をコピーし、REJECT / RETURN「クライアント誤り属性-または値-not- 」サポートされています。
message (text(127))
メッセージ（テキスト（127））
IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「テキスト」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 127 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが127オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
unknown or unsupported attribute
未知の、またはサポートされていない属性
IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax, REJECT/RETURN 'client-error-request-value-too-long'.
クライアントが供給する属性構文がサポートされていますが、長さは、その属性構文のための法的されていない場合は、REJECT / RETURN「クライアント誤り要求値-長すぎます」。
ELSE copy the attribute and value to the Unsupported Attributes response group and change the attribute value to the "out-of-band" 'unsupported' value, but otherwise ignore the attribute.
ELSEサポートされていない応答グループの属性と「アウトオブバンド」「サポートされていない」の値に属性値を変更し、それ以外の属性を無視する属性と値をコピーします。
Note: Future Operation attributes may be added to the protocol specification that may occur anywhere in the specified group. When the operation is otherwise successful, the IPP object returns the 'successful-ok-ignored-or-substituted-attributes' status code. Ignoring unsupported Operation attributes in all operations is analogous to the handling of unsupported Job Template attributes in the create and Validate-Job operations when the client supplies the "ipp-attribute-fidelity" Operation attribute with the 'false' value. This last rule is so that we can add OPTIONAL Operation attributes to future versions of IPP so that older clients can inter-work with new
注：未来の動作は、指定されたグループ内のどこにでも発生する可能性がプロトコル仕様に追加することができる属性。操作がそうでなければ成功した場合には、IPPオブジェクトは、 "成功-OK-無視-または置換 - 属性のステータスコードを返します。サポートされていない操作はすべての操作で属性を無視すると、クライアントが「偽」値と「IPP属性忠実度」Operation属性を供給する場合、テンプレートを作成および検証 - 仕事の操作でサポートされていない属性仕事の取り扱いに類似しています。我々は古いクライアントが新しいとの間の仕事ができるように任意のオペレーションは、IPPの将来のバージョンに属性を追加できるように、この最後のルールがあります
IPP objects and newer clients can inter-work with older IPP objects. (If the new attribute cannot be ignored without performing unexpectedly, the major version number would have been increased in the protocol document and in the request). This rule for Operation attributes is independent of the value of the "ipp-attribute-fidelity" attribute. For example, if an IPP object doesn't support the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k-octets" as an unknown attribute and only checks the length for the 'integer' attribute syntax supplied by the client. If it is not four octets, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code, else the IPP object copies the attribute to the Unsupported Attribute response group, setting the value to the "out-of-band" 'unsupported' value, but otherwise ignores the attribute.
IPPは、オブジェクトと、新しいクライアントが古いIPPオブジェクトと相互動作することができます。 （新しい属性が予期せずに実行せずに無視することができない場合は、メジャーバージョン番号はプロトコルドキュメントで、要求が増加されていたであろう）。操作属性のこのルールは、「IPP属性忠実度」属性の値とは無関係です。例えば、IPPオブジェクトは「、未知の属性としてIPPオブジェクト扱い 『ジョブK-オクテット』とだけのための長さをチェックする 『オプション「ジョブK-オクテット」属性をサポートしていない場合、属性構文を整数』クライアントによって提供されます。それは4つのオクテットでない場合は、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求のステータスコードを返し、それ以外のIPPオブジェクトのコピーサポートされていない属性応答グループに属性、「OUT-に値を設定します『サポートされていない』の値「バンドの、それ以外の属性を無視します。
3.1.2.2 Suggested Additional Processing Steps for Operations that Create/Validate Jobs and Add Documents
/検証ジョブを作成し、ドキュメントを追加操作の3.1.2.2推奨追加の処理ステップ
This section in combination with the previous section recommends the processing steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations that IPP objects SHOULD use. These are the operations that create jobs, validate a Print-Job request, and add documents to a job.
前のセクションとの組み合わせでこのセクションでは、印刷ジョブ、検証・ジョブ、印刷-URI、作成・ジョブ、送信、文書の処理手順を推奨していますし、IPPオブジェクトが使用する必要のある操作-URIを送信します。これらは、印刷ジョブの要求を検証し、雇用を創出する事業であり、ジョブに文書を追加します。
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v No
3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
<supplied?> |
Yes| |
| ipp-attribute-fidelity = no |
|<------------------------------+
v No
3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
<accepting jobs?>
Yes|
v err
3.1.2.3 <Validate values of> --> client-error-bad-request
<Job template attributes> client-error-request-value-too-
long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.3 <Validate values with> --> client-error-bad-request
<supported values> client-error-attributes-or-
| values-not-supported
v err
3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
attributes
<Job Template attr values> client-error-attributes-or-
values-not-supported
v
The Printer object checks to see if the client supplied an "ipp-attribute-fidelity" Operation attribute. If the attribute is not supplied by the client, the IPP object assumes that the value is 'false'.
クライアントは、「IPP属性忠実度」Operation属性を供給した場合、プリンタオブジェクトかどうかを確認します。属性がクライアントによって供給されていない場合は、IPPオブジェクトは、値が「偽」であることを前提としています。
If the value of the Printer objects "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code.
プリンタオブジェクトの「プリンタ受容され、ジョブ」の値が「偽」である場合、Printerオブジェクトは、要求を拒否し、「サーバー・エラー・-受け入れていない - のジョブのステータスコードを返します。
An IPP object validates the values of all Job Template attribute supplied by the client. The IPP object performs the analogous syntactic validation checks of each Job Template attribute value that it performs for Operation attributes (see Section 3.1.2.1.5.):
IPPオブジェクトは、クライアントが提供するすべてのジョブテンプレート属性の値を検証します。 IPPオブジェクト（セクション3.1.2.1.5を参照。）操作属性のためにそれが実行する各ジョブテンプレート属性の値の類似構文の妥当性チェックを実行します。
a) that the length of each value is correct for the attribute syntax tag supplied by the client according to [RFC2911] Section 4.1.
a）は、各値の長さは、[RFC2911]セクション4.1に従ってクライアントによって供給された属性構文タグの正しいこと。
b) that the attribute syntax tag is correct for that attribute according to [RFC2911] Sections 4.2 to 4.4.
B）属性構文タグは[RFC2911]セクション4.4から4.2によれば、その属性のために適切であること。
c) that multiple values are supplied only for multi-valued attributes, i.e., that are 1setOf X according to [RFC2911] Sections 4.2 to 4.4.
C）複数の値のみ[RFC2911]セクション4.4から4.2に係る1setOf Xある多値属性、即ち、のために供給されます。
As in Section 3.1.2.1.5, if any of these syntactic checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or 'client-error-request-value-too-long' status code as appropriate, independent of the value of the "ipp-attribute-fidelity". Since such an error is most likely to be an error detected by a client developer, rather than by an end-user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
セクション3.1.2.1.5のように、これらの構文チェックのいずれかが失敗した場合、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求」または「クライアント誤り要求値-長すぎる」ステータスを返します適切なコード、「IPP属性忠実度」の値とは独立。このようなエラーがクライアントの開発者ではなく、エンドユーザが検出されたエラーである可能性が最も高いので、IPPオブジェクトはサポートされていないが、グループ属性やステータスメッセージのいずれかのエラーを持っていた属性の表示を返す必要はありません。これらの構文チェックのそれぞれについての説明は、明示的に次の表の最初のIF文で表現されます。
Each Job Template attribute MUST occur no more than once. If an IPP Printer receives a create request with multiple occurrences of a Job Template attribute, it MAY:
各ジョブテンプレート属性が一回以下で発生してはなりません。 IPPプリンタは、ジョブテンプレート属性が複数回出現してリクエストを作成受信した場合、それは可能性があります。
1. reject the operation and return the 'client-error-bad-request' error status code
1.操作を拒否し、「クライアント誤り悪い要求」はエラーステータスコードを返します
2. accept the operation and use the first occurrence of the attribute
2.操作を受け入れ、属性の最初の発生を使用
3. accept the operation and use the last occurrence of the attribute
3.操作を受け入れ、属性の最後の発生を使用
depending on implementation. Therefore, clients MUST NOT supply multiple occurrences of the same Job Template attribute in the Job Attributes group in the request.
実装に依存します。そのため、クライアントは要求にグループ属性のジョブで同じジョブテンプレート属性の複数の発生を供給してはなりません。
The process of validating a Job-Template attribute "xxx" against a Printer attribute "xxx-supported" can use the following validation algorithm (see section 3.2.1.2 in [RFC2911]).
Printer属性「XXX-サポート」次の検証アルゴリズムを使用することができます（[RFC2911]でセクション3.2.1.2を参照）に対するジョブ・テンプレートの属性「XXX」を検証するプロセス。
To validate the value U of Job-Template attribute "xxx" against the value V of Printer "xxx-supported", perform the following algorithm:
プリンタの値Vに対する値ジョブ・テンプレートの属性「XXX」のUを検証するには、「XXX-サポート」には、以下のアルゴリズムを実行します。
1. If U is multi-valued, validate each value X of U by performing the algorithm in Table 7 with each value X. Each validation is separate from the standpoint of returning unsupported values. Example: If U is "finishings" that the client supplies with 'staple', 'bind' values, then X takes on the successive values: 'staple', then 'bind'
Uは、多値の場合1は、それぞれの検証がサポートされない値を返すの観点から分離された各値Xと表7にアルゴリズムを実行することによってUの各値Xを検証します。例：Uは「仕上げ」「ステープル」とのクライアント用品いる、「バインド」の値である場合、Xは、連続した値になります：「主食」、そして「バインド」
2. If V is multi-valued, validate X against each Z of V by performing the algorithm in Table 7 with each value Z. If a value Z validates, the validation for the attribute value X succeeds. If it fails, the algorithm is applied to the next value Z of V. If there are no more values Z of V, validation fails. Example" If V is "sides-supported" with values: 'one- sided', 'two-sided-long', and 'two-sided-short', then Z takes on the successive values: 'one-sided', 'two-sided-long', and 'two-sided-short'. If the client supplies "sides" with 'two-sided- long', the first comparison fails ('one-sided' is not equal to 'two-sided-long'), the second comparison succeeds ('two-sided-long' is equal to 'two-sided-long"), and the third comparison ('two-sided-short' with 'two-sided-long') is not even performed.
2. Vは多値である場合、値Zが、Xが成功した属性値の妥当性を検証する場合、各値Zと表7にアルゴリズムを実行することにより、Vの各Zに対するXを検証します。それが失敗した場合VのZは、検証が失敗しない複数の値が存在しない場合、アルゴリズムは、Vの次の値（Z）に印加されます。値と 『辺がサポート「Vである場合には、』例： 『ワンが両面』、 『両面長い』、および 『両面短』、次にZは、連続値を取る： 『片側』、 「両面長」、および「両面短」。クライアント用品「両面」であれば「2-sided-の長い」と、最初の比較は（「一方的に」二次元「に等しくない障害が発生しました「両面短 『両面長』と（「（）、第2の比較が成功」両面長は「両面長「に等しい」）長い辺、及び第三の比較）であっても実行されません。
3. If both U and V are single-valued, let X be U and Z be V and use the validation rules in Table 7.
3. UとVの両方が単一値である場合、X U及びZはVであり、表7に検証ルールを使用することができます。
Table 7 - Rules for validating single values X against Z
表7 - Zに対して単一の値Xを検証するためのルール
Attribute syntax attribute syntax validated if: of X of Z
ZのXの次の場合に有効と構文属性の構文属性
integer rangeOfInteger X is within the range of Z
整数rangeOfInteger XはZの範囲内であります
uri uriScheme the uri scheme in X is equal to Z
URI uriScheme XにおけるURIスキームがZに等しいです
any boolean the value of Z is TRUE
Zのいずれかのブール値がTRUEであります
any any X and Z are of the same type and are equal.
いずれかの任意のX及びZは、同じタイプのものと同じです。
If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails. If the check fails, the IPP object copies the attribute to the Unsupported Attributes response group with its unsupported value. If the attribute contains more than one value, each value is checked and each unsupported value is separately copied, while supported values are not copied. If an IPP object doesn't recognize/support a Job Template attribute, i.e., there is no corresponding Printer object "xxx-supported" attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see the last row in the table below).
Printerオブジェクトの「XXX-サポート」属性の値が「は、値が」されていない場合（システム管理者が値を設定していないので）、チェックはいつも失敗します。チェックが失敗した場合は、サポートされていないとIPPオブジェクトのコピー属性は、そのサポートされていない値を持つレスポンス・グループ属性。属性が複数の値が含まれている場合は、それぞれの値がチェックされ、サポートされている値がコピーされていないながら、各サポートされていない値は、別途、コピーされます。 IPPオブジェクトが認識されない場合は/ジョブテンプレート属性をサポートする、すなわち、該当するプリンタオブジェクト「XXX-サポート」属性が存在しない、IPPオブジェクトは、未知またはサポートされていない属性として属性を扱います（表の最後の行を参照してください未満）。
If some Job Template attributes are supported for some document formats and not for others or the values are different for different document formats, the IPP object SHOULD take that into account in this validation using the value of the "document-format" supplied by the client (or defaulted to the value of the Printer's "document-format-default" attribute, if not supplied by the client). For example, if "number-up" is supported for the 'text/plain' document format, but not for the 'application/postscript' document format, the check SHOULD (though it NEED NOT) depend on the value of the "document-format" operation attribute. See "document-format" in [RFC2911] section 3.2.1.1 and 3.2.5.1.
いくつかのジョブテンプレート属性は、いくつかの文書フォーマットのためにサポートしていない他人のためか、値が異なる文書フォーマットごとに異なるされている場合は、IPPオブジェクトは、クライアントによって提供される「ドキュメント・フォーマット」の値を使用して、この検証で考慮にそれを取る必要があります（クライアントによって提供されていない場合や、プリンタの「ドキュメント形式デフォルト」属性の値にデフォルト設定）。例えば、「数アップは」「text / plainの」ドキュメントフォーマットのためにサポートされている場合が、「アプリケーション/追伸」ドキュメントフォーマットのために、チェックする必要があります（それはする必要はありませんけれども）は、「文書の値に依存しません-format」操作属性。 [RFC2911]で「ドキュメント・フォーマット」のセクション3.2.1.1と3.2.5.1を参照してください。
Note: whether the request is accepted or rejected is determined by the value of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all Job Template attribute supplied are examined and all unsupported attributes and/or values are copied to the Unsupported Attributes response group.
注：すべてのジョブテンプレート属性が供給されるように要求が承認または拒否されるかどうかは、次のステップで「IPP属性忠実度」属性の値によって決定され、検査され、すべてのサポートされない属性および/または値がコピーされていますサポートされていないが、応答グループ属性。
----------------------------------------------- job-priority (integer(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
そうでない場合には、単一の「整数」値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT supplied by the client, use the value of the Printer object's "job-priority-default" attribute at job submission time.
クライアントによって提供されていない場合、ジョブの投入時にPrinterオブジェクトの「仕事の優先順位デフォルト」属性の値を使用します。
IF NOT in the range 1 to 100, inclusive, copy the attribute and the unsupported value to the Unsupported Attributes response group.
1〜100、包括的、コピー属性とサポートされていないにサポートされていない値は、応答グループの属性の範囲内でない場合
Map the value to the nearest supported value in the range 1:100 as specified by the number of discrete values indicated by the value of the Printer's "job-priority-supported" attribute. See the formula in [RFC2911] Section 4.2.1.
範囲1に最も近いサポート値に値をマップ：100プリンタの「ジョブの優先サポート」属性の値で示される離散的な値の数によって指定されます。 [RFC2911]セクション4.2.1で式を参照してください。
job-hold-until (type3 keyword | name)
ジョブホールドまで（TYPE3キーワード|名）
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」や「名前」の値は、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT supplied by the client, use the value of the Printer object's "job-hold-until" attribute at job submission time.
クライアントによって提供されていない場合、ジョブ投入時にPrinterオブジェクトの「仕事ホールドまで」属性の値を使用します。
IF NOT in the Printer object's "job-hold-until-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「仕事ホールドまでのサポート」属性で、属性とサポートされていないにサポートされていない値をコピーしていない場合は、応答グループ属性。
job-sheets (type3 keyword | name)
ジョブシート（TYPE3キーワード|名）
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」や「名前」の値は、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "job-sheets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの中に属性を「ジョブ・シート・サポート」されていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
multiple-document-handling (type2 keyword)
マルチドキュメントハンドリング（TYPE2キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "multiple-document-handling-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「マルチドキュメント・ハンドリング・サポート」属性にされていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
copies (integer(1:MAX))
コピー（整数（1：MAX））
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
そうでない場合には、単一の「整数」値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in range of the Printer object's "copies-supported" attribute
Printerオブジェクトの「コピー・サポート」属性の範囲内にないIF
copy the attribute and the unsupported value to the Unsupported Attributes response group.
属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
finishings (1setOf type2 enum)
仕上げ（タイプ2列挙1セット）
IF NOT an 'enum' value(s) each with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
IF NOT「列挙」値（S）4つのオクテットに等しい長さを有するそれぞれ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the Printer object's "finishings-supported" attribute, copy the attribute and the unsupported value(s), but not any supported values, to the Unsupported Attributes response group.
IF NOT Printerオブジェクトの「仕上げでサポートされている」属性では、属性とサポートされていない値（S）ではなく、サポートされている任意の値をコピーし、サポートされていないに応答グループ属性。
page-ranges (1setOf rangeOfInteger(1:MAX))
ページ範囲（1setOf rangeOfInteger（1：MAX））
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 octets, REJECT/RETURN 'client-error-bad-request'.
IF NOT「rangeOfInteger」値（単数または複数）8つのオクテットに等しい長さを有するそれぞれ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF first value is greater than second value in any range, the ranges are not in ascending order, or ranges overlap, REJECT/RETURN 'client-error-bad-request'.
最初の値は、任意の範囲の第二の値よりも大きい場合、範囲が昇順になっていない、または範囲が重複/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value of the Printer object's "page-ranges-supported" attribute is 'false', copy the attribute to the Unsupported Attributes response group and set the value to the "out-of-band" 'unsupported' value.
値がPrinterオブジェクトの「ページ範囲をサポートする」属性が「偽」である場合、サポートされていない応答グループの属性と「アウトオブバンド」「サポートされていない」の値に値を設定する属性をコピーします。
sides (type2 keyword)
側面（TYPE2キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "sides-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「サイド・サポート」属性にされていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
number-up (integer(1:MAX))
数アップ（整数（1：MAX））
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
そうでない場合には、単一の「整数」値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT a value or in the range of one of the values of the Printer object's "number-up-supported" attribute, copy the attribute and value to the Unsupported Attribute response group.
IF NOT値またはPrinterオブジェクトの「数アップサポート」属性の値の1の範囲内で、サポートされていない属性応答グループに属性と値をコピーします。
orientation-requested (type2 enum)
配向要求（タイプ2列挙型）
IF NOT a single 'enum' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
IF NOTシングル「列挙型」の値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the Printer object's "orientation-requested-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「配向要求されたサポート」属性で、属性をコピーして、サポートされていないにサポートされていない値は、応答グループの属性れていない場合。
media (type3 keyword | name)
メディア（TYPE3キーワード|名）
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-error-bad-request'.
そうでない場合は、単一の「キーワード」や「名前」の値は、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
IF NOT in the Printer object's "media-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「メディア・サポート」属性にされていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
printer-resolution (resolution)
プリンタの解像度（分解能）
IF NOT a single 'resolution' value with a length equal to 9 octets, REJECT/RETURN 'client-error-bad-request'.
IF NOT 9つのオクテットに等しい長さを持つ単一の「解像度」値、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the Printer object's "printer-resolution-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「プリンタ解像度をサポートする」属性にされていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
print-quality (type2 enum)
印刷品質（タイプ2列挙型）
IF NOT a single 'enum' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
IF NOTシングル「列挙型」の値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。
IF NOT in the Printer object's "print-quality-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
Printerオブジェクトの「印刷品質・サポート」属性にされていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
unknown or unsupported attribute (i.e., there is no corresponding Printer object "xxx-supported" attribute)
未知の、またはサポートされない属性（すなわち、該当するプリンタオブジェクト「XXX-サポート」属性が存在しません）
IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax,
クライアントが供給する属性構文がサポートされていますが、長さは、その属性構文のための法的されていない場合は、
REJECT/RETURN 'client-error-bad-request' if the length of the attribute syntax is fixed or 'client-error-request-value-too-long' if the length of the attribute syntax is variable.
属性構文の長さが固定または属性構文の長さが可変である場合は、「クライアント誤り要求値-長すぎる」されている場合/ RETURN「クライアント誤り悪い要求」を拒否します。
ELSE copy the attribute and value to the Unsupported Attributes response group and change the attribute value to the "out-of-band" 'unsupported' value. Any remaining Job Template Attributes are either unknown or unsupported Job Template attributes and are validated algorithmically according to their attribute syntax for proper length (see below).
ELSEサポートされていない応答グループの属性と「アウトオブバンド」「サポートされていない」の値に属性値を変更するには、属性と値をコピーします。残りのジョブテンプレート属性が不明またはサポートされていないいずれかのジョブテンプレート属性であり、適切な長さのために自分の属性構文（下記参照）に応じてアルゴリズム検証されます。
-----------------------------------------------
If the attribute syntax is supported AND the length check fails, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' if the length of the attribute syntax is fixed or the 'client-error-request-value-too-long' status code if the length of the attribute syntax is variable. Otherwise, the IPP object copies the unsupported Job Template attribute to the Unsupported Attributes response group and changes the attribute value to the "out-of-band" 'unsupported' value. The following table shows the length checks for all attribute syntaxes. In the following table: "<=" means less than or equal, "=" means equal to:
属性構文がサポートされ、長さチェックが失敗した場合、IPPオブジェクトは、要求を拒否し、属性構文の長さが固定されている場合は、「クライアント誤り悪い要求」を返すか「クライアント誤り要求値 - 属性構文の長さが可変である場合には、ステータスコード「長すぎます。そうでない場合は、サポートされていないとIPPオブジェクトをコピーし、サポートされていないジョブテンプレート属性は、応答グループの属性と「アウトオブバンド」「サポートされていない」の値に属性値を変更します。次の表は、すべての属性構文のための長さのチェックを示しています。以下の表に「<=」は以下を意味し、「=」は等しい意味します。
Name Octet length check for read-write attributes
---------- ---------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 'textWithoutLanguage' <= 1023 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 'nameWithoutLanguage' <= 255 'keyword' <= 255 'enum' = 4 'uri' <= 1023 'uriScheme' <= 63 'charset' <= 63 'naturalLanguage' <= 63 'mimeMediaType' <= 255 'octetString' <= 1023 'boolean' = 1 'integer' = 4 'rangeOfInteger' = 8 'dateTime' = 11 'resolution' = 9 '1setOf X'
'textWithLanguage <= 1023 AND '自然言語'<= 63 'textWithoutLanguage'<= 1023 'nameWithLanguage'<= 255 AND '自然言語'<= 63 'nameWithoutLanguage'<= 255 'キーワード'<= 255 'のenum'= 4' URI '<= 1023 'uriScheme'<= 63 'のcharset'<= 63 '自然言語'<= 63 'mimeMediaType'<= 255 'OCTETSTRING'<= 1023 'ブール'= 1 '整数'= 4 'rangeOfInteger'= 8' dateTimeの」= 11 '解像度' = 9 '1setOf X'
Note: It's possible for a Printer to receive a zero length keyword in a request. Since this is a keyword, its value needs to be compared with the supported values. Assuming that the printer doesn't have any values in its corresponding "xxx-supported" attribute that are keywords of zero length, the comparison will fail. Then the request will be accepted or rejected depending on the value of "ipp-attributes-fidelity" being 'false' or 'true', respectively. No special handling is required for
注意：プリンタがリクエストに長さゼロのキーワードを受信することが可能です。これはキーワードであるため、その値はサポートされている値と比較する必要があります。プリンタは、長さがゼロのキーワードである、それに対応する「XXX-サポート」属性に任意の値を持っていないと仮定すると、比較が失敗します。そして、要求が受け入れられるか、それぞれ、「偽の」または「真」が「IPP-属性忠実度」の値に応じて拒否されます。特別な処理は必要ありません
Once all the Operation and Job Template attributes have been checked individually, the Printer object SHOULD check for any conflicting values among all the supported values supplied by the client. For example, a Printer object might be able to staple and to print on transparencies, however due to physical stapling constraints, the Printer object might not be able to staple transparencies. The IPP object copies the supported attributes and their conflicting attribute values to the Unsupported Attributes response group. The Printer object only copies over those attributes that the Printer object either ignores or substitutes in order to resolve the conflict, and it returns the original values which were supplied by the client. For example suppose the client supplies "finishings" equals 'staple' and "media" equals 'transparency', but the Printer object does not support stapling transparencies. If the Printer chooses to ignore the stapling request in order to resolve the conflict, the Printer objects returns "finishings" equal to 'staple' in the Unsupported Attributes response group. If any attributes are multi-valued, only the conflicting values of the attributes are copied.
すべての操作およびジョブテンプレートの属性が個別にチェックされた後は、Printerオブジェクトは、クライアントによって提供されるすべてのサポートされている値のうちのいずれかの矛盾する値を確認する必要があります。例えば、プリンタオブジェクトがステープルすることができるかもしれないし、OHPフィルムに印刷するには、しかし、物理的ステープル制約のために、Printerオブジェクトは、主食、OHPフィルムにできないことがあります。サポートされていないとIPPオブジェクトのコピーをサポートする属性とその矛盾する属性値は、応答グループ属性。プリンタオブジェクトが競合を解決するために、無視するか、代替のいずれか、それらの属性を超えるPrinterオブジェクトは、コピーのみ、それがクライアントによって供給された元の値を返します。例えば、クライアント用品「仕上げ」は「ステープル」と「メディア」イコール「透明性」を等しいと仮定しますが、Printerオブジェクトは、ステープル透明度をサポートしていません。プリンタは、競合を解決するために、ステープル要求を無視することを選択した場合、プリンタがサポートされていない応答グループ属性の「ステープル」に等しい戻り、「仕上げ」をオブジェクト。いずれかの属性が複数値の場合は、属性の唯一の競合の値がコピーされます。
Note: The decisions made to resolve the conflict (if there is a choice) is implementation dependent.
注意：（選択肢がある場合）、競合を解決するためになされた決定は、実装依存です。
If there were any unsupported Job Template attributes or unsupported/conflicting Job Template attribute values and the client supplied the "ipp-attribute-fidelity" attribute with the 'true' value, the Printer object REJECTS the request and return the status code:
あった場合はサポートされていないジョブテンプレート属性またはサポートされていない/ジョブテンプレートの属性値が競合し、クライアントが「本当」の値と「IPP属性忠実度」属性を供給し、Printerオブジェクトは、要求を拒否し、ステータスコードを返します。
1.'client-error-conflicting-attributes' status code, if there were any conflicts between attributes supplied by the client.
1.'client誤り矛盾-属性のステータスコード、クライアントが供給する属性間の競合があった場合。
2.'client-error-attributes-or-values-not-supported' status code, otherwise.
そうでない場合は、「ステータスコードを2.'client誤り属性、または値は、未サポート。
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
注意：サポートされていない操作は、属性または返される値は、このステップで返されるステータスには影響を与えません。サポートされていないOperation属性は、重大なエラーだった場合は、上記のは、既に前のステップでの要求を拒否しました。コントロールがサポートされていない操作属性が返されると、このステップに入った場合、彼らは重大なエラーではありません。
In general, the final results of Job processing are unknown at Job submission time. The client has to rely on notifications or polling to find out what happens at Job processing time. However, there are cases in which some Printers can determine at Job submission time that Job processing is going to fail. As an optimization, we'd like to have the Printer reject the Job in these cases.
一般的には、ジョブの処理の最終結果は、ジョブ送信時に不明です。クライアントは、ジョブの処理時に何が起こるかを調べるために、通知またはポーリングに頼る必要があります。ただし、一部のプリンタは、ジョブの処理が失敗しようとしているジョブ送信時に決定することができる場合があります。最適化として、我々はこれらのケースで仕事を拒否するプリンタを持っているしたいと思います。
There are three types of "processing" errors that might be detectable at Job submission time:
ジョブ送信時に検出可能であるかもしれない「処理」のエラーの3種類があります。
1. 'client-error-document-format-not-supported' : For the Print-Job, Send-Document, Print-URI, and Send-URI operations, if all these conditions are true:
1.「クライアント・エラー・ドキュメント・フォーマットがサポートされていない」：印刷ジョブの場合、印刷-URI、-文書を送信し、送信-URI操作を、これらのすべての条件に該当する場合：
- the Printer supports auto-sensing, - the request "document-format" operation attribute is 'application/octet-stream', - the Printer receives document data before responding, - the Printer auto-senses the document format before responding,
リクエスト「ドキュメントフォーマット」操作属性は、「アプリケーション/オクテットストリーム」で、 - - - プリンタが自動検出をサポートし、プリンタは、応答する前にデータを記録する受信 - プリンタ応答する前に、文書の書式を自動的に感知し、
- the sensed document format is not supported by the Printer
- 検出された文書フォーマットは、プリンタでサポートされていません
then the Printer should respond with 'client-error-document-format-not-supported' status.
その後、プリンタは「クライアント・エラー・ドキュメント・フォーマット・サポートされていない」状態で応答しなければなりません。
2. 'client-error-compression-error': For the Print-Job, Send-Document, Print-URI, and Send-URI operations, if all these conditions are true:
2.「クライアント・エラー圧縮エラー」：印刷ジョブの場合、印刷-URI、-文書を送信し、送信-URI操作を、これらのすべての条件に該当する場合：
- the client supplies a supported value for the "compression" operation attribute in the request - the Printer receives document data before responding, - the Printer attempts to decompress the document data before responding, - the document data cannot be decompressed using the algorithm specified by the "compression" operation attribute
- クライアントがリクエストで「圧縮」操作属性に対してサポート値を提供 - プリンタは、応答する前に文書データを受け取る - 文書データがで指定されたアルゴリズムを使用して解凍することはできません - プリンタは、応答する前に文書データを解凍しようとします「圧縮」操作属性
then the Printer should respond with 'client-error-compression-error' status.
その後、プリンタは「クライアント・エラー圧縮エラー」ステータスで応答する必要があります。
3. 'client-error-document-access-error': For the Print-URI, and Send-URI operations, if the Printer attempts and fails to pull the referenced document data before responding, it should respond with 'client-error-document-access-error' status.
3.「クライアント誤りドキュメントアクセスエラー」：印刷-URIの場合、および送信-URI操作を、プリンタの試みと応答する前に参照された文書データを引き出すために失敗した場合、それはクライアントエラー - で応答すべきですドキュメント・アクセス・エラー」状態。
Some Printers are not able to detect these errors until Job processing time. In that case, the errors are recorded in the corresponding job-state and job-state reason attributes. (There is no standard way for a client to determine whether a Printer can detect these errors at Job submission time.) For example, if auto-sensing happens AFTER the job is accepted (as opposed to auto-sensing at submit time before returning the response), the implementation aborts the job, puts the job in the 'aborted' state and sets the 'unsupported-document-format' value in the job's "job-state-reasons".
一部のプリンタは、ジョブの処理時間まで、これらのエラーを検出することができません。その場合には、エラーは、対応するジョブ状態とジョブ状態理由属性に記録されています。 （プリンタがジョブ送信時にこれらのエラーを検出できるかどうかを判断するために、クライアントのための標準的な方法はありません。）たとえば、ジョブが受理された後の自動検出返す前に時間を提出するのとは対照的に、自動感知は（発生した場合応答）、実装が仕事を中止し、「中止に」状態で仕事を置き、ジョブの「ジョブ状態の理由」で「サポートされていないドキュメントフォーマット」の値を設定します。
A client should always provide a valid "document-format" operation attribute whenever practical. In the absence of other information, a client itself may sniff the document data to determine document format.
いつでも実用的なクライアントは、常に有効な「ドキュメント・フォーマット」操作属性を提供する必要があります。他の情報がない場合、クライアント自体は、文書フォーマットを決定するために、文書データを盗聴することができます。
Auto sensing at Job submission time may be more difficult for the Printer when combined with compression. For auto-sensed Jobs, a client may be better off deferring compression to the transfer protocol layer, e.g.; by using the HTTP Content-Encoding header.
圧縮と組み合わせると、ジョブ送信時に自動検知は、プリンタのより難しいかもしれません。自動検知されたジョブの場合、クライアントは、例えば、転送プロトコル層に圧縮を延期したほうが良いかもしれ; HTTPコンテンツ符号化ヘッダを使用することによって。
3.1.2.3.3 For the Validate-Job operation, RETURN one of the success status codes
検証ジョブ操作については3.1.2.3.3、成功のステータスコードのいずれかを返します
If the requested operation is the Validate-Job operation, the Printer object returns:
要求された操作は、検証ジョブ操作の場合は、プリンタオブジェクトを返します：
1. the "successful-ok" status code, if there are no unsupported or conflicting Job Template attributes or values. 2. the "successful-ok-conflicting-attributes, if there are any conflicting Job Template attribute or values. 3. the "successful-ok-ignored-or-substituted-attributes, if there are only unsupported Job Template attributes or values.
1.「成功-OK」のステータスコード、全くサポートされていないか、矛盾するジョブテンプレート属性または値が存在しない場合。 2.「成功-OK-競合-属性、競合するジョブテンプレート属性または値が存在する場合。3.」成功-OK-無視-または置換 - 属性のみがある場合は、サポートされていないジョブテンプレート属性または値。
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
注意：サポートされていない操作は、属性または返される値は、このステップで返されるステータスには影響を与えません。サポートされていないOperation属性は、重大なエラーだった場合は、上記のは、既に前のステップでの要求を拒否しました。コントロールがサポートされていない操作属性が返されると、このステップに入った場合、彼らは重大なエラーではありません。
If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by the client), the Printer object:
「IPP属性忠実度は、」「偽の」（または、それがクライアントによって提供されていなかった）、プリンタオブジェクトに設定されている場合：
1. creates a Job object, assigns a unique value to the job's "job-uri" and "job-id" attributes, and initializes all of the job's other supported Job Description attributes. 2. removes all unsupported attributes from the Job object. 3. for each unsupported value, removes either the unsupported value or substitutes the unsupported attribute value with some supported value. If an attribute has no values after removing unsupported values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute). 4. for each conflicting value, removes either the conflicting value or substitutes the conflicting attribute value with some other supported value. If an attribute has no values after removing conflicting values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute).
1.は、ジョブオブジェクトを作成し、ジョブの「ジョブのuri」と「仕事-ID」属性に一意の値を割り当て、ジョブのサポートされている他のジョブ記述属性のすべてを初期化します。 2.ジョブオブジェクトからすべてのサポートされていない属性を削除します。 3.各サポートされていない値のため、サポートされていない値のいずれかを削除するか、サポートされている一部の値を持つサポートされていない属性値を代入します。属性は、それから、サポートされていない値を除去した後は値を持っていない場合は（ジョブ処理時には、通常のデフォルトの動作は、その属性のための場所を取るように）、属性は、ジョブオブジェクトから削除されます。 4.各競合値のために、競合値のいずれかを削除するか、他のいくつかのサポート値を持つ競合属性値を代入します。属性はそれから矛盾する値を除去した後は値を持っていない場合は（ジョブ処理時には、通常のデフォルトの動作は、その属性のための場所を取るように）、属性は、ジョブオブジェクトから削除されます。
If there were no attributes or values flagged as unsupported, or the value of 'ipp-attribute-fidelity" was 'false', the Printer object is able to accept the create request and create a new Job object. If the "ipp-attribute-fidelity" attribute is set to 'true', the Job Template attributes that populate the new Job object are necessarily all the Job Template attributes supplied in the create request. If the "ipp-attribute-fidelity" attribute is set to 'false', the Job Template attributes that populate the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. Thus, some of the requested Job Template attributes will not appear in the Job object because the Printer object did not support those attributes. The attributes that populate the Job object are persistently stored with the Job object for that Job. A Get-Job-Attributes operation on that Job object will return only those attributes that are persistently stored with the Job object.
属性またはサポートされていないとしてフラグが立てられた値、または値がなかった場合は「『『偽IPP属性-忠実だった』、Printerオブジェクトは、要求を作成し、新しいジョブオブジェクトを作成して受け入れることができる。もし、』 IPP属性-fidelityは」属性が新しいジョブオブジェクトを取り込む 『真』、ジョブテンプレート属性に設定されて供給必ずしもすべてのジョブテンプレート属性は、要求を作成します。場合は、 『IPP属性忠実度』属性が 『偽』に設定されています、ジョブテンプレートは、新しいジョブオブジェクトを移入する属性すべてのクライアントが供給されているジョブテンプレートは、サポートされているか、その値置換を持っているという属性。Printerオブジェクトがなかったのでこのように、要求されたジョブテンプレート属性の一部は、ジョブオブジェクトには表示されませんこれらの属性をサポートしています。ジョブオブジェクトを移入属性が永続的にそのジョブのジョブオブジェクトに格納されています。AそのジョブオブジェクトでGet-ジョブ・属性操作が永続的にJで保存されている属性のみを返します。 OBオブジェクト。
Note: All Job Template attributes that are persistently stored with the Job object are intended to be "override values"; that is, they that take precedence over whatever other embedded instructions might be in the document data itself. However, it is not possible for all Printer objects to realize the semantics of "override". End users may query the Printer's "pdl-override-supported" attribute to determine if the Printer either attempts or does not attempt to override document data instructions with IPP attributes.
注意：持続的にジョブオブジェクトに保存されているすべてのジョブテンプレート属性は、「オーバーライド値」であることを意図しています。つまり、彼らは他の埋め込まれた命令は、文書データそのものであるかもしれない何よりも優先されます。すべてのプリンタオブジェクトは、「オーバーライド」のセマンティクスを実現するためにしかし、それは不可能です。エンドユーザーは、プリンタが試みやIPP属性でドキュメントデータ指示を上書きしようとしないかどうかを判断するために、プリンタの「PDL-オーバーライド・サポート」属性を問い合わせることができます。
There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer does not use its default values to populate Job attributes when creating the new Job object; only Job Template attributes actually in the create request are used to populate the Job object. The Printer's default values are only used later at Job processing time if no other IPP attribute or instruction embedded in the document data is present.
プリンタがジョブテンプレート属性をサポートしており、その属性に設定された関連付けられたデフォルト値を持っているいくつかのケースがあります。新しいジョブオブジェクトを作成するとき、クライアントは対応する属性を供給しない場合には、ジョブを投入するために、デフォルト値を使用していないプリンタ属性。唯一のジョブテンプレートを作成し、要求に実際に属性ジョブオブジェクトを移植するために使用されています。文書データに埋め込まれた他のIPP属性または命令が存在しない場合はプリンタのデフォルト値は、のみジョブの処理時に、後に使用されています。
Note: If the default values associated with Job Template attributes that the client did not supply were to be used to populate the Job object, then these values would become "override values" rather than defaults. If the Printer supports the 'attempted' value of the "pdl-override-supported" attribute, then these override values could replace values specified within the document data. This is not the intent of the default value mechanism. A default value for an attribute is used only if the create request did not specify that attribute (or it was ignored when allowed by "ipp-attribute-fidelity" being 'false') and no value was provided within the content of the document data.
注：ジョブテンプレートは、クライアントが供給していないことを属性に関連付けられたデフォルト値は、ジョブオブジェクトを移入するために使用された場合には、これらの値は「オーバーライド値」ではなくデフォルトになります。プリンタは、「PDL-オーバーライド・サポート」属性の「未遂」の値をサポートしている場合、これらのオーバーライド値はドキュメントデータ内で指定された値を置き換えることができます。これはデフォルト値のメカニズムの意図ではありません。属性のデフォルト値を作成し、要求がその属性を指定しなかった場合にのみ使用されている（または「IPP属性忠実度」で「偽の」で許可されているとき、それは無視されました）とは値が文書データの内容の中で提供されていません。
If the client does not supply a value for some Job Template attribute, and the Printer does not support that attribute, as far as IPP is concerned, the result of processing that Job (with respect to the missing attribute) is undefined.
クライアントは、いくつかのジョブテンプレート属性の値、およびプリンタを供給しない場合は、限りIPPが懸念している、（行方不明の属性に関して）仕事が定義されていない処理の結果をその属性をサポートしていません。
Once the Job object has been created, the Printer object accepts the request and returns to the client:
ジョブオブジェクトが作成されると、Printerオブジェクトは、要求を受け入れ、クライアントに返します。
1. the 'successful-ok' status code, if there are no unsupported or conflicting Job Template attributes or values. 2. the 'successful-ok-conflicting-attributes' status code, if there are any conflicting Job Template attribute or values. 3. the 'successful-ok-ignored-or-substituted-attributes' status code, if there are only unsupported Job Template attributes or values.
1.「成功-OK」のステータスコード、全くサポートされていないか、矛盾するジョブテンプレート属性または値が存在しない場合。 2.「成功-OK-競合-属性のステータスコード、競合するジョブテンプレート属性または値が存在する場合。 3.「成功-OK-無視-または置換 - 属性のステータスコード、サポートされていないジョブテンプレート属性または値のみが存在する場合。
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
注意：サポートされていない操作は、属性または返される値は、このステップで返されるステータスには影響を与えません。サポートされていないOperation属性は、重大なエラーだった場合は、上記のは、既に前のステップでの要求を拒否しました。コントロールがサポートされていない操作属性が返されると、このステップに入った場合、彼らは重大なエラーではありません。
The Printer object also returns Job status attributes that indicate the initial state of the Job ('pending', 'pending-held', 'processing', etc.), etc. See Print-Job Response, [RFC2911] section 3.2.1.2.
Printerオブジェクトは、また、（「保留-開催された」、「処理」など、「保留」）など、[RFC2911]セクション3.2.1.2印刷ジョブ応答を参照してください。ジョブの初期状態を示すジョブステータス属性を返します。 。
The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing.
Printerオブジェクトは、追加ドキュメントコンテンツデータを受け入れ、どちらかそれを印刷、または後で処理するためにスプールを開始します。
The Printer object uses its own configuration and implementation specific algorithms for scheduling the Job in the correct processing order. Once the Printer object begins processing the Job, the Printer changes the Job's state to 'processing'. If the Printer object supports PDL override (the "pdl-override-supported" attribute set to 'attempted'), the implementation does its best to see that IPP attributes take precedence over embedded instructions in the document data.
Printerオブジェクトは、正しい処理順序でジョブをスケジュールするための独自の設定と実装の特定のアルゴリズムを使用しています。 Printerオブジェクトは、ジョブの処理を開始すると、プリンタは「処理」にジョブの状態を変更します。プリンタオブジェクトがPDLオーバーライド（「未遂」に設定された「PDL-オーバーライド・サポート」属性を）サポートしている場合、実装は、IPPは、文書データに埋め込まれた命令よりも優先属性のことを確認するために最善をつくします。
The Printer object continues to process the Job until it can move the Job into the 'completed' state. If an Cancel-Job operation is received, the implementation eventually moves the Job into the 'canceled' state. If the system encounters errors during processing that do not allow it to progress the Job into a completed state, the implementation halts all processing, cleans up any resources, and moves the Job into the 'aborted' state.
Printerオブジェクトは、それが完了した」状態にジョブを移動することができるまで、ジョブの処理を続行します。キャンセル・ジョブ操作を受信した場合、実装は、最終的には「キャンセル」状態にジョブを移動します。システムは、それが完成した状態に仕事を進行することはできません処理中にエラーが発生した場合、実装は、すべての処理を停止し、すべてのリソースをクリーンアップして、「中止に」状態にジョブを移動します。
Once the Job moves to the 'completed', 'aborted', or 'canceled' state, it is an implementation decision as to when to destroy the Job object and release all associated resources. Once the Job has been destroyed, the Printer would return either the "client-error-not-found" or "client-error-gone" status codes for operations directed at that Job.
仕事を「完了」、「中止さ」、または「キャンセル」状態に移行したら、それはジョブオブジェクトを破壊し、関連するすべてのリソースを解放する必要がある場合のような実装決定です。仕事が破壊された後、プリンタはその仕事に向け業務用「クライアント誤り-が見つからない」または「クライアント誤りなくなっ」ステータスコードのいずれかを返します。
Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" value for a sufficiently long time after a job has been destroyed, so that stale references kept by clients are less likely to access the wrong (newer) job.
注意：プリンタのオブジェクトは、十分に長い時間のために、「仕事-URI」または「ジョブID」の値を再使用しないほうが仕事が破壊された後、クライアントが保持して古い参照が間違っにアクセスする可能性が低いように（それ以降）の仕事。
Some Printer object implementations may support "ipp-attribute-fidelity" set to 'true' and "pdl-override-supported" set to 'attempted' and yet still not be able to realize exactly what the client specifies in the create request. This is due to legacy decisions and assumptions that have been made about the role of job instructions embedded within the document data and external job instructions that accompany the document data and how to handle conflicts between such instructions. The inability to be 100% precise about how a given implementation will behave is also compounded by the fact that the two special attributes, "ipp-attribute-fidelity" and "pdl-"override-supported", apply to the whole job rather than specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for "number-up". Character Sets, natural languages, and internationalization
一部のプリンタオブジェクトの実装は、「真」と「未遂」と、まだ、まだ、クライアントが作成要求に指定まさに実感することができないように設定された「PDL-オーバーライド・サポート」に設定し、「IPP属性忠実度」をサポートすることができます。これは、文書データを同行し、このような命令間の競合を処理する方法を文書データや外部ジョブ命令内に埋め込まれたジョブの指示の役割について行われたレガシーの決定および仮定によるものです。与えられた実装がどのように動作するかに関する正確な100％であることができないことは、2つの特別な属性、「IPP属性忠実度」と「pdl-」オーバーライド・サポート」は、ジョブ全体に適用されるという事実によって配合されるのではなく各属性の特定の値。たとえば、いくつかの実装は、ジョブテンプレートは「数アップ」以外の属性のほとんどすべてを上書きできる可能性があります。文字セット、自然言語、および国際化
This section discusses character set support, natural language support and internationalization.
このセクションでは、文字セットのサポート、自然言語のサポートと国際化について説明します。
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and indicate that UTF-8 and US-ASCII are supported by populating the Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An IPP object is required to code covert with as little loss as possible between the charsets that it supports, as indicated in the Printer's "charsets-supported" attribute.
IPPクライアントとIPPオブジェクトはUTF-8をサポートする必要があります。彼らは追加の文字セットをサポートするかもしれません。 IPPオブジェクトはまた、多くのクライアントがUS-ASCIIをサポートし、UTF-8およびUS-ASCIIが移入によってサポートされていることを示しているので、US-ASCIIをサポートすることが推奨されているプリンタの「文字セットでサポートされている」「UTF-8」と 'とUS-ASCII」の値。プリンタの「文字セット・サポート」属性に示されるように、IPPオブジェクトは、それがサポートする文字セットの間にできるだけ損失の少ない隠れたコーディングする必要があります。
How should the server handle the situation where the "attributes-charset" of the response itself is "us-ascii", but one or more attributes in that response is in the "utf-8" format?
どのサーバが応答自体の「属性 - 文字セット」は「US-ASCII」が、その応答内の1つのまたは複数の属性が「UTF-8」の形式であるのですか？状況に対処すべきですか
Example: Consider a case where a client sends a Print-Job request with "utf-8" as the value of "attributes-charset" and with the "job-name" attribute supplied. Later another client submits a Get-Job-Attribute or Get-Jobs request. This second request contains the "attributes-charset" with value "us-ascii" and "requested-attributes" attribute with exactly one value "job-name".
例：クライアントは、「アトリビュート文字セット」の値として、および付属の「ジョブ名」属性で「UTF-8」で印刷ジョブ要求を送信する場合を考えてみましょう。その後、別のクライアントは、Get-ジョブ属性または取得し、ジョブ要求を提出します。この2番目の要求は、1つの値で値が「US-ASCII」と「要求され、属性」属性「を、文字セットを属性」、「ジョブ名」が含まれています。
According to the RFC2911 document (section 3.1.4.2), the value of the "attributes-charset" for the response of the second request must be "us-ascii" since that is the charset specified in the request. The "job-name" value, however, is in "utf-8" format. Should the request be rejected even though both "utf-8" and "us-ascii" charsets are supported by the server? or should the "job-name" value be converted to "us-ascii" and return "successful-ok-conflicting-attributes" (0x0002) as the status code?
そのリクエストで指定された文字セットであるため、RFC2911文書（セクション3.1.4.2）によれば、第2の要求の応答のための「属性、文字セット」の値が「US-ASCII」でなければなりません。 「ジョブ名」の値は、しかし、「UTF-8」の形式です。両方の「UTF-8」と「US-ASCII」文字セットがサーバによってサポートされているにもかかわらず、要求が拒否されるべきか？または「ジョブ名」の値を「US-ASCII」に変換され、ステータスコードとして「成功-OK-矛盾-属性」（0×0002）を返すべきか？
Answer: An IPP object that supports both utf-8 (REQUIRED) and us-ascii, the second paragraph of section 3.1.4.2 applies so that the IPP object MUST accept the request, perform code set conversion between these two charsets with "the highest fidelity possible" and return 'successful-ok', rather than a warning 'successful-ok-conflicting-attributes, or an error. The printer will do the best it can to convert between each of the character sets that it supports -- even if that means providing a string of question marks because none of the characters are representable in US ASCII. If it can't perform such conversion, it MUST NOT advertise us-ascii as a value of its "attributes-charset-supported" and MUST reject any request that requests 'us-ascii'.
回答：IPPオブジェクトは、要求を受け入れる「最高にこれらの二つの文字セット間のコードセット変換を実行しなければなりませんように、UTF-8（REQUIRED）との両方のUS-ASCIIをサポートしているIPPオブジェクトは、セクション3.1.4.2の2番目の段落が適用されます忠実可能」と、むしろ警告「成功-OK-競合-属性、またはエラーよりも、 『成功-OK』を返します。プリンタは、文字の各々の間で変換することができる最善を尽くします、それがサポートしていることを設定します - それは文字のいずれも米国ASCIIで表現されていないため、疑問符の文字列を提供することを意味しても。それは、このような変換を実行できない場合は、その「属性 - 文字セット・サポート」の値として、US-ASCIIを広告してはならないと「US-ASCII」を要求したすべての要求を拒絶しなければなりません。
One IPP object implementation strategy is to convert all request text and name values to a Unicode internal representation. This is 16-bit and virtually universal. Then convert to the specified operation attributes-charset on output.
一つのIPPオブジェクト実装戦略は、Unicode内部表現へのすべての要求のテキストや名前の値を変換することです。これは、16ビットおよび事実上普遍的です。指定された操作は、出力に-文字セットを属性に続いて変換します。
Also it would be smarter for a client to ask for 'utf-8', rather than 'us-ascii' and throw away characters that it doesn't understand, rather than depending on the code conversion of the IPP object.
また、それはむしろ「US-ASCII」よりも、「UTF-8」を求めると、むしろIPPオブジェクトのコード変換に依存するよりも、それは理解していない文字を捨てるために、クライアントのために賢くなります。
3.1.2.3.12 What charset to return when an unsupported charset is requested (Issue 1.19)?
サポートされていない文字セットが要求されたときに返すためにどのような文字セット3.1.2.3.12（1.19号）？
Section 3.1.4.1 Request Operation attributes was clarified in November 1998 as follows:
次のようにセクション3.1.4.1要求操作属性は、1998年11月に明らかにしました。
All clients and IPP objects MUST support the 'utf-8' charset [RFC2044] and MAY support additional charsets provided that they are registered with IANA [IANA-CS]. If the Printer object does not support the client supplied charset value, the Printer object MUST reject the request, set the "attributes-charset" to 'utf-8' in the response, and return the 'client-error-charset-not-supported' status code and any 'text' or 'name' attributes using the 'utf-8' charset.
すべてのクライアントとIPPオブジェクトは、「UTF-8」のcharset [RFC2044]をサポートしなければならないと、彼らはIANA [IANA-CS]に登録されていることを提供される追加の文字セットをサポートするかもしれません。プリンタオブジェクトは、クライアントがcharset値を与えサポートしていない場合は、プリンタのオブジェクトは、要求を拒否応答で「UTF-8」に「属性-文字セット」に設定し、「クライアント・エラー・文字セット-not-を返さなければなりませんサポート」ステータスコードと任意の 『テキスト』か 『名は、UTF-8『文字セット』を使用して属性』。
Since the client and IPP object MUST support UTF-8, returning any text or name attributes in UTF-8 when the client requests a charset that is not supported should allow the client to display the text or name.
クライアントとIPPオブジェクトはUTF-8、任意のテキストを返すか、クライアントは、クライアントがテキストや名前を表示できるようにする必要があり、サポートされていない文字セットを要求したときに名前がUTF-8の属性をサポートしなければならないので。
Since such an error is a client error, rather than a user error, the client should check the status code first so that it can avoid displaying any other returned 'text' and 'name' attributes that are not in the charset requested.
このようなエラーは、クライアントのエラーではなく、ユーザーエラーですので、それは他のどの返さ「テキスト」と要求された文字セットに含まれていない「名前」属性が表示されないようすることができるように、クライアントは、最初のステータスコードをチェックする必要があります。
Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-supported (0x040D) was clarified in November 1998 as follows:
次のようにまた、[RFC2911]セクション14.1.4.14クライアント誤り文字セット-サポートされていない（0x040D）は、1998年11月に明らかにしました。
For any operation, if the IPP Printer does not support the charset supplied by the client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status and any 'text' or 'name' attributes using the 'utf-8' charset (see Section 3.1.4.1).
IPPプリンタは、「属性-のcharset」操作属性でクライアントによって提供されたcharsetをサポートしていない場合はすべての操作については、プリンタの操作を拒否し、この状態を返し、任意の「テキスト」か「名前」 'はを使用して属性をしなければなりませんUTF-8' 文字セット（セクション3.1.4.1を参照）。
The 'text' and 'name' attributes each have two forms. One has an implicit natural language, and the other has an explicit natural language. The 'textWithoutLanguage' and 'textWithLanguage' are the two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are the two 'name' forms. If a receiver (IPP object or IPP client) supports an attribute with attribute syntax 'text', it MUST support both forms in a request and a response. A sender (IPP client or IPP object) MAY send either form for any such attribute. When a sender sends a WithoutLanguage form, the implicit natural language is specified in the "attributes-natural-language" operation attribute, which all senders MUST include in every request and response.
「テキスト」と「名前」は、それぞれが2つのフォームを持っている属性。一つは、暗黙の自然言語を持ち、もう一方は、明示的な自然言語を持っています。 「textWithoutLanguage」と「textWithLanguageは」2「テキスト」の形式です。 「nameWithoutLanguage」と「nameWithLanguageは2 『名前』形態である。受信機（IPPオブジェクトかIPPクライアント）は 『テキスト』属性構文を持つ属性をサポートしている場合、それは、要求と応答の両方の形式をサポートしなければなりません。送信者（ IPPクライアントまたはIPPオブジェクトは）どのような属性のためのフォームのいずれかを送信することができる。送信者がWithoutLanguageフォームを送信すると、暗黙の自然言語はすべての送信者は、すべてのリクエストに含まなければならない「属性自然言語を」操作属性で指定されており、応答。
When a sender sends a WithLanguage form, it MAY be different from the implicit natural language supplied by the sender or it MAY be the same. The receiver MUST treat either form equivalently.
送信者がWithLanguageフォームを送信すると、送信者によって提供される暗黙の自然言語とは異なるであってもよいし、同じであってもよいです。受信機は、いずれかの治療同等に形成しなければなりません。
There is an implementation decision for senders, whether to always send the WithLanguage forms or use the WithoutLanguage form when the attribute's natural language is the same as the request or response.
送信者のための実装決定は、常にWithLanguageフォームを送信したり、属性の自然言語は、要求または応答と同じであるときWithoutLanguageフォームを使用するかどうか、があります。
The former approach makes the sender implementation simpler. The latter approach is more efficient on the wire and allows inter-working with non-conforming receivers that fail to support the WithLanguage forms. As each approach have advantages, the choice is completely up to the implementer of the sender.
前者のアプローチは、送信側の実装が簡単になります。後者のアプローチは、ワイヤ上で、より効率的であり、可能インターワーキングWithLanguageフォームをサポートすることができない不適合受信器と。各アプローチは、利点を持っているとして、選択は完全に差出人の実装次第です。
Furthermore, when a client receives a 'text' or 'name' job attribute that it had previously supplied, that client MUST NOT expect to see the attribute in the same form, i.e., in the same WithoutLanguage or WithLanguage form as the client supplied when it created the job. The IPP object is free to transform the attribute from the WithLanguage form to the WithoutLanguage form and vice versa, as long as the natural language is preserved. However, in order to meet this latter requirement, it is usually simpler for the IPP object implementation to store the natural language explicitly with the attribute value, i.e., to store using an internal representation that resembles the WithLanguage form.
クライアントが受信したときに「テキスト」または「名前」の仕事は、それが以前に供給していたことを属性場合に、クライアントが供給されるさらに、そのクライアントは同じWithoutLanguageまたはWithLanguageの形で、すなわち、同じ形式で属性を見ると予想してはいけませんそれは、ジョブを作成しました。 IPPオブジェクトは限り自然言語が保存されているとして、WithoutLanguageフォームおよびその逆にWithLanguageフォームから属性を変換して自由です。しかしながら、この後者の要件を満たすためには、WithLanguage形に似ている内部表現を使用して格納するために、即ち、属性値で明示的に自然言語を格納するためにIPPオブジェクトインプリメンテーションのために通常簡単です。
The IPP Printer MUST copy the natural language of a job, i.e., the value of the "attributes-natural-language" operation attribute supplied by the client in the create operation, to the Job object as a Job Description attribute, so that a client is able to query it. In returning a Get-Job-Attributes response, the IPP object MAY return one of three natural language values in the responses "attributes-natural-language" operation attribute: (1) that requested by the requester, (2) the natural language of the job, or (3) the configured natural language of the IPP Printer, if the requested language is not supported by the IPP Printer.
IPPプリンタは、ジョブの自然言語をコピーする必要があり、すなわち、ジョブの説明属性としてのJobオブジェクトの作成操作で、クライアントから供給される「属性自然言語」操作属性の値が、そのため、クライアントそれを照会することができます。応答を取得し、仕事を-属性を返すには、IPPオブジェクトは、「属性自然言語」操作属性を応答の3つの自然言語の値のいずれかを返すことがあります。（1）依頼者から要求されたこと、（2）自然言語仕事、または（3）IPPプリンタの構成された自然言語、リクエストされた言語は、IPPプリンタによってサポートされていない場合。
This "attributes-natural-language" Job Description attribute is useful for an IPP object implementation that prints start sheets in the language of the user who submitted the job. This same Job Description attribute is useful to a multi-lingual operator who has to communicate with different job submitters in different natural languages. This same Job Description attribute is expected to be used in the future to generate notification messages in the natural language of the job submitter.
この「属性自然言語」ジョブ記述属性は、プリントジョブを送信したユーザーの言語でシートを開始するIPPオブジェクト実装するのに便利です。これと同じ仕事内容属性は、異なる自然言語の異なるジョブ提出者と通信している多言語オペレータに便利です。これと同じ仕事内容属性は、ジョブ提出者の自然言語で通知メッセージを生成するために、将来的に使用することが期待されています。
Early drafts of [RFC2911] contained a job-level natural language override (NLO) for the Get-Jobs response. A job-level (NLO) is an (unrequested) Job Attribute which then specified the implicit natural language for any other WithoutLanguage job attributes returned in the response for that job. Interoperability testing of early implementations showed that no one was implementing the job-level NLO in Get-Job responses. So the job-level NLO was eliminated from the Get-Jobs response. This simplification makes all requests and responses consistent in that the implicit natural language for any
[RFC2911]の初期の草案は、Get-ジョブ応答のためのジョブレベル自然言語オーバーライド（NLO）を含有していました。ジョブレベル（NLO）は、その後、他のWithoutLanguageジョブ属性の暗黙の自然言語は、そのジョブの応答で返さ指定された（非要求）ジョブ属性です。初期の実装の相互運用性テストは、誰もがGET-ジョブ応答のジョブレベルNLOを実施しなかったことを示しました。だから、ジョブレベルNLOはGet-ジョブの応答から排除されました。この単純化は任意のためにその暗黙の自然言語で一貫性のあるすべての要求と応答を行い
WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute.
WithoutLanguage「テキスト」または「名前」の形式は、常に要求のか、レスポンスの「属性自然言語」操作属性で供給されています。
This section corresponds to [RFC2911] section 3.1.6 "Operation Response Status Codes and Status Messages". This section lists all status codes once in the first operation (Print-Job). Then it lists the status codes that are different or specialized for subsequent operations under each operation.
このセクションでは、[RFC2911]セクション3.1.6「動作レスポンスのステータスコードとステータスメッセージ」に対応します。このセクションでは、最初の操作（印刷ジョブ）に一度、すべてのステータスコードを示します。それは、各操作の下でその後の操作のために異なるまたは特殊であるステータスコードを示します。
The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 13 in [RFC2911] for a more complete description of each status code.
Printerオブジェクトは、示された理由については、以下の「ステータスコード」の値のいずれかを返さなければなりません。文書データの全てが成功またはエラーレスポンスを返す前に受け入れされているかどうかは、実装に依存します。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the Job object has been created and the "job-id", and "job-uri" assigned and returned in the response:
以下の成功ステータスコードについては、ジョブオブジェクトが作成され、「ジョブID」、および「仕事-URI」応答に割り当てられたと返されました：
successful-ok: no request attributes were substituted or ignored.
成功 - OK：何の要求属性は置換しないか無視されました。
successful-ok-ignored-or-substituted-attributes: some supplied (1) attributes were ignored or (2) unsupported attribute syntaxes or values were substituted with supported values or were ignored. Unsupported attributes, attribute syntax's, or values MUST be returned in the Unsupported Attributes group of the response.
成功-OK-置換無視-または-属性：一部が供給（1）属性は無視されたか（2）サポートされていない属性構文か値がサポートされる値で置換されていたか、無視されました。サポートされていない属性は、構文の属性、または値は、応答のサポートされていない属性グループに返さなければなりません。
successful-ok-conflicting-attributes: some supplied attribute values conflicted with the values of other supplied attributes and were either substituted or ignored. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response as supplied by the client.
成功-OK-競合-属性：その他の付属属性の値と競合し、いずれかの置換または無視されたいくつかの供給の属性値。クライアントによって供給される応答のサポートされていない属性グループに返さなければならない他の属性と競合し、置換または無視されている属性または値。
[RFC2911] section 3.1.6 Operation Status Codes and Messages states:
[RFC2911]セクション3.1.6動作ステータスコードとメッセージの状態：
If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 13 in [RFC2911]): 'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server- error-operation-not-supported', and 'server-error-version-not-supported'. In this case, it MUST set the value of the "attributes-charset" operation attribute to 'utf-8' in the error response.
「クライアント・エラー：Printerオブジェクトは、「ステータスメッセージ」操作属性をサポートしている場合、それは（[RFC2911]でセクション13を参照）、次のエラーステータスコードについてステータスメッセージを返すために必要な「UTF-8」文字セットを使用すべきです-bad要求 ' 'クライアント・エラー文字セットが-サポートされていない'、 'サーバーエラー内部エラー'、 'サーバ - エラー・操作 - サポートされていない'、および' サーバー・エラー・バージョン-not- 」サポートされています。この場合、エラー応答で「UTF-8」に「属性-のcharset」操作属性の値を設定しなければなりません。
For the following error status codes, no job is created and no "job-id" or "job-uri" is returned:
以下のエラーステータスコードについては、何のジョブが作成されずに、「ジョブID」または「ジョブ-URI」が返されます：
client-error-bad-request: The request syntax does not conform to the specification.
クライアント誤り悪い要求：要求の構文は、仕様に準拠していません。
client-error-forbidden: The request is being refused for authorization or authentication reasons. The implementation security policy is to not reveal whether the failure is one of authentication or authorization.
クライアント・エラー禁制：要求が承認または認証の理由で拒否されています。実装のセキュリティポリシーは、障害が認証または認可の一つであるかどうかを明らかにしないことです。
client-error-not-authenticated: Either the request requires authentication information to be supplied or the authentication information is not sufficient for authorization.
クライアント・エラー・認証されません：要求が供給されるように、認証情報を要求するか、認証情報は、認可のためには十分ではないのどちらか。
client-error-not-authorized: The requester is not authorized to perform the request on the target object.
クライアント誤り - 権限がありません：要求者は、ターゲットオブジェクトに要求を実行するために許可されていません。
client-error-not-possible: The request cannot be carried out because of the state of the system. See also 'server-error-not-accepting-jobs' status code, which MUST take precedence if the Printer object's "printer-accepting-jobs" attribute is 'false'.
クライアント誤り-ことができません：要求が原因でシステムの状態を行うことができません。 Printerオブジェクトの「プリンタ受容-仕事」属性が「偽」である場合には優先されなければならない、また、「サーバー・エラー・-受け入れていない - のジョブのステータスコードを参照してください。
client-error-timeout: not applicable.
クライアント・エラータイムアウト：適用されません。
client-error-not-found: the target object does not exist.
クライアント・エラー - 見つかりません：ターゲット・オブジェクトが存在しません。
client-error-gone: the target object no longer exists and no forwarding address is known.
クライアント誤りなくなっ：ターゲットオブジェクトがもはや存在しないと何のフォワーディングアドレスが知られていません。
client-error-request-entity-too-large: the size of the request and/or print data exceeds the capacity of the IPP Printer to process it.
クライアント誤り要求エンティティ大きすぎる：要求および/または印刷データのサイズがそれを処理するIPPプリンタの容量を超えています。
client-error-request-value-too-long: the size of request variable length attribute values, such as 'text' and 'name' attribute syntax's, exceed the maximum length specified in [RFC2911] for the attribute and MUST be returned in the Unsupported Attributes Group.
クライアント誤り要求値-長すぎる：要求可変長属性値の大きさ、たとえば「テキスト」と「名前」、構文の属性属性の[RFC2911]で指定された最大長を超えて返さなければならないとして、サポートされていないグループ属性。
supplied is not supported. The "document-format" attribute with the unsupported value MUST be returned in the Unsupported Attributes Group. This error SHOULD take precedence over any other 'xxx-not-supported' error, except 'client-error-charset-not-supported'.
供給はサポートされていません。サポートされていない値を持つ「ドキュメント・フォーマット」属性がサポートされていないグループの属性に返さなければなりません。このエラーは、「クライアント・エラー・文字セット-サポートされていない」を除いて、他の「XXX-サポートされていません」というエラーに優先を取る必要があります。
client-error-attributes-or-values-not-supported: one or more supplied attributes, attribute syntax's, or values are not supported and the client supplied the "ipp-attributes-fidelity" operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below.
クライアント誤り属性-または値-サポートされていません：1つの以上の付属属性、構文の属性、または値がサポートされており、クライアントが「真」値と「IPP-属性忠実度」操作属性を供給されていません。以下に説明するように彼らは、サポートされていない属性グループに返さなければなりません。
client-error-uri-scheme-not-supported: not applicable.
クライアント・エラー-URI-スキーム-サポートされていません：適用されません。
client-error-charset-not-supported: the charset supplied in the "attributes-charset" operation attribute is not supported. The Printer's "configured-charset" MUST be returned in the response as the value of the "attributes-charset" operation attribute and used for any 'text' and 'name' attributes returned in the error response. This error SHOULD take precedence over any other error, unless the request syntax is so bad that the client's supplied "attributes-charset" cannot be determined.
- 文字セットが-サポートされていないクライアントエラー：「属性-のcharset」操作属性で供給されるcharsetがサポートされていません。プリンタの「構成された-charsetが」「属性、文字セット」操作属性の値として応答で返され、エラー応答で返された属性任意の「テキスト」と「名前」を使用しなければなりません。要求の構文は、クライアントの供給「属性 - 文字セット」は決定できないほど悪くない限り、このエラーは、他のエラーに優先を取る必要があります。
client-error-conflicting-attributes: one or more supplied attribute values conflicted with each other and the client supplied the "ipp-attributes-fidelity" operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below.
クライアント・エラー・競合・属性：互いとクライアントと競合一の以上提供された属性値が「真」の値と「IPP-属性忠実度」操作属性を供給しました。以下に説明するように彼らは、サポートされていない属性グループに返さなければなりません。
server-error-internal-error: an unexpected condition prevents the request from being fulfilled.
サーバーエラー内部エラー：予期しない条件が満たされてからの要求を防ぎます。
server-error-operation-not-supported: not applicable (since Print-Job is REQUIRED).
サーバー・エラー・操作 - サポートされていません：適用されません（印刷ジョブが必要とされるため）。
server-error-service-unavailable: the service is temporarily overloaded.
サーバー・エラー・サービス使用できない：サービスが一時的に過負荷になっています。
server-error-version-not-supported: the version in the request is not supported. The "closest" version number supported MUST be returned in the response.
サーバー・エラー・バージョン - サポートされていません：リクエスト内のバージョンがサポートされていません。サポート「最も近い」バージョン番号が応答で返さなければなりません。
server-error-device-error: a device error occurred while receiving or spooling the request or document data or the IPP Printer object can only accept one job at a time.
サーバー・エラー・デバイス・エラー：受信または一度に一つの仕事を受け入れることができ、要求や文書データやIPP Printerオブジェクトをスプールしながら、デバイスエラーが発生しました。
server-error-temporary-error: a temporary error such as a buffer full write error, a memory overflow, or a disk full condition occurred while receiving the request and/or the document data.
サーバーエラー一時的エラー：要求及び/又は文書データを受信しながら、そのようなバッファフル書き込みエラー、メモリのオーバーフロー、またはディスク満杯状態として一時的なエラーが発生しました。
server-error-not-accepting-jobs: the Printer object's "printer-is-not-accepting-jobs" attribute is 'false'.
サーバー・エラーが-受け入れていない - 仕事を：Printerオブジェクトの「プリンタ - - - 受け付けていません - ジョブ」属性が「偽」です。
server-error-busy: the Printer is too busy processing jobs to accept another job at this time.
サーバー・エラー・ビジー：プリンタはこの時点で別の仕事を受け入れるために、あまりにも忙しい処理ジョブです。
server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the document data.
サーバー・エラー・ジョブキャンセル：クライアントは、文書データを送信している間にジョブがオペレータまたはシステムによって取り消されました。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Print-URI with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門と違いが-URIを印刷するために適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
client-error-uri-scheme-not-supported: the URI scheme supplied
in the "document-uri" operation attribute is not supported and
is returned in the Unsupported Attributes group.
server-error-operation-not-supported: the Print-URI operation is not supported.
サーバー・エラー・操作 - サポートされていません：印刷-URI操作がサポートされていません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Validate-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが、仕事を検証するために適用されます。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Create-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブの作成に適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
server-error-operation-not-supported: the Create-Job operation
is not supported.
client-error-multiple-document-jobs-not-supported: while the Create-Job and Send-Document operations are supported, this implementation doesn't support more than one document with data.
クライアント・エラー・マルチドキュメント・ジョブ - - サポートされていません： - ジョブの作成および送信-ドキュメントを操作がサポートされていますが、この実装では、データを複数のドキュメントをサポートしていません。
All of the Print-Job status codes described in Section
3.1.3.1.1 Print-Job Response are applicable to the Get-
Printer-Attributes operation with the following
specialization's and differences. See Section 13 in [RFC2911]
for a more complete description of each status code.
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードについては、要求された属性は応答して、グループ3に返されます。
successful-ok: no operation attributes or values were substituted or ignored (same as Print-Job) and no requested attributes were unsupported.
成功 - OK：何も操作属性や値はありませんが、置換または（印刷ジョブと同じ）は無視され、何も要求された属性がサポートされていないではなかったました。
successful-ok-ignored-or-substituted-attributes: The "requested-attributes" operation attribute MAY, but NEED NOT, be returned with the unsupported values.
成功-OK-無視-または置換 - 属性：「要求され、属性」操作属性MAYを、その必要はない、サポートされていない値で返されます。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For the error status codes, Group 3 is returned containing no attributes or is not returned at all:
エラーステータスコードについては、グループ3には属性を含まない返されるか、まったく返されません。
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job, except that no print data is involved.
クライアント誤り要求エンティティ大きすぎる：なし印刷データが含まれないことを除いて、印刷ジョブと同じ。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).
クライアント誤り属性-または値-サポートされていません：適用できない、サポートされていない操作属性および/または（上記参照）の値を無視しなければなりませんし、適切な成功コードが返さ以来。
client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved.
クライアント誤り矛盾-属性：印刷ジョブと同じ、「IPP属性忠実度は」関与していないことを除いて。
server-error-operation-not-supported: not applicable (since Get-Printer-Attributes is REQUIRED).
サーバー・エラー・操作 - サポートされていません：適用されません（GET-プリンタ-属性以降が必要です）。
server-error-device-error: same as Print-Job, except that no document data is involved.
サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、何の文書データが含まれないことを除いて。
server-error-temporary-error: same as Print-Job, except that no document data is involved.
サーバーエラー一時的なエラー：なし文書データが含まれないことを除いて、印刷ジョブと同じ。
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-busy: same as Print-Job, except the IPP object is too busy to accept even query requests.
サーバー・エラー・ビジー：印刷ジョブと同じ、IPPオブジェクトを除いても、クエリ要求を受け入れることができないくらい忙しいです。
server-error-job-canceled: not applicable.
サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to the Get-Jobs operation with the following specialization's and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブに記述されたプリント・ジョブのステータスコードはすべて、応答は以下の専門のとの違いでは、Get-ジョブの操作に適用されます。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードについては、要求された属性は応答して、グループ3に返されます。
successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功-OK-無視-または置換 - 属性：ゲット・プリンタ・属性（セクション3.1.3.1.5を参照）と同じ。
successful-ok-conflicting-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功-OK-競合-属性：ゲット・プリンタ・属性（セクション3.1.3.1.5を参照）と同じ。
For any error status codes, Group 3 is returned containing no attributes or is not returned at all. The following brief error status code descriptions contain unique information for use with Get-Jobs operation. See section 14 for the other error status codes that apply uniformly to all operations:
すべてのエラーステータスコードについては、グループ3には属性を含まない返されるか、まったく返されません。次の簡単なエラーステータスコードの説明は、Get-ジョブ操作で使用するための固有の情報が含まれています。すべての操作に均等に適用されます他のエラーステータスコードのためのセクション14を参照してください。
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job, except that no print data is involved.
クライアント誤り要求エンティティ大きすぎる：なし印刷データが含まれないことを除いて、印刷ジョブと同じ。
client-error-document-format-not-supported: not applicable.
クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).
クライアント誤り属性-または値-サポートされていません：適用できない、サポートされていない操作属性および/または（上記参照）の値を無視しなければなりませんし、適切な成功コードが返さ以来。
client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved.
クライアント誤り矛盾-属性：印刷ジョブと同じ、「IPP属性忠実度は」関与していないことを除いて。
server-error-operation-not-supported: not applicable (since Get-Jobs is REQUIRED).
サーバー・エラー・操作 - サポートされていません：（GET-ジョブズが必要であるため）は適用されません。
server-error-device-error: same as Print-Job, except that no document data is involved.
サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、何の文書データが含まれないことを除いて。
server-error-temporary-error: same as Print-Job, except that no document data is involved.
サーバーエラー一時的なエラー：なし文書データが含まれないことを除いて、印刷ジョブと同じ。
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-job-canceled: not applicable.
サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Pause-Printer with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、プリンタを一時停止するために適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the Printer object is being stopped from scheduling jobs on all its devices.
以下の成功ステータスコードについては、Printerオブジェクトは、そのすべてのデバイス上でジョブをスケジュールから停止しています。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For any of the error status codes, the Printer object has not been stopped from scheduling jobs on all its devices.
エラーステータスコードのいずれかの場合、Printerオブジェクトは、そのすべてのデバイス上でジョブをスケジュールから停止されていません。
client-error-not-possible: not applicable.
クライアント誤り-ことができません：適用されません。
client-error-not-found: the target Printer object does not exist.
クライアント・エラー - 見つかりません：対象のプリンターオブジェクトが存在しません。
client-error-gone: the target Printer object no longer exists and no forwarding address is known.
クライアント誤りなくなっ：目標Printerオブジェクトがもはや存在しないと何のフォワーディングアドレスが知られていません。
client-error-request-entity-too-large: same as Print-Job, except no document data is involved.
クライアント・エラーが要求-大きすぎるエンティティ：なし文書データを除いて、印刷ジョブと同じが関与しています。
client-error-document-format-not-supported: not applicable.
クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。
client-error-conflicting-attributes: same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved.
クライアント・エラー・競合・属性：印刷ジョブと同じ、プリンタの「プリンタ受容され、ジョブが」属性が関与していないことを除いて。
server-error-operation-not-supported: the Pause-Printer operation is not supported.
サーバー・エラー・操作 - サポートされていません：一時停止 - プリンタの操作がサポートされていません。
server-error-device-error: not applicable.
サーバー・エラー・デバイス・エラー：適用されません。
server-error-temporary-error: same as Print-Job, except no document data is involved.
サーバーエラー一時的なエラー：印刷ジョブと同じ、ない文書データを除いては、関与しています。
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-job-canceled: not applicable.
サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Pause-Printer are applicable to Resume-Printer. See Section 13 in [RFC2911] for a more complete description of each status code.
専門の一時停止、プリンタの説明で、セクション3.1.3.1.1印刷ジョブ応答した印刷ジョブのステータス・コードの説明のすべては、プリンタを再開するために適用されます。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the Printer object resumes scheduling jobs on all its devices.
以下の成功ステータスコードについては、Printerオブジェクトは、そのすべてのデバイス上でスケジュールジョブを再開します。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For any of the error status codes, the Printer object does not resume scheduling jobs.
エラーステータスコードのいずれかの場合、Printerオブジェクトは、ジョブのスケジューリングを再開しません。
server-error-operation-not-supported: the Resume-Printer
operation is not supported.
3.1.3.1.8.1 What about Printers unable to change state due to an error condition?
3.1.3.1.8.1によるエラー状態に状態を変更することができないプリンタについては何？
If, in case, the IPP printer is unable to change its state due to some problem with the actual printer device (say, it is shut down or there is a media-jam as indicated in [RFC2911]), what should be the result of the "Resume-Printer" operation? Should it still change the 'printer-state-reasons' and return success or should it fail ?
場合には、IPPプリンタは（たとえば、それがシャットダウンまたは[RFC2911]に示されるようにメディア詰まりがある場合）、どのような結果でなければならないによる実際のプリンタ装置といくつかの問題にその状態を変更することができない、場合に「レジューム・プリンタ」の動作の？それはまだ「プリンタ状態の理由」を変更し、成功を返すか、それは失敗するべきか？
The Resume-Printer operation must clear the 'paused' or 'moving-to-paused' 'printer-state-message'. The operation must return a 'successful-ok' status code.
再開 - プリンタの操作は、「一時停止」または「移動-にポーズ」「プリンタ状態メッセージ」をクリアする必要があります。操作は「成功-OK」のステータスコードを返す必要があります。
If the Resume-Printer operation succeeds, what should be the value of "printer-state" and who should take care of the "printer-state" attribute value later on ?
再開 - プリンタの操作が成功した場合、何が「プリンタ状態」の値である必要があり、誰が、後に「プリンタ状態」属性値の世話をする必要がありますか？
The Resume-Printer operation may change the "printer-state-reasons" value.
再開 - プリンタの操作は、「プリンタ状態の理由」の値を変更することがあります。
The "printer-state" will change to one of three states:
「プリンタ状態」の3つの状態のいずれかに変更されます：
3. current state (i.e. no change) an error condition is present (e.g. media jam)
3.現在の状態（すなわち、変化なし）、エラー状態が存在する（例えばメディアジャム）
In the third case the "printer-state-reason" will be cleared by automata when it detects the error condition no longer exists. The "printer-state" will move to 'idle' or 'processing' when conditions permit. (i.e. no more error conditions)
それはエラー状態がもう存在を検出しないとき三番目のケースでは、「プリンタ状態理由は、」オートマトンによってクリアされます。条件が許すとき、「プリンタ状態は、」「アイドル」または「処理」に移動します。 （すなわち、これ以上のエラー状態）
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Pause-Printer are applicable to Purge-Printer. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答した印刷ジョブのステータス・コードの説明のすべての専門の一時停止、プリンタの説明では、プリンタをパージするために適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the Printer object purges all it's jobs.
以下の成功ステータスコードについては、Printerオブジェクトは、すべてのそれのジョブを削除します。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For any of the error status codes, the Printer object does not purge any jobs.
エラーステータスコードのいずれかの場合、Printerオブジェクトは、すべてのジョブを削除しません。
server-error-operation-not-supported: the Purge-Printer
operation is not supported.
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specialization's and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべては、以下の専門のとの違いとは、Get-プリンタ・属性操作にも適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the document has been added to the specified Job object and the job's "number-of-documents" attribute has been incremented:
以下の成功ステータスコードの場合、文書は、指定されたジョブオブジェクトに追加されており、ジョブの「ナンバー・オブ・ドキュメント」属性がインクリメントされています。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For the error status codes, no document has been added to the Job object and the job's "number-of-documents" attribute has not been incremented:
エラーステータスコードについては、一切の文書は、ジョブオブジェクトに追加されていないとジョブの「ナンバー・オブ・ドキュメント」属性がインクリメントされていません。
client-error-not-possible: Same as Print-Job, except that the
Printer's "printer-is-accepting-jobs" attribute is not
involved, so that the client is able to finish submitting a job
that was created with a Create-Job operation after this
attribute has been set to 'true'. Another condition is that
the state of the job precludes Send-Document, i.e., the job has already been closed out by the client. However, if the IPP
Printer closed out the job due to timeout, the 'client-error-
timeout' error status SHOULD be returned instead.
client-error-timeout: This request was sent after the Printer closed the job, because it has not received a Send-Document or Send-URI operation within the Printer's "multiple-operation-time-out" period .
クライアント・エラータイムアウト：プリンタがジョブを閉じた後に、それはプリンタの「複数の操作タイムアウト」期間内に送信-ドキュメント受信または送信-URI操作していないため、この要求は、送られました。
client-error-request-entity-too-large: same as Print-Job.
クライアント誤り要求エンティティ大きすぎる：印刷ジョブと同じ。
client-error-conflicting-attributes: same as Print-Job, except that "ipp-attributes-fidelity" operation attribute is not involved..
クライアント誤り矛盾-属性：印刷ジョブと同じ、「IPP-属性忠実度」操作属性が関与していないことを除いて。..
server-error-operation-not-supported: the Send-Document request is not supported.
サーバー・エラー・操作 - サポートされていません：センド・資料請求はサポートされていません。
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the data.
サーバー・エラー・ジョブキャンセル：クライアントがデータを送信している間にジョブがオペレータまたはシステムによって取り消されました。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Send-Document are applicable to Send-URI. See Section 13 in [RFC2911] for a more complete description of each status code.
専門のために説明して、セクション3.1.3.1.1印刷ジョブ応答した印刷ジョブのステータス・コードの説明のすべての送信は、ドキュメント-URIを送信するために適用されます。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
client-error-uri-scheme-not-supported: the URI scheme supplied
in the "document-uri" operation attribute is not supported and
the "document-uri" attribute MUST be returned in the
Unsupported Attributes group.
server-error-operation-not-supported: the Send-URI operation is not supported.
サーバー・エラー・操作 - サポートされていません：送信-URI操作がサポートされていません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Cancel-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブをキャンセルするために適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the Job object is being canceled or has been canceled:
以下の成功ステータスコードについては、ジョブオブジェクトがキャンセルされているか、またはキャンセルされました：
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For any of the error status codes, the Job object has not been canceled or was previously canceled.
エラーステータスコードのいずれかの場合は、ジョブオブジェクトがキャンセルされていないか、または以前にキャンセルされました。
client-error-not-possible: The request cannot be carried out
because of the state of the Job object ('completed',
'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object does not exist.
クライアント・エラー - 見つかりません：ターゲットプリンターおよび/またはジョブオブジェクトが存在しません。
client-error-gone: the target Printer and/or Job object no longer exists and no forwarding address is known.
なくなってクライアントエラー：対象のプリンターおよび/またはジョブオブジェクトはもはや存在せず、転送アドレスは知られていません。
client-error-request-entity-too-large: same as Print-Job, except no document data is involved.
クライアント・エラーが要求-大きすぎるエンティティ：なし文書データを除いて、印刷ジョブと同じが関与しています。
client-error-document-format-not-supported: not applicable.
クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and values MUST be ignored.
クライアント誤り属性-または値-サポートされていません：適用できない、サポートされていない操作の属性と値が無視されなければならないからです。
client-error-conflicting-attributes: same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved.
クライアント・エラー・競合・属性：印刷ジョブと同じ、プリンタの「プリンタ受容され、ジョブが」属性が関与していないことを除いて。
server-error-operation-not-supported: not applicable (Cancel-Job is REQUIRED).
サーバー・エラー・操作 - サポートされていません：（キャンセル-仕事を必要とする）は適用されません。
server-error-device-error: same as Print-Job, except no document data is involved.
サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、ない文書データを除いては、関与しています。
server-error-temporary-error: same as Print-Job, except no document data is involved.
サーバーエラー一時的なエラー：印刷ジョブと同じ、ない文書データを除いては、関与しています。
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-job-canceled: not applicable.
サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Get-Job-Attributes with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブ・属性の取得に適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードについては、要求された属性は応答して、グループ3に返されます。
successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功-OK-無視-または置換 - 属性：ゲット・プリンタ・属性（セクション3.1.3.1.5を参照）と同じ。
successful-ok-conflicting-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功-OK-競合-属性：ゲット・プリンタ・属性（セクション3.1.3.1.5を参照）と同じ。
For the error status codes, Group 3 is returned containing no attributes or is not returned at all.
エラーステータスコードについては、グループ3には属性を含まない返されるか、まったく返されません。
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-document-format-not-supported: not applicable.
クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。
client-error-attributes-or-values-not-supported: not applicable.
クライアント誤り属性-または値-サポートされていません：適用されません。
client-error-uri-scheme-not-supported: not applicable.
クライアント・エラー-URI-スキーム-サポートされていません：適用されません。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).
クライアント誤り属性-または値-サポートされていません：適用できない、サポートされていない操作属性および/または（上記参照）の値を無視しなければなりませんし、適切な成功コードが返さ以来。
client-error-conflicting-attributes: not applicable
クライアント・エラー・競合・属性：適用されません
server-error-operation-not-supported: not applicable (since Get-Job-Attributes is REQUIRED).
サーバー・エラー・操作 - サポートされていません：適用されません（GET-ジョブ・属性以来REQUIREDです）。
server-error-device-error: same as Print-Job, except no document data is involved.
サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、ない文書データを除いては、関与しています。
server-error-temporary-error: sane as Print-Job, except no document data is involved..
サーバーエラー一時的なエラー：印刷ジョブとして正気、何の文書データが含まれないを除いて。..
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-job-canceled: not applicable.
サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Hold-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブを保持するために適用されます。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
For the following success status codes, the Job object is being held or has been held:
以下の成功ステータスコードについては、ジョブオブジェクトが開催されているか開催されています：
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功-OK-競合-属性：印刷ジョブと同じ。
For any of the error status codes, the Job object has not been held or was previously held.
エラーステータスコードのいずれかの場合は、ジョブオブジェクトが開催されていないか、以前に開催されました。
client-error-not-possible: The request cannot be carried out
because of the state of the Job object ('completed',
'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object does not exist.
クライアント・エラー - 見つかりません：ターゲットプリンターおよび/またはジョブオブジェクトが存在しません。
client-error-gone: the target Printer and/or Job object no longer exists and no forwarding address is known.
なくなってクライアントエラー：対象のプリンターおよび/またはジョブオブジェクトはもはや存在せず、転送アドレスは知られていません。
client-error-request-entity-too-large: same as Print-Job, except no document data is involved.
クライアント・エラーが要求-大きすぎるエンティティ：なし文書データを除いて、印刷ジョブと同じが関与しています。
client-error-document-format-not-supported: not applicable.
クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。
client-error-conflicting-attributes: same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved.
クライアント・エラー・競合・属性：印刷ジョブと同じ、プリンタの「プリンタ受容され、ジョブが」属性が関与していないことを除いて。
server-error-operation-not-supported: the Hold-Job operation is not supported.
サーバー・エラー・操作 - サポートされていません：ホールドジョブ操作がサポートされていません。
server-error-device-error: not applicable.
サーバー・エラー・デバイス・エラー：適用されません。
server-error-temporary-error: same as Print-Job, except no document data is involved.
サーバーエラー一時的なエラー：印刷ジョブと同じ、ない文書データを除いては、関与しています。
server-error-not-accepting-jobs: not applicable.
サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-job-canceled: not applicable.
サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Hold-Job are applicable to Release-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
専門のホールドジョブの説明と、セクション3.1.3.1.1印刷ジョブ応答した印刷ジョブのステータス・コードの説明のすべては、ジョブのリリースに適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
server-error-operation-not-supported: the Release-Job operation
is not supported.
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Hold-Job are applicable to Restart-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
専門のホールドジョブの説明と、セクション3.1.3.1.1印刷ジョブ応答した印刷ジョブのステータス・コードの説明のすべては、ジョブを再開するために適用可能です。各ステータスコードのより完全な説明については、[RFC2911]に、セクション13を参照。
server-error-operation-not-supported: the Restart-Job operation
is not supported.
Assume I give a Create-Job request along with a set of 5 documents. All the documents get printed and the job state is moved to completed. I issue a Restart-Job request on the job. Now the issue is that, if I try to add new documents to the restarted job, will the IPP Server permit me to do so or return "client-error-not-possible " and again print those 5 jobs?
私は5つのドキュメントのセットと一緒に作成して、ジョブの要求を与えるものとします。すべての文書は、印刷を取得し、ジョブの状態が完了に移動されます。私は仕事上の再起動ジョブ要求を発行します。今の問題は、私が再起動ジョブに新しいドキュメントを追加しようとした場合、IPPサーバがそうするか、「クライアント誤り-ことができません」を返すと、再びそれらの5つのジョブを印刷するために私を可能にする、ということでしょうか？
A job can not move to the 'completed' state until all the documents have been processed. The 'last-document' flag indicates when the last document for a job is being sent from the client. This is the semantic equivalent of closing a job. No documents may be added once a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job is moved to the 'pending' job state and restarts the beginning on the same IPP Printer object with the same attribute values." 'number-of-documents' is a job attribute.
すべての文書が処理されるまでジョブは「完了」状態に移動することはできません。 「最後のドキュメント」フラグは、ジョブの最後の文書がクライアントから送信されている場合を示しています。これは、ジョブを閉じるの意味と同じです。ジョブが閉じられたら、何の文書を追加することはできません。 IPP / 1.1モデル状態のセクション3.3.7「ジョブが 『保留中の』ジョブの状態に移動し、同じ属性値を持つ同じIPP Printerオブジェクトの始まりを再開しています。」 「数の-文書は、」ジョブ属性です。
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 1.18)
Get-XXXX応答でサポートされていない属性を返す3.1.4（問題1.18）
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes responses, the client cannot depend on getting unsupported attributes returned in the Unsupported Attributes group that the client requested, but are not supported by the IPP object. However, such unsupported requested attributes will not be returned in the Job Attributes or Printer Attributes group (since they are unsupported). Furthermore, the IPP object is REQUIRED to return the 'successful-ok-ignored-or-substituted-attributes' status code, so that the client knows that not all that was requested has been returned.
ゲット・プリンタ・属性では、-仕事を得る、または取得・仕事・属性応答を、クライアントがサポートされていないに返され、サポートされていない属性を取得するクライアントが要求されたグループの属性に依存することはできませんが、IPPオブジェクトによってサポートされていません。しかし、そのようなサポートされていない要求された属性は、属性または（それがサポートされていませんので）プリンタがグループの属性ジョブで返されることはありません。さらに、IPPオブジェクトは、クライアントが要求したことはない、すべてが戻ってきたことを知っているように、「成功-OK-無視-または置換 - 属性のステータスコードを返すことが必要です。
The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender not send an empty attribute group in a request or a response. However, they REQUIRE a receiver to accept an empty attribute group as equivalent to the omission of that group. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that is not supplying any Job Template attributes. Similarly, an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to be returned in a response.
[RFC2911]と[RFC2910]の仕様は、送信者が要求または応答して、空の属性グループを送信しないことをお勧めします。しかし、彼らはそのグループの省略と同等に空の属性グループを受け入れるように受信機を必要としています。だから、クライアントは、ジョブテンプレートは、任意のジョブテンプレート属性を供給していない作成操作で完全にグループ属性を省略すべきです。応答で返さすべきサポートされない属性が存在しない場合同様、IPPオブジェクトがサポートされていない空の属性グループを省略すべきです。
The [RFC2910] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them equivalently. The term "receiver" means an IPP object for a request and a client for a response. The term "sender' means a client for a request and an IPP object for a response.
[RFC2910]仕様は、空の属性グループまたは省略属性グループのいずれかを受け取ると同等に扱うことができるように受信機を必要とします。用語「受信機」は、応答を要求し、クライアントのためのIPPオブジェクトを意味します。用語「送信者は、」応答の要求とIPPオブジェクトのためのクライアントを意味します。
There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2910] contains the following paragraph:
返される属性がないときには、Get-ジョブズのための規則には例外があります。 [RFC2910]は、次の段落が含まれています。
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-属性タグを送信しないことをお勧めしますが、受信機は、このような構文をデコードできなければなりません。
3.2.1.1 Flow controlling the data portion of a Print-Job request (Issue 1.22)
3.2.1.1フローは、印刷ジョブ要求（問題1.22）のデータ部分を制御します
A paused printer, or one that is stopped due to paper out or jam or spool space full or buffer space full, may flow control the data of a Print-Job operation (at the TCP/IP layer), so that the client is not able to send all the document data. Consequently, the Printer will not return a response until the condition is changed.
論文アウトまたは完全ジャムやスプールスペース全体またはバッファ空間に停止する一時停止プリンタ、または1つ、クライアントがないように、（TCP / IP層での）印刷ジョブ動作の制御データを流れることができますすべての文書データを送信することができ。条件が変更されるまでその結果、プリンタは応答を返しません。
The Printer should not return a Print-Job response with an error code in any of these conditions, since either the printer will be resumed and/or the condition will be freed either by human intervention or as jobs print.
プリンタのいずれかが再開されますので、プリンタは、これらの条件のいずれかのエラーコードで印刷ジョブの応答を返すべきではない、および/または状態は、人間の介入によって、またはジョブのプリントのいずれかとして解放されます。
In writing test scripts to test IPP Printers, the script must also be written not to expect a response, if the printer has been paused, until the printer is resumed, in order to work with all possible implementations.
プリンタが一時停止されている場合、プリンタが再開されるまで、IPPプリンタをテストするためのテストスクリプトを書くには、スクリプトは、すべての可能な実装を使用するために、、、応答を期待しないように書かなければなりません。
An IPP client submits a small job via Print-Job. By the time the IPP printer/print server is putting together a response to the operation, the job has finished printing and been removed as an object from the print system. What should the job-state be in the response?
IPPクライアントは、印刷ジョブを経由して、小さな仕事を提出します。 IPPプリンタ/プリントサーバが操作への応答を一緒に入れている時間によって、ジョブが印刷を終了した、印刷システムからオブジェクトとして削除され。ジョブの状態は応答で何をすべきですか？
The Model suggests that the Printer return a response before it even accepts the document content. The Job Object Attributes are returned only if the IPP object returns one of the success status codes. Then the job-state would always be "pending" or "pending-held".
モデルは、それも文書の内容を受け入れる前に、プリンタが応答を返すことを示唆しています。ジョブオブジェクトの属性は、IPPオブジェクトが成功ステータスコードのいずれかを返す場合にのみ返されます。その後、ジョブ状態は常に「保留中」または「-開催保留」になります。
This issue comes up for the implementation of an IPP Printer object as a server that forwards jobs to devices that do not provide job status back to the server. If the server is reasonably certain that the job completed successfully, then it should return the job-state as 'completed'. Also the server can keep the job in its "job history" long after the job is no longer in the device. Then a user could query the server and see that the job was in the 'completed' state and completed as specified by the jobs "time-at-completed" time, which would be the same as the server submitted the job to the device.
この問題は、バックサーバにジョブステータスを提供していないデバイスにジョブを転送サーバとしてIPP Printerオブジェクトの実装のためにアップしています。サーバは、ジョブが正常に完了したことを合理的に確実である場合、それは「完成」としてジョブの状態を返す必要があります。また、サーバは、ジョブがもはやデバイスである長い後に「ジョブ履歴」で仕事を続けることはできません。その後、ユーザーがジョブで指定されたジョブが「完了」状態にあったと完了したことをサーバーに照会して見ることができ、サーバがデバイスにジョブを送信したのと同じになる時間を、「時間には完了します」。
An alternative is for the server to respond to the client before or while sending the job to the device, instead of waiting until the server has finished sending the job to the device. In this case, the server can return the job's state as 'pending' with the 'job-outgoing' value in the job's "job-state-reasons" attribute.
代替前またはデバイスにジョブを送信するのではなく、サーバーがデバイスにジョブを送信完了するまで待っている間、クライアントに対応するためのサーバ用です。この場合、サーバーは、ジョブの「ジョブ状態の理由」属性の「ジョブの発信」の値を「保留」としてジョブの状態を返すことができます。
If the server doesn't know for sure whether the job completed successfully (or at all), it could return the (out-of-band) 'unknown' value.
サーバは、ジョブが正常に完了した（または全ての）かどうかを確かに知っていない場合、それは（アウト・オブ・バンド）「不明」値を返すことができます。
On the other hand, if the server is able to query the device and/or setup some sort of event notification that the device initiates when the job makes state transitions, then the server can return the current job state in the Print-Job response and in subsequent queries because the server knows what the job state is in the device (or can query the device).
一方、サーバは、デバイスおよび/またはセットアップデバイスは、ジョブが状態遷移を行う場合、サーバは印刷ジョブ応じて現在のジョブの状態を返すことができる開始というイベント通知のいくつかの並べ替えを照会することができる場合と、後続の問合せでは、サーバーは、ジョブの状態がデバイスであるかを知っている（またはデバイスを照会することができる）ので。
All of these alternatives depend on implementation of the server and the device.
これらの選択肢の全ては、サーバとデバイスの実装に依存します。
If a Printer supports the "printer-make-and-model" attribute and returns the .INF file model name of the printer in that attribute, the Microsoft client will automatically install the correct driver (if available).
プリンタは、「プリンタ・メイクとモデル」属性をサポートしており、その属性におけるプリンタの.INFファイルのモデル名を返した場合、マイクロソフトのクライアントは自動的に正しいドライバ（利用可能な場合）をインストールします。
Clients which poll periodically for printer status or queued-job-count should use the "requested-attributes" operation attribute to limit the scope of the query in order to save Printer and network resources.
プリンタの状態またはキューに入れられたジョブカウントのために定期的にポーリングは、プリンタおよびネットワークリソースを節約するために、クエリの範囲を制限するために、「要求され、属性」操作属性を使用する必要がありますクライアント。
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 1.39)?
3.2.3.1のGet-ジョブズ、私-仕事= '真'、および '要求元のユーザ名'（問題1.39）？
In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there too, and if it's not present what should the IPP printer do?
属性「私-仕事」が存在し、trueに設定されている場合、[RFC2911]セクション3.2.6.1「ゲット・ジョブズを要求」は、「要求ユーザー名」属性はあまりにもそこでなければならない、そしてそれが何を提示していない場合IPPプリンタはいいですか？
[RFC2911] Section 8.3 describes the various cases of "requesting-user-name" being present or not for any operation. If the client does not supply a value for "requesting-user-name", the printer MUST assume that the client is supplying some anonymous name, such as "anonymous".
[RFC2911]セクション8.3「要求ユーザ名」は、任意の動作のために存在するかしないという様々なケースが記載されています。クライアントは、「要求ユーザー名」の値を指定しない場合、プリンタは、クライアントが、そのような「匿名」として、いくつかの匿名の名前を供給していると仮定しなければなりません。
When using the Get-Jobs operation a client implementer might choose to limit the number of jobs that the client shows on the first screenful. For example, if its UI can only display 50 jobs, it can defend itself against a printer that would otherwise return 500 jobs, perhaps taking a long time on a slow dial-up line. The client can then go and ask for a larger number of jobs in the background, while showing the user the first 50 jobs. Since the job history is returned in reverse order, namely the most recently completed jobs are returned first, the user is most likely interested in the first jobs that are returned. Limiting the number of jobs may be especially useful for a client that is requesting 'completed' jobs from a printer that keeps a long job history. Clients that don't mind sometimes getting very large responses, can omit the "limit" attribute in their Get-Jobs requests.
ゲット・ジョブ操作を使用する場合、クライアントの実装は、クライアントが最初の画面いっぱいに表示されていることジョブの数を制限することを選択するかもしれません。そのUIが唯一の50個のジョブを表示することができた場合、それは、そうでない場合は、おそらく遅いダイヤルアップ回線に長い時間をかけて、500件の仕事を返すプリンタに対して自分自身を守ることができます。ユーザーは最初の50個のジョブを表示しながら、次にクライアントは、バックグラウンドでジョブをより多くのために行くと尋ねることができます。ジョブ履歴は逆の順序で返されているので、すなわち最も最近完了したジョブは、ユーザーが最も可能性の高い返された最初の仕事に興味があり、最初に返されます。ジョブの数を制限することは、長いジョブ履歴を保持し、プリンタから「完了のジョブを要求しているクライアントのために特に有用です。非常に大規模な応答を取得し、時には気にしないクライアントは、彼らのGet-ジョブリクエストで「リミット」属性を省略することができます。
A Printer may respond to a Create-Job operation with "job-state" 'pending' or 'pending-held' and " job-state-reason" 'job-data-insufficient' to indicate that operation has been accepted by the Printer, but the Printer is expecting additional document data before it can move the job into the 'processing' state. Alternatively, it may respond with "job-state" 'processing' and "job-state-reason" 'job-incoming' to indicate that the Create-Job operation has been accepted by the Printer, but the Printer is expecting additional Send-Document and/or Send-URI operations and/or is accessing/accepting document data. The second alternative is for non-spooling Printers that don't implement the 'pending' state.
プリンタは、プリンタによって受け入れられたその操作を示すために「保留」「ジョブ状態」または「保留-開催された」と「ジョブ状態理由」「ジョブデータが不十分」との作成・ジョブの操作に応答することができますそれは「処理」状態に仕事を動かすことができる前に、しかし、プリンタは、追加の文書データを期待しています。また、それが作成し、ジョブの操作は、プリンタによって受け入れられているが、プリンタが追加Send-を期待していることを示すために、「ジョブ状態」「処理」と「ジョブ状態理由」「ジョブの着信」で応答することができますドキュメントおよび/または送信-URIを操作および/または文書データを受け入れる/アクセスしています。第二の代替は「保留」状態を実装していない非スプールプリンタ用です。
Should the server wait for the "last-document" operation attribute set to 'true' before starting to "process" the job?
「プロセス」にジョブを開始する前に「真」に設定された「最後のドキュメント」操作属性のためのサーバーの待機が必要がありますか？
It depends on implementation. Some servers spool the entire job, including all document data, before starting to process, so such an implementation would wait for the "last-document" before starting to process the job. If the time-out occurs without the "last-document", then the server takes one of the indicated actions in section 3.3.1 in the [RFC2911] document. Other servers will start to process document data as soon as they have some. These are the so-called "non-spooling" printers. Currently, there isn't a way for a client to determine whether the Printer will spool all the data or will start to process (and print) as soon as it has some data.
これは、実装に依存します。一部のサーバーは、プロセスを開始する前に、すべての文書データを含め、ジョブ全体をスプール、そのような実装は、ジョブの処理を開始する前に、「最後のドキュメント」のために待機していました。タイムアウトは、「最後のドキュメント」なしで発生した場合、サーバは、[RFC2911]ドキュメント内のセクション3.3.1で示されたアクションのいずれかをとります。他のサーバは、すぐに彼らはいくつかを持っているように、文書データを処理するために開始します。これらは、いわゆる「非スプール」プリンタです。現在、クライアントは、それがいくつかのデータを持っているとして、プリンタが、すぐにすべてのデータをスプールしますまたはプロセス（および印刷）を開始するかどうかを決定するための方法はありません。
The Validate-Job operation has been designed so that its implementation may be a part of the Print-Job operation. Therefore, requiring Validate-Job is not a burden on implementers. Also it is useful for client's to be able to count on its presence in all conformance implementations, so that the client can determine before sending a long document, whether the job will be accepted by the IPP Printer or not.
その実装は、印刷ジョブ操作の一部とすることができるように、検証ジョブ操作が設計されています。そのため、検証-仕事を必要とすることは実装上の負担はありません。また、クライアントのクライアントは、ジョブはIPPプリンターで受け入れされるかどうか、長い文書を送信する前に判断できるように、すべての準拠実装でその存在を頼りにできるようにするために有用です。
The Restart-Job operation allows the reprocessing of a completed job. Some jobs store the document data on the printer. Jobs created using the Print-Job operation are an example. It is required that the printer retains the job data after the job has moved to a 'completed state' in order for the Restart-Job operation to succeed.
再起動して、ジョブの操作が完了したジョブの再処理を可能にします。いくつかのジョブがプリンタに文書データを保存します。印刷ジョブの操作を使用して作成されたジョブは一例です。ジョブが再起動し、ジョブの操作が成功するためには「完成した状態」に移動した後、プリンタがジョブデータを保持していることが必要です。
Some jobs contain only a reference to the job data. A job created using the Print-URI is an example of such a job. When the Restart-Job operation is issued the job is reprocessed. The job data MUST be retrieved again to print the job.
いくつかのジョブは、ジョブデータへの参照のみが含まれています。印刷-URIを使用して作成したジョブは、ジョブの一例です。再起動して、ジョブ操作が発行されるとジョブが再処理されます。ジョブデータは、ジョブを印刷するために、再度取得する必要があります。
It is possible that a job fails while attempting to access the print data. When such a job is the target of a Restart-Job the Printer SHALL attempt to retrieve the job data again.
印刷データにアクセスしようとしたときに、ジョブが失敗することも可能です。そのようなジョブが再起動して、ジョブのターゲットである場合には、プリンタは再びジョブデータを取得しようとしないものとします。
4 Object Attributes
4つのオブジェクト属性
[RFC2911] states that the 'none' value should be used as the value of a 1setOf when the set is empty. In most cases, sets that are potentially empty contain keywords so the keyword 'none' is used, but for the 3 finishings attributes, the values are enums and thus the empty set is represented by the enum 3. Currently there are no other attributes with 1setOf values, which can be empty and can contain values that are not keywords. This exception requires special code and is a potential place for bugs. It would have been better if we had chosen an out-of-band value, either "no-value" or some new value, such as 'none'. Since we didn't, implementations have to deal with the different representations of 'none', depending on the attribute syntax.
[RFC2911]は集合が空である場合に「なし」値が1setOfの値として使用されるべきであると述べています。ほとんどの場合、キーワード「なにも」が使用されていないので、潜在的に空になっているセットは、キーワードが含まれていますが、3つの仕上げ属性のため、値が列挙型であり、したがって、空のセットが列挙型3で表され、現在のところ、他の属性とが存在しません空にすることができ、キーワードではない値を含めることができ1setOf値、。この例外は、特別なコードを必要とし、バグの可能性の場所です。我々はこのような「なし」として、「無価値」またはいくつかの新しい値のいずれか、アウトオブバンド値を選択しなかった場合、それはもっと良かったはず。私たちはしなかったので、実装は、属性構文によっては、「なし」の異なる表現に対処する必要があります。
What is the attribute syntax for a multi-valued attribute? Since some attributes support values in more than one data type, such as "media", "job-hold-until", and "job-sheets", IPP semantics associate the attribute syntax with each value, not with the attribute as a whole. The protocol associates the attribute syntax tag with each value. Don't be fooled, just because the attribute syntax tag comes before the attribute keyword. All attribute values after the first have a zero length attribute keyword as the indication of a subsequent value of the same attribute.
複数値属性の属性構文は何ですか？いくつかの属性は、「メディア」、「ジョブホールドまで」、および「ジョブシート」など複数のデータ型の値を、サポートしているので、IPPの意味はありません全体として属性で、それぞれの値を持つ属性の構文を関連付けます。プロトコルは、それぞれの値を持つ属性構文タグを関連付けます。属性構文タグは属性キーワードの前に来るからといって、だまされてはいけません。後のすべての属性値は、第1の同属性のその後の値の指標としてゼロ長属性キーワードを持っています。
IPP client and server implementations must be aware of the diverse uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and Host names as case insensitive but reminds us that the rest of the URL may well demonstrate case sensitivity. When creating URL's for fields where the choice is completely arbitrary, it is probably best to select lower case. However, this cannot be guaranteed and implementations MUST NOT rely on any fields being case-sensitive or case-insensitive in the URL beyond the URL scheme and host name fields.
IPPクライアントとサーバ実装は、URIの多様な大文字/小文字の本質を認識する必要があります。 RFC 2396は、大文字と小文字を区別しないでURLスキームとホスト名を定義しますが、URLの残りの部分がうまくケース感度を示すことができることを私たちに思い出させます。 URLの選択は完全に任意であるフィールドのために作成する場合、それは下部ケースを選択するのが最善です。ただし、これは保証されませんし、実装は大文字と小文字を区別したり、大文字と小文字を区別しないURLのスキームとホスト名のフィールドを越えたURLにあるすべてのフィールド当てにしてはいけません。
The reason that the IPP specification does not make any restrictions on URIs, is so that implementations of IPP may use off-the-shelf components that conform to the standards that define URIs, such as RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these specifications for rules of matching, comparison, and case-sensitivity.
IPPの実装は、RFC 2396及びHTTP / 1.1仕様としてURIを定義する規格に適合既製部品を使用することができるように、IPP仕様はURIの上の任意の制限を行わないことが理由であり、[RFC2616] 。マッチング、比較、および大文字小文字の区別の規則のために、これらの仕様を参照してください。
It is also recommended that System Administrators and implementations avoid creating URLs for different printers that differ only in their case. For example, don't have Printer1 and printer1 as two different IPP Printers.
また、システム管理者と実装が彼らの場合のみが異なる別のプリンタのURLを作成しないことをお勧めします。例えば、Printer1の異なる2台のIPPプリンタとしてPRINTER1を持っていません。
Example of equivalent URI's
同等のURIの例
http://abc.com:80/~smith/home.html
ｈっｔｐ：／／あｂｃ。こｍ：８０／〜ｓみｔｈ／ほめ。ｈｔｍｌ
http://ABC.com/%7Esmith/home.html
ｈっｔｐ：／／あＢＣ。こｍ／％７えｓみｔｈ／ほめ。ｈｔｍｌ
http:/ABC.com:/%7esmith/home.html
http：/ABC.com：/％7esmith / home.html
Example of equivalent URI's using the IPP scheme
同等のURIのは、IPP方式を使用する例
ipp://abc.com:631/~smith/home.html ipp://ABC.com/%7Esmith/home.html
IPP：//abc.com：631 /〜・スミス/ home.html IPP：//ABC.com/%7Esmith/home.html
http:/ABC.com:631/%7esmith/home.html
http：/ABC.com：631 /％7esmith / home.html
The HTTP/1.1 specification [RFC2616] contains more details on comparing URLs.
HTTP / 1.1仕様書[RFC2616]はURLの比較の詳細が含まれています。
The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes that have two components. The first component is the 'language' component that can contain up to 63 octets. The second component is the 'text' or 'name' component. The maximum length of these are 1023 octets and 255 octets respectively. The definition of attributes with either syntax may further restrict the length (e.g., printer-name (name(127))).
「textWithLanguage」と「nameWithLanguageは」二つの成分を持つ化合物構文です。第一の成分は、最大63個のオクテットを含めることができる「言語」コンポーネントです。第二の成分は、「テキスト」か「名前」コンポーネントです。これらの最大長は、それぞれ1023オクテットと255オクテットです。さらに長さを制限することができるいずれかの構文を使用して属性の定義（例えば、プリンタ名（名前（127）））。
The length of the 'language' component has no effect on the allowable length of 'text' in 'textWithLanguage' or the length of 'name' in 'nameWithLanguage'
「言語」コンポーネントの長さが「nameWithLanguage」の「textWithLanguage」内の「テキスト」または「名前」の長さの許容長には影響を与えません
IPP/1.0 is silent on which of the four effects an implementation would perform if it supports Create-Job, but does not support "multiple-document-handling" or multiple documents per job. IPP/1.1 was changed so that a Printer could support Create-Job without having to support multiple document jobs. The "multiple-document-jobs-supported" (boolean) Printer description attribute was added to IPP/1.1 along with the 'server-error-multiple-document-jobs-not-supported' status code for a Printer to indicate whether or not it supports multiple document jobs, when it supports the Create-Job operation. Also IPP/1.1 was clarified that the Printer MUST support the "multiple-document-handling" (type2 keyword) Job Template attribute with at least one value if the Printer supports multiple documents per job.
IPP / 1.0は、実装は、それが作成し、ジョブをサポートしている場合に実行することになりますが、「マルチドキュメント・ハンドリング」やジョブごとに複数のドキュメントをサポートしていない4つの効果のどれに沈黙しています。プリンタは、複数の文書ジョブをサポートすることなく作成し、ジョブをサポートすることができるように、IPP / 1.1を変更しました。 「マルチドキュメント・ジョブはサポート」（ブール値）プリンタ記述属性はかどうかを示すために、プリンタのための「サーバー・エラー・マルチドキュメント・ジョブ - - サポートされていない」ステータスコードと一緒にIPP / 1.1に追加されましたそれが作成・ジョブの動作をサポートする場合、複数のドキュメントのジョブをサポートしています。また、IPP / 1.1は、プリンタがジョブごとに複数のドキュメントをサポートしている場合、プリンタは、少なくとも1つの値を「マルチドキュメント・ハンドリング」（TYPE2キーワード）のJob Template属性をサポートしなければならないことが明らかになりました。
The "date-time-at-creation", "date-time-at-processing", and "date-time-at-completed" attributes are returned as dateTime syntax. These attributes are OPTIONAL for a Printer to support. However, there are various ways for a Printer to get the date and time of day. Some suggestions:
「日時・アット・創造」、「日時・アット・処理」、および「日時・アット・完成を」属性はdateTimeの構文として返されます。これらの属性は、プリンタがサポートするのはオプションです。しかし、その日の日付と時刻を取得するには、プリンタのための様々な方法があります。いくつかの提案：
1. A Printer can get time from an NTP timeserver if there's one reachable on the network . See RFC 1305. Also DHCP option 32 in RFC 2132 returns the IP address of the NTP server.
ネットワーク上の到達可能な1があるかどう1.プリンタは、NTPタイムサーバから時刻を取得することができます。 RFC 2132でまたRFC 1305 DHCPオプション32は、NTPサーバのIPアドレスを返します参照してください。
3. Have an operator set the date and time using a web administrative interface
3.オペレータがWeb管理インターフェースを使用して、日付と時刻を設定しています
4. Get the date and time from incoming HTTP requests, though the problems of spoofing need to be considered. Perhaps comparing several HTTP requests could reduce the chances of spoofing.
なりすましの問題を考慮する必要があるものの4、受信HTTPリクエストから日付と時刻を取得します。おそらく、いくつかのHTTPリクエストを比較すると、なりすましの可能性を減らすことができます。
The reason that "queued-job-count" is RECOMMENDED, is that some clients look at that attribute alone when summarizing the status of a list of printers, instead of doing a Get-Jobs to determine the number of jobs in the queue. Implementations that fail to support the "queued-job-count" will cause that client to display 0 jobs when there are actually queued jobs.
「キューに入れられたジョブ・カウント」が推奨される理由は、プリンタのリストの状況をまとめ、代わりのキューにあるジョブの数を決定するには、Get-ジョブを実行するときに、いくつかのクライアントは一人でその属性を見ていることです。 「キューに入れられたジョブ-count」をサポートするために失敗する実装は、実際にキューに入れられたジョブがあるときに、クライアントは0ジョブを表示します。
We would have made it a REQUIRED Printer attribute, but some implementations had already been completed before the issue was raised, so making it a SHOULD was a compromise.
我々はそれREQUIREDのPrinter属性作られていますが、問題が発生した前に、いくつかの実装はまだSHOULDは妥協だったそれを作る、完成されていました。
4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is (Issue 1.15)?
4.4.1.2は、「キューに入れられたジョブカウント」プリンタがどれくらい忙しいの良い測定（問題1.15）ですか？
The "queued-job-count" is not a good measure of how busy the printer is when there are held jobs. A future registration could be to add a "held-job-count" (or an "active-job-count") Printer Description attribute if experience shows that such an attribute (combination) is needed to quickly indicate how busy a printer really is.
「キューに入れられたジョブ・カウントは」仕事が開催されている場合、プリンタがどれくらい忙しいの良い指標ではありません。経験は、そのような属性（組み合わせ）がすぐにプリンタが実際にどの程度ビジーであるかを示すために必要とされていることを示している場合には、将来の登録「を開催ジョブカウント」（または「アクティブ・ジョブ数」）プリンタ記述属性を追加することができ。
A Printer implementation MAY support this attribute by obtaining the date and time by any number of implementation-dependent means at startup or subsequently. Examples include:
プリンタの実装は実装依存の手段、起動時またはその後の任意の数で、日付と時刻を取得することによって、この属性をサポートするかもしれません。例としては、
6. from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132] that returns the IP address of the NTP server.
NTP [RFC1305]またはNTPサーバのIPアドレスを返すDHCPオプション32 [RFC2132]を使用してネットワークから6、。
If an implementation supports this attribute by obtaining the current time from the network (at startup or later), but the time is not available, then the implementation MUST return the value of this attribute using the out-of-band 'no-value' meaning not configured. See the beginning of section 4.1.
実装がネットワーク（起動時以降）から現在時刻を取得することによって、この属性をサポートしていますが、時間が利用できない場合、実装はアウトオブバンド「ノー-値」を使用して、この属性の値を返さなければならない場合意味構成されていません。セクション4.1の始まりを参照してください。
Since the new "date-and-time-at-xxx" Job Description attributes refer to the "printer-current-time", they will be covered also.
新しい「日時・アット・xxxの」ジョブの説明属性は、「プリンタの現在時刻」を参照してくださいので、それらもカバーされます。
Must the operational attribute for printer-uri match one of the values in "printer-uri-supported"?
プリンタ-uriの試合のための操作属性「プリンタ - uriのサポート」内の値のいずれかにする必要がありますか？
A forgiving printer implementation would not reject the operation. But the implementation has its rights to reject a printer or job operation if the operational attribute printer-uri is not a value of the printer-uri-supported. The printer might not be improperly configured. The request obviously reached the printer. The printer could treat the printer-uri as the logical equivalent of a value in the printer-uri-supported. It would be implementation dependent for which value, and associated security policy, would apply. This does also apply to a job object specified with a printer-uri and job-id, or with a job-uri. See section 4.1.3 for how to compare URI's.
寛大プリンタの実装は操作を拒否していないでしょう。しかし、実装は、プリンタ-URI操作属性は、値がない場合は、プリンタやジョブの操作を拒否する権利を持っているプリンタ-URIでサポートされています。プリンタが正しく設定されない場合があります。要求は明らかにプリンタに達しました。プリンタは、プリンタ-URI-サポートの値を論理的に同等のものとしてプリンタ-URIを処理することができます。それはどの値のため、実装依存、および関連するセキュリティポリシーになり、適用されます。これは、プリンタ-URIとジョブ-idを持つ、またはジョブ-URIで指定されたジョブオブジェクトに適用されます。 URIのを比較する方法については、セクション4.1.3を参照してください。
The IPP object model does not prohibit a job that contains no documents. Such a job may be created in a number of ways including a 'create-job' followed by an 'add-document' that contains no data and has the 'last-document' flag set.
IPPオブジェクトモデルには、文書が含まれていない仕事を禁止していません。このような仕事は、データを含まないと「最後のドキュメント」フラグがセットされている「を追加 - ドキュメント」に続く「を作成ジョブ」を含むいくつかの方法で作成することができます。
An empty job is processed just as any other job. The operation that "closes" an empty job is not rejected because the job is empty. If no other conditions exist, other than the job is empty, the response to the operation will indicate success. After the job is scheduled and processed, the job state SHALL be 'completed'.
空の仕事は、他のジョブとして処理されます。仕事が空であるため、空の仕事を「クローズ」という操作が拒否されていません。他の条件が存在しない場合は、仕事以外では空で、操作への応答は成功を示します。ジョブがスケジュールされ、処理された後、ジョブの状態は「完了」するものとします。
There will be some variation in the value(s) of the "job-state-reasons" attribute. It is required that if no conditions, other than the job being empty, exist the "job-state-reasons" SHALL include the
「ジョブ状態の理由」属性の値（複数可）でいくつかのバリエーションがあります。それは、仕事以外の条件は、空でない場合は、「ジョブ状態理由」が存在することが必要とされる含まれていなければなりません
'completed-successfully'. If other conditions existed, the 'completed-with-warnings' or 'completed-with-errors' values may be used.
「完成に成功」。他の条件が存在する場合は、「で-警告完了」または「完了-と、エラー」の値を使用することができます。
5 Directory Considerations
5ディレクトリに関する考慮事項
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object attributes for directory schemas. See [RFC2911] APPENDIX E: Generic Directory Schema.
[RFC2911]ドキュメントリスト推奨およびオプションのプリンタオブジェクトがディレクトリ・スキーマの属性。ジェネリックDirectoryスキーマ：[RFC2911]付録Eを参照してください。
The SLP printer template is defined in the "Definition of the Printer Abstract Service Type v2.0" document [svrloc-printer]. The LDAP printer template is defined in the "Internet Printing Protocol (IPP): LDAP Schema for Printer Services" document [ldap-printer]. Both documents systematically add "printer-" to any attribute that doesn't already start with "printer-" in order to keep the printer directory attributes distinct from other directory attributes. Also, instead of using "printer-uri-supported", "uri-authentication-supported", and "uri-security-supported", they use a "printer-xri-supported" attribute with special syntax to contain all of the same information in a single attribute.
SLPプリンタテンプレートは、文書[svrloc-プリンタ]「プリンタ抽象サービスタイプV2.0の定義」に定義されています。ドキュメント[LDAP-プリンタ]：LDAPプリンタテンプレートは、「LDAPスキーマプリンタサービスのためのインターネット印刷プロトコル（IPP）」に定義されています。両方の文書は、体系的に、すでに他のディレクトリの属性は異なる属性をプリンタディレクトリを維持するために「printer-」で始まっていない任意の属性に「printer-」を追加します。また、代わりに「プリンタ-uriのサポート」、「URI-認証サポート」、および「URI-セキュリティ・サポート」を使用して、彼らは同じのすべてが含まれているために、特別な構文で「プリンタ-XRIサポート」属性を使用します単一の属性の情報。
If the IPP printer has a DNS name should there be at least two values for the printer-uri-supported attribute. One URL with the fully qualified DNS name the other with the IP address in the URL?
IPPプリンタはDNS名を持っている場合、プリンタ-URIでサポートされている属性の少なくとも二つの値があるはずです。 URLでのIPアドレスを持つ他の完全修飾DNS名を使用して1つのURL？
The printer may contain one or the other or both. It's up to the administrator to configure this attribute.
プリンタは、どちらか一方または両方を含んでいてもよいです。これは、この属性を設定するには、管理者次第です。
6 Security Considerations
6セキュリティについての考慮事項
The security considerations given in [RFC2911] Section 8 "Security Considerations" all apply to this document. In addition, the following sub-sections describes security consideration that have arisen as a result of implementation testing.
[RFC2911]のセクション8「セキュリティに関する考慮事項」に記載されているセキュリティ上の考慮事項はすべて、この文書に適用されます。加えて、以下のサブセクションでは、実装試験の結果として生じたセキュリティ上の考慮事項が記載されています。
6.1 Querying jobs with IPP that were submitted using other job submission protocols (Issue 1.32)
6.1他のジョブ送信プロトコルを使用して提出されたIPPとの仕事を照会（問題1.32）
The following clarification was added to [RFC2911] section 8.5:
以下の清澄は、[RFC2911]セクション8.5に加えました。
8.5 Queries on jobs submitted using non-IPP protocols If the device that an IPP Printer is representing is able to accept jobs using other job submission protocols in addition to IPP, it is RECOMMEND that such an implementation at least allow such "foreign" jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. Such an implementation NEED NOT support all of the same IPP job attributes as for IPP jobs. The IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign job that is supported for IPP jobs, but not for foreign jobs.
IPPプリンタを表しているデバイスは、IPPに加えて、他のジョブ送信プロトコルを使用してジョブを受け入れることができる場合は、ジョブの8.5クエリが非IPPプロトコルを使用して提出し、そのような実装は、少なくともこのような「外国人」の仕事をできるようにすることをお勧めしますですゲット・ジョブズを「ジョブID」と「仕事-URI」「不明」などを返す使用して照会すること。このような実装では、同じIPPジョブのすべてがIPPジョブのよう属性をサポートする必要はありません。 IPPオブジェクトは、IPPジョブのではなく、外国人の雇用のためにサポートされている外国人の仕事のあらゆる要求された属性について「不明」の帯域外の値を返します。
It is further RECOMMENDED, that the IPP Printer generate "job-id" and "job-uri" values for such "foreign jobs", if possible, so that they may be targets of other IPP operations, such as Get-Job-Attributes and Cancel-Job. Such an implementation also needs to deal with the problem of authentication of such foreign jobs. One approach would be to treat all such foreign jobs as belonging to users other than the user of the IPP client. Another approach would be for the foreign job to belong to 'anonymous'. Only if the IPP client has been authenticated as an operator or administrator of the IPP Printer object, could the foreign jobs be queried by an IPP request. Alternatively, if the security policy were to allow users to query other users' jobs, then the foreign jobs would also be visible to an end-user IPP client using Get-Jobs and Get-Job- Attributes.
さらに可能であれば、彼らはそのようには、Get-ジョブ・属性などの他のIPP操作の対象とすることができるように、IPPプリンタは、「ジョブID」と、このような「外国人雇用」のための「仕事-URI」の値を生成することを、推奨されますそしてキャンセル・ジョブを。このような実装は、このような外国人の雇用の認証の問題に対処する必要があります。一つのアプローチは、IPPクライアントのユーザー以外のユーザーに属しているような全ての外国のジョブを処理することになります。別のアプローチは、「匿名」に所属する外国人の仕事のためになります。 IPPクライアントは、IPP Printerオブジェクトのオペレータまたは管理者として認証された場合にのみ、外国人の雇用は、IPP要求によって照会することができます。セキュリティポリシーは、ユーザが他のユーザのジョブを照会することを可能にした場合あるいは、それから外国人の仕事もゲット・ジョブとは、Get-Job-属性を使用して、エンドユーザIPPクライアントに見えるだろう。
Thus IPP MAY be implemented as a "universal" protocol that provides access to jobs submitted with any job submission protocol. As IPP becomes widely implemented, providing a more universal access makes sense.
したがって、IPPは、任意のジョブ投入プロトコルで送信されたジョブへのアクセスを提供する「ユニバーサル」プロトコルとして実装することができます。 IPPは、広く実装されるにつれて、より普遍的なアクセスを提供することは理にかなっています。
7 Encoding and Transport
7エンコーディングと交通
This section discusses various aspects of IPP/1.1 Encoding and Transport [RFC2910].
このセクションでは、IPP / 1.1符号化及び輸送[RFC2910]のさまざまな側面について説明します。
A server is not required to send a response until after it has received the client's entire request. Hence, a client must not expect a response until after it has sent the entire request. However, we recommend that the server return a response as soon as possible if an error is detected while the client is still sending the data, rather than waiting until all of the data is received. Therefore, we also recommend that a client listen for an error response that an IPP server MAY send before it receives all the data. In this case a client, if chunking the data, can send a premature zero-length chunk to end the request before sending all the data (and so the client can keep the connection open for other requests, rather than closing it). If the request is blocked for some reason, a client MAY determine the reason by opening another connection to query the server using Get-Printer-Attributes.
サーバは、クライアントの要求全体を受け取った後まで応答を送信するために必要とされていません。したがって、クライアントは、それが全体の要求を送信した後まで応答を期待してはいけません。しかし、私たちは、クライアントがデータを送信するのではなく、すべてのデータを受信するまで待機している間にエラーが検出された場合、サーバはできるだけ早く応答を返すことをお勧めします。したがって、我々はまた、クライアントは、それはすべてのデータを受信する前にIPPサーバが送信する可能性のあること、エラー応答を聞くことをお勧めします。この場合、クライアントでは、データをチャンク場合、すべてのデータを送信する前に、要求を終了するには時期尚早長さゼロのチャンクを送信することができます（そのため、クライアントは、他の要求のためのオープンではなく、それを閉じ、接続を維持することができます）。要求が何らかの理由でブロックされている場合、クライアントは、Get-プリンタ-属性を使用してサーバーを照会するための別の接続を開くことによって、その理由を決定することができます。
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to throttle clients when Printers are busy. Therefore, it is perfectly normal for an IPP client transmitting a Job to be blocked for a really long time. Accordingly, socket timeouts must be avoided. Some socket implementations have a timeout option, which specifies how long a write operation on a socket can be blocked before it times out and the blocking ends. A client should set this option for infinite timeout when transmitting Job submissions.
IPPは、設計により、プリンタが忙しいときにクライアントを絞るためにTCPのビルトインフロー制御メカニズム[RFC 793]を使用しています。したがって、それは本当に長い時間のためにブロックされるようにジョブを送信するIPPクライアントのために完全に正常です。したがって、ソケットのタイムアウトは避けなければなりません。ソケットの実装によっては、ソケット上の書き込み操作がタイムアウトすると、ブロッキングが終了する前にブロックすることができますどのくらいの時間を指定するタイムアウトオプションを持っています。ジョブの提出を送信するとき、クライアントは、無限のタイムアウトのために、このオプションを設定する必要があります。
Some IPP client applications might be able to perform other useful work while a Job transmission is blocked. For example, the client may have other jobs that it could transmit to other Printers simultaneously. A client may have a GUI, which must remain responsive to the user while the Job transmission is blocked. These clients should be designed to spawn a thread to handle the Job transmission at its own pace, leaving the main application free to do other work. Alternatively, single-threaded applications could use non-blocking I/O.
いくつかのIPPクライアントアプリケーションは、ジョブの送信がブロックされている間に、他の有用な作業を行うことができるかもしれません。例えば、クライアントは、それは同時に、他のプリンタに送信することができる他のジョブを有することができます。クライアントは、ジョブの送信がブロックされている間、ユーザーに応答しなければならないままにGUIを有していてもよいです。これらのクライアントは、他の仕事をして自由にメインアプリケーションを残して、独自のペースで仕事伝送を処理するためのスレッドを生成するように設計されなければなりません。また、シングルスレッドのアプリケーションでは、ノンブロッキングI / Oを使用することができます。
Some Printer conditions, such as jam or lack of paper, could cause a client to be blocked indefinitely. Clients may open additional connections to the Printer to Get-Printer-Attributes, determine the state of the device, alert a user if the printer is stopped, and let a user decide whether to abort the job transmission or not.
例えば、紙のジャムや不足などの一部のプリンタの条件は、クライアントが無期限にブロックされたりする可能性があります。クライアントは、-プリンタ - 属性を取得するためにプリンタへの追加の接続を開き、デバイスの状態を決定し、プリンタが停止した場合、ユーザーに警告し、ユーザがジョブ送信を中止するかどうかを決定させることがあります。
In the following sections, there are tables of all HTTP headers, which describe their use in an IPP client or server. The following is an explanation of each column in these tables.
次のセクションでは、IPPクライアントまたはサーバでの使用を記載し、すべてのHTTPヘッダのテーブルは、あります。以下は、これらのテーブルの各列の説明です。
- the "header" column contains the name of a header - the "request/client" column indicates whether a client sends the header. - the "request/ server" column indicates whether a server supports the header when received. - the "response/ server" column indicates whether a server sends the header. - the "response /client" column indicates whether a client supports the header when received. - the "values and conditions" column specifies the allowed header values and the conditions for the header to be present in a request/response.
- 「ヘッダー」の欄には、ヘッダの名前が含まれている - 「要求/クライアント」の欄には、クライアントは、ヘッダを送信するかどうかを示します。 - 「要求/サーバ」欄は、受信された場合、サーバは、ヘッダをサポートしているかどうかを示します。 - 「応答/サーバ」欄には、サーバは、ヘッダを送信するかどうかを示しています。 - 「応答/クライアント」の欄は、受信された場合、クライアントは、ヘッダをサポートしているかどうかを示します。 - 「の値および条件」欄には、許可されたヘッダ値とヘッダの条件が要求/応答中に存在することを指定します。
The table for "request headers" does not have columns for responses, and the table for "response headers" does not have columns for requests.
「リクエストヘッダ」の表には、応答のための列を持っていない、と「レスポンスヘッダ」の表には、要求のための列を持っていません。
The following is an explanation of the values in the "request/client" and "response/ server" columns.
以下は、「要求/クライアント」と「応答/サーバ」の列の値の説明です。
- must: the client or server MUST send the header, - must-if: the client or server MUST send the header when the condition described in the "values and conditions" column is met, - may: the client or server MAY send the header - not: the client or server SHOULD NOT send the header. It is not relevant to an IPP implementation.
「値と条件」欄に記載された条件が満たされたとき、クライアントまたはサーバは、ヘッダを送信しなければならない、 - てもよい： - ： - 必要がある場合、必要があり、クライアントまたはサーバは、ヘッダを送らなければなりません、クライアントまたはサーバが送るかもしれヘッダー - ません：クライアントまたはサーバは、ヘッダを送るべきではありません。これは、IPPの実装には関係ありません。
The following is an explanation of the values in the "response/client" and "request/ server" columns.
以下は、「応答/クライアント」と「要求/サーバ」の列の値の説明です。
- must: the client or server MUST support the header, - may: the client or server MAY support the header - not: the client or server SHOULD NOT support the header. It is not relevant to an IPP implementation.
- 必要があります：クライアントまたはサーバヘッダをサポートしなければならないが、 - ことがあります。クライアントまたはサーバは、ヘッダをサポートするかもしれ - ません：クライアントまたはサーバは、ヘッダをサポートすべきではありません。これは、IPPの実装には関係ありません。
The following is a table for the general headers.
以下は、一般ヘッダーのためのテーブルです。
General- Request Response Values and Conditions Header
一般 - 要求の応答値と状態ヘッダー
Client Server Server Client
クライアントサーバーサーバークライアント
Cache- not must not "no-cache" only Control must
唯一のコントロール必見「キャッシュなし」はならないではありませんCache-
Connection must- must must- must "close" only. Both if if client and server SHOULD keep a connection for the duration of a sequence of operations. The client and server MUST include this header for the last operation in such a sequence.
接続must-はmust-のみ「クローズ」しなければならない必要があります。どちらかの場合には、クライアントとサーバは、一連の操作の間、接続を維持する必要があります。クライアントとサーバは、シーケンス内の最後の操作のために、このヘッダを含まなければなりません。
Date may may must may per RFC 1123 [RFC1123] from RFC 2616 [RFC2616]
日付かもしれなければならないかもしれないRFC 2616 [RFC2616]からのRFC 1123 [RFC1123]あたり
Pragma must not must not "no-cache" only
プラグマは、「キャッシュなし」はならないしてはなりません
Transfer- must- must must- must "chunked" only. Header Encoding if if MUST be present if Content-Length is absent.
must-をTransfer- must-は唯一の「チャンク」しなければならない必要があります。ヘッダーエンコーディングのContent-Lengthが存在しない場合に存在しなければならない場合であれば。
Upgrade not not not not
アップグレードではないではないではないではありません
Via not not not not
経由していないではないではないではありません
The following is a table for the request headers.
次は、リクエストヘッダのためのテーブルです。
Request- Client Server Request Values and Conditions Header
要求 - クライアントサーバーの要求値と状態ヘッダー
Accept may must "application/ipp" only. This value is the default if the client omits it
受け入れはしなければならない「アプリケーション/ IPP」だけかもしれません。クライアントはそれを省略した場合、この値はデフォルトです
Accept- not not Charset information is within the Charset application/ipp entity
のAccept-情報は、文字セットアプリケーション/ IPP実体の中での文字セットではないではありません
Accept- may must empty and per RFC 2616 [RFC2616] Encoding and IANA registry for content-codings
なAccept-は内容コーディングのために[RFC2616]エンコーディングとIANAレジストリを空にし、RFC 2616あたりなければならないかもしれ
Accept- not not language information is within the Language application/ipp entity
なAccept-ない言語情報は、言語アプリケーション/ IPP実体の中ではありません
Authorization must- must per RFC 2616. A client MUST send if this header when it receives a 401 "Unauthorized" response and does not receive a "Proxy-Authenticate" header.
認証それは401「無許可」応答を受信し、「プロキシ認証」ヘッダーを受信しないときmust-はRFC 2616ごとにクライアントがあれば、このヘッダを送らなければなりませんしなければなりません。
From not not per RFC 2616. Because RFC recommends sending this header only with the user's approval, it is not very useful
ていないからではないRFC 2616 RFCのみ、ユーザの承認を得て、このヘッダを送信することをお勧めしますのでごとに、それは非常に便利ではありません
Host must must per RFC 2616
RFC 2616あたり必見必見ホスト
If-Match not not
もし、一致していません
If-Modified- not not Since
Modified--ない場合ではないので、
If-None-Match not not
もし-なし - 一致していません
If-Range not not
もしレンジではないではありません
If- not not Unmodified-Since
IF-変更されていない、ので、ないではありません
Request- Client Server Request Values and Conditions Header
要求 - クライアントサーバーの要求値と状態ヘッダー
Max-Forwards not not
マックス・転送しないではありません
Proxy- must- not per RFC 2616. A client MUST send Authorizati if this header when it receives a on 401 "Unauthorized" response and a "Proxy-Authenticate" header.
それは401「無許可」応答と「プロキシ認証」ヘッダーを受信したときにProxy-は、RFC 2616あたりのクライアントは、このヘッダー場合Authorizatiを送らなければなりませんではありませんmust-。
Range not not
ないない範囲
Referrer not not
リファラーではないではありません
User-Agent not not
ユーザエージェントではないではありません
The following is a table for the request headers.
次は、リクエストヘッダのためのテーブルです。
Response- Server Client Response Values and Conditions Header
対応 - Serverクライアントの応答値と状態ヘッダー
Accept-Ranges not not
受け入れ-範囲ではないではありません
Age not not
年齢ではないではありません
Location must- may per RFC 2616. When URI needs if redirection.
リダイレクション場合URIが必要になると場所must-は、RFC 2616あたりのかもしれません。
Proxy- must per RFC 2616 Authenticat e not
RFC 2616認証あたりProxy-必須ではありません
Public may may per RFC 2616
公共月RFC 2616あたりのかもしれません
Retry-After may may per RFC 2616
リトライ後5月には、RFC 2616あたりのかもしれません
Server not not
サーバーではないではありません
Vary not not
変化していません
Warning may may per RFC 2616
警告は、RFC 2616あたりかもしれないこと
WWW- must- must per RFC 2616. When a server needs Authenticate if to authenticate a client.
サーバーが認証を必要とする場合WWW-はRFC 2616ごとにクライアントを認証する必要がありますmust-場合。
The following is a table for the entity headers.
以下は、エンティティヘッダーのテーブルです。
Entity-Header Request Response Values and Conditions
エンティティヘッダリクエストの応答値と条件
Client Server Server Client
クライアントサーバーサーバークライアント
Allow not not not not
許可していないではないではないではありません
Content-Base not not not not
コンテンツベースではないではないではないではありません
Content- may must must must per RFC 2616 and Encoding IANA registry for content codings.
たContentかもしれなければならなければならない必要があり、コンテンツのコーディングのためのRFC 2616およびエンコーディングIANAレジストリあたり。
Content- not not not not Application/ipp Language handles language
たContentはないないないないアプリケーション/ IPP言語は、言語を処理します
Content- must- must must- must the length of the Length if if message-body per RFC 2616. Header MUST be present if Transfer-Encoding is absent..
たContent must- must-しなければならないしなければならない長さの長さ転送エンコードが存在しない場合は、RFC 2616あたりメッセージ本体はヘッダが存在しなければならない場合であれば..
Content- not not not not Location
たContentないないないない場所
Content-MD5 may may may may per RFC 2616
Content-MD5場合もありかもしれRFC 2616あたり
Content-Range not not not not
コンテンツレンジではないではないではないではありません
Content-Type must must must must "application/ipp" only
Content-Typeの必見なければならない必要がありますしなければならない「アプリケーション/ IPP」のみ
ETag not not not not
ETagのではないではないではないではありません
Expires not not not not
有効期限はないではないではないではありません
Last-Modified not not not not
ないないないないのLast-Modified
IPP implementations consist of an HTTP layer and an IPP layer. In the following discussion, the term "client" refers to the HTTP client layer and the term "server" refers to the HTTP server layer. The Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST be supported by all clients and all servers. However, a client and/or a server implementation may choose to also support HTTP 1.0.
IPP実装はHTTP層とIPP層から成ります。以下の議論では、用語「クライアント」HTTPクライアント層を意味し、「サーバ」という用語は、HTTPサーバの層を意味します。エンコーディングとTransportドキュメント[RFC2910]はHTTP 1.1は、すべてのクライアントとすべてのサーバーでサポートされている必要があります。しかし、クライアントおよび/またはサーバの実装はまた、HTTP 1.0をサポートすることもできます。
This option means that a server may choose to communicate with a (non-conforming) client that only supports HTTP 1.0. In such cases the server should not use any HTTP 1.1 specific parameters or features and should respond using HTTP version number 1.0.
このオプションは、サーバーがHTTP 1.0のみをサポートしています（不適合）クライアントと通信することを選択することを意味します。このような場合、サーバーは、任意のHTTP 1.1の特定のパラメータや機能を使用しないでくださいとHTTPのバージョン番号1.0を使用して応答する必要があります。
This option also means that a client may choose to communicate with a (non-conforming) server that only supports HTTP 1.0. In such cases, if the server responds with an HTTP 'unsupported version number' to an HTTP 1.1 request, the client should retry using HTTP version number 1.0.
このオプションは、クライアントがHTTP 1.0のみをサポートしています（不適合）サーバーと通信することを選択することを意味します。サーバはHTTP 1.1リクエストに対するHTTP「サポートされていないバージョン番号」で応答した場合、このようなケースでは、クライアントは、HTTPのバージョン番号1.0を使用して再試行する必要があります。
Clients MUST anticipate that the HTTP/1.1 server may chunk responses and MUST accept them in responses. However, a (non-conforming) HTTP client that is unable to accept chunked responses may attempt to request an HTTP 1.1 server not to use chunking in its response to an operation by using the following HTTP header:
クライアントは、HTTP / 1.1サーバはチャンク応答がと応答でそれらを受け入れなければならないことを予想しなければなりません。しかしながら、チャンク応答を受け入れることができない（不適合）HTTPクライアントは、以下のHTTPヘッダを使用して、操作に対する応答でチャンクを使用しないHTTP 1.1サーバに要求することを試みることができます。
TE: identity
TE：アイデンティティ
This mechanism should not be used by a server to disable a client from chunking a request, since chunking of document data is an important feature for clients to send long documents.
文書データのチャンクが長い文書を送信するためのクライアントのための重要な機能であるため、このメカニズムは、要求をチャンクからクライアントを無効にするには、サーバで使用することはできません。
This section describes some problems with the use of chunked requests and HTTP/1.1 servers.
このセクションでは、チャンク要求とHTTP / 1.1のサーバを使用したいくつかの問題について説明します。
The HTTP/1.1 standard [RFC2616] requires that conforming servers support chunked requests for any method. However, in spite of this requirement, some HTTP/1.1 implementations support chunked responses in the GET method, but do not support chunked POST method requests. Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or servlets [Servlet] require that the client supply a Content-Length. These implementations might reject a chunked POST method and return a
HTTP / 1.1規格[RFC2616]は準拠したサーバは、任意の方法のために、チャンク要求をサポートすることが必要です。しかし、この要件にもかかわらず、いくつかのHTTP / 1.1の実装のサポートは、GETメソッドで応答をチャンクが、チャンクPOSTメソッドの要求をサポートしていません。 CGIスクリプト[CGI]および/またはサーブレット[サーブレット]をサポートするいくつかのHTTP / 1.1の実装は、クライアントがコンテンツ長を供給する必要があります。これらの実装は、チャンクPOSTメソッドを拒否して返すことがあります
411 status code (Length Required), might attempt to buffer the request and run out of room returning a 413 status code (Request Entity Too Large), or might successfully accept the chunked request.
411ステータスコード（長さ必須）、（エンティティが大きすぎる要求）要求をバッファリングし、413のステータスコードを返す部屋の外に実行しようとするかもしれない、または成功したチャンク要求を受け入れるかもしれません。
Because of this lack of conformance of HTTP servers to the HTTP/1.1 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP Printer object implementation support chunked requests and that conforming clients accept chunked responses. Therefore, IPP object implementers are warned to seek HTTP server implementations that support chunked POST requests in order to conform to the IPP standard and/or use implementation techniques that support chunked POST requests.
そのためHTTP / 1.1規格にHTTPサーバの適合性の欠如により、IPP標準[RFC2910]は準拠したIPP Printerオブジェクトの実装のサポートが要求をチャンクすることを必要とし、準拠クライアントはチャンクの応答を受け入れること。したがって、IPPオブジェクトの実装は、IPP規格に準拠および/またはチャンクPOSTリクエストをサポートする実装テクニックを使用するために、チャンクPOSTリクエストをサポートするHTTPサーバの実装を求めて警告しています。
8 References
8つの参考文献
[CGI] CGI/1.1 (http://www.w3.org/CGI/).
[CGI] CGI / 1.1（http://www.w3.org/CGI/）。
[IANA-CS] IANA Registry of Coded Character Sets: http://www.iana.org/assignments/character-sets
[IANA-CS]符号化文字集合のIANAレジストリ：http://www.iana.org/assignments/character-sets
[ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald, "Internet Printing Protocol (IPP): LDAP Schema for Printer Services", Work in Progress.
[LDAP-プリンタ]フレミング、P.、ジョーンズ、K.、ルイス、H.、およびI.マクドナルド、 "インターネット印刷プロトコル（IPP）：LDAPスキーマプリンタサービスについて"、進行中の作業。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, October, 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、RFC 1123、1989年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[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月。
[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月。
[RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2565] DeBry、R.、ヘイスティングズ、T.、エリオ、R.、Isaacson氏、S.とP.パウエル、 "インターネット印刷プロトコル/ 1.0：モデルと意味論"、RFC 2566、1999年4月。
[RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566]エリオ、R.、バトラー、S.、ムーア、P.とR.ターナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、RFC 2565、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567]ライト、D.、 "インターネット印刷プロトコルの設計目標"、RFC 2567、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]エリオ、R.、ヘイスティングス、T.、ジェイコブズ、N.とJ.マーチン、 "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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、1999年6月。
[RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000.
[RFC2910]エリオ、R.、バトラー、S.、ムーア、P.とR.ターナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、RFC 2910、2000年9月。
[RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, September, 2000.
[RFC2911] DeBry、R.、ヘイスティングズ、T.、エリオ、R.、Isaacson氏、S.とP.パウエル、 "インターネット印刷プロトコル/ 1.0：モデルと意味論"、RFC 2911、2000年9月。
[Servlet] Servlet Specification Version 2.1 (http://java.sun.com/products/servlet/2.1/ index.html).
[サーブレット]サーブレット仕様バージョン2.1（http://java.sun.com/products/servlet/2.1/のindex.html）。
[svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the Printer Abstract Service Type v2.0", http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/printer.2.0.en (IANA Registered, May 27, 2000).
[svrloc-プリンタ]サンピエール、P.、Isaacson氏、S.、マクドナルド、I.、 "プリンタ抽象サービスタイプV2.0の定義"、http://www.isi.edu/in-notes/iana /assignments/svrloc-templates/printer.2.0.en（IANA登録、2000年5月27日）。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
[SSL]ネットスケープ、SSLプロトコル、バージョン3、（テキストバージョン3.02）、1996年11月。
Thomas N. Hastings Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
トーマスN.ヘイスティングスゼロックス社701航空ブルバードエル・セグンド、CA 90245
EMail: hastings@cp10.es.xerox.com
メールアドレス：hastings@cp10.es.xerox.com
Carl-Uno Manros Independent Consultant 1601 N. Sepulveda Blvd. #505 Manhattan Beach, CA 90266
カール・宇野Manros独立コンサルタント1601 N.セプルベダ大通り＃505マンハッタンビーチ、CA 90266
Email: carl@manros.com
メール：carl@manros.com
Carl Kugler Mail Stop 003G IBM Printing Systems Co 6300 Diagonal Hwy Boulder CO 80301
カール・クーグラーメールストップ003G IBMプリンティングシステムズ株式会社6300対角ハイウェイボルダーCO 80301
EMail: Kugler@us.ibm.com
メールアドレス：Kugler@us.ibm.com
Henrik Holst i-data Printing Systems Vadstrupvej 35-43 2880 Bagsvaerd, Denmark
ヘンリク・ホルストI-データプリンティングシステムズVadstrupvej 35-43 2880バグスバード、デンマーク
EMail: hh@I-data.com
メールアドレス：hh@I-data.com
Peter Zehler Xerox Corporation 800 Philips Road Webster, NY 14580
ピーターZehlerゼロックス社800フィリップス道ウェブスター、NY 14580
EMail: PZehler@crt.xerox.com
メールアドレス：PZehler@crt.xerox.com
IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org
IPPのWebページ：http://www.pwg.org/ipp/ IPPメーリングリスト：ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
IPPメーリングリストを購読するには、次の電子メールを送信します。
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
1）メッセージ本文に次の2行を置く））2をmajordomo@pwg.org 3空白の件名行を残すためにそれを送る：IPP端を購読
Implementers of this specification document are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list.
この仕様書の実装者は、明確化の問題や、追加の属性と値のための登録提案の審査のいずれかの議論に参加するために、IPPのメーリングリストに参加することを奨励されています。あなたがメーリングリストに質問やコメントを送信するために、メーリングリストに参加しなければならないので、スパムを削減するために、メーリングリストは、非加入者からのメールを拒否します。
Other Participants:
他の参加者：
Chuck Adams - Tektronix Shivaun Albright - HP
チャック・アダムス - テクトロニクスShivaunオルブライト - HP
Stefan Andersson - Axis Jeff Barnett - IBM
ステファン・アンダーソン - アクシスジェフ・バーネット - IBM
Ron Bergman - Hitachi Koki Dennis Carney - IBM Imaging Systems
ロン・バーグマン - 日立工機デニス・カーニー - IBMイメージングシステムズ
Keith Carter - IBM Angelo Caruso - Xerox
キース・カーター - IBMアンジェロカルーソ - ゼロックス
Rajesh Chawla - TR Computing Nancy Chen - Okidata Solutions
ラジェッシュチャウラ - TRコンピューティングナンシー・チェン - のOkidataソリューション
Josh Cohen - Microsoft Jeff Copeland - QMS
ジョシュ・コーエン - マイクロソフトジェフ・コープランド - QMS
Andy Davidson - Tektronix Roger deBry - IBM
アンディ・ダビッドソン - テクトロニクスロジャーdeBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Maulikデサイ - MabryたAUC Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh Systems
リー・ファレル - キヤノンインフォメーション聡Fujitami - リコーシステム
Steve Gebert - IBM Sue Gleeson - Digital
スティーブGebert - IBMスー・グリーソン - デジタル
Charles Gordon - Osicom Brian Grimshaw - Apple
チャールズ・ゴードン - Osicomブライアン・グリムショー - アップル
Jerry Hadsell - IBM Richard Hart - Digital
ジェリーHadsell - IBMリチャード・ハート - デジタル
Tom Hastings - Xerox Henrik Holst - I-data
トム・ヘイスティングス - ゼロックスヘンリックホルスト - I-データ
Stephen Holmstead Zhi-Hong Huang - Zenographics
禅0グラフィック - スティーブンHO LMは、お茶のDZのHi-香港黄です
Scott Isaacson - Novell Babek Jahromi - Microsoft
スコット・アイザックソン - ノベルBabek Jahromi - マイクロソフト
Swen Johnson - Xerox David Kellerman - Northlake Software
SWENジョンソン - ゼロックスデビッド・ケラーマン - ノースレイクソフトウェア
Robert Kline - TrueSpectra Charles Kong - Panasonic
ロバート・クライン - TrueSpectraチャールズ香港 - パナソニック
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
カール・クーグラー - IBMデイブKuntz - ヒューレット・パッカード
Takami Kurono - Brother Rick Landau - Digital
たかみ くろの ー Ｂろてぇｒ りｃｋ ぁんだう ー ぢぎたｌ
Scott Lawrence - Agranot Systems Greg LeClair - Epson
スコット・ローレンス - AgranotシステムグレッグLeClair - エプソン
Dwight Lewis - Lexmark Harry Lewis - IBM
ドワイト・ルイス - レックスマークハリー・ルイス - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
トニー遼 - 鮮やかな画像ロイLomicka - デジタル
Pete Loya - HP Ray Lutz - Cognisys
ピートロヤ - HPレイルッツ - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
マイク・マッケイ - ノベル社のDavid Manchala - ゼロックス
Carl-Uno Manros - Xerox Jay Martin - Underscore
カール・宇野Manros - ゼロックス・ジェイ・マーティン - アンダー
Stan McConnell - Xerox Larry Masinter - Xerox
スタン・マコーネル - ゼロックスラリーMasinter - ゼロックス
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
サンドラMatts - ヒューレット・パッカードピーターMichalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
アイラマクドナルド - 極北株式会社マイクモルドバ - G3ノヴァ
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
てつや もりた ー りこｈ ゆいち にわ ー りこｈ
Pat Nogay - IBM Ron Norton - Printronics
パットNogay - IBMロン・ノートン - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
ヒューゴパーラ、ノベルボブペンテコステ - ヒューレット・パッカード
Patrick Powell - Astart Jeff Rackowitz - Intermec Technologies
パトリック・パウエル - ASTARTジェフRackowitz - インターメックテクノロジーズ
Eric Random - Peerless Rob Rhoads - Intel
エリックランダム - ピアレスロブRhoadsの - インテル
Xavier Riley - Xerox Gary Roberts - Ricoh
ザビエルライリー - ゼロックスゲイリー・ロバーツ - リコー
David Roach - Unisys Stuart Rowley - Kyocera
デビッド・ローチ - ユニシススチュアートローリー - 京セラ
Yuji Sasaki - Japan Computer Richard Schneider - Epson Industry
雄二規範 - 日本のコンピュータリチャードscanedir - epison産業
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Ｋりｓ Ｓちょっｆ ー ＨＰ かつあき せきぐち ー かのん
Bob Setterbo - Adobe Gail Songer - Peerless
ボブSetterbo - アドビゲイルSONGER - ピアレス
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
田中秀樹 - キヤノンデボン・テイラー - ノベル株式会社
Mike Timperman - Lexmark Atsushi Uchino - Epson
みけ ちｍぺｒまん ー ぇｘまｒｋ あつし うちの ー えｐそん
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
うえだしげる - アンデルからキヤノンボブ - アレグロソフトウェア
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
ウィリアム・ワグナー - NetSilicon / DPIジム・ウォーカー - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
クリスWellens - インターワーキング研究所トレバー・ウェルズ - ヒューレット・パッカード
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
クレイグホイットル - シャープLabsのロブ削る - ノベル株式会社
Jasper Wong - Xionics Don Wright - Lexmark
ジャスパー・ウォン - Xionicsドン・ライト - レックスマーク
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
マイケル・呉 - ハイデルベルグ・デジタルリックYardumian - ゼロックス
Michael Yeung - Toshiba Lloyd Young - Lexmark
マイケル・ヨン - 東芝ロイドヤング - レックスマーク
Atsushi Yuki - Kyocera Peter Zehler - Xerox
敦ゆき - 京セラピーターZehler - ゼロックス
William Zhang- Canon Information Frank Zhao - Panasonic Systems
ウィリアムZhang-キヤノンインフォメーションフランク趙 - パナソニックシステム
Steve Zilles - Adobe Rob Zirnstein - Canon Information Systems
スティーブZilles - アドビロブZirnstein - キヤノンインフォメーションシステムズ
In addition to this document, the base 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 [RFC2910] Mapping between LPD and IPP Protocols [RFC2569]
以下のための構造とモデルとプロトコルのためのインターネット印刷プロトコル[RFC2567]原理の設計目標インターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/ 1.1：モデルと意味論[RFC2911]インターネット印刷プロトコル/ 1.1：コード化と輸送[RFC2910] LPDとIPPプロトコル[RFC2569]との間のマッピング
The "Design Goals for an Internet Printing Protocol" document 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 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910].
文書「インターネット印刷プロトコルの設計目標は、」分散印刷機能で幅広い見てみると、それはインターネットのための印刷プロトコルに含まれる必要な機能を明確にするために役立つ実際のシナリオを列挙します。エンドユーザー、オペレータ、および管理者：これは、ユーザーの3種類の要件を識別します。それはIPP / 1.0 [RFC2566、RFC2565]で満たされているエンドユーザ要件のサブセットを呼び出します。いくつかのOPTIONALオペレータ操作がIPP / 1.1 [RFC2911、RFC2910]に追加されています。
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document 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 IPP working group's major decisions.
文書「インターネット印刷プロトコルのための構造とモデルとプロトコルのための理論的根拠は、」高レベルのビューからIPPを説明IPP仕様書の一式を形成する様々な文書のためのロードマップを定義し、IETF IPPの背景や根拠を与えますワーキンググループの主要な決定。
The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
「インターネット印刷プロトコル/ 1.1：モデルとセマンティクス」文書は抽象オブジェクト、その属性、およびその操作で単純化したモデルを説明しています。モデルは、プリンタと仕事を紹介しています。ジョブは、ジョブごとに複数のドキュメントをサポートしています。モデルドキュメントは、セキュリティ、国際化、およびディレクトリ問題が解決されているか対応しています。
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting a message body over HTTP whose Content-Type is "application/ipp". This document defines the 'ipp' scheme for identifying IPP printers and jobs.
「インターネット印刷プロトコル/ 1.1：コード化とTransport」文書がHTTP / 1.1へのモデル文書で定義された抽象操作と属性の正式なマッピング[RFC2616]です。また、「アプリケーション/ IPP」と呼ばれる新しいインターネットMIMEメディアタイプの符号化規則を定義します。また、このドキュメントでは、そのコンテンツタイプ「アプリケーション/ IPP」であるHTTPを介してメッセージ本体を輸送するためのルールを定義します。この文書では、IPPプリンタと仕事を特定するための「IPP」スキームを定義します。
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
文書「LPDとIPPプロトコル間のマッピングは、」IPPとのLPD（Line Printer Daemon）実装の間のゲートウェイの実装にいくつかのアドバイスを提供します。
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。