RFC3196 日本語訳
3196 Internet Printing Protocol/1.1: Implementor's Guide. T. Hastings,C. Manros, P. Zehler, C. Kugler, H. Holst. November 2001. (Format: TXT=200720 bytes) (Obsoletes RFC2639) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループT.ヘイスティングズの要求をネットワークでつないでください: 3196C.Manrosは以下を時代遅れにします。 2639年のP.Zehlerカテゴリ: 情報のゼロックスのPrinting Systems Co H.ホルストi-データPrinting Systems社のC.クーグラーIBM2001年11月
Internet Printing Protocol/1.1: Implementor's Guide
インターネット印刷プロトコル/1.1: 作成者のガイド
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).
このドキュメントは1セットのドキュメントの1つであり、どれが新しいインターネットPrintingプロトコル(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
1つの序論… 4 1.1 順応言語… 5 他の1.2用語… 6 1.3冊は相互運用性からテスト出来事を上げました… 6 2IPPは反対します… 6 3のIPP操作… 7 3.1 一般的な意味論… 7 3.1 操作属性の.1概要… 8 3.1 .2はIPP物のための操作処理ステップを示しました… 16 3.1 .2 .1はすべてのOperationsのためにOperation Processing Stepsを示しました。 17 3.1 .2 .1 .1 バージョン番号を有効にしてください… 18 3.1 .2 .1 .2 操作識別子を有効にしてください… 20 3.1 .2 .1 .3 要求識別子を有効にしてください… 20 3.1 .2 .1 .4 属性グループ、属性存在、および注文を有効にしてください… 20 3.1 .2 .1 .4 .1は属性グループの存在と注文を有効にします。 20 3.1 .2 .1 .4 .2 予想された位置で未知の属性グループを無視してください… 21
Hastings, et al. Informational [Page 1] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [1ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.2.1.4.3 必要なOperation属性のただ一つの発生の存在を有効にしてください… 21 3.1 .2 .1 .5 REQUIRED Operation属性の値を有効にしてください… 29 3.1 .2 .1 .6 OPTIONAL Operation属性の値を有効にしてください… .2はOperationsのためにAdditional Processing Stepsを示しました。33 3.1 .2、そのCreate/はジョブスとAdd Documentsを有効にします… 37 3.1 .2 .2 .1 デフォルト「ipp属性信義」か供給される… 37 3.1 .2 .2 .2 Printer物が受諾仕事であることをチェックしてください… 38 3.1 .2 .2 .3 Job Template属性の値を有効にしてください… 38 3.1 .2 仕事の合法化のための.3アルゴリズム… 39 3.1 .2 .3 .1は闘争しているJob Template属性値がないかどうかチェックします。 45 3.1 .2、.2が決める.3、REJECTへの要求… 46 3.1 .2 .3 .3 Validate-仕事の操作、成功ステータスコードのRETURN1のために… 48 3.1 .2 .3 .4 支持する属性があるJob物を作成してください… 48 3.1 .2 .3 .5 成功ステータスコードの1つを返してください… 50 3.1 .2 .3 .6 追加されたDocument Contentを受け入れてください… 50 3.1 .2 .3 .7 仕事を処理し始めます計画をして、… 50 3.1 .2 .3 .8 仕事を完了します… 50 3.1 .2 .3 .9 完成の後にJobを破壊します… 51 3.1 .2 .3 「ipp属性信義」との.10相互作用… 51 3.1 .2 .3 .11 文字の組コード変換サポート… 51 3.1 .2 .3 .12 サポートされないcharsetが要求されているとき戻るどんなcharset(問題1.19)? ....................... 52 3.1 .2 .3 .13 自然言語オーバーライド(NLO)… 53 3.1 .3 操作で状態コードは戻りました… 55 3.1 .3 .1 プリンタ操作… 55 3.1 .3 .1 .1印刷仕事… 55 3.1 .3 .1 .2印刷URI… 58 3.1 .3 .1 .3 仕事を有効にします… 58 3.1 .3 .1 .4 雇用を創り出します… 58 3.1 .3 .1 .5 プリンタ属性を得てください… 59 3.1 .3 .1 .6 ジョブスを得ます… 60 3.1 .3 .1 .7くぎりプリンタ… 61 3.1 .3 .1 .8履歴書プリンタ… 62 3.1 .3 .1 .8 .1 エラー条件のため状態を変えることができないPrintersはどうですか? 63 3.1 .3 .1 .8 .2 「プリンタ状態」はResume-プリンタの上でどのように扱われますか? 63 3.1 .3 .1 .9パージプリンタ… 63 3.1 .3 .2 仕事の操作… 64 3.1 .3 .2 .1 ドキュメントを発信させます… 64 3.1 .3 .2 .2 URIを発信させます… 65 3.1 .3 .2 .3キャンセル仕事… 65 3.1 .3 .2 .4 仕事の属性を得てください… 67 3.1 .3 .2 .5保持仕事… 68 3.1 .3 .2 .6リリース仕事… 69
Hastings, et al. Informational [Page 2] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [2ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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
3.1.3.2.7 再開仕事… 69 3.1 .3 .2 .7 .1 再開している仕事にドキュメントを加えることができますか? 69 3.1 .4 Get-Xxxx応答(問題1.18)におけるサポートされない属性を返します… 70 3.1 .5の送付の空の属性は分類されます… 70 3.2 プリンタ操作… 71 3.2 .1 印刷仕事の操作… 71 3.2 .1 .1 Print-仕事の要求(問題1.22)のデータ部を制御して、流れてください… 71 3.2 .1 .2 Print-仕事の応答(問題1.30)で仕事状態を返します。 71 3.2 .2 プリンタ属性を得ている操作… 72 3.2 .3 ジョブスを得ている操作… 72 3.2 .3 .1 ジョブスを得る、私、-仕事は'本当'、そして、および'要求しているユーザ名'(問題1.39)と等しいです--… 72 3.2 .3 .2 「限界」属性はなぜGet-ジョブス操作中ですか? 73 3.2 .4 雇用を創り出している操作… 73 3.3 仕事の操作… 74 3.3 .1 仕事を有効にします… 74 3.3 .2再開仕事… 74 4 物の属性… 74 4.1 構文のものを結果と考えてください… 74 4.1 .1 'なにも'は空集合のために(問題1.37)を評価します… 74 4.1 .2のマルチ評価された属性(問題1.31)… 75 4.1 .3 URI(問題1.6)における感度をケースに入れてください… 75 4.1 .4 xxxWithLanguageとxxxWithoutLanguageに、最大の長さ。 76 4.2 仕事のテンプレート属性… 76 4.2 .1 複数のドキュメント処理(type2キーワード)… 76 4.2 .1 .1 複数のドキュメント仕事のサポート… 76 4.3 職務記述書属性… 76 4.3 .1 日付と時刻を得ます… 76 4.4 プリンタ記述属性… 77 4.4 .1の列に並ばせられた仕事のカウント(整数(0: MAX))… 77 4.4 .1 .1 「列に並ばせられた仕事のカウント」RECOMMENDEDはなぜ(問題1.14)ですか? 77 4.4 .1 .2 「列に並ばせられた仕事のカウント」はプリンタがどれくらい忙しいかに関する良い測定(問題1.15)ですか? 77 4.4 .2 プリンタ電流時間(dateTime)… 78 4.4 .3プリンタ-uri… 78 4.5 ジョブスを空にしてください… 79 5 ディレクトリ問題… 79 5.1 一般ディレクトリ図式問題… 79 DNS名がある5.2IPP Printer… 79 6 セキュリティ問題… 80 6.1 IPPとの仕事について質問して、他のジョブ依頼プロトコル(問題1.32)を使用することでそれを提出しました… 80 7 コード化と輸送… 81 7.1個の一般ヘッダー… 83 7.2 ヘッダーを要求してください… 84
Hastings, et al. Informational [Page 3] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [3ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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
7.3 応答ヘッダー… 86 7.4 実体ヘッダー… 87 7.5 HTTP/1.0の任意のサポート… 88 7.6 HTTP/1.1分魂化… 88 7.6 .1 IPPサーバ応答分魂化を無効にします… 88 7.6 .2 Chunked要求のサポートを警告します… 88 8つの参照箇所… 89 9人の作者のアドレス… 基地のIPPドキュメントの91 10記述… 94 11の完全な著作権宣言文… 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
1を見送ってください--送付者が供給しなければならないPrinter操作属性の概要。 8 テーブル2--送付者が供給するかもしれないPrinter操作属性の概要… 10 テーブル3--送付者が供給しなければならないJob操作属性の概要… 12 テーブル4--送付者が供給するかもしれないJob操作属性の概要… 14 テーブル5--プリンタ操作応答属性… 16 IPPバージョンを有効にして、6--例を見送ります。 19は7を見送ります--Z.に対してただ一つの値Xを有効にするための規則 40
1. Introduction
1. 序論
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 Model、Semantics[RFC2911]、IPP Transport、およびEncoding[RFC2910]が記録する情報を含んでいます。 implementersが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のためにImplementorのガイドであったRFC2639を時代遅れにします。 IPP Implementorのガイド(IIG)(このドキュメント)は補足のIPP Model、Semantics[RFC2911]、IPP Transport、およびEncoding[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]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコルのためのプロトコルのデザイン目標[RFC2568]
Hastings, et al. Informational [Page 4] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [4ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementor's Guide (this
document)
Mapping between LPD and IPP Protocols [RFC2569]
インターネット印刷プロトコル/1.1: モデルと意味論[RFC2911]インターネット印刷プロトコル/1.1: コード化と輸送[RFC2910]インターネット印刷プロトコル/1.1: LPDとIPPの間でプロトコルを写像する作成者のガイド(このドキュメント)[RFC2569]
See section 10 for a description of these base IPP documents. Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order.
これらのベースIPPドキュメントの記述に関してセクション10を見てください。 初めてこれらのドキュメントを読んでいるだれでも上記のオーダーにおけるIPPドキュメントを読むよう強く奨励されます。
As such the information in this document is not part of the formal specification of IPP/1.1. Instead information is presented to help implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565, RFC2566], including some of the motivation for decisions taken by the committee in developing the specification. Some of the implementation considerations are intended to help implementers design their client and/or IPP object implementations. If there are any contradictions between this document and [RFC2911] or [RFC2910], those documents take precedence over this document.
そういうものとして、情報は本書ではIPP/1.1に関する形式仕様の一部ではありません。 代わりに、情報はimplementersがIPP/1.1を理解しているのを助けるために提示されます、IPP/1.0[RFC2565、RFC2566]と同様に、仕様を開発する際に委員会によって取られた決定に関する何らかの動機を含んでいて。 実現問題のいくつかが、implementersが彼らのクライアント、そして/または、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 Model、およびSemanticsドキュメントでは、セクションを、Modelドキュメントで本書では該当箇所に沿って、相互参照の容易さのために同じように付番します。 IPP TransportとEncodingに対応するセクションは対応する相殺されます。
1.1 Conformance language
1.1 順応言語
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].
通常、このドキュメントが用語を含んでいない、NOT、5月はNOT、SHOULD、SHOULD NOT、REQUIRED、およびOPTIONALを必要としなければなりませんか? しかしながら、彼らの意図はそれらの用語が本書では現れると、追加順応要件を指定するよりむしろ、[RFC2911]と[RFC2910]ドキュメントが必要であり、許容することを繰り返すことです。 これらの用語はそれの大部分がRFC2119[RFC2119]から取られる[RFC2911]の順応用語のセクション12で定義されます。
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.
Implementersは、これらが単語を大文字で書いたのを理解するために[RFC2911]でセクション12(APPENDIX A)を読むはずです。 単語はそうしなければなりません、とNOT、およびREQUIREDは示さなければなりません。実現が[RFC2911]と[RFC2910]へのconformantになるようにクライアントかIPP物で支持するのに必要である何。 NOTを必要として、あった、OPTIONALが、示すimplementerオプションとして単に許容されるかもしれません。 SHOULDとSHOULD NOTが示す動詞が振舞いを示しましたが、どれが、仕様に従うためにそれぞれ必要ではありませんかそれとも、または禁じられませんか?
Hastings, et al. Informational [Page 5] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [5ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
1.2 Other terminology
1.2 他の用語
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物を呼びます、そして、クライアントに、それは応答を受けます。
1.3 Issues Raised from Interoperability Testing Events
1.3冊は相互運用性からテスト出来事を上げました。
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開いているInteroperability Testing Eventsを行いました。 最初のものは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.
最初のInteroperability Testing Eventから提起された問題を、本書では番号付の1.nであり、「IPP/1.0モデルと意味論」[RFC2566]と「IPP/1.0コード化と輸送」[RFC2565]というドキュメントに組み入れてあります。 しかしながら、ここ、Implementorのガイドでは、議論のいくつかが、分かるのを助けるのが残されます。
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.
本書では「IPP/1.1モデルと意味論」[RFC2911]と「IPP/1.1コード化と輸送」[RFC2910]というドキュメントにInteroperability Testing Eventが番号付の2.nである秒から提起された問題を組み入れてあります。 しかしながら、ここ、Implementorのガイドでは、議論のいくつかが、分かるのを助けるのが残されます。
The issues raised from the third Interoperability Testing Event are numbered 3.n in this document and are described in:
第3Interoperability Testing Eventから提起された問題は、本書では番号付の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
Hastings, et al. Informational [Page 6] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [6ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
2. IPP Objects
2. IPP物
The term "client" in IPP is intended to mean any client that issues IPP operation requests and accepts IPP operation responses, whether it be a desktop or a server. In other words, the term "client" does not just mean end-user clients, such as those associated with desktops.
IPPの「クライアント」という用語は操作要求をIPPに出して、IPP操作応答を受け入れるどんなクライアントも意味するつもりです、それがデスクトップかサーバであることにかかわらず。言い換えれば、「クライアント」という用語はただエンドユーザクライアントを意味しません、デスクトップに関連づけられたものなどのように。
The term "IPP Printer" in IPP is intended to mean an object that accepts IPP operation requests and returns IPP operation responses, whether implemented in a server or a device. An IPP Printer object MAY, if implemented in a server, turn around and forward received jobs (and other requests) to other devices and print servers/services, either using IPP or some other protocol.
IPPの「IPPプリンタ」という用語がIPP操作要求を受け入れて、操作応答をIPPに返す物を意味することを意図します、サーバか装置で実行されるか否かに関係なく。 IPP Printer物は、対向機器とプリント・サーバ/サービス(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.1ModelとSemanticsドキュメント[RFC2911]で「IPP操作」というセクション3に対応します。
3.1 Common Semantics
3.1 一般的な意味論
This section discusses semantics common to all operations.
このセクションはすべての操作に共通の意味論について論じます。
Hastings, et al. Informational [Page 7] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [7ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.1 Summary of Operation Attributes
3.1.1 操作属性の概要
Table 1 - Summary of Printer operation attributes that sender MUST
supply
テーブル1--送付者が供給しなければならないPrinter操作属性の概要
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を要求します。(○ +)
Operation parameters--REQUIRED to be supplied by the sender:
運転パラメータ--、送付者によって供給されるべきREQUIRED:
operation-id R R R R R R
操作イドR R R R R R
status-code R
ステータスコードR
request-id R R R R R R R
要求イド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:
操作属性--、送付者によって供給されるべきREQUIRED:
attributes- R R R R R R R
charset
属性R R R R R R R charset
attributes- R R R R R R R
natural-
language
属性R R R R R R自然なR言語
document-uri R
ドキュメント-uri R
job-id*
仕事イド*
job-uri*
仕事uri*
Hastings, et al. Informational [Page 8] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [8ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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、All Attributes VJ(O)(O)(R)(R)RP、PP(○ +)が最後に記録するOperations(R)
printer-uri R R R R R R
プリンタ-uri R R R R R R
Operation attributes--RECOMMENDED to be supplied by the
sender:
操作属性--、送付者によって供給されるべきRECOMMENDED:
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: 印刷仕事、仕事を有効にしているPu: 印刷URI CJ: 雇用を創り出しているGPA: プリンタ属性を得ているGJ: ジョブスを得ているpp、RP、pp: くぎりプリンタ、Resume-プリンタ、Purge-プリンタRはIPP物(プリンタかJob)で後押しされていなければならないREQUIRED操作を必要とします。 属性のために、Rは、関連操作を支持するIPP物で属性を支持しなければならないのを示します。 OはIPP物(プリンタかJob)によって支持されるかもしれないOPTIONAL操作か属性を必要とします。 +は、これがIPP/1.0の特徴でないことを示しますが、IPP/1.1の一部とIPPの将来のバージョンにすぎません。
Hastings, et al. Informational [Page 9] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [9ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Table 2 - Summary of Printer operation attributes that sender MAY
supply
テーブル2--送付者が供給するかもしれないPrinter操作属性の概要
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 Attributes PJ、PU CJ GPA GJ PP、All VJ(O)(O)(R)(R)RP Opera(R)PP tions(○ +)
Operation attributes--OPTIONAL to be supplied by the sender:
操作属性--、送付者によって供給されるべきOPTIONAL:
status-message O
ステータスメッセージO
detailed-status- O
message
詳細な状態のOのメッセージ
document-access- O**
error
ドキュメント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 R Rを結果と考えているR信義
job-impressions O O O
仕事印象O O O
job-k-octets O O O
仕事のk八重奏O O O
job-media-sheets O O O
仕事のメディアシートO O O
Hastings, et al. Informational [Page 10] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [10ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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 Attributes PJ、PU CJ GPA GJ PP、All VJ(O)(O)(R)(R)RP Opera(R)PP tions(○ +)
limit R
限界R
message
メッセージ
my-jobs R
私、-、仕事、R
requested-attributes R R
要求された属性R R
which-jobs R
どれ、-、仕事、R
Legend:
伝説:
PJ, VJ: Print-Job, Validate-Job
PU: Print-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Print-URI response only.
PJ、VJ: 印刷仕事、仕事を有効にしているPu: 印刷URI CJ: 雇用を創り出しているGPA: プリンタ属性を得ているGJ: ジョブスを得ているpp、RP、pp: くぎりプリンタ、Resume-プリンタ、Purge-プリンタRはIPP物(プリンタかJob)で後押しされていなければならないREQUIRED操作を必要とします。 属性のために、Rは、関連操作を支持するIPP物で属性を支持しなければならないのを示します。 OはIPP物(プリンタかJob)によって支持されるかもしれないOPTIONAL操作か属性を必要とします。 +は、これがIPP/1.0の特徴でないことを示しますが、IPP/1.1の一部とIPPの将来のバージョンにすぎません。 * 目標仕事を特定するのに「プリンタ-uri」と共に使用される場合にだけ、「仕事イド」はREQUIREDです。 さもなければ、「仕事-uri」はREQUIREDです。 ** 「ドキュメントアクセスエラー」はPrint-URI応答だけに適用されます。
Hastings, et al. Informational [Page 11] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [11ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Table 3 - Summary of Job operation attributes that sender MUST supply
テーブル3--送付者が供給しなければならないJob操作属性の概要
Job Operations
仕事の操作
Requests Responses
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
要求Responses OperationサウスダコタSU CJ GJA HJ All Attributes(O)(O)(R)(R)RJ、RJ Opera(○ +)tions
Operation parameters--REQUIRED to be supplied by the sender:
運転パラメータ--、送付者によって供給されるべきREQUIRED:
operation-id R R R R R
操作イドR R R R R
status-code R
ステータスコードR
request-id R R R R R R
要求イド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:
操作属性--、送付者によって供給されるべきREQUIRED:
attributes-charset R R R R R R
属性-charset R R R R R R
attributes-natural- R R R R R R
language
属性当然のR RのR R R R言語
document-uri R
ドキュメント-uri R
job-id* R R R R R
賃仕事のイド*R RのR R R
job-uri* R R R R R
仕事のuriな*R R R R R
last-document R R
最後のドキュメントR R
printer-uri R R R R R
プリンタ-uri R R R R R
Operation attributes--RECOMMENDED to be supplied by the sender:
操作属性--、送付者によって供給されるべきRECOMMENDED:
job-name
ジョブ名
Hastings, et al. Informational [Page 12] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [12ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Job Operations
仕事の操作
Requests Responses
応答を要求します。
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
操作サウスダコタSU CJ GJA HJ All Attributes(O)(O)(R)(R)RJ、RJ Opera(○ +)tions
requesting-user- R R R R R
name
要求しているユーザの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.
サウスダコタ: ドキュメントを発信させているSU: URIを発信させているCJ: キャンセル仕事のGJA: 仕事の属性を得ているHJ、RJ、RJ: 保持仕事、Release-仕事、Restart-仕事のRはIPPオブジェクト(プリンタかJob)で後押しされていなければならないREQUIRED操作を必要とします。 属性のために、Rは、関連操作をサポートするIPPオブジェクトで属性をサポートしなければならないのを示します。 OはIPPオブジェクト(プリンタかJob)によってサポートされるかもしれないOPTIONAL操作か属性を必要とします。 +は、これがIPP/1.0の特徴でないことを示しますが、IPP/1.1の一部とIPPの将来のバージョンにすぎません。 * 目標仕事を特定するのに「プリンタ-uri」と共に使用される場合にだけ、「仕事イド」はREQUIREDです。 さもなければ、「仕事-uri」はREQUIREDです。
Hastings, et al. Informational [Page 13] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [13ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Table 4 - Summary of Job operation attributes that sender MAY supply
テーブル4--送付者が供給するかもしれないJob操作属性の概要
Job Operations
仕事の操作
Requests Responses
応答を要求します。
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
操作SD SU CJ GJA HJ、サウスダコタAll Attributes(O)(O)(R)(R)RJ(O)オペラRJ tions(○ +)
Operation attributes--OPTIONAL to be supplied by the sender:
操作属性--、送付者によって供給されるべきOPTIONAL:
status-message O
ステータスメッセージO
detailed-status- O
message
詳細な状態のOのメッセージ
document-access- O**
error
ドキュメントOにアクセスしている**誤り
compression R R
圧縮R R
document-format R R
ドキュメント・フォーマットR R
document-name O O
ドキュメント名のO O
document-natural- O O
language
ドキュメント当然のO Oの言語
ipp-attribute-
fidelity
ipp-属性信義
job-impressions
仕事印象
job-k-octets
仕事のk八重奏
job-media-sheets
仕事のメディアシート
Hastings, et al. Informational [Page 14] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [14ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Job Operations
仕事の操作
Requests Responses
応答を要求します。
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
操作SD SU CJ GJA HJ、サウスダコタAll Attributes(O)(O)(R)(R)RJ(O)オペラRJ tions(○ +)
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
サウスダコタ: ドキュメントを発信させているSU: URIを発信させているCJ: キャンセル仕事のGJA: 仕事の属性を得ているHJ、RJ、RJ: 保持仕事、Release-仕事、Restart-仕事のRはIPPオブジェクト(プリンタかJob)で後押しされていなければならないREQUIRED操作を必要とします。 属性のために、Rは、関連操作をサポートするIPPオブジェクトで属性をサポートしなければならないのを示します。 OはIPPオブジェクト(プリンタかJob)によってサポートされるかもしれないOPTIONAL操作か属性を必要とします。 +は、これがIPP/1.0の特徴でないことを示しますが、IPP/1.1の一部とIPPの将来のバージョンにすぎません。 * 目標仕事を特定するのに「プリンタ-uri」と共に使用される場合にだけ、「仕事イド」はREQUIREDです。 さもなければ、「仕事-uri」はREQUIREDです。 ** 「ドキュメントアクセスエラー」はSend-URI操作だけに適用されます。
Hastings, et al. Informational [Page 15] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [15ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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、属性サウスダコタ(o)SU(o)(R)RP、pp(○ +)
job-uri R R R
仕事-uri R R R
job-id R R R
仕事イドR R R
job-state R R R
仕事州のR R R
job-state- R+ R+ R+
reasons
仕事州R+R+R+理由
number-of- O O O
intervening-
jobs
数、-、O O O介入している仕事
document- O
access-
error+
ドキュメントOアクセス誤り+
Legend:
伝説:
PJ, SJ: Print-Job, Send-Document
VJ: Validate-Job
PU, SU: Print-URI, Send-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
PJ、SJ: 印刷仕事、ドキュメントを発信させているVJ: 仕事を有効にしているPu、SU: 印刷URI、URIを発信させているCJ: 雇用を創り出しているGPA: プリンタ属性を得ているGJ: ジョブスを得ているpp、RP、pp: くぎりプリンタ、Resume-プリンタ、Purge-プリンタRはIPPオブジェクト(プリンタかJob)で後押しされていなければならないREQUIRED操作を必要とします。 属性のために、Rは、関連操作をサポートするIPPオブジェクトで属性をサポートしなければならないのを示します。 OはIPPオブジェクト(プリンタかJob)によってサポートされるかもしれないOPTIONAL操作か属性を必要とします。
3.1.2 Suggested Operation Processing Steps for IPP Objects
3.1.2 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
このセクションは要求を処理して、応答を返すときIPPオブジェクトが実行するかもしれないステップとエラーチェックを示します。 IPPオブジェクトはエラーチェックのいくつかかすべてを実行するかもしれません。 しかしながら、いくつか
Hastings, et al. Informational [Page 16] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [16ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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オブジェクトのimplementerは、「寛大な」実装ですかそれとも「厳しい」実装であるかを決める必要があります。 したがって、コードが返したエラー状況は実装の間で異なるかもしれません。 結果的に、クライアントSHOULD NOTはまさにこのセクションで説明されたエラーコード処理を予想します。
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オブジェクトSHOULDは以下のステップを実行します。 グループの一人となるのを含んでいて、ステップの注文を再配列される、そして/または、結合するかもしれませんか、または倍数は要求を通り過ぎます。
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.
クライアントは従っているクライアントになるようにここで示されたエラーチェックのすべてを通過する要求を提供しなければなりません。 したがって、SHOULDがいくつかの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状態がコード化するRETURNS」まで一歩一歩続きます… 声明は遭遇します。 誤りリターンは動詞によって示されます: 「拒絶します」。 クライアントがPrint-仕事の要求におけるドキュメントデータのすべてを送る前にステータスコードを得るのに苦労するので、印刷されるために大きいドキュメントを送る前にクライアントSHOULDがValidate-仕事の操作を使用する、IPP Printerが仕事を受け入れるか否かに関係なく、有効にします。
It is assumed that security authentication and authorization has already taken place at a lower layer.
それはそのセキュリティ認証であると思われます、そして、承認は下層で既に行われました。
3.1.2.1 Suggested Operation Processing Steps for all Operations
3.1.2.1 すべてのOperationsのための提案されたOperation Processing Steps
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-仕事のための追加ステップ、雇用を創り出すValidate仕事、Print-URI、Create-仕事、Send-ドキュメント、およびSend-URI操作を含んでいて、ドキュメントを加えて、仕事を有効にします。
Hastings, et al. Informational [Page 17] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [17ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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
IIG Sect#Flow IPP誤りステータスコード---------- ---- ---------------------- | vが間違える、3.1 .2 .1 .1<Validateバージョン>--、>サーバ誤りバージョンでサポートしていないOK| vが間違える、3.1 .2 .1 .2 <Validate操作>--、>サーバ誤り操作でサポートしていないOK| vが間違える、3.1 .2 .1 .4 .1<のValidate存在>--、>クライアントの誤りの悪い要求3.1.2、.1、.4、属性>OKの.2<。| vが3.1に間違える、.2、.1、.4、.3<Validate存在>、--操作の>クライアントの誤りの悪い要求<がOKに>をattrする| vが間違える、>の3.1の.2.1.5<Validate値、-->クライアントの誤りの悪い要求<操作がOKに>クライアント誤りまた、要求価値の長い<(長さ、タグ、範囲、><マルチ価値)>をattrsする| vが3.1に間違える、.2、.1、.5<Validateは>を評価します--サポートされるのがある>クライアントの誤りの悪い要求<は>クライアント誤り-charsetによってサポートされなかったOKを評価します。| または、クライアント誤り属性、-、-、値| vであることはサポートされなく3.1に間違えてください、.2、.1、.6<Validate、任意に、>、-->クライアントの誤りの悪い要求<操作が>クライアント誤り当然の言語によってサポートされなかった状態でattrされる| また、クライアント誤り要求価値の長いです。| または、クライアント誤り属性、-、-、サポートされなかった値
3.1.2.1.1 Validate version number
3.1.2.1.1 バージョン番号を有効にしてください。
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
あらゆる要求とあらゆる応答が「バージョン番号」属性を含んでいます。 この属性の値はクライアントとIPPがそれぞれ使用しているのを反対させる構文と意味論の主要で小さい方のバージョン番号です。 「バージョン番号」属性
Hastings, et al. Informational [Page 18] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [18ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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オブジェクトは、要求で供給されたメジャーバージョン番号がサポートされるかどうか確認するためにチェックします。 まして、Printerは反対します。要求とRETURNS'サポートされなかったサーバ誤りバージョン'状態が応答でコード化するREJECTS。 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オブジェクトは応じなければなりません。 メジャーバージョン番号が合っていますが、マイナーバージョン番号が合っているというわけではないなら、Printer SHOULDが、受け入れて、要求を処理するのを試みるか、要求を拒絶して、'サポートされなかったサーバ誤りバージョン'ステータスコードを返すかもしれません。 すべての場合では、Printerはサポートする中で最も近いバージョン番号を返さなければなりません。 例えば、IPP/1.2Printerがバージョン'1.1'と'1.2'をサポートすると仮定してください。 以下の応答は従っています:
Table 6 - Examples of validating IPP version
テーブル6--IPPバージョンを有効にする例
Client supplies Printer Accept Request? Printer returns
クライアント供給Printer Accept Request? プリンタリターン
1.0 yes (SHOULD) 1.1
1.0 はい(SHOULD)、1.1
1.0 no (SHOULD NOT) 1.1
1.0 (SHOULD NOT)1.1がありません。
1.1 yes (MUST) 1.1
1.1 はい、(MUST)1.1
1.2 yes (MUST) 1.2
1.2 はい、(MUST)1.2
1.3 yes (SHOULD) 1.2
1.3 はい(SHOULD)、1.2
1.3 no (SHOULD NOT) 1.2
1.3 (SHOULD NOT)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.
PrintersがIPP/1.1とIPP/1.0の両方をサポートするのは、彼らがクライアント実装で共同利用できるくらい有利です。 いくつかの実装で、Administratorは、「バージョンがサポートしたipp」Printer記述属性を設定することによって、明らかに1のサポートかもう片方を無効にすることができるかもしれません。
Hastings, et al. Informational [Page 19] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [19ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Likewise, it is advantageous for clients to support both versions to allow interoperability with new and legacy Printers.
同様に、クライアントが新しい、そして、レガシーPrintersがある相互運用性を許容するために両方のバージョンをサポートするのは、有利です。
3.1.2.1.2 Validate operation identifier
3.1.2.1.2 操作識別子を有効にしてください。
The Printer object checks to see if the "operation-id" attribute supplied by the client is supported as indicated in the Printer object's "operations-supported" attribute. If not, the Printer REJECTS the request and returns the 'server-error-operation-not- supported' status code in the response.
Printerオブジェクトは、クライアントによって供給された「操作イド」属性がPrinterオブジェクトの「操作でサポートしている」属性にみられるようにサポートされるかどうか確認するためにチェックします。 そうでなければ、Printer REJECTS、'サーバ誤り操作でサポートしていない'状態が応答でコード化する要求とリターン。
3.1.2.1.3 Validate the request identifier
3.1.2.1.3 要求識別子を有効にしてください。
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.
PrinterオブジェクトSHOULD NOTはクライアントによって供給された「要求イド」属性が範囲にあるかを確認するためにチェックします: しかし、1と2**31--1(包括的な)、コピーの間ですべての32ビット。
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.
以下に注意してください。 「バージョン番号」、「操作イド」、および「要求イド」パラメタがIPP/1.1コード化における固定八重奏位置にあります。 「バージョン番号」パラメタはプロトコルのすべてのバージョンで同じ固定八重奏位置になるでしょう。 合法化の残りを続ける前に、これらの分野は有効にされます。
3.1.2.1.4 Validate attribute group and attribute presence and order
3.1.2.1.4 属性グループ、属性存在、および注文を有効にしてください。
The order of the following validation steps depends on implementation.
以下の合法化ステップの注文は実装によります。
3.1.2.1.4.1 Validate the presence and order of attribute groups
3.1.2.1.4.1 属性グループの存在と注文を有効にしてください。
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.
(3) IPP目的が(1) 必要な属性グループ取り逃がすこと、または(2)と共に要求を受け取るなら属性グループが不適切であるか、グループが繰り返されて、IPPオブジェクトREJECTSは要求とRETURNS'クライアントの誤りの悪い要求'ステータスコードです。 例えば、それは一度よりOperation Attributesが分類する前にJob Template Attributesグループが起こるか、Operation Attributesグループが省略されるか、または属性グループがさらに起こる誤りです、Get-ジョブス応答を除いて。
Since this kind of attribute group error is most likely to be an error detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attribute group was
この種類の属性グループ誤りが顧客でというよりむしろクライアント開発者によって検出された誤りである最も傾向があるので、IPPオブジェクトはグループがどの属性であるかしるしを返す必要はありません。
Hastings, et al. Informational [Page 20] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [20ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
Unsupported AttributesグループかStatus Messageのどちらかでは、間違っています。 IPPも、戻る前のすべての属性グループ誤りがこの誤りであることがわかる必要はないのを反対します。
3.1.2.1.4.2 Ignore unknown attribute groups in the expected position
3.1.2.1.4.2 予想された位置で未知の属性グループを無視してください。
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.
将来の属性グループはDocument Contentのすぐ前での要求の終わりと応答の終わりの仕様に追加されるかもしれません、Get-ジョブス応答を除いて、どこ、それ、そこか属性が返した最初の仕事の前にそうかもしれない。 IPP目的がこれらの位置に未知の属性グループを受け取るなら、誤りを返すよりむしろ全体のグループを無視します、そのグループが無視できるプロトコルの後の小さい方のバージョンの新しいグループであるかもしれないので。 (クライアントを混乱させないで新しい属性グループを無視できないなら、メジャーバージョン番号はプロトコルドキュメントと要求で増強されたでしょう。) 未知のグループが異なった位置に起こって、IPPオブジェクトREJECTSが要求とRETURNS'クライアントの誤りの悪い要求'ステータスコードであるなら。
Clients also ignore unknown attribute groups returned in a response.
また、クライアントは応答で返された未知の属性グループを無視します。
Note: By validating that requests are in the proper form, IPP objects force clients to use the proper form which, in turn, increases the chances that customers will be able to use such clients from multiple vendors with IPP objects from other vendors.
以下に注意してください。 要求が適切なフォームにある有効にすることで、クライアントはIPPオブジェクトによってやむを得ず順番に、顧客がIPPオブジェクトで複数のベンダーから他のベンダーからそのようなクライアントを使用できるという可能性を増強する適切なフォームを使用します。
3.1.2.1.4.3 Validate the presence of a single occurrence of required
Operation attributes
3.1.2.1.4.3 必要なOperation属性のただ一つの発生の存在を有効にしてください。
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が存在しているのを必要とするOperation属性を含んでいます。 目標、charset、および自然言語属性の注文を除いて、グループの中の属性は順不同であるかもしれません。 これらの属性を1番目でなければならなく、以下のオーダーで供給しなければなりません: charset、自然言語、およびそして、目標。 IPPオブジェクトは、セクション4が、クライアントによって供給されるのを必要とする属性が要求(以下のテーブルの*のない属性)で供給されたことを確かめます。 アスタリスク(*)はクライアントが要求で省略するかもしれない属性かIPPオブジェクトが応答で省略するかもしれないグループとOperationを示します。
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オブジェクトの動きはIMPLEMENTATION DEPENDENTです。 可能な実装のいくつかは以下の通りです。
REJECTS the request and RETURNS the 'client-error-bad-request'
status code
要求とRETURNS'クライアントの誤りの悪い要求'状態がコード化するREJECTS
Hastings, et al. Informational [Page 21] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [21ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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オブジェクト実装から同じ振舞いを受けたいなら、クライアントは発信しなければなりません。 例えば、それは「属性-charset」か「属性自然言語」属性がどんな操作要求でも省略されるか、またはJob Templateグループで供給されるOperation属性かaのOperation Attributeグループで供給されるJob Template属性のために要求を作成する誤りです。 また、それは二度「属性-charset」属性を供給する誤りです。
Since these kinds of attribute errors are most likely to be detected by a client developer rather than by a customer, the IPP object NEED NOT return an indication of which attribute was in error in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all attribute errors before returning this error.
これらの種類の属性誤りが顧客でというよりむしろクライアント開発者によって最も検出されそうであるので、IPPオブジェクトはどの属性がUnsupported AttributesグループかStatus Messageのどちらかで間違っていたかのしるしを返す必要はありません。 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、自然言語、および目標)のいくつかで有名であるのを除いて。 以下のテーブルは以下の記法を使用します:
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を反対させるREQUIRED属性か操作が、IPPオブジェクトが*をサポートする必要はないOPTIONAL属性か操作が、クライアントが要求における属性を省略するかもしれなくて、IPPオブジェクトが応答における属性を省略するかもしれないのを示すのを示すのを示します。 *の不在は、クライアントが要求における属性を供給しなければならないことを意味します、そして、IPPオブジェクトは応答における属性を供給しなければなりません。 +は、これがIPP/1.0操作でないことを示しますが、IPP/1.1の一部とIPPの将来のバージョンにすぎません。
Hastings, et al. Informational [Page 22] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [22ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
以下に注意してください。 すべての操作要求が「バージョン番号」、「操作イド」、および「要求イド」パラメタを含んでいます。
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)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(R*)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)([RFC2911]セクション4.2を見る)グループ3: ドキュメントContent(R)<ドキュメント内容>。
Validate-Job Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2911] Section 4.2)
仕事を有効にしている要求(R): グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(R*)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)([RFC2911]セクション4.2を見ます)
Hastings, et al. Informational [Page 23] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [23ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Print-URI Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
document-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2911] Section 4.2)
印刷URI要求(o): グループ1: 操作のプリンタ-uriの(R)のドキュメント-uriの(R)の要求しているAttributes(R)属性-charset(R)属性自然言語(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(R*)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)、(見る。([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)
雇用を創り出している要求(o): グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)、(見る。([RFC2911]セクション4.2を見ます)
Get-Printer-Attributes Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
document-format (R*)
プリンタ属性を得ている要求(R): グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)の要求された属性(R*)ドキュメント・フォーマット(R*)
Get-Jobs Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
ジョブスを得ている要求(R): グループ1: 操作Attributes(R)は-charsetに(R) 属性自然言語を結果と考えます。(R)
Hastings, et al. Informational [Page 24] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [24ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
printer-uri (R)
requesting-user-name (R*)
limit (R*)
requested-attributes (R*)
which-jobs (R*)
my-jobs (R*)
要求された属性で(R*)(R) 要求しているユーザ名(R*)限界(R*)をプリンタでuriする、どれ、-、仕事、(R*)、私、-、仕事(R*)
Send-Document Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
Group 2: Document Content (R*)
<document content>
資料請求を発信させている(o): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の最後のドキュメントの(R)の要求しているユーザ名(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(R*)グループ2: ドキュメントContent(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*)
URIを発信させている要求(o): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの最後のドキュメントの(R)のドキュメント-uriの(R)の要求している(R)ユーザ名(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(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): リリース仕事の要求(○ +): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の要求しているユーザ名(R*)メッセージ(○ *)
Hastings, et al. Informational [Page 25] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [25ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Get-Job-Attributes Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
仕事の属性を得ている要求(R): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の要求しているユーザ名(R*)の要求された属性(R*)
Pause-Printer Request (O+):
Resume-Printer Request (O+):
Purge-Printer Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
くぎりプリンタ要求(○ +): 履歴書プリンタ要求(○ +): パージプリンタ要求(○ +): グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(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*)
保持仕事の要求(○ +): 再開仕事の要求(○ +): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の要求しているユーザ名(R*)、仕事の保持、(R*)メッセージ(○ *)
Operation Responses
操作応答
The tables below show the response attributes in their proper attribute groups for responses.
応答のために、分類します以下のテーブルが、それらの適切な属性における応答属性を示している。
Note: All operation responses contain "version-number", "status- code", and "request-id" parameters.
以下に注意してください。 すべての操作応答が「バージョン番号」、「状態コード」、および「要求イド」パラメタを含んでいます。
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)
印刷仕事の応答(R): 雇用を創り出している応答(o): ドキュメントを発信させている応答(o): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note3を見る)のn<のサポートされない属性>(R*)グループ3: 仕事のObject Attributes(R*)(Note2を見る)仕事-uri(R)仕事イド(R)
Hastings, et al. Informational [Page 26] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [26ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
介入している仕事の仕事州の(R)仕事の州の理由(○ *| R+)仕事の州のメッセージ(○ *)番号(○ *)
Validate-Job Response (R):
Cancel-Job Response (R):
Hold-Job Response (O+):
Release-Job Response (O+):
Restart-Job Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
仕事を有効にしている応答(R): キャンセル仕事の応答(R): 保持仕事の応答(○ +): リリース仕事の応答(○ +): 再開仕事の応答(○ +): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note3を見る)の<のサポートされない属性>。(R*)
Print-URI Response (O):
Send-URI Response (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
document-access-error (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
印刷URI応答(o): URIを発信させている応答(o): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)ドキュメントアクセスエラー(○ *)グループ2: サポートされないAttributes(R*)(Note3を見る)の<のサポートされない属性>(R*)グループ3: 介入している仕事の仕事のObject Attributes(R*)(Note2を見る)仕事-uri(R)仕事イド(R)仕事州の(R)仕事の州の理由(○ *| R+)仕事の州のメッセージ(○ *)番号(○ *)
Get-Printer-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
プリンタ属性を得ている応答(R): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>(R*)グループ3: プリンタObject Attributes(R*)(Note2を見る)<は属性>を要求しました。(R*)
Hastings, et al. Informational [Page 27] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [27ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Get-Jobs Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*)
ジョブスを得ている応答(R): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>(R*)グループ3: 仕事のObject Attributes(R*)(Note2、5を見る)<は属性>を要求しました。(R*)
Get-Job-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
仕事の属性を得ている応答(R): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>(R*)グループ3: 仕事のObject Attributes(R*)(Note2を見る)<は属性>を要求しました。(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*)
くぎりプリンタ応答(○ +): 履歴書プリンタ応答(○ +): パージプリンタ応答(○ +): グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)の詳細なステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>。(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オブジェクトが成功ステータスコードの1つを返す場合にだけ、Job Object AttributesとPrinter Object Attributesを返します。
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--クライアントがPrinterが成功か誤りリターンであることにかかわらずサポートしないいくらかのOperation、そして/または、Job Template属性か値を入れた場合にだけ、Unsupported Attributes Groupは存在しています。
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--クライアントがPrinterが成功か誤りリターンであることにかかわらずサポートしないいくつかのOperation属性を入れた場合にだけ、Unsupported Attributes Groupは存在しています。
Hastings, et al. Informational [Page 28] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [28ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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-ジョブス操作のために、別々のJob Object Attributesは応答にそれぞれの仕事のオブジェクトのための要求された属性を含む3〜Nを分類します。
3.1.2.1.5 Validate the values of the REQUIRED Operation attributes
3.1.2.1.5 REQUIRED Operation属性の値を有効にしてください。
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オブジェクトがサポートしなければならないREQUIRED Operation属性のクライアントによって供給された値を有効にします。 次のセクションはIPPオブジェクトがサポートするかもしれないOPTIONAL Operation属性の値の合法化を指定します。
The IPP object performs the following syntactic validation checks of each Operation attribute value:
IPPオブジェクトはそれぞれのOperation属性値の以下の構文の合法化チェックを実行します:
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に応じてクライアントによって供給された属性構文タグに、それぞれのOperation属性値の長さは適度です。
b) that the attribute syntax tag is correct for that Operation
attribute according to [RFC2911] Section 3,
b) そのOperation属性に、[RFC2911]セクション3によると、属性構文タグは正しいです。
c) that the value is in the range specified for that Operation
attribute according to [RFC2911] Section 3,
[RFC2911]セクション3によると、範囲に値をあるc)がそのOperation属性に指定しました。
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によると、それは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オブジェクトREJECTSが要求であり、RETURNSが'クライアントの誤りの悪い要求'か'クライアント誤り要求であるなら、あまりに長い間、'ステータスコードを評価してください。 そのような誤りが終わりのユーザでというよりむしろクライアント開発者によって検出された誤りである最も傾向があるので、IPPオブジェクトはどの属性がUnsupported Attributes GroupかStatus Messageのどちらかに誤りを持ったかしるしを返す必要はありません。 それぞれのこれらの構文チェックのための記述は以下のテーブルでの声明であるなら1番目で明らかに言い表されます。
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.
さらに、定義された「xxxによってサポートしている」Printerオブジェクト属性が全くなければ、IPPオブジェクトは何らかのPrinterオブジェクト属性か何らかの困難なコード化された値に対してそれぞれのOperation属性値をチェックします。 値がそれらの中でサポートされないか、または範囲でサポートされないで、次に、IPPオブジェクトREJECTSが要求であり、RETURNSが声明であるならテーブルで秒によって示された誤りステータスコードであるなら。 Printerオブジェクトの「xxxによってサポートしている」属性の値が'値がない'(システム管理者が値を構成していないので)であるなら、チェックはいつも失敗します。
Hastings, et al. Informational [Page 29] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [29ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
-----------------------------------------------
-----------------------------------------------
attributes-charset (charset)
属性-charset(charset)
IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
error-bad-request'.
単一の非空の'REJECT/RETURN'クライアントcharset'価値、誤りの悪い要求'でないなら。
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが63以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported".
オブジェクトのPrinterもので「charsetによってサポートしている」属性でないなら、REJECT/RETURN「charsetがサポートしなかったクライアント誤り。」です。
attributes-natural-language(naturalLanguage)
属性自然言語(naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'.
単一の非空の'naturalLanguage'でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが63以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
ACCEPT the request even if not a member of the set in the Printer
object's "generated-natural-language-supported" attribute. If the
supplied value is not a member of the Printer object's
"generated-natural-language-supported" attribute, use the Printer
object's "natural-language- configured" value.
ACCEPT、Printerのセットのどれかメンバーが反対しないでも、要求は「サポートされた発生している自然な言語」属性です。 供給値がPrinterオブジェクトの「サポートされた発生している自然な言語」属性のメンバーでないなら、Printerオブジェクトの「当然の言語で構成された」値を使用してください。
requesting-user-name
要求しているユーザ名
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
単一の'名前の'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF the IPP object can obtain a better-authenticated name, use it
instead.
IPPオブジェクトが、よりよく認証された名前を得ることができるなら、代わりにそれを使用してください。
job-name(name)
ジョブ名(名前)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
単一の'名前の'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT supplied by the client, the Printer object creates a name
from the document-name or document-uri.
クライアントによって供給されないで、Printerオブジェクトはドキュメント名から名前を作成するか、そして、ドキュメント-uri。
Hastings, et al. Informational [Page 30] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [30ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
document-name (name)
ドキュメント名(名前)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
単一の'名前の'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
ipp-attribute-fidelity (boolean)
ipp属性信義(論理演算子)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF NEITHER単一の'本当'NOR単一の'誤った''論理演算子'価値、REJECT/RETURN'クライアントの誤りの悪い要求'。
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
値の長さが1つの八重奏、REJECT/RETURNと'クライアント誤りはあまりに長い間、値を要求していた'状態で等しくないなら
IF NOT supplied by the client, the IPP object assumes the value
'false'.
クライアントによって供給されないなら、IPPオブジェクトは、値が'誤っている'と仮定します。
document-format (mimeMediaType)
ドキュメント・フォーマット(mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
'client-error-bad-request'.
単一の非空の'mimeMediaType'でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT in the Printer object's "document-format-supported"
attribute, REJECT/RETURN 'client-error-document-format-not-
supported'
いずれかのPrinterでそうしないなら、オブジェクトは「形式が支えたドキュメント」属性であり、REJECT/RETURNは'クライアント誤りドキュメント形式でサポートされない'です。
IF NOT supplied by the client, the IPP object assumes the value of
the Printer object's "document-format-default" attribute.
クライアントによって供給されないなら、IPPオブジェクトはPrinterオブジェクトの「ドキュメント形式デフォルト」属性の値を仮定します。
document-uri (uri)
ドキュメント-uri(uri)
IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
error-bad-request'.
単一の非空の'REJECT/RETURN'クライアントuri'価値、誤りの悪い要求'でないなら。
IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが1023以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
request'.
URIであるなら、構文は有効でなく、REJECT/RETURNは'クライアント誤り悪い要求'です。
If the client-supplied URI scheme is not supported, i.e., the
value is not in the Printer object's referenced-uri-scheme-
supported" attribute, the Printer object MUST reject the request
「クライアントによって供給されたURI体系がサポートされないなら、Printerオブジェクトの参照をつけられたuri-体系にはすなわち、値がない、-」 属性であるとサポートされて、Printerオブジェクトは要求を拒絶しなければなりません。
Hastings, et al. Informational [Page 31] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [31ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
and return the 'client-error-uri-scheme-not-supported' status
code. The Printer object MAY check to see if the document exists
and is accessible. If the document is not found or is not
accessible, REJECT/RETURN 'client-error-not found'.
そして、'uri体系がサポートしなかったクライアント誤り'ステータスコードを返してください。 Printerオブジェクトは、ドキュメントが存在していて、アクセス可能であるかどうか確認するためにチェックするかもしれません。 REJECT/RETURN、ドキュメントが見つけられないか、またはアクセス可能でない、'、クライアント誤り、設立、'
last-document (boolean)
最後のドキュメント(論理演算子)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF NEITHER単一の'本当'NOR単一の'誤った''論理演算子'価値、REJECT/RETURN'クライアントの誤りの悪い要求'。
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
値の長さが1つの八重奏、REJECT/RETURNと'クライアント誤りはあまりに長い間、値を要求していた'状態で等しくないなら
job-id (integer(1:MAX))
仕事イド(整数(1: 最大))
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においてマックスと等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。
IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
error-not-found' or 'client-error-gone' status code, if keep track
of recently deleted jobs.
またはでない、どんな既存のJobオブジェクト、REJECT/RETURNの賃仕事のイドの'見つけられなかったクライアント誤り'、も'、クライアント誤り過ぎ去る、'ステータスコード、生活費であるなら、最近の道は仕事を削除しました。
requested-attributes (1setOf keyword)
要求された属性(1setOfキーワード)
IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
error-bad-request'.
'REJECT/RETURN'クライアント値、誤りの悪い要求'という'1つ以上のキーワードでないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
Ignore unsupported values, which are the keyword names of
unsupported attributes. Don't bother to copy such requested
(unsupported) attributes to the Unsupported Attribute response
group since the response will not return them.
サポートされない値を無視してください。(値はサポートされない属性のキーワード名です)。 応答がそれらを返さないので、わざわざそのような要求された(サポートされない)属性をUnsupported Attribute応答グループにコピーしないでください。
which-jobs (type2 keyword)
どれ、-、仕事(type2キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
the unsupported value to the Unsupported Attributes response group
and REJECT/RETURN 'client-error-attributes-or-values-not-
supported'.
または、IF NEITHERの'完成した'NORが'完成されない'で、Unsupported Attributes応答グループとREJECT/RETURN'クライアント誤り属性に属性とサポートされない値をコピーしてください、-、-、値でサポートされない、'
Hastings, et al. Informational [Page 32] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [32ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Note: a Printer still supports the 'completed' value even if it
keeps no completed/canceled/aborted jobs: by returning no jobs
when so queried.
以下に注意してください。 完成するか取り消されたか中止になっている仕事を全く保たないでも、Printerはまだ'完成した'値をサポートしています: そのように質問される場合仕事を全く返さないことによって。
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'.
IF NEITHER単一の'本当'NOR単一の'誤った''論理演算子'価値、REJECT/RETURN'クライアントの誤りの悪い要求'。
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
値の長さが1つの八重奏、REJECT/RETURNと'クライアント誤りはあまりに長い間、値を要求していた'状態で等しくないなら
IF NOT supplied by the client, the IPP object assumes the 'false'
value.
クライアントによって供給されないなら、IPPオブジェクトは'誤った'値を仮定します。
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においてマックスと等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。
IF NOT supplied by the client, the IPP object returns all jobs, no
matter how many.
供給されないなら、クライアント、オブジェクトが仕事、すべての物質を返すというわけではないIPPで、いくつですか?
-----------------------------------------------
-----------------------------------------------
3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
3.1.2.1.6 OPTIONAL Operation属性の値を有効にしてください。
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.
OPTIONAL Operation属性はIPPオブジェクトがサポートするかもしれないものです。 IPPオブジェクトはクライアントによって供給されたOPTIONAL属性の値を有効にします。 それぞれのOPTIONAL属性がコネセクション3.1.2として.5に.1を評価するので、IPPオブジェクトは同じ構文の合法化チェックを実行します。 同じくらい中、セクション3.1 .2 .1 .5 いずれか失敗して、IPPオブジェクトREJECTSが要求とRETURNS'クライアントの誤りの悪い要求'か'クライアント誤りはあまりに長い間、値を要求する'ステータスコードであるなら。
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.
さらに、定義された「xxxによってサポートしている」Printer属性が全くなければ、IPPオブジェクトは何らかのPrinter属性か何らかの困難なコード化された値に対してそれぞれのOperation属性値をチェックします。 値がそれらの中でサポートされないか、または範囲でサポートされないで、次に、IPPオブジェクトREJECTSが誤りステータスコードがテーブルで示した要求とRETURNSであるなら。 Printerオブジェクトの「サポートされたxxx」属性の値が'値がない'(システム管理者が値を構成していないので)であるなら、チェックはいつも失敗します。
Hastings, et al. Informational [Page 33] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [33ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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'.
単一の非空の'naturalLanguage'でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが63以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT a value that the Printer object supports in document
formats, (no corresponding "xxx-supported" Printer attribute),
REJECT/RETURN 'client-error-natural-language-not-supported'.
Printerオブジェクトがドキュメント・フォーマットでサポートする値、(対応する「xxxによってサポートしている」Printer属性がありません)でないなら、REJECT/RETURN'自然な言語がサポートしなかったクライアント誤り'です。
compression (type3 keyword)
圧縮(type3キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT in the Printer object's "compression-supported" attribute,
REJECT/RETURN 'client-error-compression-not-supported'.
オブジェクトのPrinterもので「圧縮でサポートしている」属性でないなら、REJECT/RETURN'圧縮がサポートしなかったクライアント誤り'です。
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にimplementersに注意してください: 「圧縮」属性のサポートは、IPP/1.0で任意であり、IPP/1.1でREQUIREDに変わりました。 しかしながら、IPP/1.0オブジェクトSHOULDが「圧縮」属性存在プレゼントと廃棄物がないかどうか少なくともチェックする、要求を作成してください、彼らが「圧縮」をサポートしないなら。 データが難解になるので、どんな照合もバグではありません。
job-k-octets (integer(0:MAX))
仕事のk八重奏(整数(0: 最大))
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
'client-error-bad-request'.
単一の'整数の'4つの八重奏と等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。
IF NOT in the range of the Printer object's "job-k-octets-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
Printerオブジェクトの「仕事k-八重奏でサポートしている」属性のいずれかの範囲でそうしないなら、Unsupported Attributes応答グループとREJECT/RETURN'属性か値がサポートしなかったクライアント誤り'に属性とサポートされない値をコピーしてください。
Hastings, et al. Informational [Page 34] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [34ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
job-impressions (integer(0:MAX))
仕事印象(整数(0: 最大))
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
'client-error-bad-request'.
単一の'整数の'4つの八重奏と等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。
IF NOT in the range of the Printer object's "job-impressions-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
Printerオブジェクトの「仕事印象でサポートしている」属性のいずれかの範囲でそうしないなら、Unsupported Attributes応答グループとREJECT/RETURN'属性か値がサポートしなかったクライアント誤り'に属性とサポートされない値をコピーしてください。
job-media-sheets (integer(0:MAX))
仕事のメディアシート(整数(0: 最大))
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
'client-error-bad-request'.
単一の'整数の'4つの八重奏と等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。
IF NOT in the range of the Printer object's "job-media-sheets-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
Printerオブジェクトの「仕事メディアシートでサポートしている」属性のいずれかの範囲でそうしないなら、Unsupported Attributes応答グループとREJECT/RETURN'属性か値がサポートしなかったクライアント誤り'に属性とサポートされない値をコピーしてください。
message (text(127))
メッセージ(テキスト(127))
IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
request'.
単一の'テキスト'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。
IF the value length is greater than 127 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが127以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
unknown or unsupported attribute
未知の、または、サポートされない属性
IF the attribute syntax supplied by the client is supported but
the length is not legal for that attribute syntax, REJECT/RETURN
'client-error-request-value-too-long'.
その属性構文、REJECT/RETURNには、クライアントによって供給された属性構文がサポートされるか、しかし、長さは'クライアント誤りはあまりに長い間、値を要求していた'状態で法的ではありません。
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-band"
'unsupported' value, but otherwise ignore the attribute.
ELSEはUnsupported Attributes応答グループに属性と値をコピーして、属性値を「バンドの外」という'サポートされない'値に変えますが、別の方法で属性を無視します。
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
以下に注意してください。 将来のOperation属性は指定されたグループでどこでも現れるかもしれないプロトコル仕様に追加されるかもしれません。 そうでなければ、操作がうまくいっているとき、IPPオブジェクトは'うまくいっている間違いない無視されたか代入された属性'ステータスコードを返します。 すべての操作におけるサポートされないOperation属性を無視するのが中のサポートされないJob Template属性の取り扱いに類似している、作成、そして、クライアントが'誤った'値と共に「ipp属性信義」Operation属性を供給するときのValidate-仕事の操作。 この最後の規則は、より年取ったクライアントが新しいことで織り込むことができるように私たちがIPPの将来のバージョンにOPTIONAL Operation属性を追加できるためのそうです。
Hastings, et al. Informational [Page 35] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [35ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
IPP objects and newer clients can inter-work with older IPP objects. (If the new attribute cannot be ignored without performing unexpectedly, the major version number would have been increased in the protocol document and in the request). This rule for Operation attributes is independent of the value of the "ipp-attribute- fidelity" attribute. For example, if an IPP object doesn't support the OPTIONAL "job-k-octets" attribute', the IPP object treats "job- k-octets" as an unknown attribute and only checks the length for the 'integer' attribute syntax supplied by the client. If it is not four octets, the IPP object REJECTS the request and RETURNS the 'client- error-bad-request' status code, else the IPP object copies the attribute to the Unsupported Attribute response group, setting the value to the "out-of-band" 'unsupported' value, but otherwise ignores the attribute.
IPPオブジェクトと、より新しいクライアントは、より古いIPPと共にオブジェクトを織り込むことができます。 (不意に働かないで新しい属性を無視できないなら、メジャーバージョン番号はプロトコルドキュメントと要求で増強されたでしょう。) Operation属性のためのこの規則は「ipp信義を結果と考えている」属性の価値から独立しています。 '例えば、IPPオブジェクトはOPTIONAL「仕事のk八重奏」属性をサポートしない'なら、IPPオブジェクトは、未知の属性として「仕事のk-八重奏」を扱って、クライアントによって供給された'整数'属性構文がないかどうか長さをチェックするだけです。 それが4つの八重奏でなく、IPPオブジェクトREJECTSが要求とRETURNS'クライアントの誤りの悪い要求'ステータスコードであるなら、IPPオブジェクトは、ほかに、「バンドの外」という'サポートされない'値に値を設定して、Unsupported Attribute応答グループに属性をコピーしますが、別の方法で属性を無視します。
Hastings, et al. Informational [Page 36] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [36ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents
3.1.2.2 提案されたAdditional Processing Steps、Operationsに関しては、そのCreate/はジョブスとAdd Documentsを有効にします。
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.
前項と組み合わせたこのセクションは、Print-仕事のための処理ステップ、Validate-仕事、Print-URIにCreate仕事、Send-ドキュメントを推薦して、IPPが反対させるSend-URI操作にSHOULD使用を推薦します。 これらは雇用を創り出して、Print-仕事の要求を有効にして、仕事にドキュメントを加える操作です。
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
IIG Sect#Flow IPP誤りステータスコード---------- ---- ---------------------- | いいえ3.1、.2.2.1<ipp属性信義>に対して------------------+ 供給された<?>| はい| | | ipp属性信義はいいえと等しいです。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+vいいえ3.1、.2.2.2<Printerは>です-->仕事を受け入れないサーバ誤り<受諾仕事?>はい| vが間違える、>の3.1の.2.3<Validate値、-->クライアントの誤りの悪い要求<JobテンプレートがOKに>クライアント誤りまた、要求価値の長い<(長さ、タグ、範囲、><マルチ価値)>を結果と考える| または、vが間違える、>がある3.1の.2.3<Validate値、--、>クライアントの誤りの悪い要求<が、値が>クライアント誤り属性であるとサポートした-、-| または、サポートされなかった値のvが3.1に間違える、.2.3.1<Any闘争、>、--、>のクライアント誤りを闘争させる属性の<Job Template attrが>クライアント誤り属性を評価する-、-、サポートされなかった値のv
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied
3.1.2.2.1 デフォルト「ipp属性信義」か供給しています。
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'.
Printerオブジェクトは、クライアントが「ipp属性信義」Operation属性を供給したかどうかを見るためにチェックします。 属性がクライアントによって供給されないなら、IPPオブジェクトは、値が'誤っている'と仮定します。
Hastings, et al. Informational [Page 37] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [37ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.2.2.2 Check that the Printer object is accepting jobs
3.1.2.2.2 Printerオブジェクトが仕事を受け入れているのをチェックしてください。
If the value of the Printer objects "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code.
「プリンタは仕事を受け入れていること」がPrinterオブジェクトの値であるなら'誤ってい'て、PrinterオブジェクトREJECTSは要求とRETURNS'仕事を受け入れないサーバ誤り'ステータスコードです。
3.1.2.2.3 Validate the values of the Job Template attributes
3.1.2.2.3 Job Template属性の値を有効にしてください。
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オブジェクトはクライアントによって供給されたすべてのJob Template属性の値を有効にします。 IPPオブジェクトがそれがOperation属性のために実行するそれぞれのJob Template属性値の類似の構文の合法化チェックを実行する、(見る、セクション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.
.5、構文チェックがこれらのどれかであるなら失敗して、IPPオブジェクトREJECTSが要求であり、RETURNSが'クライアント誤り悪い要求'か'クライアント誤りはあまりに長い間、値を要求しています'であるという.1状態が「信義をipp結果と考える」値の如何にかかわらず適宜コード化するセクション3.1.2のように。 そのような誤りがエンドユーザでというよりむしろクライアント開発者によって検出された誤りである最も傾向があるので、IPPオブジェクトはどの属性がUnsupported Attributes GroupかStatus Messageのどちらかに誤りを持ったかしるしを返す必要はありません。 それぞれのこれらの構文チェックのための記述は以下のテーブルでの声明であるなら1番目で明らかに言い表されます。
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:
それぞれのJob Template属性は一度よりさらにない起こらなければなりません。 IPP Printerがaを受けるなら、Job Template属性の複数の発生と共に要求を作成してください、そして、そうしてもよいです:
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. 操作を受け入れてください、そして、属性の最後の発生を使用してください。
Hastings, et al. Informational [Page 38] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [38ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
depending on implementation. Therefore, clients MUST NOT supply multiple occurrences of the same Job Template attribute in the Job Attributes group in the request.
実装によります。 したがって、クライアントは要求におけるJob Attributesグループにおける、同じJob Template属性の複数の発生を供給してはいけません。
3.1.2.3 Algorithm for job validation
3.1.2.3 仕事の合法化のためのアルゴリズム
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]).
セクション3.2を見てください。Printer属性に対する"xxx"が「xxxサポートした」Job-テンプレート属性を有効にするプロセスが以下の合法化アルゴリズムを使用できる、(.1 .2 [RFC2911)で。
To validate the value U of Job-Template attribute "xxx" against the value V of Printer "xxx-supported", perform the following algorithm:
Printerの値Vに対してJob-テンプレート属性"xxx"の値Uを有効にするには、「xxxによってサポートされ」て、以下のアルゴリズムを実行してください:
1. If U is multi-valued, validate each value X of U by performing the
algorithm in Table 7 with each value X. Each validation is
separate from the standpoint of returning unsupported values.
Example: If U is "finishings" that the client supplies with
'staple', 'bind' values, then X takes on the successive values:
'staple', then 'bind'
1. Uがマルチ評価されているなら、各値X.でTable7のアルゴリズムを実行することによって、Uの各値Xを有効にしてください。Each合法化は戻っているサポートされない値の見地から別々です。 例: 'ひも'は、次に、XがUがクライアントが'主要部分'に供給する「仕上げ」であるなら連続した値を呈するのを評価します: '主要部分'、当時の'ひも'
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.Ifに伴う値Zが有効にするTable7におけるアルゴリズムを実行するのによるVの各Z(Xが引き継ぐ属性値のための合法化)に対してXを有効にしてください。 失敗するなら、アルゴリズムがそこでV.Ifの次の値Zに適用されているのが、Vのそれ以上の値でないというZことである、合法化は失敗します。 「例」If Vは値がある「側でサポートされる」です: '1 'そして、面があるので、'二面に長く'、'二面に短く'て、Zは連続した値で以下を取ります。 '一方的で'、'二面に長く'、'二面に短いです'。 「クライアントが'長さ二面の'を「側」に供給するなら、最初の比較は('''二面のロングには同輩がいません'一方的な)に失敗しません、そして、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の両方が単一に評価されているなら、Vと使用がTable7の合法化規則であったなら、XがUとZであることをさせてください。
Hastings, et al. Informational [Page 39] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [39ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Table 7 - Rules for validating single values X against Z
テーブル7--Zに対してただ一つの値Xを有効にするための規則
Attribute syntax attribute syntax validated if: of X of Z
属性構文属性構文が有効にした、: ZのXについて
integer rangeOfInteger X is within the range of Z
Zの範囲の中に整数rangeOfInteger Xがあります。
uri uriScheme the uri scheme in X is equal to
Z
uriがXで計画するuri uriSchemeはZと等しいです。
any boolean the value of Z is TRUE
どんな論理演算子、もZの値はTRUEです。
any any X and Z are of the same type
and are equal.
どんなXとZも、いくらか、同じタイプにはあって、等しいです。
If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails. If the check fails, the IPP object copies the attribute to the Unsupported Attributes response group with its unsupported value. If the attribute contains more than one value, each value is checked and each unsupported value is separately copied, while supported values are not copied. If an IPP object doesn't recognize/support a Job Template attribute, i.e., there is no corresponding Printer object "xxx-supported" attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see the last row in the table below).
Printerオブジェクトの「xxxによってサポートしている」属性の値が'値がない'(システム管理者が値を構成していないので)であるなら、チェックはいつも失敗します。 チェックが失敗するなら、IPPオブジェクトはサポートされない値でUnsupported Attributes応答グループに属性をコピーします。 属性が1つ以上の値を含んでいるなら、各値はチェックされます、そして、それぞれのサポートされない値は別々にコピーされます、サポートしている値がコピーされませんが。 IPPオブジェクトがJob Template属性を認識するか、またはサポートしないなら、すなわち、「xxxによってサポートしている」属性、IPPが未知の、または、サポートされない属性として属性を扱うのを反対させるどんな対応するPrinterオブジェクトもありません(以下のテーブルにおける最後の行を見てください)。
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.
いくつかのJob Template属性が他のもののためにサポートされるのではなく、いくつかのドキュメント・フォーマットのためにサポートされるか、または異なったドキュメント・フォーマットにおいて、値が異なるなら、IPPオブジェクトSHOULDは、この合法化でクライアント(または、クライアントによって供給されないなら、Printerの「ドキュメント形式デフォルト」属性の値をデフォルトとする)によって供給された「ドキュメント・フォーマット」の値を使用することでそれを考慮に入れます。 例えば、「上に数」が'テキスト/明瞭な'ドキュメント・フォーマットのためにサポートされますが、'アプリケーション/追伸'ドキュメント・フォーマットのためにサポートされるというわけではないなら、チェックSHOULD(NOTを必要としますが)は「ドキュメント・フォーマット」操作属性の値に依存します。 [RFC2911]セクション3.2.1における「ドキュメント・フォーマット」.1と3.2を見てください。.5 .1。
Note: whether the request is accepted or rejected is determined by the value of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all Job Template attribute supplied are examined and all unsupported attributes and/or values are copied to the Unsupported Attributes response group.
以下に注意してください。 要求を受け入れるか、または拒絶するかがその後のステップにおける、「ipp属性信義」属性の値で決定するので、Job Template属性が供給したすべてが調べられます、そして、すべてのサポートされない属性、そして/または、値はUnsupported Attributes応答グループにコピーされます。
-----------------------------------------------
-----------------------------------------------
Hastings, et al. Informational [Page 40] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [40ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
job-priority (integer(1:100))
ジョブ優先順位(整数(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
単一の'整数'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF NOT supplied by the client, use the value of the Printer
object's "job-priority-default" attribute at job submission time.
クライアントによって供給されないなら、ジョブ依頼時にPrinterオブジェクトの「仕事の優先権デフォルト」属性の値を使用してください。
IF NOT in the range 1 to 100, inclusive, copy the attribute and
the unsupported value to the Unsupported Attributes response
group.
包括的な1〜100がいずれかの範囲に属性とサポートされない値をUnsupported Attributes応答にコピーしないなら、分類してください。
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がPrinterの「優先権がサポートした仕事」属性の値で示した範囲で値であるとサポートされる中で最も近いものに値を写像してください。 [RFC2911]セクション4.2.1における公式を見てください。
job-hold-until (type3 keyword | name)
仕事の保持(type3キーワード| 名前)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
キーワード単一の'''REJECT/RETURN、'値を命名してください'というクライアントの誤りの悪い要求'でないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT supplied by the client, use the value of the Printer
object's "job-hold-until" attribute at job submission time.
クライアントによって供給されないなら、オブジェクトのPrinterものの値を使用してください、「仕事の保持、」 ジョブ依頼時に、結果と考えます。
IF NOT in the Printer object's "job-hold-until-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
Printerオブジェクトのどんな「サポートされるまでの仕事の保持」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
job-sheets (type3 keyword | name)
仕事シート(type3キーワード| 名前)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
キーワード単一の'''REJECT/RETURN、'値を命名してください'というクライアントの誤りの悪い要求'でないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT in the Printer object's "job-sheets-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
Printerオブジェクトのどんな「シートがサポートした仕事」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
multiple-document-handling (type2 keyword)
複数のドキュメント処理(type2キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。
Hastings, et al. Informational [Page 41] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [41ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT in the Printer object's "multiple-document-handling-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group.
Printerオブジェクトのどんな「複数のドキュメント取り扱いでサポートしている」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
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つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF NOT in range of the Printer object's "copies-supported"
attribute
オブジェクトがPrinterの範囲でないところでは、「コピーでサポートしている」属性であるなら
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
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'.
'enum'でないなら、4つの八重奏と等しい長さでREJECT/RETURN'クライアントの誤りの悪い要求'と(s) それぞれ評価してください。
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.
オブジェクトのPrinterもので「仕上げでサポートしている」属性でないなら、いずれではなく、値であるとサポートされた属性とサポートされない値をUnsupported Attributes応答グループにコピーしてください。
page-ranges (1setOf rangeOfInteger(1:MAX))
ページ範囲(1setOf rangeOfInteger(1: 最大))
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
octets, REJECT/RETURN 'client-error-bad-request'.
'rangeOfInteger'でないなら、8つの八重奏と等しい長さでREJECT/RETURN'クライアントの誤りの悪い要求'と(s) それぞれ評価してください。
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番目の値、範囲よりも昇順にすばらしいか、または範囲が重なるなら、REJECT/RETURN'クライアントの誤りの悪い要求'です。
IF the value of the Printer object's "page-ranges-supported"
attribute is 'false', copy the attribute to the Unsupported
Attributes response group and set the value to the "out-of-band"
'unsupported' value.
Printerオブジェクトの「範囲がサポートしたページ」属性の値が'誤っている'なら、Unsupported Attributes応答グループに属性をコピーしてください、そして、「バンドの外」という'サポートされない'値に値を設定してください。
sides (type2 keyword)
側(type2キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
Hastings, et al. Informational [Page 42] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [42ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
IF NOT in the Printer object's "sides-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
オブジェクトのPrinterもので「側でサポートしている」属性でないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
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つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF NOT a value or in the range of one of the values of the Printer
object's "number-up-supported" attribute, copy the attribute and
value to the Unsupported Attribute response group.
値でないPrinterオブジェクトの「サポートされることへの数」属性の値の1つの範囲でUnsupported Attribute応答グループに属性と値をコピーしてください。
orientation-requested (type2 enum)
オリエンテーションで、要求されています。(type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
単一の'enum'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF NOT in the Printer object's "orientation-requested-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
Printerオブジェクトのどんな「サポートされた状態で要求されたオリエンテーション」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
media (type3 keyword | name)
メディア(type3キーワード| 名前)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
キーワード単一の'''REJECT/RETURN、'値を命名してください'というクライアントの誤りの悪い要求'でないなら。
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。
IF NOT in the Printer object's "media-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
オブジェクトのPrinterもので「メディアによってサポートしている」属性でないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
printer-resolution (resolution)
プリンタ解決(解決)
IF NOT a single 'resolution' value with a length equal to 9
octets, REJECT/RETURN 'client-error-bad-request'.
単一の'解決'でないなら、9つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
IF NOT in the Printer object's "printer-resolution-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
Printerオブジェクトのどんな「サポートされたプリンタ解決」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
print-quality (type2 enum)
印刷品質(type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
単一の'enum'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。
Hastings, et al. Informational [Page 43] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [43ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
IF NOT in the Printer object's "print-quality-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
Printerオブジェクトのどんな「品質がサポートした印刷」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
unknown or unsupported attribute (i.e., there is no corresponding
Printer object "xxx-supported" attribute)
未知の、または、サポートされない属性(すなわち、対応してはいけませんPrinterオブジェクトが属性を「xxxサポートした」)
IF the attribute syntax supplied by the client is supported but
the length is not legal for that attribute syntax,
その属性構文には、クライアントによって供給された属性構文がサポートされるか、しかし、長さは法的ではありません。
REJECT/RETURN 'client-error-bad-request' if the length of the
attribute syntax is fixed or 'client-error-request-value-too-long'
if the length of the attribute syntax is variable.
REJECT/RETURN'クライアントの誤りの悪い要求'は、属性構文の長さであるなら属性構文の長さが可変であるなら修理されるか'クライアント誤りはあまりに長い間、値を要求しています'。
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-band"
'unsupported' value. Any remaining Job Template Attributes are
either unknown or unsupported Job Template attributes and are
validated algorithmically according to their attribute syntax for
proper length (see below).
ELSEはUnsupported Attributes応答グループに属性と値をコピーして、属性値を「バンドの外」という'サポートされない'値に変えます。 どんな残っているJob Template Attributesも未知の、または、サポートされないJob Template属性であり、それらの属性構文によると、適切な長さのためにalgorithmicallyに有効にされます(以下を見てください)。
-----------------------------------------------
-----------------------------------------------
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:
属性構文がANDであることがサポートされるなら、長さのチェックは失敗します、属性構文の長さが可変であるなら要求とRETURNS'クライアント誤り悪い要求'属性構文の長さが固定されているか、そして、または'クライアント誤りはあまりに長い間、値を要求する'状態がコード化するIPPオブジェクトREJECTS。 さもなければ、IPPオブジェクトは、Unsupported Attributes応答グループにサポートされないJob Template属性をコピーして、属性値を「バンドの外」という'サポートされない'値に変えます。 以下のテーブルは、長さがすべての属性構文がないかどうかチェックするのを示します。 以下では、以下をテーブルの上に置いてください。 「<=」は以下か等しいことを意味して、「=」は以下のことのために等しいことを意味します。
Hastings, et al. Informational [Page 44] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [44ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Name Octet length check for read-write attributes ---------- ---------------------------------------------
読書して書いている属性のための名前Octet長さのチェック---------- ---------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 'textWithoutLanguage' <= 1023 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 'nameWithoutLanguage' <= 255 'keyword' <= 255 'enum' = 4 'uri' <= 1023 'uriScheme' <= 63 'charset' <= 63 'naturalLanguage' <= 63 'mimeMediaType' <= 255 'octetString' <= 1023 'boolean' = 1 'integer' = 4 'rangeOfInteger' = 8 'dateTime' = 11 'resolution' = 9 '1setOf X'
'textWithLanguage <= 1023 AND '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
以下に注意してください。 Printerが要求におけるゼロ・レングスキーワードを受け取るのは、可能です。 これがキーワードであるので、値は、サポートしている値と比較される必要があります。 プリンタには対応する「xxxによってサポートしている」属性におけるゼロ・レングスに関するキーワードである少しの値もないと仮定すると、比較は失敗するでしょう。 そして、それぞれ'誤った'か'本当'の「ipp属性信義」の値によって、要求を受け入れるか、または拒絶するでしょう。 取り扱いが必要である特別番組がありません。
3.1.2.3.1 Check for conflicting Job Template attributes values
3.1.2.3.1 闘争しているJob Template属性値がないかどうかチェックしてください。
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
個別にかつてのすべてのOperationとJob Template属性をチェックしてあります、とPrinterオブジェクトSHOULDはすべてのサポートしている値の中の値がクライアントから供給したどんな闘争がないかどうかチェックします。 例えば、しかしながら、Printerオブジェクトがとめて、透明で印刷できて、物理的なとめ規制のためであるかもしれない、Printerオブジェクトは透明をとめることができないかもしれません。 IPPオブジェクトはサポートしている属性とそれらの闘争している属性値をUnsupported Attributes応答グループにコピーします。 Printerオブジェクトはそれらの属性の上にコピーされるだけです。どちらかが闘争、およびそれを解決するために無視するか、または置換するPrinterオブジェクトはクライアントによって供給されたものを元の値に返します。 例えば、クライアント供給が同輩が'とめる'「仕上げ」であると仮定してください。そうすれば、「メディア」は'透明'と等しいです、しかし、Printerオブジェクトはとめが透明であるとサポートしません。 Printerが、とめ要求を無視するのを選ぶ、決心
Hastings, et al. Informational [Page 45] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [45ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
Unsupported Attributes応答グループで'とめる'ために等しい「仕上げ」を返します闘争、Printerが、反対する。 何か属性がマルチ評価されているなら、属性の闘争値だけがコピーされます。
Note: The decisions made to resolve the conflict (if there is a choice) is implementation dependent.
以下に注意してください。 闘争(選択があれば)が実装に依存していると決議するのがされた決定。
3.1.2.3.2 Decide whether to REJECT the request
3.1.2.3.2 REJECTにか否かに関係なく、決めてください、要求
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:
何かサポートされないJob Template属性やサポートされないか闘争しているJob Templateがあったなら、属性値とクライアントは、'本当'の値、PrinterオブジェクトREJECTSがある「ipp属性信義」属性に要求を提供して、ステータスコードを返します:
1.'client-error-conflicting-attributes' status code, if there were
any conflicts between attributes supplied by the client.
1. 'クライアント誤り闘争属性'ステータスコード何かクライアントによって供給された属性の間の闘争があったなら。
2.'client-error-attributes-or-values-not-supported' status code,
otherwise.
2. そうでなければ、'属性か値がサポートしなかったクライアント誤り'ステータスコード。
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
以下に注意してください。 サポートされないOperation属性か返される値がこのステップで返された状態に影響しません。 サポートされないOperation属性が重大な誤りであったなら、上記は既に前のステップにおける要求を拒絶しました。 コントロールがサポートされないOperation属性が返されているこのステップを始めるなら、それらは重大な誤りではありません。
In general, the final results of Job processing are unknown at Job submission time. The client has to rely on notifications or polling to find out what happens at Job processing time. However, there are cases in which some Printers can determine at Job submission time that Job processing is going to fail. As an optimization, we'd like to have the Printer reject the Job in these cases.
一般に、Job処理の最終的な結果はJob服従時間に未知です。 クライアントは、何がJob処理時間に起こるかを見つけるために通知か世論調査に依存しなければなりません。 しかしながら、いくつかのPrintersがJob服従時間にJob処理が破産していることを決定できる場合があります。 最適化として、Printerにこれらの場合でJobを拒絶させたいと思います。
There are three types of "processing" errors that might be detectable at Job submission time:
3つのタイプのJob服従時間に検出可能であるかもしれない「処理」誤りがあります:
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. '形式が支えなかったクライアント誤りドキュメント': Print仕事、Send-ドキュメント、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,
- Printerは、要求「ドキュメント・フォーマット」操作属性は'八重奏アプリケーション/ストリーム'です--Printerが応じる前にドキュメントデータを受け取るという自動感じがドキュメントが応じる前にフォーマットするPrinter自動感覚であるとサポートします。
Hastings, et al. Informational [Page 46] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [46ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
- the sensed document format is not supported by the Printer
- 感じられたドキュメント・フォーマットはPrinterによってサポートされません。
then the Printer should respond with 'client-error-document-format- not-supported' status.
そして、Printerは'クライアント誤りドキュメント形式でサポートしていない'状態で応じるはずです。
2. 'client-error-compression-error': For the Print-Job, Send- Document, Print-URI, and Send-URI operations, if all these conditions are true:
2. 'クライアント誤り圧縮誤り': Print-仕事において、Sendドキュメント、Print-URI、およびSend-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
- クライアントは要求における「圧縮」操作属性にサポートしている値を供給します--Printerは応じる前に、ドキュメントデータを受け取ります--Printerは、応じる前にドキュメントデータを減圧するのを試みます--「圧縮」操作属性によって指定されたアルゴリズムを使用することでドキュメントデータを減圧できません。
then the Printer should respond with 'client-error-compression-error' status.
そして、Printerは'クライアント誤り圧縮誤り'状態で応じるはずです。
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. 'クライアント誤りドキュメントアクセスエラー': Print-URI、およびSend-URI操作のために、応じる前の参照をつけられたドキュメントデータでありPrinterが牽引力に試みて、失敗するなら、それは'クライアント誤りドキュメントアクセスエラー'状態で応じるべきです。
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".
いくつかのPrintersはJob処理時間までこれらの誤りを検出できません。 その場合、誤りは対応する仕事州と仕事州の理由属性に記録されます。 (クライアントが、PrinterがJob服従時間にこれらの誤りを検出できるかどうかと決心するどんな標準の方法もありません。) 自動感じが例えば起こる、AFTER、仕事を受け入れて(自動感じと対照的に、応答を返す前の時に提出してください)、実装は、仕事の「仕事の州の理由」に仕事を中止して、'中止になっている'状態に仕事を置いて、'サポートされないドキュメント・フォーマット'値を設定します。
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.
圧縮に結合されると、Printerには、Job服従時間の自動感じは、より難しいかもしれません。 自動感じられたジョブスにとって、クライアントは転送プロトコル層に圧縮を延期するところで、よりよく、そして、例えばそうです。 Contentをコード化しているHTTPヘッダーを使用することによって。
Hastings, et al. Informational [Page 47] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [47ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
status codes
3.1.2.3.3 Validate-仕事の操作、成功ステータスコードのRETURN1のために
If the requested operation is the Validate-Job operation, the Printer object returns:
要求された操作がValidate-仕事の操作であるなら、Printerオブジェクトは戻ります:
1. the "successful-ok" status code, if there are no unsupported or
conflicting Job Template attributes or values.
2. the "successful-ok-conflicting-attributes, if there are any
conflicting Job Template attribute or values.
3. the "successful-ok-ignored-or-substituted-attributes, if there
are only unsupported Job Template attributes or values.
1. 「うまくいっているOK」ステータスコード、サポートされないか闘争Job Template属性が全くないか、そして、または値。 2. 「うまくいっている間違いない闘争属性、闘争Job Templateが結果と考える何かがあるか、そして、または値。」 3. 「うまくいっている間違いない無視されたか代入された属性、サポートされないJob Template属性がないか、そして、または値。」
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
以下に注意してください。 サポートされないOperation属性か返される値がこのステップで返された状態に影響しません。 サポートされないOperation属性が重大な誤りであったなら、上記は既に前のステップにおける要求を拒絶しました。 コントロールがサポートされないOperation属性が返されているこのステップを始めるなら、それらは重大な誤りではありません。
3.1.2.3.4 Create the Job object with attributes to support
3.1.2.3.4 サポートする属性があるJobオブジェクトを作成してください。
If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by the client), the Printer object:
「ipp属性信義」が'誤っていること'に設定されるなら(それはクライアントによって供給されませんでした)、Printerは反対します:
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記述属性のすべてを初期化します。 2.、Jobオブジェクトからすべてのサポートされない属性を取り除きます。 3. それぞれにサポートされない、値であるとサポートされて、いくつか評価して、サポートされない値かサポートされない属性が評価する代用品のどちらかを取り外します。 それからサポートされない値を取り除いた後に、値が全く属性にないなら、Jobオブジェクトから属性を取り除きます(ジョブ処理時の通常のデフォルトの振舞いがその属性のために行われるように)。 4.、それぞれ闘争している値のために代入する、闘争値を取り除くか、またはある他のサポートしている値で闘争属性値を代入します。 それから闘争値を取り除いた後に、値が全く属性にないなら、Jobオブジェクトから属性を取り除きます(ジョブ処理時の通常のデフォルトの振舞いがその属性のために行われるように)。
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
Printerオブジェクトが、「属性が全くなかったか、値はサポートされないとして弛んだか、そして、'ipp属性信義の値」が'誤っていた'と受け入れることができる、要求を作成してくださいといって、新しいJobオブジェクトを作成してください、' 「ipp属性信義」属性が'本当に'設定されるなら、新しいJobオブジェクトに居住するJob Template属性がすべて、必ず中に供給されたJob Template属性である、要求を作成してください。 if
Hastings, et al. Informational [Page 48] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [48ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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属性信義」属性は'誤っていること'に設定されて、新しいJobオブジェクトに居住するJob Template属性はすべて、サポートされるか、または値の代替があるクライアントの供給されたJob Template属性です。 したがって、Printerオブジェクトがそれらの属性をサポートしなかったので、要求されたJob Template属性のいくつかがJobオブジェクトに現れないでしょう。 Jobオブジェクトに居住する属性はそのJobのためにJobオブジェクトで持続して保存されます。 そのJobオブジェクトにおけるGet仕事の属性操作はJobオブジェクトで持続して保存されるそれらの属性だけを返すでしょう。
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.
以下に注意してください。 Jobオブジェクトで持続して保存されるすべてのJob Template属性が「オーバーライド値」であると意図します。 すなわち、いかなる他の埋め込まれた指示の上でも優先する彼らはドキュメントデータ自体にいるかもしれません。 しかしながら、すべてのPrinterオブジェクトには、「オーバーライド」の意味論がわかるのは可能ではありません。 エンドユーザは、どちらかが試みるか、またはするPrinterが、IPP属性でドキュメントデータ指示をくつがえすのを試みないかどうか決定するためにPrinterの「オーバーライドがサポートしたpdl」属性について質問するかもしれません。
There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer does not use its default values to populate Job attributes when creating the new Job object; only Job Template attributes actually in the create request are used to populate the Job object. The Printer's default values are only used later at Job processing time if no other IPP attribute or instruction embedded in the document data is present.
いくつかのケースがあります。そこでは、PrinterはJob Template属性をサポートして、関連デフォルト値をその属性に設定させます。 クライアントが対応する属性を供給しない場合では、Printerは新しいJobオブジェクトを作成するとき、Job属性に居住するのにデフォルト値を使用しません。 Job Templateだけが実際に中で結果と考える、使用される要求を作成して、Jobオブジェクトに居住してください。 ドキュメントデータに埋め込まれた他のIPP属性かどんな指示も存在していない場合にだけ、Printerのデフォルト値はJob処理時間に後で使用されます。
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.
以下に注意してください。 クライアントがしたJob Template属性に関連している値が供給しないデフォルトがJobオブジェクトに居住するのに使用されることであるなら、これらの値はデフォルトよりむしろ「オーバーライド値」になります。 Printerが「オーバーライドがサポートしたpdl」属性の'試みられた'値をサポートするなら、これらのオーバーライド値はドキュメントデータの中で指定された値を取り替えるかもしれません。 これはデフォルト値メカニズムの意図ではありません。 要求を作成してください。使用される属性だけのためのAデフォルト値、属性('誤ってい'て、「ipp属性信義」によって許容されていると、それは無視された)を提供しましたが、どんな値もドキュメントデータの内容の中で提供されなかったと指定しませんでした。
If the client does not supply a value for some Job Template attribute, and the Printer does not support that attribute, as far as IPP is concerned, the result of processing that Job (with respect to the missing attribute) is undefined.
クライアントが何らかのJob Template属性に値を供給しないで、またPrinterがその属性をサポートしないなら、IPPに関する限り、そのJob(なくなった属性に関する)を処理するという結果は未定義です。
Hastings, et al. Informational [Page 49] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [49ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.2.3.5 Return one of the success status codes
3.1.2.3.5 成功ステータスコードの復帰1
Once the Job object has been created, the Printer object accepts the request and returns to the client:
Jobオブジェクトがいったん作成されると、Printerオブジェクトは、要請を受け入れて、クライアントに戻ります:
1. the 'successful-ok' status code, if there are no unsupported or
conflicting Job Template attributes or values.
2. the 'successful-ok-conflicting-attributes' status code, if
there are any conflicting Job Template attribute or values.
3. the 'successful-ok-ignored-or-substituted-attributes' status
code, if there are only unsupported Job Template attributes or
values.
1. 'うまくいっているOK'ステータスコード、サポートされないか闘争Job Template属性が全くないか、そして、または値。 2. 'うまくいっている間違いない闘争属性'ステータスコード、闘争Job Templateが結果と考える何かがあるか、そして、または値。 3. 'うまくいっている間違いない無視されたか代入された属性'ステータスコード、サポートされないJob Template属性がないか、そして、または値。
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
以下に注意してください。 サポートされないOperation属性か返される値がこのステップで返された状態に影響しません。 サポートされないOperation属性が重大な誤りであったなら、上記は既に前のステップにおける要求を拒絶しました。 コントロールがサポートされないOperation属性が返されているこのステップを始めるなら、それらは重大な誤りではありません。
The Printer object also returns Job status attributes that indicate
the initial state of the Job ('pending', 'pending-held',
'processing', etc.), etc. See Print-Job Response, [RFC2911] section
3.2.1.2.
また、PrinterオブジェクトはJob('未定'の、そして、'未定に保持された''処理'など)の初期状態などを示す状態属性をJobに返します。 .2にPrint-仕事のResponse、[RFC2911]セクション3.2.1を見てください。
3.1.2.3.6 Accept appended Document Content
3.1.2.3.6 追加されたDocument Contentを受け入れてください。
The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing.
Printerオブジェクトが追加されたDocument Contentデータを受け入れて、どちらかが、印刷し始めるか、または後で処理するためにそれをスプールします。
3.1.2.3.7 Scheduling and Starting to Process the Job
3.1.2.3.7 仕事を処理し始めること計画をして。
The Printer object uses its own configuration and implementation specific algorithms for scheduling the Job in the correct processing order. Once the Printer object begins processing the Job, the Printer changes the Job's state to 'processing'. If the Printer object supports PDL override (the "pdl-override-supported" attribute set to 'attempted'), the implementation does its best to see that IPP attributes take precedence over embedded instructions in the document data.
Printerオブジェクトは、正しい処理命令でJobの計画をするのにそれ自身の構成と実装の特定のアルゴリズムを使用します。 PrinterオブジェクトがいったんJobを処理し始めると、PrinterはJobの状態を'処理'に変えます。 Printerオブジェクトが、PDLがオーバーライドであるとサポートするなら(「オーバーライドがサポートしたpdl」属性は'試みられること'にセットしました)、実装は、IPP属性がドキュメントデータにおける埋め込まれた指示の上で優先することを確認するために最善をつくします。
3.1.2.3.8 Completing the Job
3.1.2.3.8 仕事を完了すること。
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
Printerオブジェクトは、Jobを'完成した'状態に動かすことができるまでJobを処理し続けています。 キャンセル仕事の操作が受け取られているなら、実装は結局、Jobを'取り消された'状態に動かします。 システムがそれを処理している間、誤りに遭遇するなら、それに完成した状態にJobを進行させないでください。
Hastings, et al. Informational [Page 50] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [50ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
implementation halts all processing, cleans up any resources, and moves the Job into the 'aborted' state.
実装は、'中止になっている'状態にすべての処理を止めて、どんなリソースも掃除して、Jobを動かします。
3.1.2.3.9 Destroying the Job after completion
3.1.2.3.9 完成の後にJobを破壊すること。
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.
かつての'完成した'か、'中止になった'か、'取り消された'状態へのJob移動、それはいつJobオブジェクトを破壊して、すべての関連リソースを発表するかに関する実装決定です。 または、Jobがいったん破壊されると、Printerが戻るだろう、「クライアント誤りで見つけられない」、「クライアント誤り過ぎ去る、」 操作のためのステータスコードはおまけに、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.
以下に注意してください。 仕事を破壊してある後にPrinterオブジェクトSHOULD NOTは十分長い時間、「仕事-uri」か「仕事イド」値を再使用します、クライアントによって保たれた聞き古した参照が間違った(より新しい)仕事によりアクセスしそうにないように。
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"
3.1.2.3.10 「ipp属性信義」との相互作用
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
いくつかのPrinterオブジェクト実装が'本当'への「ipp信義を結果と考えている」セットと'試みます'が、まだクライアントがまさに何を指定するかをわかることができない「オーバーライドがサポートしたpdl」セットを支えるかもしれない、要求を作成してください。 これはドキュメントデータの中で埋め込まれた教える技能と、ドキュメントデータに伴う外部の教える技能とどうそのような指示の間の闘争を扱うかに関する役割に関してされたレガシー決定と仮定のためです。 「また、与えられた実装がどう振る舞うかに関して正確な100%であることができないことは2つの特別な属性、「ipp属性信義」、および"pdl"がオーバーライドでサポートした事実によって合成されること」は各属性のために特定の値よりむしろ全体の仕事に申し込まれます。 例えば、いくつかの実装が「上に数」を除いたほとんどすべてのJob Template属性をくつがえすことができるかもしれません。 文字コード、自然言語、および国際化
This section discusses character set support, natural language support and internationalization.
このセクションは文字集合サポート、自然言語サポート、および国際化について論じます。
3.1.2.3.11 Character set code conversion support
3.1.2.3.11 文字集合コード変換サポート
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and indicate that UTF-8 and US-ASCII are supported by populating the Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An IPP object is required to code covert with as little loss as possible between the charsets that it supports, as indicated in the Printer's "charsets-supported" attribute.
IPPクライアントとIPPオブジェクトはUTF-8をサポートするREQUIREDです。 彼らは追加charsetsをサポートするかもしれません。 そして、また、IPPオブジェクトが米国-ASCIIをサポートするのは、RECOMMENDEDです、多くのクライアントが、米国-ASCIIをサポートして、UTF-8と米国-ASCIIがPrinterに居住することによって'utf-8'で「charsetによってサポートされた」状態でサポートされるのを示すので'、私たち、-、ASCII、'値。 IPPオブジェクトが同じくらい小さい損失がそれがサポートするcharsetsの間で可能な状態でおおいをコード化するのに必要です、Printerの「charsetsによってサポートしている」属性にみられるように。
Hastings, et al. Informational [Page 51] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [51ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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?
サーバがどのように、応答自体の「属性charset」がそうである状況を扱うべきであるか、「私たち、-、ASCII、「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".
例: クライアントがPrint-仕事の要求を送るケースを考えてください、「8インチをutfする、「属性-charset」と「」 属性が提供した仕事の名前」がある値。 その後、別のクライアントはGet-仕事属性かGet-ジョブス要求を提出します。 この2番目の要求が値がある「属性-charset」を含んでいる、「私たち、-、ASCII、」 ちょうど1値の「ジョブ名」がある「要求された属性」属性。
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ドキュメント、(.2、)2番目の要求の応答のための「属性-charset」の値がそうしなければならないセクション3.1.4、「私たち、-、ASCII、」 それが要求で指定されたcharsetであるので。 しかしながら、「utf-8インチの形式」には「ジョブ名」値があります。 そして、両方ですが、要求が拒絶されるべきである、「utf-8インチ、「私たち、-、ASCII、「ジョブ名」値が変えられるなら」 charsetsがサーバによってサポートされる、「私たち、-、ASCII、」 「」 状態としての(0×0002)がコード化するうまくいっている間違いない闘争属性?」を返してください。
Answer: An IPP object that supports both utf-8 (REQUIRED) and us- ascii, the second paragraph of section 3.1.4.2 applies so that the IPP object MUST accept the request, perform code set conversion between these two charsets with "the highest fidelity possible" and return 'successful-ok', rather than a warning 'successful-ok- conflicting-attributes, or an error. The printer will do the best it can to convert between each of the character sets that it supports -- even if that means providing a string of question marks because none of the characters are representable in US ASCII. If it can't perform such conversion, it MUST NOT advertise us-ascii as a value of its "attributes-charset-supported" and MUST reject any request that requests 'us-ascii'.
以下に答えてください。 そして、両方がutf-8(REQUIRED)であるとサポートするIPPオブジェクト、私たち、-、ASCII、.2がIPPオブジェクトが要請を受け入れなければならないように適用するセクション3.1.4の第2パラグラフは'うまくいって間違いない闘争している属性、または誤り'というa警告よりむしろこれらの2charsetsの間の「可能な最も高い信義」とリターンが'うまくいっているOK'であることでのコードセット変換を実行します。 それが、キャラクタのだれ一人米国ASCIIで「表-可能」でないので一連の疑問符を提供することを意味しても、プリンタはそれがそれがサポートするそれぞれの文字集合の間の転向者にそうすることができるベストを尽くすでしょう。 そのような変換を実行できないなら、広告を出してはいけない、私たち、-、ASCII、aがそれが要求するどんな要求も「charsetがサポートした属性」を評価して、拒絶しなければならない、'、私たち、-、ASCII、'
One IPP object implementation strategy is to convert all request text and name values to a Unicode internal representation. This is 16-bit and virtually universal. Then convert to the specified operation attributes-charset on output.
1つのIPPオブジェクト実装戦略はすべての要求テキストと名前値をユニコードの内部の表現に変換することです。 これは、16ビットであって実際には普遍的です。 そして、出力のときに指定された操作属性-charsetに変えてください。
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.
また、クライアントが'utf-8'を求めるのも、むしろより賢いだろう、'、私たち、-、ASCII、'IPPオブジェクトのコード変換によるよりむしろ、それが理解していないキャラクタを無駄にしてください。
3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?
3.1.2.3.12 サポートされないcharsetが要求されているとき戻るどんなcharset(問題1.19)?
Section 3.1.4.1 Request Operation attributes was clarified in November 1998 as follows:
セクション3.1 .4 .1 Request Operation属性は以下の1998年11月にはっきりさせられました:
Hastings, et al. Informational [Page 52] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [52ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
All clients and IPP objects MUST support the 'utf-8' charset [RFC2044] and MAY support additional charsets provided that they are registered with IANA [IANA-CS]. If the Printer object does not support the client supplied charset value, the Printer object MUST reject the request, set the "attributes-charset" to 'utf-8' in the response, and return the 'client-error-charset-not-supported' status code and any 'text' or 'name' attributes using the 'utf-8' charset.
すべてのクライアントとIPPオブジェクトは、'utf-8'がcharset[RFC2044]であるとサポートしなければならなくて、それらがIANA[IANA-CS]に登録されれば、追加charsetsをサポートするかもしれません。 Printerオブジェクトがクライアントの供給されたcharset価値をサポートしないなら、'utf-8'charsetを使用して、Printerオブジェクトは、要求を拒絶して、応答で「属性-charset」を'utf-8'に設定して、'charsetがサポートしなかったクライアント誤り'ステータスコードとどんな'テキスト'か'名前'属性も返さなければなりません。
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をサポートしなければならないので、クライアントがサポートされないcharsetを要求するとき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.
そのような誤りがユーザ誤りよりむしろクライアント誤りであるので、クライアントは最初に、charsetで要求されていないいかなる他の返された'テキスト'と'名前'属性も表示するのを避けることができるようにステータスコードをチェックするべきです。
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クライアント誤りcharsetを区分します。-サポートされないで、(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).
セクション3.1を見てください。'utf-8'charsetを使用して、IPP Printerが「属性-charset」操作属性におけるクライアントによって供給されたcharsetをサポートしないなら、Printerがどんな操作のためにも、操作を拒絶して、この状態とどんな'テキスト'か'名前'属性も返さなければならない、(.4 .1)。
3.1.2.3.13 Natural Language Override (NLO)
3.1.2.3.13 自然言語オーバーライド(NLO)
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つには、暗黙の自然言語があります、そして、もう片方には、明白な自然言語があります。 'textWithoutLanguage'と'テキスト'フォーム'nameWithoutLanguage」と'nameWithLanguageは2歳であること'は、textWithLanguageが'2である'と命名すること'は形成されます。「受信機(IPPオブジェクトかIPPクライアント)が属性構文'テキスト'で属性をサポートするなら、両方が要求におけるフォームと応答であるとサポートしなければなりません。' 送付者(IPPクライアントかIPPが反対する)はどんなそのような属性のためにもどちらのフォームも送るかもしれません。 送付者がWithoutLanguageフォームを送ると、暗黙の自然言語は「属性自然言語」操作属性で指定されます。(すべての送付者があらゆる要求と応答にそれを含まなければなりません)。
When a sender sends a WithLanguage form, it MAY be different from the implicit natural language supplied by the sender or it MAY be the same. The receiver MUST treat either form equivalently.
送付者がWithLanguageフォームを送るとき、それが送付者によって供給された暗黙の自然言語と異なるかもしれませんか、またはそれは同じであるかもしれません。 受信機は同等にどちらのフォームも扱わなければなりません。
There is an implementation decision for senders, whether to always send the WithLanguage forms or use the WithoutLanguage form when the attribute's natural language is the same as the request or response.
送付者、属性の自然言語が要求と同じであるときに、いつもWithLanguageフォームを送るか、WithoutLanguageフォームを使用するか、そして、または応答のための実装決定があります。
Hastings, et al. Informational [Page 53] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [53ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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フォームをサポートしない非の従う受信機で相互働くのを許容します。各アプローチはうま味があるように、選択が完全な送付者のimplementer次第です。
Furthermore, when a client receives a 'text' or 'name' job attribute that it had previously supplied, that client MUST NOT expect to see the attribute in the same form, i.e., in the same WithoutLanguage or WithLanguage form as the client supplied when it created the job. The IPP object is free to transform the attribute from the WithLanguage form to the WithoutLanguage form and vice versa, as long as the natural language is preserved. However, in order to meet this latter requirement, it is usually simpler for the IPP object implementation to store the natural language explicitly with the attribute value, i.e., to store using an internal representation that resembles the WithLanguage form.
クライアントがそれが以前に供給した'テキスト'か'名前'仕事の属性を受けるとき、その上、そのクライアントは、同じフォームの属性を見ると予想してはいけません、すなわち、雇用を創り出したとき供給されたクライアントとしての同じWithoutLanguageかWithLanguageフォームで。 IPPオブジェクトは結合していなく逆もまた同様に属性を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 Printerは仕事の自然言語をコピーしなければなりません、すなわち、クライアントによって中に供給された「属性自然言語」操作属性の値、操作を作成してください、Job記述属性としてのJobオブジェクトに、クライアントがそれについて質問できるように。 Get仕事の属性応答を返す際に、3自然言語のIPPオブジェクト5月の復帰1は応答で操作が結果と考える「属性自然言語」を評価します: (1) それは(3) リクエスタ、(2)による仕事の自然言語、またはIPP Printerの構成された自然言語を要求しました、要求された言語がIPP Printerによってサポートされないなら。
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.
この「属性自然言語」Job記述属性は仕事を提出したユーザの言葉を借りて言えばスタートシートを印刷するIPPオブジェクト実装の役に立ちます。 この同じJob記述属性は異なった自然言語で異なった仕事のsubmittersとコミュニケートしなければならない多言語オペレータの役に立ちます。 将来仕事のsubmitterの自然言語の通知メッセージを生成するのにこの同じJob記述属性が使用されると予想されます。
Early drafts of [RFC2911] contained a job-level natural language override (NLO) for the Get-Jobs response. A job-level (NLO) is an (unrequested) Job Attribute which then specified the implicit natural language for any other WithoutLanguage job attributes returned in the response for that job. Interoperability testing of early implementations showed that no one was implementing the job-level NLO in Get-Job responses. So the job-level NLO was eliminated from the Get-Jobs response. This simplification makes all requests and responses consistent in that the implicit natural language for any
[RFC2911]の早めの草稿はGet-ジョブス応答のための仕事レベル自然言語オーバーライド(NLO)を含みました。 仕事レベル(NLO)はその仕事のための応答で返されたいかなる他のWithoutLanguage仕事の属性のための暗黙の自然言語もその時指定した(非要求しました)仕事のAttributeです。 早めの実装の相互運用性テストは、だれもGet-仕事の応答で仕事の平らなNLOを実装していなかったのを示しました。 それで、仕事の平らなNLOはGet-ジョブス応答から排除されました。 この簡素化は、いずれのためにもすべてを要求にして、それで一貫した応答を暗黙の自然言語にします。
Hastings, et al. Informational [Page 54] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [54ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute.
要求か応答の「属性自然言語」操作属性でWithoutLanguage'テキスト'か'名前'フォームをいつも与えます。
3.1.3 Status codes returned by operation
3.1.3 操作で返されたステータスコード
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「操作応答ステータスコードとステータスメッセージ」に対応します。 このセクションは最初の操作(印刷仕事)ですべてのステータスコードを一度記載します。 そして、それは異なって、その後の操作のために各操作で専門にされるステータスコードを記載します。
3.1.3.1 Printer Operations
3.1.3.1 プリンタ操作
3.1.3.1.1 Print-Job
3.1.3.1.1 印刷仕事
The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 13 in [RFC2911] for a more complete description of each status code.
Printerオブジェクトは示された理由で以下の「ステータスコード」値の1つを返さなければなりません。 成功か誤りに応答を返す前にドキュメントデータのすべてを受け入れたかどうかが実装によります。 [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:
以下の成功ステータスコードにおいて、Jobオブジェクトが作成されて、「仕事イド」、および「仕事-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は、属性を無視したか、または代入しました: (2) いくつかの供給された(1)属性が無視されたか、またはサポートされない属性構文か値をサポートしている値で代入したか、無視しました。 応答のUnsupported Attributesグループでサポートされない属性、構文の属性もの、または値を返さなければなりません。
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.
うまくいっている間違いない闘争属性: いくつかの供給された属性値と他の供給された属性の値と衝突して、代入したか、または無視しました。 クライアントによって供給される応答のUnsupported Attributesグループで他の属性と衝突して、代入するか、または無視した属性か値を返さなければなりません。
[RFC2911] section 3.1.6 Operation Status Codes and Messages states:
[RFC2911]セクション3.1の.6Operation Status CodesとMessagesは以下を述べます。
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-
Printerであるなら、オブジェクトは「ステータスメッセージ」操作属性をサポートして、それはREQUIRED'utf-8'が以下の誤りステータスコードのためのステータスメッセージを返すためにcharsetするSHOULD使用([RFC2911]でセクション13を見る)です: 'クライアントの誤りの悪い要求'、'サポートされなかったクライアント誤りcharset'、'サーバ誤り内部エラー'、'サーバ'
Hastings, et al. Informational [Page 55] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [55ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
'操作がサポートしなかった誤り'、'サーバ誤りバージョンでサポートされない'。 この場合、それは誤り応答で「属性-charset」操作属性の値を'utf-8'に設定しなければなりません。
For the following error status codes, no job is created and no
"job-id" or "job-uri" is returned:
以下の誤りステータスコードにおいて、雇用を全く創り出しません、そして、「仕事イド」か「仕事-uri」を全く返しません:
client-error-bad-request: The request syntax does not conform
to the specification.
クライアントの誤りの悪い要求: 要求構文は仕様に従いません。
client-error-forbidden: The request is being refused for
authorization or authentication reasons. The implementation
security policy is to not reveal whether the failure is one of
authentication or authorization.
禁じられたクライアント誤り: 要求は承認か認証理由で拒否されています。 実装安全保障政策は失敗が認証か承認で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-authorized: The requester is not authorized
to perform the request on the target object.
認可されなかったクライアント誤り: リクエスタが目標オブジェクトに要求を実行するのが認可されません。
client-error-not-possible: The request cannot be carried out
because of the state of the system. See also 'server-error-
not-accepting-jobs' status code, which MUST take precedence if
the Printer object's "printer-accepting-jobs" attribute is
'false'.
可能でないクライアント誤り: システムの事情のために要求を行うことができません。 また、'サーバ誤り受け入れていない仕事'ステータスコードを見てください。(Printerオブジェクトの「プリンタ受諾仕事」属性が'誤っている'なら、それは、優先しなければなりません)。
client-error-timeout: not applicable.
クライアント誤りタイムアウト: 適切でない。
client-error-not-found: the target object does not exist.
見つけられなかったクライアント誤り: 目標オブジェクトは存在していません。
client-error-gone: the target object no longer exists and no
forwarding address is known.
クライアント誤り過ぎ去る、: 目標オブジェクトはもう存在していません、そして、フォーワーディング・アドレスは全く知られていません。
client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to
process it.
クライアント誤りは大き過ぎる状態で実体を要求します: 要求、そして/または、印刷データのサイズはIPP Printerがそれを処理する容量を超えています。
client-error-request-value-too-long: the size of request
variable length attribute values, such as 'text' and 'name'
attribute syntax's, exceed the maximum length specified in
[RFC2911] for the attribute and MUST be returned in the
Unsupported Attributes Group.
クライアント誤りはあまりに長い間、値を要求します: 構文の'テキスト'と'名前'属性ものなどの要求可変長属性値のサイズを属性のために[RFC2911]で指定された最大の長さを超えて、Unsupported Attributes Groupで返さなければなりません。
Hastings, et al. Informational [Page 56] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [56ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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'.
供給、サポートされません。 Unsupported Attributes Groupでサポートされない値がある「ドキュメント・フォーマット」属性を返さなければなりません。 'クライアント誤り-charsetによってサポートされないこと'を除いて、この誤りSHOULDはいかなる他の'サポートされなかったxxx'誤りの上でも優先します。
client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntax's, or values are not
supported and the client supplied the "ipp-attributes-
fidelity" operation attribute with a 'true' value. They MUST
be returned in the Unsupported Attributes Group as explained
below.
属性か値がサポートしなかったクライアント誤り: 1つ以上の供給された属性、構文の属性もの、または値がサポートされませんでした、そして、クライアントは'本当'の値と共に「ipp属性の信義」の操作属性を供給しました。 以下で説明されるUnsupported Attributes Groupでそれらを返さなければなりません。
client-error-uri-scheme-not-supported: not applicable.
uri体系がサポートしなかったクライアント誤り: 適切でない。
client-error-charset-not-supported: the charset supplied in
the "attributes-charset" operation attribute is not supported.
The Printer's "configured-charset" MUST be returned in the
response as the value of the "attributes-charset" operation
attribute and used for any 'text' and 'name' attributes
returned in the error response. This error SHOULD take
precedence over any other error, unless the request syntax is
so bad that the client's supplied "attributes-charset" cannot
be determined.
charsetがサポートしなかったクライアント誤り: 「属性-charset」操作属性で供給されたcharsetはサポートされません。 Printerの「構成されたcharset」を「属性-charset」操作属性の値として応答で返されて、誤り応答で返されたどんな'テキスト'と'名前'属性にも使用しなければなりません。 この誤りSHOULDはいかなる他の誤りの上でも優先します、要求構文が非常に悪いのでクライアントの供給された「属性-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属性信義」操作属性を提供する互いとクライアントと闘争しました。 以下で説明されるUnsupported Attributes Groupでそれらを返さなければなりません。
server-error-internal-error: an unexpected condition prevents
the request from being fulfilled.
サーバ誤り内部エラー: 予期していなかった状態は、要求が実現するのを防ぎます。
server-error-operation-not-supported: not applicable (since
Print-Job is REQUIRED).
操作がサポートしなかったサーバ誤り: 適切ではありません(Print-仕事がREQUIREDであるので)。
server-error-service-unavailable: the service is temporarily
overloaded.
入手できないサーバ誤りサービス: サービスは一時積みすぎられます。
server-error-version-not-supported: the version in the request
is not supported. The "closest" version number supported MUST
be returned in the response.
サポートされなかったサーバ誤りバージョン: 要求におけるバージョンはサポートされません。 応答で数がサポートした「最も近い」バージョンを返さなければなりません。
server-error-device-error: a device error occurred while
receiving or spooling the request or document data or the IPP
Printer object can only accept one job at a time.
サーバ誤りデバイス誤り: 要求、ドキュメントデータまたはIPP Printerオブジェクトを受け取るか、またはスプールする場合、一度に1つの仕事しか受け入れることができませんが、デバイス誤りは発生しました。
Hastings, et al. Informational [Page 57] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [57ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.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-not-accepting-jobs: the Printer object's
"printer-is-not-accepting-jobs" attribute is 'false'.
仕事を受け入れないサーバ誤り: Printerオブジェクトの「プリンタは仕事を受け入れていない」属性が'誤っています'。
server-error-busy: the Printer is too busy processing jobs to
accept another job at this time.
誤りが忙しくするサーバ: Printerは、仕事を処理することでこのとき別口の仕事を受け入れることができないくらい忙しいです。
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
document data.
サーバ誤り仕事は中止されました: クライアントがドキュメントデータを送っていた間、仕事はオペレータかシステムによって中止されています。
3.1.3.1.2 Print-URI
3.1.3.1.2 印刷URI
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでPrint-URIに適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
client-error-uri-scheme-not-supported: the URI scheme supplied
in the "document-uri" operation attribute is not supported and
is returned in the Unsupported Attributes group.
uri体系がサポートしなかったクライアント誤り: 「ドキュメント-uri」操作属性で供給されたURI体系を、サポートしないで、Unsupported Attributesグループで返します。
server-error-operation-not-supported: the Print-URI operation
is not supported.
操作がサポートしなかったサーバ誤り: Print-URI操作はサポートされません。
3.1.3.1.3 Validate-Job
3.1.3.1.3 仕事を有効にします。
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてがValidate-仕事に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
3.1.3.1.4 Create-Job
3.1.3.1.4雇用を創り出します。
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでCreate-仕事に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
server-error-operation-not-supported: the Create-Job operation
is not supported.
操作がサポートしなかったサーバ誤り: Create-仕事の操作はサポートされません。
Hastings, et al. Informational [Page 58] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [58ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
複数のドキュメント仕事がサポートしなかったクライアント誤り: Create-仕事とSend-ドキュメント操作がサポートされている間、この実装はデータで1通以上のドキュメントを支えません。
3.1.3.1.5 Get-Printer-Attributes
3.1.3.1.5 プリンタ属性を得てください。
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでGetプリンタ属性操作に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the requested
attributes are returned in Group 3 in the response:
以下の成功ステータスコードにおいて、要求された属性はGroup3で応答で返されます:
successful-ok: no operation attributes or values were
substituted or ignored (same as Print-Job) and no requested
attributes were unsupported.
うまくいっているOK: どんな操作属性も値も代入しなかったか、または(Print-仕事と同じ)であることで無視された、要求されなかった属性はサポートされなかったです。
successful-ok-ignored-or-substituted-attributes: The
"requested-attributes" operation attribute MAY, but NEED NOT,
be returned with the unsupported values.
うまくいっているOKは、属性を無視したか、または代入しました: NOTを必要として、サポートされない値と共に返して、「要求された属性」操作属性はそうするかもしれません。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
For the error status codes, Group 3 is returned containing no attributes or is not returned at all:
誤りステータスコードにおいて、Group3を属性を全く含んでいなくて、返すか、または全く返しません:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
可能でないクライアント誤り: Print-仕事と同じであることで、さらに、Printerオブジェクトはどんな要求も受け入れていません。
client-error-request-entity-too-large: same as Print-job,
except that no print data is involved.
クライアント誤りは大き過ぎる状態で実体を要求します: 印刷データが全くかかわらないのを除いたPrint-仕事と同じこと。
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.
クライアント誤り闘争属性: それを除いたPrint-仕事の「ipp属性信義」がかかわらないのと同じです。
server-error-operation-not-supported: not applicable (since
Get-Printer-Attributes is REQUIRED).
操作がサポートしなかったサーバ誤り: 適切ではありません(Getプリンタ属性がREQUIREDであるので)。
server-error-device-error: same as Print-Job, except that no
document data is involved.
サーバ誤りデバイス誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと。
Hastings, et al. Informational [Page 59] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [59ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
server-error-temporary-error: same as Print-Job, except that
no document data is involved.
サーバの誤りの一時的な誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと。
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-busy: same as Print-Job, except the IPP object is
too busy to accept even query requests.
誤りが忙しくするサーバ: Print-仕事と同じであることで、IPPを除いて、オブジェクトは質問要求さえ受け入れることができないくらい忙しいです。
server-error-job-canceled: not applicable.
サーバ誤り仕事は中止されました: 適切でない。
3.1.3.1.6 Get-Jobs
3.1.3.1.6 ジョブスを得ます。
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでGet-ジョブス操作に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードにおいて、要求された属性はGroup3で応答で返されます:
successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5).
うまくいっているOK: セクション3.1を見てください。Getプリンタ属性と同じこと、(.3 .1 .5)。
successful-ok-ignored-or-substituted-attributes: same as Get-
Printer-Attributes (see section 3.1.3.1.5).
うまくいっているOKは、属性を無視したか、または代入しました: セクション3.1を見てください。Getプリンタ属性と同じこと、(.3 .1 .5)。
successful-ok-conflicting-attributes: same as Get-Printer-
Attributes (see section 3.1.3.1.5).
うまくいっている間違いない闘争属性: セクション3.1を見てください。Get-プリンタ属性と同じこと、(.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:
どんな誤りステータスコードにおいても、Group3を属性を全く含んでいなくて、返すか、または全く返しません。 以下の簡潔なエラー状況コード記述はGet-ジョブス操作で使用のためのユニークな情報を含んでいます。 一様にすべての操作に適用される他の誤りステータスコードに関してセクション14を見てください:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
可能でないクライアント誤り: Print-仕事と同じであることで、さらに、Printerオブジェクトはどんな要求も受け入れていません。
client-error-request-entity-too-large: same as Print-job,
except that no print data is involved.
クライアント誤りは大き過ぎる状態で実体を要求します: 印刷データが全くかかわらないのを除いたPrint-仕事と同じこと。
client-error-document-format-not-supported: not applicable.
形式が支えなかったクライアント誤りドキュメント: 適切でない。
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
属性か値がサポートしなかったクライアント誤り: 適切でないことで、サポートされない操作以来、属性、そして/または、値を無視しなければなりませんでした、そして、適切な成功コードは戻りました(上を見てください)。
Hastings, et al. Informational [Page 60] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [60ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
クライアント誤り闘争属性: それを除いたPrint-仕事の「ipp属性信義」がかかわらないのと同じです。
server-error-operation-not-supported: not applicable (since
Get-Jobs is REQUIRED).
操作がサポートしなかったサーバ誤り: 適切ではありません(Get-ジョブスがREQUIREDであるので)。
server-error-device-error: same as Print-Job, except that no
document data is involved.
サーバ誤りデバイス誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと。
server-error-temporary-error: same as Print-Job, except that
no document data is involved.
サーバの誤りの一時的な誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと。
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-job-canceled: not applicable.
サーバ誤り仕事は中止されました: 適切でない。
3.1.3.1.7 Pause-Printer
3.1.3.1.7 くぎりプリンタ
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いがあるPause-プリンタに適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the Printer object is being stopped from scheduling jobs on all its devices.
以下の成功ステータスコードにおいて、Printerオブジェクトはすべてのデバイスでジョブをスケジュールするのが止められています。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
うまくいっているOKは、属性を無視したか、または代入しました: Print-仕事と同じです。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
For any of the error status codes, the Printer object has not been stopped from scheduling jobs on all its devices.
誤りステータスコードのいずれにおいても、Printerオブジェクトはすべてのデバイスでジョブをスケジュールするのが止められていません。
client-error-not-possible: not applicable.
可能でないクライアント誤り: 適切でない。
client-error-not-found: the target Printer object does not
exist.
見つけられなかったクライアント誤り: 目標Printerオブジェクトは存在していません。
client-error-gone: the target Printer object no longer exists
and no forwarding address is known.
クライアント誤り過ぎ去る、: 目標Printerオブジェクトはもう存在していません、そして、フォーワーディング・アドレスは全く知られていません。
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
クライアント誤りは大き過ぎる状態で実体を要求します: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
Hastings, et al. Informational [Page 61] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [61ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
client-error-document-format-not-supported: not applicable.
形式が支えなかったクライアント誤りドキュメント: 適切でない。
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
クライアント誤り闘争属性: Print-仕事と同じであることで、Printerが「プリンタは受諾仕事している」以外に、属性がかかわりません。
server-error-operation-not-supported: the Pause-Printer
operation is not supported.
操作がサポートしなかったサーバ誤り: Pause-プリンタ操作はサポートされません。
server-error-device-error: not applicable.
サーバ誤りデバイス誤り: 適切でない。
server-error-temporary-error: same as Print-Job, except no
document data is involved.
サーバの誤りの一時的な誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-job-canceled: not applicable.
サーバ誤り仕事は中止されました: 適切でない。
3.1.3.1.8 Resume-Printer
3.1.3.1.8 履歴書プリンタ
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専門化があるResponseがPauseのために説明した.1Print-仕事のプリンタのPrint-地位のコード記述のすべてがResume-プリンタに適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the Printer object resumes scheduling jobs on all its devices.
以下の成功ステータスコードのために、Printerオブジェクトは、すべてのデバイスでジョブをスケジュールするのを再開します。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
うまくいっているOKは、属性を無視したか、または代入しました: Print-仕事と同じです。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
For any of the error status codes, the Printer object does not resume scheduling jobs.
誤りステータスコードのいずれのためにも、Printerオブジェクトは、ジョブをスケジュールするのを再開しません。
server-error-operation-not-supported: the Resume-Printer
operation is not supported.
操作がサポートしなかったサーバ誤り: Resume-プリンタ操作はサポートされません。
Hastings, et al. Informational [Page 62] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [62ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.3.1.8.1 What about Printers unable to change state due to an error
condition?
3.1.3.1.8.1 エラー条件のため状態を変えることができないPrintersはどうですか?
If, in case, the IPP printer is unable to change its state due to some problem with the actual printer device (say, it is shut down or there is a media-jam as indicated in [RFC2911]), what should be the result of the "Resume-Printer" operation? Should it still change the 'printer-state-reasons' and return success or should it fail ?
実際のプリンタデバイスに関する何らかの問題のため、場合では、IPPプリンタが状態を変えることができないなら(たとえば、それが止められるか、またはメディアジャムが[RFC2911]にみられるようにあります)、「履歴書プリンタ」操作の結果は何であるべきですか? まだ'プリンタ州の理由'を変えていて、成功を返すべきですか、それは失敗するべきですか?
The Resume-Printer operation must clear the 'paused' or 'moving-to- paused' 'printer-state-message'. The operation must return a 'successful-ok' status code.
Resume-プリンタ操作が'ポーズ'か'運動をクリアしなければならない、-、-ポーズされて、''プリンタ状態は通信します'。 操作は'うまくいっているOK'ステータスコードを返さなければなりません。
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?
3.1.3.1.8.2 「プリンタ状態」はResume-プリンタの上でどのように扱われますか?
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-プリンタ操作が成功するなら、「プリンタ状態」の値は何であるべきです、そして、だれが後で「プリンタ状態」属性値の世話をするべきですか?
The Resume-Printer operation may change the "printer-state-reasons" value.
Resume-プリンタ操作は「プリンタ州の理由」値を変えるかもしれません。
The "printer-state" will change to one of three states:
「プリンタ状態」は3つの州の1つに変化するでしょう:
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番目の場合では、もうエラー条件を検出しないとき、オートマトンは存在しています。 状態が可能にすると、「プリンタ状態」は'怠けてください'か'処理'に移行するでしょう。 (すなわち、それ以上のエラー条件がありません)
3.1.3.1.9 Purge-Printer
3.1.3.1.9 パージプリンタ
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専門化があるResponseがPauseのために説明した.1Print-仕事のプリンタのPrint-地位のコード記述のすべてがPurge-プリンタに適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the Printer object purges all it's jobs.
すべてを掃除する成功ステータスコード、Printerが、反対する以下に関しては、それは仕事です。
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。
Hastings, et al. Informational [Page 63] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [63ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
うまくいっているOKは、属性を無視したか、または代入しました: Print-仕事と同じです。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
For any of the error status codes, the Printer object does not purge any jobs.
誤りステータスコードのいずれのためにも、Printerオブジェクトはどんな仕事も掃除しません。
server-error-operation-not-supported: the Purge-Printer
operation is not supported.
操作がサポートしなかったサーバ誤り: Purge-プリンタ操作はサポートされません。
3.1.3.2 Job Operations
3.1.3.2 仕事の操作
3.1.3.2.1 Send-Document
3.1.3.2.1 ドキュメントを発信させます。
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでGetプリンタ属性操作に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the document has been added to the specified Job object and the job's "number-of-documents" attribute has been incremented:
以下の成功ステータスコードにおいて、ドキュメントは指定されたJobオブジェクトに加えられます、そして、仕事の「ドキュメントの数」属性は増加されました:
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
うまくいっているOKは、属性を無視したか、または代入しました: Print-仕事と同じです。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
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:
誤りステータスコードにおいて、ドキュメントは全くJobオブジェクトに加えられていません、そして、仕事の「ドキュメントの数」属性は増加されていません:
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
可能でないクライアント誤り: Print-仕事と同じです、Printerが「プリンタは受諾仕事している」以外に、属性がかかわりません、クライアントが、この属性が'本当に'設定された後にCreate-仕事の操作で創り出された雇用を提出し終えることができるように。 別の状態は仕事の州がSend-ドキュメントを排除して、すなわち、仕事がそうしたということです。
Hastings, et al. Informational [Page 64] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [64ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
クライアントによって既に見切り売りされます。 しかしながら、IPP Printerが仕事を見切り売りしたなら、代わりにタイムアウト、'クライアント誤りタイムアウト'エラー状況SHOULDを返しますか?
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 .
クライアント誤りタイムアウト: Printerが仕事を終えた後にこの要求を送りました、Printerの「複数の操作しているタイムアウト」の期間中にSend-ドキュメントかSend-URI操作を受けていないので。
client-error-request-entity-too-large: same as Print-Job.
クライアント誤りは大き過ぎる状態で実体を要求します: Print-仕事と同じです。
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attributes-fidelity" operation attribute is not
involved..
クライアント誤り闘争属性: Print-仕事と同じであることで、その「ipp属性信義」以外に、操作属性はかかわりません。
server-error-operation-not-supported: the Send-Document
request is not supported.
操作がサポートしなかったサーバ誤り: Send-資料請求はサポートされません。
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
data.
サーバ誤り仕事は中止されました: クライアントがデータを送っていた間、仕事はオペレータかシステムによって中止されています。
3.1.3.2.2 Send-URI
3.1.3.2.2 URIを発信させます。
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Send- Document are applicable to Send-URI. See Section 13 in [RFC2911] for a more complete description of each status code.
セクション3.1.3.1専門化があるResponseがSendのために説明した.1Print-仕事のドキュメントにおけるPrint-地位のコード記述のすべてが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体系がサポートしなかったクライアント誤り: 「ドキュメント-uri」操作属性で供給されたURI体系はサポートされません、そして、Unsupported Attributesグループで「ドキュメント-uri」属性を返さなければなりません。
server-error-operation-not-supported: the Send-URI operation is
not supported.
操作がサポートしなかったサーバ誤り: Send-URI操作はサポートされません。
3.1.3.2.3 Cancel-Job
3.1.3.2.3 キャンセル仕事
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでキャンセル仕事に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the Job object is being canceled or has been canceled:
以下の成功ステータスコードにおいて、Jobオブジェクトは、取り消されているか、または取り消されました:
Hastings, et al. Informational [Page 65] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [65ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
うまくいっているOKは、属性を無視したか、または代入しました: Print-仕事と同じです。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
For any of the error status codes, the Job object has not been canceled or was previously canceled.
誤りステータスコードのいずれにおいても、Jobオブジェクトは、取り消されなかったか、または以前に、取り消されました。
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.
可能でないクライアント誤り: Jobオブジェクト('完成される'か、'取り消される'か、または'中止される')の州かシステムの事情のために要求を行うことができません。
client-error-not-found: the target Printer and/or Job object
does not exist.
見つけられなかったクライアント誤り: 目標Printer、そして/または、Jobオブジェクトは存在していません。
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
クライアント誤り過ぎ去る、: 目標Printer、そして/または、Jobオブジェクトはもう存在していません、そして、フォーワーディング・アドレスは全く知られていません。
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
クライアント誤りは大き過ぎる状態で実体を要求します: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
client-error-document-format-not-supported: not applicable.
形式が支えなかったクライアント誤りドキュメント: 適切でない。
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and values
MUST be ignored.
属性か値がサポートしなかったクライアント誤り: 適切でないことで、サポートされない操作以来、属性と値を無視しなければなりません。
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
クライアント誤り闘争属性: Print-仕事と同じであることで、Printerが「プリンタは受諾仕事している」以外に、属性がかかわりません。
server-error-operation-not-supported: not applicable (Cancel-
Job is REQUIRED).
操作がサポートしなかったサーバ誤り: 適切ではありません(キャンセル仕事はREQUIREDです)。
server-error-device-error: same as Print-Job, except no
document data is involved.
サーバ誤りデバイス誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
server-error-temporary-error: same as Print-Job, except no
document data is involved.
サーバの誤りの一時的な誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-job-canceled: not applicable.
サーバ誤り仕事は中止されました: 適切でない。
Hastings, et al. Informational [Page 66] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [66ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.3.2.4 Get-Job-Attributes
3.1.3.2.4 仕事の属性を得てください。
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでGet仕事の属性に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードにおいて、要求された属性はGroup3で応答で返されます:
successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5).
うまくいっているOK: セクション3.1を見てください。Getプリンタ属性と同じこと、(.3 .1 .5)。
successful-ok-ignored-or-substituted-attributes: same as Get-
Printer-Attributes (see section 3.1.3.1.5).
うまくいっているOKは、属性を無視したか、または代入しました: セクション3.1を見てください。Getプリンタ属性と同じこと、(.3 .1 .5)。
successful-ok-conflicting-attributes: same as Get-Printer-
Attributes (see section 3.1.3.1.5).
うまくいっている間違いない闘争属性: セクション3.1を見てください。Get-プリンタ属性と同じこと、(.3 .1 .5)。
For the error status codes, Group 3 is returned containing no attributes or is not returned at all.
誤りステータスコードにおいて、Group3を属性を全く含んでいなくて、返すか、または全く返しません。
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
可能でないクライアント誤り: Print-仕事と同じであることで、さらに、Printerオブジェクトはどんな要求も受け入れていません。
client-error-document-format-not-supported: not applicable.
形式が支えなかったクライアント誤りドキュメント: 適切でない。
client-error-attributes-or-values-not-supported: not
applicable.
属性か値がサポートしなかったクライアント誤り: 適切でない。
client-error-uri-scheme-not-supported: not applicable.
uri体系がサポートしなかったクライアント誤り: 適切でない。
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
属性か値がサポートしなかったクライアント誤り: 適切でないことで、サポートされない操作以来、属性、そして/または、値を無視しなければなりませんでした、そして、適切な成功コードは戻りました(上を見てください)。
client-error-conflicting-attributes: not applicable
クライアント誤り闘争属性: 適切でない
server-error-operation-not-supported: not applicable (since
Get-Job-Attributes is REQUIRED).
操作がサポートしなかったサーバ誤り: 適切ではありません(Get仕事の属性がREQUIREDであるので)。
server-error-device-error: same as Print-Job, except no
document data is involved.
サーバ誤りデバイス誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
server-error-temporary-error: sane as Print-Job, except no
document data is involved..
サーバの誤りの一時的な誤り: Print-仕事として気が確かであることで、どんなドキュメント以外にも、データはかかわりません。
Hastings, et al. Informational [Page 67] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [67ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-job-canceled: not applicable.
サーバ誤り仕事は中止されました: 適切でない。
3.1.3.2.5 Hold-Job
3.1.3.2.5 保持仕事
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で説明したPrint-地位の.1.1Print-仕事のResponseのすべてが以下の専門化と違いでHold-仕事に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
For the following success status codes, the Job object is being held or has been held:
以下の成功ステータスコードにおいて、Jobオブジェクトは、持たれているか、または持たれています:
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
うまくいっているOKは、属性を無視したか、または代入しました: Print-仕事と同じです。
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっている間違いない闘争属性: Print-仕事と同じです。
For any of the error status codes, the Job object has not been held or was previously held.
誤りステータスコードのいずれにおいても、Jobオブジェクトは、持たれていなかったか、または以前に、持たれていました。
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.
可能でないクライアント誤り: Jobオブジェクト('完成される'か、'取り消される'か、または'中止される')の州かシステムの事情のために要求を行うことができません。
client-error-not-found: the target Printer and/or Job object
does not exist.
見つけられなかったクライアント誤り: 目標Printer、そして/または、Jobオブジェクトは存在していません。
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
クライアント誤り過ぎ去る、: 目標Printer、そして/または、Jobオブジェクトはもう存在していません、そして、フォーワーディング・アドレスは全く知られていません。
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
クライアント誤りは大き過ぎる状態で実体を要求します: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
client-error-document-format-not-supported: not applicable.
形式が支えなかったクライアント誤りドキュメント: 適切でない。
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
クライアント誤り闘争属性: Print-仕事と同じであることで、Printerが「プリンタは受諾仕事している」以外に、属性がかかわりません。
server-error-operation-not-supported: the Hold-Job operation is
not supported.
操作がサポートしなかったサーバ誤り: Hold-仕事の操作はサポートされません。
server-error-device-error: not applicable.
サーバ誤りデバイス誤り: 適切でない。
Hastings, et al. Informational [Page 68] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [68ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
server-error-temporary-error: same as Print-Job, except no
document data is involved.
サーバの誤りの一時的な誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。
server-error-not-accepting-jobs: not applicable.
仕事を受け入れないサーバ誤り: 適切でない。
server-error-job-canceled: not applicable.
サーバ誤り仕事は中止されました: 適切でない。
3.1.3.2.6 Release-Job
3.1.3.2.6 リリース仕事
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.
専門化がある.1.1Print-仕事のResponseがHold-仕事のために説明したセクション3.1.3におけるPrint-地位のコード記述のすべてがRelease-仕事に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
server-error-operation-not-supported: the Release-Job operation
is not supported.
操作がサポートしなかったサーバ誤り: Release-仕事の操作はサポートされません。
3.1.3.2.7 Restart-Job
3.1.3.2.7 再開仕事
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.
専門化がある.1.1Print-仕事のResponseがHold-仕事のために説明したセクション3.1.3におけるPrint-地位のコード記述のすべてがRestart-仕事に適切です。 [RFC2911]でそれぞれのステータスコードの、より完全な記述に関してセクション13を見てください。
server-error-operation-not-supported: the Restart-Job operation
is not supported.
操作がサポートしなかったサーバ誤り: Restart-仕事の操作はサポートされません。
3.1.3.2.7.1 Can documents be added to a restarted job?
3.1.3.2.7.1 再開している仕事にドキュメントを加えることができますか?
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-仕事の要求を与えると仮定してください。 ドキュメントが印刷させて、完成されて、仕事の状態が動かされるすべて。 私は仕事に関するRestart-仕事の要求を出します。 現在、問題はそれです、私が再開している仕事に新しいドキュメントを加えようとするならIPP Serverは、私がそうするか、「可能でないクライアント誤り」を返して、または再びそれらの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 Printerオブジェクトの始めを再開します。」と、.7のセクション3.3IPP/1.1モデルが述べます。 'ドキュメントの数'は仕事の属性です。
Hastings, et al. Informational [Page 69] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [69ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
1.18)
3.1.4 Get-Xxxx応答における戻っているサポートされない属性(問題1.18)
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes responses, the client cannot depend on getting unsupported attributes returned in the Unsupported Attributes group that the client requested, but are not supported by the IPP object. However, such unsupported requested attributes will not be returned in the Job Attributes or Printer Attributes group (since they are unsupported). Furthermore, the IPP object is REQUIRED to return the 'successful- ok-ignored-or-substituted-attributes' status code, so that the client knows that not all that was requested has been returned.
Getプリンタ属性、Get-仕事、またはGet仕事の属性応答では、クライアントはクライアントが要求したUnsupported Attributesグループで返しますが、サポートされない属性がIPPオブジェクトによってサポートされない得るのを当てにすることができません。 しかしながら、そのようなサポートされない要求された属性はJob AttributesかPrinter Attributesグループで返されないでしょう(彼らがサポートされないので)。 その上、IPPオブジェクトは'うまくいっている間違いない無視されたか代入された属性'ステータスコードを返すREQUIREDです、クライアントが、要求されたというわけではないすべてが返されたのを知るように。
3.1.5 Sending empty attribute groups
3.1.5 送付の空の属性グループ
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]仕様RECOMMENDは要求か応答で分類します。 しかしながら、それら、空の属性グループがそのグループの省略に同等であると受け入れるREQUIRE a受信機。 したがって、クライアントSHOULDは完全にaのグループが作成するJob Template Attributesを省略します。どんなJob Template属性も供給するのではなく、作動。 同様に、応答で返されるどんなサポートされない属性もなければ、IPPオブジェクトSHOULDは空のUnsupported Attributesグループを省略します。
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]仕様REQUIRES a受信機。 「受信機」という用語は要求のためのIPPオブジェクトと応答のためのクライアントを意味します。 '「送付者'という用語は要求のためのクライアントと応答のためのIPPオブジェクトを意味します」。
There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2910] contains the following paragraph:
返される属性が全くないとき、Get-ジョブスのための規則への例外があります。 [RFC2910]は以下のパラグラフを含んでいます:
The syntax allows an xxx-attributes-tag to be present when the xxx- attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
従うxxx属性順序が空であるときに、構文は、xxx属性タグが現在であるのを許容します。 構文は、属性が全くいくつかの仕事オブジェクトのために返されないところでGet-ジョブスの応答を考慮するためにこの道と定義されます。 属性(ただ言及されたGet-ジョブス応答を除いた)が全くなければ送付者がxxx属性タグを送らないのが、RECOMMENDEDですが、受信機はそのような構文を解読できなければなりません。
Hastings, et al. Informational [Page 70] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [70ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.2 Printer Operations
3.2 プリンタ操作
3.2.1 Print-Job operation
3.2.1 印刷仕事の操作
3.2.1.1 Flow controlling the data portion of a Print-Job request (Issue
1.22)
3.2.1.1 Print-仕事の要求のデータ部を制御する流れ(問題1.22)
A paused printer, or one that is stopped due to paper out or jam or spool space full or buffer space full, may flow control the data of a Print-Job operation (at the TCP/IP layer), so that the client is not able to send all the document data. Consequently, the Printer will not return a response until the condition is changed.
ポーズされたプリンタ、またはいっぱいに紙への支払われるべきものにストライキを続けさせるか、詰め込むか、スペースをいっぱいにスプールするか、またはスペースをバッファリングすることであるもの、フロー制御、クライアントがすべてのドキュメントデータを送ることができるというわけではないためのPrint-仕事の操作(TCP/IP層の)に関するデータであるかもしれない。 その結果、Printerは状態を変えるまで応答を返さないでしょう。
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.
エラーコードがこれらの状態のどれかにある状態で、Printerは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 Printersをテストするためにテストスクリプトを書く際に、応答を予想しないようにスクリプトを書かなければなりません、プリンタがポーズされたなら、プリンタが再開されるまで、すべての可能な実装で働くために。
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
3.2.1.2 Print-仕事の応答における戻っている仕事状態(問題1.30)
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クライアントはPrint-仕事で小さい仕事を提出します。 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".
Modelは、ドキュメント内容を受け入れる前にさえPrinterが応答を返すのを示します。 IPPオブジェクトが成功ステータスコードの1つを返す場合にだけ、Job Object Attributesを返します。 そして、仕事状態は、いつも「未定である」か「未定に保持されているでしょう」。
This issue comes up for the implementation of an IPP Printer object as a server that forwards jobs to devices that do not provide job status back to the server. If the server is reasonably certain that the job completed successfully, then it should return the job-state as 'completed'. Also the server can keep the job in its "job history" long after the job is no longer in the device. Then a user could query the server and see that the job was in the 'completed' state and completed as specified by the jobs "time-at-completed" time, which would be the same as the server submitted the job to the device.
この問題はサーバへの地位の後部を提供しないデバイスに仕事を送るサーバとしてIPP Printerオブジェクトの実装を取りに上がります。サーバが仕事が首尾よく完了して、そうするべきであるのを合理的に確信しているなら、'完成される'ように仕事状態を返してください。 また、仕事がもういずれのデバイスにもないずっと後にサーバは「仕事の歴史」における仕事を保つことができます。 次に、ユーザがサーバについて質問して、仕事が仕事で指定されるように'完成した'状態にあって、完成しているのを見ることができた、「完成されて、調節する、」時間。(その時間はサーバがデバイスに仕事を提出したのと同じでしょう)。
Hastings, et al. Informational [Page 71] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [71ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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).
他方では、仕事が状態遷移をするとき、デバイスについて質問する、そして/または、サーバがデバイスが開始するある種のイベント通知をセットアップできるなら、サーバが、デバイス(または、デバイスについて質問できる)の仕事の状態が何であるかを知っているので、サーバはPrint-仕事の応答とその後の質問で現在の仕事の状態を返すことができます。
All of these alternatives depend on implementation of the server and the device.
これらの代替手段のすべてがサーバとデバイスの実装によります。
3.2.2 Get-Printer-Attributes operation
3.2.2 プリンタ属性を得ている操作
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).
Printerが「プリンタメーカーとモデル」属性をサポートして、その属性でプリンタの.INFファイル機種モデル名を返すと、マイクロソフトのクライアントは自動的に正しいドライバーをインストールするでしょう(利用可能であるなら)。
Clients which poll periodically for printer status or queued-job- count should use the "requested-attributes" operation attribute to limit the scope of the query in order to save Printer and network resources.
定期的にプリンタ状態か列に並ばせられた仕事カウントに投票するクライアントは、Printerとネットワーク資源を取っておくために質問の範囲を制限するのに「要求された属性」操作属性を使用するべきです。
3.2.3 Get-Jobs operation
3.2.3 ジョブスを得ている操作
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
1.39)?
3.2.3.1 ジョブスを得る、私、-仕事は'本当'、そして、および'要求しているユーザ名'(問題1.39)と等しいですか?
In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there too, and if it's not present what should the IPP printer do?
中、[RFC2911]セクション3.2 .6 .1 'ジョブスを得ているRequest'、属性であるなら私、-、仕事、'存在していて、TRUEに設定されて、また、'要求しているユーザ名'属性がそこにあるに違いなくて、それが存在していないなら、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はどんな操作のためにも存在しているのによる「ユーザ名を要求します」の様々なケースについて説明します。 クライアントが「要求しているユーザ名」に値を供給しないなら、プリンタは、クライアントが何らかの匿名の名前を提供していると仮定しなければなりません、「匿名であること」のように。
Hastings, et al. Informational [Page 72] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [72ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
3.2.3.2 「限界」属性はなぜGet-ジョブス操作中ですか?
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-ジョブス操作を使用するとき、クライアントimplementerは、1日のクライアントショーがscreenfulする仕事の数を制限するのを選ぶかもしれません。 例えば、UIが50の仕事しか表示できないなら、そうでなければ500の仕事を返すプリンタに対して自らを守ることができます、恐らく遅いダイヤルアップ系列で長くかかっていて。 そして、クライアントは最初の50の仕事をユーザに示している間、バックグラウンドにおける、より多くの仕事を求めに行くことができます。 逆順で仕事の歴史を返すので、すなわち、最初に最も最近完成した仕事を返して、たぶん返される最初の仕事にユーザを関心があります。 仕事の数を制限するのは特に長い仕事の歴史を保管するプリンタから'完成した'仕事を要求しているクライアントの役に立つかもしれません。 それが時々非常に大きい応答を得るのを気にしないで、「限界」属性を忘れることができる彼らのGet-ジョブスが要求するクライアント。
3.2.4 Create-Job operation
3.2.4 雇用を創り出している操作
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.
Printerは操作がPrinterによって受け入れられたのを示すためには未定の、そして、''未定に保持され'て「仕事の州の理由」'仕事データ不十分である'「仕事状態」と共にCreate-仕事の操作に応じるかもしれませんが、仕事を'処理'状態に動かすことができる前にPrinterは追加ドキュメントデータを予想しています。 あるいはまた、それは「仕事状態」'処理'と「仕事の州の理由」Create-仕事の操作がPrinterによって受け入れられましたが、Printerが追加Send-ドキュメント、そして/または、Send-URI操作を予想している、そして/または、アクセスするか、または受け入れているのを示すために'仕事の入って来る'ドキュメントデータで応じるかもしれません。 2番目の代替手段は'未定'の状態を実装しない非スプールPrintersのためのものです。
Should the server wait for the "last-document" operation attribute set to 'true' before starting to "process" the job?
サーバは、始まる前'本当'への「最後のドキュメント」操作属性セットが仕事を「処理すること」を待つべきですか?
It depends on implementation. Some servers spool the entire job, including all document data, before starting to process, so such an implementation would wait for the "last-document" before starting to process the job. If the time-out occurs without the "last-document", then the server takes one of the indicated actions in section 3.3.1 in the [RFC2911] document. Other servers will start to process document data as soon as they have some. These are the so-called "non-spooling" printers. Currently, there isn't a way for a client to determine whether the Printer will spool all the data or will start to process (and print) as soon as it has some data.
それは実装によります。 いくつかのサーバが仕事全体をスプールします、すべてのドキュメントデータを含んでいて、仕事を処理し始める前にそのような実装が「最後のドキュメント」を待って処理し始める前に。 タイムアウトが「最後のドキュメント」なしで起こるなら、サーバは[RFC2911]ドキュメントのセクション3.3.1における示された動作の1つを取ります。 それらに何かがあるとすぐに、他のサーバはドキュメントデータを処理し始めるでしょう。 これらはいわゆる「非スプール」プリンタです。 現在、それにいくつかのデータがあるとすぐに、クライアントが、Printerが、すべてのデータをスプールするか、または処理するのを出発するか(印刷する)を決心する方法がありません。
Hastings, et al. Informational [Page 73] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [73ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
3.3 Job Operations
3.3 仕事の操作
3.3.1 Validate-Job
3.3.1 仕事を有効にします。
The Validate-Job operation has been designed so that its implementation may be a part of the Print-Job operation. Therefore, requiring Validate-Job is not a burden on implementers. Also it is useful for client's to be able to count on its presence in all conformance implementations, so that the client can determine before sending a long document, whether the job will be accepted by the IPP Printer or not.
Validate-仕事の操作は、実装がPrint-仕事の操作の一部であることができるように設計されています。 したがって、Validate-仕事を必要とするのは、implementersでの負担ではありません。 また、それもしたがってすべての順応実装で存在を頼りにすることができる長いドキュメントを送る前にクライアントが決心できるクライアントのものの役に立ちます、仕事がIPP Printerによって受け入れられるか否かに関係なく。
3.3.2 Restart-Job
3.3.2 再開仕事
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-仕事の操作は完了した作業の再処理を許します。 いくつかの仕事がプリンタに関するドキュメントデータを保存します。 Print-仕事の操作を使用することで創り出される雇用は例です。 Restart-仕事の操作が引き継ぐように仕事が'完成した状態'に移行した後にプリンタが仕事のデータを保有するのが必要です。
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仕事の操作が発行されるとき、仕事は再処理されます。 仕事を印刷するために再び仕事のデータを検索しなければなりません。
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.
印刷データにアクセスするのを試みている間仕事が失敗するのは、可能です。 そのような仕事がRestart-仕事の目標であるときに、Printer SHALLは、再び仕事のデータを検索するのを試みます。
4 Object Attributes
4 オブジェクト属性
4.1 Attribute Syntax's
4.1属性構文のもの
4.1.1 The 'none' value for empty sets (Issue 1.37)
4.1.1 空集合のための'なにも'値(問題1.37)
[RFC2911] states that the 'none' value should be used as the value of a 1setOf when the set is empty. In most cases, sets that are potentially empty contain keywords so the keyword 'none' is used, but for the 3 finishings attributes, the values are enums and thus the empty set is represented by the enum 3. Currently there are no other attributes with 1setOf values, which can be empty and can contain values that are not keywords. This exception requires special code and is a potential place for bugs. It would have been better if we had chosen an out-of-band value, either "no-value" or some new value, such as 'none'. Since we didn't, implementations have to deal with the different representations of 'none', depending on the attribute syntax.
[RFC2911]は、セットが空であるときに、'なにも'値が1setOfの値として使用されるべきであると述べます。 多くの場合、潜在的に空のセットは'なにも'というキーワードが使用されていますが、3つの仕上げ属性のためのキーワードを含んでいます、そして、値はenumsです、そして、その結果、空集合はenum3によって表されます。 現在、1setOf値がある他の属性が全くありません。(値は、空である場合があり、キーワードでない値を含むことができます)。 この例外は、特別なコードを必要として、バグのための潜在的場所です。 私たちがバンドで出ている値を選んだなら、より良かったでしょうに、「値がありません」か何らかの新しい値のどちらか、'なにも'などのように。 私たちが対処しなかったので、属性構文によって、実装は'なにも'の異なった表現に対処しなければなりません。
Hastings, et al. Informational [Page 74] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [74ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
4.1.2 Multi-valued attributes (Issue 1.31)
4.1.2 マルチ評価された属性(問題1.31)
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.
マルチ評価された属性のための属性構文は何ですか? 以来いくつかの属性が1つ以上のデータ型の「メディア」などの値をサポートする、「仕事の保持、」 「仕事シート」、IPP意味論は属性構文を各値に関連づけます、全体でいずれの属性でも、そうしません。 プロトコルは属性構文タグを各値に関連づけます。 ただ属性構文タグが属性キーワードに優先するので、だまされないでください。 1日後のすべての属性値には、同じ属性のその後の価値のしるしとしてゼロ・レングス属性キーワードがあります。
4.1.3 Case Sensitivity in URIs (issue 1.6)
4.1.3 URIにおけるケース感度(問題1.6)
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のさまざまの大文字しているか小文字の本質を意識しているに違いありません。 RFC2396は、URL体系とHost名を大文字と小文字を区別しなく定義しますが、URLの残りがたぶんケース感度を示すだろうというのを私たちに思い出させます。 選択が完全に任意である分野へのURLを作成するとき、小文字を選択するのはたぶん最も良いです。 しかしながら、これを保証できません、そして、実装はどんなURLでURL体系を超えて大文字と小文字を区別するか、または大文字と小文字を区別しない分野とホスト名分野も当てにしてはいけません。
The reason that the IPP specification does not make any restrictions on URIs, is so that implementations of IPP may use off-the-shelf components that conform to the standards that define URIs, such as RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these specifications for rules of matching, comparison, and case- sensitivity.
IPP仕様がURIにおける少しの制限もしない理由は、RFC2396やHTTP/1.1の仕様[RFC2616]のようにIPPの実装が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.
また、System Administratorsと実装が、彼らの場合だけにおいて異なる異なったプリンタのためにURLを作成するのを避けるのも、お勧めです。 例えば、2異なったIPP PrintersとしてPrinter1とprinter1を持たないでください。
Example of equivalent URI's
同等なURIのものに関する例
http://abc.com:80/~smith/home.html
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
同等なURIのものがIPP体系を使用する例
ipp://abc.com:631/~smith/home.html
ipp://abc.com: 631/~鍛冶屋/home.html
Hastings, et al. Informational [Page 75] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [75ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
ipp://ABC.com/%7Esmith/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を比較することに関するその他の詳細を含んでいます。
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
4.1.4 xxxWithLanguageとxxxWithoutLanguageに、最大の長さ
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'
'言語'コンポーネントの長さは'textWithLanguage'の許容できる長さの'テキスト'か'nameWithLanguage'の'名前'の長さで効き目がありません。
4.2 Job Template Attributes
4.2 仕事のテンプレート属性
4.2.1 multiple-document-handling(type2 keyword)
4.2.1 複数のドキュメント処理(type2キーワード)
4.2.1.1 Support of multiple document jobs
4.2.1.1 複数のドキュメント仕事のサポート
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-仕事をサポートするなら実装が4つの効果のどれを実行するだろうかに関して静かですが、仕事単位で「複数のドキュメント処理」か複数のドキュメントを支えません。 複数のドキュメントが仕事であるとサポートする必要はなくてPrinterがCreate-仕事をサポートすることができるように、IPP/1.1を変えました。 Printerが、それが、複数のドキュメントが仕事であるとサポートするかどうかを示すように、「複数のドキュメント仕事でサポートしている」(論理演算子)プリンタ記述属性は'サーバ誤り複数のドキュメント仕事でサポートしていない'ステータスコードに伴うIPP/1.1に加えられました、Create-仕事の操作をサポートすると。 また、IPP/1.1ははっきりさせられました。Printerが複数の1仕事あたりのドキュメントを支えるなら、Printerは、少なくとも1がある「複数のドキュメント処理」(type2キーワード)仕事のTemplate属性が値であるとサポートしなければなりません。
4.3 Job Description Attributes
4.3 職務記述書属性
4.3.1 Getting the date and time of day
4.3.1 日付と時刻を得ること。
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
そして、「作成における日付の時間」、「処理における日付の時間」、「日付、完成されて、調節する、」 属性はdateTime構文として返されます。 これらの属性はサポートへのPrinterのためのOPTIONALです。 しかしながら、あります。
Hastings, et al. Informational [Page 76] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [76ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
various ways for a Printer to get the date and time of day. Some suggestions:
Printerが日付と時刻を得る様々な方法。 いくつかの提案:
1. A Printer can get time from an NTP timeserver if there's one
reachable on the network . See RFC 1305. Also DHCP option 32
in RFC 2132 returns the IP address of the NTP server.
1. ネットワークで届いている1つがあれば、PrinterはNTP日和見主義者から時間を得ることができます。RFC1305を見てください。 また、RFC2132のDHCPオプション32は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. オペレータにウェブの管理インタフェースを使用することで日時を決めさせてください。
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 "
4.4 Printer Description Attributes
4.4 プリンタ記述属性
4.4.1 queued-job-count (integer(0:MAX))
4.4.1 列に並ばせられた仕事のカウント(整数(0: 最大))
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
4.4.1.1 「列に並ばせられた仕事のカウント」RECOMMENDEDはなぜ(問題1.14)ですか?
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.
「列に並ばせられた仕事のカウント」がRECOMMENDEDであり、プリンタのリストの状態をまとめるとき待ち行列における、仕事の数を測定するためにGet-ジョブスをすることの代わりにそれがその属性だけへの何らかのクライアント一見である理由。 実際に列に並ばせられた仕事があるとき、「列に並ばせられた仕事のカウント」をサポートしない実装で、そのクライアントは0つの仕事を表示するでしょう。
We would have made it a REQUIRED Printer attribute, but some implementations had already been completed before the issue was raised, so making it a SHOULD was a compromise.
私たちがそれをREQUIRED Printer属性にしたでしょうが、問題が提起される前にいくつかの実装が既に完成したので、それをSHOULDにするのは、感染でした。
4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
(Issue 1.15)?
4.4.1.2 「列に並ばせられた仕事のカウント」はプリンタがどれくらい忙しいかに関する良い測定(問題1.15)ですか?
The "queued-job-count" is not a good measure of how busy the printer is when there are held jobs. A future registration could be to add a "held-job-count" (or an "active-job-count") Printer Description attribute if experience shows that such an attribute (combination) is needed to quickly indicate how busy a printer really is.
「列に並ばせられた仕事のカウント」は仕事が持たれているとき、プリンタがどれくらい忙しいかに関する良い測定ではありません。 今後の登録は経験が、そのような属性(組み合わせ)がプリンタが本当にどれくらい忙しいかをすばやく示すのに必要であることを示すなら「保持された仕事のカウント」(または、「活発な仕事のカウント」)プリンタ記述属性を加えることであるかもしれません。
Hastings, et al. Informational [Page 77] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [77ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
4.4.2 printer-current-time (dateTime)
4.4.2プリンタ電流時間(dateTime)
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:
Printer実装は、始動において次にいろいろな実装依存する手段で日時を得ることによって、この属性をサポートするかもしれません。 例は:
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. オペレータ使用からの管理ウェブページ
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[RFC1305]かDHCPオプション32[RFC2132]を使用して、それはNTPサーバのIPアドレスを返します。
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の日付と時間」Job記述属性が「プリンタ電流時間」を参照するので、また、それらはカバーされているでしょう。
4.4.3 Printer-uri
4.4.3 プリンタ-uri
Must the operational attribute for printer-uri match one of the values in "printer-uri-supported"?
プリンタ-uriのための操作上の属性は「uriが支えたプリンタ」で値の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.
寛大なプリンタ実装は操作を拒絶しないでしょう。 しかし、実装にはプリンタを拒絶する権利か仕事の操作が操作上の属性プリンタ-uriがuriが支えたプリンタの値でないならあります。 プリンタは不適切に構成されないかもしれません。 要求は明らかにプリンタに達しました。 プリンタはuriが支えたプリンタで価値の論理的な同等物としてプリンタ-uriを扱うかもしれません。 それは値、および関連安全保障政策が適用される実装扶養家族でしょう。 また、これはプリンタ-uriと仕事イド、または仕事-uriで指定された仕事のオブジェクトに適用されます。 セクション4.1.3を見て、どうURIのものを比較してくださいか。
Hastings, et al. Informational [Page 78] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [78ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
4.5 Empty Jobs
4.5 空のジョブス
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オブジェクト・モデルはドキュメントを全く含まない仕事を禁止しません。 ''それは、データを全く含んでいなくて、'最後のドキュメントを持っている'というドキュメントを加えている'旗が支えていて、aが付番するa'を含む方法の作成されたコネが雇用を創り出したなら仕事がそうするかもしれないそのようなものはセットしました。
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'.
空の仕事はちょうどいかなる他の仕事としても処理されます。 仕事が空であるので、空の仕事を「閉じる」操作は拒絶されません。 他の状態が全く存在していないなら示す、仕事が空である、操作への応答は成功を示すでしょう。 予定されて、処理された後に、仕事は、SHALLが'完成される'と述べます。
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
「仕事の理由を述べている」属性の値の何らかの変化があるでしょう。 必要であることで、仕事が空になって、存在することであるのを除いて、それがいいえなら「仕事の州の理由」SHALLインクルードを条件とさせるということです。
'completed-successfully'. If other conditions existed, the 'completed-with-warnings' or 'completed-with-errors' values may be used.
'-首尾よく完成されます'。 他の状態が存在したなら、'警告で完成した'か'誤りで完成した'値は使用されるかもしれません。
5 Directory Considerations
5 ディレクトリ問題
5.1 General Directory Schema Considerations
5.1 一般ディレクトリ図式問題
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object attributes for directory schemas. See [RFC2911] APPENDIX E: Generic Directory Schema.
[RFC2911]ドキュメントはディレクトリschemasのためにRECOMMENDEDとOPTIONAL Printerオブジェクト属性を記載します。 [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プリンタテンプレートは「Printerの抽象的なService Type v2.0"ドキュメント[svrloc-プリンタ]の定義」で定義されます。 LDAPプリンタテンプレートは「インターネット印刷は以下について議定書の中で述べ(IPP)」において定義されます。 「Printer ServicesのためのLDAP Schema」は[ldap-プリンタ]を記録します。 両方のドキュメントは系統的に他のディレクトリ属性と異なるようにプリンタディレクトリ属性を保つために既に「プリンタ」から始まらないどんな属性にも「プリンタ」を加えます。 また、「uriが支えたプリンタ」、「認証がサポートしたuri」、および「セキュリティがサポートしたuri」を使用することの代わりに、彼らは、ただ一つの属性に同じ情報のすべてを含むのに特別な構文がある「xriが支えたプリンタ」属性を使用します。
5.2 IPP Printer with a DNS name
5.2 DNS名があるIPP Printer
If the IPP printer has a DNS name should there be at least two values for the printer-uri-supported attribute. One URL with the fully qualified DNS name the other with the IP address in the URL?
IPPプリンタが、名前がそこでそうするべきであるDNSがuriが支えたプリンタ属性のための少なくとも2つの値であることを持っているなら。 IPがあるもう片方がURLで扱う完全に適切なDNS名がある1つのURL?
Hastings, et al. Informational [Page 79] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [79ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
The printer may contain one or the other or both. It's up to the administrator to configure this attribute.
プリンタは1、もう片方または両方を含むかもしれません。 この属性を構成するのは、管理者次第です。
6 Security Considerations
6 セキュリティ問題
The security considerations given in [RFC2911] Section 8 "Security Considerations" all apply to this document. In addition, the following sub-sections describes security consideration that have arisen as a result of implementation testing.
「セキュリティ問題」という[RFC2911]セクション8で与えられたセキュリティ問題はこのドキュメントにすべて適用されます。 さらに、以下の小区分は実装テストの結果、起こった警備上の配慮について説明します。
6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32)
6.1 他のジョブ依頼プロトコルを使用することで提出されたIPPとの仕事について質問すること。(問題1.32)
The following clarification was added to [RFC2911] section 8.5:
以下の明確化は[RFC2911]セクション8.5に追加されました:
8.5 Queries on jobs submitted using non-IPP protocols If the
device that an IPP Printer is representing is able to accept jobs
using other job submission protocols in addition to IPP, it is
RECOMMEND that such an implementation at least allow such
"foreign" jobs to be queried using Get-Jobs returning "job-id" and
"job-uri" as 'unknown'. Such an implementation NEED NOT support
all of the same IPP job attributes as for IPP jobs. The IPP
object returns the 'unknown' out-of-band value for any requested
attribute of a foreign job that is supported for IPP jobs, but not
for foreign jobs.
IPP Printerがデバイスですが、表しながら非IPPプロトコルIfを使用することで提出された仕事の8.5の質問がIPPに加えた他のジョブ依頼プロトコルを使用することで仕事を受け入れることができる、そのような実装が、そのような「外国」の仕事が質問されるのを'未知'のGet-ジョブスの戻っている「仕事イド」と「仕事-uri」を使用することで少なくとも許容するのは、RECOMMENDです。 そのような実装は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.
それが一層のRECOMMENDEDである、IPP Printerが「仕事イド」と「仕事-uri」を生成するのがそのようなもののために「外国仕事」を評価します、できれば、それらが他のIPP操作の目標であることができるように、Get-仕事属性やキャンセル仕事のように。 また、そのような実装は、そのような外国仕事の認証の問題に対処する必要があります。 1つのアプローチはIPPクライアントのユーザ以外のユーザに属すようなすべての外国仕事を扱うだろうことです。 別のアプローチは外国仕事が'匿名'に属するだろうことです。 IPPクライアントがIPP Printerオブジェクトのオペレータか管理者として認証された場合にだけ、外国仕事はIPP要求で質問されるかもしれませんか? あるいはまた、また、安全保障政策がユーザが他のユーザの仕事について質問するのを許容することであるなら、エンドユーザIPPクライアントにとって、外国仕事もGet仕事とGet-仕事属性を使用するのにおいて目に見えます。
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 MAY、仕事へのアクセスを提供する「普遍的な」プロトコルがどんなジョブ依頼プロトコルでも提出されたように、実装されてください。 IPPが広く実装されるようになるとき、より普遍的なアクセスを提供するのは理解できます。
Hastings, et al. Informational [Page 80] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [80ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
7 Encoding and Transport
7 コード化と輸送
This section discusses various aspects of IPP/1.1 Encoding and Transport [RFC2910].
このセクションはIPP/1.1EncodingとTransport[RFC2910]の種々相について論じます。
A server is not required to send a response until after it has received the client's entire request. Hence, a client must not expect a response until after it has sent the entire request. However, we recommend that the server return a response as soon as possible if an error is detected while the client is still sending the data, rather than waiting until all of the data is received. Therefore, we also recommend that a client listen for an error response that an IPP server MAY send before it receives all the data. In this case a client, if chunking the data, can send a premature zero-length chunk to end the request before sending all the data (and so the client can keep the connection open for other requests, rather than closing it). If the request is blocked for some reason, a client MAY determine the reason by opening another connection to query the server using Get-Printer-Attributes.
サーバは、クライアントの全体の要求を受け取った後まで応答を送るのに必要ではありません。 したがって、全体の要求を送った後までクライアントは応答を予想してはいけません。 しかしながら、私たちは、クライアントがデータのすべてが受け取られているまで待つよりまだむしろデータを送る間、誤りが検出されるならサーバができるだけ早く応答を返すことを勧めます。 したがって、また、私たちは、すべてのデータを受け取る前にクライアントがIPPサーバが送るかもしれない誤り応答の聞こうとすることを勧めます。 この場合分魂化であることでのクライアント、データ、すべてのデータを送る前に要求を終わらせるために時期尚早なゼロ・レングス塊を送ることができます(クライアントがそれを閉じるよりむしろ他の要求において開くように接続を保つことができるように)。 要求がある理由で妨げられるなら、クライアントは、Getプリンタ属性を使用することでサーバについて質問するために別の接続を開くことによって、理由を決定するかもしれません。
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to throttle clients when Printers are busy. Therefore, it is perfectly normal for an IPP client transmitting a Job to be blocked for a really long time. Accordingly, socket timeouts must be avoided. Some socket implementations have a timeout option, which specifies how long a write operation on a socket can be blocked before it times out and the blocking ends. A client should set this option for infinite timeout when transmitting Job submissions.
IPPは、Printersが忙しいときに、クライアントを阻止するのに、故意に、TCPの内蔵のフロー制御メカニズム[RFC793]を使用します。 したがって、Jobを伝えるIPPクライアントにとって、本当に長い時間妨げられるのは完全に正常です。 それに従って、ソケットタイムアウトを避けなければなりません。 いくつかのソケット実装には、タイムアウトオプションがあります。(それは、それの前に妨げられて、回のアウトとブロッキングが終わるという長いaが、ソケットにおける操作に書くことであることができるその方法を指定します)。 Job差出を伝えるとき、クライアントは無限のタイムアウトのためのこのオプションを設定するべきです。
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.
Jobトランスミッションが妨げられている間、いくつかのIPPクライアントアプリケーションが他の実質的な仕事を実行できるかもしれません。 例えば、クライアントには、それが同時に他のPrintersに伝えることができる他の仕事があるかもしれません。 クライアントはGUIを持っているかもしれません。(Jobトランスミッションが妨げられている間、GUIはユーザにとって敏感なままでなければなりません)。 これらのクライアントはマイペースでJobトランスミッションを扱うためにスレッドを生じさせるように設計されるべきです、主要出願を他の仕事をするのにおいて自由なままにして。 あるいはまた、シングルで糸を通されたアプリケーションは非ブロッキング入出力を使用するかもしれません。
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.
紙のジャムか不足などのいくつかのPrinter状態で、クライアントを無期限に妨げることができました。 クライアントは、Getプリンタ属性へのPrinterに追加接続を開いて、デバイスの状態を決心して、プリンタが止められるならユーザを警告して、仕事の送信を中止するかどうかユーザに決めさせるかもしれません。
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ヘッダのテーブルがあります。(HTTPヘッダはIPPクライアントかサーバにおける彼らの使用について説明します)。↓これはこれらのテーブルのそれぞれのコラムに関する説明です。
Hastings, et al. Informational [Page 81] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [81ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
- 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.
- 必須: クライアントかサーバがヘッダーを送らなければなりません--、-、:でなければならない 「値と状態」コラムで説明された条件が満たされるとき、クライアントかサーバがヘッダーを送らなければなりません--、:であるかもしれない クライアントかサーバがヘッダーを送るかもしれません--、: SHOULD NOTがヘッダーに送るクライアントかサーバ。 それは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.
- 必須: クライアントかサーバがヘッダーを支えなければなりません--、:であるかもしれない クライアントかサーバがヘッダーを支えるかもしれません--、: SHOULD NOTがヘッダーを支えるクライアントかサーバ。 それはIPP実装に関連していません。
Hastings, et al. Informational [Page 82] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [82ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
7.1 General Headers
7.1 一般ヘッダー
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
キャッシュはControl必須だけを「キャッシュしないではいけません」。
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.
必須必須必須が「閉じなければならない」接続専用。 ともにSHOULDがクライアントとサーバであるなら操作の系列の持続時間のための接続を保つなら。 クライアントとサーバはそのような系列で最後の操作のためのこのヘッダーを入れなければなりません。
Date may may must may per RFC 1123 [RFC1123]
from RFC 2616
[RFC2616]
日付がそうするかもしれない、必須はRFC2616からのRFC1123[RFC1123]単位でそうするかもしれません。[RFC2616]
Pragma must not must not "no-cache" only
どんな必須も「キャッシュしない」Pragma必須専用
Transfer- must- must must- must "chunked" only. Header
Encoding if if MUST be present if
Content-Length is
absent.
必須が「chunkedした」必須必須必須だけを移してください。 ヘッダーEncoding、Content-長さが欠けるなら、存在しなければならなくなってください。
Upgrade not not not not
アップグレード
Via not not not not
via
Hastings, et al. Informational [Page 83] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [83ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
7.2 Request Headers
7.2 要求ヘッダー
The following is a table for the request headers.
↓これは要求ヘッダーのためのテーブルです。
Request- Client Server Request Values and Conditions Header
クライアントサーバ要求値と状態ヘッダーを要求してください。
Accept may must "application/ipp" only. This
value is the default if the
client omits it
受け入れてください。必須「アプリケーション/ipp」だけ、がそうしてもよいです。 クライアントがそれを省略するなら、この値はデフォルトです。
Accept- not not Charset information is within the
Charset application/ipp entity
受け入れてください、Charsetアプリケーション/ippな実体の中にCharset情報があります。
Accept- may must empty and per RFC 2616 [RFC2616]
Encoding and IANA registry for content-
codings
受け入れてください、必須が、内容コーディングのために空になって、RFC2616[RFC2616]のコード化とIANA登録単位でそうしますように。
Accept- not not language information is within the
Language application/ipp entity
受け入れてください、Languageアプリケーション/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.
承認必須はRFC2616単位でそうしなければなりません。 401の「権限のない」応答を受けて、aを受けないとき、クライアントがこのヘッダーであるなら発信しなければならない、「プロキシ」 ヘッダーを認証してください。
From not not per RFC 2616. Because RFC
recommends sending this header
only with the user's approval,
it is not very useful
RFC2616 RFCが、ユーザの賛成だけがあるこのヘッダーを送ることを勧めるので、それはそれほど役に立ちません。
Host must must per RFC 2616
RFC2616あたりのホスト必須必須
If-Match not not
-合ってください。
If-Modified- not not
Since
--以来変更されたなら
If-None-Match not not
なにも合っていません。
If-Range not not
-及んでください。
If- not not
Unmodified-
Since
-、以来、変更されていない。
Hastings, et al. Informational [Page 84] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [84ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
RFC2616でないのあたりのプロキシ必須。 それが401の「権限のない」応答のときにaを受けるとき、クライアントはこのヘッダーであるならAuthorizatiを送らなければなりません、そして、aはヘッダーを「プロキシで認証します」。
Range not not
範囲
Referrer not not
リファラー
User-Agent not not
ユーザエージェント
Hastings, et al. Informational [Page 85] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [85ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
7.3 Response Headers
7.3 応答ヘッダー
The following is a table for the request headers.
↓これは要求ヘッダーのためのテーブルです。
Response- Server Client Response Values and Conditions Header
応答サーバクライアント応答値と状態ヘッダー
Accept-Ranges not not
範囲を受け入れます。
Age not not
時代
Location must- may per RFC 2616. When URI needs
if redirection.
位置必須はRFC2616単位でそうするかもしれません。 いつ、URIがリダイレクションであるなら必要であるか。
Proxy- must per RFC 2616
Authenticat
e not
プロキシはRFC2616Authenticat e単位でそうしなければなりません。
Public may may per RFC 2616
公衆がそうするかもしれない、RFC2616単位でそうするかもしれません。
Retry-After may may per RFC 2616
再試行した後がそうするかもしれない、RFC2616単位でそうするかもしれません。
Server not not
サーバ
Vary not not
異なる
Warning may may per RFC 2616
警告がそうするかもしれない、RFC2616単位でそうするかもしれません。
WWW- must- must per RFC 2616. When a server needs
Authenticate if to authenticate a client.
WWW必須はRFC2616単位でそうしなければなりません。 サーバがAuthenticateを必要とする、クライアントを認証するために。
Hastings, et al. Informational [Page 86] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [86ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
7.4 Entity Headers
7.4 実体ヘッダー
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.
内容はRFC2616あたりの必須必須必須と満足しているコーディングのためのEncoding IANA登録がそうするかもしれません。
Content- not not not not Application/ipp
Language handles language
内容Application/ipp Languageは言語を扱います。
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..
内容必須必須必須がそうしなければならない、Lengthの長さ、RFC2616単位でメッセージ本体です。 Transferコード化が休むなら、ヘッダーは出席しているに違いありません。
Content- not not not not
Location
内容位置
Content-MD5 may may may may per RFC 2616
内容-MD5がそうするかもしれない、RFC2616単位でそうするかもしれません。
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
最終更新日
Hastings, et al. Informational [Page 87] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [87ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
7.5 Optional support for HTTP/1.0
7.5 HTTP/1.0の任意のサポート
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サーバ層について言及します。 EncodingとTransportは、すべてのクライアントとすべてのサーバでHTTP1.1をサポートしなければならないのが必要であると[RFC2910]記録します。 しかしながら、クライアント、そして/または、サーバ実装は、また、HTTP1.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.
このオプションは、サーバが、HTTP1.0をサポートするだけである(非従うこと)のクライアントとコミュニケートするのを選ぶかもしれないことを意味します。 そのような場合サーバは、どんなHTTP1.1特有のパラメタや特徴も使用するべきでなくて、HTTPバージョンNo.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.
また、このオプションは、クライアントが、HTTP1.0をサポートするだけである(非従うこと)のサーバとコミュニケートするのを選ぶかもしれないことを意味します。 そのような場合、サーバがHTTP'サポートされないバージョン番号'で1.1が要求するHTTPに反応するなら、クライアントは、HTTPバージョンNo.1.0を使用することで再試行するべきです。
7.6 HTTP/1.1 Chunking
7.6 HTTP/1.1分魂化
7.6.1 Disabling IPP Server Response Chunking
7.6.1 IPPがサーバ応答分魂化であると無効にすること。
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サーバがそうするかもしれないと予期しなければならない、塊応答、応答でそれらを受け入れなければなりません。 しかしながら、chunked応答を受け入れることができない(非従うこと)のHTTPクライアントは、以下のHTTPヘッダを使用することによって操作への応答における分魂化を使用しないようにHTTP1.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.
サーバでこのメカニズムを使用して、分魂化からのクライアントに要求を無効にすることがないべきです、ドキュメントデータの分魂化がクライアントが長いドキュメントを送る重要な特徴であるので。
7.6.2 Warning About the Support of Chunked Requests
7.6.2 Chunked要求のサポートを警告すること。
This section describes some problems with the use of chunked requests and HTTP/1.1 servers.
このセクションはchunked要求とHTTP/1.1のサーバの使用に関するいくつかの問題について説明します。
The HTTP/1.1 standard [RFC2616] requires that conforming servers support chunked requests for any method. However, in spite of this requirement, some HTTP/1.1 implementations support chunked responses in the GET method, but do not support chunked POST method requests. Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or servlets [Servlet] require that the client supply a Content-Length. These implementations might reject a chunked POST method and return a
HTTP/1.1規格[RFC2616]は、サーバサポートを従わせるとどんなメソッドを求める要求もchunkedされたのを必要とします。 しかしながら、この要件にもかかわらず、何らかのHTTP/1.1実装サポートは、GETメソッドで応答をchunkedしましたが、chunkedポストメソッドが要求であるとサポートしません。 いくつかのHTTP/1.1の実装そのサポートCGIスクリプト[CGI]、そして/または、サーブレット[サーブレット]が、クライアントがContent-長さを供給するのを必要とします。 これらの実装は、chunkedポストメソッドを拒絶して、aを返すかもしれません。
Hastings, et al. Informational [Page 88] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [88ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
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.
状態がコード化して(長さのRequired)、要求と走行をバッファリングするのを試みるかもしれない411は、413ステータスコード(Entity Too Largeを要求する)を返しながら同居するか、または首尾よくchunked要求を受け入れるかもしれません。
Because of this lack of conformance of HTTP servers to the HTTP/1.1 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP Printer object implementation support chunked requests and that conforming clients accept chunked responses. Therefore, IPP object implementers are warned to seek HTTP server implementations that support chunked POST requests in order to conform to the IPP standard and/or use implementation techniques that support chunked POST requests.
HTTP/1.1規格へのHTTPサーバの順応のこの不足のために、従っているIPP Printerオブジェクト実装がサポートするIPPの標準の[RFC2910]REQUIRESは要求をchunkedしました、そして、クライアントが受け入れるその従うのは応答をchunkedしました。 したがって、IPPオブジェクトimplementersは、IPP規格に従う、そして/または、chunkedポストの要求をサポートする実装のテクニックを使用するためにHTTPサーバ実装を求めるために、そのサポートがポストの要求をchunkedしたと警告されます。
8 References
8つの参照箇所
[CGI] CGI/1.1 (http://www.w3.org/CGI/).
[CGI。]CGI/1.1( http://www.w3.org/CGI/ )
[IANA-CS] IANA Registry of Coded Character Sets:
http://www.iana.org/assignments/character-sets
[IANA-Cs] コード化文字集合のIANA登録: http://www.iana.org/assignments/character-sets
[ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald,
"Internet Printing Protocol (IPP): LDAP Schema for
Printer Services", Work in Progress.
[ldap-プリンタ] フレミング、P.、ジョーンズ、K.、ルイス、H.、およびI.マクドナルド、「インターネット印刷は(IPP)について議定書の中で述べます」。 「プリンタサービスのためのLDAP図式」、処理中の作業。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October, 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123、10月、1989
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119 , March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
and P. Powell, "Internet Printing Protocol/1.0:
Model and Semantics", RFC 2566, April 1999.
[RFC2565] DeBryとR.とヘイスティングズとT.とエリオとR.とイサクソンとS.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
Hastings, et al. Informational [Page 89] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [89ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
[RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[RFC2566] エリオとR.とバトラーとS.とムーアとP.とR.ターナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2567] ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model
and Protocol for the Internet Printing Protocol",
RFC 2568, April 1999.
[RFC2568]Zilles、S.、「インターネット印刷プロトコルのための構造、モデル、およびプロトコルのための原理」、RFC2568、1999年4月。
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J.
Martin, "Mapping between LPD and IPP Protocols",
RFC 2569, April 1999.
[RFC2569] エリオとR.とヘイスティングズとT.とジェイコブズとN.とJ.マーチン、「LPDとIPPプロトコルの間のマッピング」、RFC2569、1999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee,
"Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「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] エリオとR.とバトラーとS.とムーアとP.とR.ターナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2910、9月、2000
[RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
and P. Powell, "Internet Printing Protocol/1.0:
Model and Semantics", RFC 2911, September, 2000.
[RFC2911] DeBryとR.とヘイスティングズとT.とエリオとR.とイサクソンとS.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2911、9月、2000
[Servlet] Servlet Specification Version 2.1
(http://java.sun.com/products/servlet/2.1/
index.html).
[サーブレット]サーブレットSpecificationバージョン2.1( http://java.sun.com/products/servlet/2.1/ index.html)。
[svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I.,
"Definition of the Printer Abstract Service Type
v2.0", http://www.isi.edu/in-
notes/iana/assignments/svrloc-
templates/printer.2.0.en (IANA Registered, May 27,
2000).
[svrloc-プリンタ] サン・ピエール島、P.、イサクソン、S.、マクドナルド、I.、「Printerの抽象的なService Type v2.0"、 http://www.isi.edu/in- 注意/iana/課題/svrlocテンプレート/プリンタ.2.0.en(2000年5月27日のIANA Registered)の定義。」
[SSL] Netscape, The SSL Protocol, Version 3, (Text
version 3.02), November 1996.
[SSL]Netscape、SSLプロトコル、バージョン3、(テキストバージョン3.02)、1996年11月。
Hastings, et al. Informational [Page 90] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [90ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
9. Authors' Addresses
9. 作者のアドレス
Thomas N. Hastings Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
トーマスN.ヘイスティングズゼロックス社701の航空Blvd. エルセガンド、カリフォルニア 90245
EMail: hastings@cp10.es.xerox.com
メール: hastings@cp10.es.xerox.com
Carl-Uno Manros Independent Consultant 1601 N. Sepulveda Blvd. #505 Manhattan Beach, CA 90266
カール-宇野Manros独立しているコンサルタント1601N.セプルベダBlvd. #505 マンハッタンビーチ、カリフォルニア 90266
Email: carl@manros.com
メール: carl@manros.com
Carl Kugler Mail Stop 003G IBM Printing Systems Co 6300 Diagonal Hwy Boulder CO 80301
カールクーグラーメール停止003G IBM印刷システム共同6300の対角線のHwyボウルダーCO 80301
EMail: Kugler@us.ibm.com
メール: Kugler@us.ibm.com
Henrik Holst i-data Printing Systems Vadstrupvej 35-43 2880 Bagsvaerd, Denmark
Bagsvaerd、Henrikホルストi-データPrinting Systems Vadstrupvej35-43 2880デンマーク
EMail: hh@I-data.com
メール: hh@I-data.com
Peter Zehler Xerox Corporation 800 Philips Road Webster, NY 14580
ピーターZehlerゼロックス社800のフィリップスのRoadウェブスター、ニューヨーク 14580
EMail: PZehler@crt.xerox.com
メール: PZehler@crt.xerox.com
Hastings, et al. Informational [Page 91] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [91ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org
IPPウェブページ: http://www.pwg.org/ipp/ IPPメーリングリスト: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
ippメーリングリストに加入するには、以下のメールを送ってください:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end
1) 2が)3が)以下の2つの系列をメッセージ本体に入れる件名空白を出る majordomo@pwg.org にそれを送ってください: ippエンドを申し込んでください。
Implementers of this specification document are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list.
この仕様ドキュメントのImplementersが明確化問題のどんな議論と追加属性と値のための登録提案のレビューにも参加するためにIPP Mailing Listを接合するよう奨励されます。 メーリングリスト廃棄物が非加入者から郵送するスパムを減少させて、したがって、あなたは、質問やご意見をメーリングリストに送るためにメーリングリストに加入しなければなりません。
Other Participants:
他の関係者:
Chuck Adams - Tektronix Shivaun Albright - HP
チャック・アダムス--テクトロニクスのShivaunオルブライト--hp
Stefan Andersson - Axis Jeff Barnett - IBM
ステファン・アンデション--枢軸ジェフ・バーネット--IBM
Ron Bergman - Hitachi Koki Dennis Carney - IBM Imaging Systems
ロンバーグマン--日立工機のデニス・カーニー--IBMイメージシステム
Keith Carter - IBM Angelo Caruso - Xerox
キース・カーター--IBMのアンジェロのカルーソ--ゼロックス
Rajesh Chawla - TR Computing Nancy Chen - Okidata Solutions
ラジェッシュChawla--ナンシー・チェンを計算するTR--Okidataソリューション
Josh Cohen - Microsoft Jeff Copeland - QMS
ジョッシュ・コーエン--マイクロソフトのジェフ・コープランド--QMS
Andy Davidson - Tektronix Roger deBry - IBM
アンディ・ディヴィッドソン--テクトロニクスロジャーdeBry--IBM
Maulik Desai - Auco Mabry Dozier - QMS
Maulikデセイ--Aucoメイブリー・ドージア--QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh Systems
リー・ファレル--教会法情報Satoshi Fujitami--リコーシステム
Steve Gebert - IBM Sue Gleeson - Digital
スティーブ・ゲーベルト--IBMのスー・グリーソン--Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
チャールズ・ゴードン--Osicomブライアン・グリムショー--アップル
Jerry Hadsell - IBM Richard Hart - Digital
ジェリーHadsell--IBMのリチャード・ハート--Digital
Hastings, et al. Informational [Page 92] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [92ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Tom Hastings - Xerox Henrik Holst - I-data
トム・ヘイスティングズ--ゼロックスHenrikホルスト--I-データ
Stephen Holmstead Zhi-Hong Huang - Zenographics
スティーブン・Holmstead Zhi-Hongホアン--Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
スコット・イサクソン--ノベルBabek Jahromi--マイクロソフト
Swen Johnson - Xerox David Kellerman - Northlake
Software
Swenジョンソン--ゼロックスのデヴィッド・ケラーマン--Northlakeソフトウェア
Robert Kline - TrueSpectra Charles Kong - Panasonic
ロバート・クライン--TrueSpectraチャールズ・コン--パナソニック
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
カール・クーグラー--IBMデーヴKuntz--ヒューレット・パッカード
Takami Kurono - Brother Rick Landau - Digital
敬美Kurono--兄弟リック・ランドー--Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
スコット・ローレンス--Agranotシステムグレッグ・ルクレア--エプソン
Dwight Lewis - Lexmark Harry Lewis - IBM
ドワイト・ルイス--Lexmarkハリー・ルイス--IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
トニー・リャオ--生き生きとしたイメージロイLomicka--Digital
Pete Loya - HP Ray Lutz - Cognisys
ピートLoya--hpレイ・ルッツ--Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
マイク・マッケイ--ノベルInc.デヴィッドManchala--ゼロックス
Carl-Uno Manros - Xerox Jay Martin - Underscore
カール-宇野Manros--ゼロックスのジェイ・マーチン--強調
Stan McConnell - Xerox Larry Masinter - Xerox
スタン・マッコネール--ゼロックスラリーMasinter--ゼロックス
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
サンドラMatts--ヒューレットのパッカードのピーター・ミハウェック--Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
イラ・マクドナルド--高い北の株式会社マイクMoldovan--G3新星
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Tetsuya森田--リコーYuichi丹羽--リコー
Pat Nogay - IBM Ron Norton - Printronics
パットNogay--IBMロンノートン--Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
ユーゴー・パラ、ノベルボブの五旬節--ヒューレット・パッカード
Patrick Powell - Astart Jeff Rackowitz - Intermec Technologies
パトリック・パウエル--AstartジェフRackowitz--Intermec技術
Eric Random - Peerless Rob Rhoads - Intel
エリックRandom(無比のロブ・ローズ)のインテル
Xavier Riley - Xerox Gary Roberts - Ricoh
ザビエルライリー--ゼロックスのゲーリー・ロバーツ--リコー
David Roach - Unisys Stuart Rowley - Kyocera
デヴィッド・ローチ--ユニシスのスチュアート・ローリー--京セラ
Hastings, et al. Informational [Page 93] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [93ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
Yuji Sasaki - Japan Computer Richard Schneider - Epson Industry
Yuji佐々木--日本のコンピュータリチャード・シュナイダー--エプソン産業
Kris Schoff - HP Katsuaki Sekiguchi - Canon
クリスSchoff--hp Katsuaki Sekiguchi--キヤノン
Bob Setterbo - Adobe Gail Songer - Peerless
ボブSetterbo(AdobeゲイルSonger)無比です。
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
Hideki田中--教会法デボンテイラー--ノベルInc.
Mike Timperman - Lexmark Atsushi Uchino - Epson
マイクTimperman--Lexmark篤Uchino--エプソン
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
Shigeru上田--教会法ボブフォンAndel--急速なソフトウェア
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
ウィリアム・ワグナー--NetSilicon/dpiジム・ウォーカー--DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
クリスWellens--研究室のトレバー・ウェルズを織り込みます--ヒューレットパッカード
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
クレイグはノベルInc.を削ります(ロブが削る鋭い研究室)。
Jasper Wong - Xionics Don Wright - Lexmark
碧玉ウォン--Xionicsドン・ライト--Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
マイケル・ウー--ハイデルベルグのデジタルリックYardumian--ゼロックス
Michael Yeung - Toshiba Lloyd Young - Lexmark
マイケルYeung--東芝のロイド・ヤング--Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
ユキ・篤--京セラピーターZehler--ゼロックス
William Zhang- Canon Information Frank Zhao - Panasonic Systems
ウィリアム・チャン教会法情報フランク・チャオ--パナソニックシステム
Steve Zilles - Adobe Rob Zirnstein - Canon
Information Systems
スティーブZilles--AdobeロブZirnstein--教会法情報システム
10. Description of the Base IPP Documents
10. 基地のIPPドキュメントの記述
In addition to this document, the base set of IPP documents includes:
このドキュメントに加えたIPPドキュメントの基底集合は:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Mapping between LPD and IPP Protocols [RFC2569]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/1.1のためのプロトコルの目標を設計してください: モデルと意味論[RFC2911]インターネット印刷プロトコル/1.1: LPDとIPPの間でプロトコルを写像するコード化と輸送[RFC2910][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
「インターネット印刷プロトコルのデザイン目標」ドキュメントは分散印刷の機能性への広い一見を取ります、そして、それは必要がある特徴であることをはっきりさせるのを助ける現実のシナリオを列挙します。
Hastings, et al. Informational [Page 94] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [94ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910].
インターネットへの印刷プロトコルでは、含まれています。 それは3つのタイプのユーザのための要件を特定します: エンドユーザ、オペレータ、および管理者。 それはIPP/1.0[RFC2566、RFC2565]で満たされているエンドユーザ要件の部分集合を呼び出します。 いくつかのOPTIONALオペレータ操作がIPP/1.1[RFC2911、RFC2910]に加えられます。
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF IPP working group's major decisions.
「構造とモデルのための原理とインターネット印刷プロトコルのためのプロトコル」ドキュメントは、高い平らな視点からIPPについて説明して、IPP仕様ドキュメントのスイートを形成する様々なドキュメントのために道路地図を定義して、IETF IPPワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
「プロトコル/1.1に以下を印刷するインターネット」 「モデルとSemantics」というドキュメントは抽象的な物、それらの属性、および彼らの操作で簡易型のモデルについて説明します。 モデルはPrinterとJobを導入します。 Jobは複数の1Jobあたりのドキュメントを支えます。 また、モデルドキュメントはセキュリティ、国際化、およびディレクトリ問題がどう記述されるかを記述します。
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting a message body over HTTP whose Content-Type is "application/ipp". This document defines the 'ipp' scheme for identifying IPP printers and jobs.
「プロトコル/1.1に以下を印刷するインターネット」 「コード化とTransport」というドキュメントはモデルドキュメントでHTTP/1.1[RFC2616]と定義された抽象的な操作と属性の正式なマッピングです。 また、それはメディアタイプが「アプリケーション/ipp」と呼んだ新しいインターネットMIMEのために符号化規則を定義します。 また、このドキュメントは、コンテントタイプが「アプリケーション/ipp」であるHTTPの上でメッセージ本体を輸送するために規則を決めます。 このドキュメントはIPPプリンタと仕事を特定することの'ipp'計画を定義します。
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
「LPDとIPPの間でプロトコルを写像します」ドキュメントはIPPとLPD(線Printer Daemon)実現の間で何らかのアドバイスをゲートウェイのimplementersに与えます。
Hastings, et al. Informational [Page 95] RFC 3196 Internet Printing Protocol/1.1 November 2001
ヘイスティングズ、他 [95ページ]情報のRFC3196インターネット印刷プロトコル/2001年11月1.1日
11 Full Copyright Statement
11 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hastings, et al. Informational [Page 96]
ヘイスティングズ、他 情報[96ページ]
一覧
スポンサーリンク
