Network Working Group T. Hastings
Request for Comments: 2639 C. Manros
Category: Informational Xerox Corporation
July 1999
Internet Printing Protocol/1.0: Implementer'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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
この文書は、一緒に新しいインターネット印刷プロトコル（IPP）のすべての側面を記述した文書のセットの1つです。 IPPは、インターネットツールと技術を使用して、分散印刷のために使用することができるアプリケーションレベルのプロトコルです。この文書では、IPPモデルと意味論[RFC2566]とIPP交通エンコーディング[RFC2565]の文書を補足する情報が含まれています。実装がIPP / 1.0とそのクライアントおよび/またはIPPオブジェクト実装のデザインでそれらを支援することが検討事項のいくつかを理解するためのものです。例えば、処理要求の典型的な順序は、エラー・チェックを含む、与えられます。仕様決定のいくつかのための動機も含まれています。
The full set of IPP documents includes:
IPPドキュメントのフルセットが含まれています：
Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.0: Model and Semantics [RFC2566] Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] Mapping between LPD and IPP Protocols [RFC2569]
以下のための構造とモデルとプロトコルのためのインターネット印刷プロトコル[RFC2567]原理の設計目標インターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/ 1.0：モデルと意味論[RFC2566]インターネット印刷プロトコル/ 1.0：コード化と輸送[RFC2565] LPDとIPPプロトコル[RFC2569]との間のマッピング
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
文書、「インターネット印刷プロトコルの設計目標は、」分散印刷機能で幅広い見てみると、それはインターネットのための印刷プロトコルに含まれる必要な機能を明確にするために役立つ実際のシナリオを列挙します。エンドユーザー、オペレータ、および管理者：これは、ユーザーの3種類の要件を識別します。設計目標の文書がIPP / 1.0で満たされているエンドユーザーの要求のサブセットを呼び出します。オペレータと管理者の要件は、バージョン1.0の範囲外です。
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.
文書、「インターネット印刷プロトコルのための構造とモデルとプロトコルのための理論的根拠は、」高レベルのビューからIPPを説明し、IPP仕様のスイートを構成する様々な文書のためのロードマップを定義し、IETFの背景や根拠を与えますワーキンググループの主要な決定。
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. 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.0：モデルとセマンティクス」、抽象オブジェクト、その属性、およびその操作で単純化したモデルを説明しています。モデルは、プリンタと仕事を紹介しています。ジョブは、ジョブごとに複数のドキュメントをサポートしています。モデルドキュメントは、セキュリティ、国際化、およびディレクトリ問題が解決されているか対応しています。
The document, "Internet Printing Protocol/1.0: Encoding and Transport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called "application/ipp".
文書、「インターネット印刷プロトコル/ 1.0：コード化と輸送」は、HTTP / 1.1にモデル文書で定義された抽象操作と属性の正式なマッピングです。また、「アプリケーション/ IPP」と呼ばれる新しいインターネットメディアタイプのための符号化規則を定義します。
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
文書は、「LPDとIPPプロトコル間のマッピング」、IPPとのLPD（Line Printer Daemon）実装の間のゲートウェイの実装にいくつかのアドバイスを提供します。
Table of Contents
目次
1 Introduction......................................................4
1.1 Conformance language............................................4
1.2 Other terminology...............................................5
2 Model and Semantics...............................................5
2.1 Summary of Operation Attributes.................................5
2.2 Suggested Operation Processing Steps for IPP Objects ..........10
2.2.1 Suggested Operation Processing Steps for all Operations..11
2.2.1.1 Validate version number...............................11
2.2.1.2 Validate operation identifier.........................11
2.2.1.3 Validate the request identifier.......................11
2.2.1.4 Validate attribute group and attribute presence and
order.................................................12
2.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................19
2.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................23
2.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents.....................26
2.2.2.1 Default "ipp-attribute-fidelity" if not supplied......26
2.2.2.2 Check that the Printer object is accepting jobs.......26
2.2.2.3 Validate the values of the Job Template attributes....26
2.2.3 Algorithm for job validation...............................27
2.2.3.1 Check for conflicting Job Template attributes values..33
2.2.3.2 Decide whether to REJECT the request..................33
2.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes..................................34
2.2.3.4 Create the Job object with attributes to support......34
2.2.3.5 Return one of the success status codes................36
2.2.3.6 Accept appended Document Content......................36
2.2.3.7 Scheduling and Starting to Process the Job............36
2.2.3.8 Completing the Job....................................37
2.2.3.9 Destroying the Job after completion...................37
2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
2.3 Status codes returned by operation ............................37
2.3.1 Printer Operations.........................................38
2.3.1.1 Print-Job.............................................38
2.3.1.2 Print-URI.............................................40
2.3.1.3 Validate-Job..........................................40
2.3.1.4 Create-Job............................................41
2.3.1.5 Get-Printer-Attributes................................41
2.3.1.6 Get-Jobs..............................................42
2.3.2 Job Operations.............................................43
2.3.2.1 Send-Document.........................................43
2.3.2.2 Send-URI..............................................44
2.3.2.3 Cancel-Job............................................44
2.3.2.4 Get-Job-Attributes....................................45
2.4 Validate-Job...................................................46
2.5 Case Sensitivity in URIs ......................................46
2.6 Character Sets, natural languages, and internationalization....46
2.6.1 Character set code conversion support .....................46
2.6.2 What charset to return when an unsupported charset is
requested?.................................................48
2.6.3 Natural Language Override (NLO) ...........................48
2.7 The "queued-job-count" Printer Description attribute...........50
2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
2.7.2 Is "queued-job-count" a good measure of how busy a printer
is?........................................................50
2.8 Sending empty attribute groups ................................50
2.9 Returning unsupported attributes in Get-Xxxx responses ........51
2.10 Returning job-state in Print-Job response ....................51
2.11 Flow controlling the data portion of a Print-Job request .....52
2.12 Multi-valued attributes ......................................53
2.13 Querying jobs with IPP that were submitted using other job
submission protocols .........................................53
2.14 The 'none' value for empty sets ..............................54
2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
2.16 The "multiple-document-handling" Job Template attribute and
support of multiple document jobs.............................54
3 Encoding and Transport...........................................55
3.1 General Headers................................................56
3.2 Request Headers...............................................57
3.3 Response Headers...............................................58
3.4 Entity Headers................................................59
3.5 Optional support for HTTP/1.0..................................60
3.6 HTTP/1.1 Chunking..............................................60
3.6.1 Disabling IPP Server Response Chunking.....................60
3.6.2 Warning About the Support of Chunked Requests..............60
4 References.......................................................61
4.1 Authors' Addresses.............................................62
5 Security Considerations..........................................62
6 Notices..........................................................62
Full Copyright Statement............................................65
1 Introduction
1はじめに
This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. As such this information is not part of the formal specifications. Instead information is presented to help implementers understand the specification, 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 [RFC2566] or [RFC2565], those documents take precedence over this document.
この文書では、IPPモデルと意味論[RFC2566]とIPP交通エンコーディング[RFC2565]の文書を補足する情報が含まれています。そのため、この情報は、正式な仕様の一部ではありません。代わりに、情報は、実装者が仕様を開発する際に委員会によって行われた決定のための動機の一部を含め、仕様の理解を助けるために提示されます。実装上の考慮事項の一部は、実装が彼らのクライアントおよび/またはIPPオブジェクト実装の設計を支援することを意図しています。このドキュメントと[RFC2566]か[RFC2565]の間に何らかの矛盾がある場合は、それらの文書は、この文書に優先します。
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 [RFC2566] and [RFC2565] documents require and allow, rather than specifying additional conformance requirements. These terms are defined in section 13 on conformance terminology in [RFC2566], most of which is taken from RFC 2119 [RFC2119].
通常、MUSTは、NOT MUST用語、MAYが含まれていないこの文書では、SHOULD、SHOULD、REQUIRED、およびオプションではない、する必要はありません。それらの用語は、本文書に表示されないときしかし、彼らの意図ではなく、追加の適合性要件を指定するよりも、[RFC2566]と[RFC2565]の文書が必要で何を繰り返してできるようにすることです。これらの用語は[RFC2566]に順応用語のセクション13で定義され、そのほとんどは、RFC 2119 [RFC2119]から取られます。
Implementers should read section 13 in [RFC2566] 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 [RFC2566] and [RFC2565]. 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.
実装は、これらの大文字の単語を理解するために[RFC2566]セクション13を読んでください。言葉は、NOT MUST MUST、およびREQUIREDは、[RFC2566]と[RFC2565]に準拠するために、クライアントやIPPオブジェクトでサポートするために必要なものを実装を示しています。 MAYは、必要はなく、オプションは単に実装オプションとして許可されたことを示します。動詞はと提案行動を示しすべきでないが、仕様に準拠するためには、それぞれ、必須または禁止されていません。
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.
用語「送信者は、」要求または応答を返すIPPオブジェクトを送信するクライアントを指します。用語「受信機」は、要求を受信し、応答を受信したクライアントにIPPオブジェクトを指します。
2 Model and Semantics
2モデルとセマンティクス
This section discusses various aspects of IPP/1.0 Model and Semantics [RFC2566].
このセクションでは、IPP / 1.0モデルと意味論[RFC2566]のさまざまな側面について説明します。
Legend for the following table:
次の表の凡例：
R indicates a REQUIRED operation or attribute for an
implementation to support
O indicates an OPTIONAL operation or attribute for an implementation to support
Oは、サポートへの実装のために任意のオペレーションや属性を示します
Table 1. Summary of operation attributes for Printer operations
操作表1.は、プリンタの操作属性
Printer Operations
プリンタの操作
Requests Responses
要求応答
Operation Print- Pri Crea Get- Get- All Attributes Job, nt- te- Printer- Jobs Opera-Validate URI Job Attribut tions -Job (O) (O) es
操作プリントのPriクレアGET- GET-すべてのジョブ属性、NT-TE- Printer-ジョブズオペラ・検証URI仕事Attributション - ジョブ（O）（O）ES
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- R R R R R R natural-language
属性 - R R R R R R自然言語
document-uri R
文書-URI R
job-id*
ジョブID *
job-uri*
仕事-URI *
last-document
最後に、文書
printer-uri R R R R R
プリンタ・ウリ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 name
R R R R R名-USER-を要求
Printer Operations
プリンタの操作
Requests Responses
要求応答
Operation Print- Pri Crea Get- Get- All Attributes Job, nt- te- Printer Jobs Opera-Vali- URI Job Attri- tions date-Job (O) (O) butes
操作プリントのPriクレアGET- GET-すべては仕事、NT-TE-プリンタジョブオペラVali- URI仕事Attri-のション日付仕事（O）（O）butes属性
Operation attributes-OPTIONAL to be supplied by the sender
送信者によって供給される操作属性 - オプション
status-message O
ステータスメッセージO
compression O O
圧縮ザ・
document-format R R O
文書フォーマットR R O
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
じょｂーめぢあーしぇえｔｓ お お お
limit R
リミットR
message
メッセージ
my-jobs R
私-ジョブR
requested- R R attributes
requested- R R属性
which-jobs R
- ジョブR
* "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED.
*「ジョブID」は、対象のジョブを識別するために、「プリンタ-URI」と一緒に使用する場合にのみ必要です。そうでない場合は、「ジョブ-URI」が必要です。
Table 2. Summary of operation attributes for Job operations
操作の表2の概要は、ジョブ操作のための属性
Requests Responses
要求応答
Operation Send- Send- Cancel Get- All Attributes Document URI -Job Job- Opera-(O) (O) Attri- tions butes
操作Send- Send-キャンセルGET-すべてのドキュメントURI - ジョブJob- Opera-（O）（O）Attri-ションbutes属性
Operation parameters--REQUIRED to be supplied by the sender
動作パラメータ - 送信者によって供給する必要が
operation-id R R R R
操作IDのR R R R
status-code R
ステータスコードR
request-id R R R R R
要求ID R R R R R
version-number 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 charset
属性 - R R R R R文字セット
attributes- R R R R R natural-language
属性 - R R R R R自然言語
document-uri R
文書-URI R
job-id* R R R R
ジョブID * R R R R
job-uri* R R R R
仕事-URI * R R R R
last-document R R
最後に、文書R R
printer-uri R R R R
プリンタ・ウリP P P P
Operation attributes-RECOMMENDED to be supplied by the sender
操作属性推奨の送信者によって供給されます
job-name
職種名
requesting-user- R R R R name
R R R R名-USER-を要求
Job Operations
ジョブの操作
Requests Responses
要求応答
Operation Attributes Send- Send- Cance Get- All Document URI l-Job Job- Opera-(O) (O) Attri- tions butes
操作属性Send- Send- Cance GET-すべてのドキュメントURIリットル-ジョブJob- Opera-（O）（O）Attri-ションbutes
Operation attributes.OPTIONAL to be supplied by the sender
操作attributes.OPTIONALは、送信者によって供給されます
status-message O
ステータスメッセージO
compression O O
圧縮ザ・
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
ジョブメディアシート
limit
限定
message O
メッセージO
my-jobs
私、仕事
requested-attributes R
Rは、要求されたアトリビュート
which-jobs
これは、ジョブ
* "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED.
*「ジョブID」は、対象のジョブを識別するために、「プリンタ-URI」と一緒に使用する場合にのみ必要です。そうでない場合は、「ジョブ-URI」が必要です。
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に送信し、文書を追加し、ジョブを検証します。
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 requested minor version is not supported (the requested minor version is either higher or lower) than a supported minor version, the IPP object SHOULD return the closest supported minor version.
マイナーバージョン番号のチェックは実装依存である、しかし、クライアントはマイナーバージョンを供給した場合、明示的にIPPオブジェクトはその同じマイナーバージョン番号を使用して応答しなければならない、サポートされています。要求されたマイナーバージョンがサポートされていない場合は、サポートのマイナーバージョンより（要求されたマイナーバージョンは、どちらか高いか低い）、IPPオブジェクトは、最も近いサポートマイナーバージョンを返すべきです。
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.0 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.0符号化における固定オクテットの位置にあります。 「バージョン番号」パラメータは、プロトコルのすべてのバージョンで同じ固定オクテット位置であろう。これらのフィールドは、検証の残りの部分に進む前に検証されます。
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は、他のベンダーからのオブジェクトと複数のベンダーから、このようなクライアントを使用することができます可能性が高くなり、適切なフォームを使用するように強制クライアントオブジェクト。
2.2.1.4.3 Validate the presence of a single occurrence of required Operation attributes
2.2.1.4.3必要な操作属性の1回の発生の有無を検証します
Client requests and IPP object responses contain Operation attributes that [RFC2566] 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オブジェクト応答は、操作は[RFC2566]セクション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オブジェクトの振る舞いは実装依存です。可能な実装のいくつかは以下のとおりです。
1.REJECTS the request and RETURNS the 'client-error-bad-request' status code
リクエストを1.REJECTSと 'クライアント誤り悪い要求のステータスコードを返します
2.accepts the request and uses the first occurrence of the attribute no matter where it is
リクエストを2.acceptsと関係なく、それがどこにある属性の最初の発生を使用していません
3.accepts the request and uses the last occurrence of the attribute no matter where it is
リクエストを3.acceptsと関係なく、それがどこにある属性の最後の発生を使用していません
4.accept the request and assume some default value for the missing attribute
リクエスト4.acceptし、不足している属性のためのいくつかのデフォルト値を仮定
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 [RFC2566] 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:
以下の表は、各要求と各応答における属性グループによってすべての操作のすべての属性をリストします。グループの順序は、[RFC2566]セクション3で指定されたグループ内の属性の順序が特別な操作属性（文字セット、自然言語の一部について述べたように除いて、任意で、クライアントがグループを供給するようにするためでありますそしてターゲット）。以下の表は、次の表記を使用します。
R indicates a REQUIRED attribute that an IPP object MUST support O indicates an OPTIONAL attribute 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.
RはIPPオブジェクトがOをサポートしなければならないことをREQUIRED属性は、クライアントがリクエストに属性を省略し、IPPオブジェクトが応答で属性を省略するかもしれないことかもしれないことを示している* IPPオブジェクトがサポートする必要がないことがOPTIONAL属性を示して示しています。 *の不在は、クライアントがリクエストに属性を供給しなければなりませんし、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: 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 (O*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see [RFC2566] Section 4.2) Group 3: Document Content (R) <document content>
印刷ジョブ要求：グループ1：操作（R）属性は、（R）属性 - 自然言語（R）プリンタ-uriの（R）を要求するユーザー名（R *）ジョブ名（R *）IPPを、文字セット属性-attribute忠実度（R *）ドキュメント名（R *）ドキュメントフォーマット（R *）ドキュメント自然言語（O *）圧縮（O *）ジョブ-K-オクテット（O *）ジョブ・インプレッション（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（Rの*）<ジョブテンプレート属性>（O *）（参照[RFC2566]セクション4.2）グループ3：ドキュメントコンテンツ（R）<文書の内容>
Validate-Job Request: 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 (O*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see [RFC2566] Section 4.2)
リクエストを-仕事に検証：グループ1：操作は、（R）属性 - 文字セット（R）属性 - 自然言語（R）プリンタ-uriの（R）を要求するユーザー名（R *）ジョブ名（R *）IPP属性-attribute忠実度（R *）ドキュメント名（R *）ドキュメントフォーマット（R *）ドキュメント自然言語（O *）圧縮（O *）ジョブ-K-オクテット（O *）ジョブ・インプレッション（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（式中、R *）<ジョブテンプレート属性>（O *）（参照[RFC2566]セクション4.2）
Create-Job Request: 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 [RFC2566] Section 4.2)
作成し、仕事の要求：グループ1：操作（R）の属性属性-文字セット（R）属性 - 自然言語（R）プリンタ-uriの（R）を要求するユーザー名（R *）ジョブ名（R *）IPPを-attribute忠実度（Rの*）ジョブKオクテット（O *）ジョブ感想（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（Rの*）<ジョブテンプレート属性>（O *）（（参照[RFC2566]セクション4.2を参照されたいです）
Print-URI Request: 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 (O*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see (see [RFC2566] Section 4.2)
印刷-URI要求：グループ1：操作（R）属性は、属性、文字セット（R）は属性 - 自然言語（R）プリンタ-uriの（R）文書-uriの（R）を要求するユーザー名（R *）job-名（R *）IPP属性忠実度（R *）、文書名（R *）ドキュメント・フォーマット（R *）ドキュメント自然言語（O *）圧縮（O *）ジョブKオクテット（O * ）ジョブ感想（O *）ジョブメディアシート（O *）グループ2：ジョブテンプレート属性（Rの*）<ジョブテンプレート属性>（O *）（参照（参照[RFC2566]セクション4.2）
Send-Document Request: 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 (O*) Group 2: Document Content (R*) <document content>
送信・資料請求：グループ1：操作（R）属性は、（R）属性 - 自然言語（R）（プリンタ-URI＆ジョブid）を、文字セット属性を|仕事-URI（R）最後のドキュメント（R）を要求するユーザー名（R *）、文書名（R *）ドキュメント・フォーマット（R *）ドキュメント自然言語（O *）圧縮（O *）グループ2：ドキュメントコンテンツ（R *）<文書の内容>
Send-URI Request: 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 (O*)
要求URIの送信：グループ1：操作（R）属性属性-文字セット（R）は、属性の自然言語（R）（プリンタ-URI＆ジョブIDを）|仕事-URI（R）最後のドキュメント（R）文書-uriの（R）を要求するユーザー名（R *）、文書名（R *）ドキュメント・フォーマット（Rの*）ドキュメント自然言語（Oの*）圧縮（Oの*）
Cancel-Job Request: 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*)
キャンセル-仕事要求：グループ1：操作（R）属性は、（R）属性 - 自然言語（R）（プリンタ-URI＆ジョブID） - 文字セット属性|仕事-URI（R）を要求するユーザー名（R *）メッセージ（Oの*）
Get-Printer-Attributes Request: 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*)
リクエスト・プリンタ・属性の取得：グループ1：操作は、（R）の属性属性-文字セット（R）は属性 - 自然言語を（R）プリンタ-uriの（R）を要求するユーザー名（R *）要求-属性（R * ）ドキュメントフォーマット（R *）
Get-Job-Attributes Request: 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*)
・ジョブ・属性取得要求：グループ1：操作は、（R）属性（R）属性 - 自然言語（R）（プリンタ-URI＆ジョブID） - 文字セット属性|仕事-URI（R）を要求するユーザー名（R *）要求-属性（R *）
Get-Jobs Request: 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*)
リクエストを-ジョブズ入手：グループ1：操作は、（R）属性（R）属性 - 自然言語（R）プリンタ-uriの（R）を要求するユーザー名（R *）リミット（R *）を、文字セットの属性を要求し、属性（R *）は、ジョブ（R *）私の-ジョブ（R *）
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: Print-URI Response: Create-Job Response:
印刷ジョブの応答：印刷-URIの応答：作成し、仕事の応答：
Send-Document Response: Send-URI Response: Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (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*) job-state-message (O*) number-of-intervening-jobs (O*)
送信-ドキュメントレスポンス：送信-URI応答：グループ1：操作（R）属性を属性 - 文字セット（R）は属性 - 自然言語（R）のステータスメッセージ（O *）グループ2：サポートされていない属性（R *）（参照注3）<サポートされていない属性は>（R *は）グループ3：ジョブオブジェクトの属性（R *）（2）仕事-URI（R）ジョブID（R）ジョブの状態（R）ジョブ状態の理由を（注記Oの*）ジョブ状態メッセージ（O *）数の--ジョブを介在（O *）
Validate-Job Response: Cancel-Job Response: Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) Group 2: Unsupported Attributes (R*) (see Note 3) <unsupported attributes> (R*)
レスポンス・ジョブを検証：レスポンス・ジョブをキャンセル：グループ1：サポートされていない属性（R *）（参照：操作は（R）属性は、（R）属性 - 自然言語（R）のステータスメッセージ（O *）グループ2 - 文字セットの属性注3）<サポートされていない属性>（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注 - サポートされていないグループは、クライアントがプリンタがサポートしていないいくつかの操作、および/またはジョブテンプレート属性または値が含まれている場合にのみ存在する属性の成功またはエラーリターンするかどうか。
Get-Printer-Attributes Response: Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) 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*)
ゲット・プリンタは、属性の応答：グループ1：操作属性（R）属性 - 文字セット（R）は属性 - 自然言語（R）のステータスメッセージ（O *）グループ2：サポートされていない属性（R *）を（注4参照） <サポートされていない属性>（R *）グループ3：プリンタオブジェクトの属性（R *）（注2参照）<要求された属性>（R *）
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 - サポートされていないグループは、クライアントは、いくつかの操作は、プリンタでサポートされていない属性が含まれている場合にのみ存在する属性の成功またはエラーリターンするかどうか。
Get-Job-Attributes Response: Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) 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*)
ゲット・仕事・属性応答：グループ1：操作属性（R）属性 - 文字セット（R）は、属性の自然言語（R）のステータスメッセージ（O *）グループ2：サポートされていない属性（R *）を（注4参照します） <サポートされていない属性>（R *）グループ3：ジョブオブジェクトの属性（R *）（注2参照）<要求された属性>（R *）
Get-Jobs Response: Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) 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*)
ゲット・ジョブズの応答：グループ1：操作の属性（R）は属性-文字セット（R）は属性 - 自然言語（R）のステータスメッセージ（O *）グループ2：サポートされていない属性（R *）を<サポートされていない（注4参照）属性>（R *）グループ3：ジョブオブジェクトの属性（R *）（注2参照、5）<要求された属性>（R *）
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 [RFC2566] Section 4.1,
A）各操作属性値の長さは、[RFC2566]セクション4.1に従ってクライアントによって供給された属性構文タグに正しいこと
b)that the attribute syntax tag is correct for that Operation attribute according to [RFC2566] Section 3,
B）属性構文タグは、[RFC2566]セクション3に係るその操作属性の正しいこと
c)that the value is in the range specified for that Operation attribute according to [RFC2566] Section 3,
C）値は、[RFC2566]セクション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 [RFC2566] Section 3.
D）複数の値のみ1setOf Xは[RFC2566]セクション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
これらのチェックのいずれかが失敗した場合、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求」または「クライアント誤り要求値-長すぎる」ステータスコードを返します。このようなエラーがクライアントの開発者ではなく、エンドユーザが検出されたエラーである可能性が最も高いので、IPPオブジェクトはサポートされていない属性グループまたはいずれかのエラーを持っていた属性の表示を返す必要はありません
Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
ステータスメッセージ。これらの構文チェックのそれぞれについての説明は、明示的に次の表の最初の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'. IF NOT in the Printer object's "charset-supported" attribute, REJECT/RETURN "client-error-charset-not-supported".
値の長さが63オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 Printerオブジェクトの "文字セット・サポート" 属性で、/ RETURNをREJECTていない場合は、 "クライアント・エラー-charsetが-サポートされていません"。
attributes-natural-language(naturalLanguage)
属性 - 自然言語（自然言語）
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 63 octets, REJECT/RETURN ' client-error-request-value-too-long'. 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.
そうでない場合は、単一の非空の「自然言語」値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが63オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。要求してもいない場合はPrinterオブジェクトの「生成された自然言語サポート」属性にセットのメンバーを受け入れます。指定された値がPrinterオブジェクトの「生成された自然言語サポート」属性のメンバーでない場合、Printerオブジェクトの「自然言語に構成された」値を使用します。
requesting-user-name
要求元のユーザー名
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF the IPP object can obtain a better authenticated name, use it instead.
そうでない場合は、単一の「name」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 IPPオブジェクトは、より良い認証された名前を取得することができる場合、代わりにそれを使用しています。
job-name(name)
ジョブ名（名前）
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT supplied by the client, the Printer object creates a name from the document-name or document-uri.
そうでない場合は、単一の「name」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。クライアントによって提供されていない場合、Printerオブジェクトは、文書名や文書-URIから名前を作成します。
document-name (name)
文書名（名前）
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
そうでない場合は、単一の「name」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
ipp-attribute-fidelity (boolean)
IPP属性忠実度（ブール値）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is NOT equal to 1 octet, REJECT/RETURN ' client-error-request-value-too-long' IF NOT supplied by the client, the IPP object assumes the value 'false'.
シングル「真」NORシングル「偽」「ブールNEITHER場合、クライアント誤り悪い要求」「値、/ RETURN REJECT」を。値の長さは1つのオクテットに等しいされていない場合は、クライアントによって提供されていない場合、IPPオブジェクトが「偽」の値をとる「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
document-format (mimeMediaType)
ドキュメント・フォーマット（mimeMediaType）
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT in the Printer object's "document-format-supported" attribute, REJECT/RETURN 'client-error-document-format-not-supported'
そうでない場合は、単一の非空の「mimeMediaType」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 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'. IF the value length is greater than 1023 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-request'. IF scheme is NOT in the Printer object's "reference-uri-schemes-supported" attribute, REJECT/RETURN 'client-error-uri-scheme-not-supported'. 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」値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが1023オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 URIの構文が有効でない場合、/ RETURN「クライアント誤り悪い要求」を拒否します。スキームはPrinterオブジェクトの「参照-URI-スキーム・サポート」属性にされていない場合は、/ RETURNのクライアント・エラー-URI-スキーム-サポートされていません "REJECT。 Printerオブジェクトは、文書が存在し、アクセス可能であるかどうかを確認するかもしれません。文書が見つからないか、アクセスできませんされている場合は、RETURN「クライアント誤りが見つかりません」/ REJECT。
last-document (boolean)
最後のドキュメント（ブール値）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is NOT equal to 1 octet, REJECT/RETURN ' client-error-request-value-too-long'
シングル「真」NORシングル「偽」「ブールNEITHER場合、クライアント誤り悪い要求」「値、/ RETURN REJECT」を。値の長さは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'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. 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.
そうでない場合は1以上の「キーワード」値は、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。サポートされていない属性のキーワード名ですサポートされていない値を無視します。 （サポートされていない）、このような要求をコピーするために気にしないでください応答がそれらを返さないので、サポートされていない属性応答グループに属性。
which-jobs (type2 keyword)
・ジョブ（TYPE2キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. 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'. 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.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 IF NEITHER「完了」NOR「-完了していない」、属性をコピーして、サポートされていないにサポートされていない値は、応答グループの属性と/ RETURN「クライアント誤り属性 - または - 値は-サポートされていません」REJECT。注意：プリンタはまだそれが完了/キャンセル/中止されたジョブを保持していない場合でも、「完了」の値をサポートしていますので、照会時にどんな仕事を返さないことで。クライアントによって提供されていない場合、IPPオブジェクトは、「未完」の値をとります。
my-jobs (boolean)
私-ジョブ（ブール値）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is NOT equal to 1 octet, REJECT/RETURN ' client-error-request-value-too-long' IF NOT supplied by the client, the IPP object assumes the 'false' value.
シングル「真」NORシングル「偽」「ブールNEITHER場合、クライアント誤り悪い要求」「値、/ RETURN REJECT」を。値の長さは1つのオクテットに等しいされていない場合は、クライアントによって提供されていない場合、IPPオブジェクトが「偽」の値をとる「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。
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'. IF NOT supplied by the client, the IPP object returns all jobs, no matter how many.
4つのオクテットに等しい単一の「整数」の値でない場合にはMAXの範囲1において、/ RETURN「クライアント誤り悪い要求」を拒否します。クライアントによって提供されていない場合、IPPオブジェクトは、どんなに多くの、すべてのジョブを返しません。
OPTIONAL Operation attributes are those that an IPP object MAY or MAY NOT 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 2.2.1.5. As in Section 2.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オブジェクトは、セクション2.2.1.5に、各オプションの属性値に対して同じ構文検証チェックを行います。節2.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'. IF the value length is greater than 63 octets, REJECT/RETURN ' client-error-request-value-too-long'. 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'.
そうでない場合は、単一の非空の「自然言語」値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが63オクテットよりも大きい場合、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。そうでない場合は、プリンタオブジェクトがドキュメント形式に対応していること値、（ノー対応する「XXX-サポート」Printer属性）、RETURN「クライアント誤り自然言語-サポートされていません」/ REJECT。
compression (type3 keyword)
圧縮（TYPE3キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN ' client-error-request-value-too-long'. IF NOT in the Printer object's "compression-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'.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 Printerオブジェクトの「圧縮サポート」属性で、属性とサポートされていないにサポートされていない値応答グループの属性をコピーして/ RETURN REJECTされていない場合のクライアント誤り属性-または値を-サポートされていません "。
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'. 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'.
そうでない場合は4つのオクテットに等しい単一の「整数」値、/ RETURN「クライアント誤り悪い要求」を拒否します。 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'. 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'.
そうでない場合は4つのオクテットに等しい単一の「整数」値、/ RETURN「クライアント誤り悪い要求」を拒否します。 Printerオブジェクトのの範囲内で、「ジョブメディアシート・サポート」されていない場合、属性、属性およびサポートされていない属性応答グループにサポートされていない値をコピーし、REJECT / RETURN「クライアント誤り属性-または値-not- 」サポートされています。
message (text(127))
メッセージ（テキスト（127））
IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 127 octets, REJECT/RETURN 'client-error-request-value-too-long'.
そうでない場合は、単一の「テキスト」値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが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'. 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.
クライアントが供給する属性構文がサポートされていますが、長さは、その属性構文のための法的されていない場合は、REJECT / RETURN「クライアント誤り要求値-長すぎます」。 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 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オブジェクトは、 "成功-OK-無視-または置換 - 属性のステータスコードを返します。サポートされていない操作はすべての操作で属性を無視すると、クライアントが「偽」値と「IPP属性忠実度」Operation属性を供給する場合、テンプレートを作成および検証 - 仕事の操作でサポートされていない属性仕事の取り扱いに類似しています。我々は古いクライアントができる新しいIPPオブジェクトと、新しいクライアントとの間の作業の古いIPPオブジェクトとの間の仕事ができるように任意のオペレーションは、IPPの将来のバージョンに属性を追加できるように、この最後のルールがあります。 （新しい属性が予期せずに実行せずに無視することができない場合は、メジャーバージョン番号はプロトコルドキュメントで、要求が増加されていたであろう）。操作属性のこのルールは、「IPP属性忠実度」属性の値とは無関係です。例えば、IPPオブジェクトは「、未知の属性としてIPPオブジェクト扱い 『ジョブK-オクテット』とだけのための長さをチェックする 『オプション「ジョブK-オクテット」属性をサポートしていない場合、属性構文を整数』クライアントによって提供されます。それは4つのオクテットでない場合は、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求のステータスコードを返し、それ以外のIPPオブジェクトのコピーサポートされていない属性応答グループに属性、「OUT-に値を設定します『サポートされていない』の値「バンドの、それ以外の属性を無視します。
2.2.2 Suggested Additional Processing Steps for Operations that Create/Validate Jobs and Add Documents
/検証ジョブを作成し、ドキュメントを追加操作の2.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を送信します。これらは、印刷ジョブの要求を検証し、雇用を創出する事業であり、ジョブに文書を追加します。
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 object's "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code.
Printerオブジェクトの「プリンタ - 受容され、ジョブ」の値が「偽」である場合、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 2.2.1.5.):
IPPオブジェクトは、クライアントが提供するすべてのジョブテンプレート属性の値を検証します。 IPPオブジェクト（セクション2.2.1.5を参照。）操作属性のためにそれが実行する各ジョブテンプレート属性の値の類似構文の妥当性チェックを実行します。
a)that the length of each value is correct for the attribute syntax tag supplied by the client according to [RFC2566] Section 4.1.
a）は、各値の長さは、[RFC2566]セクション4.1に従ってクライアントによって供給された属性構文タグの正しいこと。
b)that the attribute syntax tag is correct for that attribute according to [RFC2566] Sections 4.2 to 4.4.
B）属性構文タグは[RFC2566]セクション4.4から4.2によれば、その属性のために適切であること。
c)that multiple values are supplied only for multi-valued attributes, i.e., that are 1setOf X according to [RFC2566] Sections 4.2 to 4.4.
C）複数の値のみ[RFC2566]セクション4.4から4.2に係る1setOf Xある多値属性、即ち、のために供給されます。
As in Section 2.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.
節2.2.1.5と同様に、これらの構文チェックのいずれかが失敗した場合、IPPオブジェクトは、要求を拒否し、「クライアント誤り悪い要求」または「クライアント誤り要求値-長すぎる」ステータスコードなどをRETURNS 「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 syntax' error status code
操作1.rejectと「クライアント誤り悪い構文」エラーステータスコードを返します
2.accept the operation and use the first occurrence of the attribute
操作を2.acceptと属性の最初の発生を使用
3.accept the operation and use the last occurrence of the attribute
操作を3.acceptと属性の最後の発生を使用
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 [RFC2566]).
Printer属性「XXX-サポート」次の検証アルゴリズムを使用することができます（[RFC2566]でセクション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 3 with each value X. Each validation is separate from the standpoint of returning unsupported values.
1.If U各検証がサポートされない値を返すの観点から分離された各値Xを用いて、表3にアルゴリズムを実行することによってUの各値Xを検証し、多値です。
Example: If U is "finishings" that the client supplies with 'staple', 'bind' values, then X takes on the successive values: 'staple', then 'bind'
例：Uは「仕上げ」「ステープル」とのクライアント用品いる、「バインド」の値である場合、Xは、連続した値になります：「主食」、そして「バインド」
2.If V is multi-valued, validate X against each Z of V by performing the algorithm in Table 3 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.
2.IfはVが値Zが、Xが成功した属性値の妥当性を検証する場合、各値Zを用いて、表3にアルゴリズムを実行することにより、Vの各Zに対するXを検証し、多値です。それが失敗した場合VのZは、検証が失敗しない複数の値が存在しない場合、アルゴリズムは、Vの次の値（Z）に印加されます。
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.
Vが「辺サポート」が値で：例えば「片面」、「両面長い」、および「両面短」、次にZは、連続値を取る：「片側」、 「両面長」、および「両面短」。 「両面長」があれば、クライアント用品「両面」、最初の比較が失敗した（「一方的な」「両面長」に等しくない）、第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 3.
3.IfはUとVの両方が単一値であり、X U及びZはVであり、表3に検証ルールを使用することができます。
Table 3 - Rules for validating single values X against Z
表3 - Zに対して単一の値Xを検証するためのルール
attribute attribute validated if: syntax of X syntax 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 [RFC2566] section 3.2.1.1 and 3.2.5.1.
いくつかのジョブテンプレート属性は、いくつかの文書フォーマットのためにサポートしていない他人のためか、値が異なる文書フォーマットごとに異なるされている場合は、IPPオブジェクトは、クライアントによって提供される「ドキュメント・フォーマット」の値を使用して、この検証で考慮にそれを取る必要があります（クライアントによって提供されていない場合や、プリンタの「ドキュメント形式デフォルト」属性の値にデフォルト設定）。例えば、「数アップは」「text / plainの」ドキュメントフォーマットのためにサポートされている場合が、「アプリケーション/追伸」ドキュメントフォーマットのために、チェックする必要があります（それはする必要はありませんけれども）は、「文書の値に依存しません-format」操作属性。 [RFC2566]で「ドキュメント・フォーマット」のセクション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))
ジョブ優先度（整数（1：100））
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'. IF NOT supplied by the client, use the value of the Printer object's "job-priority-default" attribute at job submission time. IF NOT in the range 1 to 100, inclusive, copy the attribute and the unsupported value to the Unsupported Attributes response group. 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 [RFC2566] Section 4.2.1.
そうでない場合には、単一の「整数」値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。クライアントによって提供されていない場合、ジョブの投入時にPrinterオブジェクトの「仕事の優先順位デフォルト」属性の値を使用します。 1〜100、包括的、コピー属性とサポートされていないにサポートされていない値は、応答グループの属性の範囲内でない場合範囲1に最も近いサポート値に値をマップ：100プリンタの「ジョブの優先サポート」属性の値で示される離散的な値の数によって指定されます。 [RFC2566]セクション4.2.1で式を参照してください。
job-hold-until (type3 keyword | name)
ジョブホールドまで（TYPE3キーワード|名）
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT supplied by the client, use the value of the Printer object's "job-hold-until" attribute at job submission time. 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.
そうでない場合は、単一の「キーワード」や「名前」の値は、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。クライアントによって提供されていない場合、ジョブ投入時にPrinterオブジェクトの「仕事ホールドまで」属性の値を使用します。 Printerオブジェクトの「仕事ホールドまでのサポート」属性で、属性とサポートされていないにサポートされていない値をコピーしていない場合は、応答グループ属性。
job-sheets (type3 keyword | name)
ジョブシート（TYPE3キーワード|名）
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT in the Printer object's "job-sheets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
そうでない場合は、単一の「キーワード」や「名前」の値は、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 Printerオブジェクトの中に属性を「ジョブ・シート・サポート」されていない場合、属性をコピーして、サポートされていないにサポートされていない値は、応答グループ属性。
multiple-document-handling (type2 keyword)
マルチドキュメントハンドリング（TYPE2キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. 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.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 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'. IF NOT in range of the Printer object's "copies-supported" attribute copy the attribute and the unsupported value to the Unsupported Attributes response group.
そうでない場合には、単一の「整数」値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。 IF NOT Printerオブジェクトの「コピー・サポート」の範囲内の属性とサポートされていない応答グループの属性にサポートされていない値をコピーする属性。
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 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「列挙」値（S）4つのオクテットに等しい長さを有するそれぞれ、/ RETURN「クライアント誤り悪い要求」を拒否します。 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 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'. 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.
IF NOT「rangeOfInteger」値（単数または複数）8つのオクテットに等しい長さを有するそれぞれ、/ RETURN「クライアント誤り悪い要求」を拒否します。最初の値は、任意の範囲の第二の値よりも大きい場合、範囲が昇順になっていない、または範囲が重複/ RETURN「クライアント誤り悪い要求」を拒否します。値がPrinterオブジェクトの「ページ範囲をサポートする」属性が「偽」である場合、サポートされていない応答グループの属性と「アウトオブバンド」「サポートされていない」の値に値を設定する属性をコピーします。
sides (type2 keyword)
側面（TYPE2キーワード）
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT in the Printer object's "sides-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
そうでない場合は、単一の「キーワード」の値、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 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'. 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.
そうでない場合には、単一の「整数」値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。 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 in the Printer object's "orientation-requested-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
IF NOTシングル「列挙型」の値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。 Printerオブジェクトの「配向要求されたサポート」属性で、属性をコピーして、サポートされていないにサポートされていない値は、応答グループの属性れていない場合。
media (type3 keyword | name)
メディア（TYPE3キーワード|名）
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT in the Printer object's "media-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
そうでない場合は、単一の「キーワード」や「名前」の値は、/ RETURN「クライアント誤り悪い要求」を拒否します。値の長さが255オクテットよりも大きい場合は、「長すぎるクライアント誤り要求値-」/ RETURNを拒否します。 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 in the Printer object's "printer-resolution-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
IF NOT 9つのオクテットに等しい長さを持つ単一の「解像度」値、/ RETURN「クライアント誤り悪い要求」を拒否します。 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 in the Printer object's "print-quality-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
IF NOTシングル「列挙型」の値4つのオクテットに等しい長さを持つ、/ RETURN「クライアント誤り悪い要求」を拒否します。 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. 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).
クライアントが供給する属性構文がサポートされていますが、長さは、その属性構文のための法的されていない場合、属性構文の長さが固定されたか「クライアント誤り要求 - である場合、/ RETURN「クライアント誤り悪い要求」とREJECT 「の値があまりに長い属性構文の長さは可変である場合。 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'
'OCTETSTRING' <= 1023 'ブール' = 1 '整数' = 4 'rangeOfInteger' = 8 'のdateTime' = 11 '解像度' = 9 '1setOf X'
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. (2) 'client-error-attributes-or-values-not-supported' status code, otherwise.
（1）「クライアント誤り競合-属性」ステータスコード、クライアントによって供給された属性との間の競合があった場合。 （2）ステータスコード 'クライアント誤り属性、または値-サポートされていない'、そうでありません。
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属性は、重大なエラーだった場合は、上記のは、既に前のステップでの要求を拒否しました。コントロールがサポートされていない操作属性が返されると、このステップに入った場合、彼らは重大なエラーではありません。
2.2.3.3 For the Validate-Job operation, RETURN one of the success status codes
検証ジョブ操作については2.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 may 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-ジョブ・属性操作が永続的にジョーに保存されている属性のみを返します。 Bオブジェクト。
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-競合-属性のステータスコードを、任意の競合のJob Template属性や値があるかどうか。 （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, [RFC2566] section 3.2.1.2.
Printerオブジェクトは、また、（「保留-開催された」、「処理」など、「保留」）など、[RFC2566]セクション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".
一部のプリンタオブジェクトの実装は、「真」と「未遂」と、まだ、まだ、クライアントが作成要求に指定まさに実感することができないように設定された「PDL-オーバーライド・サポート」に設定し、「IPP属性忠実度」をサポートすることができます。これは、文書データを同行し、このような命令間の競合を処理する方法を文書データや外部ジョブ命令内に埋め込まれたジョブの指示の役割について行われたレガシーの決定および仮定によるものです。与えられた実装がどのように動作するかに関する正確な100％であることができないことは、2つの特別な属性、「IPP属性忠実度」と「PDL-オーバーライド・サポート」は、ジョブ全体ではなく特定には適用されているという事実によって悪化します各属性の値。例えば、いくつかの実装では、ほぼすべてのジョブテンプレートは「数アップ」以外の属性を上書きすることができるかもしれません。
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.
このセクションでは、最初の操作（印刷ジョブ）に一度、すべてのステータスコードを示します。それは、各操作の下でその後の操作のために異なるまたは特殊であるステータスコードを示します。
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 14 for a more complete description of each status code.
Printerオブジェクトは、示された理由については、以下の「ステータスコード」の値のいずれかを返さなければなりません。文書データの全てが成功またはエラーレスポンスを返す前に受け入れされているかどうかは、実装に依存します。各ステータスコードのより完全な説明については、セクション14を参照してください。
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. 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 syntaxes, or values MUST be returned in the Unsupported Attributes group of the response. 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：何の要求属性は置換しないか無視されました。成功-OK-置換無視-または-属性：一部が供給（1）属性は無視されたか（2）サポートされていない属性構文か値がサポートされる値で置換されていたか、無視されました。サポートされていない属性は、属性構文、または値は、応答のサポートされていない属性グループに返さなければなりません。成功-OK-競合-属性：その他の付属属性の値と競合し、いずれかの置換または無視されたいくつかの供給の属性値。クライアントによって供給される応答のサポートされていない属性グループに返さなければならない他の属性と競合し、置換または無視されている属性または値。
[RFC2566] section 3.1.6 Operation Status Codes and Messages states:
[RFC2566]セクション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 14): '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.
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'. 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. client-error-request-value-too-long: the size of request variable length attribute values, such as 'text' and 'name' attribute syntaxes, exceed the maximum length specified in [RFC2566] for the attribute and MUST be returned in the Unsupported Attributes Group. client-error-document-format-not-supported: the document format 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'. client-error-attributes-or-values-not-supported: one or more supplied attributes, attribute syntaxes, 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. client-error-uri-scheme-not-supported: not applicable. 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.
クライアント・エラー禁制：要求が承認または認証の理由で拒否されています。実装のセキュリティポリシーは、障害が認証または認可の一つであるかどうかを明らかにしないことです。クライアント・エラー・認証されません：要求が供給されるように、認証情報を要求するか、認証情報は、認可のためには十分ではないのどちらか。クライアント誤り - 権限がありません：要求者は、ターゲットオブジェクトに要求を実行するために許可されていません。クライアント誤り-ことができません：要求が原因でシステムの状態を行うことができません。また、Printerオブジェクトの「プリンタ受容-仕事」属性が「偽」である場合には優先しなければならない「サーバー・エラー・-受け入れていない - のジョブのステータスコードを参照してください。クライアント・エラータイムアウト：適用されません。クライアント・エラー - 見つかりません：ターゲット・オブジェクトが存在しません。クライアント誤りなくなっ：ターゲットオブジェクトがもはや存在しないと何のフォワーディングアドレスが知られていません。クライアント誤り要求エンティティ大きすぎる：要求および/または印刷データのサイズがそれを処理するIPPプリンタの容量を超えています。クライアントエラー要求値があまりに長く：要求可変長属性値の大きさ、そのような「テキスト」と「名前」としては、構文は、属性の[RFC2566]で指定された最大長を超えて返さなければならない属性サポートされていないグループ属性。クライアント・エラーは、文書フォーマットは-サポートされていない：付属ドキュメントフォーマットがサポートされていません。サポートされていない値を持つ「ドキュメント・フォーマット」属性がサポートされていないグループの属性に返さなければなりません。このエラーは、「クライアント・エラー・文字セット-サポートされていない」を除いて、他の「XXX-サポートされていません」というエラーに優先を取る必要があります。クライアント誤り属性-または値-サポートされていません：1以上の付属属性、属性構文、または値がサポートされており、クライアントが「真」値と「IPP-属性忠実度」操作属性を供給されていません。以下に説明するように彼らは、サポートされていない属性グループに返さなければなりません。クライアント・エラー-URI-スキーム-サポートされていません：適用されません。 - 文字セットが-サポートされていないクライアントエラー：「属性-のcharset」操作属性で供給されるcharsetがサポートされていません。プリンタの「構成された-charsetが」「属性、文字セット」操作属性の値として応答で返され、エラー応答で返された属性任意の「テキスト」と「名前」を使用しなければなりません。要求の構文は、クライアントの供給「属性 - 文字セット」は決定できないほど悪くない限り、このエラーは、他のエラーに優先を取る必要があります。
client-error-conflicting-attributes: one or more supplied attribute va 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. 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. 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'. 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.
クライアント・エラー・競合・属性：一つ以上の付属の属性Vaは互いに矛盾属性値とクライアントが「真」の値と「IPP-属性忠実度」操作属性を供給しました。以下に説明するように彼らは、サポートされていない属性グループに返さなければなりません。サーバーエラー内部エラー：予期しない条件が満たされてからの要求を防ぎます。サーバー・エラー・操作 - サポートされていません：適用されません（印刷ジョブが必要とされるため）。サーバー・エラー・サービス使用できない：サービスが一時的に過負荷になっています。サーバー・エラー・バージョン - サポートされていません：リクエスト内のバージョンがサポートされていません。サポート「最も近い」バージョン番号が応答で返さなければなりません。サーバー・エラー・デバイス・エラー：受信または一度に一つの仕事を受け入れることができ、要求や文書データやIPP Printerオブジェクトをスプールしながら、デバイスエラーが発生しました。サーバーエラー一時的エラー：要求及び/又は文書データを受信しながら、そのようなバッファフル書き込みエラー、メモリのオーバーフロー、またはディスク満杯状態として一時的なエラーが発生しました。サーバー・エラーが-受け入れていない - 仕事を：Printerオブジェクトの「プリンタ - - - 受け付けていません - ジョブ」属性が「偽」です。サーバー・エラー・ビジー：プリンタはこの時点で別の仕事を受け入れるために、あまりにも忙しい処理ジョブです。サーバー・エラー・ジョブキャンセル：クライアントは、文書データを送信している間にジョブがオペレータまたはシステムによって取り消されました。
All of the Print-Job status codes described in Section 3.2.1.2 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.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門と違いが-URIを印刷するために適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
server-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.
サーバー・エラー-URI-スキーム-サポートされていません：「文書-URI」操作属性で供給されたURIスキームがサポートされていないため、サポートされない属性グループに返されます。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Validate-Job. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが検証・ジョブに適用されます。各ステータスコードのより完全な説明については、セクション14を参照してください。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Create-Job with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブの作成に適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
server-error-operation-not-supported: the Create-Job operation is not supported.
サーバー・エラー・操作 - サポートされていません：作成 - ジョブ操作がサポートされていません。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いとは、Get-プリンタ・属性操作にも適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードについては、要求された属性は応答して、グループ3に返されます。
successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported. successful-ok-ignored-or-substituted-attributes: same as Print-Job, except the "requested-attributes" operation attribute MAY, but NEED NOT, be returned with the unsupported values. successful-ok-conflicting-attributes: same as Print-Job.
成功 - OK：何の要求属性は置換しないか無視（印刷ジョブと同じ）と全く要求された属性は、サポートされていないではなかったました。成功-OK-無視-または置換 - 属性：印刷ジョブと同じ、「要求され、属性」操作属性MAY除いては、しかし、サポートされていない値で返される必要はありません。成功-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 MUST be ignored and ' successful-ok-ignored-or-substituted-attributes' returned. client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved. server-error-operation-not-supported: not applicable (since Get-Printer-Attributes is REQUIRED). 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.
クライアント誤り-ことができません：印刷ジョブと同じ、加えて、Printerオブジェクトは、すべてのリクエストを受け付けていません。クライアント誤り要求エンティティ大きすぎる：なし印刷データが含まれないことを除いて、印刷ジョブと同じ。クライアント誤り属性-または値-サポートされていません：適用できない、サポートされていない操作属性は無視されなければならないと「成功-OK-無視-または置換 - 属性は」返さ以来。クライアント誤り矛盾-属性：印刷ジョブと同じ、「IPP属性忠実度は」関与していないことを除いて。サーバー・エラー・操作 - サポートされていません：適用されません（GET-プリンタ-属性以降が必要です）。サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、何の文書データが含まれないことを除いて。サーバーエラー一時的なエラー：なし文書データが含まれないことを除いて、印刷ジョブと同じ。サーバー・エラー・-ジョブを受け入れない：適用されません。
server-error-busy: same as Print-Job, except the IPP object is too busy to accept even query requests. server-error-job-canceled: not applicable.
サーバー・エラー・ビジー：印刷ジョブと同じ、IPPオブジェクトを除いても、クエリ要求を受け入れることができないくらい忙しいです。サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Jobs operation with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いとは、Get-ジョブの操作に適用されます。各ステータスコードのより完全な説明については、セクション14を参照してください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードについては、要求された属性は応答して、グループ3に返されます。
successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported. successful-ok-ignored-or-substituted-attributes: same as Print-Job, except the "requested-attributes" operation attribute MAY, but NEED NOT, be returned with the unsupported values. successful-ok-conflicting-attributes: same as Print-Job.
成功 - OK：何の要求属性は置換しないか無視（印刷ジョブと同じ）と全く要求された属性は、サポートされていないではなかったました。成功-OK-無視-または置換 - 属性：印刷ジョブと同じ、「要求され、属性」操作属性MAY除いては、しかし、サポートされていない値で返される必要はありません。成功-OK-競合-属性：印刷ジョブと同じ。
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 MUST be ignored and ' successful-ok-ignored-or-substituted-attributes' returned. client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved. server-error-operation-not-supported: not applicable (since Get-Jobs is REQUIRED). 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.
クライアント誤り-ことができません：印刷ジョブと同じ、加えて、Printerオブジェクトは、すべてのリクエストを受け付けていません。クライアント誤り要求エンティティ大きすぎる：なし印刷データが含まれないことを除いて、印刷ジョブと同じ。クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。クライアント誤り属性-または値-サポートされていません：適用できない、サポートされていない操作属性は無視されなければならないと「成功-OK-無視-または置換 - 属性は」返さ以来。クライアント誤り矛盾-属性：印刷ジョブと同じ、「IPP属性忠実度は」関与していないことを除いて。サーバー・エラー・操作 - サポートされていません：（GET-ジョブズが必要であるため）は適用されません。サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、何の文書データが含まれないことを除いて。サーバーエラー一時的なエラー：なし文書データが含まれないことを除いて、印刷ジョブと同じ。サーバー・エラー・-ジョブを受け入れない：適用されません。サーバー・エラー・ジョブキャンセル：適用されません。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いとは、Get-プリンタ・属性操作にも適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
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. successful-ok-conflicting-attributes: same as Print-Job.
成功 - OK：何の要求属性が（印刷ジョブと同じ）置換したり、無視されました。成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。成功-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 multi-document job 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. 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. 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.
クライアント誤り-ことができません：印刷ジョブと同様に、この属性は持っていた後、クライアントがマルチドキュメントジョブを送信終えることができているように、プリンタの「プリンタである受容-ジョブ」ことを除い属性は、関与していません「真」に設定されて。もう一つの条件は、ジョブの状態は、すなわち、ジョブはすでにクライアントによって閉鎖されている、送信-文書を排除するということです。 IPPプリンタがタイムアウトにジョブを手仕舞う場合は、「クライアント・エラータイムアウト」エラー状態が代わりに返されるべきです。クライアント・エラータイムアウト：プリンタがジョブを閉じた後に、それはプリンタの「複数の操作タイムアウト」期間内に送信-ドキュメント受信または送信-URI操作していないため、この要求は、送られました。クライアント誤り要求エンティティ大きすぎる：印刷ジョブと同じ。クライアント誤り矛盾-属性：印刷ジョブと同じ、「IPP-属性忠実度」操作属性が関与していないことを除いて。サーバー・エラー・操作 - サポートされていません：センド・資料請求はサポートされていません。サーバー・エラー・-ジョブを受け入れない：適用されません。サーバー・エラー・ジョブキャンセル：クライアントがデータを送信している間にジョブがオペレータまたはシステムによって取り消されました。
All of the Print-Job status code descriptions in Section 3.2.1.2 Print-Job Response with the specializations described for Send-Document are applicable to Send-URI. See Section 14 for a more complete description of each status code.
以下のために説明した専門分野を持つセクション3.2.1.2印刷ジョブ応答した印刷ジョブのステータス・コードの説明のすべての送信は、ドキュメント-URIを送信するために適用されます。各ステータスコードのより完全な説明については、セクション14を参照してください。
server-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.
サーバー・エラー-URI-スキーム-サポートされていません：「文書-URI」操作属性で供給されたURIスキームがサポートされていないと、「文書-URI」属性がサポートされていない属性グループに返さなければなりません。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Cancel-Job with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブをキャンセルするために適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
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. successful-ok-conflicting-attributes: same as Print-Job.
成功 - OK：何の要求属性が（印刷ジョブと同じ）置換したり、無視されました。成功-OK-無視-または置換 - 属性：印刷ジョブと同じ。成功-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.2.1.2 Print-Job Response are applicable to Get-Job-Attributes with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.2.1.2印刷ジョブ応答で記述された印刷ジョブステータスコードのすべてが以下の専門との違いで、ジョブ・属性の取得に適用可能です。各ステータスコードのより完全な説明については、セクション14を参照してください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードについては、要求された属性は応答して、グループ3に返されます。
successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported. successful-ok-ignored-or-substituted-attributes: same as Print-Job, except the "requested-attributes" operation attribute MAY, but NEED NOT, be returned with the unsupported values. successful-ok-conflicting-attributes: same as Print-Job.
成功 - OK：何の要求属性は置換しないか無視（印刷ジョブと同じ）と全く要求された属性は、サポートされていないではなかったました。成功-OK-無視-または置換 - 属性：印刷ジョブと同じ、「要求され、属性」操作属性MAY除いては、しかし、サポートされていない値で返される必要はありません。成功-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-document-format-not-supported: not applicable. client-error-attributes-or-values-not-supported: not applicable. client-error-uri-scheme-not-supported: not applicable. client-error-conflicting-attributes: not applicable server-error-operation-not-supported: not applicable (since Get-Job-Attributes is 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.
クライアント誤り-ことができません：印刷ジョブと同じ、加えて、Printerオブジェクトは、すべてのリクエストを受け付けていません。クライアント・エラー・ドキュメント・フォーマット・サポートされていません：適用されません。クライアント誤り属性-または値-サポートされていません：適用されません。クライアント・エラー-URI-スキーム-サポートされていません：適用されません。クライアント誤り矛盾 - 属性：サーバー・エラー・操作 - サポートされていません適用されません：適用されません（GET-仕事-属性以降が必要です）。サーバー・エラー・デバイス・エラー：印刷ジョブと同じ、ない文書データを除いては、関与しています。サーバーエラー一時的なエラー：なし文書データが含まれないを除いて、印刷ジョブとして正気。サーバー・エラー・-ジョブを受け入れない：適用されません。サーバー・エラー・ジョブキャンセル：適用されません。
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プリンターで受け入れされるかどうか、長い文書を送信する前に判断できるように、すべての準拠実装でその存在を頼りにできるようにするために有用です。
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 [RFC2068]. See these specifications for rules of matching, comparison, and case-sensitivity.
IPPの実装は、RFC 2396及びHTTP / 1.1仕様としてURIを定義する規格に適合既製部品を使用することができるように、IPP仕様はURIの上の任意の制限を行わないことが理由であり、[RFC2068] 。マッチング、比較、および大文字小文字の区別の規則のために、これらの仕様を参照してください。
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を持っていません。
The HTTP/1.1 specification [RFC2068] contains more details on comparing URLs.
HTTP / 1.1仕様書[RFC2068]はURLの比較の詳細が含まれています。
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
IPPクライアントとIPPオブジェクトはUTF-8をサポートする必要があります。彼らは追加の文字セットをサポートするかもしれません。 IPPオブジェクトはまた、多くのクライアントがUS-ASCIIをサポートし、UTF-8およびUS-ASCIIが移入によってサポートされていることを示しているので、US-ASCIIをサポートすることが推奨されます
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.
プリンタの "文字セットでサポートされている" '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 RFC2566 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?
そのリクエストで指定された文字セットであるため、RFC2566文書（セクション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で表現されていないため、疑問符の文字列を提供することを意味しても、それはsupports--ことを設定します。それは、このような変換を実行できない場合は、その「属性 - 文字セット・サポート」の値として、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オブジェクトのコード変換に依存するよりも、それは理解していない文字を捨てるために、クライアントのために賢くなります。
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, [RFC2566] section 14.1.4.14 client-error-charset-not-supported (0x040D) was clarified in November 1998 as follows:
次のようにまた、[RFC2566]セクション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 'textWithoutLanguage' 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」と「textWithoutLanguageは」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. 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フォームを送信したり、属性の自然言語は、要求または応答と同じであるときWithoutLanguageフォームを使用するかどうか、があります。前者のアプローチは、送信側の実装が簡単になります。後者のアプローチは、ワイヤ上で、より効率的であり、可能インターワーキング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 response's "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 [RFC2566] 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 WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute.
[RFC2566]の初期の草案は、Get-ジョブ応答のためのジョブレベル自然言語オーバーライド（NLO）を含有していました。ジョブレベル（NLO）は、その後、他のWithoutLanguageジョブ属性の暗黙の自然言語は、そのジョブの応答で返さ指定された（非要求）ジョブ属性です。初期の実装の相互運用性テストは、誰もがGET-ジョブ応答のジョブレベルNLOを実施しなかったことを示しました。だから、ジョブレベルNLOはGET-ジョブズ応答から排除されました。この単純化は、任意のWithoutLanguage「テキスト」か「名前」形式のための暗黙の自然言語は常にリクエストのか、レスポンスの「属性自然言語」操作属性で供給されているという点で一貫性のあるすべての要求と応答を行います。
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は妥協だったそれを作る、完成されていました。
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.
「キューに入れられたジョブ・カウントは」仕事が開催されている場合、プリンタがどれくらい忙しいの良い指標ではありません。経験は、そのような属性（組み合わせ）がすぐにプリンタが実際にどの程度ビジーであるかを示すために必要とされていることを示している場合には、将来の登録「を開催ジョブカウント」（または「アクティブ・ジョブ数」）プリンタ記述属性を追加することができ。
The [RFC2566] and [RFC2565] 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.
[RFC2566]と[RFC2565]の仕様は、送信者が要求または応答して、空の属性グループを送信しないことをお勧めします。しかし、彼らはそのグループの省略と同等に空の属性グループを受け入れるように受信機を必要としています。だから、クライアントは、ジョブテンプレートは、任意のジョブテンプレート属性を供給していない作成操作で完全にグループ属性を省略すべきです。応答で返さすべきサポートされない属性が存在しない場合同様、IPPオブジェクトがサポートされていない空の属性グループを省略すべきです。
The [RFC2565] 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.
[RFC2565]仕様は、空の属性グループまたは省略属性グループのいずれかを受け取ると同等に扱うことができるように受信機を必要とします。用語「受信機」は、応答を要求し、クライアントのためのIPPオブジェクトを意味します。用語「送信者は、」応答の要求とIPPオブジェクトのためのクライアントを意味します。
There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2565] contains the following paragraph:
返される属性がないときには、Get-ジョブズのための規則には例外があります。 [RFC2565]は、次の段落が含まれています。
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-属性タグを送信しないことをお勧めしますが、受信機は、このような構文をデコードできなければなりません。
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-無視-または置換 - 属性のステータスコードを返すことが必要です。
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 job's "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.
これらの選択肢の全ては、サーバとデバイスの実装に依存します。
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.
論文アウトまたは完全ジャムやスプールスペース全体またはバッファ空間に停止する一時停止プリンタ（または、クライアントがないように、）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プリンタをテストするためのテストスクリプトを書くには、スクリプトは、すべての可能な実装を使用するために、、、応答を期待しないように書かなければなりません。
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の同属性のその後の値の指標としてゼロ長属性キーワードを持っています。
2.13 Querying jobs with IPP that were submitted using other job submission protocols
他のジョブ送信プロトコルを使用して提出されたIPPと2.13照会仕事
The following clarification was added to [RFC2566] section 8.5:
以下の清澄は、[RFC2566]セクション8.5に加えました。
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に加えて、他のジョブ送信プロトコルを使用してジョブを受け入れることができるならば、そのような実装は、少なくとも、このような「外来」のジョブが取得・ジョブ「job-を返す使用して照会できるようにすることをお勧めしますです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 is 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-ジョブ・属性を使用して、エンドユーザ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は、広く実装されるにつれて、より普遍的なアクセスを提供することは理にかなっています。
[RFC2566] 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.
[RFC2566]は集合が空である場合に「なし」値が1SetOfの値として使用されるべきであると述べています。ほとんどの場合、キーワード「なにも」が使用されていないので、潜在的に空になっているセットは、キーワードが含まれていますが、3つの仕上げ属性のため、値が列挙型であり、したがって、空のセットが列挙型3で表され、現在のところ、他の属性とが存在しません空にすることができ、キーワードではない値を含めることができ1SetOf値。この例外は、特別なコードを必要とし、バグの可能性の場所です。我々はこのような「なし」として、「無価値」またはいくつかの新しい値のいずれか、アウトオブバンド値を選択しなかった場合、それはもっと良かったはず。私たちはしなかったので、実装は、属性構文によっては、「なし」の異なる表現に対処する必要があります。
In [RFC2566] 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 to, and if it's not present what should the IPP printer do?
[RFC2566]セクション3.2.6.1「ゲット・ジョブズを要求」で、属性「私-仕事」は、現在およびTrueに設定されている「要求するユーザー名」属性がに存在しなければなりません、そしてそれが何を提示していない場合場合IPPプリンタはいいですか？
[RFC2566] 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".
[RFC2566]セクション8.3「要求ユーザ名」は、任意の動作のために存在するかしないという様々なケースが記載されています。クライアントは、「要求ユーザー名」の値を指定しない場合、プリンタは、クライアントが、そのような「匿名」として、いくつかの匿名の名前を供給していると仮定しなければなりません。
2.16 The "multiple-document-handling" Job Template attribute and support of multiple document jobs
2.16「マルチドキュメントハンドリング」複数のドキュメントのジョブのジョブテンプレート属性とサポート
ISSUE: 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".
ISSUE：IPP / 1.0は、それが作成し、ジョブをサポートしている場合、実装は、実行することになり4つの効果のどちらが沈黙しているが、「マルチドキュメント・ハンドリング」をサポートしていません。
A fix to IPP/1.0 would be to require implementing all four values of "multiple-document-handling" if Create-Job is supported at all. Or at least 'single-document-new-sheet' and 'separate-documents-uncollated-copies'. In any case, an implementation that supports Create-Job SHOULD also support "multiple-document-handling". Support for all four values is RECOMMENDED, but at least the 'single-document-new-sheet' and 'separate-documents-uncollated-copies' values, along with the "multiple-document-handling-default" indicating the default behavior and "multiple-document-handling-supported" values. If an implementation spools the data, it should also support the 'separate-documents-collated-copies' value as well.
IPP / 1.0への修正は、「マルチドキュメントハンドリング」を作成し、仕事をまったくサポートされている場合の4つの値すべてを実装する必要がすることです。あるいは、少なくとも「シングルドキュメント新しいシート」と「セパレート文書-非照合-コピー」。いずれの場合も、作成-仕事をサポートする実装はまた、「マルチドキュメントハンドリング」をサポートすべきです。すべての4つの値のサポートが推奨されますが、デフォルトの動作を示す「マルチドキュメント・ハンドリング・デフォルト」と一緒に「シングルドキュメント新しいシート」と 'セパレート文書-非照合-コピーの価値観、少なくとも、および「マルチドキュメント・ハンドリング・サポート」の値。実装はデータをスプールした場合、それはまた、同様に「セパレート文書-照合-コピー」の値をサポートする必要があります。
3 Encoding and Transport
3エンコーディングおよび交通
This section discusses various aspects of IPP/1.0 Encoding and Transport [RFC2565].
このセクションでは、IPP / 1.0コード化と輸送[RFC2565]のさまざまな側面について説明します。
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.
サーバーは、それがclient.s全体の要求を受信した後まで応答を送信するために必要とされていません。したがって、クライアントは、それが全体の要求を送信した後まで応答を期待してはいけません。しかし、私たちは、クライアントがデータを送信するのではなく、すべてのデータを受信するまで待機している間にエラーが検出された場合、サーバはできるだけ早く応答を返すことをお勧めします。したがって、我々はまた、クライアントは、それはすべてのデータを受信する前にIPPサーバが送信する可能性のあること、エラー応答を聞くことをお勧めします。この場合、クライアントでは、データをチャンク場合、すべてのデータを送信する前に、要求を終了するには時期尚早長さゼロのチャンクを送信することができます（そのため、クライアントは、他の要求のためのオープンではなく、それを閉じ、接続を維持することができます）。要求が何らかの理由でブロックされている場合、クライアントは、Get-プリンタ-属性を使用してサーバーを照会するための別の接続を開くことによって、その理由を決定することができます。
In the following sections, there are a 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.
- .header。カラムヘッダの名前を含んでいます。 - .request /クライアント。カラムは、クライアントがヘッダを送信するかどうかを示しています。 - .request /サーバー。カラムは、受信された場合、サーバは、ヘッダをサポートしているかどうかを示します。 - .response /サーバー。カラムは、サーバは、ヘッダを送信するかどうかを示しています。 - .response /クライアント。カラムは、受信された場合、クライアントは、ヘッダをサポートしているかどうかを示します。 - .valuesと条件。カラムヘッダの許容ヘッダ値及び条件は、要求/応答中に存在することを指定します。
The table for .request headers. does not have columns for responses, and the table for .response headers. does not have columns for requests.
.requestヘッダーのテーブル。応答のための列、および.responseヘッダーのテーブルを持っていません。要求のための列を持っていません。
The following is an explanation of the values in the .request/client. and .response/ server. columns.
以下は.request /クライアントの値の説明です。そして.response /サーバー。列。
- 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,
- 必要がありますクライアントまたはサーバは、ヘッダを送信しなければならない、 - -場合なければならない：クライアントまたはサーバは、ヘッダを送信する必要がある場合.values及び条件に記述された条件。列が満たされ、
- 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.
以下は.response /クライアントの値の説明です。そして.request /サーバー。列。
- 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- must not must not .no-cache. only Control
Cache-は.NO-キャッシュをしてはならないしてはなりません。唯一のコントロール
Connection must-if must must- must .close. only. Both 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-は.closeしなければならない必要があります。のみ。クライアントとサーバの両方が一連の操作の間、接続を維持する必要がある場合。クライアントとサーバは、シーケンス内の最後の操作のために、このヘッダを含まなければなりません。
Date may may must may per RFC 1123 [RFC1123] from RFC 2068 [RFC2068]
日付かもしれなければならないかもしれないRFC 2068 [RFC2068]からのRFC 1123 [RFC1123]あたり
Pragma must not must not .no-cache. only
プラグマは.NO-キャッシュをしてはならないしてはなりません。のみ
Transfer- must-if must must- must .chunked. only . Encoding if Header MUST be present if Content-Length is absent.
Transfer-は-場合は、必要がありますmust-は.chunkedしなければならない必要があります。のみ。エンコーディングのContent-Lengthが存在しない場合のヘッダが存在しなければならない場合。
Upgrade not not not not
アップグレードではないではないではないではありません
Via not not not not
経由していないではないではないではありません
The following is a table for the request headers.
次は、リクエストヘッダのためのテーブルです。
Request-Header Client Server Request Values and Conditions
リクエストヘッダクライアントサーバー要求値と条件
Accept may must .application/ipp. only. This value is the default if the
/ IPPを.applicationのしなければならないことが受け入れます。のみ。この値があれば、デフォルトで
Request-Header Client Server Request Values and Conditions
リクエストヘッダクライアントサーバー要求値と条件
client omits it
クライアントはそれを省略します
Accept-Charset not not Charset information is within the application/ipp entity
受け入れ-文字セットを情報をCHARSETないいないアプリケーション/ IPPエンティティ内にあります
Accept-Encoding may must empty and per RFC 2068 [RFC2068] and IANA registry for content-codings
受け入れ-エンコーディングは空にしなければならないかもしれ内容コーディングのためのRFC 2068 [RFC2068]とIANAレジストリあたり
Accept-Language not not language information is within the application/ipp entity
言語情報は、アプリケーション/ IPP実体の中で受け入れ言語ではないではありません
Authorization must-if must per RFC 2068. A client MUST send this header when it receives a 401 .Unauthorized. response and does not receive a .Proxy-Authenticate. header.
承認は必要-場合、それは401 .Unauthorizedを受信したときにRFC 2068あたりの必要のあるクライアントは、このヘッダを送らなければなりません。応答と.Proxy-認証を受けていません。ヘッダ。
From not not per RFC 2068. Because RFC recommends sending this header only with the user.s approval, it is not very useful
いないいないRFC 2068 RFCのみuser.s承認を得て、このヘッダを送信することをお勧めしますのでごとに、それは非常に有用ではありませんから、
Host must must per RFC 2068
RFC 2068あたり必見必見ホスト
If-Match not not
もし、一致していません
If-Modified- not not Since
Modified--ない場合ではないので、
If-None-Match not not
もし-なし - 一致していません
If-Range not not
もしレンジではないではありません
If-Unmodified- not not Since
もし-Unmodified-ないではないので、
Max-Forwards not not
マックス・転送しないではありません
Proxy- must-if not per RFC 2068. A client MUST send Authorization this header when it receives a 401 .Unauthorized. response and a .Proxy-Authenticate. header.
それは401 .Unauthorizedを受信したときProxy-は、必要がある場合ではないRFC 2068ごとにクライアントが認証にこのヘッダを送らなければなりません。応答と.Proxy-認証します。ヘッダ。
Range not not
ないない範囲
Referer 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-if may per RFC 2068. When URI needs redirection.
場所必要があり、もしRFC 2068 URIがリダイレクトを必要とするあたり5月。
Proxy- not must per RFC 2068 Authenticate
Proxy- RFCあたり2068認証しなければなりません
Public may may per RFC 2068
公共月RFC 2068あたりのかもしれません
Retry-After may may per RFC 2068
リトライ後5月には、RFC 2068あたりのかもしれません
Server not not
サーバーではないではありません
Vary not not
変化していません
Warning may may per RFC 2068
警告は、RFC 2068あたりかもしれないこと
WWW- must-if must per RFC 2068. When a server needs to Authenticate authenticate a client.
WWW-を行う必要があり-IF RFC 2068あたり必見サーバがクライアントを認証認証する必要がある場合。
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 2068 and IANA Encoding registry for content codings.
たContent月なければならなければならない必要があり、コンテンツのコーディングのためのRFC 2068およびIANAエンコーディングレジストリあたり。
Content- not not not not Application/ipp Language handles language
たContentはないないないないアプリケーション/ IPP言語は、言語を処理します
Content- must-if must must-if must the length of the Length message-body per RFC 2068. Header MUST be present if Transfer-
たContentは、必要がある場合は必須では、もし必要がありRFC 2068あたりの長さのメッセージボディの長さは、ヘッダTransfer-もし存在しなければならない必要があります
Entity-Header Request Response Values and Conditions
エンティティヘッダリクエストの応答値と条件
Client Server Server Client
クライアントサーバーサーバークライアント
Encoding is absent.
エンコーディングは存在しません。
Content- not not not not Location
たContentないないないない場所
Content-MD5 may may may may per RFC 2068
Content-MD5場合もありかもしれRFC 2068あたり
Content-Range not not not not
コンテンツレンジではないではないではないではありません
Content-Type must must must must .application/ipp. only
Content-Type必見/ IPPを.applicationの必要がありますしなければならない必要があります。のみ
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 [RFC2565] 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ドキュメント[RFC2565]は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 .unsupportedバージョン番号で応答します。 HTTP 1.1要求に、クライアントは、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 [HTTP] 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.
HTTP / 1.1規格[HTTP]は準拠したサーバは、任意の方法のためにチャンク要求をサポートすることが必要です。しかし、この要件にもかかわらず、いくつかのHTTP / 1.1の実装のサポートは、GETメソッドで応答をチャンクが、チャンクPOSTメソッドの要求をサポートしていません。
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 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.
CGIスクリプト[CGI]および/またはサーブレット[サーブレット]をサポートするいくつかのHTTP / 1.1の実装は、クライアントがコンテンツ長を供給する必要があります。これらの実装は、チャンクPOSTメソッドを拒否し、411ステータスコード（長さ必須）を返し、要求をバッファリングし、413のステータスコード（リクエスト・エンティティが大きすぎます）を返す部屋の外に実行しようとするかもしれない、または成功したチャンク要求を受け入れる場合があります。
Because of this lack of conformance of HTTP servers to the HTTP/1.1 standard, the IPP standard [RFC2565] 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標準[RFC2565]は準拠したIPP Printerオブジェクトの実装のサポートが要求をチャンクすることを必要とし、準拠クライアントはチャンクの応答を受け入れること。したがって、IPPオブジェクトの実装は、IPP規格に準拠および/またはチャンクPOSTリクエストをサポートする実装テクニックを使用するために、チャンクPOSTリクエストをサポートするHTTPサーバの実装を求めて警告しています。
4 References
4つの参考文献
[CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface Version 1.1 (CGI/1.1)", Work in Progress.
[CGI] COAR、K.、およびD.ロビンソン、 "WWWのCommon Gateway Interfaceバージョン1.1（CGI / 1.1）" が進行中で働いています。
[HTTP] 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.
[HTTP]フィールディング、R.、ゲティス、J、モーグル、J.、Frystyk ,, H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569]エリオ、R.、ヘイスティングス、T.、ジェイコブズ、N.とJ.マーチン、 "LPDとIPPプロトコルとの間のマッピング"、RFC 2569、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] deBry、R.、ヘイスティングズ、T.、エリオ、R.、Isaacson氏、S.とP.パウエル、 "インターネット印刷プロトコル/ 1.0：モデルと意味論"、RFC 2566、1999年4月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565]エリオ、R.、バトラー、S.、ムーア、P.とR.チューナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、RFC 2565、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S.、「インターネット印刷プロトコルのための構造とモデルとプロトコルのための理論的根拠」、RFC 2568、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567]ライト、D.、 "インターネット印刷プロトコルの設計目標"、RFC 2567、1999年4月。
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、S.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、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月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[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月。
[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）。
[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 Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
カール・ワンManreゼロックス社701航空ブルバードエル・セグンド、CA 90245
EMail: manros@cp10.es.xerox.com
メールアドレス：manros@cp10.es.xerox.com
5 Security Considerations
5セキュリティに関する考慮事項
Security issues are discussed in sections 2.2, 2.3.1, and 8.5.
セキュリティ問題はセクション2.2、2.3.1、および8.5で議論されています。
6 Notices
6つの注意事項
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 [BCP-11]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11 [BCP-11]に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。