[要約] RFC 3196は、インターネット印刷プロトコル（IPP）の実装者向けのガイドです。このRFCの目的は、IPP/1.1の実装に関する情報とガイダンスを提供することです。
Network Working Group T. Hastings
Request for Comments: 3196 C. Manros
Obsoletes: 2639 P. Zehler
Category: Informational Xerox Corporation
C. Kugler
IBM Printing Systems Co
H. Holst
i-data Printing Systems
November 2001
Internet Printing Protocol/1.1: Implementor's Guide
インターネット印刷プロトコル/1.1：実装者ガイド
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).
このドキュメントは一連のドキュメントの1つであり、新しいインターネット印刷プロトコル（IPP）のすべての側面を一緒に説明しています。
Table of Contents
目次
1 Introduction................................................... 4
1.1 Conformance language........................................ 5
1.2 Other terminology........................................... 6
1.3 Issues Raised from Interoperability Testing Events.......... 6
2 IPP Objects.................................................... 6
3 IPP Operations................................................. 7
3.1 Common Semantics............................................ 7
3.1.1 Summary of Operation Attributes............................ 8
3.1.2 Suggested Operation Processing Steps for IPP Objects....... 16
3.1.2.1 Suggested Operation Processing Steps for all Operations. 17
3.1.2.1.1 Validate version number............................... 18
3.1.2.1.2 Validate operation identifier......................... 20
3.1.2.1.3 Validate the request identifier....................... 20
3.1.2.1.4 Validate attribute group and attribute presence and
order................................................. 20
3.1.2.1.4.1 Validate the presence and order of attribute groups. 20
3.1.2.1.4.2 Ignore unknown attribute groups in the expected
position............................................ 21
3.1.2.1.4.3 Validate the presence of a single occurrence of
required Operation attributes....................... 21
3.1.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................ 29
3.1.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................ 33
3.1.2.2 Suggested Additional Processing Steps for Operations
that Create/Validate Jobs and Add Documents............. 37
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
3.1.2.2.3 Validate the values of the Job Template attributes.... 38
3.1.2.3 Algorithm for job validation............................ 39
3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
3.1.2.3.2 Decide whether to REJECT the request.................. 46
3.1.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes.................................. 48
3.1.2.3.4 Create the Job object with attributes to support...... 48
3.1.2.3.5 Return one of the success status codes................ 50
3.1.2.3.6 Accept appended Document Content...................... 50
3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
3.1.2.3.8 Completing the Job.................................... 50
3.1.2.3.9 Destroying the Job after completion................... 51
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
3.1.2.3.11 Character set code conversion support................. 51
3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?....... ....................... 52
3.1.2.3.13 Natural Language Override (NLO)....................... 53
3.1.3 Status codes returned by operation......................... 55
3.1.3.1 Printer Operations...................................... 55
3.1.3.1.1 Print-Job............................................. 55
3.1.3.1.2 Print-URI............................................. 58
3.1.3.1.3 Validate-Job.......................................... 58
3.1.3.1.4 Create-Job............................................ 58
3.1.3.1.5 Get-Printer-Attributes................................ 59
3.1.3.1.6 Get-Jobs.............................................. 60
3.1.3.1.7 Pause-Printer......................................... 61
3.1.3.1.8 Resume-Printer........................................ 62
3.1.3.1.8.1 What about Printers unable to change state due to
an error condition?................................. 63
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
3.1.3.1.9 Purge-Printer......................................... 63
3.1.3.2 Job Operations.......................................... 64
3.1.3.2.1 Send-Document......................................... 64
3.1.3.2.2 Send-URI.............................................. 65
3.1.3.2.3 Cancel-Job............................................ 65
3.1.3.2.4 Get-Job-Attributes.................................... 67
3.1.3.2.5 Hold-Job.............................................. 68
3.1.3.2.6 Release-Job........................................... 69
3.1.3.2.7 Restart-Job........................................... 69
3.1.3.2.7.1 Can documents be added to a restarted job?.......... 69
3.1.4 Returning unsupported attributes in Get-Xxxx responses
(Issue 1.18)............................................... 70
3.1.5 Sending empty attribute groups............................. 70
3.2 Printer Operations.......................................... 71
3.2.1 Print-Job operation........................................ 71
3.2.1.1 Flow controlling the data portion of a Print-Job
request (Issue 1.22).................................... 71
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
3.2.2 Get-Printer-Attributes operation........................... 72
3.2.3 Get-Jobs operation......................................... 72
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
(Issue 1.39)?.......................................... 72
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
operation?.............................................. 73
3.2.4 Create-Job operation....................................... 73
3.3 Job Operations.............................................. 74
3.3.1 Validate-Job............................................... 74
3.3.2 Restart-Job................................................ 74
4 Object Attributes.............................................. 74
4.1 Attribute Syntax's.......................................... 74
4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
4.2 Job Template Attributes..................................... 76
4.2.1 multiple-document-handling(type2 keyword).................. 76
4.2.1.1 Support of multiple document jobs....................... 76
4.3 Job Description Attributes.................................. 76
4.3.1 Getting the date and time of day........................... 76
4.4 Printer Description Attributes.............................. 77
4.4.1 queued-job-count (integer(0:MAX)).......................... 77
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
4.4.1.2 Is "queued-job-count" a good measure of how busy a
printer is (Issue 1.15)?................................ 77
4.4.2 printer-current-time (dateTime)............................ 78
4.4.3 Printer-uri................................................ 78
4.5 Empty Jobs.................................................. 79
5 Directory Considerations....................................... 79
5.1 General Directory Schema Considerations..................... 79
5.2 IPP Printer with a DNS name................................. 79
6 Security Considerations........................................ 80
6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32)........................... 80
7 Encoding and Transport......................................... 81
7.1 General Headers............................................. 83
7.2 Request Headers............................................ 84
7.3 Response Headers............................................ 86
7.4 Entity Headers............................................. 87
7.5 Optional support for HTTP/1.0............................... 88
7.6 HTTP/1.1 Chunking........................................... 88
7.6.1 Disabling IPP Server Response Chunking..................... 88
7.6.2 Warning About the Support of Chunked Requests.............. 88
8 References..................................................... 89
9 Authors' Addresses............................................. 91
10 Description of the Base IPP Documents.......................... 94
11 Full Copyright Statement....................................... 96
Tables
テーブル
Table 1 - Summary of Printer operation attributes that sender MUST
supply ................................................. 8
Table 2 - Summary of Printer operation attributes that sender MAY
supply ................................................. 10
Table 3 - Summary of Job operation attributes that sender MUST
supply.................................................. 12
Table 4 - Summary of Job operation attributes that sender MAY
supply.................................................. 14
Table 5 - Printer operation response attributes................... 16
Table 6 - Examples of validating IPP version...................... 19
Table 7 - Rules for validating single values X against Z.......... 40
IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. It is intended to help implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may assist them in the design of their client and/or IPP object implementation. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
IPPは、インターネットツールとテクノロジーを使用した分散印刷に使用できるアプリケーションレベルのプロトコルです。このドキュメントには、IPPモデルとセマンティクス[RFC2911]とIPP輸送およびエンコード[RFC2910]ドキュメントを補足する情報が含まれています。実装者がIPP/1.1、およびIPP/1.0 [RFC2565、RFC2566]、およびクライアントおよび/またはIPPオブジェクトの実装の設計に役立つ可能性のある考慮事項のいくつかを理解するのを支援することを目的としています。たとえば、エラーチェックを含む、処理リクエストの典型的な順序が与えられます。仕様決定のいくつかの動機も含まれています。
This document obsoletes RFC 2639 which was the Implementor's Guide for IPP/1.0. The IPP Implementor's Guide (IIG) (this document) contains information that supplements the IPP Model and Semantics [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. This document is just one of a suite of documents that fully define IPP. The base set of IPP documents includes:
このドキュメントは、IPP/1.0の実装ガイドであったRFC 2639を廃止しました。IPP実装ガイド（IIG）（このドキュメント）には、IPPモデルとセマンティクス[RFC2911]とIPP輸送およびエンコード[RFC2910]ドキュメントを補完する情報が含まれています。このドキュメントは、IPPを完全に定義する一連のドキュメントの1つにすぎません。IPPドキュメントのベースセットには以下が含まれます。
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementor's Guide (this
document)
Mapping between LPD and IPP Protocols [RFC2569]
See section 10 for a description of these base IPP documents. Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order.
これらのベースIPPドキュメントの説明については、セクション10を参照してください。これらのドキュメントを初めて読んでいる人は誰でも、上記の順序でIPPドキュメントを読むことを強くお勧めします。
As such the information in this document is not part of the formal specification of IPP/1.1. Instead information is presented to help implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565, RFC2566], including some of the motivation for decisions taken by the committee in developing the specification. Some of the implementation considerations are intended to help implementers design their client and/or IPP object implementations. If there are any contradictions between this document and [RFC2911] or [RFC2910], those documents take precedence over this document.
このように、このドキュメントの情報は、IPP/1.1の正式な仕様の一部ではありません。代わりに、実装者がIPP/1.1とIPP/1.0 [RFC2565、RFC2566]を理解するのに役立つ情報が提示されます。実装の考慮事項の一部は、実装者がクライアントおよび/またはIPPオブジェクトの実装を設計するのに役立つことを目的としています。このドキュメントと[RFC2911]または[RFC2910]の間に矛盾がある場合、これらのドキュメントはこのドキュメントよりも優先されます。
Platform-specific implementation considerations will be included in this guide as they become known.
プラットフォーム固有の実装に関する考慮事項は、このガイドが知られるようになるにつれて含まれます。
Note: In order to help the reader of the IIG and the IPP Model and Semantics document, the sections in this document parallel the corresponding sections in the Model document and are numbered the same for ease of cross reference. The sections that correspond to the IPP Transport and Encoding are correspondingly offset.
注：IIGおよびIPPモデルおよびセマンティクスドキュメントの読者を支援するために、このドキュメントのセクションは、モデルドキュメントの対応するセクションに並行しており、相互参照を容易にするために同じ番号が付けられています。IPPトランスポートとエンコードに対応するセクションは、それに応じてオフセットされています。
Usually, this document does not contain the terminology MUST, MUST NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, when those terms do appear in this document, their intent is to repeat what the [RFC2911] and [RFC2910] documents require and allow, rather than specifying additional conformance requirements. These terms are defined in section 12 on conformance terminology in [RFC2911], most of which is taken from RFC 2119 [RFC2119].
通常、このドキュメントには、用語が含まれていません。必要はありません。必要はありません。必要はありません。ただし、これらの用語がこのドキュメントに表示される場合、それらの意図は、追加の適合要件を指定するのではなく、[RFC2911]および[RFC2910]ドキュメントが必要とするものを繰り返すことです。これらの用語は、[RFC2911]の適合用語に関するセクション12で定義されており、そのほとんどはRFC 2119 [RFC2119]から取得されています。
Implementers should read section 12 (APPENDIX A) in [RFC2911] in order to understand these capitalized words. The words MUST, MUST NOT, and REQUIRED indicate what implementations are required to support in a client or IPP object in order to be conformant to [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed as an implementer option. The verbs SHOULD and SHOULD NOT indicate suggested behavior, but which is not required or disallowed, respectively, in order to conform to the specification.
実装者は、これらの大文字の単語を理解するために、[RFC2911]のセクション12（付録A）を読む必要があります。単語は、[RFC2911]および[RFC2910]に適合するために、クライアントまたはIPPオブジェクトでサポートするために必要な実装が必要である必要があり、そうでなければなりません。必要になる場合があり、オプションの示すことは、単に実装者オプションとして許可されています。動詞は、指定された動作を示すべきではありませんが、仕様に準拠するためにはそれぞれ必要または禁止されていません。
This document uses other terms, such as "attributes", "operation", and "Printer" as defined in [RFC2911] section 12. In addition, the term "sender" refers to the client that sends a request or an IPP object that returns a response. The term "receiver" refers to the IPP object that receives a request and to a client that receives a response.
このドキュメントでは、[RFC2911]セクション12で定義されている「属性」、「操作」、「プリンター」などの他の用語を使用します。さらに、「送信者」という用語は、リクエストまたはIPPオブジェクトを送信するクライアントを指します。応答を返します。「受信機」という用語は、リクエストを受信するIPPオブジェクトと応答を受信するクライアントを指します。
The IPP WG has conducted three open Interoperability Testing Events. The first one was held in September 1998, the second one was held in March 1999, and the third one was held in October 2000. See the summary reports in:
IPP WGは、3つのオープンな相互運用性テストイベントを実施しました。最初のものは1998年9月に開催され、2番目は1999年3月に開催され、3番目は2000年10月に開催されました。概要レポートを参照してください。
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
The issues raised from the first Interoperability Testing Event are numbered 1.n in this document and have been incorporated into "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and Transport" [RFC2565] documents. However, some of the discussion is left here in the Implementor's Guide to help understanding.
最初の相互運用性テストイベントから提起された問題には、このドキュメントで1.Nが番号が付けられており、「IPP/1.0モデルとセマンティクス」[RFC2566]および「IPP/1.0エンコードと輸送」[RFC2565]ドキュメントに組み込まれています。ただし、いくつかの議論は、理解を支援する実装者のガイドに記載されています。
The issues raised from the second Interoperability Testing Event are numbered 2.n in this document have been incorporated into "IPP/1.1 Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and Transport" [RFC2910] documents. However, some of the discussion is left here in the Implementor's Guide to help understanding.
2番目の相互運用性テストイベントから提起された問題は、2.Nの番号が付けられています。このドキュメントには、「IPP/1.1モデルとセマンティクス」[RFC2911]および「IPP/1.1エンコーディングと輸送」[RFC2910]ドキュメントに組み込まれています。ただし、いくつかの議論は、理解を支援する実装者のガイドに記載されています。
The issues raised from the third Interoperability Testing Event are numbered 3.n in this document and are described in:
3番目の相互運用性テストイベントから提起された問題は、このドキュメントで3.nの番号が付けられており、以下で説明されています。
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
The term "client" in IPP is intended to mean any client that issues IPP operation requests and accepts IPP operation responses, whether it be a desktop or a server. In other words, the term "client" does not just mean end-user clients, such as those associated with desktops.
IPPの「クライアント」という用語は、IPPの操作を発行するクライアントが、デスクトップであろうとサーバーであろうと、IPPの操作応答を要求および受け入れることを意味することを意図しています。言い換えれば、「クライアント」という用語は、デスクトップに関連するエンドユーザークライアントだけを意味するわけではありません。
The term "IPP Printer" in IPP is intended to mean an object that accepts IPP operation requests and returns IPP operation responses, whether implemented in a server or a device. An IPP Printer object MAY, if implemented in a server, turn around and forward received jobs (and other requests) to other devices and print servers/services, either using IPP or some other protocol.
IPPの「IPPプリンター」という用語は、サーバーまたはデバイスで実装されているかどうかにかかわらず、IPP操作要求を受け入れ、IPP操作応答を返すオブジェクトを意味することを目的としています。IPPプリンターオブジェクトは、サーバーに実装されている場合、IPPまたは他のプロトコルを使用して、他のデバイスや印刷サーバー/サービスに受け取ったジョブ（およびその他のリクエスト）をターンアラウンドして転送します。
3 IPP Operations
3 IPP操作
This section corresponds to Section 3 "IPP Operations" in the IPP/1.1 Model and Semantics document [RFC2911].
このセクションは、IPP/1.1モデルおよびセマンティクスドキュメント[RFC2911]のセクション3「IPP操作」に対応しています。
This section discusses semantics common to all operations.
このセクションでは、すべての操作に共通するセマンティクスについて説明します。
Table 1 - Summary of Printer operation attributes that sender MUST supply
表1-送信者が提供する必要があるプリンター操作属性の概要
Printer Operations
プリンター操作
Requests Responses Operation PJ, PU CJ GPA GJ PP, All Attributes VJ (O) (O) (R) (R) RP, Operations (R) PP (O+)
応答操作PJ、PU CJ GPA GJ PP、すべての属性VJ（O）（O）（R）（R）RP、操作（R）PP（O）
Operation parameters--REQUIRED to be supplied by the sender:
操作パラメーター - 送信者から提供されるようにリクエアされています。
operation-id R R R R R R
Operation-Id r r r r r r
status-code R
ステータスコードr
request-id R R R R R R R
Request-Id r r r r r r r
version-number R R R R R R R
バージョン番号r r r r r r r
Operation attributes--REQUIRED to be supplied by the sender:
操作属性 - 送信者から供給されるように要求されました。
attributes- R R R R R R R charset
属性 - R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R
attributes- R R R R R R R natural-language
属性 - r r r r r r r自然言語
document-uri R
document-uri r
job-id*
job-id*
job-uri*
job-uri*
Printer Operations
プリンター操作
Requests Responses
応答を要求します
Operation PJ, PU CJ GPA GJ PP, All Attributes VJ (O) (O) (R) (R) RP, Operations (R) PP (O+) last-document
操作PJ、PU CJ GPA GJ PP、すべての属性VJ（O）（O）（R）（R）RP、操作（R）PP（O）Last-Document
printer-uri R R R R R R
プリンター - ウリr r r r r r
Operation attributes--RECOMMENDED to be supplied by the sender:
操作属性 - 送信者から提供されるように推奨されます。
job-name R R R
ジョブネームr r r
requesting-user- R R R R R R name
リクエスト - ユーザー - r r r r r r名
Legend:
伝説：
PJ, VJ: Print-Job, Validate-Job PU: Print-URI CJ: Create-Job GPA: Get-Printer-Attributes GJ: Get-Jobs PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP.
PJ、VJ：Print-Job、Validate-Job PU：Print-URI CJ：Create-Job GPA：Get-Printer-Attributes GJ：Get-Jobs PP、RP、PP：Pause-Printer、Resume-Printer、Purge-PrinterRは、IPPオブジェクト（プリンターまたはジョブ）でサポートする必要がある必要な操作を示します。属性の場合、Rは、関連する操作をサポートするIPPオブジェクトによって属性がサポートされている必要があることを示します。o IPPオブジェクト（プリンターまたはジョブ）によってサポートされる可能性のあるオプションの操作または属性を示します。これはIPP/1.0機能ではなく、IPP/1.1およびIPPの将来のバージョンの一部にすぎないことを示します。
Table 2 - Summary of Printer operation attributes that sender MAY supply
表2-送信者が提供する可能性のあるプリンター操作の概要
Printer Operations
プリンター操作
Requests Respon-ses Operation Attributes PJ, PU CJ GPA GJ PP, All VJ (O) (O) (R) (R) RP, Opera (R) PP tions (O+)
リクエストRespon-SES Operation属性PJ、PU CJ GPA GJ PP、すべてのVJ（O）（O）（R）（R）RP、Opera（R）PPITIONS（O）
Operation attributes--OPTIONAL to be supplied by the sender:
操作属性 - 送信者によって提供されるようになります。
status-message O
ステータスメッセージo
detailed-status- O message
詳細なステータス-Oメッセージ
document-access- O** error
document-access- o **エラー
compression R R
圧縮r r
document-format R R R
ドキュメント形式r r r
document-name O O
ドキュメント名o o
document-natural- O O language
ドキュメント自然 - o o言語
ipp-attribute- R R R fidelity
ipp-aTtribute- r r r fidelity
job-impressions O O O
職務障害o o o
job-k-octets O O O
job-k-octets o o o
job-media-sheets O O O
ジョブメディアシートo o
Printer Operations
プリンター操作
Requests Respon-ses Operation Attributes PJ, PU CJ GPA GJ PP, All VJ (O) (O) (R) (R) RP, Opera (R) PP tions (O+)
リクエストRespon-SES Operation属性PJ、PU CJ GPA GJ PP、すべてのVJ（O）（O）（R）（R）RP、Opera（R）PPITIONS（O）
limit R
制限r
message
メッセージ伝言言付け一報人伝託け使命使い奨励
my-jobs R
my-jobs r
requested-attributes R R
リクエスト - アトリビュートr r
which-jobs R
which-jobs r
Legend:
伝説：
PJ, VJ: Print-Job, Validate-Job PU: Print-URI CJ: Create-Job GPA: Get-Printer-Attributes GJ: Get-Jobs PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP. * "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED. ** "document-access-error" applies to the Print-URI response only.
PJ、VJ：Print-Job、Validate-Job PU：Print-URI CJ：Create-Job GPA：Get-Printer-Attributes GJ：Get-Jobs PP、RP、PP：Pause-Printer、Resume-Printer、Purge-PrinterRは、IPPオブジェクト（プリンターまたはジョブ）でサポートする必要がある必要な操作を示します。属性の場合、Rは、関連する操作をサポートするIPPオブジェクトによって属性がサポートされている必要があることを示します。o IPPオブジェクト（プリンターまたはジョブ）によってサポートされる可能性のあるオプションの操作または属性を示します。これはIPP/1.0機能ではなく、IPP/1.1およびIPPの将来のバージョンの一部にすぎないことを示します。*ターゲットジョブを識別するために「プリンター-Ri」と一緒に使用される場合にのみ、「Job-ID」が必要です。それ以外の場合は、「job-uri」が必要です。**「Document-Access-Error」は、印刷-URI応答のみに適用されます。
Table 3 - Summary of Job operation attributes that sender MUST supply
表3-送信者が供給しなければならない雇用操作の要約
Job Operations
職務操作
Requests Responses
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
Operation parameters--REQUIRED to be supplied by the sender:
操作パラメーター - 送信者から提供されるようにリクエアされています。
operation-id R R R R R
Operation-ID R R R R R
status-code R
ステータスコードr
request-id R R R R R R
Request-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
属性-chharset r r r r r r
attributes-natural- R R R R R R language
属性 - 自然 - r r r r r r r言語
document-uri R
document-uri r
job-id* R R R R R
job-id* r r r r r
job-uri* R R R R R
job-uri* r r r r r
last-document R R
ラストドキュメントr r
printer-uri R R R R R
プリンター - ウリr r r r r
Operation attributes--RECOMMENDED to be supplied by the sender:
操作属性 - 送信者から提供されるように推奨されます。
job-name
職種名
Job Operations
職務操作
Requests Responses
応答を要求します
Operation SD SU CJ GJA HJ All Attributes (O) (O) (R) (R) RJ, RJ Opera-(O+) tions
Operation SD SU CJ GJA HJすべての属性（O）（O）（R）（R）RJ、RJオペラ（O）
requesting-user- R R R R R name
リクエストユーザー - r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r
Legend:
伝説：
SD: Send-Document SU: Send-URI CJ: Cancel-Job GJA: Get-Job-Attributes HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP. * "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED.
SD：send-document su：send-uri cj：cancel-job gja：get-job-attributes hj、rj、rj：hold-job、release-job、restart-job rは、必要な操作を示しています。IPPオブジェクト（プリンターまたはジョブ）。属性の場合、Rは、関連する操作をサポートするIPPオブジェクトによって属性がサポートされている必要があることを示します。o IPPオブジェクト（プリンターまたはジョブ）によってサポートされる可能性のあるオプションの操作または属性を示します。これはIPP/1.0機能ではなく、IPP/1.1およびIPPの将来のバージョンの一部にすぎないことを示します。*ターゲットジョブを識別するために「プリンター-Ri」と一緒に使用される場合にのみ、「Job-ID」が必要です。それ以外の場合は、「job-uri」が必要です。
Table 4 - Summary of Job operation attributes that sender MAY supply
表4-送信者が提供する可能性のある職務操作の要約
Job Operations
職務操作
Requests Responses
応答を要求します
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
Operation attributes--OPTIONAL to be supplied by the sender:
操作属性 - 送信者によって提供されるようになります。
status-message O
ステータスメッセージo
detailed-status- O message
詳細なステータス-Oメッセージ
document-access- O** error
document-access- o **エラー
compression R R
圧縮r r
document-format R R
ドキュメント形式r r
document-name O O
ドキュメント名o o
document-natural- O O language
ドキュメント自然 - o o言語
ipp-attribute-fidelity
ipp-aTtribute-fidelity
job-impressions
就職活動
job-k-octets
Job-K-Octets
job-media-sheets
ジョブメディアシート
Job Operations
職務操作
Requests Responses
応答を要求します
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
limit
制限限定リミット限界限度極限限り際限限る端果て局限程果てし郊外
message O O O
メッセージo o o
job-hold-until R
ヨブ・ホルド・ティルr
my-jobs
私のジョブ
requested- R attributes
要求-R属性
which-jobs
どちらのジョブ
Legend:
伝説：
SD: Send-Document SU: Send-URI CJ: Cancel-Job GJA: Get-Job-Attributes HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job). + indicates that this is not an IPP/1.0 feature, but is only a part of IPP/1.1 and future versions of IPP. * "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED. ** "document-access-error" applies to the Send-URI operation only
SD：send-document su：send-uri cj：cancel-job gja：get-job-attributes hj、rj、rj：hold-job、release-job、restart-job rは、必要な操作を示しています。IPPオブジェクト（プリンターまたはジョブ）。属性の場合、Rは、関連する操作をサポートするIPPオブジェクトによって属性がサポートされている必要があることを示します。o IPPオブジェクト（プリンターまたはジョブ）によってサポートされる可能性のあるオプションの操作または属性を示します。これはIPP/1.0機能ではなく、IPP/1.1およびIPPの将来のバージョンの一部にすぎないことを示します。*ターゲットジョブを識別するために「プリンター-Ri」と一緒に使用される場合にのみ、「Job-ID」が必要です。それ以外の場合は、「job-uri」が必要です。** "Document-Access-Error"はsend-uri操作のみに適用されます
Table 5 - Printer operation response attributes
表5-プリンター操作応答属性
Printer Operations
プリンター操作
Response
応答
Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP, Attributes SD (O) SU (O) (R) RP, PP (O+)
操作PJ（R）VJ（R）PU（O）CJ（O）GPA GJ（R）PP、属性SD（O）SU（O）（R）RP、PP（O）
job-uri R R R
job-uri r r r
job-id R R R
Job-Id r r r
job-state R R R
ジョブステートr r r
job-state- R+ R+ R+ reasons
ジョブステートリングの理由
number-of- O O O intervening-jobs
o o o o o介入ジョブの数
document- O access-error+
Document-Oアクセスエラー
Legend:
伝説：
PJ, SJ: Print-Job, Send-Document VJ: Validate-Job PU, SU: Print-URI, Send-URI CJ: Create-Job GPA: Get-Printer-Attributes GJ: Get-Jobs PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer R indicates a REQUIRED operation that MUST be supported by the IPP object (Printer or Job). For attributes, R indicates that the attribute MUST be supported by the IPP object that supports the associated operation. O indicates an OPTIONAL operation or attribute that MAY be supported by the IPP object (Printer or Job).
PJ、SJ：Print-Job、Send-Document VJ：Validate-Job PU、Su：Print-uri、Send-Uri CJ：Create-Job GPA：Get-Printer-Attributes GJ：Get-Jobs PP、RP、PP：一時停止 - プリンター、履歴書 - プリンター、パージプリンターRは、IPPオブジェクト（プリンターまたはジョブ）でサポートする必要がある必要な操作を示します。属性の場合、Rは、関連する操作をサポートするIPPオブジェクトによって属性がサポートされている必要があることを示します。o IPPオブジェクト（プリンターまたはジョブ）によってサポートされる可能性のあるオプションの操作または属性を示します。
This section suggests the steps and error checks that an IPP object MAY perform when processing requests and returning responses. An IPP object MAY perform some or all of the error checks. However, some implementations MAY choose to be more forgiving than the error checks shown here, in order to be able to accept requests from non-conforming clients. Not performing all of these error checks is a so-called "forgiving" implementation. On the other hand, clients that successfully submit requests to IPP objects that do perform all the error checks will be more likely to be able to interoperate with other IPP object implementations. Thus an implementer of an IPP object needs to decide whether to be a "forgiving" or a "strict" implementation. Therefore, the error status codes returned may differ between implementations. Consequentially, client SHOULD NOT expect exactly the error code processing described in this section.
このセクションでは、IPPオブジェクトがリクエストを処理して応答を返すときに実行できるステップとエラーチェックを示唆しています。IPPオブジェクトは、エラーチェックの一部またはすべてを実行する場合があります。ただし、一部の実装は、不適合クライアントからのリクエストを受け入れることができるために、ここに示すエラーチェックよりも寛容であることを選択する場合があります。これらすべてのエラーチェックを実行しないことは、いわゆる「寛容」の実装です。一方、すべてのエラーチェックを実行するIPPオブジェクトにリクエストを正常に送信するクライアントは、他のIPPオブジェクトの実装と相互運用できる可能性が高くなります。したがって、IPPオブジェクトの実装者は、「寛容」または「厳格な」実装であるかどうかを決定する必要があります。したがって、返されるエラーステータスコードは、実装間で異なる場合があります。結果として、クライアントはこのセクションで説明されているエラーコード処理を正確に期待してはなりません。
When an IPP object receives a request, the IPP object either accepts or rejects the request. In order to determine whether or not to accept or reject the request, the IPP object SHOULD execute the following steps. The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request.
IPPオブジェクトがリクエストを受信すると、IPPオブジェクトはリクエストを受け入れるか拒否します。リクエストを受け入れるか拒否するかどうかを判断するために、IPPオブジェクトは次の手順を実行する必要があります。ステップの順序は、リクエスト上の1つまたは複数のパスを行うなど、再配置および/または組み合わせることができます。
A client MUST supply requests that would pass all of the error checks indicated here in order to be a conforming client. Therefore, a client SHOULD supply requests that are conforming, in order to avoid being rejected by some IPP object implementations and/or risking different semantics by different implementations of forgiving implementations. For example, a forgiving implementation that accepts multiple occurrences of the same attribute, rather than rejecting the request might use the first occurrences, while another might use the last occurrence. Thus such a non-conforming client would get different results from the two forgiving implementations.
クライアントは、適合クライアントになるためにここに示されているすべてのエラーチェックに合格するリクエストを提供する必要があります。したがって、クライアントは、一部のIPPオブジェクトの実装によって拒否されたり、寛容な実装のさまざまな実装によって異なるセマンティクスを危険にさらすことを避けるために、適合しているリクエストを提供する必要があります。たとえば、リクエストを拒否するのではなく、同じ属性の複数の発生を受け入れる寛容な実装は、最初の発生を使用する場合があり、別のものが最後の発生を使用する場合があります。したがって、このような不適合クライアントは、2つの寛容な実装から異なる結果を得るでしょう。
In the following, processing continues step by step until a "RETURNS the xxx status code ..." statement is encountered. Error returns are indicated by the verb: "REJECTS". Since clients have difficulty getting the status code before sending all of the document data in a Print-Job request, clients SHOULD use the Validate-Job operation before sending large documents to be printed, in order to validate whether the IPP Printer will accept the job or not.
以下では、処理は「XXXステータスコードを返す...」ステートメントが発生するまで段階的に継続します。エラーリターンは動詞で示されます：「拒否」。クライアントはすべてのドキュメントデータを印刷ジョブリクエストで送信する前にステータスコードを取得するのが困難であるため、IPPプリンターがジョブを受け入れるかどうかを検証するために、クライアントは大規模なドキュメントを送信する前に検証とジョブの操作を使用する必要があります。か否か。
It is assumed that security authentication and authorization has already taken place at a lower layer.
セキュリティ認証と承認はすでに下層で行われていると想定されています。
This section is intended to apply to all operations. The next section contains the additional steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations that create jobs, adds documents, and validates jobs.
このセクションは、すべての操作に適用することを目的としています。次のセクションには、雇用を作成し、ドキュメントを追加し、ジョブを検証する、Print-Job、Validate-Job、Print-uri、Create-Job、Send-Document、およびSend-URIオペレーションの追加の手順が含まれています。
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v err
3.1.2.1.1 <Validate version> --> server-error-version-not-
supported
ok|
v err
3.1.2.1.2 <Validate operation> --> server-error-operation-not-
supported
ok|
v err
3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
3.1.2.1.4.2 <of attributes>
ok|
v err
3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
<of operation attr>
ok|
v err
3.1.2.1.5 <Validate values of> --> client-error-bad-request
<operation attrs> client-error-request-value-
too-long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.1.5 <Validate values> --> client-error-bad-request
<with supported values> client-error-charset-not-
supported
ok| client-error-attributes-or-
values-
| not-supported
v err
3.1.2.1.6 <Validate optionally> --> client-error-bad-request
<operation attr> client-error-natural-language-
not-supported
| client-error-request-value-
too-long
| client-error-attributes-or-
values-not-supported
Every request and every response contains the "version-number" attribute. The value of this attribute is the major and minor version number of the syntax and semantics that the client and IPP object is using, respectively. The "version-number" attribute remains in a fixed position across all future versions so that all clients and IPP object that support future versions can determine which version is being used. The IPP object checks to see if the major version number supplied in the request is supported. If not, the Printer object REJECTS the request and RETURNS the 'server-error-version-not-supported' status code in the response. The IPP object returns in the "version-number" response attribute the major and minor version for the error response. Thus the client can learn at least one major and minor version that the IPP object supports. The IPP object is encouraged to return the closest version number to the one supplied by the client.
すべてのリクエストとすべての応答には、「バージョン番号」属性が含まれています。この属性の値は、クライアントとIPPオブジェクトがそれぞれ使用している構文とセマンティクスの主要なバージョンおよびマイナーバージョン番号です。「バージョン番号」属性は、将来のすべてのバージョンにわたって固定された位置に残っているため、将来のバージョンをサポートするすべてのクライアントとIPPオブジェクトが使用されているバージョンを決定できます。IPPオブジェクトは、リクエストで提供されたメジャーバージョン番号がサポートされているかどうかを確認します。そうでない場合、プリンターオブジェクトはリクエストを拒否し、「サーバーエラーバージョンのサポートされていない」ステータスコードを応答で返します。IPPオブジェクトは、エラー応答の「バージョン番号」応答属性のメジャーバージョンとマイナーバージョンに戻ります。したがって、クライアントは、IPPオブジェクトがサポートする少なくとも1つの主要バージョンとマイナーバージョンを学習できます。IPPオブジェクトは、クライアントが提供するものに最も近いバージョン番号を返すことをお勧めします。
The checking of the minor version number is implementation dependent, however if the client-supplied minor version is explicitly supported, the IPP object MUST respond using that identical minor version number. If the major version number matches, but the minor version number does not, the Printer SHOULD accept and attempt to process the request, or MAY reject the request and return the 'server-error-version-not-supported' status code. In all cases, the Printer MUST return the nearest version number that it supports. For example, suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'. The following responses are conforming:
マイナーバージョン番号のチェックは実装に依存しますが、クライアントがサプライされたマイナーバージョンが明示的にサポートされている場合、IPPオブジェクトはその同一のマイナーバージョン番号を使用して応答する必要があります。メジャーバージョン番号が一致しているが、マイナーバージョン番号がない場合、プリンターはリクエストを受け入れて処理しようとするか、リクエストを拒否して「サーバーエラーバージョンがサポートされていない」ステータスコードを返す必要があります。いずれの場合も、プリンターはサポートする最も近いバージョン番号を返す必要があります。たとえば、IPP/1.2プリンターがバージョン「1.1」と「1.2」をサポートしていると仮定します。次の回答が適合しています。
Table 6 - Examples of validating IPP version
表6- IPPバージョンの検証例
Client supplies Printer Accept Request? Printer returns
クライアントサプライプリンターはリクエストを受け入れますか？プリンターが返されます
1.0 yes (SHOULD) 1.1
1.0 はい（必要）1.1
1.0 no (SHOULD NOT) 1.1
1.0 いいえ（すべきではない）1.1
1.1 yes (MUST) 1.1
1.1 はい（必須）1.1
1.2 yes (MUST) 1.2
1.2 はい（必須）1.2
1.3 yes (SHOULD) 1.2
1.3 はい（必要）1.2
1.3 no (SHOULD NOT) 1.2
1.3 いいえ（すべきではない）1.2
It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, so that they can interoperate with either client implementations. Some implementations may allow an Administrator to explicitly disable support for one or the other by setting the "ipp-versions-supported" Printer description attribute.
プリンターがIPP/1.1とIPP/1.0の両方をサポートすることが有利であり、いずれかのクライアントの実装と相互操作できるようにします。一部の実装により、「IPP-versionsがサポートする」プリンター説明属性を設定することにより、管理者がどちらか一方のサポートを明示的に無効にすることができます。
Likewise, it is advantageous for clients to support both versions to allow interoperability with new and legacy Printers.
同様に、クライアントが両方のバージョンをサポートして、新しいレガシープリンターとの相互運用性を可能にすることが有利です。
The Printer object checks to see if the "operation-id" attribute supplied by the client is supported as indicated in the Printer object's "operations-supported" attribute. If not, the Printer REJECTS the request and returns the 'server-error-operation-not-supported' status code in the response.
プリンターオブジェクトは、クライアントが提供する「Operation-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.
プリンターオブジェクトは、クライアントが提供する「リクエストID」属性が範囲であるかどうかを確認してはなりません。
Note: The "version-number", "operation-id", and the "request-id" parameters are in fixed octet positions in the IPP/1.1 encoding. The "version-number" parameter will be the same fixed octet position in all versions of the protocol. These fields are validated before proceeding with the rest of the validation.
注：「バージョン番号」、「Operation-ID」、および「Request-ID」パラメーターは、IPP/1.1エンコーディングの固定オクテット位置にあります。「バージョン番号」パラメーターは、プロトコルのすべてのバージョンで同じ固定オクテット位置になります。これらのフィールドは、残りの検証を進める前に検証されます。
The order of the following validation steps depends on implementation.
次の検証手順の順序は、実装に依存します。
Client requests and IPP object responses contain attribute groups that Section 3 requires to be present and in a specified order. An IPP object verifies that the attribute groups are present and in the correct order in requests supplied by clients (attribute groups without an * in the following tables).
クライアントリクエストとIPPオブジェクト応答には、セクション3が存在し、指定された順序で必要とする属性グループが含まれています。IPPオブジェクトは、属性グループが存在することを確認し、クライアント（次のテーブルには *のない属性グループ）が提供するリクエストで正しい順序で順序で確認されます。
If an IPP object receives a request with (1) required attribute groups missing, or (2) the attributes groups are out of order, or (3) the groups are repeated, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code. For example, it is an error for the Job Template Attributes group to occur before the Operation Attributes group, for the Operation Attributes group to be omitted, or for an attribute group to occur more than once, except in the Get-Jobs response.
IPPオブジェクトが（1）必要な属性グループが欠落しているリクエストを受信した場合、または（2）属性グループが故障していない場合、または（3）グループが繰り返される場合、IPPオブジェクトはリクエストを拒否し、 'client-errorを返します-bad-request 'ステータスコード。たとえば、Job Template属性グループが操作属性グループの前に発生すること、操作属性グループが省略されるか、属性グループがGet-Jobs応答を除いて複数回発生することはエラーです。
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.
将来の属性グループは、ドキュメントコンテンツの直前と応答の終了時にリクエストの最後に仕様に追加される場合があります。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オブジェクトはクライアントに適切なフォームを使用するように強制します。
Client requests and IPP object responses contain Operation attributes that [RFC2911] Section 3 requires to be present. Attributes within a group may be in any order, except for the ordering of target, charset, and natural languages attributes. These attributes MUST be first, and MUST be supplied in the following order: charset, natural language, and then target. An IPP object verifies that the attributes that Section 4 requires to be supplied by the client have been supplied in the request (attributes without an * in the following tables). An asterisk (*) indicates groups and Operation attributes that the client may omit in a request or an IPP object may omit in a response.
クライアントリクエストとIPPオブジェクト応答には、[RFC2911]セクション3が存在する必要がある操作属性が含まれています。グループ内の属性は、ターゲット、チャーセット、および自然言語の属性の順序を除き、任意の順序である場合があります。これらの属性は最初に必要であり、次の順序で提供する必要があります：charset、natural Language、およびターゲット。IPPオブジェクトは、セクション4がクライアントが提供する必要がある属性がリクエストに提供されていることを確認します（次のテーブルには *なしで属性）。アスタリスク（*）は、クライアントがリクエストで省略するか、IPPオブジェクトが応答で省略できるグループと操作の属性を示します。
If an IPP object receives a request with required attributes missing or repeated from a group or in the wrong position, the behavior of the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible implementations are:
IPPオブジェクトが、グループまたは間違った位置から欠落または繰り返される必要な属性を持つリクエストを受信した場合、IPPオブジェクトの動作は実装依存です。可能な実装のいくつかは次のとおりです。
REJECTS the request and RETURNS the 'client-error-bad-request' status code accepts the request and uses the first occurrence of the attribute no matter where it is
リクエストを拒否し、「クライアントエラーバッドレクエスト」ステータスコードを返しますリクエストを受け入れ、属性の最初の発生を使用します。
accepts the request and uses the last occurrence of the attribute no matter where it is
リクエストを受け入れ、属性の最後の発生をどこにいても使用します
accept the request and assume some default value for the missing attribute
リクエストを受け入れ、欠落属性のデフォルト値を想定してください
Therefore, client MUST send conforming requests, if they want to receive the same behavior from all IPP object implementations. For example, it is an error for the "attributes-charset" or "attributes-natural-language" attribute to be omitted in any operation request, or for an Operation attribute to be supplied in a Job Template group or a Job Template attribute to be supplied in an Operation Attribute group in a create request. It is also an error to supply the "attributes-charset" attribute twice.
したがって、すべてのIPPオブジェクトの実装から同じ動作を受信したい場合、クライアントは適合リクエストを送信する必要があります。たとえば、操作要求で「属性」または「属性」属性が省略されるか、またはジョブテンプレートグループまたはジョブテンプレート属性に操作属性が提供されるためのエラーです。作成リクエストでOperation属性グループに提供されます。また、「属性 - チャレット」属性を2回提供するエラーでもあります。
Since these kinds of attribute errors are most likely to be detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attribute was in error in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all attribute errors before returning this error.
これらの種類の属性エラーは、顧客ではなくクライアント開発者によって検出される可能性が最も高いため、IPPオブジェクトは、サポートされていない属性グループまたはステータスメッセージのいずれかで誤っている属性の表示を返す必要はありません。また、このエラーを返す前に、IPPオブジェクトはすべての属性エラーを見つける必要はありません。
The following tables list all the attributes for all the operations by attribute group in each request and each response. The order of the groups is the order that the client supplies the groups as specified in [RFC2911] Section 3. The order of the attributes within a group is arbitrary, except as noted for some of the special operation attributes (charset, natural language, and target). The tables below use the following notation:
次のテーブルには、各要求と各応答の属性グループごとのすべての操作のすべての属性をリストします。グループの順序は、クライアントが[RFC2911]セクション3で指定されているグループに供給する順序です。グループ内の属性の順序は、特別操作属性の一部（charset、natural Language、およびターゲット）。以下の表は、次の表記を使用します。
R indicates a REQUIRED attribute or operation that an IPP object MUST support O indicates an OPTIONAL attribute or operation that an IPP object NEED NOT support * indicates that a client MAY omit the attribute in a request and that an IPP object MAY omit the attribute in a response. The absence of an * means that a client MUST supply the attribute in a request and an IPP object MUST supply the attribute in a response. + indicates that this is not a IPP/1.0 operation, but is only a part of IPP/1.1 and future versions of IPP.
Rは、IPPオブジェクトがサポートする必要があることを必要とする属性または操作を示しますoは、IPPオブジェクトがサポートする必要がないというオプションの属性または操作を示します *クライアントが要求で属性を省略し、IPPオブジェクトが属性を省略することができることを示します。応答。*がないということは、クライアントが要求に属性を提供する必要があり、IPPオブジェクトが応答で属性を提供する必要があることを意味します。これはIPP/1.0操作ではなく、IPP/1.1およびIPPの将来のバージョンの一部にすぎないことを示します。
Operation Requests
操作リクエスト
The tables below show the attributes in their proper attribute groups for operation requests:
以下の表は、操作要求のための適切な属性グループの属性を示しています。
Note: All operation requests contain "version-number", "operation-id", and "request-id" parameters.
注：すべての操作要求には、「バージョン番号」、「Operation-ID」、および「Request-ID」パラメーターが含まれています。
Print-Job Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see [RFC2911] Section 4.2) Group 3: Document Content (R) <document content>
印刷ジョブリクエスト（R）：グループ1：操作属性（r）属性 - チャチャーセット（r）属性 - 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*）圧縮（r*）job-k-octets（o*）job-インプレッション（o*）ジョブメディアシート（o*）グループ2：ジョブテンプレート属性（r*）<ジョブテンプレート属性>（o*）（[rfc2911]セクション4.2を参照）グループ3：ドキュメントコンテンツ（r）<ドキュメントコンテンツ>
Validate-Job Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see [RFC2911] Section 4.2)
VALIDATE-JOB要求（R）：グループ1：操作属性（r）属性 - 特徴（R）属性 - とんず言語（R）プリンター-URI（R）リクエスト-USER-NAME（r*）Job-Name（R*）ipp-aTtribute-fidelity（r*）document-name（r*）document-format（r*）document-natural-language（o*）圧縮（r*）job-k-octets（o*）job-インプレッション（o*）ジョブメディアシート（o*）グループ2：ジョブテンプレート属性（r*）<ジョブテンプレート属性>（o*）（[rfc2911]セクション4.2を参照）
Print-URI Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) document-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see (see [RFC2911] Section 4.2)
Print-uri request（o）：グループ1：操作属性（r）属性-chharset（r）属性 - uring-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*）圧縮（r*）Job-K-Octets（o*）ジョブインプレッション（o*）ジョブメディアシート（o*）グループ2：ジョブテンプレート属性（r*）<ジョブテンプレート属性>（o*）（（[rfc2911]を参照）セクション4.2を参照）
Create-Job Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) job-name (R*) ipp-attribute-fidelity (R*) job-k-octets (O*) job-impressions (O*) job-media-sheets (O*) Group 2: Job Template Attributes (R*) <Job Template attributes> (O*) (see (see [RFC2911] Section 4.2)
Create-Job request（o）：グループ1：操作属性（R）属性-chharset（r）属性 - uring-uri（r）requesting-user-name（r*）job-name（r*）IPP-Attribute-Fidelity（r*）Job-K-Octets（O*）Job-Impressions（O*）Job-Media-Sheets（O*）グループ2：ジョブテンプレート属性（r*）<ジョブテンプレート属性>（o*）（参照（[rfc2911]セクション4.2を参照）
Get-Printer-Attributes Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) requested-attributes (R*) document-format (R*)
Get-Printer-Attributes request（r）：グループ1：操作属性（R）属性-chharset（r）属性 - natural-language（r）Printer-uri（r）requesting-user-name（r*）requested-attributes（r*）document-format（r*）
Get-Jobs Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*) limit (R*) requested-attributes (R*) which-jobs (R*) my-jobs (R*)
get-jobs request（r）：グループ1：操作属性（r）属性-chharset（r）属性 - uring-uri（r）requesting-user-name（r*）limit（r*）リクエスト済み - アトリビュート（r*）what-jobs（r*）my-jobs（r*）
Send-Document Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) last-document (R) requesting-user-name (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*) Group 2: Document Content (R*) <document content>
Send-Document Request（o）：グループ1：操作属性（R）属性-chharset（r）属性 - uri-uri＆job-id）|Job-uri（r）Last-Document（R）requesting-user-name（r*）document-name（r*）document-format（r*）document-natural-language（o*）圧縮（r*）グループ2：ドキュメントコンテンツ（r*）<ドキュメントコンテンツ>
Send-URI Request (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) last-document (R) document-uri (R) requesting-user-name (R*) document-name (R*) document-format (R*) document-natural-language (O*) compression (R*)
Send-uri request（o）：グループ1：操作属性（r）属性-chharset（r）属性 - uri-uri＆job-id）|Job-uri（r）last-document（r）document-uri（r）requiest-user-name（r*）document-name（r*）document-format（r*）document-natural-language（o*）圧縮（r*）
Cancel-Job Request (R): Release-Job Request (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) requesting-user-name (R*) message (O*)
キャンセルジョブリクエスト（r）：リリースジョブリクエスト（o）：グループ1：操作属性（r）属性-chharset（r）属性 - ナチュラルランガージ（r）（printer-uri＆job-id）|job-uri（r）requiest-user-name（r*）メッセージ（o*）
Get-Job-Attributes Request (R): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) requesting-user-name (R*) requested-attributes (R*)
get-job-attributes request（r）：グループ1：操作属性（r）属性-chharset（r）属性 - uri-uri＆job-id）|job-uri（r）requesting-user-name（r*）requested-attributes（r*）
Pause-Printer Request (O+): Resume-Printer Request (O+): Purge-Printer Request (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) printer-uri (R) requesting-user-name (R*)
Pause-Printer request（O）：Resume-Printer Request（O）：Purge-Printer Request（o）：グループ1：操作属性（R）属性-Charset（R）属性 - uring-language（r）Printer-uri（r）リクエスト - ユーザー名（r*）
Hold-Job Request (O+): Restart-Job Request (O+): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) (printer-uri & job-id) | job-uri (R) requesting-user-name (R*) job-hold-until (R*) message (O*)
Hold-Job request（o）：Restart-Job request（o）：グループ1：操作属性（r）属性-chharset（r）属性 - uri-uri＆job-id）|job-uri（r）requiest-user-name（r*）job-hold-until（r*）メッセージ（o*）
Operation Responses
操作応答
The tables below show the response attributes in their proper attribute groups for responses.
以下の表は、応答のための適切な属性グループの応答属性を示しています。
Note: All operation responses contain "version-number", "status-code", and "request-id" parameters.
注：すべての操作応答には、「バージョン番号」、「ステータスコード」、および「リクエストID」パラメーターが含まれています。
Print-Job Response (R):
Create-Job Response (O):
Send-Document Response (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
n <unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
Validate-Job Response (R):
Cancel-Job Response (R):
Hold-Job Response (O+):
Release-Job Response (O+):
Restart-Job Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Print-URI Response (O): Send-URI Response (O): Group 1: Operation Attributes (R) attributes-charset (R) attributes-natural-language (R) status-message (O*) detailed-status-message (O*) document-access-error (O*) Group 2: Unsupported Attributes (R*) (see Note 3) <unsupported attributes> (R*) Group 3: Job Object Attributes(R*) (see Note 2) job-uri (R) job-id (R) job-state (R) job-state-reasons (O* | R+) job-state-message (O*) number-of-intervening-jobs (O*)
Print-URI Response（O）：Send-URI Response（O）：グループ1：操作属性（R）属性-Charset（r）属性 - と様式と言語（r）ステータス - メッサージ（o*）詳細ステータスメサージ（o*）document-access-error（o*）グループ2：サポートされていない属性（r*）（注3を参照）<サポート属性>（r*）グループ3：ジョブオブジェクト属性（r*）（注2を参照）Job-uri（r）Job-id（r）Job-State（r）Job-State-Reasons（O*| r）Job-State-Message（O*）Intervening-Jobs（O*）
Get-Printer-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Get-Jobs Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*)
Get-Job-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Pause-Printer Response (O+):
Resume-Printer Response (O+):
Purge-Printer Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Note 2 - the Job Object Attributes and Printer Object Attributes are returned only if the IPP object returns one of the success status codes.
注2-ジョブオブジェクト属性とプリンターオブジェクト属性は、IPPオブジェクトが成功ステータスコードのいずれかを返す場合にのみ返されます。
Note 3 - the Unsupported Attributes Group is present only if the client included some Operation and/or Job Template attributes or values that the Printer doesn't support whether a success or an error return.
注3-サポートされていない属性グループは、クライアントが成功またはエラーリターンのいずれかをサポートしていない操作および/またはジョブテンプレートの属性または値をクライアントに含めた場合にのみ存在します。
Note 4 - the Unsupported Attributes Group is present only if the client included some Operation attributes that the Printer doesn't support whether a success or an error return.
注4-サポートされていない属性グループは、クライアントが成功かエラーの返されたかどうかをサポートしていないといういくつかの操作属性をクライアントに含めた場合にのみ存在します。
Note 5: for the Get-Jobs operation the response contains a separate Job Object Attributes group 3 to N containing requested-attributes for each job object in the response.
注5：get-jobs操作の場合、応答には、応答内の各ジョブオブジェクトの要求されたアトリビュートを含むグループ3を属性属性属性属性が含まれます。
An IPP object validates the values supplied by the client of the REQUIRED Operation attribute that the IPP object MUST support. The next section specifies the validation of the values of the OPTIONAL Operation attributes that IPP objects MAY support.
IPPオブジェクトは、IPPオブジェクトがサポートする必要がある必要な操作属性のクライアントが提供する値を検証します。次のセクションでは、IPPオブジェクトがサポートできるオプションの操作属性の値の検証を指定します。
The IPP object performs the following syntactic validation checks of each Operation attribute value:
IPPオブジェクトは、各操作属性値の次の構文検証チェックを実行します。
a) that the length of each Operation attribute value is correct for the attribute syntax tag supplied by the client according to [RFC2911] Section 4.1,
a) 各操作属性値の長さは、[RFC2911]セクション4.1に従ってクライアントが提供する属性構文タグに対して正しいことです。
b) that the attribute syntax tag is correct for that Operation attribute according to [RFC2911] Section 3,
b) [RFC2911]セクション3に従って、属性構文タグがその操作属性に対して正しいこと
c) that the value is in the range specified for that Operation attribute according to [RFC2911] Section 3,
c) 値が[RFC2911]セクション3に従ってその操作属性に指定された範囲にあること
d) that multiple values are supplied by the client only for operation attributes that are multi-valued, i.e., that are 1setOf X according to [RFC2911] Section 3.
d) 複数の値は、[RFC2911]セクション3に従ってXの1SetOf Xである操作属性に対してのみクライアントによって提供されます。
If any of these checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request-value-too-long' status code. Since such an error is most likely to be an error detected by a client developer, rather than by an end-user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
これらのチェックのいずれかが失敗した場合、IPPオブジェクトはリクエストを拒否し、「クライアントエラーバッドレクエスト」または「クライアントエラーレクスト値」ステータスコードを返します。このようなエラーは、エンドユーザーではなく、クライアント開発者によって検出されるエラーである可能性が最も高いため、IPPオブジェクトは、サポートされていない属性グループまたはステータスメッセージのいずれかでエラーがある属性の表示を返す必要はありません。これらの構文チェックのそれぞれの説明は、次の表の最初のIFステートメントで明示的に表現されています。
In addition, the IPP object checks each Operation attribute value against some Printer object attribute or some hard-coded value if there is no "xxx-supported" Printer object attribute defined. If its value is not among those supported or is not in the range supported, then the IPP object REJECTS the request and RETURNS the error status code indicated in the table by the second IF statement. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails.
さらに、IPPオブジェクトは、「xxxサポートされた」プリンターオブジェクト属性が定義されている場合、各操作属性値をいくつかのプリンターオブジェクト属性またはハードコーディングされた値に対してチェックします。その値がサポートされているものの中にない場合、またはサポートされている範囲にない場合、IPPオブジェクトはリクエストを拒否し、2番目のIFステートメントで表に示されているエラーステータスコードを返します。プリンターオブジェクトの「xxxサポート」属性の値が「価値のない」（システム管理者が値を構成していないため）の場合、チェックは常に失敗します。
-----------------------------------------------
attributes-charset (charset)
属性-harset（charset）
IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-error-bad-request'.
単一の非空白の「チャーセット」値でない場合は、「クライアントとエラーバッドレクエスト」を拒否/返還してください。
IF the value length is greater than 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが63オクテットを超える場合は、「クライアントエラーレクスト値」を拒否/返信します。
IF NOT in the Printer object's "charset-supported" attribute, REJECT/RETURN "client-error-charset-not-supported".
プリンターオブジェクトの「チャーセットがサポートする」属性にない場合は、「クライアントエラーセットなし」を拒否/返還してください。
attributes-natural-language(naturalLanguage)
属性 - 自然言語（naturallanguage）
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 'client-error-bad-request'.
単一の非空白の「naturallangage」値でない場合は、「client-error-bad-request」を拒否/返還してください。
IF the value length is greater than 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが63オクテットを超える場合は、「クライアントエラーレクスト値」を拒否/返信します。
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.
プリンターオブジェクトの「生成された自然言語サポート」属性のセットのメンバーではない場合でも、リクエストを受け入れます。供給された値がプリンターオブジェクトの「生成された自然言語サポート」属性のメンバーではない場合は、プリンターオブジェクトの「自然言語構成」値を使用します。
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF the IPP object can obtain a better-authenticated name, use it instead.
IPPオブジェクトがよりよく認識された名前を取得できる場合は、代わりにそれを使用します。
job-name(name)
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF NOT supplied by the client, the Printer object creates a name from the document-name or document-uri.
クライアントから提供されていない場合、プリンターオブジェクトはドキュメント名またはドキュメントウリから名前を作成します。
document-name (name)
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
ipp-attribute-fidelity (boolean)
ipp-aTtribute-fidelity（boolean）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'.
単一の「真」または単一の「false」「ブール」値のいずれでもない場合は、クライアントとエラーのバッドレクエスト 'を拒否/返却します。
IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client-error-request-value-too-long'
値の長さが1オクテットに等しくない場合は、 'client-error-request-value-too-long'を拒否/返信します
IF NOT supplied by the client, the IPP object assumes the value 'false'.
クライアントから提供されていない場合、IPPオブジェクトは値「false」を想定しています。
document-format (mimeMediaType)
ドキュメントフォーマット（mimemediatype）
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN 'client-error-bad-request'.
単一の非空白の「Mimemediatype」値でない場合は、「クライアントエラーバッドレクエスト」を拒否/返還してください。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF NOT in the Printer object's "document-format-supported" attribute, REJECT/RETURN 'client-error-document-format-not-supported'
プリンターオブジェクトの「ドキュメントフォーマットがサポートする」属性にない場合は、「クライアントエラードキュメントフォーマットとサポートされていない」を拒否/返却します」
IF NOT supplied by the client, the IPP object assumes the value of the Printer object's "document-format-default" attribute.
クライアントから提供されていない場合、IPPオブジェクトは、プリンターオブジェクトの「ドキュメントフォーマットデフォルト」属性の値を想定しています。
document-uri (uri)
document-uri（uri）
IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-error-bad-request'.
単一の非空白の「uri」値でない場合は、「クライアントとエラーバッドレクエスト」を拒否/返還してください。
IF the value length is greater than 1023 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが1023オクテットを超えている場合は、「クライアントエラーレクスト値」を拒否/返信します。
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-request'.
URI構文が有効でない場合は、「クライアントエラーバッドレクエスト」を拒否/返信します。
If the client-supplied URI scheme is not supported, i.e., the value is not in the Printer object's referenced-uri-scheme-supported" attribute, the Printer object MUST reject the request and return the 'client-error-uri-scheme-not-supported' status code. The Printer object MAY check to see if the document exists and is accessible. If the document is not found or is not accessible, REJECT/RETURN 'client-error-not found'.
クライアントがサプリしたURIスキームがサポートされていない場合、つまり、値がプリンターオブジェクトの参照された尿素帯にサポートされている属性にない場合、プリンターオブジェクトはリクエストを拒否し、 'client-error-uri-scheme-を返す必要があります。サポートされていない「ステータスコード。プリンターオブジェクトは、ドキュメントが存在し、アクセス可能かどうかを確認することができます。ドキュメントが見つからないか、アクセスできない場合は、「クライアントエラーなし」を拒否/返信します。
last-document (boolean)
ラストドキュメント（ブール）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'.
単一の「真」または単一の「false」「ブール」値のいずれでもない場合は、クライアントとエラーのバッドレクエスト 'を拒否/返却します。
IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client-error-request-value-too-long'
値の長さが1オクテットに等しくない場合は、 'client-error-request-value-too-long'を拒否/返信します
job-id (integer(1:MAX))
job-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オクテットに等しく、範囲1から最大値に等しくない場合、「クライアントとエラーバッドレクエスト」を拒否/返信します。
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.
既存のジョブオブジェクトのジョブIDではない場合は、最近削除されたジョブを追跡する場合、「クライアントエラーのない」または「クライアントとエラーグ」ステータスコードを拒否/返送してください。
requested-attributes (1setOf keyword)
リクエスト済み - アトリビュート（1setofキーワード）
IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-bad-request'.
1つ以上の「キーワード」値がない場合は、「クライアントとエラーバッドレクエスト」を拒否/返信します。
IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
Ignore unsupported values, which are the keyword names of unsupported attributes. Don't bother to copy such requested (unsupported) attributes to the Unsupported Attribute response group since the response will not return them.
サポートされていない属性のキーワード名であるサポートされていない値を無視します。応答が返されないため、そのような要求された（サポートされていない）属性をサポートされていない属性応答グループにコピーすることを気にしないでください。
which-jobs (type2 keyword)
どちらのジョブ（タイプ2キーワード）
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
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.
クライアントから提供されていない場合、IPPオブジェクトは「完了していない」値を想定しています。
my-jobs (boolean)
私のジョブ（ブール）
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, REJECT/RETURN 'client-error-bad-request'.
単一の「真」または単一の「false」「ブール」値のいずれでもない場合は、クライアントとエラーのバッドレクエスト 'を拒否/返却します。
IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client-error-request-value-too-long'
値の長さが1オクテットに等しくない場合は、 'client-error-request-value-too-long'を拒否/返信します
IF NOT supplied by the client, the IPP object assumes the 'false' value.
クライアントから提供されていない場合、IPPオブジェクトは「false」値を想定しています。
limit (integer(1:MAX))
制限（整数（1：最大））
IF NOT a single 'integer' value equal to 4 octets AND in the range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
単一の「整数」値が4オクテットに等しく、範囲1から最大値に等しく、「クライアントエラーバッドレクエスト」を拒否/返還します。
IF NOT supplied by the client, the IPP object returns all jobs, no matter how many.
クライアントから提供されていない場合、IPPオブジェクトはすべてのジョブを返します。
-----------------------------------------------
OPTIONAL Operation attributes are those that an IPP object MAY support. An IPP object validates the values of the OPTIONAL attributes supplied by the client. The IPP object performs the same syntactic validation checks for each OPTIONAL attribute value as in Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request-value-too-long' status code.
オプションの操作属性は、IPPオブジェクトがサポートできる属性です。IPPオブジェクトは、クライアントが提供するオプションの属性の値を検証します。IPPオブジェクトは、セクション3.1.2.1.5のように、各オプションの属性値に対して同じ構文検証チェックを実行します。セクション3.1.2.1.5のように、失敗した場合、IPPオブジェクトはリクエストを拒否し、「クライアントエラーバッドレクエスト」または「クライアントエラー - レクエスト値」ステータスコードを返します。
In addition, the IPP object checks each Operation attribute value against some Printer attribute or some hard-coded value if there is no "xxx-supported" Printer attribute defined. If its value is not among those supported or is not in the range supported, then the IPP object REJECTS the request and RETURNS the error status code indicated in the table. If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails.
さらに、IPPオブジェクトは、定義された「xxxサポートされた」プリンター属性がない場合、一部のプリンター属性またはハードコーディングされた値に対して各操作属性値をチェックします。その値がサポートされているものの中にない場合、またはサポートされている範囲にない場合、IPPオブジェクトはリクエストを拒否し、表に示されているエラーステータスコードを返します。プリンターオブジェクトの「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)
ドキュメント自然言語（naturallanguage）
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 'client-error-bad-request'.
単一の非空白の「naturallangage」値でない場合は、「client-error-bad-request」を拒否/返還してください。
IF the value length is greater than 63 octets, REJECT/RETURN 'client-error-request-value-too-long'.
値の長さが63オクテットを超える場合は、「クライアントエラーレクスト値」を拒否/返信します。
IF NOT a value that the Printer object supports in document formats, (no corresponding "xxx-supported" Printer attribute), REJECT/RETURN 'client-error-natural-language-not-supported'.
プリンターオブジェクトがドキュメント形式でサポートする値（対応する「XXXサポート」プリンター属性はありません）でなければ、「クライアントとエラーと自然の言語なし」を拒否/返信します。
compression (type3 keyword)
圧縮（タイプ3キーワード）
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF NOT in the Printer object's "compression-supported" attribute, REJECT/RETURN 'client-error-compression-not-supported'.
プリンターオブジェクトの「圧縮サポート」属性にない場合は、「クライアントとエラーの圧縮なし」を拒否/返信します。
Note to IPP/1.0 implementers: Support for the "compression" attribute was optional in IPP/1.0 and was changed to REQUIRED in IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the "compression" attribute being present and reject the create request, if they don't support "compression". Not checking is a bug, since the data will be unintelligible.
IPP/1.0の実装者への注意：「圧縮」属性のサポートはIPP/1.0でオプションであり、IPP/1.1で必要に応じて変更されました。ただし、IPP/1.0オブジェクトは、少なくとも「圧縮」属性が存在していることを確認し、「圧縮」をサポートしていない場合は作成要求を拒否する必要があります。データは理解できないため、チェックしないことはバグです。
job-k-octets (integer(0:MAX))
Job-K-Octets（整数（0：最大））
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
4オクテットに等しい単一の「整数」値がない場合は、「クライアントとエラーバッドレクエスト」を拒否/返還します。
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'.
プリンターオブジェクトの「job-k-octetsがサポートする」属性の範囲がない場合は、サポートされていない属性の応答グループに属性とサポートされていない値をコピーし、「client-error-attributes-or-values-not-を拒否/返信するサポート '。
job-impressions (integer(0:MAX))
ジョブインプレッション（整数（0：最大））
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
4オクテットに等しい単一の「整数」値がない場合は、「クライアントとエラーバッドレクエスト」を拒否/返還します。
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'.
プリンターオブジェクトの「ジョブインプレッションがサポートする」属性の範囲がない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーし、「クライアントエラーアトトリューズ - オアバリュー - サポートなし」を拒否/返信します。
job-media-sheets (integer(0:MAX))
ジョブメディアシート（整数（0：最大））
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
4オクテットに等しい単一の「整数」値がない場合は、「クライアントとエラーバッドレクエスト」を拒否/返還します。
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'.
プリンターオブジェクトの「ジョブメディアシートがサポートする」属性の範囲がない場合は、サポートされていない属性の応答グループに属性とサポートされていない値をコピーし、「クライアントエラーアトトリュースとバリューを拒否/返信します。サポート '。
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'.
値の長さが127オクテットを超えている場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
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.
そうでなければ、属性と値をサポートされていない属性応答グループにコピーし、属性値を「サポートされていない」値に変更しますが、属性を無視します。
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-INORED-OR-STITUTED-ATTRIBUTES」ステータスコードを返します。すべての操作におけるサポートされていない操作属性を無視することは、クライアントが「IPP-Attribute-Fideity」操作属性を「false」値に提供する場合、作成および検証JOB操作でサポートされていないジョブテンプレート属性の処理に類似しています。この最後のルールは、古いクライアントが新しいIPPオブジェクトとインターワークを行うことができ、新しいクライアントが古いIPPオブジェクトとインターワークできるように、IPPの将来のバージョンにオプションの操作属性を追加できるようにするためです。（予期せずに実行せずに新しい属性を無視できない場合、プロトコルドキュメントおよびリクエストでメジャーバージョン番号が増加していました）。操作属性に関するこのルールは、「IPP-Attribute-Fidelity」属性の値とは無関係です。たとえば、IPPオブジェクトがオプションの「job-k-octets "属性 'をサポートしていない場合、IPPオブジェクトは「job-k-octets」を未知の属性として扱い、「整数」属性syntaxの長さのみをチェックするクライアントから提供されます。4オクテットではない場合、IPPオブジェクトはリクエストを拒否し、「クライアントエラーバッドレケスト」ステータスコードを返します。バンド「「サポートされていない」値の帯域がありますが、それ以外の場合は属性を無視します。
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.
前のセクションと組み合わせたこのセクションでは、IPPオブジェクトが使用する必要のある印刷ジョブ、検証済みのジョブ、print-uri、create-job、send-document、およびsend-uri操作の処理手順を推奨します。これらは、ジョブを作成し、印刷ジョブリクエストを検証し、ジョブにドキュメントを追加する操作です。
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v No
3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
<supplied?> |
Yes| |
| ipp-attribute-fidelity = no |
|<------------------------------+
v No
3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
<accepting jobs?>
Yes|
v err
3.1.2.3 <Validate values of> --> client-error-bad-request
<Job template attributes> client-error-request-value-too-
long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.3 <Validate values with> --> client-error-bad-request
<supported values> client-error-attributes-or-
| values-not-supported
v err
3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
attributes
<Job Template attr values> client-error-attributes-or-
values-not-supported
v
The Printer object checks to see if the client supplied an "ipp-attribute-fidelity" Operation attribute. If the attribute is not supplied by the client, the IPP object assumes that the value is 'false'.
プリンターオブジェクトは、クライアントが「IPP-Attribute-Fidelity」操作属性を提供したかどうかを確認します。属性がクライアントによって提供されない場合、IPPオブジェクトは値が「false」であると想定しています。
If the value of the Printer objects "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code.
プリンターオブジェクトの「プリンター-is-accepting-jobs」の値が「false」である場合、プリンターオブジェクトはリクエストを拒否し、「サーバーエラーノットアクセプトジョブ」ステータスコードを返します。
An IPP object validates the values of all Job Template attribute supplied by the client. The IPP object performs the analogous syntactic validation checks of each Job Template attribute value that it performs for Operation attributes (see Section 3.1.2.1.5.):
IPPオブジェクトは、クライアントが提供するすべてのジョブテンプレート属性の値を検証します。IPPオブジェクトは、操作属性に対して実行される各ジョブテンプレート属性値の類似の構文検証チェックを実行します（セクション3.1.2.1.5を参照）：
a) that the length of each value is correct for the attribute syntax tag supplied by the client according to [RFC2911] Section 4.1.
a) 各値の長さは、[RFC2911]セクション4.1に従ってクライアントが提供する属性構文タグに対して正しいこと。
b) that the attribute syntax tag is correct for that attribute according to [RFC2911] Sections 4.2 to 4.4.
b) [RFC2911]セクション4.2から4.4に従って、属性構文タグがその属性に対して正しいこと。
c) that multiple values are supplied only for multi-valued attributes, i.e., that are 1setOf X according to [RFC2911] Sections 4.2 to 4.4.
c) 複数の値は、[RFC2911]セクション4.2から4.4に従って、マルチ値の属性、つまり1SetOf Xです。
As in Section 3.1.2.1.5, if any of these syntactic checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or 'client-error-request-value-too-long' status code as appropriate, independent of the value of the "ipp-attribute-fidelity". Since such an error is most likely to be an error detected by a client developer, rather than by an end-user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
セクション3.1.2.1.5のように、これらの構文チェックのいずれかが失敗した場合、IPPオブジェクトはリクエストを拒否し、「クライアントエラーバッドレクエスト」または「クライアントエラーレクストバリュー - ロング」ステータスを返します必要に応じて、「IPP-Attribute-Fideity」の価値とは無関係にコード。このようなエラーは、エンドユーザーではなく、クライアント開発者によって検出されるエラーである可能性が最も高いため、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:
各ジョブテンプレート属性は、1回しか発生しない必要があります。IPPプリンターが、ジョブテンプレート属性の複数の発生で作成要求を受信した場合、次の場合があります。
1. reject the operation and return the 'client-error-bad-request' error status code
1. 操作を拒否し、「クライアントエラーバッドレクエスト」エラーステータスコードを返します
2. accept the operation and use the first occurrence of the attribute
2. 操作を受け入れ、属性の最初の発生を使用します
3. accept the operation and use the last occurrence of the attribute
3. 操作を受け入れ、属性の最後の発生を使用します
depending on implementation. Therefore, clients MUST NOT supply multiple occurrences of the same Job Template attribute in the Job Attributes group in the request.
実装に応じて。したがって、クライアントは、リクエストでジョブ属性グループに同じジョブテンプレート属性の複数の発生を提供してはなりません。
The process of validating a Job-Template attribute "xxx" against a Printer attribute "xxx-supported" can use the following validation algorithm (see section 3.2.1.2 in [RFC2911]).
ジョブテンプレート属性「xxx」をプリンター属性「xxxサポート」に対して検証するプロセスは、次の検証アルゴリズムを使用できます（[RFC2911]のセクション3.2.1.2を参照）。
To validate the value U of Job-Template attribute "xxx" against the value V of Printer "xxx-supported", perform the following algorithm:
ジョブテンプレート属性の値uの値を検証するには、プリンター "xxx-supported"の値vに対して "xxx" "xxx"を実行するには、次のアルゴリズムを実行します。
1. If U is multi-valued, validate each value X of U by performing the algorithm in Table 7 with each value X. Each validation is separate from the standpoint of returning unsupported values. Example: If U is "finishings" that the client supplies with 'staple', 'bind' values, then X takes on the successive values: 'staple', then 'bind'
1. Uが多値の場合は、各値Xで表7でアルゴリズムを実行することにより、uの各値xを検証します。各検証は、サポートされていない値を返す立場とは別になります。例：uが「ステープル」、「バインド」値をクライアントが提供する「仕上げ」である場合、Xは「ステープル」、「バインド」という連続した値を引き受けます。
2. If V is multi-valued, validate X against each Z of V by performing the algorithm in Table 7 with each value Z. If a value Z validates, the validation for the attribute value X succeeds. If it fails, the algorithm is applied to the next value Z of V. If there are no more values Z of V, validation fails. Example" If V is "sides-supported" with values: 'one- sided', 'two-sided-long', and 'two-sided-short', then Z takes on the successive values: 'one-sided', 'two-sided-long', and 'two-sided-short'. If the client supplies "sides" with 'two-sided- long', the first comparison fails ('one-sided' is not equal to 'two-sided-long'), the second comparison succeeds ('two-sided-long' is equal to 'two-sided-long"), and the third comparison ('two-sided-short' with 'two-sided-long') is not even performed.
2. vが多値の場合、各値zで表7でアルゴリズムを実行することにより、Vの各zに対してxを検証します。値zが検証すると、属性値xの検証が成功します。失敗した場合、アルゴリズムはVの次の値zに適用されます。Vの値zがもうない場合、検証は失敗します。例「vが「片面」、「双方向」、および「両面短縮」を持つ「側面がサポートする」の場合、Zは連続した値を引き受けます：「片面」、「両面長」、および「両面短縮」。クライアントに「両側 - 長い」を「側面」に供給する場合、最初の比較は「片側」は「2つ」に等しくありません。Sided-Long '）、2番目の比較は成功します（「双方向長い」は「両面長」に等しい）、3番目の比較（「両面長'」を含む「両面ショート」）実行されません。
3. If both U and V are single-valued, let X be U and Z be V and use the validation rules in Table 7.
3. uとvの両方が単一値である場合、xとzとzをVとし、表7の検証ルールを使用します。
Table 7 - Rules for validating single values X against Z
表7- zに対して単一の値xを検証するためのルール
Attribute syntax attribute syntax validated if: of X of Z
属性構文属性構文検証if：of z of z
integer rangeOfInteger X is within the range of Z
Integer 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
any any X and Z are of the same type
and are equal.
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).
プリンターオブジェクトの「xxxサポート」属性の値が「価値のない」（システム管理者が値を構成していないため）の場合、チェックは常に失敗します。チェックが失敗した場合、IPPオブジェクトは、サポートされていない値を持つサポートされていない属性応答グループへの属性をコピーします。属性に複数の値が含まれている場合、各値がチェックされ、サポートされていない値が個別にコピーされ、サポート値はコピーされません。IPPオブジェクトがジョブテンプレート属性を認識/サポートしない場合、つまり、対応するプリンターオブジェクト「xxxサポート」属性がない場合、IPPオブジェクトは属性を未知またはサポートされていない属性として扱います（テーブルの最後の行を参照してください下に）。
If some Job Template attributes are supported for some document formats and not for others or the values are different for different document formats, the IPP object SHOULD take that into account in this validation using the value of the "document-format" supplied by the client (or defaulted to the value of the Printer's "document-format-default" attribute, if not supplied by the client). For example, if "number-up" is supported for the 'text/plain' document format, but not for the 'application/postscript' document format, the check SHOULD (though it NEED NOT) depend on the value of the "document-format" operation attribute. See "document-format" in [RFC2911] section 3.2.1.1 and 3.2.5.1.
一部のジョブテンプレート属性が一部のドキュメント形式でサポートされており、他のドキュメント形式ではない場合、または値が異なるドキュメント形式で異なる場合、IPPオブジェクトは、クライアントが提供する「ドキュメントフォーマット」の値を使用してこの検証でそれを考慮する必要があります（または、クライアントから提供されていない場合、プリンターの「ドキュメントフォーマットデフォルト」属性の値がデフォルトになりました）。たとえば、「Text/Plain」ドキュメント形式で「番号」がサポートされているが、「アプリケーション/ポストスクリプト」ドキュメント形式ではサポートされていない場合、チェックは（ただし必要ありませんが）「ドキュメントの値に依存する必要があります。-format "操作属性。[RFC2911]セクション3.2.1.1および3.2.5.1の「ドキュメントフォーマット」を参照してください。
Note: whether the request is accepted or rejected is determined by the value of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all Job Template attribute supplied are examined and all unsupported attributes and/or values are copied to the Unsupported Attributes response group.
注：リクエストが受け入れられるか拒否されたかは、後続のステップで「IPP-Attribute-Fidelity」属性の値によって決定されるかどうか、提供されるすべてのジョブテンプレート属性が調べられ、すべてのサポートされていない属性および/または値がコピーされます。サポートされていない属性応答グループ。
-----------------------------------------------
job-priority (integer(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
長さが4オクテットに等しい単一の「整数」値でない場合は、「クライアントエラーバッドレクエスト」を拒否/返還します。
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.
1〜100の範囲でない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
Map the value to the nearest supported value in the range 1:100 as specified by the number of discrete values indicated by the value of the Printer's "job-priority-supported" attribute. See the formula in [RFC2911] Section 4.2.1.
値を、プリンターの「ジョブ優先順位をサポートする」属性の値によって示される離散値の数で指定されている範囲1：100の最も近いサポート値にマッピングされます。[RFC2911]セクション4.2.1の式を参照してください。
job-hold-until (type3 keyword | name)
job-hold-until（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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
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.
プリンターオブジェクトの「ジョブホールドサポートされた」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
job-sheets (type3 keyword | name)
ジョブシート（タイプ3キーワード|名前）
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF NOT in the Printer object's "job-sheets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
プリンターオブジェクトの「ジョブシートがサポートする」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
multiple-document-handling (type2 keyword)
マルチドキュメントハンドリング（タイプ2キーワード）
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
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.
プリンターオブジェクトの「マルチドキュメントハンドリングサポート」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
copies (integer(1:MAX))
コピー（整数（1：最大））
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
長さが4オクテットに等しい単一の「整数」値でない場合は、「クライアントエラーバッドレクエスト」を拒否/返還します。
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.
サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
finishings (1setOf type2 enum)
仕上げ（1Setof Type2 Enum）
IF NOT an 'enum' value(s) each with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
長さが4オクテットに等しい「列挙」値ではない場合は、「クライアントエラーバッドレクエスト」を拒否/返却します。
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.
プリンターオブジェクトの「仕上げがサポートされている」属性にない場合は、サポートされていない値ではなく、属性とサポートされていない値をサポートされていない属性応答グループにコピーします。
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'.
8オクテットに等しい長さを持つ「範囲の範囲」値ではない場合、「クライアントとバッドのリケスト」を拒否/返還します。
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'.
最初の値が任意の範囲の2番目の値より大きい場合、範囲は昇順ではなく、範囲が重複して「クライアントとエラーバッドレクエスト」を拒否/返信します。
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.
プリンターオブジェクトの「ページレンジがサポートする」属性の値が「false」である場合、サポートされていない属性応答グループに属性をコピーし、値を「サポートされていない」値に設定します。
sides (type2 keyword)
サイド（タイプ2キーワード）
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF NOT in the Printer object's "sides-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
プリンターオブジェクトの「サイドサポートされた」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
number-up (integer(1:MAX))
数字（整数（1：最大））
IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
長さが4オクテットに等しい単一の「整数」値でない場合は、「クライアントエラーバッドレクエスト」を拒否/返還します。
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.
値ではない場合、またはプリンターオブジェクトの「番号付きサポート」属性の値の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'.
4オクテットに等しい長さの単一の「列挙」値でない場合は、「クライアントエラーバッドレクエスト」を拒否/返却します。
IF NOT in the Printer object's "orientation-requested-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
プリンターオブジェクトの「方向要求されたサポート」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
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'.
値の長さが255オクテットを超える場合は、「クライアントエラーとレクエストの価値」を拒否/返送してください。
IF NOT in the Printer object's "media-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
プリンターオブジェクトの「メディアサポート」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
printer-resolution (resolution)
プリンター解像度（解像度）
IF NOT a single 'resolution' value with a length equal to 9 octets, REJECT/RETURN 'client-error-bad-request'.
9オクテットに等しい長さの単一の「解像度」値がない場合は、「クライアントとエラーバッドレクエスト」を拒否/返還します。
IF NOT in the Printer object's "printer-resolution-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
プリンターオブジェクトの「プリンター解像度がサポートする」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
print-quality (type2 enum)
印刷品質（タイプ2列
IF NOT a single 'enum' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'.
4オクテットに等しい長さの単一の「列挙」値でない場合は、「クライアントエラーバッドレクエスト」を拒否/返却します。
IF NOT in the Printer object's "print-quality-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
プリンターオブジェクトの「印刷品質サポート」属性にない場合は、サポートされていない属性応答グループに属性とサポートされていない値をコピーします。
unknown or unsupported attribute (i.e., there is no corresponding Printer object "xxx-supported" attribute)
不明またはサポートされていない属性（つまり、対応するプリンターオブジェクト「xxx-supported」属性はありません）
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).
それ以外の場合、属性と値をサポートされていない属性応答グループにコピーし、属性値を「サポートされていない」値に変更します。残りのジョブテンプレート属性は、不明またはサポートされていないジョブテンプレート属性のいずれかであり、適切な長さの属性構文に従ってアルゴリズム的に検証されます（以下を参照）。
-----------------------------------------------
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'
Note: It's possible for a Printer to receive a zero length keyword in a request. Since this is a keyword, its value needs to be compared with the supported values. Assuming that the printer doesn't have any values in its corresponding "xxx-supported" attribute that are keywords of zero length, the comparison will fail. Then the request will be accepted or rejected depending on the value of "ipp-attributes-fidelity" being 'false' or 'true', respectively. No special handling is required for
注：プリンターがリクエストでゼロの長さキーワードを受信する可能性があります。これはキーワードであるため、その値をサポートされた値と比較する必要があります。プリンターに、長さがゼロのキーワードである対応する「xxxサポート」属性に値がないと仮定すると、比較は失敗します。次に、「IPP-Attributes-Fideity」の価値に応じて、それぞれ「偽」または「真」であることに応じて、要求が受け入れられたり拒否されたりします。特別な取り扱いは必要ありません
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.
すべての操作およびジョブテンプレート属性が個別にチェックされたら、プリンターオブジェクトは、クライアントが提供するすべてのサポートされた値の間で矛盾する値をチェックする必要があります。たとえば、プリンターオブジェクトは透明性に登録して印刷できる場合がありますが、物理的なステープル化の制約により、プリンターオブジェクトは透明度をホチキス止めできない場合があります。IPPオブジェクトは、サポートされている属性とその矛盾する属性値を、サポートされていない属性応答グループにコピーします。プリンターオブジェクトは、プリンターオブジェクトが競合を解決するために無視または代替のいずれかの属性をコピーするだけで、クライアントが提供した元の値を返します。たとえば、クライアントが「仕上げ」が「定番」に等しく、「メディア」が「透明度」に等しいと仮定しますが、プリンターオブジェクトはステープルの透明度をサポートしていません。プリンターが競合を解決するためにステープルング要求を無視することを選択した場合、プリンターオブジェクトは、サポートされていない属性応答グループの「ステープル」に等しい「仕上げ」を返します。属性が多値である場合、属性の矛盾する値のみがコピーされます。
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-Attribute-Fideity」属性を「真」値で提供した場合、プリンターオブジェクトはリクエストを拒否し、ステータスコードを返します。
1.'client-error-conflicting-attributes' status code, if there were any conflicts between attributes supplied by the client.
1.クライアントが提供する属性間に競合がある場合、'Client-Error-conflicting-aTtributesのステータスコード。
2.'client-error-attributes-or-values-not-supported' status code, otherwise.
2.'Client-error-attributes-or-values-supported 'ステータスコード、それ以外の場合。
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.
注：返されるサポートされていない操作属性または値は、このステップで返されたステータスに影響しません。サポートされていない操作属性が深刻なエラーである場合、上記は前のステップですでに要求を拒否しました。コントロールがこのステップに到達した場合、サポートされていない操作属性が返されている場合、それらは深刻なエラーではありません。
In general, the final results of Job processing are unknown at Job submission time. The client has to rely on notifications or polling to find out what happens at Job processing time. However, there are cases in which some Printers can determine at Job submission time that Job processing is going to fail. As an optimization, we'd like to have the Printer reject the Job in these cases.
一般に、ジョブ処理の最終結果は、求人の提出時に不明です。クライアントは、ジョブ処理時間で何が起こるかを知るために通知またはポーリングに依存する必要があります。ただし、一部のプリンターは、ジョブの処理が失敗することを求職時間で決定できる場合があります。最適化として、これらの場合にプリンターにジョブを拒否させたいと考えています。
There are three types of "processing" errors that might be detectable at Job submission time:
仕事の提出時に検出可能な3種類の「処理」エラーがあります。
1. 'client-error-document-format-not-supported' : For the Print-Job, Send-Document, Print-URI, and Send-URI operations, if all these conditions are true:
1. 'Client-Error-Document-format-not-Supported」：Print-job、send-document、print-uri、およびsend-uri操作の場合、これらすべての条件が真実である場合：
- the Printer supports auto-sensing, - the request "document-format" operation attribute is 'application/octet-stream', - the Printer receives document data before responding, - the Printer auto-senses the document format before responding,
- プリンターはオートセンシングをサポートします - リクエスト「ドキュメントフォーマット」操作属性は「アプリケーション/オクテットストリーム」です - プリンターは応答する前にドキュメントデータを受信します - プリンターは応答する前にドキュメント形式を自動センスします、
- the sensed document format is not supported by the Printer
- 検知されたドキュメント形式は、プリンターによってサポートされていません
then the Printer should respond with 'client-error-document-format-not-supported' status.
次に、プリンターは「クライアントエラードキュメントフォーマットとサポートされていない」ステータスで応答する必要があります。
2. 'client-error-compression-error': For the Print-Job, Send-Document, Print-URI, and Send-URI operations, if all these conditions are true:
2. 'Client-Error-Compression-error'：これらすべての条件が真実である場合、印刷ジョブ、送信ドキュメント、印刷物、および送信-URI操作の場合：
- the client supplies a supported value for the "compression" operation attribute in the request - the Printer receives document data before responding, - the Printer attempts to decompress the document data before responding, - the document data cannot be decompressed using the algorithm specified by the "compression" operation attribute
- クライアントは、リクエストの「圧縮」操作属性のサポートされた値を提供します - プリンターは応答する前にドキュメントデータを受信します - プリンターは応答する前にドキュメントデータを解凍しようとします - ドキュメントデータを使用してドキュメントデータを解凍できません。「圧縮」操作属性
then the Printer should respond with 'client-error-compression-error' status.
次に、プリンターは「クライアントエラーコンプレッションエラー」ステータスで応答する必要があります。
3. 'client-error-document-access-error': For the Print-URI, and Send-URI operations, if the Printer attempts and fails to pull the referenced document data before responding, it should respond with 'client-error-document-access-error' status.
3. 'client-error-document-access-error'：print-uriおよびsend-uri操作の場合、プリンターが応答する前に参照されたドキュメントデータを試していない場合、「client-error-document-で応答する必要があります。アクセスエラー 'ステータス。
Some Printers are not able to detect these errors until Job processing time. In that case, the errors are recorded in the corresponding job-state and job-state reason attributes. (There is no standard way for a client to determine whether a Printer can detect these errors at Job submission time.) For example, if auto-sensing happens AFTER the job is accepted (as opposed to auto-sensing at submit time before returning the response), the implementation aborts the job, puts the job in the 'aborted' state and sets the 'unsupported-document-format' value in the job's "job-state-reasons".
一部のプリンターでは、ジョブの処理時間までこれらのエラーを検出できません。その場合、エラーは、対応するジョブステートおよびジョブステートの理由属性に記録されます。（クライアントがプリンターが求人提出時にこれらのエラーを検出できるかどうかを判断する標準的な方法はありません。）たとえば、ジョブが受け入れられた後に自動検知が発生した場合（返品する前に提出時に自動検査とは対照的に応答）、実装は仕事を中止し、仕事を「中止」状態に置き、ジョブの「ジョブステートレゾン」に「サポートされていないドキュメント形式」価値を設定します。
A client should always provide a valid "document-format" operation attribute whenever practical. In the absence of other information, a client itself may sniff the document data to determine document format.
クライアントは、実用的にいつでも有効な「ドキュメント形式」操作属性を常に提供する必要があります。他の情報がない場合、クライアント自体がドキュメントデータを嗅ぎ、ドキュメント形式を決定する場合があります。
Auto sensing at Job submission time may be more difficult for the Printer when combined with compression. For auto-sensed Jobs, a client may be better off deferring compression to the transfer protocol layer, e.g.; by using the HTTP Content-Encoding header.
就職時間での自動センシングは、圧縮と組み合わせると、プリンターにとってより困難な場合があります。自動感染ジョブの場合、クライアントは、転送プロトコル層への圧縮を延期する方が良い場合があります。HTTPコンテンツエンコードヘッダーを使用します。
If the requested operation is the Validate-Job operation, the Printer object returns:
要求された操作がVALIDATE-JOB操作である場合、プリンターオブジェクトが返されます。
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. サポートされていないまたは競合するジョブテンプレートの属性または値がない場合、「成功した」ステータスコード。2.「成功した紛争の属性属性または値がある場合、「成功した紛争 - アトリビュート」。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.
注：返されるサポートされていない操作属性または値は、このステップで返されたステータスに影響しません。サポートされていない操作属性が深刻なエラーである場合、上記は前のステップですでに要求を拒否しました。コントロールがこのステップに到達した場合、サポートされていない操作属性が返されている場合、それらは深刻なエラーではありません。
If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by the client), the Printer object:
「IPP-Attribute-Fidelity」が「False」に設定されている場合（またはクライアントから提供されなかった）、プリンターオブジェクト：
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. ジョブオブジェクトを作成し、ジョブの「Job-URI」および「Job-ID」属性に一意の値を割り当て、ジョブの他のすべてのサポートされているジョブ説明属性を初期化します。2.ジョブオブジェクトからサポートされていないすべての属性を削除します。3.サポートされていない各値について、サポートされていない値を削除するか、サポートされていない属性値をサポートされた値に置き換えます。サポートされていない値を削除した後に属性に値がない場合、属性はジョブオブジェクトから削除されます（そのため、ジョブ処理時間での通常のデフォルト動作がその属性に対して行われます）。4.競合する価値ごとに、競合する値を削除するか、矛盾する属性値を他のサポートされた値に置き換えます。属性が競合する値を削除した後に値がない場合、属性はジョブオブジェクトから削除されます（そのため、ジョブ処理時間での通常のデフォルトの動作がその属性に対して行われます）。
If there were no attributes or values flagged as unsupported, or the value of 'ipp-attribute-fidelity" was 'false', the Printer object is able to accept the create request and create a new Job object. If the "ipp-attribute-fidelity" attribute is set to 'true', the Job Template attributes that populate the new Job object are necessarily all the Job Template attributes supplied in the create request. If the "ipp-attribute-fidelity" attribute is set to 'false', the Job Template attributes that populate the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. Thus, some of the requested Job Template attributes will not appear in the Job object because the Printer object did not support those attributes. The attributes that populate the Job object are persistently stored with the Job object for that Job. A Get-Job-Attributes operation on that Job object will return only those attributes that are persistently stored with the Job object.
サポートされていないものとしてフラグが付けられた属性または値がなかった場合、または「ipp-aTtribute-fidelity」の値が「false」だった場合、プリンターオブジェクトは作成要求を受け入れ、新しいジョブオブジェクトを作成できます。-fidelity "属性は「true」に設定されます。新しいジョブオブジェクトに入力するジョブテンプレート属性は、必然的に作成要求で提供されるすべてのジョブテンプレート属性です。、新しいジョブオブジェクトを埋めるジョブテンプレート属性はすべて、サポートされている、または価値のあるものがあるクライアントが提供するジョブテンプレート属性です。これらの属性をサポートします。ジョブオブジェクトに設定する属性は、そのジョブオブジェクトのジョブオブジェクトに永続的に保存されます。そのジョブオブジェクトのget-aTtributes操作は、ジョブオブジェクトに永続的に保存されている属性のみを返します。
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.
注：ジョブオブジェクトに永続的に保存されているすべてのジョブテンプレート属性は、「値をオーバーライドする」ことを目的としています。つまり、他の埋め込まれた命令がドキュメントデータ自体にあるものよりも優先されるものです。ただし、すべてのプリンターオブジェクトが「オーバーライド」のセマンティクスを実現することはできません。エンドユーザーは、プリンターの「PDL-Overrideサポート」属性を照会して、プリンターがIPP属性を使用してドキュメントデータ命令を上書きしようとしないかどうかを判断することができます。
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-Overrideがサポートする」属性の「試行」値をサポートする場合、これらのオーバーライド値はドキュメントデータ内で指定された値を置き換えることができます。これは、デフォルト値メカニズムの意図ではありません。属性のデフォルト値は、作成要求がその属性を指定しなかった場合にのみ使用されます（または、「ipp-aTtribute-fidelity」である「false」である場合に許可された場合に無視されました）。。
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:
ジョブオブジェクトが作成されると、プリンターオブジェクトはリクエストを受け入れ、クライアントに戻ります。
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. サポートされていないまたは競合するジョブテンプレートの属性または値がない場合、「成功した」ステータスコード。2.競合するジョブテンプレートの属性または値がある場合、「成功したOK執行装置」ステータスコード。3.サポートされていないジョブテンプレートの属性または値のみがある場合、「成功したOK-INORED-OR-STITUTED-ATTRIBUTES」ステータスコード。
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.
注：返されるサポートされていない操作属性または値は、このステップで返されたステータスに影響しません。サポートされていない操作属性が深刻なエラーである場合、上記は前のステップですでに要求を拒否しました。コントロールがこのステップに到達した場合、サポートされていない操作属性が返されている場合、それらは深刻なエラーではありません。
The Printer object also returns Job status attributes that indicate the initial state of the Job ('pending', 'pending-held', 'processing', etc.), etc. See Print-Job Response, [RFC2911] section 3.2.1.2.
また、プリンターオブジェクトは、ジョブの初期状態（「保留中」、「保留中」、「処理」などを示すジョブステータス属性も返します。印刷ジョブ応答、[RFC2911]セクション3.2.1.2を参照してください。。
The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing.
プリンターオブジェクトは、追加されたドキュメントコンテンツデータを受け入れ、印刷を開始するか、後で処理するためにスプールします。
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.
プリンターオブジェクトは、正しい処理順序でジョブをスケジュールするために、独自の構成および実装固有のアルゴリズムを使用します。プリンターオブジェクトがジョブの処理を開始すると、プリンターはジョブの状態を「処理」に変更します。プリンターオブジェクトがPDLオーバーライド（「PDL-Overrideサポート」属性が「Tiremed」に設定されている）をサポートする場合、実装は、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.
プリンターオブジェクトは、ジョブが「完了した」状態に移動できるまで、ジョブを処理し続けます。キャンセルジョブ操作が受信された場合、実装は最終的にジョブを「キャンセルされた」状態に移動します。処理中にシステムが完了した状態にジョブを進めることができないエラーに遭遇すると、実装はすべての処理を停止し、リソースをクリーンアップし、ジョブを「中止」状態に移動します。
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.
注：プリンターオブジェクトは、ジョブが破壊されてから十分に長い間「ジョブウリ」または「ジョブID」値を再利用してはなりません。新しい）ジョブ。
Some Printer object implementations may support "ipp-attribute-fidelity" set to 'true' and "pdl-override-supported" set to 'attempted' and yet still not be able to realize exactly what the client specifies in the create request. This is due to legacy decisions and assumptions that have been made about the role of job instructions embedded within the document data and external job instructions that accompany the document data and how to handle conflicts between such instructions. The inability to be 100% precise about how a given implementation will behave is also compounded by the fact that the two special attributes, "ipp-attribute-fidelity" and "pdl-"override-supported", apply to the whole job rather than specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for "number-up". Character Sets, natural languages, and internationalization
一部のプリンターオブジェクトの実装は、「True」および「PDL-Overrideがサポートする」に設定された「IPP-Attribute-Fideity」を「試行」に設定することをサポートする場合がありますが、クライアントが作成リクエストで指定するものを正確に理解することはできません。これは、ドキュメントデータに埋め込まれた職務指示の役割と、ドキュメントデータに伴う外部ジョブ命令と、そのような指示間の競合を処理する方法について行われた遺産の決定と仮定によるものです。特定の実装がどのように振る舞うかについて100％正確にすることができないことは、2つの特別な属性「IPP-Attribute-Fidelity」と「PDL-」がサポートされている」という事実によって、仕事全体に適用されるという事実によっても悪化します。各属性の特定の値。たとえば、一部の実装では、「番号」を除くほとんどすべてのジョブテンプレート属性をオーバーライドできる場合があります。文字セット、自然言語、国際化
This section discusses character set support, natural language support and internationalization.
このセクションでは、キャラクターセットのサポート、自然言語サポート、国際化について説明します。
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and indicate that UTF-8 and US-ASCII are supported by populating the Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An IPP object is required to code covert with as little loss as possible between the charsets that it supports, as indicated in the Printer's "charsets-supported" attribute.
UTF-8をサポートするには、IPPクライアントとIPPオブジェクトが必要です。追加の充電器をサポートする場合があります。多くのクライアントがUS-ASCIIをサポートしているため、IPPオブジェクトもUS-ASCIIをサポートし、UTF-8とUS-ASCIIが「UTF-8」と 'にプリンターの「チャーセットサポート」を埋めることによってサポートされていることを示すことをお勧めします。us-ascii '値。IPPオブジェクトは、プリンターの「充電セットがサポートする」属性に示されているように、サポートする充電の間にできるだけ損失をできるだけ損失しないカバーをコードする必要があります。
How should the server handle the situation where the "attributes-charset" of the response itself is "us-ascii", but one or more attributes in that response is in the "utf-8" format?
サーバーは、応答自体の「属性」自体が「us-ascii」である状況をどのように処理する必要がありますが、その応答の1つ以上の属性は「utf-8」形式です。
Example: Consider a case where a client sends a Print-Job request with "utf-8" as the value of "attributes-charset" and with the "job-name" attribute supplied. Later another client submits a Get-Job-Attribute or Get-Jobs request. This second request contains the "attributes-charset" with value "us-ascii" and "requested-attributes" attribute with exactly one value "job-name".
例：クライアントが「UTF-8」を「属性 - チャージセット」の値として、および「ジョブ名」属性の値として「UTF-8」で印刷ジョブリクエストを送信する場合を検討してください。その後、別のクライアントがGet-Job-AttributeまたはGet-Jobsリクエストを提出します。この2番目の要求には、値「us-ascii」と「要求されたアトリビュート」属性を持つ「属性 - チャージセット」が含まれています。
According to the RFC2911 document (section 3.1.4.2), the value of the "attributes-charset" for the response of the second request must be "us-ascii" since that is the charset specified in the request. The "job-name" value, however, is in "utf-8" format. Should the request be rejected even though both "utf-8" and "us-ascii" charsets are supported by the server? or should the "job-name" value be converted to "us-ascii" and return "successful-ok-conflicting-attributes" (0x0002) as the status code?
RFC2911ドキュメント（セクション3.1.4.2）によると、2番目の要求の応答の「属性 - チャージセット」の値は「US-ASCII」でなければなりません。これは要求で指定されている請求書であるためです。ただし、「ジョブ名」値は「UTF-8」形式です。「UTF-8」と「US-ASCII」の両方の充電器がサーバーによってサポートされている場合でも、リクエストを拒否すべきですか？または、「ジョブ名」値を「us-ascii」に変換し、ステータスコードとして「成功したOK紛争 - アトリビュート」（0x0002）を返す必要がありますか？
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'.
回答：UTF-8（必須）とUS-ASCIIの両方をサポートするIPPオブジェクトは、セクション3.1.4.2の2番目の段落が適用されるため、IPPオブジェクトはリクエストを受け入れ、これら2つのcharセット間のコードセット変換を実行する必要があります。忠実度は、「成功した「OK」を「成功」している「成功」を「成功」します。プリンターは、それがサポートする各キャラクターセット間で変換するために最善を尽くします - たとえそれが米国のASCIIで表現できないため、一連の疑問符を提供することを意味します。そのような変換を実行できない場合、US-ASCIIを「属性-Charset-Supported」の値として宣伝してはなりません。
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オブジェクトの実装戦略の1つは、すべての要求テキストと名前の値を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: 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.
セクション3.1.4.1要求操作属性は、1998年11月に次のように明確にされました。すべてのクライアントとIPPオブジェクトは、「UTF-8」チャーセット[RFC2044]をサポートする必要があり、IANA [IANA-CS]に登録されている場合、追加の炭みをサポートする必要があります。プリンターオブジェクトがクライアントのcharset値をサポートしていない場合、プリンターオブジェクトはリクエストを拒否し、応答で「属性 - charset」を「utf-8」に設定し、 'client-error-charset-not-を返しなければなりません。「UTF-8」チャーセットを使用して、「ステータスコードと「テキスト」または「名前」属性がサポートされています。
Since the client and IPP object MUST support UTF-8, returning any text or name attributes in UTF-8 when the client requests a charset that is not supported should allow the client to display the text or name.
クライアントとIPPオブジェクトはUTF-8をサポートする必要があるため、クライアントがサポートされていないチャーセットを要求する場合、UTF-8のテキストまたは名前の属性を返します。クライアントがテキストまたは名前を表示できるようにする必要があります。
Since such an error is a client error, rather than a user error, the client should check the status code first so that it can avoid displaying any other returned 'text' and 'name' attributes that are not in the charset requested.
このようなエラーはユーザーエラーではなくクライアントエラーであるため、クライアントは最初にステータスコードをチェックして、リクエストされていない他の「テキスト」および「名前」属性が要求されていない属性を表示しないようにする必要があります。
Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-supported (0x040D) was clarified in November 1998 as follows:
さらに、[RFC2911]セクション14.1.4.14クライアントエラーセットなし（0x040d）は、次のように1998年11月に明確にされました。
For any operation, if the IPP Printer does not support the charset supplied by the client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status and any 'text' or 'name' attributes using the 'utf-8' charset (see Section 3.1.4.1).
任意の操作の場合、IPPプリンターが「属性 - チャージセット」操作属性でクライアントが提供するcharSetをサポートしていない場合、プリンターは操作を拒否し、このステータスと「テキスト」または「名前」属性を使用して返す必要があります。UTF-8 'チャーセット（セクション3.1.4.1を参照）。
The 'text' and 'name' attributes each have two forms. One has an implicit natural language, and the other has an explicit natural language. The 'textWithoutLanguage' and 'textWithLanguage' are the two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are the two 'name' forms. If a receiver (IPP object or IPP client) supports an attribute with attribute syntax 'text', it MUST support both forms in a request and a response. A sender (IPP client or IPP object) MAY send either form for any such attribute. When a sender sends a WithoutLanguage form, the implicit natural language is specified in the "attributes-natural-language" operation attribute, which all senders MUST include in every request and response.
「テキスト」と「名前」属性には、それぞれ2つのフォームがあります。1つは暗黙の自然言語を持ち、もう1つは明示的な自然言語を持っています。「TextWithOutLanguage」と「TextWithLanguage」は、2つの「テキスト」フォームです。「namewithoutlanguage」と「namewithlanguageは2つの「名前」フォームです。受信機（IPPオブジェクトまたはIPPクライアント）が属性構文「テキスト」を持つ属性をサポートする場合、リクエストと応答で両方のフォームをサポートする必要があります。IPPクライアントまたはIPPオブジェクト）は、そのような属性に対していずれかのフォームを送信できます。送信者が言語の形式を送信する場合、暗黙の自然言語は「属性と自然言語」操作属性で指定されます。応答。
When a sender sends a WithLanguage form, it MAY be different from the implicit natural language supplied by the sender or it MAY be the same. The receiver MUST treat either form equivalently.
送信者がwithlanguageフォームを送信する場合、送信者が提供する暗黙の自然言語とは異なる場合があります。受信者は、どちらかを同等に処理する必要があります。
There is an implementation decision for senders, whether to always send the WithLanguage forms or use the WithoutLanguage form when the attribute's natural language is the same as the request or response.
属性の自然言語が要求または応答と同じである場合、常にwithlanguageフォームを送信するか、withoutlanguageフォームを使用するか、送信者には実装決定があります。
The former approach makes the sender implementation simpler. The latter approach is more efficient on the wire and allows inter-working with non-conforming receivers that fail to support the WithLanguage forms. As each approach have advantages, the choice is completely up to the implementer of the sender.
以前のアプローチにより、送信者の実装がより簡単になります。後者のアプローチは、ワイヤーでより効率的であり、withlanguageフォームをサポートできない不適合なレシーバーとの相互作用を可能にします。各アプローチには利点があるため、選択は完全に送信者の実装者次第です。
Furthermore, when a client receives a 'text' or 'name' job attribute that it had previously supplied, that client MUST NOT expect to see the attribute in the same form, i.e., in the same WithoutLanguage or WithLanguage form as the client supplied when it created the job. The IPP object is free to transform the attribute from the WithLanguage form to the WithoutLanguage form and vice versa, as long as the natural language is preserved. However, in order to meet this latter requirement, it is usually simpler for the IPP object implementation to store the natural language explicitly with the attribute value, i.e., to store using an internal representation that resembles the WithLanguage form.
さらに、クライアントが以前に提供していた「テキスト」または「名前」ジョブ属性を受け取ると、そのクライアントは同じ形式、つまり言語のない、またはクライアントが提供したときと同じ形で属性を表示することを期待してはなりません。それは仕事を生み出しました。IPPオブジェクトは、自然言語が保存されている限り、属性をwithlanguageフォームからwithoutlanguage形式から、その逆に自由に変換できます。ただし、この後者の要件を満たすためには、通常、IPPオブジェクトの実装が属性値で自然言語を明示的に保存すること、つまり、withlanguageフォームに似た内部表現を使用して保存することがより簡単です。
The IPP Printer MUST copy the natural language of a job, i.e., the value of the "attributes-natural-language" operation attribute supplied by the client in the create operation, to the Job object as a Job Description attribute, so that a client is able to query it. In returning a Get-Job-Attributes response, the IPP object MAY return one of three natural language values in the responses "attributes-natural-language" operation attribute: (1) that requested by the requester, (2) the natural language of the job, or (3) the configured natural language of the IPP Printer, if the requested language is not supported by the IPP Printer.
IPPプリンターは、ジョブの自然言語、つまり、クライアントがクライアントが提供する「属性 - 自然言語」操作属性の値を、ジョブオブジェクトにジョブオブジェクトに属性として、クライアントがコピーする必要があります。それを照会することができます。Get-job-aTtributes Responseを返す際、IPPオブジェクトは、応答の3つの自然言語値のいずれかを「属性」操作属性を返すことができます。要求された言語がIPPプリンターによってサポートされていない場合、ジョブ、または（3）IPPプリンターの構成された自然言語。
This "attributes-natural-language" Job Description attribute is useful for an IPP object implementation that prints start sheets in the language of the user who submitted the job. This same Job Description attribute is useful to a multi-lingual operator who has to communicate with different job submitters in different natural languages. This same Job Description attribute is expected to be used in the future to generate notification messages in the natural language of the job submitter.
この「属性 - 自然言語」の職務記述書属性は、ジョブを提出したユーザーの言語で開始シートを印刷するIPPオブジェクトの実装に役立ちます。この同じ職務記述書属性は、異なる自然言語で異なる職務提出者と通信しなければならない多言語オペレーターに役立ちます。この同じ職務記述書の属性は、将来、ジョブ提出者の自然言語で通知メッセージを生成するために使用されることが期待されています。
Early drafts of [RFC2911] contained a job-level natural language override (NLO) for the Get-Jobs response. A job-level (NLO) is an (unrequested) Job Attribute which then specified the implicit natural language for any other WithoutLanguage job attributes returned in the response for that job. Interoperability testing of early implementations showed that no one was implementing the job-level NLO in Get-Job responses. So the job-level NLO was eliminated from the Get-Jobs response. This simplification makes all requests and responses consistent in that the implicit natural language for any WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute.
[RFC2911]の初期ドラフトには、Get-Jobs応答のための職務レベルの自然言語オーバーライド（NLO）が含まれていました。ジョブレベル（NLO）は、そのジョブの応答で返された言語なしのジョブ属性の暗黙的な自然言語を指定した（レクストなしの）ジョブ属性です。早期実装の相互運用性テストにより、誰もGet-Job応答でジョブレベルのNLOを実装していないことが示されました。したがって、ジョブレベルのNLOは、Get-Jobsの応答から排除されました。この単純化により、すべてのリクエストと応答が一貫しています。なぜなら、言語の「テキスト」または「名前」フォームの暗黙の自然言語は、リクエストまたは応答の「属性 - 自然言語」操作属性に常に提供されます。
This section corresponds to [RFC2911] section 3.1.6 "Operation Response Status Codes and Status Messages". This section lists all status codes once in the first operation (Print-Job). Then it lists the status codes that are different or specialized for subsequent operations under each operation.
このセクションは、[RFC2911]セクション3.1.6「操作応答ステータスコードとステータスメッセージ」に対応しています。このセクションには、最初の操作（print-job）ですべてのステータスコードが一度リストされます。次に、各操作の下での後続の操作に異なるまたは専門化されたステータスコードをリストします。
The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 13 in [RFC2911] for a more complete description of each status code.
プリンターオブジェクトは、指定された理由で次の「ステータスコード」値のいずれかを返す必要があります。成功またはエラー応答を返す前に、すべてのドキュメントデータが受け入れられているかどうかは、実装に依存します。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the Job object has been created and the "job-id", and "job-uri" assigned and returned in the response:
次の成功ステータスコードでは、ジョブオブジェクトが作成され、「ジョブID」と「ジョブURI」が割り当てられて返されます。
successful-ok: no request attributes were substituted or ignored.
成功したOK：リクエスト属性は置換または無視されませんでした。
successful-ok-ignored-or-substituted-attributes: some supplied (1) attributes were ignored or (2) unsupported attribute syntaxes or values were substituted with supported values or were ignored. Unsupported attributes, attribute syntax's, or values MUST be returned in the Unsupported Attributes group of the response.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：いくつかの提供された（1）属性は無視されたか、（2）サポートされていない属性の構文または値は、サポートされた値で置き換えられるか、無視されました。サポートされていない属性、属性構文、または値は、サポートされていない属性グループで返される必要があります。
successful-ok-conflicting-attributes: some supplied attribute values conflicted with the values of other supplied attributes and were either substituted or ignored. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response as supplied by the client.
成功したOK紛争 - アトリビュート：提供された属性値の一部は、他の供給された属性の値と矛盾し、置換または無視されました。他の属性と競合し、置換または無視された属性または値は、クライアントが提供する応答のサポートされていない属性グループで返品する必要があります。
[RFC2911] section 3.1.6 Operation Status Codes and Messages states:
[RFC2911]セクション3.1.6操作ステータスコードとメッセージの記述：
If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 13 in [RFC2911]): 'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server- error-operation-not-supported', and 'server-error-version-not-supported'. In this case, it MUST set the value of the "attributes-charset" operation attribute to 'utf-8' in the error response.
プリンターオブジェクトが「ステータスメサージ」操作属性をサポートする場合、必要な「UTF-8」チャーセットを使用して、次のエラーステータスコードのステータスメッセージを返す必要があります（[RFC2911]のセクション13を参照）： 'クライアントエラー-bad-request '、' client-error-charset-not-supported '、' server-error-internal-error '、' server-error-operation-not-supported '、' server-error-version-not-サポート '。この場合、エラー応答で「属性 - チャージセット」操作属性の値を「UTF-8」に設定する必要があります。
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-Bad-Request：リクエスト構文は、仕様に準拠していません。
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.
クライアントエラーフォーブドメッド：承認または認証の理由でリクエストが拒否されています。実装セキュリティポリシーは、失敗が認証または認証の1つであるかどうかを明らかにしないことです。
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-authenticated：リクエストでは、認証情報を提供する必要があるか、認証情報が許可に十分ではありません。
client-error-not-authorized: The requester is not authorized to perform the request on the target object.
Client-Error -Not-authorized：requesterは、ターゲットオブジェクトでリクエストを実行することを許可されていません。
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-Not-Possible：システムの状態のためにリクエストを実行することはできません。 「Server-error-not-accepting-jobs」ステータスコードも参照してください。これは、プリンターオブジェクトの「プリンター受容」属性が「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-Gone：ターゲットオブジェクトは存在しなくなり、転送アドレスが既知ではありません。
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-Entity-Too-Large：リクエストおよび/または印刷データのサイズは、IPPプリンターの処理容量を超えています。
client-error-request-value-too-long: the size of request variable length attribute values, such as 'text' and 'name' attribute syntax's, exceed the maximum length specified in [RFC2911] for the attribute and MUST be returned in the Unsupported Attributes Group.
クライアント-RREROR-REQUEST-VALUE-TOO-LONG：「テキスト」や「名前」属性の構文などのリクエスト変数の長さ属性値のサイズは、属性の[RFC2911]で指定された最大長を超え、で返される必要があります。サポートされていない属性グループ。
supplied is not supported. The "document-format" attribute with the unsupported value MUST be returned in the Unsupported Attributes Group. This error SHOULD take precedence over any other 'xxx-not-supported' error, except 'client-error-charset-not-supported'.
供給はサポートされていません。サポートされていない値を持つ「ドキュメント形式」属性は、サポートされていない属性グループで返される必要があります。このエラーは、「クライアントとエラーセットなしのサポート」を除き、他の「xxx-not-not-supported」エラーよりも優先されるはずです。
client-error-attributes-or-values-not-supported: one or more supplied attributes, attribute syntax's, or values are not supported and the client supplied the "ipp-attributes-fidelity" operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below.
クライアントエラーアトリブス - オアバリュー - サポートされていない：1つ以上の提供された属性、属性構文、または値はサポートされておらず、クライアントは「IPP-Attributes-Fideity」操作属性を「真の」値で提供しました。以下で説明するように、それらはサポートされていない属性グループに戻す必要があります。
client-error-uri-scheme-not-supported: not applicable.
client-error-uri-scheme-not-supported：該当なし。
client-error-charset-not-supported: the charset supplied in the "attributes-charset" operation attribute is not supported. The Printer's "configured-charset" MUST be returned in the response as the value of the "attributes-charset" operation attribute and used for any 'text' and 'name' attributes returned in the error response. This error SHOULD take precedence over any other error, unless the request syntax is so bad that the client's supplied "attributes-charset" cannot be determined.
クライアントエラーセットなしサポート：「属性 - チャールセット」操作属性で提供されるcharsetはサポートされていません。プリンターの「構成済み - charset」は、「属性」操作属性の値として応答で返され、エラー応答で返される「テキスト」および「名前」属性に使用する必要があります。リクエストの構文が非常に悪いため、クライアントが提供した「属性 - チャーセット」を決定できない場合を除き、このエラーは他のエラーよりも優先されるはずです。
client-error-conflicting-attributes: one or more supplied attribute values conflicted with each other and the client supplied the "ipp-attributes-fidelity" operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below.
クライアントとエラーの紛争 - アトリビュート：1つ以上の提供された属性値が互いに矛盾し、クライアントは「IPP-Attributes-Fideity」操作属性を「真の」値で提供しました。以下で説明するように、それらはサポートされていない属性グループに戻す必要があります。
server-error-internal-error: an unexpected condition prevents the request from being fulfilled.
Server-Error-Internal-Error：予期しない条件により、リクエストが満たされないようにします。
server-error-operation-not-supported: not applicable (since Print-Job is REQUIRED).
Server-Error-operation-not-supported：該当なし（印刷ジョブが必要なため）。
server-error-service-unavailable: the service is temporarily overloaded.
Server-Error-Service-Available：サービスは一時的に過負荷になっています。
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-version-not-supported：リクエストのバージョンはサポートされていません。サポートされている「最も近い」バージョン番号は、応答で返される必要があります。
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-device-error：リクエストまたはドキュメントデータの受信またはスプール中にデバイスエラーが発生するか、IPPプリンターオブジェクトは一度に1つのジョブのみを受け入れることができます。
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-tempolary-error：バッファーの完全な書き込みエラー、メモリオーバーフロー、またはリクエストおよび/またはドキュメントデータの受信中にディスクの完全な状態などの一時的なエラーが発生しました。
server-error-not-accepting-jobs: the Printer object's "printer-is-not-accepting-jobs" attribute is 'false'.
Server-error-not-accepting-jobs：プリンターオブジェクトの「プリンター - ノットアクセプトジョブ」属性は「false」です。
server-error-busy: the Printer is too busy processing jobs to accept another job at this time.
Server-Error-Busy：プリンターは、ジョブの処理に忙しすぎて、現時点では別のジョブを受け入れることができません。
server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the document data.
Server-Error-Job-Canceled：クライアントがドキュメントデータを送信している間、ジョブはオペレーターまたはシステムによってキャンセルされました。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Print-URI with the following specializations and differences. See Section 14 for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、次の専門分野と違いを伴う印刷物に適用できます。各ステータスコードのより完全な説明については、セクション14を参照してください。
client-error-uri-scheme-not-supported: the URI scheme supplied in the "document-uri" operation attribute is not supported and is returned in the Unsupported Attributes group.
クライアントエラー-URI-Scheme-Not-Supported：「Document-URI」操作属性で提供されるURIスキームはサポートされておらず、サポートされていない属性グループで返されます。
server-error-operation-not-supported: the Print-URI operation is not supported.
Server-Error-operation-supported：印刷-RI操作はサポートされていません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Validate-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、検証JOBに適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Create-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、次の専門化と違いを伴うCreate-Jobに適用できます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
server-error-operation-not-supported: the Create-Job operation is not supported.
Server-Error-operation-supported：Create-Job操作はサポートされていません。
client-error-multiple-document-jobs-not-supported: while the Create-Job and Send-Document operations are supported, this implementation doesn't support more than one document with data.
Client-Multiple-Document-Jobs-Not-Supported：Create-JobおよびSend-Document操作はサポートされていますが、この実装はデータを使用して複数のドキュメントをサポートしていません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specialization's and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されている印刷ジョブステータスコードはすべて、次の専門化と違いを伴うGet-Printer-Attributes操作に適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
次の成功ステータスコードについて、要求された属性は、応答のグループ3で返されます。
successful-ok: no operation attributes or values were substituted or ignored (same as Print-Job) and no requested attributes were unsupported.
成功：操作の属性や値は置き換えられたり無視されたりしませんでした（印刷ジョブと同じ）、要求された属性はサポートされていません。
successful-ok-ignored-or-substituted-attributes: The "requested-attributes" operation attribute MAY, but NEED NOT, be returned with the unsupported values.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：「要求されたアトリビュート」操作属性は、サポートされていない値で返される場合がありますが、必要ではありません。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
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-Not-Possible：Print-Jobと同じ、さらにプリンターオブジェクトはリクエストを受け入れていません。
client-error-request-entity-too-large: same as Print-job, except that no print data is involved.
クライアントエラーレクエストエンティティ - と主張：印刷データが含まれていないことを除いて、印刷ジョブと同じです。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).
クライアントエラーアトリビュートオアバリュー - サポートなし：サポートされていない操作の属性および/または値を無視し、適切な成功コードを返す必要があるため、該当しません（上記を参照）。
client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved.
クライアントエラーの紛争 - アトリビュート：「IPP-Attribute-Fideity」が関与していないことを除いて、印刷ジョブと同じです。
server-error-operation-not-supported: not applicable (since Get-Printer-Attributes is REQUIRED).
Server-Error-Operation-Not-Supported：該当なし（Get-Printer-Attributesが必要なため）。
server-error-device-error: same as Print-Job, except that no document data is involved.
Server-error-device-error：文書データが関係していないことを除いて、印刷ジョブと同じです。
server-error-temporary-error: same as Print-Job, except that no document data is involved.
Server-Error-tempolary-error：文書データが含まれていないことを除いて、印刷ジョブと同じです。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-busy: same as Print-Job, except the IPP object is too busy to accept even query requests.
Server-Error-Busy：IPPオブジェクトが忙しすぎてクエリリクエストを受け入れることができないことを除いて、print-jobと同じです。
server-error-job-canceled: not applicable.
Server-error-jobcanceled：該当なし。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to the Get-Jobs operation with the following specialization's and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されている印刷ジョブステータスコードはすべて、次の専門化と違いを伴うGet-Jobs操作に適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
次の成功ステータスコードについて、要求された属性は、応答のグループ3で返されます。
successful-ok: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功：Get-Printer-Attributesと同じ（セクション3.1.3.1.5を参照）。
successful-ok-ignored-or-substituted-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Get-Printer-Attributesと同じ（セクション3.1.3.1.5を参照）。
successful-ok-conflicting-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功したOK紛争 - アトリビュート：Get-Printer-Attributesと同じ（セクション3.1.3.1.5を参照）。
For any error status codes, Group 3 is returned containing no attributes or is not returned at all. The following brief error status code descriptions contain unique information for use with Get-Jobs operation. See section 14 for the other error status codes that apply uniformly to all operations:
エラーステータスコードの場合、グループ3は属性が含まれていないか、まったく返されません。次の簡単なエラーステータスコードの説明には、Get-Jobs操作で使用するための一意の情報が含まれています。すべての操作に均一に適用される他のエラーステータスコードについては、セクション14を参照してください。
client-error-not-possible: Same as Print-Job, in addition the Printer object is not accepting any requests.
Client-Error-Not-Possible：Print-Jobと同じ、さらにプリンターオブジェクトはリクエストを受け入れていません。
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-document-format-not-supported：該当なし。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).
クライアントエラーアトリビュートオアバリュー - サポートなし：サポートされていない操作の属性および/または値を無視し、適切な成功コードを返す必要があるため、該当しません（上記を参照）。
client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved.
クライアントエラーの紛争 - アトリビュート：「IPP-Attribute-Fideity」が関与していないことを除いて、印刷ジョブと同じです。
server-error-operation-not-supported: not applicable (since Get-Jobs is REQUIRED).
Server-Error-operation-not-supported：該当なし（get-jobsが必要なため）。
server-error-device-error: same as Print-Job, except that no document data is involved.
Server-error-device-error：文書データが関係していないことを除いて、印刷ジョブと同じです。
server-error-temporary-error: same as Print-Job, except that no document data is involved.
Server-Error-tempolary-error：文書データが含まれていないことを除いて、印刷ジョブと同じです。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-job-canceled: not applicable.
Server-error-jobcanceled：該当なし。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Pause-Printer with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、次の専門分野と違いを伴う一時停止プリンターに適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the Printer object is being stopped from scheduling jobs on all its devices.
次の成功ステータスコードでは、プリンターオブジェクトがすべてのデバイスでジョブのスケジューリングを停止しています。
successful-ok: no request attributes were substituted or ignored (same as Print-Job).
成功したOK：リクエスト属性は置換または無視されませんでした（print-jobと同じ）。
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Print-Jobと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
For any of the error status codes, the Printer object has not been stopped from scheduling jobs on all its devices.
エラーステータスコードのいずれかについて、プリンターオブジェクトは、すべてのデバイスでジョブのスケジュールを停止していません。
client-error-not-possible: not applicable.
Client-Error-Not-Possible：該当なし。
client-error-not-found: the target Printer object does not exist.
クライアントとエラーのないもの：ターゲットプリンターオブジェクトは存在しません。
client-error-gone: the target Printer object no longer exists and no forwarding address is known.
Client-Error-Gone：ターゲットプリンターオブジェクトは存在しなくなり、転送アドレスがわかっていません。
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-document-format-not-supported：該当なし。
client-error-conflicting-attributes: same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved.
クライアントとエラーの紛争 - アトリビュート：プリンターの「プリンター-is-Is-accepting-jobs」属性が関与していないことを除いて、print-jobと同じです。
server-error-operation-not-supported: the Pause-Printer operation is not supported.
Server-Error-operation-supported：Pause-Printer操作はサポートされていません。
server-error-device-error: not applicable.
Server-error-device-error：該当なし。
server-error-temporary-error: same as Print-Job, except no document data is involved.
Server-Error-tempolary-error：ドキュメントデータが含まれていないことを除いて、print-jobと同じです。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-job-canceled: not applicable.
Server-error-jobcanceled：該当なし。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Pause-Printer are applicable to Resume-Printer. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1のPrint-Jobステータスコードのすべての説明は、Pause-Printerについて説明されている専門化を備えたPrint-Job応答を履歴書 - プリンターに適用できます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the Printer object resumes scheduling jobs on all its devices.
次の成功ステータスコードでは、プリンターオブジェクトはすべてのデバイスのジョブのスケジュールを再開します。
successful-ok: no request attributes were substituted or ignored (same as Print-Job).
成功したOK：リクエスト属性は置換または無視されませんでした（print-jobと同じ）。
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Print-Jobと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
For any of the error status codes, the Printer object does not resume scheduling jobs.
エラーステータスコードのいずれかについて、プリンターオブジェクトはスケジューリングジョブを再開しません。
server-error-operation-not-supported: the Resume-Printer operation is not supported.
Server-Error-operation-supported：resume-Printer操作はサポートされていません。
If, in case, the IPP printer is unable to change its state due to some problem with the actual printer device (say, it is shut down or there is a media-jam as indicated in [RFC2911]), what should be the result of the "Resume-Printer" operation? Should it still change the 'printer-state-reasons' and return success or should it fail ?
場合に備えて、実際のプリンターデバイスに問題があるためにIPPプリンターが状態を変更できない場合（たとえば、シャットダウンされているか、[RFC2911]に示されているメディアジャムがあります）、結果はどうなりますか？「resume-printer」操作の？それはまだ「プリンターステートレゾン」を変更し、成功を返す必要がありますか、それとも失敗する必要がありますか？
The Resume-Printer operation must clear the 'paused' or 'moving-to-paused' 'printer-state-message'. The operation must return a 'successful-ok' status code.
Resume-Printer操作は、「一時停止」または「移動する」「プリンター状態のようなもの」をクリアする必要があります。操作は、「成功したOK」ステータスコードを返す必要があります。
If the Resume-Printer operation succeeds, what should be the value of "printer-state" and who should take care of the "printer-state" attribute value later on ?
Resume-Printerの操作が成功した場合、「プリンター状態」の価値はどうあるべきであり、後で「プリンター状態」属性値を世話する必要があるのは誰ですか？
The Resume-Printer operation may change the "printer-state-reasons" value.
Resume-Printerの操作により、「プリンターステートレゾン」値が変更される場合があります。
The "printer-state" will change to one of three states:
「プリンター状態」は、3つの州のいずれかに変更されます。
1. 'idle' - no additional jobs and no error conditions present
1. 「アイドル」 - 追加のジョブもエラー条件もありません
2. 'processing' - job available and no error conditions present
2. 「処理」 - 利用可能なジョブとエラー条件なし
3. current state (i.e. no change) an error condition is present (e.g. media jam)
3. 現在の状態（つまり、変更なし）エラー条件が存在します（メディアジャムなど）
In the third case the "printer-state-reason" will be cleared by automata when it detects the error condition no longer exists. The "printer-state" will move to 'idle' or 'processing' when conditions permit. (i.e. no more error conditions)
3番目のケースでは、エラー条件が存在しなくなったことを検出すると、「プリンターステートリアン」がオートマトンによってクリアされます。「プリンター状態」は、条件が許可されたときに「アイドル」または「処理」に移動します。（つまり、これ以上エラー条件はありません）
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Pause-Printer are applicable to Purge-Printer. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1のPrint-Jobステータスコードの説明はすべて、Pause-Printerについて説明されている専門化を備えたPrint-Job応答は、パージプリンターに適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the Printer object purges all it's jobs.
次の成功ステータスコードでは、プリンターオブジェクトがすべてのジョブをパージします。
successful-ok: no request attributes were substituted or ignored (same as Print-Job).
成功したOK：リクエスト属性は置換または無視されませんでした（print-jobと同じ）。
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Print-Jobと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
For any of the error status codes, the Printer object does not purge any jobs.
エラーステータスコードのいずれかについて、プリンターオブジェクトはジョブをパージしません。
server-error-operation-not-supported: the Purge-Printer operation is not supported.
サーバーエラーオペレーション - サポートされていない：パージプリンター操作はサポートされていません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specialization's and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されている印刷ジョブステータスコードはすべて、次の専門化と違いを伴うGet-Printer-Attributes操作に適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the document has been added to the specified Job object and the job's "number-of-documents" attribute has been incremented:
次の成功ステータスコードについて、ドキュメントは指定されたジョブオブジェクトに追加され、ジョブの「ドキュメント数」属性が増加しました。
successful-ok: no request attributes were substituted or ignored (same as Print-Job).
成功したOK：リクエスト属性は置換または無視されませんでした（print-jobと同じ）。
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Print-Jobと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
For the error status codes, no document has been added to the Job object and the job's "number-of-documents" attribute has not been incremented:
エラーステータスコードの場合、ジョブオブジェクトにドキュメントが追加されておらず、ジョブの「ドキュメント数」属性が増加していません。
client-error-not-possible: Same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved, so that the client is able to finish submitting a job that was created with a Create-Job operation after this attribute has been set to 'true'. Another condition is that the state of the job precludes Send-Document, i.e., the job has already been closed out by the client. However, if the IPP Printer closed out the job due to timeout, the 'client-error-timeout' error status SHOULD be returned instead.
Client-error-not-possible：プリントジョブと同じですが、プリンターの「プリンター-is-Is-accepting-jobs」属性が関与していないことを除いて、クライアントは作成されたジョブを作成したジョブの送信を終了できます。この属性の後の職務は、「真」に設定されています。別の条件は、仕事の状態が送信ドキュメントを排除することです。つまり、仕事はすでにクライアントによって閉鎖されています。ただし、IPPプリンターがタイムアウトのためにジョブを閉鎖した場合、代わりに「クライアントエラータイムアウト」エラーステータスを返す必要があります。
client-error-timeout: This request was sent after the Printer closed the job, because it has not received a Send-Document or Send-URI operation within the Printer's "multiple-operation-time-out" period .
クライアントエラータイムアウト：このリクエストは、プリンターがジョブを閉鎖した後に送信されました。これは、プリンターの「複数操作時間外出」期間内に送信ドキュメントまたは送信-URI操作を受け取っていないためです。
client-error-request-entity-too-large: same as Print-Job.
Client-Error-Request-Entity-Too-Large：Print-Jobと同じ。
client-error-conflicting-attributes: same as Print-Job, except that "ipp-attributes-fidelity" operation attribute is not involved..
クライアントとエラーの紛争 - アトリビュート：「IPP-Attributes-Fidelity」操作属性が関与していないことを除いて、Print-Jobと同じです。
server-error-operation-not-supported: the Send-Document request is not supported.
Server-Error-operation-supported：send-documentリクエストはサポートされていません。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the data.
Server-Error-Job-Canceled：クライアントがデータを送信している間、ジョブはオペレーターまたはシステムによってキャンセルされました。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Send-Document are applicable to Send-URI. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.3.1.1のSend-Documentについて説明された専門化を伴うPrint-Job応答のすべての印刷ジョブステータスコードの説明は、Send-URIに適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
client-error-uri-scheme-not-supported: the URI scheme supplied in the "document-uri" operation attribute is not supported and the "document-uri" attribute MUST be returned in the Unsupported Attributes group.
クライアントエラー-URI-SCHEME-NOT-SUPPORTED：「Document-URI」操作属性で提供されるURIスキームはサポートされておらず、「Document-URI」属性をサポートされていない属性グループで返す必要があります。
server-error-operation-not-supported: the Send-URI operation is not supported.
Server-Error-operation-supported：送信-URI操作はサポートされていません。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Cancel-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、以下の専門化と違いを伴うキャンセルジョブに適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the Job object is being canceled or has been canceled:
次の成功ステータスコードでは、ジョブオブジェクトがキャンセルされているか、キャンセルされています。
successful-ok: no request attributes were substituted or ignored (same as Print-Job).
成功したOK：リクエスト属性は置換または無視されませんでした（print-jobと同じ）。
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Print-Jobと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
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-Possible：ジョブオブジェクトの状態（「完了」、「キャンセル」、または「中止」）またはシステムの状態のために、リクエストを実行することはできません。
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-Gone：ターゲットプリンターおよび/またはジョブオブジェクトはもはや存在せず、転送アドレスが既にわかっていません。
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-document-format-not-supported：該当なし。
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.
クライアントとエラーの紛争 - アトリビュート：プリンターの「プリンター-is-Is-accepting-jobs」属性が関与していないことを除いて、print-jobと同じです。
server-error-operation-not-supported: not applicable (Cancel-Job is REQUIRED).
Server-Error-Operation-Not-Supported：該当なし（Cancel-Jobが必要です）。
server-error-device-error: same as Print-Job, except no document data is involved.
Server-error-device-error：ドキュメントデータが含まれていないことを除いて、print-jobと同じです。
server-error-temporary-error: same as Print-Job, except no document data is involved.
Server-Error-tempolary-error：ドキュメントデータが含まれていないことを除いて、print-jobと同じです。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-job-canceled: not applicable.
Server-error-jobcanceled：該当なし。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Get-Job-Attributes with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、次の専門化と違いを伴うget-job-attributesに適用できます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
次の成功ステータスコードについて、要求された属性は、応答のグループ3で返されます。
successful-ok: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功：Get-Printer-Attributesと同じ（セクション3.1.3.1.5を参照）。
successful-ok-ignored-or-substituted-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Get-Printer-Attributesと同じ（セクション3.1.3.1.5を参照）。
successful-ok-conflicting-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
成功したOK紛争 - アトリビュート：Get-Printer-Attributesと同じ（セクション3.1.3.1.5を参照）。
For the error status codes, Group 3 is returned containing no attributes or is not returned at all.
エラーステータスコードの場合、グループ3は属性を含むか、まったく返されません。
client-error-not-possible: Same as Print-Job, in addition the Printer object is not accepting any requests.
Client-Error-Not-Possible：Print-Jobと同じ、さらにプリンターオブジェクトはリクエストを受け入れていません。
client-error-document-format-not-supported: not applicable.
client-error-document-format-not-supported：該当なし。
client-error-attributes-or-values-not-supported: not applicable.
client-error-attributes-or-values-supported：該当なし。
client-error-uri-scheme-not-supported: not applicable.
client-error-uri-scheme-not-supported：該当なし。
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).
クライアントエラーアトリビュートオアバリュー - サポートなし：サポートされていない操作の属性および/または値を無視し、適切な成功コードを返す必要があるため、該当しません（上記を参照）。
client-error-conflicting-attributes: not applicable
クライアントとエラーの紛争 - アトリビュート：該当なし
server-error-operation-not-supported: not applicable (since Get-Job-Attributes is REQUIRED).
Server-Error-operation-not-supported：該当なし（get-job-attributesが必要なため）。
server-error-device-error: same as Print-Job, except no document data is involved.
Server-error-device-error：ドキュメントデータが含まれていないことを除いて、print-jobと同じです。
server-error-temporary-error: sane as Print-Job, except no document data is involved..
Server-Error-tempolary-error：文書データが含まれていないことを除いて、印刷ジョブとしてのSANE。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-job-canceled: not applicable.
Server-error-jobcanceled：該当なし。
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Hold-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1で説明されているすべての印刷ジョブステータスコードは、次の専門分野と違いを伴うホールドジョブに適用できます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
For the following success status codes, the Job object is being held or has been held:
次の成功ステータスコードについては、ジョブオブジェクトが保持されているか、保持されています。
successful-ok: no request attributes were substituted or ignored (same as Print-Job).
成功したOK：リクエスト属性は置換または無視されませんでした（print-jobと同じ）。
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
成功したOK-INORED-OR-STITUTED-ATTRIBUTES：Print-Jobと同じ。
successful-ok-conflicting-attributes: same as Print-Job.
成功したOK紛争 - アトリビュート：Print-Jobと同じ。
For any of the error status codes, the Job object has not been held or was previously held.
エラーステータスコードのいずれかについて、ジョブオブジェクトは保持されていないか、以前に保持されていません。
client-error-not-possible: The request cannot be carried out because of the state of the Job object ('completed', 'canceled', or 'aborted') or the state of the system.
Client-Error-Not-Possible：ジョブオブジェクトの状態（「完了」、「キャンセル」、または「中止」）またはシステムの状態のために、リクエストを実行することはできません。
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-Gone：ターゲットプリンターおよび/またはジョブオブジェクトはもはや存在せず、転送アドレスが既にわかっていません。
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-document-format-not-supported：該当なし。
client-error-conflicting-attributes: same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved.
クライアントとエラーの紛争 - アトリビュート：プリンターの「プリンター-is-Is-accepting-jobs」属性が関与していないことを除いて、print-jobと同じです。
server-error-operation-not-supported: the Hold-Job operation is not supported.
Server-Error-operation-supported：ホールドジョブ操作はサポートされていません。
server-error-device-error: not applicable.
Server-error-device-error：該当なし。
server-error-temporary-error: same as Print-Job, except no document data is involved.
Server-Error-tempolary-error：ドキュメントデータが含まれていないことを除いて、print-jobと同じです。
server-error-not-accepting-jobs: not applicable.
Server-error-not-accepting-jobs：該当なし。
server-error-job-canceled: not applicable.
Server-error-jobcanceled：該当なし。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Hold-Job are applicable to Release-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1のPrint-Jobステータスコードの説明はすべて、Hold-Jobについて説明した専門化を使用したPrint-Jobの応答は、リリースJOBに適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
server-error-operation-not-supported: the Release-Job operation is not supported.
Server-Error-Operation-Supported：リリースジョブ操作はサポートされていません。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Hold-Job are applicable to Restart-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1.1のPrint-Jobステータスコードのすべての説明は、Hold-Jobについて説明されている専門化を使用した印刷ジョブの応答が再起動に適用されます。各ステータスコードのより完全な説明については、[RFC2911]のセクション13を参照してください。
server-error-operation-not-supported: the Restart-Job operation is not supported.
Server-Error-operation-Supported：再起動とジョブの操作はサポートされていません。
Assume I give a Create-Job request along with a set of 5 documents. All the documents get printed and the job state is moved to completed. I issue a Restart-Job request on the job. Now the issue is that, if I try to add new documents to the restarted job, will the IPP Server permit me to do so or return "client-error-not-possible " and again print those 5 jobs?
5つのドキュメントのセットとともに、Create-Jobリクエストを提供していると仮定します。すべてのドキュメントが印刷され、ジョブ状態が完了するように移動されます。ジョブに再起動ジョブリクエストを発行します。問題は、再起動したジョブに新しいドキュメントを追加しようとすると、IPPサーバーは「クライアントエラーのないもの」を返すことを許可して、再びそれらの5つのジョブを印刷することを許可しますか？
A job can not move to the 'completed' state until all the documents have been processed. The 'last-document' flag indicates when the last document for a job is being sent from the client. This is the semantic equivalent of closing a job. No documents may be added once a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job is moved to the 'pending' job state and restarts the beginning on the same IPP Printer object with the same attribute values." 'number-of-documents' is a job attribute.
すべての文書が処理されるまで、ジョブは「完了した」状態に移動することはできません。「最後のドキュメント」フラグは、ジョブの最後のドキュメントがクライアントから送信されていることを示します。これは、ジョブを閉鎖することに相当するセマンティックです。ジョブが閉じると、ドキュメントを追加することはできません。IPP/1.1モデルのセクション3.3.7では、「ジョブは「保留中」のジョブ状態に移動され、同じ属性値を持つ同じIPPプリンターオブジェクトの開始を再起動します。」「ドキュメント数」はジョブ属性です。
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.
Get-Printer-Attributes、Get-Jobs、またはGet-Job-Attributes Responseでは、クライアントは、クライアントが要求したがIPPオブジェクトによってサポートされていないサポートされていない属性グループでサポートされていない属性を取得することに依存することはできません。ただし、そのようなサポートされていない要求された属性は、ジョブ属性またはプリンター属性グループ（サポートされていないため）で返されません。さらに、IPPオブジェクトは、「成功したOK-INORED-OR-STITUTED-ATTRIBUTES」ステータスコードを返す必要があります。そのため、クライアントは要求されたものがすべて返されていないことを知っています。
The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender not send an empty attribute group in a request or a response. However, they REQUIRE a receiver to accept an empty attribute group as equivalent to the omission of that group. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that is not supplying any Job Template attributes. Similarly, an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to be returned in a response.
[RFC2911]および[RFC2910]仕様は、送信者が要求または応答で空の属性グループを送信しないことを推奨しています。ただし、そのグループの省略に相当する空の属性グループを受け入れるレシーバーが必要です。そのため、クライアントは、ジョブテンプレート属性を作成していない作成操作で、ジョブテンプレート属性グループを完全に省略する必要があります。同様に、IPPオブジェクトは、応答で返されるサポートされていない属性がない場合、空のサポートされていない属性グループを省略する必要があります。
The [RFC2910] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them equivalently. The term "receiver" means an IPP object for a request and a client for a response. The term "sender' means a client for a request and an IPP object for a response.
[RFC2910]仕様では、レシーバーが空の属性グループまたは省略された属性グループを受信して同等に処理できる必要があります。「受信機」という用語は、リクエストのIPPオブジェクトと応答のクライアントを意味します。「送信者」という用語は、リクエストのクライアントと応答のIPPオブジェクトを意味します。
There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2910] contains the following paragraph:
返される属性がない場合、get-jobsのルールには例外があります。[RFC2910]には、次の段落が含まれています。
The syntax allows an xxx-attributes-tag to be present when the xxx-attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
構文により、XXX-Attributes-Tagが存在するようになります。構文はこの方法で定義されており、いくつかの職務objectsの属性が返されないget-jobsの応答を可能にします。属性がない場合は送信者がxxx-attributes-tagを送信しないことをお勧めしますが（先ほど言及したGet-Jobs応答を除く）、受信者はそのような構文をデコードできる必要があります。
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プリンターをテストするテストスクリプトを書く際には、プリンターが一時停止された場合、すべての可能な実装を使用するために、プリンターが再開されるまで、応答を期待しないように書かれている必要があります。
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".
このモデルは、ドキュメントのコンテンツを受け入れる前に、プリンターが応答を返すことを示唆しています。Job Object属性は、IPPオブジェクトが成功ステータスコードのいずれかを返す場合にのみ返されます。その後、ジョブステートは常に「保留中」または「保留中」になります。
This issue comes up for the implementation of an IPP Printer object as a server that forwards jobs to devices that do not provide job status back to the server. If the server is reasonably certain that the job completed successfully, then it should return the job-state as 'completed'. Also the server can keep the job in its "job history" long after the job is no longer in the device. Then a user could query the server and see that the job was in the 'completed' state and completed as specified by the jobs "time-at-completed" time, which would be the same as the server submitted the job to the device.
この問題は、ジョブステータスをサーバーに戻さないデバイスにジョブを転送するサーバーとしてIPPプリンターオブジェクトを実装するために発生します。サーバーがジョブが正常に完了したことを合理的に確信している場合、ジョブステートを「完了」として返す必要があります。また、サーバーは、ジョブがデバイスになくなった後もずっと「仕事の歴史」を維持することができます。次に、ユーザーはサーバーを照会し、ジョブが「完了」状態であり、ジョブが「完了した時間」の時間で指定されているように完了したことを確認できます。これは、サーバーがジョブをデバイスに送信したのと同じです。
An alternative is for the server to respond to the client before or while sending the job to the device, instead of waiting until the server has finished sending the job to the device. In this case, the server can return the job's state as 'pending' with the 'job-outgoing' value in the job's "job-state-reasons" attribute.
別の方法は、サーバーがジョブにジョブの送信を終了するまで待機するのではなく、サーバーがジョブをデバイスに送信する前にクライアントに応答することです。この場合、サーバーは、ジョブの「ジョブステートレゾン」属性の「ジョブアウト」値で「係争中」としてジョブの状態を「保留」として返すことができます。
If the server doesn't know for sure whether the job completed successfully (or at all), it could return the (out-of-band) 'unknown' value.
サーバーがジョブが正常に（またはまったく）完了したかどうかを確実に知らない場合、（帯域外）「未知の」値を返す可能性があります。
On the other hand, if the server is able to query the device and/or setup some sort of event notification that the device initiates when the job makes state transitions, then the server can return the current job state in the Print-Job response and in subsequent queries because the server knows what the job state is in the device (or can query the device).
一方、サーバーがデバイスを照会したり、ジョブが状態遷移を行ったときにデバイスが開始するというイベント通知をセットアップできる場合、サーバーはプリントジョブ応答で現在のジョブ状態を返すことができます。サーバーがデバイス内のジョブ状態が何であるかを知っている（またはデバイスを照会することができる）ため、後続のクエリで。
All of these alternatives depend on implementation of the server and the device.
これらの選択肢はすべて、サーバーとデバイスの実装に依存します。
If a Printer supports the "printer-make-and-model" attribute and returns the .INF file model name of the printer in that attribute, the Microsoft client will automatically install the correct driver (if available).
プリンターが「プリンターメイクアンドモデル」属性をサポートし、その属性のプリンターの.INFファイルモデル名を返す場合、Microsoftクライアントは正しいドライバーを自動的にインストールします（利用可能な場合）。
Clients which poll periodically for printer status or queued-job-count should use the "requested-attributes" operation attribute to limit the scope of the query in order to save Printer and network resources.
プリンターのステータスまたはキュームジョブカウントについて定期的に投票するクライアントは、「要求されたアトリビュート」操作属性を使用して、プリンターとネットワークリソースを保存するためにクエリの範囲を制限する必要があります。
In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there too, and if it's not present what should the IPP printer do?
[rfc2911]セクション3.2.6.1「get-jobs request」では、属性「my-jobs」が存在して真に設定されている場合、「リクエストユーザー」属性もそこにある必要があります。IPPプリンターはすべきですか？
[RFC2911] Section 8.3 describes the various cases of "requesting-user-name" being present or not for any operation. If the client does not supply a value for "requesting-user-name", the printer MUST assume that the client is supplying some anonymous name, such as "anonymous".
[RFC2911]セクション8.3では、「リクエストユーザー」が存在するかどうかにかかわらず、「リクエストユーザー」のさまざまなケースについて説明します。クライアントが「リクエストユーザー名」の値を提供しない場合、プリンターは、クライアントが「匿名」などの匿名の名前を提供していると想定する必要があります。
When using the Get-Jobs operation a client implementer might choose to limit the number of jobs that the client shows on the first screenful. For example, if its UI can only display 50 jobs, it can defend itself against a printer that would otherwise return 500 jobs, perhaps taking a long time on a slow dial-up line. The client can then go and ask for a larger number of jobs in the background, while showing the user the first 50 jobs. Since the job history is returned in reverse order, namely the most recently completed jobs are returned first, the user is most likely interested in the first jobs that are returned. Limiting the number of jobs may be especially useful for a client that is requesting 'completed' jobs from a printer that keeps a long job history. Clients that don't mind sometimes getting very large responses, can omit the "limit" attribute in their Get-Jobs requests.
get-jobs操作を使用する場合、クライアントの実装者は、クライアントが最初のスクリーンフルに表示するジョブの数を制限することを選択する場合があります。たとえば、UIが50のジョブしか表示できない場合、500のジョブを返すプリンターに対して防御でき、おそらく遅いダイヤルアップラインで長い時間をかけています。その後、クライアントはバックグラウンドでより多くのジョブを求めることができ、最初の50のジョブをユーザーに見せます。仕事の履歴は逆の順序で返されるため、つまり最近完成したジョブが最初に返されるため、ユーザーは返される最初のジョブに興味がある可能性が高いです。ジョブの数を制限することは、長い仕事の歴史を保つプリンターから「完了した」ジョブを要求しているクライアントにとって特に役立ちます。時々非常に大きな応答を得ることを気にしないクライアントは、Get-Jobsリクエストで「制限」属性を省略できます。
A Printer may respond to a Create-Job operation with "job-state" 'pending' or 'pending-held' and " job-state-reason" 'job-data-insufficient' to indicate that operation has been accepted by the Printer, but the Printer is expecting additional document data before it can move the job into the 'processing' state. Alternatively, it may respond with "job-state" 'processing' and "job-state-reason" 'job-incoming' to indicate that the Create-Job operation has been accepted by the Printer, but the Printer is expecting additional Send-Document and/or Send-URI operations and/or is accessing/accepting document data. The second alternative is for non-spooling Printers that don't implement the 'pending' state.
プリンターは、「ジョブステート」「保留中」または「保留中の」および「ジョブステートリアン」と「ジョブダタが不十分」で、プリンターによって操作が受け入れられていることを示す「ジョブステート」および「ジョブステートリアン」を備えた作成とジョブの操作に応答する場合があります。、しかし、プリンターは、ジョブを「処理」状態に移動する前に、追加のドキュメントデータを期待しています。あるいは、「ジョブステート」「処理」および「ジョブステートリアン」「ジョブインコーミング」で応答して、プリンターによって作成された操作が受け入れられていることを示すことができますが、プリンターは追加の送信を期待しています - ドキュメントおよび/または送信-URI操作および/またはドキュメントデータにアクセス/受け入れています。2番目の選択肢は、「保留中」状態を実装しない非スプールプリンターのためです。
Should the server wait for the "last-document" operation attribute set to 'true' before starting to "process" the job?
サーバーは、ジョブを「処理」し始める前に「true」に設定された「ラストドキュメント」操作属性を待つ必要がありますか？
It depends on implementation. Some servers spool the entire job, including all document data, before starting to process, so such an implementation would wait for the "last-document" before starting to process the job. If the time-out occurs without the "last-document", then the server takes one of the indicated actions in section 3.3.1 in the [RFC2911] document. Other servers will start to process document data as soon as they have some. These are the so-called "non-spooling" printers. Currently, there isn't a way for a client to determine whether the Printer will spool all the data or will start to process (and print) as soon as it has some data.
実装に依存します。一部のサーバーは、すべてのドキュメントデータを含むすべてのドキュメントデータを含む、処理を開始する前にジョブ全体をスプールするため、そのような実装はジョブの処理を開始する前に「最後のドキュメント」を待ちます。「最後のドキュメント」なしでタイムアウトが発生した場合、サーバーは[RFC2911]ドキュメントのセクション3.3.1で指定されたアクションの1つを取得します。他のサーバーは、いくつかがあるとすぐにドキュメントデータの処理を開始します。これらは、いわゆる「非スパイリング」プリンターです。現在、クライアントがプリンターがすべてのデータをスプールするか、データがあるとすぐに処理（および印刷）を開始するかどうかを判断する方法はありません。
The Validate-Job operation has been designed so that its implementation may be a part of the Print-Job operation. Therefore, requiring Validate-Job is not a burden on implementers. Also it is useful for client's to be able to count on its presence in all conformance implementations, so that the client can determine before sending a long document, whether the job will be accepted by the IPP Printer or not.
検証済みの実地操作は、その実装が印刷ジョブ操作の一部になるように設計されています。したがって、Validate-Jobを要求することは、実装者の負担ではありません。また、クライアントがすべての適合実装でその存在を期待できるようにすることが役立つため、クライアントは、ジョブがIPPプリンターに受け入れられるかどうかにかかわらず、長いドキュメントを送信する前に決定できます。
The Restart-Job operation allows the reprocessing of a completed job. Some jobs store the document data on the printer. Jobs created using the Print-Job operation are an example. It is required that the printer retains the job data after the job has moved to a 'completed state' in order for the Restart-Job operation to succeed.
Restart-Job操作により、完了したジョブの再処理が可能になります。一部のジョブは、ドキュメントデータをプリンターに保存します。Print-Job操作を使用して作成されたジョブは例です。再起動とジョブの操作が成功するために、ジョブが「完成した状態」に移動した後、プリンターがジョブデータを保持する必要があります。
Some jobs contain only a reference to the job data. A job created using the Print-URI is an example of such a job. When the Restart-Job operation is issued the job is reprocessed. The job data MUST be retrieved again to print the job.
一部のジョブには、ジョブデータへの参照のみが含まれています。Print-uriを使用して作成されたジョブは、そのような仕事の例です。Restart-Job操作が発行されると、ジョブが再処理されます。ジョブデータを再度取得して、ジョブを印刷する必要があります。
It is possible that a job fails while attempting to access the print data. When such a job is the target of a Restart-Job the Printer SHALL attempt to retrieve the job data again.
印刷データにアクセスしようとしているときにジョブが失敗する可能性があります。そのようなジョブが再起動のターゲットである場合、プリンターは再びジョブデータを取得しようとします。
4 Object Attributes
4つのオブジェクト属性
[RFC2911] states that the 'none' value should be used as the value of a 1setOf when the set is empty. In most cases, sets that are potentially empty contain keywords so the keyword 'none' is used, but for the 3 finishings attributes, the values are enums and thus the empty set is represented by the enum 3. Currently there are no other attributes with 1setOf values, which can be empty and can contain values that are not keywords. This exception requires special code and is a potential place for bugs. It would have been better if we had chosen an out-of-band value, either "no-value" or some new value, such as 'none'. Since we didn't, implementations have to deal with the different representations of 'none', depending on the attribute syntax.
[RFC2911]は、セットが空の場合、「なし」の値を1セットの値として使用する必要があると述べています。ほとんどの場合、空の潜在的なセットにキーワードが含まれているため、キーワード「なし」が使用されますが、3つの仕上げ属性については、値は列挙であるため、空のセットは列挙3で表されます。現在、他の属性はありません。1セットの値。空にすることができ、キーワードではない値を含めることができます。この例外には特別なコードが必要であり、バグの潜在的な場所です。「none」などの「価値のない」または新しい値のいずれかの帯域外値を選択していれば、より良いでしょう。そうではないので、属性の構文に応じて、実装は「なし」の異なる表現に対処する必要があります。
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セマンティクスは属性の構文を各値に関連付けます。。プロトコルは、属性構文タグを各値に関連付けます。属性構文タグが属性キーワードの前に来るからといって、だまされないでください。最初の後のすべての属性値は、同じ属性の後続の値の表示としてゼロの長さ属性キーワードを持っています。
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がケース感度を十分に示している可能性があることを思い出させます。選択が完全にarbitrary意的であるフィールドにURLを作成する場合、おそらく小文字を選択するのが最善です。ただし、これを保証することはできず、実装は、URLスキームとホスト名フィールドを超えて、URLでケースに敏感またはケースに依存しないフィールドに依存してはなりません。
The reason that the IPP specification does not make any restrictions on URIs, is so that implementations of IPP may use off-the-shelf components that conform to the standards that define URIs, such as RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these specifications for rules of matching, comparison, and case-sensitivity.
IPP仕様がURIを制限しない理由は、IPPの実装が、RFC 2396やHTTP/1.1仕様[RFC2616]などのURIを定義する標準に準拠する既製のコンポーネントを使用できるようにするためです。。一致、比較、ケース感受性のルールについては、これらの仕様を参照してください。
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とPrinter1を2つの異なるIPPプリンターとして持っていません。
Example of equivalent URI's
同等のウリの例
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com/%7Esmith/home.html
http:/ABC.com:/%7esmith/home.html
http：/abc.com：/％7esmith/home.html
Example of equivalent URI's using the IPP scheme
IPPスキームを使用した同等のURIの例
ipp://abc.com:631/~smith/home.html
ipp://ABC.com/%7Esmith/home.html
http:/ABC.com:631/%7esmith/home.html
http：/abc.com：631/％7esmith/home.html
The HTTP/1.1 specification [RFC2616] contains more details on comparing URLs.
HTTP/1.1仕様[RFC2616]には、URLの比較に関する詳細が含まれています。
The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes that have two components. The first component is the 'language' component that can contain up to 63 octets. The second component is the 'text' or 'name' component. The maximum length of these are 1023 octets and 255 octets respectively. The definition of attributes with either syntax may further restrict the length (e.g., printer-name (name(127))).
「TextWithLanguage」と「NameWithLanguage」は、2つのコンポーネントを持つ複合構文です。最初のコンポーネントは、最大63オクテットを含むことができる「言語」コンポーネントです。2番目のコンポーネントは、「テキスト」または「名前」コンポーネントです。これらの最大長は、それぞれ1023オクテットと255オクテットです。いずれかの構文を使用した属性の定義は、長さをさらに制限する場合があります（例：プリンター名（名前（127）））。
The length of the 'language' component has no effect on the allowable length of 'text' in 'textWithLanguage' or the length of 'name' in 'nameWithLanguage'
「言語」コンポーネントの長さは、「テキスト」の「テキスト」の許容長さ」に影響を与えません。
IPP/1.0 is silent on which of the four effects an implementation would perform if it supports Create-Job, but does not support "multiple-document-handling" or multiple documents per job. IPP/1.1 was changed so that a Printer could support Create-Job without having to support multiple document jobs. The "multiple-document-jobs-supported" (boolean) Printer description attribute was added to IPP/1.1 along with the 'server-error-multiple-document-jobs-not-supported' status code for a Printer to indicate whether or not it supports multiple document jobs, when it supports the Create-Job operation. Also IPP/1.1 was clarified that the Printer MUST support the "multiple-document-handling" (type2 keyword) Job Template attribute with at least one value if the Printer supports multiple documents per job.
IPP/1.0は、Create-Jobをサポートしている場合に実装が実行する4つの効果のどれが実行されるかについて、沈黙していますが、ジョブあたりの「複数ドキュメント処理」または複数のドキュメントをサポートしていません。IPP/1.1は、複数のドキュメントジョブをサポートすることなくプリンターがCreate-Jobをサポートできるように変更されました。「マルチドキュメント - ジョブがサポートした」（ブール値）プリンター説明属性がIPP/1.1に追加されました。Create-Job操作をサポートする場合、複数のドキュメントジョブをサポートします。また、IPP/1.1は、プリンターがジョブごとに複数のドキュメントをサポートする場合、少なくとも1つの値で「複数のドキュメントハンドリング」（Type2キーワード）ジョブテンプレート属性をサポートする必要があることを明らかにしました。
The "date-time-at-creation", "date-time-at-processing", and "date-time-at-completed" attributes are returned as dateTime syntax. These attributes are OPTIONAL for a Printer to support. However, there are various ways for a Printer to get the date and time of day. Some suggestions:
「日付時刻と制作」、「処理日付の日時」、および「承認時刻の日付」属性は、DateTime構文として返されます。これらの属性は、プリンターがサポートするためにオプションです。ただし、プリンターが日付と時刻を取得するにはさまざまな方法があります。いくつかの提案：
1. A Printer can get time from an NTP timeserver if there's one reachable on the network . See RFC 1305. Also DHCP option 32 in RFC 2132 returns the IP address of the NTP server.
1. ネットワークに到達可能なものがある場合、プリンターはNTP TimesServerから時間を取得できます。RFC 1305を参照してください。DHCPオプション32 in RFC 2132は、NTPサーバーのIPアドレスを返します。
2. Get the date and time at startup from a human operator
2. 人間のオペレーターからスタートアップで日付と時刻を取得する
3. Have an operator set the date and time using a web administrative interface
3. Web管理インターフェイスを使用してオペレーターに日付を設定してもらう
4. Get the date and time from incoming HTTP requests, though the problems of spoofing need to be considered. Perhaps comparing several HTTP requests could reduce the chances of spoofing.
4. スプーフィングの問題を考慮する必要がありますが、着信HTTPリクエストから日付と時刻を取得します。おそらく、いくつかのHTTPリクエストを比較すると、スプーフィングの可能性が減る可能性があります。
5. Internal date time clock battery driven.
5. 内部日付タイムクロックバッテリー駆動。
6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
6. クエリ "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
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.
「Queued-job-count」が推奨される理由は、キュー内のジョブの数を決定するためにget-jobsを行うのではなく、プリンターのリストのステータスを要約するときに、その属性のみを単独で見るクライアントです。「キュードジョブカウント」をサポートできない実装により、実際にキューに登録されているジョブがある場合、クライアントは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.
私たちはそれを必要なプリンター属性にしたでしょうが、問題が提起される前にいくつかの実装がすでに完了していたので、それをすることは妥協でした。
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.
「Queued-job-count」は、ジョブが開催されているときにプリンターがどれほど忙しいかについての良い尺度ではありません。将来の登録は、エクスペリエンスがプリンターが実際にどれほど忙しいかを迅速に示すためにそのような属性（組み合わせ）が必要であることを示している場合、「保有ジョブカウント」（または「アクティブジョブカウント」）プリンターの説明属性を追加することです。。
A Printer implementation MAY support this attribute by obtaining the date and time by any number of implementation-dependent means at startup or subsequently. Examples include:
プリンターの実装は、起動時またはその後の任意の数の実装依存手段で日付と時刻を取得することにより、この属性をサポートする場合があります。例は次のとおりです。
1. an internal date time clock,
1. 内部デートタイムクロック、
2. from the operator at startup using the console,
2. スタートアップのオペレーターからコンソールを使用して、
3. from an operator using an administrative web page,
3. 管理者Webページを使用してオペレーターから、
4. from HTTP headers supplied in client requests,
4. クライアントリクエストで提供されたHTTPヘッダーから、
5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
5. httpを使用して「http://tycho.usno.navy.mil/cgi-bin/timer.pl」を照会します
6. from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132] that returns the IP address of the NTP server.
6. ネットワークから、NTPサーバーのIPアドレスを返すNTP [RFC1305]またはDHCPオプション32 [RFC2132]を使用しています。
If an implementation supports this attribute by obtaining the current time from the network (at startup or later), but the time is not available, then the implementation MUST return the value of this attribute using the out-of-band 'no-value' meaning not configured. See the beginning of section 4.1.
実装がネットワークから（スタートアップ以降）から現在の時間を取得してこの属性をサポートしているが、時間が利用できない場合、実装は帯域外の「無価値」を使用してこの属性の値を返す必要があります。構成されていないことを意味します。セクション4.1の開始を参照してください。
Since the new "date-and-time-at-xxx" Job Description attributes refer to the "printer-current-time", they will be covered also.
新しい「日付と時間のXXX」の職務記述書の属性は、「プリンター電流時刻」を参照するため、カバーされます。
Must the operational attribute for printer-uri match one of the values in "printer-uri-supported"?
プリンター-RIの運用属性は、「プリンター-RIがサポートする」の値の1つと一致する必要がありますか？
A forgiving printer implementation would not reject the operation. But the implementation has its rights to reject a printer or job operation if the operational attribute printer-uri is not a value of the printer-uri-supported. The printer might not be improperly configured. The request obviously reached the printer. The printer could treat the printer-uri as the logical equivalent of a value in the printer-uri-supported. It would be implementation dependent for which value, and associated security policy, would apply. This does also apply to a job object specified with a printer-uri and job-id, or with a job-uri. See section 4.1.3 for how to compare URI's.
寛容なプリンターの実装では、操作は拒否されません。しかし、実装には、プリンター-Ri-URIがサポートされているものの価値ではない場合、プリンターまたは職務操作を拒否する権利があります。プリンターが不適切に構成されていない場合があります。リクエストは明らかにプリンターに到達しました。プリンターは、プリンター-RIをプリンター尿中の値に相当する論理的な相当物として扱うことができます。どの値と関連するセキュリティポリシーが適用されるかに依存する実装になります。これは、プリンター-URIおよびJob-IDで指定されたジョブオブジェクト、またはJob-URIにも適用されます。URIの比較方法については、セクション4.1.3を参照してください。
The IPP object model does not prohibit a job that contains no documents. Such a job may be created in a number of ways including a 'create-job' followed by an 'add-document' that contains no data and has the 'last-document' flag set.
IPPオブジェクトモデルは、ドキュメントを含むジョブを禁止していません。このようなジョブは、データが含まれておらず、「ラストドキュメント」フラグセットを備えた「ドキュメント」が続く「Create-Job」を含むさまざまな方法で作成される場合があります。
An empty job is processed just as any other job. The operation that "closes" an empty job is not rejected because the job is empty. If no other conditions exist, other than the job is empty, the response to the operation will indicate success. After the job is scheduled and processed, the job state SHALL be 'completed'.
空の仕事は、他の仕事と同じように処理されます。空の仕事を「閉じる」操作は、ジョブが空であるため拒否されません。ジョブが空である以外に他の条件が存在しない場合、操作への応答は成功を示します。ジョブがスケジュールされ、処理された後、ジョブ状態は「完了」します。
There will be some variation in the value(s) of the "job-state-reasons" attribute. It is required that if no conditions, other than the job being empty, exist the "job-state-reasons" SHALL include the
「ジョブステートリーズン」属性の値にいくつかのバリエーションがあります。ジョブが空である以外の条件が存在しない場合、「ジョブステートリーズン」には、
'completed-successfully'. If other conditions existed, the 'completed-with-warnings' or 'completed-with-errors' values may be used.
「完成した状態で」。他の条件が存在する場合、「説明で完了した」または「エラーで完了した」値を使用することができます。
5 Directory Considerations
5つのディレクトリに関する考慮事項
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object attributes for directory schemas. See [RFC2911] APPENDIX E: Generic Directory Schema.
[RFC2911]ドキュメントには、ディレクトリスキーマの推奨されるプリンターオブジェクト属性をリストします。[RFC2911]付録E：汎用ディレクトリスキーマを参照してください。
The SLP printer template is defined in the "Definition of the Printer Abstract Service Type v2.0" document [svrloc-printer]. The LDAP printer template is defined in the "Internet Printing Protocol (IPP): LDAP Schema for Printer Services" document [ldap-printer]. Both documents systematically add "printer-" to any attribute that doesn't already start with "printer-" in order to keep the printer directory attributes distinct from other directory attributes. Also, instead of using "printer-uri-supported", "uri-authentication-supported", and "uri-security-supported", they use a "printer-xri-supported" attribute with special syntax to contain all of the same information in a single attribute.
SLPプリンターテンプレートは、「プリンターの抽象サービスタイプV2.0」ドキュメント[SVRLOC-PRINTER]の「定義」で定義されています。LDAPプリンターテンプレートは、「インターネット印刷プロトコル（IPP）：プリンターサービス用のLDAPスキーマ」ドキュメント[LDAP-Printer]で定義されています。両方のドキュメントは、他のディレクトリ属性とは異なるプリンターディレクトリ属性を維持するために、「プリンタ」でまだ開始されていない属性に「プリンター」を体系的に追加します。また、「プリンター-RIサポート」、「URI-Authentication-Supported」、および「URI-Security-Supported」を使用する代わりに、「プリンター-XRIサポートされた」属性を特別な構文を使用して、同じすべてを含むように使用します。単一の属性の情報。
If the IPP printer has a DNS name should there be at least two values for the printer-uri-supported attribute. One URL with the fully qualified DNS name the other with the IP address in the URL? The printer may contain one or the other or both. It's up to the administrator to configure this attribute.
IPPプリンターにDNS名がある場合、プリンター-Ri-Supported属性に少なくとも2つの値があるはずです。完全に認定されたDNSを備えた1つのURLは、URLにIPアドレスが付いたもう1つのURLに名前を付けますか？プリンターには、どちらか一方またはその両方が含まれている場合があります。この属性を構成するのは管理者次第です。
6 Security Considerations
6つのセキュリティ上の考慮事項
The security considerations given in [RFC2911] Section 8 "Security Considerations" all apply to this document. In addition, the following sub-sections describes security consideration that have arisen as a result of implementation testing.
[RFC2911]セクション8「セキュリティ上の考慮事項」に記載されているセキュリティ上の考慮事項はすべて、このドキュメントに適用されます。さらに、次のサブセクションは、実装テストの結果として生じたセキュリティの考慮事項について説明しています。
The following clarification was added to [RFC2911] section 8.5:
次の説明が[RFC2911]セクション8.5に追加されました。
8.5 Queries on jobs submitted using non-IPP protocols If the device that an IPP Printer is representing is able to accept jobs using other job submission protocols in addition to IPP, it is RECOMMEND that such an implementation at least allow such "foreign" jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. Such an implementation NEED NOT support all of the same IPP job attributes as for IPP jobs. The IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign job that is supported for IPP jobs, but not for foreign jobs.
8.5 IPPプリンターが表現しているデバイスがIPPに加えて他の求人提出プロトコルを使用してジョブを受け入れることができる場合、非IPPプロトコルを使用して送信されたジョブのクエリのクエリは、少なくともそのような実装では、少なくともそのような「外国人」のジョブを許可することをお勧めします。get-jobsを「Job-id」と「Job-uri」を「不明」として返していることを照会しました。このような実装は、IPPジョブと同じIPPジョブ属性のすべてをサポートする必要はありません。IPPオブジェクトは、IPPジョブでサポートされているが外国のジョブではそうではなく、外国の仕事の要求された属性に対して「未知の」帯域外値を返します。
It is further RECOMMENDED, that the IPP Printer generate "job-id" and "job-uri" values for such "foreign jobs", if possible, so that they may be targets of other IPP operations, such as Get-Job-Attributes and Cancel-Job. Such an implementation also needs to deal with the problem of authentication of such foreign jobs. One approach would be to treat all such foreign jobs as belonging to users other than the user of the IPP client. Another approach would be for the foreign job to belong to 'anonymous'. Only if the IPP client has been authenticated as an operator or administrator of the IPP Printer object, could the foreign jobs be queried by an IPP request. Alternatively, if the security policy were to allow users to query other users' jobs, then the foreign jobs would also be visible to an end-user IPP client using Get-Jobs and Get-Job- Attributes.
さらに、IPPプリンターは、そのような「外国のジョブ」の「ジョブID」と「ジョブ・ウリ」の値を生成し、可能であれば、Get-job-aTtributesなどの他のIPP操作のターゲットになることをお勧めします。キャンセルジョブ。このような実装は、そのような外国の仕事の認証の問題にも対処する必要があります。1つのアプローチは、IPPクライアントのユーザー以外のユーザーに属するすべての外国の仕事を扱うことです。別のアプローチは、外国の仕事が「匿名」に属することです。IPPクライアントがIPPプリンターオブジェクトのオペレーターまたは管理者として認証された場合にのみ、IPPリクエストによって外国のジョブを照会できます。あるいは、セキュリティポリシーがユーザーが他のユーザーのジョブを照会できるようにする場合、外国のジョブもGet-JobsとGet-Job-属性を使用してエンドユーザーIPPクライアントにも表示されます。
Thus IPP MAY be implemented as a "universal" protocol that provides access to jobs submitted with any job submission protocol. As IPP becomes widely implemented, providing a more universal access makes sense.
したがって、IPPは、求人提出プロトコルで提出されたジョブへのアクセスを提供する「ユニバーサル」プロトコルとして実装できます。IPPが広く実装されると、より普遍的なアクセスを提供することは理にかなっています。
7 Encoding and Transport
7エンコードと輸送
This section discusses various aspects of IPP/1.1 Encoding and Transport [RFC2910].
このセクションでは、IPP/1.1エンコードと輸送のさまざまな側面について説明します[RFC2910]。
A server is not required to send a response until after it has received the client's entire request. Hence, a client must not expect a response until after it has sent the entire request. However, we recommend that the server return a response as soon as possible if an error is detected while the client is still sending the data, rather than waiting until all of the data is received. Therefore, we also recommend that a client listen for an error response that an IPP server MAY send before it receives all the data. In this case a client, if chunking the data, can send a premature zero-length chunk to end the request before sending all the data (and so the client can keep the connection open for other requests, rather than closing it). If the request is blocked for some reason, a client MAY determine the reason by opening another connection to query the server using Get-Printer-Attributes.
サーバーは、クライアントの要求全体を受け取るまで応答を送信する必要はありません。したがって、クライアントは、リクエスト全体を送信するまで応答を期待してはなりません。ただし、すべてのデータが受信されるまで待機するのではなく、クライアントがまだデータを送信している間にエラーが検出された場合、サーバーはできるだけ早く応答を返すことをお勧めします。したがって、クライアントは、すべてのデータを受信する前にIPPサーバーが送信する可能性のあるエラー応答をクライアントに聞くことをお勧めします。この場合、クライアントは、データをチャンキングする場合、すべてのデータを送信する前に、より早期のゼロ長さのチャンクを送信してリクエストを終了できます（およびクライアントは、閉じるのではなく、他のリクエストの接続を開いたままにします）。何らかの理由で要求がブロックされている場合、クライアントは、Get-Printer-Attributesを使用してサーバーを照会するために別の接続を開くことにより、理由を決定することができます。
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to throttle clients when Printers are busy. Therefore, it is perfectly normal for an IPP client transmitting a Job to be blocked for a really long time. Accordingly, socket timeouts must be avoided. Some socket implementations have a timeout option, which specifies how long a write operation on a socket can be blocked before it times out and the blocking ends. A client should set this option for infinite timeout when transmitting Job submissions.
IPPは、設計上、TCPの組み込みフロー制御メカニズム[RFC 793]を使用して、プリンターが忙しいときにクライアントをスロットルします。したがって、IPPクライアントがジョブを送信すると、非常に長い間ブロックされることは完全に正常です。したがって、ソケットのタイムアウトを避ける必要があります。一部のソケットの実装には、タイムアウトオプションがあります。これは、ソケットの書き込み操作が時間が外れて終了する前にブロックできる時間を指定します。クライアントは、ジョブの提出物を送信するときに、無限のタイムアウトにこのオプションを設定する必要があります。
Some IPP client applications might be able to perform other useful work while a Job transmission is blocked. For example, the client may have other jobs that it could transmit to other Printers simultaneously. A client may have a GUI, which must remain responsive to the user while the Job transmission is blocked. These clients should be designed to spawn a thread to handle the Job transmission at its own pace, leaving the main application free to do other work. Alternatively, single-threaded applications could use non-blocking I/O.
一部のIPPクライアントアプリケーションは、求人の送信がブロックされている間、他の有用な作業を実行できる場合があります。たとえば、クライアントは、他のプリンターに同時に送信できる他のジョブを持っている場合があります。クライアントにはGUIがある場合があります。これは、求人の伝達がブロックされている間、ユーザーに応答し続ける必要があります。これらのクライアントは、ジョブの伝送を独自のペースで処理するためにスレッドを生成するように設計されている必要があり、メインアプリケーションは他の作業を自由に行うことができます。あるいは、シングルスレッドアプリケーションは、非ブロッキングI/Oを使用できます。
Some Printer conditions, such as jam or lack of paper, could cause a client to be blocked indefinitely. Clients may open additional connections to the Printer to Get-Printer-Attributes, determine the state of the device, alert a user if the printer is stopped, and let a user decide whether to abort the job transmission or not.
ジャムや紙の不足などのいくつかのプリンター条件により、クライアントが無期限にブロックされる可能性があります。クライアントは、プリンターへの追加の接続を開き、プリンターアトリビュートを獲得し、デバイスの状態を決定し、プリンターが停止した場合にユーザーに警告し、ユーザーにジョブの送信を中止するかどうかを決定させます。
In the following sections, there are tables of all HTTP headers, which describe their use in an IPP client or server. The following is an explanation of each column in these tables.
次のセクションには、すべてのHTTPヘッダーの表があり、IPPクライアントまたはサーバーでの使用を説明しています。以下は、これらのテーブルの各列の説明です。
- the "header" column contains the name of a header - the "request/client" column indicates whether a client sends the header. - the "request/ server" column indicates whether a server supports the header when received. - the "response/ server" column indicates whether a server sends the header. - the "response /client" column indicates whether a client supports the header when received. - the "values and conditions" column specifies the allowed header values and the conditions for the header to be present in a request/response.
- 「ヘッダー」列には、ヘッダーの名前が含まれています - 「リクエスト/クライアント」列は、クライアントがヘッダーを送信するかどうかを示します。 - 「リクエスト/サーバー」列は、受信時にサーバーがヘッダーをサポートするかどうかを示します。 - 「応答/サーバー」列は、サーバーがヘッダーを送信するかどうかを示します。 - 「応答 /クライアント」列は、クライアントが受信時にヘッダーをサポートするかどうかを示します。 - 「値と条件」列は、許可されたヘッダー値と、ヘッダーがリクエスト/応答に存在する条件を指定します。
The table for "request headers" does not have columns for responses, and the table for "response headers" does not have columns for requests.
「リクエストヘッダー」のテーブルには応答の列がなく、「応答ヘッダー」のテーブルにはリクエストの列がありません。
The following is an explanation of the values in the "request/client" and "response/ server" columns.
以下は、「リクエスト/クライアント」および「応答/サーバー」列の値の説明です。
- must: the client or server MUST send the header, - must-if: the client or server MUST send the header when the condition described in the "values and conditions" column is met, - may: the client or server MAY send the header - not: the client or server SHOULD NOT send the header. It is not relevant to an IPP implementation.
- 必須：クライアントまたはサーバーはヘッダーを送信する必要があります-if -if：「値と条件」列に記載されている条件が満たされている場合、クライアントまたはサーバーはヘッダーを送信する必要があります。 - そうでない：クライアントまたはサーバーはヘッダーを送信しないでください。IPP実装には関係ありません。
The following is an explanation of the values in the "response/client" and "request/ server" columns.
以下は、「応答/クライアント」および「リクエスト/サーバー」列の値の説明です。
- must: the client or server MUST support the header, - may: the client or server MAY support the header - not: the client or server SHOULD NOT support the header. It is not relevant to an IPP implementation.
- マスト：クライアントまたはサーバーはヘッダーをサポートする必要があります - 5月：クライアントまたはサーバーはヘッダーをサポートする場合があります - クライアントまたはサーバーはヘッダーをサポートしてはなりません。IPP実装には関係ありません。
The following is a table for the general headers.
以下は、一般的なヘッダーの表です。
General- Request Response Values and Conditions Header
一般 - リクエスト応答の値と条件ヘッダー
Client Server Server Client
クライアントサーバークライアント
Cache- not must not "no-cache" only Control must
キャッシュ - 「ノーキャッシュ」のみを制御する必要はありません
Connection must- must must- must "close" only. Both
if if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
Date may may must may per RFC 1123 [RFC1123] from RFC 2616 [RFC2616]
5月5AMは、RFC 2616 [RFC2616]からRFC 1123 [RFC1123]ごとに5月5月
Pragma must not must not "no-cache" only
プラグマは「キャッシュなし」であってはなりません
Transfer- must- must must- must "chunked" only. Header
Encoding if if MUST be present if
Content-Length is
absent.
Upgrade not not not not
アップグレードではない
Via not not not not
そうではないことではありません
The following is a table for the request headers.
以下は、リクエストヘッダーの表です。
Request- Client Server Request Values and Conditions Header
リクエスト - クライアントサーバーの要求値と条件ヘッダー
Accept may must "application/ipp" only. This value is the default if the client omits it
受け入れる5月は「アプリケーション/IPP」のみをしなければなりません。クライアントが省略した場合、この値はデフォルトです
Accept- not not Charset information is within the Charset application/ipp entity
受け入れ - charset情報はcharsetアプリケーション/ippエンティティ内にありません
Accept- may must empty and per RFC 2616 [RFC2616] Encoding and IANA registry for content-codings
Accept- 5月は空にし、RFC 2616 [RFC2616]エンコードとコンテンツコーディングのIANAレジストリ
Accept- not not language information is within the Language application/ipp entity
受け入れ - 言語情報は言語アプリケーション/IPPエンティティ内にありません
Authorization must- must per RFC 2616. A client MUST send if this header when it receives a 401 "Unauthorized" response and does not receive a "Proxy-Authenticate" header.
承認必須 - RFC 2616ごとに必須。クライアントは、401の「許可されていない」応答を受信し、「プロキシと認識」ヘッダーを受け取らないときにこのヘッダーを送信する必要があります。
From not not per RFC 2616. Because RFC recommends sending this header only with the user's approval, it is not very useful
RFC 2616に従っていないことから。RFCはユーザーの承認だけでこのヘッダーを送信することを推奨するため、あまり役に立ちません
Host must must per RFC 2616
ホストはRFC 2616ごとに必要です
If-Match not not
そうではない場合
If-Modified- not not Since
if-modified-以来ではありません
If-None-Match not not
そうではない場合
If-Range not not
そうではない場合
If- not not Unmodified-Since
if-は変更されていないことではありません
Request- Client Server Request Values and Conditions Header
リクエスト - クライアントサーバーの要求値と条件ヘッダー
Max-Forwards not not
マックスフォワードではありません
Proxy- must- not per RFC 2616. A client MUST send
Authorizati if this header when it receives a
on 401 "Unauthorized" response and
a "Proxy-Authenticate" header.
Range not not
範囲ではありません
Referrer not not
リファラーではありません
User-Agent not not
ユーザーエージェントではありません
The following is a table for the request headers.
以下は、リクエストヘッダーの表です。
Response- Server Client Response Values and Conditions Header
Response-サーバークライアント応答の値と条件ヘッダー
Accept-Ranges not not
受け入れない
Age not not
年齢ではありません
Location must- may per RFC 2616. When URI needs if redirection.
ロケーション必須 - RFC 2616ごとに5月。URIがリダイレクトの場合に必要な場合。
Proxy- must per RFC 2616 Authenticat e not
RFC 2616 Authenticat e Not Notごとにプロキシ-必要になります
Public may may per RFC 2616
RFC 2616ごとに公開される可能性があります
Retry-After may may per RFC 2616
RFC 2616ごとにretry-After 5月
Server not not
サーバーではありません
Vary not not
違いはありません
Warning may may per RFC 2616
RFC 2616ごとに警告があります
WWW- must- must per RFC 2616. When a server needs Authenticate if to authenticate a client.
www-必須 - RFC 2616ごとに必須。クライアントを認証するためにサーバーが認証を必要とする場合。
The following is a table for the entity headers.
以下は、エンティティヘッダーの表です。
Entity-Header Request Response Values and Conditions
エンティティヘッドリクエスト応答の値と条件
Client Server Server Client
クライアントサーバークライアント
Allow not not not not
そうではないことを許可します
Content-Base not not not not
コンテンツベースではない
Content- may must must must per RFC 2616 and Encoding IANA registry for content codings.
Content- Mayは、RFC 2616ごとに、コンテンツコーディング用のIANAレジストリをエンコードする必要があります。
Content- not not not not Application/ipp Language handles language
コンテンツ - アプリケーションではない/IPP言語は言語を処理する
Content- must- must must- must the length of the
Length if if message-body per
RFC 2616. Header
MUST be present
if Transfer-
Encoding is
absent..
Content- not not not not Location
コンテンツ - 場所ではない
Content-MD5 may may may may per RFC 2616
content-md5 5月5A月RFC 2616ごとに5月5月
Content-Range not not not not
コンテンツレンジではありません
Content-Type must must must must "application/ipp" only
コンテンツタイプは、「アプリケーション/ipp」のみをマストする必要があります
ETag not not not not
ETAGはそうではありません
Expires not not not not
期限切れではありません
Last-Modified not not not not
永続的ではない
IPP implementations consist of an HTTP layer and an IPP layer. In the following discussion, the term "client" refers to the HTTP client layer and the term "server" refers to the HTTP server layer. The Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST be supported by all clients and all servers. However, a client and/or a server implementation may choose to also support HTTP 1.0.
IPP実装は、HTTPレイヤーとIPPレイヤーで構成されています。次の説明では、「クライアント」という用語はHTTPクライアントレイヤーを指し、「サーバー」という用語はHTTPサーバーレイヤーを指します。エンコーディングおよびトランスポートドキュメント[RFC2910]では、HTTP 1.1がすべてのクライアントとすべてのサーバーによってサポートされる必要があります。ただし、クライアントおよび/またはサーバーの実装は、HTTP 1.0もサポートすることを選択できます。
This option means that a server may choose to communicate with a (non-conforming) client that only supports HTTP 1.0. In such cases the server should not use any HTTP 1.1 specific parameters or features and should respond using HTTP version number 1.0.
このオプションは、サーバーがHTTP 1.0のみをサポートする（不適合な）クライアントと通信することを選択できることを意味します。このような場合、サーバーはHTTP 1.1特定のパラメーターまたは機能を使用してはならず、HTTPバージョン番号1.0を使用して応答する必要があります。
This option also means that a client may choose to communicate with a (non-conforming) server that only supports HTTP 1.0. In such cases, if the server responds with an HTTP 'unsupported version number' to an HTTP 1.1 request, the client should retry using HTTP version number 1.0.
また、このオプションは、クライアントがHTTP 1.0のみをサポートする（不適合な）サーバーと通信することを選択できることを意味します。そのような場合、サーバーがHTTP「サポートされていないバージョン番号」で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 [RFC2616] requires that conforming servers support chunked requests for any method. However, in spite of this requirement, some HTTP/1.1 implementations support chunked responses in the GET method, but do not support chunked POST method requests. Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or servlets [Servlet] require that the client supply a Content-Length. These implementations might reject a chunked POST method and return a 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.
HTTP/1.1標準[RFC2616]では、適合サーバーがあらゆる方法のチャンクされた要求をサポートする必要があります。ただし、この要件にもかかわらず、一部のHTTP/1.1実装は、GETメソッドのチャンクされた応答をサポートしていますが、チャンクされたPOSTメソッドリクエストをサポートしていません。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 [RFC2910] REQUIRES that a conforming IPP Printer object implementation support chunked requests and that conforming clients accept chunked responses. Therefore, IPP object implementers are warned to seek HTTP server implementations that support chunked POST requests in order to conform to the IPP standard and/or use implementation techniques that support chunked POST requests.
HTTPサーバーのHTTP/1.1標準への適合性がないため、IPP標準[RFC2910]では、適合するIPPプリンターオブジェクトの実装がチャンクされた要求をサポートし、適合クライアントがチャンクされた応答を受け入れる必要があります。したがって、IPPオブジェクトの実装者は、IPP標準に準拠し、チャンクされたPostリクエストをサポートする実装手法に準拠するために、チャンクされたPOSTリクエストをサポートするHTTPサーバーの実装を求めるように警告されます。
8 References
8参照
[CGI] CGI/1.1 (http://www.w3.org/CGI/).
[CGI] CGI/1.1（http://www.w3.org/cgi/）。
[IANA-CS] IANA Registry of Coded Character Sets: http://www.iana.org/assignments/character-sets
[IANA-CS]コード化された文字セットのIANAレジストリ：http：//www.iana.org/assignments/character-sets
[ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald, "Internet Printing Protocol (IPP): LDAP Schema for Printer Services", Work in Progress.
[LDAP-Printer] Fleming、P.、Jones、K.、Lewis、H。、およびI. McDonald、「インターネット印刷プロトコル（IPP）：プリンターサービス用のLDAPスキーマ」、進行中の作業。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, October, 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、RFC 1123、1989年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119 , March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2565] Debry、R.、Hastings、T.、Herriot、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2566、1999年4月。
[RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566] Herriot、R。、Butler、S.、Moore、P。and R. Turner、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567] Wright、D。、「インターネット印刷プロトコルの設計目標」、RFC 2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S。、「インターネット印刷プロトコルの構造とモデルとプロトコルの理論的根拠」、RFC 2568、1999年4月。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2569] Herriot、R.、Hastings、T.、Jacobs、N。およびJ. Martin、「LPDとIPPプロトコルのマッピング」、RFC 2569、1999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners -Lee、 "Hypertext Transfer Protocol -HTTP/1.1"、RFC2616、1999年6月。
[RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000.
[RFC2910] Herriot、R。、Butler、S.、Moore、P。、およびR. Turner、「インターネット印刷プロトコル/1.0：エンコードと輸送」、RFC 2910、2000年9月。
[RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, September, 2000.
[RFC2911] Debry、R.、Hastings、T.、Herriot、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2911、2000年9月。
[Servlet] Servlet Specification Version 2.1 (http://java.sun.com/products/servlet/2.1/ index.html).
[サーブレット]サーブレット仕様バージョン2.1（http://java.sun.com/products/servlet/2.1/ index.html）。
[svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the Printer Abstract Service Type v2.0", http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/printer.2.0.en (IANA Registered, May 27, 2000).
[SVRLOC-PRINTER] St. Pierre、P.、Isaacson、S.、McDonald、I。、「プリンターの定義抽象サービスタイプV2.0」、http：//www.isi.edu/in-notes/iana/assignments/svrloc-templates/printer.2.0.en（IANA登録、2000年5月27日）。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
[SSL] Netscape、The SSLプロトコル、バージョン3、（テキストバージョン3.02）、1996年11月。
Thomas N. Hastings Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
トーマス・N・ヘイスティングス・ゼロックス・コーポレーション701 Aviation Blvd.El Segundo、CA 90245
EMail: hastings@cp10.es.xerox.com
Carl-Uno Manros Independent Consultant 1601 N. Sepulveda Blvd. #505 Manhattan Beach, CA 90266
Carl-Uno Manros Independent Consultant 1601 N. Sepulveda Blvd.＃505マンハッタンビーチ、CA 90266
Email: carl@manros.com
Carl Kugler Mail Stop 003G IBM Printing Systems Co 6300 Diagonal Hwy Boulder CO 80301
Carl Kugler Mail Stop 003g IBM Printing Systems Co 6300 Diagonal Hwy Boulder Co 80301
EMail: Kugler@us.ibm.com
Henrik Holst i-data Printing Systems Vadstrupvej 35-43 2880 Bagsvaerd, Denmark
Henrik Holst I-Data印刷システムVadstrupvej 35-43 2880 Bagsvaerd、デンマーク
EMail: hh@I-data.com
Peter Zehler Xerox Corporation 800 Philips Road Webster, NY 14580
Peter Zegler Xerox Corporation 800 Phillips Road Webster、NY 14580
EMail: PZehler@crt.xerox.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
IPPメーリングリストを購読するには、次のメールを送信してください。
1) send it to majordomo@pwg.org 2) leave the subject line blank 3) put the following two lines in the message body: subscribe ipp end
1) majordomo@pwg.orgに送信します2）件名を空白のままにしてください3）次の2行をメッセージ本文に置きます：登録IPP End
Implementers of this specification document are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list.
この仕様文書の実装者は、追加の属性と価値に関する明確化の問題と登録提案のレビューの議論に参加するために、IPPメーリングリストに参加することをお勧めします。スパムを削減するために、メーリングリストは非登録者からのメールを拒否するため、メーリングリストに質問やコメントを送信するためにメーリングリストを購読する必要があります。
Other Participants:
他の参加者：
Chuck Adams - Tektronix Shivaun Albright - HP
チャックアダムス-Tektronix Shivaun Albright -HP
Stefan Andersson - Axis Jeff Barnett - IBM
Stefan Andersson -Axis Jeff Barnett -IBM
Ron Bergman - Hitachi Koki Dennis Carney - IBM Imaging Systems
Ron Bergman -Hitachi Koki Dennis Carney -IBMイメージングシステム
Keith Carter - IBM Angelo Caruso - Xerox
キース・カーター-IBMアンジェロ・カルーソ - ゼロックス
Rajesh Chawla - TR Computing Nancy Chen - Okidata Solutions
Rajesh Chawla -TRコンピューティングナンシーチェン - オキダタソリューション
Josh Cohen - Microsoft Jeff Copeland - QMS
Josh Cohen -Microsoft Jeff Copeland -QMS
Andy Davidson - Tektronix Roger deBry - IBM
アンディ・デイビッドソン - テクトロニックス・ロジャー・デブリー-IBM
Maulik Desai - Auco Mabry Dozier - QMS
Maulik Desai -Auco Mabry Dozier -QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh Systems
Lee Farrell -Canon Information Satoshi Fujitami -ricoh Systems
Steve Gebert - IBM Sue Gleeson - Digital
Steve Gebert -IBM Sue Gleeson -Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
チャールズ・ゴードン - オシコム・ブライアン・グリムショー - アップル
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Stephen Holmstead Zhi -Hong Huang -Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
スコット・アイザックソン - ノベル・バベック・ジャフロ - マイクロソフト
Swen Johnson - Xerox David Kellerman - Northlake Software
Swen Johnson -Xerox David Kellerman -Northlake Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
ロバート・クライン - トゥルセプトラ・チャールズ・コング - パナソニック
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Carl Kugler -IBM Dave Kuntz -Hewlett -Packard
Takami Kurono - Brother Rick Landau - Digital
タカミクロノ - 兄弟リックランダウ - デジタル
Scott Lawrence - Agranot Systems Greg LeClair - Epson
スコット・ローレンス - アグラノット・システムグレッグ・レクレア - エプソン
Dwight Lewis - Lexmark Harry Lewis - IBM
ドワイトルイス - レックスマークハリールイス-IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Tony Liao -Vivid Image Roy Lomicka -Digital
Pete Loya - HP Ray Lutz - Cognisys
Pete Loya -HP Ray Lutz -Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
マイク・マッカイ-Novell、Inc。David Manchala -Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Carl -Uno Manros -Xerox Jay Martin-アンダースコア
Stan McConnell - Xerox Larry Masinter - Xerox
スタン・マッコネル - Xerox Larry Masinter -Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
サンドラ・マッツ - ヒューレット・パッカード・ピーター・ミカレック - シャインソフト
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
IRAマクドナルド-High North Inc. Mike Moldovan -G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Tetsuya Morita -ricoh Yuichi niwa -ricoh
Pat Nogay - IBM Ron Norton - Printronics
パットノガイ-IBMロンノートン - プリントロニクス
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Hugo Parra、Novell Bob Pentecost -Hewlett -Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec Technologies
パトリック・パウエル - アスター・ジェフ・ラコウィッツ - インターメックテクノロジー
Eric Random - Peerless Rob Rhoads - Intel
エリックランダム-Peerless Rob Rhoads -Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
Xavier Riley -Xerox Gary Roberts -Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Kris Schoff -HP Katsuaki Sekiguchi -Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Bob Setterbo -Adobe Gail Songer -Peerless
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
田中秀樹 - キヤノン・デボン・テイラー-Novell、Inc。
Mike Timperman - Lexmark Atsushi Uchino - Epson
マイク・ティンパーマン - レックスマーク・アトシュシノ - エプソン
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
浅田清 - カノンボブフォンアンデル - アレグロソフトウェア
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
ウィリアム・ワーグナー - ネッツィリコン/DPIジム・ウォーカー - ダゼル
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
クリスウェンズ - インターワーキングラボトレバーウェルズ - ヒューレットパッカード
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Craig Whittle -Sharp Labs Rob Whittle -Novell、Inc。
Jasper Wong - Xionics Don Wright - Lexmark
Jasper Wong -Xionics Don Wright -Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
マイケル・ウー - ハイデルベルク・デジタル・リック・ヤルドゥミアン - ゼロックス
Michael Yeung - Toshiba Lloyd Young - Lexmark
マイケル・ヨン - 東芝ロイド・ヤング - レックスマーク
Atsushi Yuki - Kyocera Peter Zehler - Xerox
アトシュユキ - 京セラピーターゼーラー - ゼロックス
William Zhang- Canon Information Frank Zhao - Panasonic Systems
William Zhang- Canon Information Frank Zhao-パナソニックシステム
Steve Zilles - Adobe Rob Zirnstein - Canon Information Systems
Steve Zilles -Adobe Rob Zirnstein -Canon Information Systems
In addition to this document, the base set of IPP documents includes:
このドキュメントに加えて、IPPドキュメントのベースセットには以下が含まれます。
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910].
「インターネット印刷プロトコルの設計目標」ドキュメントは、分散した印刷機能を幅広く見ています。また、インターネットの印刷プロトコルに含める必要がある機能を明確にするのに役立つ実生活のシナリオを列挙します。エンドユーザー、オペレーター、および管理者の3種類のユーザーの要件を特定します。IPP/1.0 [RFC2566、RFC2565]で満たされるエンドユーザー要件のサブセットを呼び出します。IPP/1.1 [RFC2911、RFC2910]にいくつかのオプションのオペレーター操作が追加されています。
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF IPP working group's major decisions.
「インターネット印刷プロトコルの構造とモデルとプロトコルの根拠」ドキュメントは、高レベルのビューからのIPPを説明し、IPP仕様ドキュメントのスイートを形成するさまざまなドキュメントのロードマップを定義し、IETF IPPの背景と根拠を提供します。ワーキンググループの主要な決定。
The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
「インターネット印刷プロトコル/1.1：モデルとセマンティクス」ドキュメントでは、抽象的なオブジェクト、属性、および操作を備えた簡略化されたモデルについて説明しています。このモデルは、プリンターとジョブを紹介します。ジョブは、ジョブあたりの複数のドキュメントをサポートしています。モデルドキュメントでは、セキュリティ、国際化、およびディレクトリの問題に対処する方法についても説明します。
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting a message body over HTTP whose Content-Type is "application/ipp". This document defines the 'ipp' scheme for identifying IPP printers and jobs.
「インターネット印刷プロトコル/1.1：エンコーディングとトランスポート」ドキュメントは、モデルドキュメントで定義されている抽象操作とhttp/1.1 [RFC2616]に定義されている属性の正式なマッピングです。また、「Application/IPP」と呼ばれる新しいインターネットMIMEメディアタイプのエンコーディングルールを定義します。このドキュメントでは、コンテンツタイプが「アプリケーション/IPP」であるHTTPを介してメッセージ本文を輸送するためのルールも定義しています。このドキュメントでは、IPPプリンターとジョブを識別するための「IPP」スキームを定義しています。
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
「LPDとIPPプロトコル間のマッピング」ドキュメントは、IPPとLPD（Line Printer Daemon）の実装の間のゲートウェイの実装者にアドバイスを提供します。
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。