RFC2639 日本語訳
2639 Internet Printing Protocol/1.0: Implementer's Guide. T. Hastings,C. Manros. July 1999. (Format: TXT=145086 bytes) (Obsoleted by RFC3196) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hastings
Request for Comments: 2639 C. Manros
Category: Informational Xerox Corporation
July 1999
コメントを求めるワーキンググループT.ヘイスティングズの要求をネットワークでつないでください: 2639年のC.Manrosカテゴリ: 情報のゼロックス社の1999年7月
Internet Printing Protocol/1.0: Implementer's Guide
インターネット印刷プロトコル/1.0: Implementerのガイド
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
このドキュメントは1セットのドキュメントの1つであり、どれが新しいインターネットPrintingプロトコル(IPP)の全面について一緒に説明しますか? IPPは分配された印刷にインターネット・ツールと技術を使用することで使用できるアプリケーションレベルプロトコルです。 このドキュメントは補足のIPP Model、Semantics[RFC2566]、IPP Transport、およびEncoding[RFC2565]が記録する情報を含んでいます。 implementersが彼らのクライアント、そして/または、IPPオブジェクト実装のデザインにそれらを助けるかもしれない問題のIPP/1.0といくつかを理解しているのを助けるのは意図しています。 例えば、誤りを含んでいるのがチェックして、処理要求の典型的な注文を与えます。 また、仕様決定のいくつかに関する動機は含まれています。
The full set of IPP documents includes:
IPPドキュメントのフルセットは:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Mapping between LPD and IPP Protocols [RFC2569]
構造とモデルのためのインターネット印刷プロトコル[RFC2567]原理とインターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/1.0のためのプロトコルの目標を設計してください: モデルと意味論[RFC2566]インターネット印刷プロトコル/1.0: LPDとIPPの間でプロトコルを写像するコード化と輸送[RFC2565][RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and
「インターネット印刷プロトコルのデザイン目標」というドキュメントは分散印刷の機能性への広い一見を取ります、そして、それは印刷プロトコルに含まれる必要がある特徴をインターネットにはっきりさせるのを助ける現実のシナリオを列挙します。 それは3つのタイプのユーザのための要件を特定します: そしてエンドユーザ、オペレータ。
Hastings & Manros Informational [Page 1] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[1ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
管理者。 デザイン目標ドキュメントはIPP/1.0で満たされているエンドユーザ要件の部分集合を呼び出します。 バージョン1.0のための範囲の外にオペレータと管理者要件があります。
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.
「構造とモデルのための原理とインターネット印刷プロトコルのためのプロトコル」というドキュメントは、高い平らな視点からIPPについて説明して、IPP仕様のスイートを形成する様々なドキュメントのために道路地図を定義して、IETFワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
ドキュメント、「プロトコル/1.0に以下を印刷するインターネット」 「モデルとSemantics」と、簡易型のモデルは抽象的なオブジェクト、それらの属性、および彼らの操作で説明します。 モデルはPrinterとJobを導入します。 Jobは複数の1Jobあたりのドキュメントを支えます。 また、モデルドキュメントはセキュリティ、国際化、およびディレクトリ問題がどう扱われるかを扱います。
The document, "Internet Printing Protocol/1.0: Encoding and Transport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called "application/ipp".
ドキュメント、「プロトコル/1.0に以下を印刷するインターネット」 「コード化とTransport」はモデルドキュメントでHTTP/1.1と定義された抽象的な操作と属性の正式なマッピングです。 また、それはメディアタイプが「アプリケーション/ipp」と呼んだ新しいインターネットと符号化規則を定義します。
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
「LPDとIPPの間でプロトコルを写像し」て、ドキュメントはIPPとLPD(線Printer Daemon)実装の間で何らかのアドバイスをゲートウェイのimplementersに与えます。
Table of Contents
目次
1 Introduction......................................................4
1.1 Conformance language............................................4
1.2 Other terminology...............................................5
2 Model and Semantics...............................................5
2.1 Summary of Operation Attributes.................................5
2.2 Suggested Operation Processing Steps for IPP Objects ..........10
2.2.1 Suggested Operation Processing Steps for all Operations..11
2.2.1.1 Validate version number...............................11
2.2.1.2 Validate operation identifier.........................11
2.2.1.3 Validate the request identifier.......................11
2.2.1.4 Validate attribute group and attribute presence and
order.................................................12
2.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................19
2.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................23
2.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents.....................26
2.2.2.1 Default "ipp-attribute-fidelity" if not supplied......26
1つの序論…4 1.1 順応言語…4 他の1.2用語…5 2モデルと意味論…5 操作属性の2.1概要…5 2.2はIPPオブジェクトのための操作処理ステップを示しました…10 2.2 .1はすべてのOperationsのためにOperation Processing Stepsを示しました。11 2.2 .1 .1 バージョン番号を有効にしてください…11 2.2 .1 .2 操作識別子を有効にしてください…11 2.2 .1 .3 要求識別子を有効にしてください…11 2.2 .1 .4 属性グループ、属性存在、および注文を有効にしてください…12 2.2 .1 .5 REQUIRED Operation属性の値を有効にしてください…19 2.2 .1 .6 OPTIONAL Operation属性の値を有効にしてください…2.2に、.2はOperationsのためにAdditional Processing Stepsを示しました。23、そのCreate/はジョブスとAdd Documentsを有効にします…26 2.2 .2 .1 デフォルト「ipp属性信義」か供給される…26
Hastings & Manros Informational [Page 2] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[2ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.2.2.2 Check that the Printer object is accepting jobs.......26
2.2.2.3 Validate the values of the Job Template attributes....26
2.2.3 Algorithm for job validation...............................27
2.2.3.1 Check for conflicting Job Template attributes values..33
2.2.3.2 Decide whether to REJECT the request..................33
2.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes..................................34
2.2.3.4 Create the Job object with attributes to support......34
2.2.3.5 Return one of the success status codes................36
2.2.3.6 Accept appended Document Content......................36
2.2.3.7 Scheduling and Starting to Process the Job............36
2.2.3.8 Completing the Job....................................37
2.2.3.9 Destroying the Job after completion...................37
2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
2.3 Status codes returned by operation ............................37
2.3.1 Printer Operations.........................................38
2.3.1.1 Print-Job.............................................38
2.3.1.2 Print-URI.............................................40
2.3.1.3 Validate-Job..........................................40
2.3.1.4 Create-Job............................................41
2.3.1.5 Get-Printer-Attributes................................41
2.3.1.6 Get-Jobs..............................................42
2.3.2 Job Operations.............................................43
2.3.2.1 Send-Document.........................................43
2.3.2.2 Send-URI..............................................44
2.3.2.3 Cancel-Job............................................44
2.3.2.4 Get-Job-Attributes....................................45
2.4 Validate-Job...................................................46
2.5 Case Sensitivity in URIs ......................................46
2.6 Character Sets, natural languages, and internationalization....46
2.6.1 Character set code conversion support .....................46
2.6.2 What charset to return when an unsupported charset is
requested?.................................................48
2.6.3 Natural Language Override (NLO) ...........................48
2.7 The "queued-job-count" Printer Description attribute...........50
2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
2.7.2 Is "queued-job-count" a good measure of how busy a printer
is?........................................................50
2.8 Sending empty attribute groups ................................50
2.9 Returning unsupported attributes in Get-Xxxx responses ........51
2.10 Returning job-state in Print-Job response ....................51
2.11 Flow controlling the data portion of a Print-Job request .....52
2.12 Multi-valued attributes ......................................53
2.13 Querying jobs with IPP that were submitted using other job
submission protocols .........................................53
2.14 The 'none' value for empty sets ..............................54
2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
2.2.2.2 Printerオブジェクトが仕事を受け入れているのをチェックしてください…26 2.2 .2 .3 Job Template属性の値を有効にしてください…26 2.2 仕事の合法化のための.3アルゴリズム…27 2.2 .3 .1は闘争しているJob Template属性値がないかどうかチェックします。33 2.2 .2が決める.3、REJECTへの要求…33 2.2 .3 .3 Validate-仕事の操作、成功ステータスコードのRETURN1のために…34 2.2 .3 .4 サポートする属性があるJobオブジェクトを作成してください…34 2.2 .3 .5 成功ステータスコードの1つを返してください…36 2.2 .3 .6 追加されたDocument Contentを受け入れてください…36 2.2 .3 .7 仕事を処理し始めます計画をして、…36 2.2 .3 .8 仕事を完了します…37 2.2 .3 .9 完成の後にJobを破壊します…37 2.2 .3 「ipp属性信義」との.10相互作用…37 2.3 操作で状態コードは戻りました…37 2.3 .1 プリンタ操作…38 2.3 .1 .1印刷仕事…38 2.3 .1 .2印刷URI…40 2.3 .1 .3 仕事を有効にします…40 2.3 .1 .4 雇用を創り出します…41 2.3 .1 .5 プリンタ属性を得てください…41 2.3 .1 .6 ジョブスを得ます…42 2.3 .2 仕事の操作…43 2.3 .2 .1 ドキュメントを発信させます…43 2.3 .2 .2 URIを発信させます…44 2.3 .2 .3キャンセル仕事…44 2.3 .2 .4 仕事の属性を得てください…45 2.4 仕事を有効にします…46 2.5 URIにおける感度をケースに入れてください…46 2.6回の文字コード、自然言語、および国際化…46 2.6 .1 文字集合コード変換サポート…46 2.6 .2 サポートされないcharsetが要求されているとき戻るどんなcharset?48 2.6 .3 自然言語オーバーライド(NLO)…48 2.7 「列に並ばせられた仕事のカウント」Printer記述属性…50 2.7 .1 「列に並ばせられた仕事のカウント」はなぜRECOMMENDEDですか?50 2.7 .2 「列に並ばせられた仕事のカウント」はプリンタがどれくらい忙しいかに関する良い測定ですか?50 2.8の送付の空の属性は分類されます…50 2.9 Get-Xxxx応答におけるサポートされない属性を返します…51 2.10 Print-仕事の応答で仕事状態を返します…51 2.11 Print-仕事の要求のデータ部を制御して、流れてください…52 2.12のマルチ評価された属性…53 2.13 IPPとの仕事について質問して、他のジョブ依頼プロトコルを使用することでそれを提出しました…53 2.14 空集合のための'なにも'値…54 2.15 ジョブスを得る、私、-仕事は'本当'、そして、および'要求しているユーザ名'と等しいです--…54
Hastings & Manros Informational [Page 3] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[3ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.16 The "multiple-document-handling" Job Template attribute and
support of multiple document jobs.............................54
3 Encoding and Transport...........................................55
3.1 General Headers................................................56
3.2 Request Headers...............................................57
3.3 Response Headers...............................................58
3.4 Entity Headers................................................59
3.5 Optional support for HTTP/1.0..................................60
3.6 HTTP/1.1 Chunking..............................................60
3.6.1 Disabling IPP Server Response Chunking.....................60
3.6.2 Warning About the Support of Chunked Requests..............60
4 References.......................................................61
4.1 Authors' Addresses.............................................62
5 Security Considerations..........................................62
6 Notices..........................................................62
Full Copyright Statement............................................65
2.16 倍数の「複数のドキュメント処理」Job Template属性とサポートは仕事を記録します…54 3 コード化と輸送…55 3.1個の一般ヘッダー…56 3.2 ヘッダーを要求してください…57 3.3 応答ヘッダー…58 3.4 実体ヘッダー…59 3.5 HTTP/1.0の任意のサポート…60 3.6 HTTP/1.1分魂化…60 3.6 .1 IPPがサーバ応答分魂化であると無効にします…60 3.6 .2 Chunked要求のサポートを警告します…60 4つの参照箇所…61 4.1人の作者のアドレス…62 5 セキュリティ問題…62 6 気付きます…62 完全な著作権宣言文…65
1 Introduction
1つの序論
This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. As such this information is not part of the formal specifications. Instead information is presented to help implementers understand the specification, including some of the motivation for decisions taken by the committee in developing the specification. Some of the implementation considerations are intended to help implementers design their client and/or IPP object implementations. If there are any contradictions between this document and [RFC2566] or [RFC2565], those documents take precedence over this document.
このドキュメントは補足のIPP Model、Semantics[RFC2566]、IPP Transport、およびEncoding[RFC2565]が記録する情報を含んでいます。 そういうものとして、この情報は形式仕様の一部ではありません。 代わりに、情報はimplementersが仕様を理解しているのを助けるために提示されます、仕様を開発する際に委員会によって取られた決定に関する何らかの動機を含んでいて。 実装問題のいくつかが、implementersが彼らのクライアント、そして/または、IPPオブジェクト実装を設計するのを助けることを意図します。 このドキュメントと[RFC2566]か[RFC2565]の間には、何か矛盾があれば、それらのドキュメントはこのドキュメントの上に優先します。
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 [RFC2566] and [RFC2565] documents require and allow, rather than specifying additional conformance requirements. These terms are defined in section 13 on conformance terminology in [RFC2566], most of which is taken from RFC 2119 [RFC2119].
通常、このドキュメントが用語を含んでいない、NOT、5月はNOT、SHOULD、SHOULD NOT、REQUIRED、およびOPTIONALを必要としなければなりませんか? しかしながら、彼らの意図はそれらの用語が本書では現れると、追加順応要件を指定するよりむしろ、[RFC2566]と[RFC2565]ドキュメントが必要であり、許容することを繰り返すことです。 これらの用語はそれの大部分がRFC2119[RFC2119]から取られる[RFC2566]の順応用語のセクション13で定義されます。
Implementers should read section 13 in [RFC2566] in order to understand these capitalized words. The words MUST, MUST NOT, and REQUIRED indicate what implementations are required to support in a client or IPP object in order to be conformant to [RFC2566] and [RFC2565]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed as an implementer option. The verbs SHOULD and SHOULD NOT indicate suggested behavior, but which is not required or disallowed, respectively, in order to conform to the specification.
Implementersは、これらが単語を大文字で書いたのを理解するために[RFC2566]のセクション13を読むはずです。 単語はそうしなければなりません、とNOT、およびREQUIREDは示さなければなりません。実装が[RFC2566]と[RFC2565]へのconformantになるようにクライアントかIPPオブジェクトでサポートするのに必要である何。 NOTを必要として、あった、OPTIONALが、示すimplementerオプションとして単に許容されるかもしれません。 SHOULDとSHOULD NOTが示す動詞が振舞いを示しましたが、どれが、仕様に従うためにそれぞれ必要ではありませんかそれとも、または禁じられませんか?
Hastings & Manros Informational [Page 4] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[4ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
1.2 Other terminology
1.2 他の用語
The term "sender" refers to the client that sends a request or an IPP object that returns a response. The term "receiver" refers to the IPP object that receives a request and to a client that receives a response.
「送付者」という用語は要求を送るクライアントか応答を返すIPPオブジェクトについて言及します。 「受信機」という用語は要求を受け取るIPPオブジェクトを呼びます、そして、クライアントに、それは応答を受けます。
2 Model and Semantics
2モデルと意味論
This section discusses various aspects of IPP/1.0 Model and Semantics [RFC2566].
このセクションはIPP/1.0ModelとSemantics[RFC2566]の種々相について論じます。
2.1 Summary of Operation Attributes
2.1 操作属性の概要
Legend for the following table:
以下のテーブルのための伝説:
R indicates a REQUIRED operation or attribute for an
implementation to support
Rは実装がサポートするREQUIRED操作か属性を必要とします。
O indicates an OPTIONAL operation or attribute for an
implementation to support
Oは実装がサポートするOPTIONAL操作か属性を必要とします。
Hastings & Manros Informational [Page 5] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[5ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Table 1. Summary of operation attributes for Printer operations
1を見送ってください。 Printer操作のための操作属性の概要
Printer Operations
プリンタ操作
Requests Responses
応答を要求します。
Operation Print- Pri Crea Get- Get- All
Attributes Job, nt- te- Printer- Jobs Opera-
Validate URI Job Attribut tions
-Job (O) (O) es
操作Print- PriクレアGetはすべてのAttributes Jobを手に入れて、nt Teプリンタ仕事のOperaは(O) URI Job Attribut tions仕事(O)のesを有効にします。
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- R R R R R R
natural-language
属性R R R R R R、自然言語
document-uri R
ドキュメント-uri R
job-id*
仕事イド*
job-uri*
仕事uri*
last-document
最後のドキュメント
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 R R R
ジョブ名R R R
requesting-user- R R R R R
name
要求しているユーザのR RのR R R名
Hastings & Manros Informational [Page 6] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[6ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Printer Operations
プリンタ操作
Requests Responses
応答を要求します。
Operation Print- Pri Crea Get- Get- All
Attributes Job, nt- te- Printer Jobs Opera-
Vali- URI Job Attri- tions
date-Job (O) (O) butes
操作Print- PriクレアGetすべてのAttributes Job、nt TeプリンタジョブスOperaバーリURI Job Attri- tions日付仕事の(O)(O)butesを手に入れてください。
Operation attributes-OPTIONAL to be supplied by the sender
送付者によって供給されるべき操作属性-OPTIONAL
status-message O
ステータスメッセージO
compression O O
圧縮O O
document-format R R O
ドキュメント・フォーマットR R O
document-name O O
ドキュメント名のO O
document-natural- O O
language
ドキュメント当然のO Oの言語
ipp-attribute- R R R
fidelity
ipp 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
limit R
限界R
message
メッセージ
my-jobs R
私、-、仕事、R
requested- R R
attributes
要求されたR R属性
which-jobs R
どれ、-、仕事、R
* "job-id" is REQUIRED only if used together with
"printer-uri" to identify the target job; otherwise, "job-
uri" is REQUIRED.
* 目標仕事を特定するのに「プリンタ-uri」と共に使用される場合にだけ、「仕事イド」はREQUIREDです。 さもなければ、「仕事のuri」はREQUIREDです。
Hastings & Manros Informational [Page 7] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[7ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Table 2. Summary of operation attributes for Job operations
2を見送ってください。 Job操作のための操作属性の概要
Requests Responses
応答を要求します。
Operation Send- Send- Cancel Get- All
Attributes Document URI -Job Job- Opera-
(O) (O) Attri- tions
butes
操作SendはすべてのAttributes Document URI仕事Jobのオペラ(O)(O)Attri- tions butesをキャンセルGetに送ります。
Operation parameters--REQUIRED to be supplied by the sender
運転パラメータ--送付者によって供給されるべきREQUIRED
operation-id R R R R
操作イドR R R R
status-code R
ステータスコードR
request-id R R R R R
要求イドR R R R R
version-number R R R R R
バージョン番号R R R R R
Operation attributes-REQUIRED to be supplied by the sender
送付者によって供給されるべき操作属性-REQUIRED
attributes- R R R R R
charset
属性R R R R R charset
attributes- R R R R R
natural-language
属性R R R R R、自然言語
document-uri R
ドキュメント-uri R
job-id* R R R R
賃仕事のイド*R RのR R
job-uri* R R R R
仕事のuriな*R R R R
last-document R R
最後のドキュメントR R
printer-uri R R R R
プリンタ-uri R R R R
Operation attributes-RECOMMENDED to be supplied by the
sender
送付者によって供給されるべき操作属性-RECOMMENDED
job-name
ジョブ名
requesting-user- R R R R
name
要求しているユーザのR RのR R名
Hastings & Manros Informational [Page 8] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[8ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Job Operations
仕事の操作
Requests Responses
応答を要求します。
Operation Attributes Send- Send- Cance Get- All
Document URI l-Job Job- Opera-
(O) (O) Attri- tions
butes
操作Attributes SendはすべてのDocument URI l-仕事のJobオペラ(O)(O)Attri- tions butesをCance Getに送ります。
Operation attributes.OPTIONAL to be supplied by the sender
送付者によって供給されるべき操作attributes.OPTIONAL
status-message O
ステータスメッセージO
compression O O
圧縮O O
document-format R R
ドキュメント・フォーマットR R
document-name O O
ドキュメント名のO O
document-natural- O O
language
ドキュメント当然のO Oの言語
ipp-attribute-
fidelity
ipp-属性信義
job-impressions
仕事印象
job-k-octets
仕事のk八重奏
job-media-sheets
仕事のメディアシート
limit
限界
message O
メッセージO
my-jobs
私、-、仕事
requested-attributes R
要求された属性R
which-jobs
どれ、-、仕事
* "job-id" is REQUIRED only if used together with "printer-
uri" to identify the target job; otherwise, "job-uri" is
REQUIRED.
* 目標仕事を特定するのに「プリンタuri」と共に使用される場合にだけ、「仕事イド」はREQUIREDです。 さもなければ、「仕事-uri」はREQUIREDです。
Hastings & Manros Informational [Page 9] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[9ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.2 Suggested Operation Processing Steps for IPP Objects
2.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 implementations MAY choose to be more forgiving than the error checks shown here, in order to be able to accept requests from non- conforming clients. Not performing all of these error checks is a so-called "forgiving" implementation. On the other hand, clients that successfully submit requests to IPP objects that do perform all the error checks will be more likely to be able to interoperate with other IPP object implementations. Thus an implementer of an IPP object needs to decide whether to be a "forgiving" or a "strict" implementation. Therefore, the error status codes returned may differ between implementations. Consequentially, client SHOULD NOT expect exactly the error code processing described in this section.
このセクションは要求を処理して、応答を返すときIPPオブジェクトが実行するかもしれないステップとエラーチェックを示します。 IPPオブジェクトはエラーチェックのいくつかかすべてを実行するかもしれません。 しかしながら、いくつかの実装が、ここに示されたエラーチェックより寛大であることを選ぶかもしれません、非従っているクライアントから要求を受け入れることができるように。 これらのエラーチェックのすべてを実行しないのは、いわゆる「寛大な」実装です。 他方では、首尾よくすべてのエラーチェックを実行するIPPオブジェクトに要求を提出するクライアントは他のIPPオブジェクト実装で、より共同利用できそうでしょう。 したがって、IPPオブジェクトの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.
それはそのセキュリティ認証であると思われます、そして、承認は下層で既に行われました。
Hastings & Manros Informational [Page 10] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[10ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.2.1 Suggested Operation Processing Steps for all Operations
2.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操作を含んでいて、ドキュメントを加えて、仕事を有効にします。
2.2.1.1 Validate version number
2.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 remains in a fixed position across all future versions so that all clients and IPP object that support future versions can determine which version is being used. The IPP object checks to see if the major version number supplied in the request is supported. If not, the Printer object REJECTS the request and RETURNS the 'server- error-version-not-supported' status code in the response. The IPP object returns in the "version-number" response attribute the major and minor version for the error response. Thus the client can learn at least one major and minor version that the IPP object supports. The IPP object is encouraged to return the closest version number to the one supplied by the client.
あらゆる要求とあらゆる応答が「バージョン番号」属性を含んでいます。 この属性の値はクライアントとIPPがそれぞれ使用しているのを反対させる構文と意味論の主要で小さい方のバージョン番号です。 「バージョン番号」属性は、将来のバージョンをサポートするすべてのクライアントとIPP目的が、どのバージョンが使用されているかを決心できるように、すべての将来のバージョンの向こう側に固定位置に留まっています。 IPPオブジェクトは、要求で供給されたメジャーバージョン番号がサポートされるかどうか確認するためにチェックします。 まして、Printerは反対します。要求と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 requested minor version is not supported (the requested minor version is either higher or lower) than a supported minor version, the IPP object SHOULD return the closest supported minor version.
マイナーバージョン番号の照合が実装に依存している、しかしながら、クライアントの供給された小さい方のバージョンが明らかにサポートされるなら、その同じマイナーバージョン番号を使用して、IPPオブジェクトは応じなければなりません。 要求された小さい方のバージョンがサポートしている小さい方のバージョンほどサポートされないなら(要求された小さい方のバージョンは、より高いか、または低いです)、SHOULDが最も近くに返すIPPオブジェクトは小さい方のバージョンをサポートしました。
2.2.1.2 Validate operation identifier
2.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、'サーバ誤り操作でサポートしていない'状態が応答でコード化する要求とリターン。
2.2.1.3 Validate the request identifier
2.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ビット。
Hastings & Manros Informational [Page 11] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[11ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Note: The "version-number", "operation-id", and the "request-id" parameters are in fixed octet positions in the IPP/1.0 encoding. The "version-number" parameter will be the same fixed octet position in all versions of the protocol. These fields are validated before proceeding with the rest of the validation.
以下に注意してください。 「バージョン番号」、「操作イド」、および「要求イド」パラメタがIPP/1.0コード化における固定八重奏位置にあります。 「バージョン番号」パラメタはプロトコルのすべてのバージョンで同じ固定八重奏位置になるでしょう。 合法化の残りを続ける前に、これらの分野は有効にされます。
2.2.1.4 Validate attribute group and attribute presence and order
2.2.1.4 属性グループ、属性存在、および注文を有効にしてください。
The order of the following validation steps depends on implementation.
以下の合法化ステップの注文は実装によります。
2.2.1.4.1 Validate the presence and order of attribute groups
2.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 in error in either the Unsupported Attributes group or the Status Message. Also, the IPP object NEED NOT find all attribute group errors before returning this error.
この種類の属性グループ誤りが顧客でというよりむしろクライアント開発者によって検出された誤りである最も傾向があるので、IPPオブジェクトはどの属性グループがUnsupported AttributesグループかStatus Messageのどちらかで間違っていたかのしるしを返す必要はありません。 IPPも、戻る前のすべての属性グループ誤りがこの誤りであることがわかる必要はないのを反対します。
2.2.1.4.2 Ignore unknown attribute groups in the expected position
2.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
将来の属性グループはDocument Contentのすぐ前での要求の終わりと応答の終わりの仕様に追加されるかもしれません、Get-ジョブス応答を除いて、どこ、それ、そこか属性が返した最初の仕事の前にそうかもしれない。 IPP目的がこれらの位置に未知の属性グループを受け取るなら、誤りを返すよりむしろ全体のグループを無視します、そのグループが無視できるプロトコルの後の小さい方のバージョンの新しいグループであるかもしれないので。 (クライアントを混乱させないで新しい属性グループを無視できないなら、メジャーバージョン番号は増やされたでしょう。
Hastings & Manros Informational [Page 12] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[12ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
protocol document and in the request). If the unknown group occurs in a different position, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code.
ドキュメントと要求におけるプロトコル) 未知のグループが異なった位置に起こって、IPPオブジェクト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オブジェクトで複数のベンダーから他のベンダーからそのようなクライアントを使用できるという可能性を増強する適切なフォームを使用します。
2.2.1.4.3 Validate the presence of a single occurrence of required
Operation attributes
2.2.1.4.3 必要なOperation属性のただ一つの発生の存在を有効にしてください。
Client requests and IPP object responses contain Operation attributes that [RFC2566] Section 3 requires to be present. Attributes within a group may be in any order, except for the ordering of target, charset, and natural languages attributes. These attributes MUST be first, and MUST be supplied in the following order: charset, natural language, and then target. An IPP object verifies that the attributes that Section 4 requires to be supplied by the client have been supplied in the request (attributes without an * in the following tables). An asterisk (*) indicates groups and Operation attributes that the client may omit in a request or an IPP object may omit in a response.
クライアント要求とIPPオブジェクト応答は[RFC2566]セクション3が存在しているのを必要とする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です。 可能な実装のいくつかは以下の通りです。
1.REJECTS the request and RETURNS the 'client-error-bad-request'
status code
1. 要求とRETURNS'クライアントの誤りの悪い要求'状態がコード化するREJECTS
2.accepts the request and uses the first occurrence of the
attribute no matter where it is
2.、要請を受け入れて、それがどこにあっても、属性の最初の発生を使用します。
3.accepts the request and uses the last occurrence of the
attribute no matter where it is
3.、要請を受け入れて、それがどこにあっても、属性の最後の発生を使用します。
4.accept the request and assume some default value for the missing
attribute
4. 要請を受け入れてください、そして、なくなった属性のために何らかのデフォルトが値であると仮定してください。
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
したがって、要求を従わせて、すべてのIPPオブジェクト実装から同じ振舞いを受けたいなら、クライアントは発信しなければなりません。 例えば、それは「属性-charset」か「属性自然言語」属性がどんな操作要求でも省略されるか、またはOperation属性がJob Templateグループで供給される誤りです。
Hastings & Manros Informational [Page 13] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[13ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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.
または、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 [RFC2566] Section 3. The order of the attributes within a group is arbitrary, except as noted for some of the special operation attributes (charset, natural language, and target). The tables below use the following notation:
以下のテーブルは各要求と各応答における属性グループによるすべての操作のためにすべての属性を記載します。 グループの注文はクライアントが[RFC2566]セクション3の指定されるとしてのグループを供給するオーダーです。 グループの中の属性の注文は任意です、特殊作戦属性(charset、自然言語、および目標)のいくつかで有名であるのを除いて。 以下のテーブルは以下の記法を使用します:
R indicates a REQUIRED attribute that an IPP object MUST support
O indicates an OPTIONAL attribute that an IPP object NEED NOT
support
* indicates that a client MAY omit the attribute in a request
and that an IPP object MAY omit the attribute in a
response. The absence of an * means that a client MUST
supply the attribute in a request and an IPP object MUST
supply the attribute in a response.
Rは、サポートしなければならないIPPがOを反対させるREQUIRED属性が、IPPオブジェクトが*をサポートする必要はないOPTIONAL属性が、クライアントが要求における属性を省略するかもしれなくて、IPPオブジェクトが応答における属性を省略するかもしれないのを示すのを示すのを示します。 *の不在は、クライアントが要求における属性を供給しなければならないことを意味します、そして、IPPオブジェクトは応答における属性を供給しなければなりません。
Operation Requests
操作要求
The tables below show the attributes in their proper attribute groups for operation requests:
以下のテーブルは操作要求のためにそれらの適切な属性グループで属性を示しています:
Note: All operation requests contain "version-number", "operation- id", and "request-id" parameters.
以下に注意してください。 すべての操作要求が「バージョン番号」、「操作イド」、および「要求イド」パラメタを含んでいます。
Print-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
印刷仕事の要求: グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(○ *)
Hastings & Manros Informational [Page 14] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[14ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2566] Section 4.2)
Group 3: Document Content (R)
<document content>
仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)([RFC2566]セクション4.2を見る)グループ3: ドキュメントContent(R)<ドキュメント内容>。
Validate-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2566] Section 4.2)
仕事を有効にしている要求: グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(○ *)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)([RFC2566]セクション4.2を見ます)
Create-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2566] Section 4.2)
雇用を創り出している要求: グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)、(見る。([RFC2566]セクション4.2を見ます)
Print-URI Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
印刷URI要求: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)プリンタ-uri(R)
Hastings & Manros Informational [Page 15] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[15ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
document-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2566] Section 4.2)
ドキュメント-uriの(R)の要求しているユーザ名(R*)ジョブ名(R*)ipp属性信義(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(○ *)仕事のk八重奏(○ *)仕事印象(○ *)仕事のメディアシート(○ *)グループ2: 仕事のTemplate Attributes(R*)<Job Template属性>(○ *)、(見る。([RFC2566]セクション4.2を見ます)
Send-Document Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
Group 2: Document Content (R*)
<document content>
資料請求を発信させます: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の最後のドキュメントの(R)の要求しているユーザ名(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(○ *)グループ2: ドキュメントContent(R*)<ドキュメント内容>。
Send-URI Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
document-uri (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
URIを発信させている要求: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの最後のドキュメントの(R)のドキュメント-uriの(R)の要求している(R)ユーザ名(R*)ドキュメント名(R*)のドキュメント・フォーマット(R*)ドキュメント自然言語(○ *)圧縮(○ *)
Hastings & Manros Informational [Page 16] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[16ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Cancel-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
message (O*)
キャンセル仕事の要求: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の要求しているユーザ名(R*)メッセージ(○ *)
Get-Printer-Attributes Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
document-format (R*)
プリンタ属性を得ている要求: グループ1: 操作の属性自然言語の(R)のプリンタ-uriの(R)の要求しているAttributes(R)属性-charset(R)ユーザ名(R*)の要求された属性(R*)ドキュメント・フォーマット(R*)
Get-Job-Attributes Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
仕事の属性を得ている要求: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)(プリンタ-uriと仕事イド)| 仕事-uriの(R)の要求しているユーザ名(R*)の要求された属性(R*)
Get-Jobs Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
limit (R*)
requested-attributes (R*)
which-jobs (R*)
my-jobs (R*)
ジョブスを得ている要求: グループ1: 操作Attributes(R)が-charsetに、要求された属性で(R*)(R) 属性自然言語の(R)のプリンタ-uriの(R)の要求しているユーザ名(R*)限界(R*)を結果と考える、どれ、-、仕事、(R*)、私、-、仕事(R*)
Operation Responses
操作応答
The tables below show the response attributes in their proper attribute groups for responses.
応答のために、分類します以下のテーブルが、それらの適切な属性における応答属性を示している。
Note: All operation responses contain "version-number", "status- code", and "request-id" parameters.
以下に注意してください。 すべての操作応答が「バージョン番号」、「状態コード」、および「要求イド」パラメタを含んでいます。
Print-Job Response: Print-URI Response: Create-Job Response:
印刷仕事の応答: 印刷URI応答: 雇用を創り出している応答:
Hastings & Manros Informational [Page 17] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[17ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Send-Document Response:
Send-URI Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O*)
job-state-message (O*)
number-of-intervening-jobs (O*)
ドキュメントを発信させている応答: URIを発信させている応答: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note3を見る)の<のサポートされない属性>(R*)グループ3: 介入している仕事の仕事のObject Attributes(R*)(Note2を見る)仕事-uri(R)仕事イド(R)仕事州の(R)仕事の州の理由(○ *)仕事の州のメッセージ(○ *)番号(○ *)
Validate-Job Response:
Cancel-Job Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
仕事を有効にしている応答: キャンセル仕事の応答: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note3を見る)の<のサポートされない属性>。(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は存在しています。
Get-Printer-Attributes Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
プリンタ属性を得ている応答: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>(R*)グループ3: プリンタObject Attributes(R*)(Note2を見る)<は属性>を要求しました。(R*)
Note 4 - the Unsupported Attributes Group is present only if the client included some Operation attributes that the Printer doesn't support whether a success or an error return.
注意4--クライアントがPrinterが成功か誤りリターンであることにかかわらずサポートしないいくつかのOperation属性を入れた場合にだけ、Unsupported Attributes Groupは存在しています。
Hastings & Manros Informational [Page 18] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[18ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Get-Job-Attributes Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
仕事の属性を得ている応答: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>(R*)グループ3: 仕事のObject Attributes(R*)(Note2を見る)<は属性>を要求しました。(R*)
Get-Jobs Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*)
ジョブスを得ている応答: グループ1: 操作Attributes(R)属性-charset(R)属性自然言語(R)ステータスメッセージ(○ *)グループ2: サポートされないAttributes(R*)(Note4を見る)の<のサポートされない属性>(R*)グループ3: 仕事のObject Attributes(R*)(Note2、5を見る)<は属性>を要求しました。(R*)
Note 5: for the Get-Jobs operation the response contains a separate Job Object Attributes group 3 to N containing requested-attributes for each job object in the response.
注意5: 応答が含むGet-ジョブス操作のために、別々のJob Object Attributesは応答にそれぞれの仕事のオブジェクトのための要求された属性を含む3〜Nを分類します。
2.2.1.5 Validate the values of the REQUIRED Operation attributes
2.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
[RFC2566] Section 4.1,
a) [RFC2566]セクション4.1に応じてクライアントによって供給された属性構文タグに、それぞれのOperation属性値の長さは適度です。
b)that the attribute syntax tag is correct for that Operation
attribute according to [RFC2566] Section 3,
b) そのOperation属性に、[RFC2566]セクション3によると、属性構文タグは正しいです。
c)that the value is in the range specified for that Operation
attribute according to [RFC2566] Section 3,
[RFC2566]セクション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 [RFC2566] Section 3.
d) そんなに複数の値がクライアントによってマルチ評価された操作属性だけに供給されて、すなわち、[RFC2566]セクション3によると、それは1setOf Xです。
Hastings & Manros Informational [Page 19] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[19ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
If any of these checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request- value-too-long' status code. Since such an error is most likely to be an error detected by a client developer, rather than by an end- user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the
-これらのチェックのどれかが失敗して、IPPオブジェクトREJECTSが要求であり、RETURNSが'クライアントの誤りの悪い要求'か'クライアント誤り要求であるなら、あまりに長い間、'ステータスコードを評価してください。 またはそのような誤りが終わりのユーザでというよりむしろクライアント開発者によって検出された誤りである最も傾向があるので、IPPオブジェクトがどの属性がどちらかに誤りを持ったかしるしにUnsupported Attributes Groupを返す必要はない。
Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
ステータスメッセージ。 それぞれのこれらの構文チェックのための記述は以下のテーブルでの声明であるなら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によってサポートしている」属性の値が'値がない'(システム管理者が値を構成していないので)であるなら、チェックはいつも失敗します。
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'.
IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported".
値の長さが63以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 オブジェクトのPrinterもので「charsetによってサポートしている」属性でないなら、REJECT/RETURN「charsetがサポートしなかったクライアント誤り。」です。
attributes-natural-language(naturalLanguage)
属性自然言語(naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN '
client-error-request-value-too-long'.
ACCEPT the request even if not a member of the set in the Printer
object's "generated-natural-language-supported" attribute. If
the supplied value is not a member of the Printer object's
"generated-natural-language-supported" attribute, use the
Printer object's "natural-language-configured" value.
単一の非空の'naturalLanguage'でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 値の長さが63以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 ACCEPT、Printerのセットのどれかメンバーが反対しないでも、要求は「サポートされた発生している自然な言語」属性です。 供給値がPrinterオブジェクトの「サポートされた発生している自然な言語」属性のメンバーでないなら、Printerオブジェクトの「構成された自然な言語」値を使用してください。
Hastings & Manros Informational [Page 20] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[20ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
requesting-user-name
要求しているユーザ名
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the IPP object can obtain a better authenticated name, use it
instead.
単一の'名前の'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 IPPオブジェクトがより認証された名前を得ることができるなら、代わりにそれを使用してください。
job-name(name)
ジョブ名(名前)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT supplied by the client, the Printer object creates a name
from the document-name or document-uri.
単一の'名前の'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 クライアントによって供給されないで、Printerオブジェクトはドキュメント名から名前を作成するか、そして、ドキュメント-uri。
document-name (name)
ドキュメント名(名前)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
単一の'名前の'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。 値の長さが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 the value length is NOT equal to 1 octet, REJECT/RETURN '
client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the value
'false'.
IF NEITHER単一の'本当'NOR単一の'誤った''論理演算子'価値、REJECT/RETURN'クライアントの誤りの悪い要求'。 値の長さがクライアントによる'クライアント誤りはあまりに長い間、値を要求しています'が、1つの八重奏、REJECT/RETURNに供給されなかった同輩でないなら、IPPオブジェクトは、値が'誤っている'と仮定します。
document-format (mimeMediaType)
ドキュメント・フォーマット(mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "document-format-supported"
attribute, REJECT/RETURN 'client-error-document-format-not-
supported'
単一の非空の'mimeMediaType'でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 いずれかのPrinterでそうしないなら、オブジェクトは「形式が支えたドキュメント」属性であり、REJECT/RETURNは'クライアント誤りドキュメント形式でサポートされない'です。
Hastings & Manros Informational [Page 21] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[21ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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'.
IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
request'.
IF scheme is NOT in the Printer object's "reference-uri-schemes-
supported" attribute, REJECT/RETURN 'client-error-uri-scheme-
not-supported'.
The Printer object MAY check to see if the document exists and is
accessible. If the document is not found or is not accessible,
REJECT/RETURN 'client-error-not found'.
単一の非空の'REJECT/RETURN'クライアントuri'価値、誤りの悪い要求'でないなら。 値の長さが1023以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 URIであるなら、構文は有効でなく、REJECT/RETURNは'クライアント誤り悪い要求'です。 体系がPrinterオブジェクトの「参照-uri体系でサポートしている」属性、REJECT/RETURNで'クライアント誤り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 the value length is NOT equal to 1 octet, REJECT/RETURN '
client-error-request-value-too-long'
IF NEITHER単一の'本当'NOR単一の'誤った''論理演算子'価値、REJECT/RETURN'クライアントの誤りの悪い要求'。 値の長さが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'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
Ignore unsupported values which are the keyword names of
unsupported attributes. Don't bother to copy such requested
(unsupported) attributes to the Unsupported Attribute response
group since the response will not return them.
1以上でないなら、'キーワード'は、REJECT/RETURN'クライアント誤り悪い要求'と評価します。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 サポートされない属性のキーワード名であるサポートされない値を無視してください。 応答がそれらを返さないので、わざわざそのような要求された(サポートされない)属性をUnsupported Attribute応答グループにコピーしないでください。
Hastings & Manros Informational [Page 22] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[22ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
which-jobs (type2 keyword)
どれ、-、仕事(type2キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
the unsupported value to the Unsupported Attributes response
group and REJECT/RETURN 'client-error-attributes-or-values-
not-supported'.
Note: a Printer still supports the 'completed' value even if it
keeps no completed/canceled/aborted jobs: by returning no jobs
when so queried.
IF NOT supplied by the client, the IPP object assumes the 'not-
completed' value.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 または、IF NEITHERの'完成した'NORが'完成されない'で、Unsupported Attributes応答グループとREJECT/RETURN'クライアント誤り属性に属性とサポートされない値をコピーしてください、-、-、値でサポートされない、' 以下に注意してください。 完成するか取り消されたか中止になっている仕事を全く保たないでも、Printerはまだ'完成した'値をサポートしています: そのように質問される場合仕事を全く返さないことによって。 クライアント、オブジェクトが仮定するIPPによって供給されない、'、-、完成した'値。
my-jobs (boolean)
私、-、仕事(論理演算子)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN '
client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the 'false'
value.
IF NEITHER単一の'本当'NOR単一の'誤った''論理演算子'価値、REJECT/RETURN'クライアントの誤りの悪い要求'。 値の長さがクライアントによる'クライアント誤りはあまりに長い間、値を要求しています'が、1つの八重奏、REJECT/RETURNに供給されなかった同輩でないなら、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'.
IF NOT supplied by the client, the IPP object returns all jobs, no
matter how many.
単一の'整数の'4つの八重奏と範囲1においてマックスと等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。 供給されないなら、クライアント、オブジェクトが仕事、すべての物質を返すというわけではないIPPで、いくつですか?
2.2.1.6 Validate the values of the OPTIONAL Operation attributes
2.2.1.6 OPTIONAL Operation属性の値を有効にしてください。
OPTIONAL Operation attributes are those that an IPP object MAY or MAY NOT support. An IPP object validates the values of the OPTIONAL attributes supplied by the client. The IPP object performs the same syntactic validation checks for each OPTIONAL attribute value as in Section 2.2.1.5. As in Section 2.2.1.5, if any fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request-value-too-long' status code.
OPTIONAL Operation属性はIPPオブジェクトがサポートするかもしれないものです。 IPPオブジェクトはクライアントによって供給されたOPTIONAL属性の値を有効にします。 IPPオブジェクトはそれぞれのOPTIONAL属性のためのチェックがセクション2.2.1のように.5に評価する同じ構文の合法化を実行します。 セクション2.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
さらに、定義された「xxxによってサポートしている」Printer属性が全くなければ、IPPオブジェクトは何らかのPrinter属性か何らかの困難なコード化された値に対してそれぞれのOperation属性値をチェックします。 値はそれらの中でサポートされないか、または次に、サポートされた範囲、IPPにないなら
Hastings & Manros Informational [Page 23] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[23ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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.
誤りステータスコードがテーブルで示したオブジェクトREJECTSの要求とRETURNS。 Printerオブジェクトの「サポートされたxxx」属性の値が'値がない'(システム管理者が値を構成していないので)であるなら、チェックはいつも失敗します。
If the IPP object doesn't recognize/support an attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see the last row in the table below).
IPPオブジェクトが属性を認識するか、またはサポートしないなら、IPPオブジェクトは未知の、または、サポートされない属性として属性を扱います(以下のテーブルにおける最後の行を見てください)。
document-natural-language (naturalLanguage)
ドキュメント自然言語(naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN '
client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN '
client-error-request-value-too-long'.
IF NOT a value that the Printer object supports in document
formats, (no corresponding "xxx-supported" Printer attribute),
REJECT/RETURN 'client-error-natural-language-not-supported'.
単一の非空の'naturalLanguage'でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 値の長さが63以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 Printerオブジェクトがドキュメント・フォーマットでサポートする値、(対応する「xxxによってサポートしている」Printer属性がありません)でないなら、REJECT/RETURN'自然な言語がサポートしなかったクライアント誤り'です。
compression (type3 keyword)
圧縮(type3キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN '
client-error-request-value-too-long'.
IF NOT in the Printer object's "compression-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group and REJECT/RETURN 'client-error-
attributes-or-values-not-supported'.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 オブジェクトのPrinterもので「圧縮でサポートしている」属性でないなら、Unsupported Attributes応答グループとREJECT/RETURN'サポートされなかったクライアント誤り属性か値'に属性とサポートされない値をコピーしてください。
job-k-octets (integer(0:MAX))
仕事のk八重奏(整数(0: 最大))
IF NOT a single 'integer' value equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-k-octets-
supported" attribute, copy the attribute and the unsupported
value to the Unsupported Attributes response group and
REJECT/RETURN 'client-error-attributes-or-values-not-
supported'.
単一の'整数の'4つの八重奏と等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。 または、Printerオブジェクトの「仕事k-八重奏でサポートしている」属性のいずれかの範囲でそうしないなら、Unsupported Attributes応答グループとREJECT/RETURN'クライアント誤り属性に属性とサポートされない値をコピーしてください、-、-、値でサポートされない、'
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'クライアントの誤りの悪い要求'でないなら。
Hastings & Manros Informational [Page 24] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[24ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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'.
IF NOT in the range of the Printer object's "job-media-sheets-
supported" attribute, copy the attribute and the unsupported
value to the Unsupported Attributes response group and
REJECT/RETURN 'client-error-attributes-or-values-not-
supported'.
単一の'整数の'4つの八重奏と等しい値、REJECT/RETURN'クライアントの誤りの悪い要求'でないなら。 または、Printerオブジェクトの「仕事メディアシートでサポートしている」属性のいずれかの範囲でそうしないなら、Unsupported Attributes応答グループとREJECT/RETURN'クライアント誤り属性に属性とサポートされない値をコピーしてください、-、-、値でサポートされない、'
message (text(127))
メッセージ(テキスト(127))
IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 127 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
単一の'テキスト'値、REJECT/RETURN'クライアント誤り悪い要求'でないなら。 値の長さが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'.
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-
band" 'unsupported' value, but otherwise ignore the attribute.
その属性構文、REJECT/RETURNには、クライアントによって供給された属性構文がサポートされるか、しかし、長さは'クライアント誤りはあまりに長い間、値を要求していた'状態で法的ではありません。 ELSEが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 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
以下に注意してください。 将来のOperation属性は指定されたグループでどこでも現れるかもしれないプロトコル仕様に追加されるかもしれません。 そうでなければ、操作がうまくいっているとき、IPPオブジェクトは'うまくいっている間違いない無視されたか代入された属性'ステータスコードを返します。 すべての操作におけるサポートされないOperation属性を無視するのが中のサポートされないJob Template属性の取り扱いに類似している、作成、そして、クライアントが'誤った'値と共に「ipp属性信義」Operation属性を供給するときのValidate-仕事の操作。 この最後の規則は、より年取ったクライアントが新しいIPPと共にオブジェクトを織り込むことができて、より新しいクライアントが、より古いIPPと共にオブジェクトを織り込むことができるように私たちがIPPの将来のバージョンにOPTIONAL Operation属性を追加できるためのそうです。 (不意に働かないで新しい属性を無視できないなら、メジャーバージョン番号は無視されるでしょう。
Hastings & Manros Informational [Page 25] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[25ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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.
プロトコルドキュメントと要求で増強されてください、そうした、) Operation属性のためのこの規則は「ipp属性信義」属性の価値から独立しています。 '例えば、IPPオブジェクトはOPTIONAL「仕事のk八重奏」属性をサポートしない'なら、IPPオブジェクトは、「仕事のk八重奏」を未知の属性として扱って、クライアントによって供給された'整数'属性構文がないかどうか長さをチェックするだけです。 それが4つの八重奏でなく、IPPオブジェクトREJECTSが要求とRETURNS'クライアントの誤りの悪い要求'ステータスコードであるなら、IPPオブジェクトは、ほかに、「バンドの外」という'サポートされない'値に値を設定して、Unsupported Attribute応答グループに属性をコピーしますが、別の方法で属性を無視します。
2.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents
2.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-仕事の要求を有効にして、仕事にドキュメントを加える操作です。
2.2.2.1 Default "ipp-attribute-fidelity" if not supplied
2.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オブジェクトは、値が'誤っている'と仮定します。
2.2.2.2 Check that the Printer object is accepting jobs
2.2.2.2 Printerオブジェクトが仕事を受け入れているのをチェックしてください。
If the value of the Printer object's "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code.
「プリンタは仕事を受け入れていること」がオブジェクトのPrinterものの値であるなら'誤ってい'て、PrinterオブジェクトREJECTSは要求とRETURNS'仕事を受け入れないサーバ誤り'ステータスコードです。
2.2.2.3 Validate the values of the Job Template attributes
2.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 2.2.1.5.):
IPPオブジェクトはクライアントによって供給されたすべてのJob Template属性の値を有効にします。 IPPオブジェクトはそれがOperation属性のために実行するそれぞれのJob Template属性値の類似の構文の合法化チェックを実行します(.5にセクション2.2.1を見てください):
a)that the length of each value is correct for the attribute
syntax tag supplied by the client according to [RFC2566] Section
4.1.
a) [RFC2566]セクション4.1に応じてクライアントによって供給された属性構文タグに、それぞれの価値の長さは適度です。
b)that the attribute syntax tag is correct for that attribute
according to [RFC2566] Sections 4.2 to 4.4.
b) その属性に、[RFC2566]セクション4.2〜4.4によると、属性構文タグは正しいです。
Hastings & Manros Informational [Page 26] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[26ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
c)that multiple values are supplied only for multi-valued
attributes, i.e., that are 1setOf X according to [RFC2566]
Sections 4.2 to 4.4.
c) そんなに複数の値をマルチ評価された属性だけに供給して、すなわち、[RFC2566]セクション4.2〜4.4によると、それは1setOf Xです。
As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or 'client-error-request-value-too-long' status code as appropriate, independent of the value of the "ipp-attribute-fidelity". Since such an error is most likely to be an error detected by a client developer, rather than by an end-user, the IPP object NEED NOT return an indication of which attribute had the error in either the Unsupported Attributes Group or the Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table.
.5、これらの構文チェックのどれかが失敗して、IPPオブジェクトREJECTSが要求であり、RETURNSが'クライアントの誤りの悪い要求'であるかどうかまたは'クライアント誤りはあまりに長い間、値を要求している'状態が「ipp属性信義」の値の如何にかかわらず適宜コード化するセクション2.2.1のように。 そのような誤りがエンドユーザでというよりむしろクライアント開発者によって検出された誤りである最も傾向があるので、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 syntax'
error status code
1. 操作を拒絶してください、そして、'クライアント誤り誤りのある構文'誤りステータスコードを返してください。
2.accept the operation and use the first occurrence of the
attribute
2. 操作を受け入れてください、そして、属性の最初の発生を使用してください。
3.accept the operation and use the last occurrence of the
attribute
3. 操作を受け入れてください、そして、属性の最後の発生を使用してください。
depending on implementation. Therefore, clients MUST NOT supply multiple occurrences of the same Job Template attribute in the Job Attributes group in the request.
実装によります。 したがって、クライアントは要求におけるJob Attributesグループにおける、同じJob Template属性の複数の発生を供給してはいけません。
2.2.3 Algorithm for job validation
2.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 [RFC2566]).
セクション3.2を見てください。Printer属性に対する"xxx"が「xxxサポートした」Job-テンプレート属性を有効にするプロセスが以下の合法化アルゴリズムを使用できる、(.1 .2 [RFC2566)で。
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 3 with each value X. Each validation is
separate from the standpoint of returning unsupported values.
1. Uがマルチ評価されているなら、各値X.でTable3のアルゴリズムを実行することによって、Uの各値Xを有効にしてください。Each合法化は戻っているサポートされない値の見地から別々です。
Example: If U is "finishings" that the client supplies with
'staple', 'bind' values, then X takes on the successive values:
'staple', then 'bind'
例: 'ひも'は、次に、XがUがクライアントが'主要部分'に供給する「仕上げ」であるなら連続した値を呈するのを評価します: '主要部分'、当時の'ひも'
Hastings & Manros Informational [Page 27] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[27ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.If V is multi-valued, validate X against each Z of V by
performing the algorithm in Table 3 with each value Z. If a
value Z validates, the validation for the attribute value X
succeeds. If it fails, the algorithm is applied to the next
value Z of V. If there are no more values Z of V, validation
fails.
2. Vがマルチ評価されているなら、それぞれの値のZ.Ifに伴う値Zが有効にするTable3におけるアルゴリズムを実行するのによるVの各Z(Xが引き継ぐ属性値のための合法化)に対してXを有効にしてください。 失敗するなら、アルゴリズムがそこでV.Ifの次の値Zに適用されているのが、Vのそれ以上の値でないというZことである、合法化は失敗します。
Example: If V is "sides-supported" with values: 'one-sided',
'two-sided-long', and 'two-sided-short', then Z takes on the
successive values: 'one-sided', 'two-sided-long', and
'two-sided-short'. If the client supplies "sides" with 'two-
sided-long', the first comparison fails ('one-sided' is not
equal to 'two-sided-long'), the second comparison succeeds
('two-sided-long' is equal to 'two-sided-long"), and the third
comparison ('two-sided-short' with 'two-sided-long') is not even
performed.
例: Vが値がある「側でサポートされる」であるなら: '一方的で'、'二面に長く'、'二面に短く'て、次に、Zは連続した値を呈します: '一方的で'、'二面に長く'、'二面に短いです'。 「クライアントが'2に-長い間、面があったこと'を「側」に供給するなら、最初の比較は失敗します、そして、('一方的'は'二面に長いこと'と等しくはありません)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 3.
3. UとVの両方が単一に評価されているなら、Vと使用がTable3の合法化規則であったなら、XがUとZであることをさせてください。
Table 3 - Rules for validating single values X against Z
テーブル3--Zに対してただ一つの値Xを有効にするための規則
attribute attribute validated if:
syntax of X syntax of Z
属性属性が有効にした、: ZのX構文の構文
integer rangeOfInteger X is within the range of
Z
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オブジェクトもありません(以下のテーブルにおける最後の行を見てください)。
Hastings & Manros Informational [Page 28] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[28ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
If some Job Template attributes are supported for some document formats and not for others or the values are different for different document formats, the IPP object SHOULD take that into account in this validation using the value of the "document-format" supplied by the client (or defaulted to the value of the Printer's "document- format-default" attribute, if not supplied by the client). For example, if "number-up" is supported for the 'text/plain' document format, but not for the 'application/postscript' document format, the check SHOULD (though it NEED NOT) depend on the value of the "document-format" operation attribute. See "document-format" in [RFC2566] section 3.2.1.1 and 3.2.5.1.
いくつかのJob Template属性が他のもののためにサポートされるのではなく、いくつかのドキュメント・フォーマットのためにサポートされるか、または異なったドキュメント・フォーマットにおいて、値が異なるなら、IPPオブジェクトSHOULDは、この合法化でクライアント(または、クライアントによって供給されないなら、Printerの「ドキュメント形式デフォルト」属性の値をデフォルトとする)によって供給された「ドキュメント・フォーマット」の値を使用することでそれを考慮に入れます。 例えば、「上に数」が'テキスト/明瞭な'ドキュメント・フォーマットのためにサポートされますが、'アプリケーション/追伸'ドキュメント・フォーマットのためにサポートされるというわけではないなら、チェックSHOULD(NOTを必要としますが)は「ドキュメント・フォーマット」操作属性の値に依存します。 [RFC2566]セクション3.2.1における「ドキュメント・フォーマット」.1と3.2を見てください。.5 .1。
Note: whether the request is accepted or rejected is determined by the value of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all Job Template attribute supplied are examined and all unsupported attributes and/or values are copied to the Unsupported Attributes response group.
以下に注意してください。 要求を受け入れるか、または拒絶するかがその後のステップにおける、「ipp属性信義」属性の値で決定するので、Job Template属性が供給したすべてが調べられます、そして、すべてのサポートされない属性、そして/または、値はUnsupported Attributes応答グループにコピーされます。
job-priority (integer(1:100))
ジョブ優先順位(整数(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, use the value of the Printer
object's "job-priority-default" attribute at job submission
time.
IF NOT in the range 1 to 100, inclusive, copy the attribute and
the unsupported value to the Unsupported Attributes response
group.
Map the value to the nearest supported value in the range 1:100 as
specified by the number of discrete values indicated by the
value of the Printer's "job-priority-supported" attribute. See
the formula in [RFC2566] Section 4.2.1.
単一の'整数'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 クライアントによって供給されないなら、ジョブ依頼時にPrinterオブジェクトの「仕事の優先権デフォルト」属性の値を使用してください。 包括的な1〜100がいずれかの範囲に属性とサポートされない値をUnsupported Attributes応答にコピーしないなら、分類してください。 離散的な値の数に従った指定されるとしての1:100がPrinterの「優先権がサポートした仕事」属性の値で示した範囲で値であるとサポートされる中で最も近いものに値を写像してください。 [RFC2566]セクション4.2.1における公式を見てください。
job-hold-until (type3 keyword | name)
仕事の保持(type3キーワード| 名前)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT supplied by the client, use the value of the Printer
object's "job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
キーワード単一の'''REJECT/RETURN、'値を命名してください'というクライアントの誤りの悪い要求'でないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 クライアントによって供給されないなら、オブジェクトのPrinterものの値を使用してください、「仕事の保持、」 ジョブ依頼時に、結果と考えます。 Printerオブジェクトのどんな「サポートされるまでの仕事の保持」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
Hastings & Manros Informational [Page 29] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[29ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
job-sheets (type3 keyword | name)
仕事シート(type3キーワード| 名前)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "job-sheets-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
キーワード単一の'''REJECT/RETURN、'値を命名してください'というクライアントの誤りの悪い要求'でないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 Printerオブジェクトのどんな「シートがサポートした仕事」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
multiple-document-handling (type2 keyword)
複数のドキュメント処理(type2キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "multiple-document-handling-
supported" attribute, copy the attribute and the unsupported
value to the Unsupported Attributes response group.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 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'.
IF NOT in range of the Printer object's "copies-supported"
attribute copy the attribute and the unsupported value to the
Unsupported
Attributes response group.
単一の'整数'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 オブジェクトがPrinterの範囲でないことでの「コピーでサポートしている」属性コピーであるなら、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'.
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.
'enum'でないなら、4つの八重奏と等しい長さでREJECT/RETURN'クライアントの誤りの悪い要求'と(s) それぞれ評価してください。 オブジェクトの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'.
IF first value is greater than second value in any range, the
ranges are not in ascending order, or ranges overlap,
REJECT/RETURN 'client-error-bad-request'.
IF the value of the Printer object's "page-ranges-supported"
attribute is 'false', copy the attribute to the Unsupported
Attributes response group and set the value to the "out-of-
band" 'unsupported' value.
'rangeOfInteger'でないなら、8つの八重奏と等しい長さでREJECT/RETURN'クライアントの誤りの悪い要求'と(s) それぞれ評価してください。 最初に、値がどんな範囲の2番目の値、範囲よりも昇順にすばらしいか、または範囲が重なるなら、REJECT/RETURN'クライアントの誤りの悪い要求'です。 Printerオブジェクトの「範囲がサポートしたページ」属性の値が'誤っている'なら、応答が値を分類して、設定するUnsupported Attributesに属性をコピーしてください、「外、-、-」 'サポートされない'値を括ってください。
Hastings & Manros Informational [Page 30] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[30ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
sides (type2 keyword)
側(type2キーワード)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "sides-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
'値、REJECT/RETURN'クライアント誤り悪い要求'というただ一つの'キーワードでないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 オブジェクトの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'.
IF NOT a value or in the range of one of the values of the Printer
object's "number-up-supported" attribute, copy the attribute
and value to the Unsupported Attribute response group.
単一の'整数'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 値でない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'.
IF NOT in the Printer object's "orientation-requested-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
単一の'enum'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 Printerオブジェクトのどんな「サポートされた状態で要求されたオリエンテーション」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
media (type3 keyword | name)
メディア(type3キーワード| 名前)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "media-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
キーワード単一の'''REJECT/RETURN、'値を命名してください'というクライアントの誤りの悪い要求'でないなら。 値の長さが255以上の八重奏であるなら、REJECT/RETURN'誤り要求があまりに長い間評価するクライアント'です。 オブジェクトの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'.
IF NOT in the Printer object's "printer-resolution-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
単一の'解決'でないなら、9つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 Printerオブジェクトのどんな「サポートされたプリンタ解決」属性でもそうしないなら、Unsupported Attributes応答グループに属性とサポートされない値をコピーしてください。
Hastings & Manros Informational [Page 31] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[31ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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'.
IF NOT in the Printer object's "print-quality-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
単一の'enum'でないなら、4つの八重奏と等しい長さで、REJECT/RETURN'クライアントの誤りの悪い要求'と評価してください。 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.
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).
クライアントによって供給された属性構文がサポートされますが、属性構文の長さ的であり、属性構文の長さが可変であり、その属性構文には、長さが法的でないなら、REJECT/RETURN'クライアントの誤りの悪い要求'は、修理されるか'また、クライアント誤り要求価値の長いです'。 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属性をコピーして、属性値を「バンドの外」という'サポートされない'値に変えます。 以下のテーブルは、長さがすべての属性構文がないかどうかチェックするのを示します。 以下では、以下をテーブルの上に置いてください。 「<=」は以下か等しいことを意味して、「=」は以下のことのために等しいことを意味します。
Name Octet length check for read-write attributes ----------- -------------------------------------------- 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 'textWithoutLanguage' <= 1023 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 'nameWithoutLanguage' <= 255 'keyword' <= 255 'enum' = 4 'uri' <= 1023 'uriScheme' <= 63 'charset' <= 63 'naturalLanguage' <= 63 'mimeMediaType' <= 255
読書して書いている属性のための名前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
Hastings & Manros Informational [Page 32] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[32ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
'octetString' <= 1023 'boolean' = 1 'integer' = 4 'rangeOfInteger' = 8 'dateTime' = 11 'resolution' = 9 '1setOf X'
11 8 4 1 1023'octetString'<='論理演算子'='整数'='rangeOfInteger'='dateTime'='解決'は9'1setOf X'と等しいです。
2.2.3.1 Check for conflicting Job Template attributes values
2.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 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.
個別にかつてのすべてのOperationとJob Template属性をチェックしてあります、とPrinterオブジェクトSHOULDはすべてのサポートしている値の中の値がクライアントから供給したどんな闘争がないかどうかチェックします。 例えば、しかしながら、Printerオブジェクトがとめて、透明で印刷できて、物理的なとめ規制のためであるかもしれない、Printerオブジェクトは透明をとめることができないかもしれません。 IPPオブジェクトはサポートしている属性とそれらの闘争している属性値をUnsupported Attributes応答グループにコピーします。 Printerオブジェクトはそれらの属性の上にコピーされるだけです。どちらかが闘争、およびそれを解決するために無視するか、または置換するPrinterオブジェクトはクライアントによって供給されたものを元の値に返します。 例えば、クライアント供給が同輩が'とめる'「仕上げ」であると仮定してください。そうすれば、「メディア」は'透明'と等しいです、しかし、Printerオブジェクトはとめが透明であるとサポートしません。 Printerが選ぶなら、闘争、Printerが反対すると決議するためにとめ要求を無視するのはUnsupported Attributes応答グループで'とめる'ために等しい「仕上げ」を返します。 何か属性がマルチ評価されているなら、属性の闘争値だけがコピーされます。
Note: The decisions made to resolve the conflict (if there is a choice) is implementation dependent.
以下に注意してください。 闘争(選択があれば)が実装に依存していると決議するのがされた決定。
2.2.3.2 Decide whether to REJECT the request
2.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.
(2) 'client-error-attributes-or-values-not-supported' status code,
otherwise.
(1) 'クライアント誤り闘争属性'ステータスコード何かクライアントによって供給された属性の間の闘争があったなら。 (2) そうでなければ、'属性か値がサポートしなかったクライアント誤り'ステータスコード。
Hastings & Manros Informational [Page 33] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[33ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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属性が返されているこのステップを始めるなら、それらは重大な誤りではありません。
2.2.3.3 For the Validate-Job operation, RETURN one of the success
status codes
2.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属性が返されているこのステップを始めるなら、それらは重大な誤りではありません。
2.2.3.4 Create the Job object with attributes to support
2.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オブジェクトから属性を取り除きます(ジョブ処理時の通常のデフォルトの振舞いがその属性のために行われるように)。
Hastings & Manros Informational [Page 34] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[34ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
If there were no attributes or values flagged as unsupported, or the value of 'ipp-attribute-fidelity" was 'false', the Printer object is able to accept the create request and create a new Job object. If the "ipp-attribute-fidelity" attribute is set to 'true', the Job Template attributes that populate the new Job object are necessarily all the Job Template attributes supplied in the create request. If the "ipp-attribute-fidelity" attribute is set to 'false', the Job Template attributes that populate the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. Thus, some of the requested Job Template attributes may not appear in the Job object because the Printer object did not support those attributes. The attributes that populate the Job object are persistently stored with the Job object for that Job. A Get-Job-Attributes operation on that Job object will return only those attributes that are persistently stored with the Job object.
Printerオブジェクトが、「属性が全くなかったか、値はサポートされないとして弛んだか、そして、'ipp属性信義の値」が'誤っていた'と受け入れることができる、要求を作成してくださいといって、新しいJobオブジェクトを作成してください、' 「ipp属性信義」属性が'本当に'設定されるなら、新しいJobオブジェクトに居住するJob Template属性がすべて、必ず中に供給されたJob Template属性である、要求を作成してください。 「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属性信義」によって許容されていると、それは無視された)を提供しましたが、どんな値もドキュメントデータの内容の中で提供されなかったと指定しませんでした。
Hastings & Manros Informational [Page 35] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[35ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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(なくなった属性に関する)を処理するという結果は未定義です。
2.2.3.5 Return one of the success status codes
2.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, [RFC2566] section
3.2.1.2.
また、PrinterオブジェクトはJob('未定'の、そして、'未定に保持された''処理'など)の初期状態などを示す状態属性をJobに返します。 .2にPrint-仕事のResponse、[RFC2566]セクション3.2.1を見てください。
2.2.3.6 Accept appended Document Content
2.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データを受け入れて、どちらかが、印刷し始めるか、または後で処理するためにそれをスプールします。
2.2.3.7 Scheduling and Starting to Process the Job
2.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属性がドキュメントデータにおける埋め込まれた指示の上で優先することを確認するために最善をつくします。
Hastings & Manros Informational [Page 36] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[36ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.2.3.8 Completing the Job
2.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 implementation halts all processing, cleans up any resources, and moves the Job into the 'aborted' state.
Printerオブジェクトは、Jobを'完成した'状態に動かすことができるまでJobを処理し続けています。 キャンセル仕事の操作が受け取られているなら、実装は結局、Jobを'取り消された'状態に動かします。 システムが処理の間のそれが完成した状態にJobを進行できない誤りに遭遇するなら、実装は、'中止になっている'状態にすべての処理を止めて、どんなリソースも掃除して、Jobを動かします。
2.2.3.9 Destroying the Job after completion
2.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」か「仕事イド」値を再使用します、クライアントによって保たれた聞き古した参照が間違った(より新しい)仕事によりアクセスしそうにないように。
2.2.3.10 Interaction with "ipp-attribute-fidelity"
2.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".
いくつかのPrinterオブジェクト実装が'本当'への「ipp信義を結果と考えている」セットと'試みます'が、まだクライアントがまさに何を指定するかをわかることができない「オーバーライドがサポートしたpdl」セットを支えるかもしれない、要求を作成してください。 これはドキュメントデータの中で埋め込まれた教える技能と、ドキュメントデータに伴う外部の教える技能とどうそのような指示の間の闘争を扱うかに関する役割に関してされたレガシー決定と仮定のためです。 また、「ipp属性信義」と「オーバーライドがサポートしたpdl」という2つの特別な属性が各属性のために特定の値よりむしろ全体の仕事に適用されるという事実によって与えられた実装がどう振る舞うかに関して正確な100%であることができないことは合成されます。 例えば、いくつかの実装が「上に数」を除いたほとんどすべてのJob Template属性をくつがえすことができるかもしれません。
2.3 Status codes returned by operation
2.3 操作で返された状態コード
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.
このセクションは最初の操作(印刷仕事)ですべてのステータスコードを一度記載します。 そして、それは異なって、その後の操作のために各操作で専門にされるステータスコードを記載します。
Hastings & Manros Informational [Page 37] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[37ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.3.1 Printer Operations
2.3.1 プリンタ操作
2.3.1.1 Print-Job
2.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 14 for a more complete description of each status code.
Printerオブジェクトは示された理由で以下の「ステータスコード」値の1つを返さなければなりません。 成功か誤りに応答を返す前にドキュメントデータのすべてを受け入れたかどうかが実装によります。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
For the following success status codes, the Job object has been created and the "job-id", and "job-uri" assigned and returned in the response:
以下の成功ステータスコードにおいて、Jobオブジェクトが作成されて、「仕事イド」、および「仕事-uri」は、応答で割り当てて、戻りました:
successful-ok: no request attributes were substituted or ignored.
successful-ok-ignored-or-substituted-attributes: some supplied
(1) attributes were ignored or (2) unsupported attribute
syntaxes or values were substituted with supported values or
were ignored. Unsupported attributes, attribute syntaxes, or
values MUST be returned in the Unsupported Attributes group of
the response.
successful-ok-conflicting-attributes: some supplied attribute
values conflicted with the values of other supplied attributes
and were either substituted or ignored. Attributes or values
which conflict with other attributes and have been substituted
or ignored MUST be returned in the Unsupported Attributes group
of the response as supplied by the client.
うまくいっているOK: 要求属性を全く代入もしませんでしたし、無視もしませんでした。うまくいっているOKは、属性を無視したか、または代入しました: (2) いくつかの供給された(1)属性が無視されたか、またはサポートされない属性構文か値をサポートしている値で代入したか、無視しました。 サポートされない属性、属性構文、または値が返して、Unsupported Attributesでは. うまくいっている間違いない闘争属性が応答を分類しているということでなければなりません: いくつかの供給された属性値と他の供給された属性の値と衝突して、代入したか、または無視しました。 クライアントによって供給される応答のUnsupported Attributesグループで他の属性と衝突して、代入するか、または無視した属性か値を返さなければなりません。
[RFC2566] section 3.1.6 Operation Status Codes and Messages states:
[RFC2566]セクション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 14): 'client-error-bad-request', 'client-error-
charset-not-supported', 'server-error-internal-error', '
server-error-operation-not-supported', and 'server-error-
version-not-supported'. In this case, it MUST set the value of
the "attributes-charset" operation attribute to 'utf-8' in the
error response.
Printerであるなら、オブジェクトは「ステータスメッセージ」操作属性をサポートして、それはREQUIRED'utf-8'が以下の誤りステータスコードのためのステータスメッセージを返すためにcharsetするSHOULD使用(セクション14を見る)です: 'クライアントの誤りの悪い要求'、'サポートされなかったクライアント誤りcharset'、'サーバ誤り内部エラー'、'操作がサポートしなかったサーバ誤り'、および'サポートされなかったサーバ誤りバージョン'。 この場合、それは誤り応答で「属性-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.
クライアントの誤りの悪い要求: 要求構文は仕様に従いません。
Hastings & Manros Informational [Page 38] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[38ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
client-error-forbidden: The request is being refused for
authorization or authentication reasons. The implementation
security policy is to not reveal whether the failure is one of
authentication or authorization.
client-error-not-authenticated: Either the request requires
authentication information to be supplied or the authentication
information is not sufficient for authorization.
client-error-not-authorized: The requester is not authorized to
perform the request on the target object.
client-error-not-possible: The request cannot be carried out
because of the state of the system. See also 'server-error-
not-accepting-jobs' status code which MUST take precedence if
the Printer object's "printer-accepting-jobs" attribute is '
false'.
client-error-timeout: not applicable.
client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no
forwarding address is known.
client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to
process it.
client-error-request-value-too-long: the size of request variable
length attribute values, such as 'text' and 'name' attribute
syntaxes, exceed the maximum length specified in [RFC2566] for
the attribute and MUST be returned in the Unsupported
Attributes Group.
client-error-document-format-not-supported: the document format
supplied is not supported. The "document-format" attribute
with the unsupported value MUST be returned in the Unsupported
Attributes Group. This error SHOULD take precedence over any
other 'xxx-not-supported' error, except 'client-error-charset-
not-supported'.
client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntaxes, or values are not
supported and the client supplied the "ipp-attributes-fidelity"
operation attribute with a 'true' value. They MUST be returned
in the Unsupported Attributes Group as explained below.
client-error-uri-scheme-not-supported: not applicable.
client-error-charset-not-supported: the charset supplied in the
"attributes-charset" operation attribute is not supported. The
Printer's "configured-charset" MUST be returned in the response
as the value of the "attributes-charset" operation attribute
and used for any 'text' and 'name' attributes returned in the
error response. This error SHOULD take precedence over any
other error, unless the request syntax is so bad that the
client's supplied "attributes-charset" cannot be determined.
禁じられたクライアント誤り: 要求は承認か認証理由で拒否されています。 実装安全保障政策は失敗が認証か承認誤りが認証しなかったクライアントで1であるかどうかを明らかにしないことです: 要求が、認証情報が提供されるのを必要とするか、または認証情報は承認誤りが権限を与えなかったクライアントに十分ではありません: リクエスタによる要求を実行するのは認可されないで、目標の上では. 可能でないクライアント誤りが反対しているということです: システムの事情のために要求を行うことができません。 また、''状態がコード化するPrinterオブジェクトの「プリンタ受諾仕事」属性が優先するなら優先しなければならないサーバ誤り受け入れていない仕事の'誤る'クライアント誤りタイムアウトを見てください: 適切でない. 見つけられなかったクライアント誤り: 目標オブジェクトが存在していない、クライアント誤り過ぎ去る、: 目標オブジェクトはもう存在していません、そして、フォーワーディング・アドレスは全く知られていません。クライアント誤りは大き過ぎる状態で実体を要求します: 要求、そして/または、印刷データのサイズはIPP Printerがそれを処理する容量を超えています。クライアント誤りはあまりに長い間、値を要求します: 'テキスト'と'名前'属性構文などの要求可変長属性値のサイズを属性のために[RFC2566]で指定された最大の長さを超えて、Unsupported Attributes Groupで返さなければなりません。クライアント誤りはサポートされなかった書式を記録します: 形式が提供したドキュメントは支えられません。 Unsupported Attributes Groupでサポートされない値がある「ドキュメント・フォーマット」属性を返さなければなりません。 この誤りSHOULDは'クライアント誤り-charsetによってサポートされないこと'を除いたいかなる他の'サポートされなかったxxx'誤りにも. 属性か値がサポートしなかったクライアント誤りに優先します: 1、さらに供給された属性、属性構文、または値がサポートされませんでした、そして、クライアントは'本当'の値と共に「ipp属性信義」操作属性を供給しました。 . uri体系がサポートしなかったクライアント誤りの下で説明されるUnsupported Attributes Groupでそれらを返さなければなりません: 適切でない. charsetがサポートしなかったクライアント誤り: 「属性-charset」操作属性で供給されたcharsetはサポートされません。 Printerの「構成されたcharset」を「属性-charset」操作属性の値として応答で返されて、誤り応答で返されたどんな'テキスト'と'名前'属性にも使用しなければなりません。 この誤りSHOULDはいかなる他の誤りの上でも優先します、要求構文が非常に悪いのでクライアントの供給された「属性-charset」が決定できるなら。
Hastings & Manros Informational [Page 39] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[39ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
client-error-conflicting-attributes: one or more supplied
attribute va attribute values conflicted with each other and
the client supplied the "ipp-attributes-fidelity" operation
attribute with a 'true' value. They MUST be returned in the
Unsupported Attributes Group as explained below.
server-error-internal-error: an unexpected condition prevents the
request from being fulfilled.
server-error-operation-not-supported: not applicable (since
Print-Job is REQUIRED).
server-error-service-unavailable: the service is temporarily
overloaded.
server-error-version-not-supported: the version in the request is
not supported. The "closest" version number supported MUST be
returned in the response.
server-error-device-error: a device error occurred while
receiving or spooling the request or document data or the IPP
Printer object can only accept one job at a time.
server-error-temporary-error: a temporary error such as a buffer
full write error, a memory overflow, or a disk full condition
occurred while receiving the request and/or the document data.
server-error-not-accepting-jobs: the Printer object's "printer-
is-not-accepting-jobs" attribute is 'false'.
server-error-busy: the Printer is too busy processing jobs to
accept another job at this time.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
document data.
クライアント誤り闘争属性: 1かさらに供給された属性va属性値が'本当'の値と共に「ipp属性信義」操作属性を提供する互いとクライアントと闘争しました。 . サーバ誤り内部エラーの下で説明されるUnsupported Attributes Groupでそれらを返さなければなりません: 予期していなかった状態が防ぐ、実現するので. 操作がサポートしなかったサーバ誤りを要求してください: 適切でない、(Print-仕事がREQUIREDであるので) . 入手できないサーバ誤りサービス: サービスが一時積みすぎられる. サポートされなかったサーバ誤りバージョン: 要求におけるバージョンはサポートされません。 応答で数がサポートした「最も近い」バージョンを返さなければならない、サーバ誤りデバイス誤り: 要求、ドキュメントデータまたはIPP Printerオブジェクトを受け取るか、またはスプールすると. サーバの誤りの一時的な誤りを一度に1仕事して受け入れることができるだけですが、デバイス誤りは発生しました: バッファ満などの一時的な誤りは誤りを書きます、メモリオーバーフロー、または、ディスクの完全な状態が要求、そして/または、ドキュメントデータを受け取っている間、現れた、仕事を受け入れないサーバ誤り: 「プリンタ受諾は仕事ではありません」というPrinterオブジェクトの属性が'誤っている'、誤りが忙しくするサーバ: Printerは、仕事を処理することでこのとき別口の仕事を受け入れることができないくらい忙しいです。サーバ誤り仕事は中止されました: クライアントがドキュメントデータを送っていた間、仕事はオペレータかシステムによって中止されています。
2.3.1.2 Print-URI
2.3.1.2 印刷URI
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Print-URI with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでPrint-URIに適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
server-error-uri-scheme-not-supported: the URI scheme supplied in
the "document-uri" operation attribute is not supported and is
returned in the Unsupported Attributes group.
uri体系がサポートしなかったサーバ誤り: 「ドキュメント-uri」操作属性で供給されたURI体系を、サポートしないで、Unsupported Attributesグループで返します。
2.3.1.3 Validate-Job
2.3.1.3 仕事を有効にします。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Validate-Job. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてがValidate-仕事に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
Hastings & Manros Informational [Page 40] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[40ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.3.1.4 Create-Job
2.3.1.4雇用を創り出します。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Create-Job with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでCreate-仕事に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
server-error-operation-not-supported: the Create-Job operation is
not supported.
操作がサポートしなかったサーバ誤り: Create-仕事の操作はサポートされません。
2.3.1.5 Get-Printer-Attributes
2.3.1.5 プリンタ属性を得てください。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでGetプリンタ属性操作に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードにおいて、要求された属性はGroup3で応答で返されます:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were
unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-
Job, except the "requested-attributes" operation attribute MAY,
but NEED NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっているOK: 要求属性を全く代入しなかったか、または(Print-仕事と同じ)であることで無視された、要求されなかった属性はサポートされなかったです。うまくいっているOKは、属性を無視したか、または代入しました: NOTを必要として、「要求された属性」操作属性以外のPrint仕事がそうするかもしれないのと同じであることで、サポートされない値と共に返してください、うまくいっている間違いない闘争属性: 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.
client-error-request-entity-too-large: same as Print-job, except
that no print data is involved.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes MUST be ignored and '
successful-ok-ignored-or-substituted-attributes' returned.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get-
Printer-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable.
可能でないクライアント誤り: Print-仕事と同じであることで、さらに、Printerオブジェクトはどんな要求も受け入れていません。クライアント誤りは大き過ぎる状態で実体を要求します: 印刷データが全くかかわらないのを除いたPrint-仕事と同じこと、属性か値がサポートしなかったクライアント誤り: 適切でないことで、サポートされない操作属性がそうしなければならないので、無視されてください。そうすれば、'うまくいっているOKは、属性を無視したか、または代入したこと'は. クライアント誤り闘争属性を返しました: それを除いたPrint-仕事の「ipp属性信義」がかかわらないのと同じである、操作がサポートしなかったサーバ誤り: 適切でない、(Getプリンタ属性がREQUIREDであるので) . サーバ誤りデバイス誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと、サーバの誤りの一時的な誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと、仕事を受け入れないサーバ誤り: 適切でない。
Hastings & Manros Informational [Page 41] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[41ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
server-error-busy: same as Print-Job, except the IPP object is
too busy to accept even query requests.
server-error-job-canceled: not applicable.
誤りが忙しくするサーバ: Print-仕事と同じであることで、IPPを除いて、オブジェクトは質問要求さえ受け入れることができないくらい忙しいです。サーバ誤り仕事は中止されました: 適切でない。
2.3.1.6 Get-Jobs
2.3.1.6 ジョブスを得ます。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Jobs operation with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでGet-ジョブス操作に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードにおいて、要求された属性はGroup3で応答で返されます:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were
unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-
Job, except the "requested-attributes" operation attribute MAY,
but NEED NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっているOK: 要求属性を全く代入しなかったか、または(Print-仕事と同じ)であることで無視された、要求されなかった属性はサポートされなかったです。うまくいっているOKは、属性を無視したか、または代入しました: NOTを必要として、「要求された属性」操作属性以外のPrint仕事がそうするかもしれないのと同じであることで、サポートされない値と共に返してください、うまくいっている間違いない闘争属性: Print-仕事と同じです。
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.
client-error-request-entity-too-large: same as Print-job, except
that no print data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes MUST be ignored and '
successful-ok-ignored-or-substituted-attributes' returned.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get-
Jobs is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
可能でないクライアント誤り: Print-仕事と同じであることで、さらに、Printerオブジェクトはどんな要求も受け入れていません。クライアント誤りは大き過ぎる状態で実体を要求します: Print-仕事と同じであることで、それ以外に、印刷データは全くかかわりません。クライアント誤りはサポートされなかった書式を記録します: 適切でない. 属性か値がサポートしなかったクライアント誤り: 適切でないことで、サポートされない操作属性がそうしなければならないので、無視されてください。そうすれば、'うまくいっているOKは、属性を無視したか、または代入したこと'は. クライアント誤り闘争属性を返しました: それを除いたPrint-仕事の「ipp属性信義」がかかわらないのと同じである、操作がサポートしなかったサーバ誤り: 適切でない、(GetジョブスがREQUIREDであるので) . サーバ誤りデバイス誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと、サーバの誤りの一時的な誤り: ドキュメントデータが全くかかわらないのを除いたPrint-仕事と同じこと、仕事を受け入れないサーバ誤り: 適切でない. サーバ誤り仕事は中止されました: 適切でない。
Hastings & Manros Informational [Page 42] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[42ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.3.2 Job Operations
2.3.2 仕事の操作
2.3.2.1 Send-Document
2.3.2.1 ドキュメントを発信させます。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでGetプリンタ属性操作に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
For the following success status codes, the document has been added to the specified Job object and the job's "number-of-documents" attribute has been incremented:
以下の成功ステータスコードにおいて、ドキュメントは指定されたJobオブジェクトに加えられます、そして、仕事の「ドキュメントの数」属性は増加されました:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-
Job.
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。うまくいっているOKは、属性を無視したか、または代入しました: Print仕事うまくいっている間違いない闘争属性と同じ: 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
multi-document job after this attribute has been set to 'true'.
Another condition is that the state of the job precludes Send-
Document, i.e., the job has already been closed out by the
client. However, if the IPP Printer closed out the job due to
timeout, the 'client-error-timeout' error status SHOULD be
returned instead.
client-error-timeout: This request was sent after the Printer
closed the job, because it has not received a Send-Document or
Send-URI operation within the Printer's "multiple-operation-
time-out" period.
client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attributes-fidelity" operation attribute is not
involved.
server-error-operation-not-supported: the Send-Document request
is not supported.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
data.
可能でないクライアント誤り: Print-仕事と同じです、Printerが「プリンタは受諾仕事している」以外に、属性がかかわりません、クライアントが、'本当に'この属性が設定された後にマルチドキュメント仕事を提出し終えることができるように。 別の状態が仕事の州がSendドキュメントを排除するということである、すなわち、仕事はクライアントによって既に見切り売りされました。 しかしながら、IPP Printerが仕事から閉じたなら代わりにタイムアウト、'クライアント誤りタイムアウト'エラー状況SHOULDを返すか、クライアント誤りタイムアウト: Printerが仕事を終えた後にこの要求を送りました、Printerの「複数の操作しているタイムアウト」の期間中にSend-ドキュメントかSend-URI操作を受けていないので。クライアント誤りは大き過ぎる状態で実体を要求します: Print-Jobクライアント誤り闘争属性と同じ: Print-仕事と同じであることで、その「ipp属性信義」以外に、操作属性がかかわらない、操作がサポートしなかったサーバ誤り: Send-資料請求は. 仕事を受け入れないサーバ誤りであるとサポートされません: 適切でない. サーバ誤り仕事は中止されました: クライアントがデータを送っていた間、仕事はオペレータかシステムによって中止されています。
Hastings & Manros Informational [Page 43] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[43ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.3.2.2 Send-URI
2.3.2.2 URIを発信させます。
All of the Print-Job status code descriptions in Section 3.2.1.2 Print-Job Response with the specializations described for Send- Document are applicable to Send-URI. See Section 14 for a more complete description of each status code.
専門化がSendのために説明されている.2Print-仕事のResponseが記録するセクション3.2.1におけるPrint-地位のコード記述のすべてがSend-URIに適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
server-error-uri-scheme-not-supported: the URI scheme supplied in
the "document-uri" operation attribute is not supported and the
"document-uri" attribute MUST be returned in the Unsupported
Attributes group.
uri体系がサポートしなかったサーバ誤り: 「ドキュメント-uri」操作属性で供給されたURI体系はサポートされません、そして、Unsupported Attributesグループで「ドキュメント-uri」属性を返さなければなりません。
2.3.2.3 Cancel-Job
2.3.2.3 キャンセル仕事
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Cancel-Job with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでキャンセル仕事に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
For the following success status codes, the Job object is being canceled or has been canceled:
以下の成功ステータスコードにおいて、Jobオブジェクトは、取り消されているか、または取り消されました:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-
Job.
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっているOK: (Print-仕事と同じ)であることで要求属性を全く代入もしませんでしたし、無視もしませんでした。うまくいっているOKは、属性を無視したか、または代入しました: Print仕事うまくいっている間違いない闘争属性と同じ: 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.
client-error-not-found: the target Printer and/or Job object does
not exist.
client-error-gone: the target Printer and/or Job object no longer
exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job, except
no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes and values MUST be
ignored.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
可能でないクライアント誤り: 要求は. Jobオブジェクト('完成される'か、'取り消される'か、または'中止される')の州かシステムの事情による運ばれたアウトが誤りが当たらなかったクライアントであったならそうすることができません: 目標Printer、そして/または、Jobオブジェクトが存在していない、クライアント誤り過ぎ去る、: 目標Printer、そして/または、Jobオブジェクトはもう存在していません、そして、フォーワーディング・アドレスは全く知られていません。クライアント誤りは大き過ぎる状態で実体を要求します: Print-仕事と同じであることで、どんなドキュメント以外にも、データはかかわりません。クライアント誤りはサポートされなかった書式を記録します: 適切でない. 属性か値がサポートしなかったクライアント誤り: 適切でないことで、サポートされない操作以来、属性と値を無視しなければならない、クライアント誤り闘争属性: Print-仕事と同じであることで、Printerが「プリンタは受諾仕事している」以外に、属性がかかわりません。
Hastings & Manros Informational [Page 44] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[44ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
server-error-operation-not-supported: not applicable (Cancel-Job
is REQUIRED).
server-error-device-error: same as Print-Job, except no document
data is involved.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
操作がサポートしなかったサーバ誤り: 適切でない、(キャンセル仕事はREQUIREDです) . サーバ誤りデバイス誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データがかかわらない、サーバの誤りの一時的な誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データがかかわらない、仕事を受け入れないサーバ誤り: 適切でない. サーバ誤り仕事は中止されました: 適切でない。
2.3.2.4 Get-Job-Attributes
2.3.2.4 仕事の属性を得てください。
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Get-Job-Attributes with the following specializations and differences. See Section 14 for a more complete description of each status code.
コードがセクション3.2.1で説明したPrint-地位の.2Print-仕事のResponseのすべてが以下の専門化と違いでGet仕事の属性に適切です。 それぞれのステータスコードの、より完全な記述に関してセクション14を見てください。
For the following success status codes, the requested attributes are returned in Group 3 in the response:
以下の成功ステータスコードにおいて、要求された属性はGroup3で応答で返されます:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were
unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-
Job, except the "requested-attributes" operation attribute MAY,
but NEED NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
うまくいっているOK: 要求属性を全く代入しなかったか、または(Print-仕事と同じ)であることで無視された、要求されなかった属性はサポートされなかったです。うまくいっているOKは、属性を無視したか、または代入しました: NOTを必要として、「要求された属性」操作属性以外のPrint仕事がそうするかもしれないのと同じであることで、サポートされない値と共に返してください、うまくいっている間違いない闘争属性: 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.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable.
client-error-uri-scheme-not-supported: not applicable.
client-error-conflicting-attributes: not applicable
server-error-operation-not-supported: not applicable (since Get-
Job-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no document
data is involved.
server-error-temporary-error: sane as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable. server-error-
job-canceled: not applicable.
可能でないクライアント誤り: Print-仕事と同じであることで、さらに、Printerオブジェクトはどんな要求も受け入れていません。クライアント誤りはサポートされなかった書式を記録します: 適切でない. 属性か値がサポートしなかったクライアント誤り: 適切でない. uri体系がサポートしなかったクライアント誤り: 適切でない. クライアント誤り闘争属性: 操作がサポートしなかったどんな適切なサーバ誤りも: 適切でない、(Get以来賃仕事の属性であることは、REQUIREDです) . サーバ誤りデバイス誤り: Print-仕事と同じであることで、どんなドキュメント以外にも、データがかかわらない、サーバの誤りの一時的な誤り: Print-仕事として気が確かであることで、どんなドキュメント以外にも、データがかかわらない、仕事を受け入れないサーバ誤り: 適切でない. サーバ誤り仕事で取り消される: 適切でない。
Hastings & Manros Informational [Page 45] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[45ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.4 Validate-Job
2.4、仕事を有効にします。
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によって受け入れられるか否かに関係なく。
2.5 Case Sensitivity in URIs
2.5 URIにおけるケース感度
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 [RFC2068]. See these specifications for rules of matching, comparison, and case- sensitivity.
IPP仕様がURIにおける少しの制限もしない理由は、RFC2396やHTTP/1.1の仕様[RFC2068]のように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を持たないでください。
The HTTP/1.1 specification [RFC2068] contains more details on comparing URLs.
HTTP/1.1仕様[RFC2068]はURLを比較することに関するその他の詳細を含んでいます。
2.6 Character Sets, natural languages, and internationalization
2.6 文字コード、自然言語、および国際化
This section discusses character set support, natural language support and internationalization.
このセクションは文字集合サポート、自然言語サポート、および国際化について論じます。
2.6.1 Character set code conversion support
2.6.1 文字集合コード変換サポート
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and indicate that UTF-8 and US-ASCII are supported by populating the
IPPクライアントとIPPオブジェクトはUTF-8をサポートするREQUIREDです。 彼らは追加charsetsをサポートするかもしれません。 また、IPPオブジェクトが米国-ASCIIをサポートするのは、RECOMMENDEDです、多くのクライアントが、米国-ASCIIをサポートして、UTF-8と米国-ASCIIが居住することによってサポートされるのを示すので
Hastings & Manros Informational [Page 46] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[46ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An IPP object is required to code covert with as little loss as possible between the charsets that it supports, as indicated in the Printer's "charsets-supported" attribute.
そして、プリンタが'utf-8'で「charsetによってサポートされる」、'、私たち、-、ASCII、'値。 IPPオブジェクトが同じくらい小さい損失がそれがサポートするcharsetsの間で可能な状態でおおいをコード化するのに必要です、Printerの「charsetsによってサポートしている」属性にみられるように。
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 RFC2566 document (section 3.1.4.2), the value of the "attributes-charset" for the response of the second request must be "us-ascii" since that is the charset specified in the request. The "job-name" value, however, is in "utf-8" format. Should the request be rejected even though both "utf-8" and "us-ascii" charsets are supported by the server? or should the "job-name" value be converted to "us-ascii" and return "successful-ok-conflicting-attributes" (0x0002) as the status code?
RFC2566ドキュメント、(.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オブジェクトのコード変換によるよりむしろ、それが理解していないキャラクタを無駄にしてください。
Hastings & Manros Informational [Page 47] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[47ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.6.2 What charset to return when an unsupported charset is requested?
2.6.2 サポートされないcharsetが要求されているとき戻るどんなcharset?
Section 3.1.4.1 Request Operation attributes was clarified in November 1998 as follows:
セクション3.1 .4 .1 Request Operation属性は以下の1998年11月にはっきりさせられました:
All clients and IPP objects MUST support the 'utf-8' charset
[RFC2044] and MAY support additional charsets provided that they
are registered with IANA [IANA-CS]. If the Printer object does
not support the client supplied charset value, the Printer object
MUST reject the request, set the "attributes-charset" to 'utf-8'
in the response, and return the 'client-error-charset-not-
supported' status code and any 'text' or 'name' attributes using
the 'utf-8' charset.
すべてのクライアントとIPPオブジェクトは、'utf-8'がcharset[RFC2044]であるとサポートしなければならなくて、それらがIANA[IANA-CS]に登録されれば、追加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, [RFC2566] section 14.1.4.14 client-error-charset-not- supported (0x040D) was clarified in November 1998 as follows:
その上、[RFC2566]は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)。
2.6.3 Natural Language Override (NLO)
2.6.3 自然言語オーバーライド(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 'textWithoutLanguage' are the two 'text' forms. The 'nameWithoutLanguage" and ' nameWithLanguage are the two 'name' forms. If a receiver (IPP object or IPP client) supports an attribute with attribute syntax 'text', it MUST support both forms in a request and a response. A sender (IPP client or IPP object) MAY send either form for any such attribute. When a sender sends a WithoutLanguage form, the implicit natural language is specified in the "attributes-natural-language" operation attribute which all senders MUST include in every request and response.
属性という'テキスト'と'名前'には、それぞれ2つのフォームがあります。1つには、暗黙の自然言語があります、そして、もう片方には、明白な自然言語があります。 「'textWithoutLanguage'と'textWithoutLanguage'はフォーム'nameWithoutLanguage」と'nameWithLanguageは2歳であること'が命名する2'テキスト'です'は形成されます。受信機(IPPオブジェクトかIPPクライアント)が属性構文'テキスト'で属性をサポートするなら、それは、両方が要求におけるフォームと応答であるとサポートしなければなりません。 送付者(IPPクライアントかIPPが反対する)はどんなそのような属性のためにもどちらのフォームも送るかもしれません。 送付者がWithoutLanguageフォームを送ると、暗黙の自然言語はすべての送付者があらゆる要求と応答に含まなければならない「属性自然言語」操作属性で指定されます。
Hastings & Manros Informational [Page 48] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[48ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
When a sender sends a WithLanguage form, it MAY be different from the implicit natural language supplied by the sender or it MAY be the same. The receiver MUST treat either form equivalently.
送付者がWithLanguageフォームを送るとき、それが送付者によって供給された暗黙の自然言語と異なるかもしれませんか、またはそれは同じであるかもしれません。 受信機は同等にどちらのフォームも扱わなければなりません。
There is an implementation decision for senders, whether to always send the WithLanguage forms or use the WithoutLanguage form when the attribute's natural language is the same as the request or response. The former approach makes the sender implementation simpler. The latter approach is more efficient on the wire and allows inter- working with non-conforming receivers that fail to support the WithLanguage forms. As each approach have advantages, the choice is completely up to the implementer of the sender.
送付者、属性の自然言語が要求と同じであるときに、いつもWithLanguageフォームを送るか、WithoutLanguageフォームを使用するか、そして、または応答のための実装決定があります。 前のアプローチで、送付者実装は、より簡単になります。 後者のアプローチは、ワイヤでは、より効率的であり、WithLanguageフォームをサポートしない非の従う受信機で相互働くのを許容します。各アプローチはうま味があるように、選択が完全な送付者の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 response's "attributes- natural-language" operation attribute: (1) that requested by the requester, (2) the natural language of the job, or (3) the configured natural language of the IPP Printer, if the requested language is not supported by the IPP Printer.
IPP Printerは仕事の自然言語をコピーしなければなりません、すなわち、クライアントによって中に供給された「属性自然言語」操作属性の値、操作を作成してください、Job記述属性としてのJobオブジェクトに、クライアントがそれについて質問できるように。 Get仕事の属性応答を返す際に、IPPオブジェクトは応答の「属性自然言語」操作属性における3つの自然言語値の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 [RFC2566] contained a job-level natural language override (NLO) for the Get-Jobs response. A job-level (NLO) is an (unrequested) Job Attribute which then specified the implicit natural
[RFC2566]の早めの草稿はGet-ジョブス応答のための仕事レベル自然言語オーバーライド(NLO)を含みました。 仕事レベル(NLO)は内在している生まれつきの名手がその時指定した(非要求しました)仕事のAttributeです。
Hastings & Manros Informational [Page 49] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[49ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
language for any other WithoutLanguage job attributes returned in the response for that job. Interoperability testing of early implementations showed that no one was implementing the job-level NLO in Get-Job responses. So the job-level NLO was eliminated from the Get- Jobs response. This simplification makes all requests and responses consistent in that the implicit natural language for any WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute.
いかなる他のWithoutLanguage仕事の属性のための言語もその仕事のための応答で戻りました。 早めの実装の相互運用性テストは、だれもGet-仕事の応答で仕事の平らなNLOを実装していなかったのを示しました。 それで、仕事の平らなNLOはGet仕事の応答から排除されました。 この簡素化で、すべての要求と応答は、要求か応答の「属性自然言語」操作属性でどんなWithoutLanguage'テキスト'か'名前'フォームのための暗黙の自然言語もいつも供給するので、一貫するようになります。
2.7 The "queued-job-count" Printer Description attribute
2.7 「列に並ばせられた仕事のカウント」Printer記述属性
2.7.1 Why is "queued-job-count" RECOMMENDED?
2.7.1 「列に並ばせられた仕事のカウント」はなぜRECOMMENDEDですか?
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にするのは、感染でした。
2.7.2 Is "queued-job-count" a good measure of how busy a printer is?
2.7.2 「列に並ばせられた仕事のカウント」はプリンタがどれくらい忙しいかに関する良い測定ですか?
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.
「列に並ばせられた仕事のカウント」は仕事が持たれているとき、プリンタがどれくらい忙しいかに関する良い測定ではありません。 今後の登録は経験が、そのような属性(組み合わせ)がプリンタが本当にどれくらい忙しいかをすばやく示すのに必要であることを示すなら「保持された仕事のカウント」(または、「活発な仕事のカウント」)プリンタ記述属性を加えることであるかもしれません。
2.8 Sending empty attribute groups
2.8 送付の空の属性グループ
The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender not send an empty attribute group in a request or a response. However, they REQUIRE a receiver to accept an empty attribute group as equivalent to the omission of that group. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that is not supplying any Job Template attributes. Similarly, an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to be returned in a response.
送付者が空の属性を送らない[RFC2566]と[RFC2565]仕様RECOMMENDは要求か応答で分類します。 しかしながら、それら、空の属性グループがそのグループの省略に同等であると受け入れるREQUIRE a受信機。 したがって、クライアントSHOULDは完全にaのグループが作成するJob Template Attributesを省略します。どんなJob Template属性も供給するのではなく、作動。 同様に、応答で返されるどんなサポートされない属性もなければ、IPPオブジェクトSHOULDは空のUnsupported Attributesグループを省略します。
Hastings & Manros Informational [Page 50] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[50ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
The [RFC2565] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them equivalently. The term "receiver" means an IPP object for a request and a client for a response. The term "sender' means a client for a request and an IPP object for a response.
空の属性グループか省略された属性グループのどちらかを受け取って、同等に彼らを扱うことができる[RFC2565]仕様REQUIRES a受信機。 「受信機」という用語は要求のためのIPPオブジェクトと応答のためのクライアントを意味します。 '「送付者'という用語は要求のためのクライアントと応答のためのIPPオブジェクトを意味します」。
There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2565] contains the following paragraph:
返される属性が全くないとき、Get-ジョブスのための規則への例外があります。 [RFC2565]は以下のパラグラフを含んでいます:
The syntax allows an xxx-attributes-tag to be present when the
xxx-attribute-sequence that follows is empty. The syntax is
defined this way to allow for the response of Get-Jobs where no
attributes are returned for some job-objects. Although it is
RECOMMENDED that the sender not send an xxx-attributes-tag if
there are no attributes (except in the Get-Jobs response just
mentioned), the receiver MUST be able to decode such syntax.
従うxxx属性順序が空であるときに、構文は、xxx属性タグが現在であるのを許容します。 構文は、属性が全くいくつかの仕事オブジェクトのために返されないところでGet-ジョブスの応答を考慮するためにこの道と定義されます。 属性(ただ言及されたGet-ジョブス応答を除いた)が全くなければ送付者がxxx属性タグを送らないのが、RECOMMENDEDですが、受信機はそのような構文を解読できなければなりません。
2.9 Returning unsupported attributes in Get-Xxxx responses
2.9 Get-Xxxx応答における戻っているサポートされない属性
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です、クライアントが、要求されたというわけではないすべてが返されたのを知るように。
2.10 Returning job-state in Print-Job response
2.10 Print-仕事の応答における戻っている仕事状態
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
この問題はサーバへの地位の後部を提供しないデバイスに仕事を送るサーバとしてIPP Printerオブジェクトの実装を取りに上がります。サーバが仕事が首尾よく完了して、そうするべきであるのを合理的に確信しているなら、'完成される'ように仕事状態を返してください。 また、仕事がもういずれのデバイスにもないずっと後にサーバは「仕事の歴史」における仕事を保つことができます。 そして、ユーザ
Hastings & Manros Informational [Page 51] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[51ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
could query the server and see that the job was in the 'completed' state and completed as specified by the job's "time-at-completed" time which would be the same as the server submitted the job to the device.
サーバについて質問して、仕事が仕事のもので指定されるように'完成した'状態にあって、完成しているのを見ることができた、「完成されて、調節する、」 サーバと同じ時間はデバイスに仕事を提出しました。
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.
これらの代替手段のすべてがサーバとデバイスの実装によります。
2.11 Flow controlling the data portion of a Print-Job request
2.11 Print-仕事の要求のデータ部を制御する流れ
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.
Aはプリンタをポーズしました。(または、紙のアウト、ジャム、スプールスペース満またはバッファ領域満のため止まります、操作(TCP/IP層の)、クライアントがそうでないPrint賃仕事のそう. その結果Printerをすべてのドキュメントデータに送ることができるaに関するデータが望んでいるフロー制御が状態を変えるまで応答を返しませんようにということであるもの。
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をテストするためにテストスクリプトを書く際に、応答を予想しないようにスクリプトを書かなければなりません、プリンタがポーズされたなら、プリンタが再開されるまで、すべての可能な実装で働くために。
2.12 Multi-valued attributes
2.12 マルチ評価された属性
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
マルチ評価された属性のための属性構文は何ですか? 以来いくつかの属性が1つ以上のデータ型の「メディア」などの値をサポートする、「仕事の保持、」 「賃仕事のシート」のIPP意味論関連
Hastings & Manros Informational [Page 52] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[52ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
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日後のすべての属性値には、同じ属性のその後の価値のしるしとしてゼロ・レングス属性キーワードがあります。
2.13 Querying jobs with IPP that were submitted using other job
submission protocols
2.13 他のジョブ依頼プロトコルを使用することで提出されたIPPとの仕事について質問すること。
The following clarification was added to [RFC2566] section 8.5:
以下の明確化は[RFC2566]セクション8.5に追加されました:
8.5 Queries on jobs submitted using non-IPP protocols
仕事の8.5の質問が、非IPPプロトコルを使用することで提出されました。
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に加えた他のジョブ依頼プロトコルを使用することで仕事を受け入れることができるなら、そのような実装が、そのような「外国」の仕事が質問されるのを'未知'の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
is to allow users to query other users' jobs, then the foreign
jobs would also be visible to an end-user IPP client using Get-
Jobs and Get-Job-Attributes.
それが一層の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 & Manros Informational [Page 53] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[53ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
2.14 The 'none' value for empty sets
2.14 空集合のための'なにも'値
[RFC2566] states that the 'none' value should be used as the value of a 1SetOf when the set is empty. In most cases, sets that are potentially empty contain keywords so the keyword 'none' is used, but for the 3 finishings attributes, the values are enums and thus the empty set is represented by the enum 3. Currently there are no other attributes with 1SetOf values which can be empty and can contain values that are not keywords. This exception requires special code and is a potential place for bugs. It would have been better if we had chosen an out-of-band value, either "no-value" or some new value, such as 'none'. Since we didn't, implementations have to deal with the different representations of 'none', depending on the attribute syntax.
[RFC2566]は、セットが空であるときに、'なにも'値が1SetOfの値として使用されるべきであると述べます。 多くの場合、潜在的に空のセットは'なにも'というキーワードが使用されていますが、3つの仕上げ属性のためのキーワードを含んでいます、そして、値はenumsです、そして、その結果、空集合はenum3によって表されます。 現在、空である場合があり、キーワードでない値を含むことができる1SetOf値がある他の属性が全くありません。 この例外は、特別なコードを必要として、バグのための潜在的場所です。 私たちがバンドで出ている値を選んだなら、より良かったでしょうに、「値がありません」か何らかの新しい値のどちらか、'なにも'などのように。 私たちが対処しなかったので、属性構文によって、実装は'なにも'の異なった表現に対処しなければなりません。
2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?
2.15 ジョブスを得る、私、-仕事は'本当'、そして、および'要求しているユーザ名'と等しいですか?
In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute ' my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there to, and if it's not present what should the IPP printer do?
中、[RFC2566]セクション3.2 .6 .1 'ジョブスを得ているRequest'、属性であるなら私、-、仕事、'存在していて、TRUEに設定されて、'要求しているユーザ名'属性がそこにあるに違いない、それが存在していないならIPPプリンタがことをするはずである、--
[RFC2566] Section 8.3 describes the various cases of "requesting- user-name" being present or not for any operation. If the client does not supply a value for "requesting-user-name", the printer MUST assume that the client is supplying some anonymous name, such as "anonymous".
[RFC2566]セクション8.3はどんな操作のためにも存在しているのによる「ユーザ名を要求します」の様々なケースについて説明します。 クライアントが「要求しているユーザ名」に値を供給しないなら、プリンタは、クライアントが何らかの匿名の名前を提供していると仮定しなければなりません、「匿名であること」のように。
2.16 The "multiple-document-handling" Job Template attribute and support
of multiple document jobs
2.16 複数のドキュメント仕事の「複数のドキュメント処理」Job Template属性とサポート
ISSUE: IPP/1.0 is silent on which of the four effects an implementation would perform if it supports Create-Job, but does not support "multiple-document-handling".
以下を発行してください。 IPP/1.0はCreate-仕事をサポートするなら実装が4つの効果のどれを実行するだろうかに関して静かですが、「複数のドキュメント処理」をサポートしません。
A fix to IPP/1.0 would be to require implementing all four values of "multiple-document-handling" if Create-Job is supported at all. Or at least 'single-document-new-sheet' and 'separate-documents- uncollated-copies'. In any case, an implementation that supports Create-Job SHOULD also support "multiple-document-handling". Support for all four values is RECOMMENDED, but at least the 'single- document-new-sheet' and 'separate-documents-uncollated-copies' values, along with the "multiple-document-handling-default" indicating the default behavior and "multiple-document-handling- supported" values. If an implementation spools the data, it should also support the 'separate-documents-collated-copies' value as well.
IPP/1.0へのフィックスはCreate-仕事が少しでもサポートされるならすべての4つの値を実装するのを「複数のドキュメント処理」を要求するだろうことです。 少なくとも'単一のドキュメント新しいシート'と'別々のドキュメント非照合されたコピー'。 また、どんなケース、Create-仕事のSHOULDをサポートする実装ではも、「複数のドキュメント処理」をサポートしてください。 すべての4つの値のサポートはRECOMMENDEDですが、少なくとも'シングルは''そして、別々のドキュメントはコピーを非照合した'という新しいシートを記録している値です、デフォルトの振舞いと「複数のドキュメント取り扱いでサポートしている」値を示す「複数のドキュメント取り扱いデフォルト」と共に。 また、実装がデータをスプールするなら、それはまた、別々のドキュメントがコピーを照合している''価値をサポートするべきです。
Hastings & Manros Informational [Page 54] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[54ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
3 Encoding and Transport
3 コード化と輸送
This section discusses various aspects of IPP/1.0 Encoding and Transport [RFC2565].
このセクションはIPP/1.0EncodingとTransport[RFC2565]の種々相について論じます。
A server is not required to send a response until after it has received the client.s entire request. Hence, a client must not expect a response until after it has sent the entire request. However, we recommend that the server return a response as soon as possible if an error is detected while the client is still sending the data, rather than waiting until all of the data is received. Therefore, we also recommend that a client listen for an error response that an IPP server MAY send before it receives all the data. In this case a client, if chunking the data, can send a premature zero-length chunk to end the request before sending all the data (and so the client can keep the connection open for other requests, rather than closing it). If the request is blocked for some reason, a client MAY determine the reason by opening another connection to query the server using Get-Printer-Attributes.
サーバは、client.sの全体の要求を受け取った後まで応答を送るのに必要ではありません。 したがって、全体の要求を送った後までクライアントは応答を予想してはいけません。 しかしながら、私たちは、クライアントがデータのすべてが受け取られているまで待つよりまだむしろデータを送る間、誤りが検出されるならサーバができるだけ早く応答を返すことを勧めます。 したがって、また、私たちは、すべてのデータを受け取る前にクライアントがIPPサーバが送るかもしれない誤り応答の聞こうとすることを勧めます。 この場合分魂化であることでのクライアント、データ、すべてのデータを送る前に要求を終わらせるために時期尚早なゼロ・レングス塊を送ることができます(クライアントがそれを閉じるよりむしろ他の要求において開くように接続を保つことができるように)。 要求がある理由で妨げられるなら、クライアントは、Getプリンタ属性を使用することでサーバについて質問するために別の接続を開くことによって、理由を決定するかもしれません。
In the following sections, there are a tables of all HTTP headers which describe their use in an IPP client or server. The following is an explanation of each column in these tables.
以下のセクションに、IPPクライアントかサーバにおける彼らの使用について説明するすべてのHTTPヘッダのテーブルがあります。↓これはこれらのテーブルのそれぞれのコラムに関する説明です。
- the .header. column contains the name of a header.
- the .request/client. column indicates whether a client sends the
header.
- the .request/ server. column indicates whether a server supports
the header when received.
- the .response/ server. column indicates whether a server sends
the header.
- the .response /client. column indicates whether a client
supports the header when received.
- the .values and conditions. column specifies the allowed header
values and the conditions for the header to be present in a
request/response.
- .headerコラムはヘッダーの名前を含んでいます。 - クライアントがヘッダーを送るか否かに関係なく. コラムが示す.request/クライアント。 - 受け取るとサーバがヘッダーを支えるか否かに関係なく. コラムが示す.request/サーバ。 - サーバがヘッダーを送るか否かに関係なく. コラムが示す.response/サーバ。 - 受け取るとクライアントがヘッダーを支えるか否かに関係なく. コラムが示す.response/クライアント。 - .values. コラムが許容ヘッダー値を指定するという条件、およびヘッダーが要求/応答で出席している条件。
The table for .request headers. does not have columns for responses, and the table for .response headers. does not have columns for requests.
応答のためにコラムを持って、.response headersのためにテーブルを持ってください。.requestヘッダーのためのテーブル. 要求のためのコラムは持っていません。
The following is an explanation of the values in the .request/client. and .response/ server. columns.
↓これは.requestの値に関する説明です。/クライアント.response/サーバコラム。
- must: the client or server MUST send the header,
- must-if: the client or server MUST send the header when the
condition described in the .values and conditions. column is
met,
- 必須: クライアントかサーバがヘッダーを送らなければなりません--、-、:でなければならない 状態であるときに、.valuesと状態で説明されて、クライアントかサーバがヘッダーを送らなければなりません。コラムは達成されます。
Hastings & Manros Informational [Page 55] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[55ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
- 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.
↓これは.responseの値に関する説明です。/クライアント.request/サーバコラム。
- must: the client or server MUST support the header,
- may: the client or server MAY support the header
- not: the client or server SHOULD NOT support the header. It is
not relevant to an IPP implementation.
- 必須: クライアントかサーバがヘッダーを支えなければなりません--、:であるかもしれない クライアントかサーバがヘッダーを支えるかもしれません--、: SHOULD NOTがヘッダーを支えるクライアントかサーバ。 それはIPP実装に関連していません。
3.1 General Headers
3.1 一般ヘッダー
The following is a table for the general headers.
↓これは一般的なヘッダーのためのテーブルです。
General- Request Response Values and Conditions Header
一般応答値と状態ヘッダーを要求してください。
Client Server Server Client
クライアントサーバサーバクライアント
Cache- must not must not .no-cache. only Control
.no-cacheキャッシュ必須必須Controlだけ
Connection must-if must must- must .close. only. Both
if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
接続、-、必須必須必須.close単になければならない。 ともにクライアントとサーバSHOULDが操作の系列の持続時間のための接続を保つなら。 クライアントとサーバはそのような系列で最後の操作のためのこのヘッダーを入れなければなりません。
Date may may must may per RFC 1123 [RFC1123]
from RFC 2068
[RFC2068]
日付がそうするかもしれない、必須はRFC2068からのRFC1123[RFC1123]単位でそうするかもしれません。[RFC2068]
Pragma must not must not .no-cache. only
Pragma必須必須.no-cache、唯一
Transfer- must-if must must- must .chunked. only .
Encoding if Header MUST be present
if Content-Length is
absent.
転送、-、必須必須は.chunkedを存在させなければならなくて. コード化だけがHeaderであるならContent-長さが欠けるなら存在していなければなりません。
Hastings & Manros Informational [Page 56] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[56ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Upgrade not not not not
アップグレード
Via not not not not
via
3.2 Request Headers
3.2 要求ヘッダー
The following is a table for the request headers.
↓これは要求ヘッダーのためのテーブルです。
Request-Header Client Server Request Values and Conditions
要求ヘッダークライアントサーバ要求値と状態
Accept may must .application/ipp. only. This
value is the default if the
必須.application/ippはそうするかもしれません。受諾、単に。 この値はデフォルトです。
Request-Header Client Server Request Values and Conditions
要求ヘッダークライアントサーバ要求値と状態
client omits it
クライアントはそれを省略します。
Accept-Charset not not Charset information is within
the application/ipp entity
Charsetを受け入れる、Charset情報はアプリケーション/ippな実体の中のそうです。
Accept-Encoding may must empty and per RFC 2068 [RFC2068]
and IANA registry for content-
codings
コード化を受け入れる、必須が、内容コーディングのために空になって、RFC2068[RFC2068]とIANA登録単位でそうしますように。
Accept-Language not not language information is within
the application/ipp entity
言語を受け入れる、言語情報はアプリケーション/ippな実体の中のそうです。
Authorization must-if must per RFC 2068. A client MUST send
this header when it receives a
401 .Unauthorized. response and
does not receive a .Proxy-
Authenticate. header.
承認、-、RFC2068単位でそうしなければなりません。 クライアントは、それが401.Unauthorizedを受けるこのヘッダーに. 応答を送らなければならなくて、.Proxyを受け取りません。. ヘッダーを認証してください。
From not not per RFC 2068. Because RFC
recommends sending this header
only with the user.s approval, it
is not very useful
RFC2068 RFCが、user.s承認だけがあるこのヘッダーを送ることを勧めるので、それはそれほど役に立ちません。
Host must must per RFC 2068
RFC2068あたりのホスト必須必須
If-Match not not
-合ってください。
If-Modified- not not Since
--以来変更されたなら
If-None-Match not not
なにも合っていません。
Hastings & Manros Informational [Page 57] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[57ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
If-Range not not
-及んでください。
If-Unmodified- not not Since
-、-以来、変更されていない。
Max-Forwards not not
前方へマックス
Proxy- must-if not per RFC 2068. A client MUST send
Authorization this header when it receives a
401 .Unauthorized. response and a
.Proxy-Authenticate. header.
まして、RFC2068あたりのプロキシ必須。 それがa401.Unauthorized応答とa.Proxy-Authenticateヘッダーを受けるとき、クライアントはこのヘッダーをAuthorizationに送らなければなりません。
Range not not
範囲
Referer not not
より多くのRefererにそうしません。
User-Agent not not
ユーザエージェント
3.3 Response Headers
3.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-if may per RFC 2068. When URI needs
redirection.
位置、-、RFC2068単位でそうしなければならないかもしれません。 URIがリダイレクションを必要とすると。
Proxy- not must per RFC 2068 Authenticate
どんなRFC2068あたりの必須も認証しないプロキシ
Public may may per RFC 2068
公衆がそうするかもしれない、RFC2068単位でそうするかもしれません。
Retry-After may may per RFC 2068
再試行した後がそうするかもしれない、RFC2068単位でそうするかもしれません。
Server not not
サーバ
Vary not not
異なる
Warning may may per RFC 2068
警告がそうするかもしれない、RFC2068単位でそうするかもしれません。
Hastings & Manros Informational [Page 58] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[58ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
WWW- must-if must per RFC 2068. When a server needs to Authenticate authenticate a client.
WWW、-、RFC2068単位でそうしなければなりません。 サーバであるときに、Authenticateにおける必要性はクライアントを認証します。
3.4 Entity Headers
3.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 2068 and IANA
Encoding registry for content
codings.
内容はRFC2068あたりの必須必須必須と満足しているコーディングのためのIANA Encoding登録がそうするかもしれません。
Content- not not not not Application/ipp Language handles language
内容Application/ipp Languageは言語を扱います。
Content- must-if must must-if must the length of the
Length message-body per RFC
2068. Header MUST be
present if Transfer-
内容、-、-、RFC2068あたりのLengthメッセージボディーの長さはそうしなければなりません。 ヘッダーはTransferであるなら出席しているに違いありません。
Entity-Header Request Response Values and Conditions
実体ヘッダー要求応答値と状態
Client Server Server Client
クライアントサーバサーバクライアント
Encoding is absent.
コード化は休んでいます。
Content- not not not not Location
内容位置
Content-MD5 may may may may per RFC 2068
内容-MD5がそうするかもしれない、RFC2068単位でそうするかもしれません。
Content-Range not not not not
満足している範囲
Content-Type must must must must .application/ipp.
only
コンテントタイプ必須必須必須必須.application/ipp単に
ETag not not not not
ETag
Expires not not not not
期限が切れる
Hastings & Manros Informational [Page 59] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[59ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Last-Modified not not not not
最終更新日
3.5 Optional support for HTTP/1.0
3.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 [RFC2565] requires that HTTP 1.1 MUST be supported by all clients and all servers. However, a client and/or a server implementation may choose to also support HTTP 1.0.
IPP実装はHTTP層とIPP層から成ります。 以下の議論では、「クライアント」という用語はHTTPクライアント層について言及します、そして、「サーバ」という用語はHTTPサーバ層について言及します。 EncodingとTransportは、すべてのクライアントとすべてのサーバでHTTP1.1をサポートしなければならないのが必要であると[RFC2565]記録します。 しかしながら、クライアント、そして/または、サーバ実装は、また、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をサポートするだけである(非従うこと)のサーバとコミュニケートするのを選ぶかもしれないことを意味します。 サーバが. 1.1要求、HTTPへのクライアントがそうするべきであるHTTP.unsupportedバージョン番号で反応するなら、そのような場合、HTTPバージョンNo.1.0を使用することで再試行してください。
3.6 HTTP/1.1 Chunking
3.6 HTTP/1.1分魂化
3.6.1 Disabling IPP Server Response Chunking
3.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.
サーバでこのメカニズムを使用して、分魂化からのクライアントに要求を無効にすることがないべきです、ドキュメントデータの分魂化がクライアントが長いドキュメントを送る重要な特徴であるので。
3.6.2 Warning About the Support of Chunked Requests
3.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 [HTTP] requires that conforming servers support chunked requests for any method. However, in spite of this requirement, some HTTP/1.1 implementations support chunked responses in the GET method, but do not support chunked POST method requests.
HTTP/1.1規格[HTTP]は、サーバサポートを従わせるとどんなメソッドを求める要求もchunkedされたのを必要とします。 しかしながら、この要件にもかかわらず、何らかのHTTP/1.1実装サポートは、GETメソッドで応答をchunkedしましたが、chunkedポストメソッドが要求であるとサポートしません。
Hastings & Manros Informational [Page 60] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[60ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or servlets [Servlet] require that the client supply a Content-Length. These implementations might reject a chunked POST method and return a 411 status code (Length Required), might attempt to buffer the request and run out of room returning a 413 status code (Request Entity Too Large), or might successfully accept the chunked request.
いくつかのHTTP/1.1の実装そのサポートCGIスクリプト[CGI]、そして/または、サーブレット[サーブレット]が、クライアントがContent-長さを供給するのを必要とします。 これらの実装は、chunkedポストメソッドを拒絶して、411ステータスコード(長さのRequired)を返すか、要求をバッファリングして、413ステータスコードを返す余地を使い果たすのを試みるか(Entity Too Largeを要求します)、または首尾よくchunked要求を受け入れるかもしれません。
Because of this lack of conformance of HTTP servers to the HTTP/1.1 standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP Printer object implementation support chunked requests and that conforming clients accept chunked responses. Therefore, IPP object implementers are warned to seek HTTP server implementations that support chunked POST requests in order to conform to the IPP standard and/or use implementation techniques that support chunked POST requests.
HTTP/1.1規格へのHTTPサーバの順応のこの不足のために、従っているIPP Printerオブジェクト実装がサポートするIPPの標準の[RFC2565]REQUIRESは要求をchunkedしました、そして、クライアントが受け入れるその従うのは応答をchunkedしました。 したがって、IPPオブジェクトimplementersは、IPP規格に従う、そして/または、chunkedポストの要求をサポートする実装のテクニックを使用するためにHTTPサーバ実装を求めるために、そのサポートがポストの要求をchunkedしたと警告されます。
4 References
4つの参照箇所
[CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface
Version 1.1 (CGI/1.1)", Work in Progress.
[CGI] 「WWW共通ゲートウェイインターフェイスバージョン1.1(CGI/1.1)」というCoar、K.、およびD.ロビンソンは進行中で働いています。
[HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「ハイパーテキストはプロトコルを何HTTP/1.1インチも移します、RFC2616、1999年6月。」
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
[RFC2569] エリオとR.とヘイスティングズとT.とジェイコブズとN.とJ.マーチン、「LPDとIPPプロトコルの間のマッピング」、RFC2569、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2566] deBryとR.とヘイスティングズとT.とエリオとR.とイサクソンとS.とP.パウエル、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2566、4月1999日
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
[RFC2565] エリオとR.とバトラーとS.とムーアとP.とR.チューナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[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月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2567] ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、1999年4月。
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、S.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
Hastings & Manros Informational [Page 61] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[61ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[RFC2068] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
[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月。
[Servlet] Servlet Specification Version 2.1
(http://java.sun.com/products/servlet/2.1/index.html).
[サーブレット]サーブレット仕様バージョン2.1( http://java.sun.com/products/servlet/2.1/index.html )。
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02),
November 1996.
[SSL]Netscape、SSLプロトコル、バージョン3、(テキストバージョン3.02)、1996年11月。
4.1 Authors' Addresses
4.1 作者のアドレス
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 Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
カール-宇野Manrosゼロックス社701の航空Blvd. エルセガンド、カリフォルニア 90245
EMail: manros@cp10.es.xerox.com
メール: manros@cp10.es.xerox.com
5 Security Considerations
5 セキュリティ問題
Security issues are discussed in sections 2.2, 2.3.1, and 8.5.
セクション2.2、2.3.1、および8.5で安全保障問題について議論します。
6 Notices
6つの通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それを表さない、それ
Hastings & Manros Informational [Page 62] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[62ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 [BCP-11]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
どんなそのような権利も特定するためにどんな取り組みも作りました。 BCP-11[BCP-11]で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Hastings & Manros Informational [Page 63] RFC 2639 IPP/1.0: Implementer's Guide July 1999
ヘイスティングズとManrosの情報[63ページ]のRFC2639IPP/1.0: Implementerのガイド1999年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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 & Manros Informational [Page 64]
ヘイスティングズとManros情報です。[64ページ]
一覧
スポンサーリンク
