Network Working Group R. Herriot
Request For Comments: 2569 Xerox Corporation
Category: Experimental N. Jacobs
Sun Microsystems, Inc.
T. Hastings
Xerox Corporation
J. Martin
Underscore, Inc.
April 1999
Mapping between LPD and IPP Protocols
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
IESG Note
IESG注意
This document defines an Experimental protocol for the Internet community. The IESG expects that a revised version of this protocol will be published as Proposed Standard protocol. The Proposed Standard, when published, is expected to change from the protocol defined in this memo. In particular, it is expected that the standards-track version of the protocol will incorporate strong authentication and privacy features, and that an "ipp:" URL type will be defined which supports those security measures. Other changes to the protocol are also possible. Implementors are warned that future versions of this protocol may not interoperate with the version of IPP defined in this document, or if they do interoperate, that some protocol features may not be available.
この文書は、インターネットコミュニティのための実験プロトコルを定義します。 IESGはこのプロトコルの改訂版が提案されている標準的なプロトコルとして公開されることを期待しています。標準化提案は、公表されたときに、このメモで定義されたプロトコルから変更することが期待されています。 URLタイプは、これらのセキュリティ対策をサポートする定義されます。特に、プロトコルの標準トラックバージョンは強力な認証とプライバシー機能を組み込み、「IPP」ということが期待されます。プロトコルに対するその他の変更も可能です。実装者はこのプロトコルの将来のバージョンでは、この文書で定義されたIPPのバージョンとの相互運用性はありませかもしれないと警告している、またはそれらが相互運用しなければ、一部のプロトコル機能は利用できない可能性があること。
The IESG encourages experimentation with this protocol, especially in combination with Transport Layer Security (TLS) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP.
IESGは、TLSが有効IPPのセキュリティ層として使用することができる方法を決定するために役立つ、特にトランスポート層セキュリティ（TLS）[RFC 2246]との組み合わせで、このプロトコルを用いて実験を奨励します。
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 gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified in RFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP.
この文書は、一緒に新しいインターネット印刷プロトコル（IPP）のすべての側面を記述した文書のセットの1つです。 IPPは、インターネットツールと技術を使用して、分散印刷のために使用することができるアプリケーションレベルのプロトコルです。この文書では、IPPとLPD（ラインプリンタデーモン）の間のゲートウェイの実装にいくつかのアドバイスを提供します。この文書では、（1）のコマンドとオペランド「ラインプリンタデーモン（LPD）は議定書RFC 1179で指定され、（2）の操作、操作属性とインターネット印刷プロトコル/ 1.0（IPPのジョブテンプレート属性の間のマッピングを記述する）。このドキュメントの目的の一つは、2つのプロトコルの機能を比較することです。もう一つの目的は、LPDとIPPの間のゲートウェイの実装を容易にすることです。
WARNING: RFC 1179 was not on the IETF standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementers.
警告：RFC 1179は、IETF標準化過程の上ではなかったです。 RFC 1179は、既存の練習を記録することを意図していたが、それは一部の地域では及びませんでした。しかし、RFC 1179の（1）実際の現在の慣行及び（2）IPPの間に、本明細書マップ。この文書では、多くの実装者によって行われてきたLPDプロトコルへの多数の発散の拡張機能をマッピングしようとしません。
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] Internet Printing Protocol/1.0: Implementors Guide [ipp-iig] Mapping between LPD and IPP Protocols (this document)
以下のための構造とモデルとプロトコルのためのインターネット印刷プロトコル[RFC2567]原理の設計目標インターネット印刷プロトコル[RFC2568]インターネット印刷プロトコル/ 1.0：モデルと意味論[RFC2566]インターネット印刷プロトコル/ 1.0：コード化と輸送[RFC2565]インターネット印刷プロトコル/ 1.0：LPDとIPPプロトコル間の実装者ガイド[IPP-IIG]マッピング（本書）
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
文書、「インターネット印刷プロトコルの設計目標は、」分散印刷機能で幅広い見てみると、それはインターネットのための印刷プロトコルに含まれる必要な機能を明確にするために役立つ実際のシナリオを列挙します。エンドユーザー、オペレータ、および管理者：これは、ユーザーの3種類の要件を識別します。これは、IPP / 1.0で満たされているエンドユーザーの要求のサブセットを呼び出します。オペレータと管理者の要件は、バージョン1.0の範囲外です。
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.
文書、「インターネット印刷プロトコルのための構造とモデルとプロトコルのための理論的根拠は、」高レベルのビューからIPPを説明し、IPP仕様のスイートを構成する様々な文書のためのロードマップを定義し、IETFの背景や根拠を与えますワーキンググループの主要な決定。
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job object. The Job object supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
文書、「インターネット印刷プロトコル/ 1.0：モデルとセマンティクス」、抽象オブジェクト、その属性、およびその操作で単純化したモデルを説明しています。これは、プリンタとジョブオブジェクトを紹介します。ジョブオブジェクトは、ジョブごとに複数のドキュメントをサポートしています。また、セキュリティ、国際化、およびディレクトリ問題に対処します。
The document, "Internet Printing Protocol/1.0: Encoding and Transport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called ' application/ipp'.
文書、「インターネット印刷プロトコル/ 1.0：コード化と輸送」は、HTTP / 1.1にモデル文書で定義された抽象操作と属性の正式なマッピングです。それはアプリケーション/ IPP 'と呼ばれる新しいインターネットメディアタイプの符号化規則を定義します。
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
この文書で「インターネット印刷プロトコル/ 1.0：インプリメンターズ・ガイド」、IPPクライアントとIPPオブジェクトの実装者に助言を与えます。
TABLE OF CONTENTS
目次
1. Introduction.....................................................4
2. Terminology......................................................5
3. Mapping from LPD Commands to IPP Operations......................5
3.1 Print any waiting jobs..........................................6
3.2 Receive a printer job...........................................6
3.2.1 Abort job.....................................................7
3.2.2 Receive control file..........................................7
3.2.3 Receive data file.............................................8
3.3 Send queue state (short)........................................8
3.4 Send queue state (long)........................................10
3.5 Remove jobs....................................................12
4. Mapping of LPD Control File Lines to IPP Operation and Job
Template Attributes.............................................13
4.1 Required Job Functions.........................................13
4.2 Optional Job Functions.........................................14
4.3 Required Document Functions....................................14
4.4 Recommended Document Functions.................................16
5. Mapping from IPP operations to LPD commands.....................16
5.1 Print-Job......................................................16
5.2 Print-URI......................................................18
5.3 Validate-Job...................................................18
5.4 Create-Job.....................................................18
5.5 Send-Document..................................................18
5.6 Send-URI.......................................................18
5.7 Cancel-Job.....................................................18
5.8 Get-Printer-Attributes.........................................19
5.9 Get-Job-Attributes.............................................19
5.10 Get-Jobs......................................................20
6. Mapping of IPP Attributes to LPD Control File Lines.............20
6.1 Required Job Functions.........................................21
6.2 Optional Job Functions.........................................21
6.3 Required Document Functions....................................22
7. Security Considerations.........................................23
8. References......................................................23
9. Authors' Addresses..............................................24
10.Appendix A: ABNF Syntax for response of Send-queue-state (short)25
11.Appendix B: ABNF Syntax for response of Send-queue-state (long) 26
12.Appendix C: Unsupported LPD functions...........................27
13.Full Copyright Statement........................................28
The reader of this specification is expected to be familiar with the IPP Model and Semantics specification [RFC2566], the IPP Encoding and Transport [RF2565], and the Line Printer Daemon (LPD) protocol specification [RFC1179] as described in RFC 1179.
本明細書の読者は、RFC 1179に記載されているようにIPPモデル及びセマンティクス仕様[RFC2566]、IPP符号化およびトランスポート[RF2565]、およびラインプリンタデーモン（LPD）プロトコル仕様[RFC1179]に精通していることが期待されます。
RFC 1179 was written in 1990 in an attempt to document existing LPD protocol implementations. Since then, a number of undocumented extensions have been made by vendors to support functionality specific to their printing solutions. All of these extensions consist of additional control file commands. This document does not address any of these vendor extensions. Rather it addresses existing practice within the context of the features described by RFC 1179. Deviations of existing practice from RFC 1179 are so indicated.
RFC 1179は、既存のLPDプロトコルの実装を文書化する試みで、1990年に書かれました。それ以来、文書化されていない拡張子の数は、彼らの印刷ソリューションに固有の機能をサポートするために、ベンダーによって行われています。これらの拡張機能のすべては、追加の制御ファイルのコマンドで構成されています。この文書では、これらのベンダー拡張のいずれかに対応していません。むしろそれは、RFC 1179から既存の練習のRFC 1179偏差によって記載された特徴のコンテキスト内で既存の実務に対処するように示されています。
Other LPD control file commands in RFC 1179 are obsolete. They are intended to work on "text" only formats and are inappropriate for many contemporary document formats that completely specify each page. This document does not address the support of these obsolete features.
RFC 1179の他のLPD制御ファイルのコマンドが廃止されました。彼らは、「テキスト」のみの形式で作業することを意図しており、完全に各ページを指定して、多くの現代的な文書フォーマットに対して不適切なされています。この文書では、これらの時代遅れの機能のサポートに対応していません。
In the area of document formats, also known as page description languages (PDL), RFC 1179 defines a fixed set with no capability for extension. Consequently, some new PDL's are not supported, and some of those that are supported are sufficiently unimportant now that they have not been registered for use with the Printer MIB [RFC1759] and IPP [RFC2566] [RFC2565], though they could be registered if desired. See the Printer MIB specification [RFC1759] and/or the IPP Model specification [RFC2566] for instructions for registration of document-formats with IANA. IANA lists the registered document-formats as "printer languages".
また、ページ記述言語（PDL）として知られているドキュメントフォーマットの領域では、RFC 1179には、拡張のためのない能力を有する固定されたセットを定義します。その結果、いくつかの新しいPDLのがサポートされておらず、サポートされているもののいくつかは、彼らがあれば登録することができたものの、彼らは、プリンタMIB [RFC1759]とIPP [RFC2566] [RFC2565]で使用するために登録されていないことを今、十分に重要ではありません希望。 IANAでのドキュメントフォーマットの登録のための手順については、プリンタMIB仕様[RFC1759]および/またはIPPモデル仕様[RFC2566]を参照してください。 IANAは、「プリンタ言語」として登録したドキュメント形式を示しています。
This document addresses the protocol mapping for both directions: mapping of the LPD protocol to the IPP protocol and mapping of the IPP protocol to the LPD protocol. The former is called the "LPD-to-IPP mapper" and the latter is called the "IPP-to-LPD mapper".
LPDプロトコルへのIPPプロトコルのIPPプロトコルおよびマッピングにLPDプロトコルのマッピング：この文書では、両方向のためのプロトコルマッピングに対応しています。前者は、「LPDツーIPPマッパ」と呼ばれ、後者は、「IPP対LPDマッパ」と呼ばれます。
This document is an informational document that is not on the standards track. It is intended to help implementers of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP.
この文書では、標準化過程の上ではない情報のドキュメントです。 IPPとLPDの間のゲートウェイの実装を支援するためのものです。また、IPPへの追加の洞察力を与える例を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
RFC 1179 uses the word "command" in two contexts: for over-the-wire operations and for command file functions. This document SHALL use the word "command" for the former and the phrase "functions" for the latter. The syntax of the LPD commands is given using ABNF [RFC2234].
RFC 1179は、二つの文脈で単語「コマンド」を使用していますオーバーザワイヤ操作のために、コマンドファイル機能に。この文書では、前者と後者のためのフレーズ「機能」のための言葉「コマンド」を使用しなければなりません。 LPDコマンドの構文は、ABNF [RFC2234]を用いて説明します。
The following tokens are used in order to make the syntax more readable:
次のトークンは、構文がより読みやすくするために使用されます。
LF stands for %x0A (linefeed) SP stands for %x20. (space) DIGIT stands for %x30-39 ("0" to "9")
LFは、SPは％X20の略％のX0A（改行）の略です。 （スペース）DIGITは％x30-39を表し（ "0" 〜 "9"）
This section describes the mapping from LPD commands to IPP operations. Each of the following sub-sections appear as sub-sections of section 5 of RFC 1179.
このセクションでは、IPP操作にLPDコマンドからのマッピングを説明しています。次のサブセクションの各々は、RFC 1179のセクション5のサブセクションとして現れます。
The following table summarizes the IPP operation that the mapper uses when it receives an LPD command. Each section below gives more detail:
次の表は、LPDコマンドを受信したときに、マッパーが使用するIPP操作をまとめたもの。各セクションは、以下に詳細を与えます：
LPD command IPP operation
LPDコマンドIPP操作
print-any-waiting-jobs ignore receive-a-printer-job Print-Job or Create-Job/Send-Document send queue state Get-Printer-Attributes and Get-Jobs (short or long) remove-jobs Cancel-Job
印刷任意の-待ちのジョブがキュー状態のGet-プリンタ-属性を送信し、（短期または長期） - ジョブズゲット受信-プリンタジョブの印刷ジョブ無視したり、ジョブの作成/送信-文書削除 - ジョブはキャンセル、ジョブの
Command syntax:
コマンド構文：
print-waiting-jobs = %x01 printer-name LF
OF印刷待ちのジョブが=％X01のプリンタ名
This command causes the LPD daemon check its queue and print any waiting jobs. An IPP printer handles waiting jobs without such a nudge.
このコマンドは、LPDデーモンがそのキューをチェックし、すべての待機中のジョブを印刷する原因となります。 IPPプリンタは、このようなナッジせずにジョブを待って処理します。
If the mapper receives this LPD command, it SHALL ignore it and send no IPP operation.
マッパーは、このLPDコマンドを受信した場合、それを無視して何のIPP操作を送信しないものとします。
Command syntax:
コマンド構文：
receive-job = %x02 printer-name LF
OF受信ジョブ=％のX02のプリンタ名
The control file and data files mentioned in the following paragraphs are received via LPD sub-commands that follow this command. Their mapping to IPP commands and attributes is described later in this section.
以下の段落で述べた制御ファイルとデータファイルは、このコマンドに続くLPDサブコマンドを介して受信されています。 IPPへのマッピングは、コマンドと属性は、このセクションで後述します。
The mapper maps the 'Receive a printer job' command to either:
マッパーは、どちらかに「プリンタジョブを受信」コマンドをマッピングします。
- the Print-Job operation which includes a single data file or - the Create-Job operation followed by one Send-Document operation for each data file.
各データファイルに対して1つの送信、文書操作に続いて作成・ジョブの操作 - - 1つのデータファイルまたはを含んで印刷ジョブ操作。
If the IPP printer supports both Create-Job and Send-Document, and if a job consists of:
IPPプリンタはサポートされている場合は、ジョブの作成および送信-ドキュメント、およびジョブがで構成されている場合は、両方：
- a single data file, the mapper SHOULD use the Print-Job operation, but MAY use the Create-Job and Send-Document operations. - more than one data file, the mapper SHALL use Create-Job followed by one Send-Document for each received LPD data file.
- 1つのデータファイル、マッパーは、印刷ジョブ操作を使用する必要がありますが、-ジョブの作成と送信 - ドキュメント操作を使用するかもしれません。 - マッパーが使用しなければならない複数のデータファイルは、作成・ジョブを1つの送信、文書が続くそれぞれのLPDデータファイルを受け取りました。
If the IPP printer does not support both Create-Job and Send-Document, and if a job consists of:
：IPPプリンタは、ジョブの作成および送信-ドキュメント、およびジョブがで構成されている場合の両方をサポートしていない場合
- a single data file, the mapper SHALL use the PrintJob operation. - more than one data file, the mapper SHALL submit each received LPD data file as a separate Print-Job operation (thereby converting a single LPD job into multiple IPP jobs).
- 1つのデータファイルは、マッパーは、PrintJobの操作を使用しなければなりません。 - 1つのデータファイルよりも、マッパーは、それぞれ別々の印刷ジョブ操作（これにより、複数のIPPジョブに単一のLPDジョブを変換）のようなLPDデータファイルを受信し提出しなければなりません。
If the mapper uses Create-Job and Send-Document, it MUST send the Create-Job operation before it sends any Send-Document operations whether the LPD control file, which supplies attributes for Create-Job, arrives before or after all LPD data files.
それが作成・ジョブのための属性を提供するLPD制御ファイル、かどうかを任意の送信、文書の操作を送信する前に、マッパーは、ジョブの作成および送信-ドキュメントを使用している場合、それが作成・ジョブの操作を送らなければなりません、すべてのLPDデータファイルの前または後に到着。
NOTE: This specification does not specify how the mapper maps: the LPD Printer-name operand to the IPP "printer-uri" operation attribute.
注：IPP「プリンタ-URI」操作属性にLPDプリンタ名オペランド：この仕様は、どのようにマッパーマップを指定していません。
The following three sub-sections gives further details about the mapping from LPD receive-a-printer-job sub-commands. Each of the following subsections appear as sub-sections of section 6 of RFC 1179.
次の三つのサブセクションでは、LPD受信-プリンタジョブをサブコマンドのマッピングについての更なる詳細を提供します。以下のサブセクションのそれぞれは、RFC 1179のセクション6のサブセクションとして表示されます。
Sub-command syntax:
サブコマンドの構文：
abort-job = %x1 LF
中止ジョブ=％×1 LF
This sub-command of receive-a-printer-job is intended to abort any job transfer in process.
受信プリンタジョブのこのサブコマンドは、プロセス内の任意のジョブの転送を中止することを意図しています。
If the mapper receives this sub-command, it SHALL cancel the job that it is in the process of transmitting.
マッパーは、このサブコマンドを受信した場合、それは、送信中であることを仕事を取り消さなければなりません。
If the mapper is in the process of sending a Print-Job or Create-Job operation, it terminates the job either by closing the connection, or performing the Cancel-Job operation with the job-uri that it received from the Print-Job or Create-Job operation.
マッパーは、印刷ジョブまたは作成し、ジョブの操作を送信するプロセスである場合は、接続を閉じる、またはジョブ-URIそれが印刷ジョブかから受信したことで、キャンセル・ジョブの操作を実行することにより、いずれかのジョブを終了し作成・ジョブの操作を。
NOTE: This sub-command is implied if at any time the connection between the LPD client and server is terminated before an entire print job has been transferred via an LPD Receive-a-printer-job request.
注：このサブコマンドは、全体の印刷ジョブがLPD受信-プリンタジョブを要求介して転送されてきた前の任意の時点でLPDクライアントとサーバー間の接続が終了した場合暗示されます。
Sub-command syntax:
サブコマンドの構文：
receive-control-file = %x2 number-of-bytes SP name-of-control-file LF number-of-bytes = 1*DIGIT name-of-control-file = "cfA" job-number client-host-name ; e.g. "cfA123woden" job-number = 3DIGIT client-host-name = <a host name>
受信制御ファイルを=％×2バイト数のSP名・オブ・コントロール・ファイルLFバイト数の= 1 * DIGIT名・オブ・コントロール・ファイル=「CFA」ジョブ番号クライアントのホスト名;例えば「cfA123woden」ジョブ番号= 3DIGITクライアントホスト名= <aホストname>
This sub-command is roughly equivalent to the IPP Create-Job operation.
このサブコマンドは、IPP作成・ジョブの操作とほぼ同等です。
The mapper SHALL use the contents of the received LPD control file to create IPP operation attribute and job template attribute values to transmit with the Print-Job or Create-Job operation.
マッパーは、IPP操作属性とジョブテンプレートを作成するために、受信したLPD制御ファイルの内容を使用しなければならない印刷ジョブまたは作成し、ジョブを操作して送信するために属性値。
Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
サブコマンドの構文：％×3バイト数のイン・データ・ファイル名・オブ・データ・ファイル
receive-data-file = %x03 number-of-bytes SP name-of-data-file LF number-of-bytes = 1*DIGIT name-of-data-file = "df" letter job-number client-host-name ; e.g. "dfA123woden for the first file letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z" ; first file is "A", ; second "B", and 52nd file is "z" job-number = 3DIGIT client-host-name = <a host name>
受信データファイルを=％のX03バイト数のSP名-のデータ・ファイルLFバイト数の= 1 * DIGIT名-のデータ・ファイル= "DF" の文字ジョブ数のクライアントホスト - 名前 ;例えば「dfA123wodenは、最初のファイルの文字=％x41-5A /％x61-7Aために、 "A" から "Z"、 "" から "Z; A" 最初のファイルである ""、2番目の "B"、および第52ファイル「Z」ジョブ番号= 3DIGITクライアントホスト名= <aホストname>です
This sub-command is roughly equivalent to the IPP Send-Document operation.
このサブコマンドは、IPP送る-ドキュメントの操作とほぼ同等です。
The mapper SHALL use the contents of the received LPD data file as the data to transmit with the IPP Print-Job or Send-Document operation.
マッパーは、IPP印刷ジョブを送信または送信し、文書操作をするためのデータとして受信LPDデータファイルの内容を使用しなければなりません。
Although RFC 1179 alludes to a method for passing an unspecified length data file by using an octet-count of zero, no implementations support this feature. The mapper SHALL reject a job that has a value of 0 in the number-of-bytes field.
RFC 1179は、ゼロのオクテットカウントを使用して、不特定の長さのデータファイルを渡すための方法を暗示するが、何の実装は、この機能をサポートしていません。マッパーは、数のバイトフィールドに0の値を有するジョブを拒否しなければなりません。
Command syntax:
コマンド構文：
send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF
送信キュー短=％のX03のプリンタ名*（SP（ユーザー名/ジョブ番号））の
The mapper's response to this command includes information about the printer and its jobs. RFC 1179 specifies neither the information nor the format of its response. This document requires the mapper to follow existing practice as specified in this document.
このコマンドにマッパーの応答は、プリンタとそのジョブに関する情報が含まれています。 RFC 1179は、情報もその応答の形式どちらを指定します。この文書は、本文書に指定されている既存の慣行に従うことマッパーが必要です。
The mapper SHALL produce a response in the following format which consists of a printer-status line optionally followed by a heading line, and a list of jobs. This format is defined by examples below. Appendix A contains the ABNF syntax.
マッパーは、必要に応じて見出し行に続いてプリンタステータスラインで構成され、以下の形式で応答し、ジョブのリストを作成しなければなりません。この形式は、以下の例により定義されます。付録Aは、ABNFの構文が含まれています。
For an printer with no jobs, the response starts in column 1 and is:
なしジョブとプリンタの場合、応答が列1で始まり、次のとおりです。
no entries
エントリありません
For a printer with jobs, an example of the response is:
ジョブとプリンタの場合、応答の例は次のとおりです。
killtree is ready and printing Rank Owner Job Files Total Size active fred 123 stuff 1204 bytes 1st smith 124 resume, foo 34576 bytes 2nd fred 125 more 99 bytes 3rd mary 126 mydoc 378 bytes 4th jones 127 statistics.ps 4567 bytes 5th fred 128 data.txt 9 bytes
killtreeは準備され、印刷ランクオーナージョブファイルの合計サイズアクティブフレッド123スタッフ1204バイト1スミス124レジューム、FOO 34576バイトの2フレッド125より99バイト3メアリー126がMyDoc 378バイト4ジョーンズ127 statistics.ps 4567バイトの5フレッド128のデータ。 9バイトのtxt
The column numbers of above headings and job entries are:
上記の見出しの列番号とジョブエントリは次のとおりです。
| | | | | 01 08 19 35 63
｜ ｜ ｜ ｜ ｜ ０１ ０８ １９ ３５ ６３
The mapper SHALL produce each field above from the following IPP attribute:
マッパーは、次のIPP属性から上記の各フィールドを生成しなければなりません。
LPD field IPP attribute special conversion details
LPDフィールドIPP特別な変換の詳細属性
printer- printer-state and For a printer-state of idle or status printer-state-reasons processing, the mapper SHALL use the formats above. For stopped, the mapper SHALL use printer-state-reasons to produce an unspecified format for the error. rank number-of- the mapper SHALL the format above intervening-jobs owner job-originating-user- unspecified conversion; job-name originating-user-name may be the mapper's user-name job job-id the mapper shall use the job-id files document-name the mapper shall create a comma separated list of the document-names and then truncate this list to the first 24 characters total- job-k- the mapper shall multiple the size octets*copies*1024 value of job-k-octets by 1024 and by the value of the "copies" attribute.
printer-プリンタ状態及びアイドル状態またはステータスプリンタ状態理由処理のプリンタ状態に関しては、マッパーは、上記のフォーマットを使用しなければなりません。停止のために、マッパーは、エラーのために指定されていない形式を生成するためにプリンタ状態理由を使用しなければなりません。ランク番号・オブ・マッパーが介在-ジョブ所有者ジョブ発信USER-未指定の変換上記フォーマットしなければなりません。ジョブ名由来のユーザー名は、マッパーは、マッパーは、文書名のカンマ区切りリストを作成し、このリストを切り捨てるものとする文書名ジョブIDファイルを使用しなければならないマッパーのユーザー名・ジョブ・ジョブIDを指定することも可能total-仕事-K-マッパーは、ジョブ-K-オクテットの倍数のサイズのオクテット*コピー* 1024値は1024と「コピー」属性の値によってはなら最初の24の文字。
A mapper SHOULD use the job attribute number-of-intervening-jobs rather than the job's position in a list of jobs to determine 'rank' because a Printer may omit jobs that it wants to keep secret. If a printer doesn't support the job attribute number-of-intervening-jobs, a mapper MAY use the job's position.
マッパーではなく、プリンタが、それは秘密にしておきたいことを仕事を省略することがあるので「ランク」を決定するジョブのリストでは、ジョブの位置よりもジョブ属性の数の-介在-ジョブを使用すべきです。プリンタがジョブ属性の数の-介在-の仕事をサポートしていない場合、マッパーは、ジョブの位置を使用するかもしれません。
Note: a Printer may set the value of job-originating-user-name to the authenticated user or to the value of "requesting-user-name", depending on the implementation and configuration. For a gateway, the authenticated user is the user-id of the gateway, but the "requesting-user-name" may contain the name of the user who is the gateway's client.
注：プリンタは、実装や構成に応じて、認証されたユーザまたは「要求ユーザー名」の値にジョブ発信ユーザー名の値を設定することができます。ゲートウェイの場合、認証されたユーザーは、ゲートウェイのユーザーIDですが、「要求ユーザー名は、」ゲートウェイのクライアントであるユーザーの名前が含まれていてもよいです。
In order to obtain the information specified above, The LPD-to-IPP mapper SHALL use the Get-Printer-Attributes operation to get printer-status and SHOULD use the Get-Jobs operation to get information about all of the jobs. If the LPD command contains job-numbers or user-names, the mapper MAY handle the filtering of the response. If the LPD command contains job-numbers but no user-names, the mapper MAY use Get-Job-Attributes on each converted job-number rather than Get-Jobs. If the LPD command contains a single user-name but no job-numbers, the mapper MAY use Get-Jobs with the my-jobs option if the server supports this option and if the server allows the client to be a proxy for the LPD user.
上記の指定された情報を得るためには、LPDツーIPPマッパーは、プリンタのステータスを取得するには、Get-プリンタ・属性操作を使用しなければならないし、すべてのジョブに関する情報を取得するには、Get-ジョブ操作を使用すべきです。 LPDコマンドは、ジョブ番号やユーザー名が含まれている場合は、マッパーは、応答のフィルタリングを処理することができます。 LPDコマンドは、ジョブ番号が、ノーユーザー名が含まれている場合は、マッパーは、各変換されたジョブ番号でGet-ジョブ・属性を使用するかもしれなく、ゲット・ジョブ。 LPDコマンドは、単一のユーザー名が、ノージョブ番号が含まれている場合、サーバーは、このオプションをサポートし、サーバが許可されている場合、クライアントはLPDのユーザのプロキシする場合は、マッパーがmy-ジョブオプションでは、Get-ジョブを使用するかもしれ。
NOTE: This specification does not define how the mapper maps the LPD Printer-name operand to the IPP "printer-uri" operation attribute.
注：この仕様は、マッパーはIPP「プリンタ-URI」操作属性にLPDプリンタ名オペランドをマップする方法を定義していません。
Command syntax:
コマンド構文：
send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
送信キュー長=％のX04のプリンタ名*（SP（ユーザー名/ジョブ番号））の
The mapper's response to this command includes information about the printer and its jobs. RFC 1179 specifies neither the information nor the format of its response. This document requires the mapper to follow existing practice as specified in this document.
このコマンドにマッパーの応答は、プリンタとそのジョブに関する情報が含まれています。 RFC 1179は、情報もその応答の形式どちらを指定します。この文書は、本文書に指定されている既存の慣行に従うことマッパーが必要です。
The mapper SHALL produce a response in the following format which consists of a printer-status line optionally followed a list of jobs, where each job consists of a blank line, a description line, and one line for each file. The description line contains the user-name, rank, job-number and host. This format is defined by examples below. Appendix B contain the ABNF syntax.
プリンタステータスラインで構成され、次の形式で応答を作成しなければならないマッパーは、必要に応じて、各ジョブは空白行、説明行、および各ファイルのための1つの行で構成されたジョブのリストを、続きます。記述行は、ユーザー名、ランク、ジョブ番号とホストが含まれています。この形式は、以下の例により定義されます。付録Bは、ABNFの構文が含まれています。
For an printer with no jobs the response is:
応答が無いジョブとプリンタの場合：
no entries
エントリありません
For a printer with jobs, an example of the response is:
ジョブとプリンタの場合、応答の例は次のとおりです。
killtree is ready and printing
killtreeは準備ができて、印刷され
fred: active [job 123 tiger] 2 copies of stuff 602 bytes
フレッド：アクティブ[ジョブ123虎]スタッフ602バイトの2つのコピー
smith: 1st [job 124 snail] 2 copies of resume 7088 bytes 2 copies of foo 10200 bytes
スミス：1 [ジョブ124カタツムリ]再開の2つのコピーFOOの7088のバイト2つのコピー10200のバイト
fred: 2nd [job 125 tiger] more 99 bytes
フレッド：2 [ジョブ125虎]以上99のバイト
The column numbers of above headings and job entries are:
上記の見出しの列番号とジョブエントリは次のとおりです。
| | | 01 09 41
｜ ｜ ｜ ０１ ０９ ４１
Although the format of the long form is different from the format of the short form, their fields are identical except for a) the copies and host fields which are only in the long form, and b) the "size" field contains the single copy size of each file. Thus the sum of the file sizes in the "size" field times the value of the "copies" field produces the value for the "Total Size" field in the short form. For fields other than the host and copies fields, see the preceding section. For the host field see the table below.
長い形態のフォーマットは、短い形式のフォーマットとは異なるが、それらのフィールドがコピーのみ長い形態であるホスト・フィールド）を除いて同一である、およびb）「サイズ」フィールドには、単一コピーを含みます各ファイルのサイズ。したがって、「サイズ」フィールドにファイルサイズの合計は、「コピー」フィールドの倍の値が短い形式で「合計サイズ」フィールドの値を生成します。ホストおよびコピー分野以外の分野については、前のセクションを参照してください。ホストフィールドの場合は下記の表を参照してください。
LPD field IPP attribute special conversion details
LPDフィールドIPP特別な変換の詳細属性
host unspecified conversion; job-originating-host may be the mapper's host copies copies the mapper shall assume the value of copies precedes the string "copies of "; otherwise, the value of copies is 1.
未指定の変換をホストします。ジョブ発信元ホストは、マッパーが先行し、文字列「のコピー」のコピーの値を負うマッパーのホストにコピーコピーであってもよく、そうでない場合は、コピーの値は1です。
NOTE: This specification does not define how the mapper maps the LPD Printer-name operand to the IPP printer-uri operation attribute.
注：この仕様は、マッパーは、IPPプリンタ-URI操作属性にLPDプリンタ名オペランドをマップする方法を定義していません。
Command syntax:
コマンド構文：
remove-jobs = %x05 printer-name SP agent *(SP(user-name / job-number)) LF
削除 - ジョブ=％のX05プリンタ名SPエージェント*（SP（ユーザー名/ジョブ番号））の
The agent operand is the user-name of the user initiating the remove-jobs command. The special user-name 'root' indicates a privileged user who can remove jobs whose user-name differs from the agent.
エージェント・オペランドは、remove-ジョブコマンドを開始したユーザーのユーザー名です。特別なユーザー名「ルートは」ユーザー名エージェントは異なったジョブを削除することができ特権ユーザを示しています。
The mapper SHALL issue one Cancel-Job operation for each job referenced by the remove-jobs command. Each job-number in the remove-jobs command references a single job. Each user-name in the remove-jobs command implicitly references all jobs owned by the specified user. The active job is implicitly referenced when the remove-jobs command contains neither job-numbers nor user-names. The mapper MAY use Get-Jobs to determine the job-uri of implicitly referenced jobs.
マッパーは、remove-ジョブコマンドで参照されるジョブごとに1キャンセル・ジョブの操作を発行しなければなりません。削除 - ジョブコマンド内の各ジョブ番号1つのジョブを参照します。削除・ジョブ内の各ユーザー名は、暗黙的に指定したユーザーが所有するすべてのジョブを参照するコマンド。削除 - ジョブコマンドは、ジョブ番号やユーザー名でもないが含まれている場合、アクティブなジョブは暗黙的に参照されます。マッパーは、ジョブ-URIの暗黙的に参照されたジョブを決定するには、Get-ジョブを使用するかもしれません。
The mapper SHALL not use the agent name of 'root' when end-users cancel their own jobs. Violation of this rule creates a potential security violation, and it may cause the printer to issue a notification that misleads a user into thinking that some other person canceled the job.
エンドユーザーが自分のジョブをキャンセルしたときに、マッパーは、「ルート」のエージェント名を使用してはなりません。このルールの違反は、潜在的なセキュリティ違反を作成し、それはいくつか他の人が仕事をキャンセルしたことを考えるにユーザーを誤解させる通知を発行するプリンタを引き起こす可能性があります。
If the agent of a remove-jobs command for a job J is the same as the user name specified with the 'P' function in the control file for job J, then the mapper SHALL ensure that the initiator of the Cancel-Job command for job J is the same as job-originating-user for job J.
削除 - ジョブのエージェントは、ジョブのコマンドならばJは、ジョブJの制御ファイルの「P」関数で指定したユーザ名と同じである場合、マッパーは確保しなければならないことキャンセル-JobコマンドのイニシエータのためのジョブJジョブJ.用ジョブ発信ユーザーと同じです
Note: This requirement means that a mapper must be consistent in who the receiver perceives as the initiator of IPP operations. The mapper either acts as itself or acts on behalf of another user. The latter is preferable if it is possible. This consistency is necessary between Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but it is also desirable for other operations. For example, Get-Jobs may give more information about job submitted by the initiator of this operation.
注：この要件は、マッパーが、受信機がIPP操作の開始剤として知覚する人に一致していなければならないことを意味します。マッパーは、それ自体として動作するか、別のユーザーの代わりに作用するのどちらか。後者は、それが可能であれば好ましいです。この一貫性は、印刷ジョブの間で必要である/ - ジョブの作成およびキャンセル・ジョブをキャンセルし、ジョブを機能させるために、それは他の操作のためにも望ましいです。たとえば、Get-ジョブズCEOは、この操作のイニシエータによって発行されたジョブに関する詳細な情報を与えることができます。
NOTE: This specification does not define how the mapper maps: (1) the LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to the IPP "job-uri".
注：この仕様はどのようにマッパーマップを定義していません：（1）LPDプリンタ名IPP「仕事-URI」をIPP「プリンタ-URI」または（2）LPDジョブ番号に。
NOTE: This specification does not specify how the mapper maps the LPD user-name to the IPP job-originating-user because the mapper may use its own user-name with jobs.
注：この仕様は、マッパーが仕事で、独自のユーザー名を使用することができますので、マッパーはIPPジョブ発信ユーザーにLPDのユーザー名をマップする方法を指定しません。
4. Mapping of LPD Control File Lines to IPP Operation and Job Template Attributes
IPP操作と仕事のテンプレート属性にLPD制御ファイルの行の4マッピング
This section describes the mapping from LPD control file lines (called 'functions') to IPP operation attributes and job template attributes. The mapper receives the control file lines via the LPD receive-control-file sub-command. Each of the LPD functions appear as sub-sections of section 7 of RFC 1179.
このセクションでは、IPP操作属性とジョブテンプレート属性に（「機能」と呼ばれる）LPD制御ファイルの行からのマッピングを説明しています。マッパーは、LPD受信制御ファイルのサブコマンドを介して、制御ファイルの行を受信します。 LPDの各機能は、RFC 1179のセクション7のサブセクションとして現れます。
In LPD control file lines, the text operands have a maximum length of 31 or 99 while IPP operation attribute and job template attribute values have a maximum of 255 or 1023 octets, depending on the attribute syntax. Therefore, no data is lost.
IPP操作属性とジョブテンプレートの属性値が属性構文に応じて、255または1023オクテットの最大を持っていながら、LPD制御ファイルの行では、テキストオペランドは、31または99の最大の長さを持っています。そのため、データは失われません。
The mapper converts each supported LPD function to its corresponding IPP operation or job template attribute as defined by tables in the subsections that follow. These subsections group functions according to whether they are:
以下のサブセクション内のテーブルによって定義されるようマッパは、対応するIPP操作またはジョブテンプレート属性にサポートされている各LPD関数に変換します。彼らはあるかどうかに応じて、これらのサブセクショングループ機能：
- required with a job, - optional with a job - required with each document.
- ジョブにオプション - - 各ドキュメントに必要なジョブ、と必要。
In the tables below, each LPD value is given a name, such as 'h'. If an IPP value uses the LPD value, then the IPP value column contains the LPD name, such as 'h' to denote this. Otherwise, the IPP value column specifies the literal value.
以下の表に、各LPDの値は、「H」として、名前を与えられています。 IPP値がLPDの値を使用する場合、IPP値欄は、これを示すために「H」として、LPDの名前を含んでいます。それ以外の場合は、IPP値の欄には、リテラル値を指定します。
The following LPD functions MUST be in a received LPD job. The mapper SHALL receive each of the following LPD functions and SHALL include the information as a operation or job template attribute with each IPP job. The functions SHOULD be in the order 'H', 'P' and they SHOULD be the first two functions in the control file, but they MAY be anywhere in the control file and in any order:
以下のLPDの機能は、受信LPDジョブでなければなりません。マッパーは、以下のLPDの機能のそれぞれを受けるものとし、各IPPジョブに操作またはジョブテンプレート属性などの情報を含まなければなりません。関数は、順番「H」、「P」であるべきであり、そして、彼らは、制御ファイル内の最初の2つの機能であるべきであるが、彼らはどこにでも制御ファイルに、任意の順序であってもよいです。
LPD function IPP name value description name value
LPD機能IPP名前値説明名前値
H h Originating Host h (in security layer) P u User identification requesting- u (and in security user-name layer) none ipp- 'true' attribute-fidelity
HのH（セキュリティ層内）ホストH発信P uはユーザ識別は、U（およびセキュリティでユーザ名層）なしIPP-「真」属性忠実requesting-
A mapper MAY send its own host rather than the client's host, and a mapper MAY send its own user-name as user identification rather than the client user. But in any case, the values sent SHALL be compatible with the Cancel-Job operation. The IPP operation MAY have no way to specify an originating host-name.
マッパーは、クライアントのホストではなく、独自のホストを送信することができ、そしてマッパーは、ユーザ識別ではなく、クライアントのユーザとして独自のユーザー名を送信することができます。しかし、どのような場合には、送信された値はキャンセル・ジョブの操作と互換性がなければなりません。 IPP操作は、元のホスト名を指定する方法を有していなくてもよいです。
The mapper SHALL include ipp-attribute-fidelity = true so that it doesn't have to determine which attributes a printer supports.
それは、プリンタがサポートする属性を決定する必要がないように、マッパーは、真のIPP属性-忠実=を含まなければなりません。
The following LPD functions MAY be present in a received job. These functions SHOULD follow the required job functions and precede the document functions, but they MAY be anywhere in the control file.
以下のLPDの機能は、受信したジョブに存在してもよいです。これらの機能は、必要なジョブ機能に従うと、ドキュメント機能の前に、彼らはどこにでも制御ファイルであってもよいべきです。
If the mapper receives such an LPD function, the mapper SHALL include the corresponding IPP attribute with the value converted as specified in the table below. If the mapper does not receive such an LPD attribute, the mapper SHALL NOT include the corresponding IPP attribute, except the 'L' LPD function whose absence has a special meaning as noted in the table.
マッパーは、LPD機能を受信した場合、マッピングは以下の表に指定されるように変換された値と、対応するIPP属性を含まなければなりません。マッパーは、このようなLPD属性を受信しない場合、マッパーは不在表に示すように特別な意味を持っている「L」LPD機能を除いて、対応するIPP属性が含まれないものとします。
LPD function IPP name value description name value
LPD機能IPP名前値説明名前値
J j Job name for job-name j banner page L l Print banner page job-sheets 'standard' if 'L' is present 'none' if 'L' is present M m Mail When Printed IPP has no notification mechanism. To support this LPD feature, the gateway must poll using the Get-Job-Attributes operation.
ジョブ名jのバナーページのLリットルを印刷バナーページジョブ・シート「標準」のためのJ Jジョブ名「L」は存在している場合は、「なし」「L」が存在M mのメールであればプリントIPPには通知メカニズムを持っていない場合。このLPD機能をサポートするために、ゲートウェイは、Get-ジョブ・属性操作を使用してポーリングする必要があります。
The mapper SHALL receive one set of the required document functions with each copy of a document, and SHALL include the converted information as operation or job template attributes with each IPP document.
マッパーは、ドキュメントの各コピーに必要なドキュメント機能の一組を受けるもの、及び操作またはジョブテンプレートは、各IPP文書に属性として変換された情報を含まなければなりません。
If the control file contains required and recommended document functions, the required functions SHOULD precede the recommended ones and if the job contains multiple documents, all the functions for each document are grouped together as shown in the example of section 6.3 "Required Document Functions". However, the document functions MAY be in any order.
制御ファイルが必要とドキュメント機能をお勧め含まれている場合は、必要な機能は、推奨のものを先行すべきジョブが複数のドキュメントが含まれている場合、セクション6.3「必要なドキュメントの機能」の例に示すように、各ドキュメントのすべての機能が一緒にグループ化されます。しかし、ドキュメント機能は、任意の順序であってもよいです。
LPD function IPP name value description name value
LPD機能IPP名前値説明名前値
f fff Print formatted document-format 'application/octet-file stream' l fff Print file leaving document-format 'application/octet-control characters stream' o fff Print Postscript document-format 'application/PostScri output file pt' copies see note
F FFF文書フォーマット残しフォーマットされた文書フォーマット「アプリケーション/オクテットファイルストリーム」LのFFFプリントファイルを印刷「アプリケーション/オクテットの制御文字をストリームO」FFF PostScriptドキュメント・フォーマットを印刷「アプリケーション/ PostScri出力ファイルPT」コピーはノートを参照してください
Note: In practice, the 'f' LPD function is often overloaded. It is often used with any format of document data including PostScript and PCL data.
注意：実際には、「F」LPD機能は、多くの場合、オーバーロードされます。それは、多くの場合、PostScriptおよびPCLデータを含む文書データのいずれかの形式で使用されています。
Note: In practice, the 'l' LPD function is often used as a rough equivalent to the 'f' function.
注：実際には、「L」LPD機能は、多くの場合、「F」機能に粗い等価物として使用されます。
Note: When RFC 1179 was written, no implementation supported the 'o' function; instead 'f' was used for PostScript. Windows NT now sends ' o' function for a PostScript file.
注意：RFC 1179が書かれたとき、何の実装は「O」機能をサポートしていません。代わりに、PostScriptのために使用された「F」。 Windows NTは、今のPostScriptファイルの「O」機能を送ります。
Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name of the data file as transferred, e.g. "dfA123woden".
注：「F」の値「FFF」、転送として「L」と「O」の機能は、データファイルの名前であり、例えば"dfA123woden"。
If the mapper receives any other lower case letter, the mapper SHALL reject the job because the document contains a format that the mapper does not support.
マッパーは、他の小文字を受信した場合、文書はマッパーがサポートされていないフォーマットが含まれているため、マッパーは、ジョブを拒否しなければなりません。
The mapper determines the number of copies by counting the number of occurrences of each 'fff' file with one of the lower-case functions above. For example, if 'f dfA123woden' occurs 4 times, then copies has a value of 4. Although the LPD protocol allows the value of copies to be different for each document, the commands and the receiving print systems don't support this.
マッパーは、上記下部ケースの機能の一つとそれぞれ「FFF」ファイルの出現回数をカウントすることによってコピー数を決定します。例えば、「dfA123woden F」4回発生した場合、LPDプロトコルはコピーの値は、各文書ごとに異なることを可能にするが、その後、コピーは4の値を有し、コマンド受信印刷システムはこれをサポートしていません。
The mapper SHOULD receive one set of the recommended document functions with each document, and SHOULD include the converted information as an operation or job template attribute with each IPP document. The functions SHOULD be received in the order 'U' and 'N', but they MAY arrive in any order.
マッパは、各文書に推奨文書関数の一組を受信する必要があり、各IPP文書に操作やジョブテンプレート属性として変換された情報を含むべきです。機能が順序「U」と「N」で受信されるべきであり、それらは任意の順序で到着するかもしれません。
LPD function IPP name value description name value
LPD機能IPP名前値説明名前値
U fff ignored N n Name of source file document-name n
Uは無視FFF N n個のソースファイル、ドキュメント名nの名前
Note: the value 'fff' of the 'U' function is the name of the data file as transferred, e.g. "dfA123woden".
注：「U」関数の値「FFF」は、データファイルの名前で転送されるように、例えば"dfA123woden"。
If the IPP-to-LPD mapper receives an IPP operation, the following table summarizes the LPD command that it uses. Each section below gives the detail. Each of the following sub-sections appear as sub-sections of section 3 in the document "Internet Printing Protocol/1.0: Model and Semantics" [RFC2566].
IPPツーLPDマッパーは、IPP操作を受信した場合、次の表では、それが使用するLPDコマンドをまとめたものです。各セクションには、以下に詳細を提供します。 [RFC2566]：以下のサブセクションでは、それぞれの文書「モデルとセマンティクスインターネット印刷プロトコル/ 1.0」のセクション3のサブセクションとして表示されます。
IPP operation LPD command
IPP操作LPDコマンド
Print-Job or Print-URI or receive-a-printer-job Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs Validate-Job implemented by the mapper Cancel-Job remove-jobs Get-Printer-Attributes, Get-Job- send queue state (short or long) Attributes or Get-Jobs
マッパーキャンセル・ジョブを削除し、ジョブによって実装され、印刷ジョブまたは印刷-URIまたは受信-プリンタジョブの作成・ジョブ/送信-ドキュメント/送信-URIと、その後印刷任意の-待ちジョブを検証し、仕事GET-プリンタの属性は、Get-Job-送信キューの状態（ショートまたはロング）属性または取得し、ジョブ
The mapper SHALL send the following commands in the order listed below:
マッパーは、下記の順序で次のコマンドを送信しなければなりません：
- receive-a-printer-job command - both receive-control-file sub-command and receive-data-file sub-command (unspecified order, see Note below) - print-any-waiting-jobs command, except that if the mapper is sending a sequence of receive a printer-job commands, it MAY omit sending print-any-waiting-jobs after any receive a printer-job command that is neither the first nor last command in this sequence
- コマンド - プリンタジョブ受信 - サブコマンド - 制御ファイルの受信およびサブコマンド・データ・ファイルを受信の両方（指定されていないため、下記の注意を参照） - 印刷 - 任意の-待ちのジョブがある場合以外は、コマンドマッパーは、プリンタ・ジョブコマンドを受信するシーケンスを送信している任意のは、このシーケンスの最初でも最後のコマンドでもないプリンタ・ジョブコマンドを受け取った後、それが印刷任意の-待ちのジョブを送信省略してもよい（MAY）
Note: it is recommended that the order of the receive-control-file subcommand and the receive-data-file sub-command be configurable because either order fails for some print systems. Some print systems assume that the control file follows all data files and start printing immediately on receipt of the control file. When such a print system tries to print a data file that has not arrived, it produces an error. Other print systems assume that the control file arrives before the data files and start printing when the first data file arrives. Such a system ignores the control information, such as banner page or copies.
注意：どちらの順序は、いくつかの印刷システムで失敗したので、受信制御ファイルのサブコマンドおよび受信データファイルサブコマンドの順序が設定可能にすることをお勧めします。いくつかの印刷システムでは、制御ファイルは、すべてのデータファイルをたどり、制御ファイルの受信時に、すぐに印刷を開始することを前提としています。そのような印刷システムが到着していないデータファイルを印刷しようとすると、エラーを生成します。他の印刷システムでは、制御ファイルは、データファイルの前に到着したことを想定し、最初のデータファイルが到着したときに印刷を開始します。このようなシステムは、このようなバナーページやコピーとして、制御情報を無視します。
NOTE: This specification does not define the mapping between the IPP printer-uri and the LPD printer-name.
注：この仕様は、IPPプリンタ-URIとLPDプリンタ名の間のマッピングを定義していません。
The mapper SHALL send the IPP operation attributes and job template attributes received from the operation to the LPD printer by using the LPD receive-control-file sub-command. The mapper SHALL create the LPD job-number for use in the control file name, but the receiving printer MAY, in some circumstances, assign a different job-number to the job. The mapper SHALL create the IPP job-id and IPP job-uri returned in the Print-Job response.
マッパーは、IPP操作属性とジョブテンプレート属性がLPD受信制御ファイルサブコマンドを使用してLPDプリンタに操作から受信送信しなければなりません。マッパーは、制御ファイル名で使用するためのLPDジョブ番号を作成するものとしますが、受信プリンタMAYは、いくつかの状況では、ジョブに別のジョブ番号を割り当てます。マッパーは、印刷ジョブの応答で返さIPPジョブ-idとIPPジョブ-URIを作成するものとします。
NOTE: This specification does not specify how the mapper determines the LPD job-number, the IPP job-id or the IPP job-uri of a job that it creates nor does it specify the relationship between the IPP job-uri, IPP the job-id and the LPD job-number, both of which the mapper creates. However, it is likely that the mapper will use the same integer value for both the LPD job-number and the IPP job-id, and that the IPP Job-uri is the printer's URI with the job-id concatenated on the end.
注：この仕様は、マッパーが仕事をし、それが作成したり、それは、IPPをIPPジョブ-URIとの間の関係を指定しないことLPDジョブ番号、IPPのジョブIDまたはジョブのIPPジョブ-URIを決定する方法を指定しません。 -id及びマッパーが作成どちらのLPDジョブ番号、。しかし、マッパーはLPDジョブ番号とIPPジョブ-idの両方に同じ整数値を使用して、IPPジョブ-URIが端に連結されたジョブIDとプリンタのURIであることをする可能性があります。
The mapper SHALL send data received in the IPP operation to the LPD printer by using the LPD receive-data-file sub-command. The mapper SHALL specify the exact number of bytes being transmitted in the number-of-bytes field of the receive-data-file sub-command. It SHALL NOT use a value of 0 in this field.
マッパーは、LPD受信データファイルサブコマンドを使用してLPDプリンタにIPP操作で受信したデータを送信しなければなりません。マッパーは、受信データファイルサブコマンドの数のバイトフィールドで送信されるバイトの正確な数を指定します。これは、このフィールドに0の値を使用してはなりません。
If the mapper, while it is transmitting a receive-a-printer-job command or sub-command, either detects that its IPP connection has closed or receives a Cancel-Job operation, the mapper SHALL terminate the LPD job either with the abort sub-command or the remove-jobs command.
それはいずれかのIPP接続が閉じられたことを検出またはキャンセルジョブ操作を受け付け、受信プリンタジョブのコマンドまたはサブコマンドを送信している間マッパーは、マッパーのいずれかアボートサブ有するLPDジョブを終了するものとした場合-commandまたは削除 - ジョブコマンド。
This document does not address error code conversion.
この文書では、エラーコード変換に対応していません。
The mapper SHALL handle this operation in the same way as a Print-Job operation except that it SHALL obtain data referenced by the "document-uri" operation attribute and SHALL then treat that data as if it had been received via a Print-Job operation.
マッパーは、「文書-URI」操作属性によって参照されるデータを得なければならないことを除いて、印刷ジョブの操作と同じように、この操作を取り扱うものとし、それが印刷ジョブの操作を介して受信されたかのようにそのデータを扱うものと。
The mapper SHALL perform this operation directly. Because LPD supports very few attributes, this operation doesn't have much to check.
マッパーは、直接この操作を実行しなければなりません。 LPDは非常にいくつかの属性をサポートしているため、この操作はチェックして多くを持っていません。
The mapper SHALL handle this operation like Print-Job, except:
マッパーは除いて、印刷ジョブのように、この操作を処理しなければなりません。
- the mapper SHALL send the control file after it has received the last Send-Document or Send-URI operation because the control file contains all the document-name and document-format values specified in the Send-Document and Send-URI operations. - the mapper SHALL perform one receive-data-file sub-command for each Send-Document or Send-URI operation received and in the same order received. - the mapper SHALL send the control file either before all data files or after all data files. (See the note in the section on Print-Job about the dilemma of sending the control file either before or after the data files.
- 制御ファイルは、すべての文書名や文書フォーマットの送信、文書で指定された値と送信-URI操作が含まれているため、それが最後の送信、ドキュメントまたは送信-URIを操作を受けた後マッパーは、制御ファイルを送信しなければなりません。 - マッパーはそれぞれ、ドキュメントを送信または送信-URIの操作を受け付け、受信した順序と同じ順序にするための1つが受信データファイルサブコマンドを実行しなければなりません。 - マッパーは、すべてのデータファイルの前に、またはすべてのデータファイルの後にいずれかの制御ファイルを送信しなければなりません。 （データファイルの前または後に、制御ファイルを送信するのジレンマについての印刷ジョブのセクションに注意を参照してください。
The mapper performs a receive-data-file sub-command on the received data. See the preceding section 5.4 "Create-Job" for the details.
マッパーは、受信したデータに受信データファイルサブコマンドを実行します。詳細については、前のセクション5.4「を作成し、ジョブを」を参照してください。
The mapper SHALL obtain the data referenced by the "document-uri" operation attribute, and SHALL then treat that data as if it had been received via a Send-Document operation. See the preceding section 5.5 "Send-Document" for the details.
マッパーは、「文書-URI」操作属性によって参照されるデータを得なければならない、そしてそれが送信・ドキュメントの操作を介して受信されたかのようにそのデータを扱うものとします。詳細については、前のセクション5.5「送信-ドキュメント」を参照してください。
The mapper SHALL perform a remove-jobs command with the following operation attributes:
マッパーは、remove-ジョブは、次の操作属性を指定したコマンドを実行しなければなりません。
- the printer is the one to which the job was submitted, that is the IPP printer-uri is mapped to an LPD printer-name by the same mechanism as for all commands - the agent is the authenticated user-name of the IPP client - the job-number is the job-id returned by the Print-Job command, that is, the LPD job-number has the same value as the IPP job-id for likely implementations
- エージェントはIPPクライアントの認証されたユーザ名である - プリンタは、プリンタ-uriのすべてのコマンドの場合と同じメカニズムでLPDプリンタ名にマッピングされているが、IPPで、ジョブが提出された先の一つです - ジョブ番号が印刷-Jobコマンドによって返されたジョブIDである、つまり、LPDジョブ数はおそらく実装のためのIPPジョブ-IDと同じ値を持ちます
LPD severely limits the set of attributes that the mapper is able to return in its response for this operation. The mapper SHALL support, at most, the following printer attributes:
LPDは厳しくマッパーは、この操作のためにその応答で返すことができる属性のセットを制限します。マッパーは、最大で、以下のプリンタ属性をサポートしなければなりません。
- printer-state - printer-state-reasons
- プリンタの状態 - プリンタ状態の理由
The mapper uses either the long or short form of the "send queue state" command.
マッパーは、「キューの状態を送信する」コマンドの長いか短い形式のいずれかを使用しています。
The mapper SHALL assume that the LPD response that it receives has the format and information specified in section 3.3 "Send queue state (short)" and section 3.4 "Send queue state (long)". The mapper SHALL determine the value of each requested attribute by using the inverse of the mapping specified in the two aforementioned sections.
マッパーは、それが受信したLPD応答はセクション3.3で指定されたフォーマット情報を有すること「（ロング）キュー状態を送信する」とセクション3.4「キュー状態（ショート）を送る」負います。マッパーは、前述の2つのセクションで指定されたマッピングの逆を使用して、各要求された属性の値を決定しなければなりません。
Note: the mapper can determine the response from the printer-status line without examining the rest of the LPD response.
注意：マッパーがLPD応答の残りの部分を検討することなく、プリンタステータス行からの応答を決定することができます。
LPD severely limits the set of attributes that the mapper is able to return in its response for this operation. The mapper SHALL support, at most, the following job attributes:
LPDは厳しくマッパーは、この操作のためにその応答で返すことができる属性のセットを制限します。マッパーは、最大で、次のジョブ属性、サポートしなければなりません。
- number-of-intervening-jobs - job-originating-user-name - job-id - document-name - job-k-octets - copies
- 数の-介入 - ジョブ - ジョブ発信ユーザー名 - ジョブID - ドキュメント名 - ジョブKオクテット - コピー
The mapper uses either the long or short form of the "send queue state" command. If it receives a request for the "job-k-octets" or "copies" and supports the attribute it SHALL use the long form; otherwise, it SHALL use the short form.
マッパーは、「キューの状態を送信する」コマンドの長いか短い形式のいずれかを使用しています。それは「仕事-K-オクテット」または「コピー」のリクエストを受信して、属性をサポートしている場合には、長い形式を使用しなければなりません。それ以外の場合は、短い形式を使用しなければなりません。
Note: the value of job-k-octets is the value in the short form divided by the number of "copies" which is on the long form only. Its value can also be determined by adding the "size" field values for each document in the job in the long form.
注：ジョブ-K-オクテットの値は、長い形式である「コピー」の数で割った短形の値です。その値も長い形式で、ジョブ内の各ドキュメントの「サイズ」フィールドの値を加算することによって決定することができます。
The mapper SHALL assume that the LPD response that it receives has the format and information specified in section 3.3 "Send queue state (short)" and section 3.4 "Send queue state (long)". The mapper SHALL determine the value of each requested attribute by using the inverse of the mapping specified in the two aforementioned sections.
マッパーは、それが受信したLPD応答はセクション3.3で指定されたフォーマット情報を有すること「（ロング）キュー状態を送信する」とセクション3.4「キュー状態（ショート）を送る」負います。マッパーは、前述の2つのセクションで指定されたマッピングの逆を使用して、各要求された属性の値を決定しなければなりません。
Note: when the mapper uses the LPD short form, it can determine the response from the single LPD line that pertains to the job specified by the Get-Job-Attributes operation.
注：マッパーがLPD短い形式を使用する場合、それは入手-仕事を-属性の操作で指定されたジョブに関連する単一LPDラインからの応答を決定することができます。
Note: the mapper can use its correspondence between the IPP job-id, job-uri and the LPD job-number.
注：マッパーはIPPジョブID、ジョブURIとLPDジョブ番号の間の対応を使用することができます。
The mapper SHALL perform this operation in the same way as Get-Job-Attributes except that the mapper converts all the LPD job-lines, and the IPP response contains one job object for each job-line in the LPD response.
マッパーは、マッパーがすべてのLPDジョブラインを変換し、IPP応答はLPD応答に各ジョブ・ラインに1つのジョブオブジェクトが含まれていることを除いては、Get-ジョブ・属性と同じように、この操作を実行しなければなりません。
This section describes the mapping from IPP operation attributes and job template attributes to LPD control file lines (called ' functions'). The mapper receives the IPP operation attributes and job template atributes via the IPP operation. Each of the IPP operation attributes and job template attributes appear as sub-sections of section 3 and 4.2 in the IPP model document [RFC2566].
このセクションでは、IPP操作属性からのマッピングを説明し、ジョブテンプレートは、（「機能」と呼ばれる）LPD制御ファイルの行に属性。マッパーは、IPP操作によってIPP操作属性とジョブテンプレートatributesを受けます。 IPP操作の各属性とジョブテンプレート属性がIPPモデルドキュメント[RFC2566]セクション3および4.2のサブセクションとして現れます。
In the context of LPD control file lines, the text operands have a maximum length of 31 or 99 while IPP operation attributes and job template attributes have a maximum of 255 or 1023 octets, depending on the attribute syntax. Therefore, there may be some data loss if the IPP operation attribute and job template attribute values exceed the maximum length of the LPD equivalent operands.
IPP操作属性とジョブテンプレート属性は255または1023オクテットの最大を持っていながら、LPD制御ファイルの行のコンテキストでは、テキストオペランドは、属性構文に応じて、31または99の最大の長さを持っています。 IPPの操作属性とジョブテンプレートは、値がLPD等価オペランドの最大長を超え属性場合したがって、いくつかのデータ損失があってもよいです。
The mapper converts each supported IPP operation attribute and job template attribute to its corresponding LPD function as defined by tables in the subsections that follow. These subsections group functions according to whether they are:
以下のサブセクション内のテーブルによって定義されるようマッパは、その対応するLPDの機能にサポートされている各IPPの操作属性とジョブテンプレート属性を変換します。彼らはあるかどうかに応じて、これらのサブセクショングループ機能：
- required with a job, - optional with a job - required with each document.
- ジョブにオプション - - 各ドキュメントに必要なジョブ、と必要。
In the tables below, each IPP value is given a name, such as 'h'. If an LPD value uses the IPP value, then the LPD value column contains the IPP name, such as 'h' to denote this. Otherwise, the LPD value column specifies the literal value.
以下の表に、各IPP値は、「H」として、名前を与えられています。 LPD値がIPPの値を使用する場合、LPD値欄は、これを示すために「H」として、IPP名を含みます。それ以外の場合は、LPD値の欄には、リテラル値を指定します。
The mapper SHALL include the following LPD functions with each job, and they SHALL have the specified value. They SHALL be the first functions in the control file and they SHALL be in the order "H" and then "P".
マッパーは、各ジョブに以下のLPDの機能が含まれるものとし、彼らが指定した値を持たなければなりません。彼らは、制御ファイルの最初の関数でなければならず、彼らは秩序「H」とし、「P」にされなければなりません。
IPP LPD function name value name value description
IPP LPD関数名値の名前と値の説明
(perhaps in security h H gateway host Originating Host layer) requesting-user-name u P u User identification and in the security layer
要求ユーザ名U P uのユーザ識別及びセキュリティ層に（おそらくセキュリティ時間Hゲートウェイホストのホスト層を発信）
A mapper SHALL sends its own host rather than the client's host, because some LPD systems require that it be the same as the host from which the remove-jobs command comes. A mapper MAY send its own user name as user identification rather than the client user. But in any case, the values sent SHALL be compatible with the LPD remove-jobs operation.
一部のLPDシステムは、それがremove-仕事が来るコマンド元のホストと同じにすることを必要とするので、マッパーはSHALL、クライアントのホストではなく、独自のホストを送信します。マッパーは、ユーザ識別ではなく、クライアントのユーザとして独自のユーザー名を送信することができます。しかし、どのような場合には、送信された値は、LPD削除 - ジョブの動作と互換性がなければなりません。
The mapper MAY include the following LPD functions with each job. They SHALL have the specified value if they are sent. These functions, if present, SHALL follow the require job functions, and they SHALL precede the required document functions.
マッパーは、各ジョブに以下のLPD機能を含むことができます。それらが送信された場合、それらは指定された値を持たなければなりません。これらの機能は、存在する場合、必要とジョブ機能に従うものとし、彼らが必要なドキュメント機能を先行するものとします。
IPP attribute LPD function name value name value description
IPPは、LPD関数名値の名前と値の説明属性
job-name j J j Job name for banner page job-sheets 'standard' L u Print banner page job-sheets 'none' omit 'L' function
uはバナーページジョブ・シート「どれも」を印刷していないバナーページジョブ・シート「標準」Lのためのジョブ名JのJ Jジョブ名が「L」の機能を省略します
Note: 'L' has special meaning when it is omitted. If 'J' is omitted, some undefined behavior occurs with respect to the banner page.
注意：「L」は、それが省略されている特別な意味を持っています。 「J」が省略されている場合、いくつかの未定義の動作は、バナーページに関して発生します。
The mapper SHALL include one set of the following LPD functions with each document, and they SHALL have the specified values. For each document, the order of the functions SHALL be 'f', 'U' and then 'N', where 'f' is replicated once for each copy.
マッパーは、各ドキュメントでは、次のLPDの機能の1組を含むものとし、彼らは指定された値を持たなければなりません。各文書のために、機能の順序は、「F」、「U」と「F」は各コピーに対して一度複製され、次いで「N」でなければなりません。
IPP attribute LPD function
IPPは、LPD機能属性
name value name value description
名前値の名前と値の説明
document- 'application/octet- f fff Print formatted file format stream' or 'application/PostScript' copies c replicate 'f' 'c' times none U fff Unlink data file document- n N n Name of source file name
Uリンクを解除データファイルをFFF document- N N Nソースファイル名の名称「アプリケーション/ octet- F FFF形式のファイル形式のストリームを印刷する」または「アプリケーション/ポストスクリプト」コピー「F」「C」回なしを複製しないcはdocument-
Note: the value 'fff' of the 'f' and 'U' functions is the name of the data file as transferred, e.g. "dfA123woden".
注：値を「F」の「FFF」と「U」の機能は、データファイルの名前で転送されるように、例えば"dfA123woden"。
Note: the mapper SHALL not send the 'o' function
注意：マッパーは「O」機能を送信してはなりません
ISSUE: should we register DVI, troff or ditroff?
問題：私たちはDVI、troffのかditroffのを登録する必要がありますか？
If the mapper receives no "ipp-attribute-fidelitybest-effort" or it has a value of false, then the mapper SHALL reject the job if it specifies attributes or attribute values that are not among those supported in the above tables.
マッパーはない「IPP-属性fidelitybestエフォート」を受信しないか、それが偽の値を持つ場合、それは上記の表にサポートされているものの中ではない属性または属性値を指定した場合、その後、マッパーは、ジョブを拒否しなければなりません。
Below is an example of the minimal control file for a job with three copies of two files 'foo' and 'bar':
下の2つのファイル「foo」と「bar」の3つのコピーを持つジョブのための最小限の制御ファイルの例です。
H tiger P jones f dfA123woden f dfA123woden f dfA123woden U dfA123woden N foo f dfB123woden f dfB123woden f dfB123woden
dfB123woden F dfB123woden F dfB123woden F HトラPジョーンズF dfA123woden F dfA123woden F dfA123woden U dfA123woden NのFOO
U dfB123woden N bar
U dfB123woden Nバー
There are no security issues beyond those covered in the IPP Encoding and Transport document [RFC2565], the IPP model document [RFC2566] and the LPD document [RFC1179].
IPPコード化とTransportドキュメント[RFC2565]、IPPモデルドキュメント[RFC2566]とLPDのドキュメント[RFC1179]でカバーされたもの以外はセキュリティ上の問題はありません。
[ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0: Implementer's Guide", Work in Progress.
[IPP-IIG]ヘイスティングス、T.、ら、 "インターネット印刷プロトコル/ 1.0：Implementerのガイド"。、進行中の作業。
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759]スミス、R.、ライト、F.、ヘイスティングス、T.、Zilles、S.、およびJ.およびGyllenskog、 "プリンタMIB"、RFC 1759、1995年3月。
[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, August 1990.
[RFC1179]マクラフリン、L.、 "ラインプリンタデーモンプロトコル"、RFC 1179、1990年8月。
[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S. "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] D.クロッカーら、 "増補構文仕様のためのBNF：ABNF"、RFC 2234、1997年11月。
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2565]エリオ、R.、バトラー、S.、ムーア、P.とR.チューナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、RFC 2565、1999年4月。
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] deBry、R.、ヘイスティングズ、T.、エリオ、R.、Isaacson氏、S.、およびP.パウエル、 "インターネット印刷プロトコル/ 1.0：モデルと意味論"、RFC 2566、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567]ライト、D.、 "インターネット印刷プロトコルの設計目標"、RFC 2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S.、「インターネット印刷プロトコルのための構造とモデルとプロトコルのための理論的根拠」、RFC 2568、1999年4月。
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
ロバート・エリオット（編集）ゼロックス・コーポレーション3400ヒルビューアベニュー、ビル＃1パロアルト、CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
電話：650-813-7696ファックス：650-813-6860 Eメール：rherriot@pahv.xerox.com
Norm Jacobs Sun Microsystems Inc. 1430 Owl Ridge Rd. Colorado Springs, CO 80919
ノーム・ジェイコブスサン・マイクロ株式会社1430フクロウリッジRdを。コロラドスプリングス、CO 80919
Phone: 719-532-9927 Fax: 719-535-0956 EMail: Norm.Jacobs@Central.sun.com
電話：719-532-9927ファックス：719-535-0956 Eメール：Norm.Jacobs@Central.sun.com
Thomas N. Hastings Xerox Corporation 701 S. Aviation Blvd., ESAE-231 El Segundo, CA 90245
トーマスN.ヘイスティングスゼロックスコーポレーション701 S.航空ブルバード、ESAE-231エルセグンド、CA 90245
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
電話：310-333-6413ファックス：310-333-5514 Eメール：hastings@cp10.es.xerox.com
Jay Martin Underscore, Inc. 41-C Sagamore Park Road Hudson, NH 03051-4915
ジェイ・マーティンアンダースコア、Inc.の41-Cサガモアパークロード・ハドソン、NH 03051から4915
Phone: 603-889-7000 Fax: 603-889-2699 EMail: jkm@underscore.com
電話：603-889-7000ファックス：603-889-2699 Eメール：jkm@underscore.com
The syntax in ABNF for the response to the LPD command 'send-queue-state (long)' is:
LPDコマンド「送信キュー状態（ロング）」への対応のためのABNFで構文は次のとおりです。
status-response = empty-queue / nonempty-queue empty-queue = "no-entries" LF nonempty-queue = printer-status LF heading LF *(job LF) printer-status = OK-status / error-status OK-status = printer-name SP "ready and printing" LF error-status = < implementation dependent status information > heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files" 23SP "Total Size" LF ; the column headings and their values below begin at the columns ; 1, 8, 19, 35 and 63 job = rank *SP owner *SP job *SP files *SP total-size "bytes" ; jobs are in order of oldest to newest rank = "active" / "1st" / "2nd" / "3rd" / integer "th" ; job that is printing is "active" ; other values show position in the queue owner = <user name of person who submitted the job> job = 1*3DIGIT ; job-number files = <file name> *( "," <file name>) ; truncated to 24 characters total-size = 1*DIGIT ; combined size in bytes of all documents
ステータス応答=空のキュー/空でないキューは空キュー=「ノーエントリ」LFの空でないキュー= LF *（ジョブLF）プリンタステータスを見出し、プリンタステータスLF = OKステータス/エラーステータスOKステータス=プリンタ名SP「準備および印刷」LFエラーステータス= <実装に依存するステータス情報>見出し=「ランク」3SP「所有者」6SP「仕事」13SP「ファイル」23SP「合計サイズ」LF。列見出しとその値は以下の列で始まります。 1、8、19、35及び63ジョブ=ランク* SPの所有者* SPのジョブ* SPファイル* SP合計サイズ "バイト"。ジョブは、最新ランク=「アクティブ」/「第一」/「第二」/「第3回」/整数「目」へ最古の順です。印刷されたジョブは「アクティブ」です。他の値は、ジョブ= 1キュー所有者= <ジョブを送信した人のユーザー名> * 3DIGITに位置を表示します。ジョブ番号ファイル= <ファイル名> *（「」<ファイル名>）。切り捨てられた24文字の合計サイズ= 1 * DIGIT。すべての文書のバイト単位の合計サイズ
The syntax in ABNF for the response to the LPD command 'send-queue-state (long)' is:
LPDコマンド「送信キュー状態（ロング）」への対応のためのABNFで構文は次のとおりです。
status-response = empty-queue / nonempty-queue empty-queue = "no-entries" LF nonempty-queue = printer-status LF *job printer-status = OK-status / error-status OK-status = printer-name SP "ready and printing" LF error-status = < implementation dependent status information > job = LF line-1 LF line-2 LF line-1 = owner ":" SP rank 1*SP "[job" job SP host "]" line-2 = file-name 1*SP document-size "bytes" ; jobs are in order of oldest to newest rank = "active" / "1st" / "2nd" / "3rd" / integer "th" ; job that is printing is "active" ; other values show position in the queue owner = <user name of person who submitted the job> job = 1*3DIGIT file-name = [ 1*DIGIT "copies of" SP ] <file name> ; truncated to 24 characters document-size = 1*DIGIT ;size of single copy of the document.
ステータス応答=空のキュー/空でないキューは空キュー=「ノーエントリ」LFの空でないキュー=プリンタステータスLF *ジョブプリンタステータス= OKステータス/エラーステータスOKステータス=プリンタ名SP "準備と印刷" LFエラーステータス= <実装に依存ステータス情報>ジョブ= LF線-1 LFライン2 LF線-1 =所有者 "：" SPランク1 *のSP "[ジョブ" ジョブSPホスト "]"ライン-2 =ファイル名1 * SPの原稿サイズ "バイト"。ジョブは、最新ランク=「アクティブ」/「第一」/「第二」/「第3回」/整数「目」へ最古の順です。印刷されたジョブは「アクティブ」です。他の値は= <ジョブを送信した人のユーザー名>仕事= 1 * 3DIGITファイル名= [SP 1 * DIGIT「のコピー」] <ファイル名>キューの所有者に位置を表示します。 = 1 * DIGIT 24文字に切り捨て原稿サイズ、文書の単一コピーのサイズ。
The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper ignores them and the IPP-to-LPD mapper does not send them.
フォローのLPD機能にはIPP相当を持っていません。 LPDツーIPPマッパーはそれらを無視し、IPPツーLPDマッパーは、それらを送信しません。
LPD command name description
LPDコマンド名説明
C Class for banner page I Indent Printing H Host of client M Mail when printed S Symbolic link data T Title for pr W Width of output 1 troff R font 2 troff I font 3 troff B font 4 troff S font
S出力1のtroff Rフォント2のtroffのPR幅Wに対するシンボリックリンクデータTタイトルを印刷するとき、クライアントMメールのバナーページIインデント印刷HホストのCクラスI 3のtroff Bフォント4のtroff Sフォントをフォント
The follow LPD functions specify document-formats which have no IPP equivalent, unless someone registers them. The LPD-to-IPP mapper rejects jobs that request such a document format, and the IPP-to-LPD mapper does not send them.
フォローのLPD機能は、誰かが彼らを登録していない限り、何のIPP相当を持っていないドキュメントの形式を指定します。 LPDツーIPPマッパーは、このような文書フォーマットを要求するジョブを拒否し、IPPツーLPDマッパーは、それらを送信しません。
LPD command name description
LPDコマンド名説明
c Plot CIF file d Print DVI file g Plot file k reserved for Kerberized clients and servers n Print ditroff output file p Print file with 'pr' format r File to print with FORTRAN carriage control t Print troff output file v Print raster file z reserved for future use with the Palladium print system
Cケルベロスクライアントとサーバのために予約プロットCIFファイルD印刷DVIファイルGプロットファイルK N印刷ditroffの出力ファイルP印刷ファイル「PR」フォーマットrファイルとFORTRANキャリッジ制御T印刷のtroff出力ファイルV印刷ラスタファイルZが予約で印刷しますパラジウムプリントシステムとの将来の使用のため
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。