RFC2569 日本語訳
2569 Mapping between LPD and IPP Protocols. R. Herriot, Ed., T.Hastings, N. Jacobs, J. Martin. April 1999. (Format: TXT=57886 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.エリオの要求をネットワークでつないでください: 2569年のゼロックス社のカテゴリ: 実験的なN.の社のJ.マーチン強調Inc.ジェイコブズサン・マイクロシステムズ・インクT.ヘイスティングズゼロックス1999年4月
Mapping between LPD and IPP Protocols
LPDとIPPの間でプロトコルを写像します。
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
このドキュメントはインターネットコミュニティのためにExperimentalプロトコルを定義します。 IESGは、Proposed Standardが議定書を作るときこのプロトコルの改訂版が発行されると予想します。 発行されると、Proposed Standardがこのメモで定義されたプロトコルから変化すると予想されます。 特に、プロトコルの標準化過程バージョンが強い認証、プライバシー機能、およびそれを取り入れると予想される、「ipp:」 URLタイプは定義されるでしょう(それらの安全策をサポートします)。 また、プロトコルへの他の変化も可能です。 作成者はこのプロトコルの将来のバージョンが、本書では、または彼らが共同利用するなら定義された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はこのプロトコルによる実験を奨励します、特にTransport Layer Security(TLS)[RFC2246]と組み合わせて助けるのは、セキュリティにIPPのために層にされるときTLSがどのように事実上使用されるかもしれないかを決定します。
Herriot, et al. Experimental [Page 1] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[1ページ]RFC2569
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.
このドキュメントは1セットのドキュメントの1つであり、どれが新しいインターネットPrintingプロトコル(IPP)の全面について一緒に説明しますか? IPPは分配された印刷にインターネット・ツールと技術を使用することで使用できるアプリケーションレベルプロトコルです。 このドキュメントはIPPとLPD(線Printer Daemon)の間で何らかのアドバイスをゲートウェイのimplementersに与えます。 このドキュメントは(1) インターネットPrintingプロトコル/1.0(IPP)の(2) RFC1179で指定された'線Printer Daemon(LPD)プロトコル'と操作のコマンドとオペランドと、操作属性と仕事のテンプレート属性の間のマッピングについて説明します。 このドキュメントの目的の1つは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.
警告: IETF標準化過程の上にRFC1179がありませんでした。 RFC1179が既存の習慣を記録することを意図しましたが、それはいくつかの領域に不足しました。 しかしながら、この仕様は(1)の間でRFC1179と(2)IPPの実際の現在の習慣を写像します。 このドキュメントは、LPDプロトコルへの多くのimplementersによってされた大幅な拡散している拡大を写像するのを試みません。
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ワーキンググループの主たる決定のためにバックグラウンドと原理を与えます。
Herriot, et al. Experimental [Page 2] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[2ページ]RFC2569
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に以下を印刷するインターネット」 「モデルと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 defines the encoding rules for a new Internet media type called ' application/ipp'.
ドキュメント、「プロトコル/1.0に以下を印刷するインターネット」 「コード化とTransport」はモデルドキュメントで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に以下を印刷するインターネット」 「Implementerのガイド」はIPPクライアントとIPPオブジェクトのimplementersにアドバイスします。
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
1. 序論…4 2. 用語…5 3. LPDからのマッピングはIPP操作に命令します…5 3.1 あらゆる待ち仕事を印刷してください…6 3.2 プリンタ仕事を受けてください…6 3.2 .1 仕事を中止してください…7 3.2 .2 制御ファイルを受け取ってください…7 3.2 .3 データファイルを受け取ってください…8 3.3 待ち行列状態(短い)を送ってください…8 3.4 待ち行列状態(長い)を送ってください…10 3.5 仕事を取り除いてください…12 4. LPD制御ファイルに関するマッピングはIPP操作と仕事のテンプレート属性まで立ち並んでいます…13 4.1の必要な仕事は機能します…13 4.2の任意の仕事は機能します…14 4.3の必要なドキュメントは機能します…14 4.4のお勧めのドキュメントは機能します…16 5. 操作をIPPからLPDに写像するのは命令します…16 5.1印刷仕事…16 5.2印刷URI…18 5.3 仕事を有効にします…18 5.4 雇用を創り出します…18 5.5 ドキュメントを発信させます…18 5.6 URIを発信させます…18 5.7キャンセル仕事…18 5.8 プリンタ属性を得てください…19 5.9 仕事の属性を得てください…19 5.10 ジョブスを得ます…20 6. LPD制御ファイルへのIPP属性に関するマッピングは立ち並んでいます…20 6.1の必要な仕事は機能します…21 6.2の任意の仕事は機能します…21
Herriot, et al. Experimental [Page 3] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[3ページ]RFC2569
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
6.3の必要なドキュメントは機能します…22 7. セキュリティ問題…23 8. 参照…23 9. 作者のアドレス…24 10. 付録A: Sendが状態を列に並ばせている(短い)25 11.Appendix Bの応答のためのABNF Syntax: Sendが状態を列に並ばせている(長い)26 12.Appendix Cの応答のためのABNF Syntax: サポートされないLPDは機能します…27 13. 完全な著作権宣言文…28
1. Introduction
1. 序論
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.
この仕様の読者はRFC1179で説明されるようにIPP Model、Semantics仕様[RFC2566]、IPP Encoding、Transport[RF2565]、および線Printer Daemonに身近な(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.
RFC1179は1990年に既存のLPDプロトコル実装を記録する試みに書かれました。 それ以来、多くの正式書類のない拡大が彼らの印刷解決に特定の機能性をサポートするのがベンダーによってされています。 これらの拡大のすべてが追加規制ファイル命令から成ります。 このドキュメントはこれらのベンダー拡大のいずれも扱いません。 むしろそれはRFC1179によって説明された特徴の文脈の中で既存の習慣を扱います。 したがって、示されて、RFC1179からの既存の習慣の逸脱はそうです。
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.
RFC1179での他の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)として知られているドキュメント・フォーマットの領域では、RFC1179は拡大のために能力なしで固定セットを定義します。 その結果、新しいPDLの何らかのものはサポートされません、そして、それらが使用のためにPrinter MIB[RFC1759]とIPPに登録されていないので[RFC2566][RFC2565]、サポートされるもののいくつかが十分重要ではありません、望まれているなら、それらは登録されるかもしれませんが。 IANAとのドキュメント・フォーマットの登録のための指示のためのPrinter MIB仕様[RFC1759]、そして/または、IPP Model仕様[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".
このドキュメントは両方の方向のためのプロトコルマッピングを扱います: IPPプロトコルへのLPDプロトコルに関するマッピングとIPPに関するマッピングはLPDプロトコルに議定書を作ります。 前者は「LPDからIPPへのマッパ」と呼ばれます、そして、後者は「IPPからLPDへのマッパ」と呼ばれます。
Herriot, et al. Experimental [Page 4] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[4ページ]RFC2569
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の間のゲートウェイのimplementersを助けるのは意図しています。 また、それは例を提供します。(それは、IPPに関する追加洞察を与えます)。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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].
RFC1179は2つの文脈で「コマンド」という言葉を使用します: 過剰、ワイヤ、操作とコマンドには、機能をファイルしてください。 このドキュメントSHALLは後者のための「機能」という前者と句に「コマンド」という言葉を使用します。 ABNF[RFC2234]を使用することでLPDコマンドの構文を与えます。
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はx0A(ラインフィード)SPが%x20高さがある%を表します。 (スペース) DIGITは%x30-39を表します。(「0インチ、「9インチ)」
3. Mapping from LPD Commands to IPP Operations
3. LPDコマンドからIPPまで操作を写像します。
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.
このセクションはLPDコマンドからIPP操作までマッピングについて説明します。 それぞれの以下の小区分はRFC1179のセクション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プリンタプリンタ仕事を受けているPrint-仕事かCreate-仕事/属性と(短いか長い)の仕事を取り外しているGet-ジョブスキャンセル仕事を無視してください。
Herriot, et al. Experimental [Page 5] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[5ページ]RFC2569
3.1 Print any waiting jobs
3.1はどんな待ち仕事も印刷します。
Command syntax:
構文を命令してください:
print-waiting-jobs = %x01 printer-name LF
印刷待ち仕事=%x01プリンタ名のLF
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は命令して、それはSHALLです。それを無視してください、そして、IPP操作を全く送らないでください。
3.2 Receive a printer job
3.2はプリンタ仕事を受けます。
Command syntax:
構文を命令してください:
receive-job = %x02 printer-name LF
仕事を受けている=%x02プリンタ名のLF
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.
- または、ただ一つのデータファイルを含んでいるPrint-仕事の操作、--各データファイルあたり1つのSend-ドキュメント操作でCreate-仕事の操作は続きました。
If the IPP printer supports both Create-Job and Send-Document, and if a job consists of:
IPPであるなら、プリンタはCreate-仕事とSend-ドキュメントの両方を支えます、そして、仕事はaであるなら以下から成ります。
- 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.
- ただ一つのデータファイルであり、マッパSHOULDはPrint-仕事の操作を使用しますが、Create-仕事とSend-ドキュメント操作を使用するかもしれません。 - 1つ以上のデータファイル、マッパSHALLはそれぞれの受信されたLPDデータファイルにCreate-仕事を使用します、続いて、1通のSend-ドキュメントを使用します。
If the IPP printer does not support both Create-Job and Send- Document, and if a job consists of:
IPPプリンタがそうしないなら、Create-仕事とSendドキュメントの両方を支えてください。そうすれば、仕事はaであるなら以下から成ります。
- 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).
- ただ一つのデータファイルであり、マッパSHALLはPrintJob操作を使用します。 - 1つ以上のデータファイル、マッパSHALLは別々のPrint-仕事の操作としてそれぞれの受信されたLPDデータファイルを提出します(その結果、ただ一つのLPD仕事を複数のIPP仕事に変換します)。
Herriot, et al. Experimental [Page 6] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[6ページ]RFC2569
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.
マッパがCreate-仕事とSend-ドキュメントを使用するなら、LPD制御ファイル(Create仕事に属性を供給する)がすべてのLPDデータファイルの前または後に届くか否かに関係なく、どんなSend-ドキュメント操作も送る前にそれはCreate-仕事の操作を送らなければなりません。
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 Printer-名前オペランド。
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.
以下の3つの小区分がプリンタ仕事を受けているLPDサブコマンドからマッピングに関する詳細を与えます。 それぞれの以下の小区分はRFC1179のセクション6の小区分として現れます。
3.2.1 Abort job
3.2.1 仕事を中止してください。
Sub-command syntax:
サブコマンド構文:
abort-job = %x1 LF
アボート仕事=%x1 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.
マッパはこのサブコマンドを受けて、それはSHALLです。伝えることの途中に仕事を中止してください。
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.
Print-仕事かCreate-仕事の操作を送ることの途中にマッパがあるなら、それは、接続を終えるか、またはそれがPrint-仕事かCreate-仕事の操作から受けた仕事-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 Receive aプリンタ仕事の要求で全体の印刷仕事を移す前にLPDクライアントとサーバとの関係がいつでも終えるなら、このサブコマンドを含意します。
3.2.2 Receive control file
3.2.2 制御ファイルを受け取ってください。
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>
制御ファイルを受け取っている=%1*DIGIT制御ファイルの名前=x2バイト数SP制御ファイルの名前LFバイト数="cfA"職務番号クライアントホスト名。 3DIGITクライアント例えば、"cfA123woden"職務番号=ホスト名はホストが>と命名する<と等しいです。
Herriot, et al. Experimental [Page 7] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[7ページ]RFC2569
This sub-command is roughly equivalent to the IPP Create-Job operation.
このサブコマンドはおよそIPP Create-仕事の操作に同等です。
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.
マッパSHALLは、Print-仕事かCreate-仕事の操作で伝わるようにIPP操作属性と仕事のテンプレート属性値を作成するのに受信されたLPD制御ファイルのコンテンツを使用します。
3.2.3 Receive data file
3.2.3 受信データファイル
Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
サブコマンド構文: データファイルの%x3データファイルのバイトの数のName
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>
データファイルを受け取っている=%1*DIGITデータファイルの名前=x03バイト数SPデータファイルの名前LFバイト数="df"手紙職務番号クライアントホスト名。 例えば、「1番目のためのdfA123wodenは手紙=%x41-5A/%x61-7Aをファイルします」。 「Z」への「A」、「z」への“a"。 最初のファイルは「A」です。 「B」を後援してください。そうすれば、52番目のファイルは<a3DIGITクライアント「z」職務番号=ホスト名=ホスト名>です。
This sub-command is roughly equivalent to the IPP Send-Document operation.
このサブコマンドはおよそIPP Send-ドキュメント操作に同等です。
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.
マッパSHALLは、IPP Print-仕事かSend-ドキュメント操作で伝わるのにデータとして受信された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.
RFC1179はゼロの八重奏カウントを使用することによって不特定の長さのデータファイルを通過するためのメソッドを暗示しますが、どんな実装もこの特徴をサポートしません。 マッパSHALLはバイト数分野の0の値を持っている仕事を拒絶します。
3.3 Send queue state (short)
3.3 送信キュー状態(急に)
Command syntax:
構文を命令してください:
send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF
急に待ち行列を送っている=%x03プリンタ名の*(SP(ユーザ名/職務番号))LF
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.
このコマンドへのマッパの応答はプリンタとその仕事の情報を含んでいます。 RFC1179は情報も応答の形式も指定しません。 このドキュメントは、本書では指定されるとしての既存の習慣に続くようにマッパを必要とします。
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.
マッパSHALLは成る見出し行が任意に支えたプリンタ状況表示行の以下の形式、および仕事のリストにおける応答を起こします。 この書式は以下の例によって定義されます。 付録AはABNF構文を含んでいます。
Herriot, et al. Experimental [Page 8] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[8ページ]RFC2569
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は準備ができています、そして、印刷しているRank Owner Job Files Total Sizeアクティブなfred123は124が再開する1204バイトの最初の鍛冶屋、foo34576バイトもう2番目のfred125 99バイト3番目のmary126mydoc378バイト4番目の中毒127statistics.ps4567バイト5番目のfred128data.txtを9バイト詰めます。
The column numbers of above headings and job entries are:
上記の見出しと仕事のエントリーの桁位置は以下の通りです。
| | | | |
01 08 19 35 63
| | | | | 01 08 19 35 63
The mapper SHALL produce each field above from the following IPP attribute:
マッパSHALLは以下の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.
プリンタプリンタ状態とFor活動していないか状態プリンタ州の理由のプリンタ州の処理、マッパSHALLは上の形式を使用します。 止まります、マッパSHALLは誤りに不特定の形式を発生させるプリンタ州理由を使用します。数を格付けしてください、-、-、マッパSHALL、介入している仕事の所有者仕事を溯源するユーザ不特定の変換を超えた形式。 仕事の名前起因するユーザ名は仕事イドファイルがマッパをドキュメントで命名するマッパがそうするマッパのユーザ名仕事の仕事イド使用がドキュメント名のコンマの切り離されたリストを作成して、次に、最初の24のキャラクタ合計の仕事kにこのリストに先端を切らせるものとするということであるかもしれません。-マッパはサイズ八重奏*コピー*1024が評価する1024と「コピー」属性の値による仕事のk八重奏の倍数がそうするでしょう。
Herriot, et al. Experimental [Page 9] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[9ページ]RFC2569
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.
Printerがそれが秘密にしたがっている仕事を省略するかもしれないので決定する仕事のリストの仕事の見解よりむしろ介入している仕事の仕事の属性番号が'格付けする'マッパSHOULD使用。 プリンタが、仕事の属性が介入している仕事の数であるとサポートしないなら、マッパは仕事の位置を使用するかもしれません。
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.
以下に注意してください。 Printerは認証されたユーザ、または、「要求しているユーザ名」の値に仕事の起因するユーザ名の値を設定するかもしれません、実装と構成によって。 ゲートウェイに関しては、認証されたユーザはゲートウェイのユーザ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へのマッパSHALLはプリンタ状態を得るのにGetプリンタ属性操作を使用します、そして、SHOULDは仕事のすべての情報を得るのにGet-ジョブス操作を使用します。 LPDコマンドが仕事の番号かユーザ名を含んでいるなら、マッパは応答のフィルタリングを扱うかもしれません。 職務番号を含んでいますが、LPDコマンドがどんなユーザ名も含んでいないなら、マッパがGet-ジョブスよりむしろそれぞれの変換された職務番号のGet仕事の属性を使用するかもしれません。 LPDコマンドが5月がGet-ジョブスを使用するシングルユーザー名にもかかわらず、賃仕事の数がない、マッパを含んでいる、私、-、仕事、オプションは、サーバがこのオプションをサポートして、サーバであるならクライアントがLPDユーザのためのプロキシであることを許容します。
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 Printer-名前オペランドを写像するかを定義しません。
3.4 Send queue state (long)
3.4 送信キュー状態(長い)
Command syntax:
構文を命令してください:
send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
長い間待ち行列を送っている=%x04プリンタ名の*(SP(ユーザ名/職務番号))LF
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.
このコマンドへのマッパの応答はプリンタとその仕事の情報を含んでいます。 RFC1179は情報も応答の形式も指定しません。 このドキュメントは、本書では指定されるとしての既存の習慣に続くようにマッパを必要とします。
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.
SHALLが応答を起こす以下がフォーマットするプリンタ状況表示行から成るマッパは任意に仕事のリストに従いました。そこでは、各仕事が空白行、記述系列、および各ファイルあたり1つの系列から成ります。 記述系列はユーザ名、ランク、職務番号、およびホストを含みます。 この書式は以下の例によって定義されます。 付録BはABNF構文を含んでいます。
Herriot, et al. Experimental [Page 10] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[10ページ]RFC2569
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
fred: もの602バイトのアクティブな[仕事123の虎]コピー2部
smith: 1st [job 124 snail]
2 copies of resume 7088 bytes
2 copies of foo 10200 bytes
鍛冶屋: foo10200バイトの7088バイトの履歴書2コピーのコピー最初[仕事124のカタツムリ]の2部
fred: 2nd [job 125 tiger]
more 99 bytes
fred: さらに2[仕事125の虎]番目の99バイト
The column numbers of above headings and job entries are:
上記の見出しと仕事のエントリーの桁位置は以下の通りです。
| | |
01 09 41
| | | 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.
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.
LPD field IPP attribute special conversion details
LPD field IPP attribute special conversion details
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.
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.
NOTE: This specification does not define how the mapper maps the LPD Printer-name operand to the IPP printer-uri operation attribute.
NOTE: This specification does not define how the mapper maps the LPD Printer-name operand to the IPP printer-uri operation attribute.
Herriot, et al. Experimental [Page 11] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 11] RFC 2569 Mapping between LPD and IPP Protocols April 1999
3.5 Remove jobs
3.5 Remove jobs
Command syntax:
Command syntax:
remove-jobs = %x05 printer-name SP agent
*(SP(user-name / job-number)) LF
remove-jobs = %x05 printer-name SP agent *(SP(user-name / job-number)) LF
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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".
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.
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.
Herriot, et al. Experimental [Page 12] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 12] RFC 2569 Mapping between LPD and IPP Protocols April 1999
4. Mapping of LPD Control File Lines to IPP Operation and Job Template Attributes
4. Mapping of LPD Control File Lines to IPP Operation and Job Template Attributes
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.
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.
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.
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.
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:
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:
- required with a job,
- optional with a job
- required with each document.
- 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.
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.
4.1 Required Job Functions
4.1 Required Job Functions
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:
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 function IPP name value description name value
LPD function IPP name value description name value
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 Originating Host h (in security layer) P u User identification requesting- u (and in security user-name layer) none ipp- 'true' attribute- fidelity
Herriot, et al. Experimental [Page 13] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 13] RFC 2569 Mapping between LPD and IPP Protocols April 1999
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.
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.
The mapper SHALL include ipp-attribute-fidelity = true so that it doesn't have to determine which attributes a printer supports.
The mapper SHALL include ipp-attribute-fidelity = true so that it doesn't have to determine which attributes a printer supports.
4.2 Optional Job Functions
4.2 Optional Job Functions
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.
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.
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.
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 function IPP name value description name value
LPD function IPP name value description name value
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 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.
4.3 Required Document Functions
4.3 Required Document Functions
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.
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.
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
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
Herriot, et al. Experimental [Page 14] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 14] RFC 2569 Mapping between LPD and IPP Protocols April 1999
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.
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.
LPD function IPP name value description name value
LPD function IPP name value description name value
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 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
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.
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.
Note: In practice, the 'l' LPD function is often used as a rough equivalent to the 'f' function.
Note: In practice, the 'l' LPD function is often used as a rough equivalent to the 'f' function.
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.
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.
Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name of the data file as transferred, e.g. "dfA123woden".
Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name of the data file as transferred, e.g. "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.
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.
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.
Herriot, et al. Experimental [Page 15] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 15] RFC 2569 Mapping between LPD and IPP Protocols April 1999
4.4 Recommended Document Functions
4.4 Recommended Document Functions
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.
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.
LPD function IPP name value description name value
LPD function IPP name value description name value
U fff ignored N n Name of source file document-name n
U fff ignored N n Name of source file document-name n
Note: the value 'fff' of the 'U' function is the name of the data file as transferred, e.g. "dfA123woden".
Note: the value 'fff' of the 'U' function is the name of the data file as transferred, e.g. "dfA123woden".
5. Mapping from IPP operations to LPD commands
5. Mapping from IPP operations to LPD commands
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].
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 operation LPD command
IPP operation LPD command
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
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
5.1 Print-Job
5.1 Print-Job
The mapper SHALL send the following commands in the order listed below:
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
- 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
Herriot, et al. Experimental [Page 16] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 16] RFC 2569 Mapping between LPD and IPP Protocols April 1999
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: 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.
NOTE: This specification does not define the mapping between the IPP printer-uri and the LPD printer-name.
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.
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.
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.
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.
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.
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.
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.
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.
This document does not address error code conversion.
This document does not address error code conversion.
Herriot, et al. Experimental [Page 17] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 17] RFC 2569 Mapping between LPD and IPP Protocols April 1999
5.2 Print-URI
5.2 Print-URI
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.
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.
5.3 Validate-Job
5.3 Validate-Job
The mapper SHALL perform this operation directly. Because LPD supports very few attributes, this operation doesn't have much to check.
The mapper SHALL perform this operation directly. Because LPD supports very few attributes, this operation doesn't have much to check.
5.4 Create-Job
5.4 Create-Job
The mapper SHALL handle this operation like Print-Job, except:
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.
- 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.
5.5 Send-Document
5.5 Send-Document
The mapper performs a receive-data-file sub-command on the received data. See the preceding section 5.4 "Create-Job" for the details.
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.6 Send-URI
5.6 Send-URI
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.
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.
5.7 Cancel-Job
5.7 Cancel-Job
The mapper SHALL perform a remove-jobs command with the following operation attributes:
The mapper SHALL perform a remove-jobs command with the following operation attributes:
Herriot, et al. Experimental [Page 18] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 18] RFC 2569 Mapping between LPD and IPP Protocols April 1999
- 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
- 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
5.8 Get-Printer-Attributes
5.8 Get-Printer-Attributes
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 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:
- printer-state
- printer-state-reasons
- printer-state - printer-state-reasons
The mapper uses either the long or short form of the "send queue state" command.
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.
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.
Note: the mapper can determine the response from the printer-status line without examining the rest of the LPD response.
Note: the mapper can determine the response from the printer-status line without examining the rest of the LPD response.
5.9 Get-Job-Attributes
5.9 Get-Job-Attributes
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 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:
- number-of-intervening-jobs
- job-originating-user-name
- job-id
- document-name
- job-k-octets
- copies
- number-of-intervening-jobs - job-originating-user-name - job-id - document-name - job-k-octets - copies
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.
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.
Herriot, et al. Experimental [Page 19] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 19] RFC 2569 Mapping between LPD and IPP Protocols April 1999
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.
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.
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.
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.
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.
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.
Note: the mapper can use its correspondence between the IPP job-id, job-uri and the LPD job-number.
Note: the mapper can use its correspondence between the IPP job-id, job-uri and the LPD job-number.
5.10 Get-Jobs
5.10 Get-Jobs
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.
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.
6. Mapping of IPP Attributes to LPD Control File Lines
6. Mapping of IPP Attributes to LPD Control File Lines
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].
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].
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.
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.
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:
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:
Herriot, et al. Experimental [Page 20] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 20] RFC 2569 Mapping between LPD and IPP Protocols April 1999
- required with a job,
- optional with a job
- required with each document.
- 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.
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.
6.1 Required Job Functions
6.1 Required Job Functions
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".
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".
IPP LPD function name value name value description
IPP LPD function name value name value description
(perhaps in security h H gateway host Originating Host layer) requesting-user-name u P u User identification and in the security layer
(perhaps in security h H gateway host Originating Host layer) requesting-user-name u P u User identification and in the security layer
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.
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.
6.2 Optional Job Functions
6.2 Optional Job Functions
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.
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.
IPP attribute LPD function name value name value description
IPP attribute LPD function name value name value description
job-name j J j Job name for banner
page
job-sheets 'standard' L u Print banner page
job-sheets 'none' omit 'L' function
job-name j J j Job name for banner page job-sheets 'standard' L u Print banner page job-sheets 'none' omit 'L' function
Herriot, et al. Experimental [Page 21] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Herriot, et al. Experimental [Page 21] RFC 2569 Mapping between LPD and IPP Protocols April 1999
Note: 'L' has special meaning when it is omitted. If 'J' is omitted, some undefined behavior occurs with respect to the banner page.
Note: 'L' has special meaning when it is omitted. If 'J' is omitted, some undefined behavior occurs with respect to the banner page.
6.3 Required Document Functions
6.3 Required Document Functions
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.
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.
IPP attribute LPD function
IPP attribute LPD function
name value name value description
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
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
Note: the value 'fff' of the 'f' and 'U' functions is the name of the data file as transferred, e.g. "dfA123woden".
以下に注意してください。 'f'と'U'機能の値の'fff'は名前わたっている同じくらいデータファイル、例えば、"dfA123woden"です。
Note: the mapper SHALL not send the 'o' function
以下に注意してください。 マッパSHALLは'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な努力」を全く受けないか、またはそれに誤ることの値があるなら、上のテーブルで支持されたものにない属性か属性値を指定するなら、マッパSHALLは仕事を拒絶します。
Below is an example of the minimal control file for a job with three copies of two files 'foo' and 'bar':
以下に、コピー3部の'foo'という2個のファイルと'バー'による仕事のための最小量の制御ファイルに関する例があります:
H tiger
P jones
f dfA123woden
f dfA123woden
f dfA123woden
U dfA123woden
N foo
f dfB123woden
f dfB123woden
f dfB123woden
H虎のP中毒f dfA123woden f dfA123woden f dfA123woden U dfA123woden N foo f dfB123woden f dfB123woden f dfB123woden
Herriot, et al. Experimental [Page 22] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[22ページ]RFC2569
U dfB123woden
N bar
U dfB123woden Nバー
7. Security Considerations
7. セキュリティ問題
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 EncodingとTransportドキュメントでカバーされたもの[RFC2565]、IPPモデルドキュメント[RFC2566]、およびLPDドキュメント[RFC1179]を超えていません。
8. References
8. 参照
[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.
1995年3月の[RFC1759]スミスとR.とライトとF.とヘイスティングズとT.とZilles、S.とJ.Gyllenskog、「プリンタMIB」RFC1759。
[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
August 1990.
[RFC1179] マクラフリン、L.、「ラインプリンタデーモンプロトコル」、RFC1179、1990年8月。
[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月。
[RFC2234] D. Crocker et al., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] D. クロッカー他、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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日
[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日
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2567] ライト、D.、「インターネット印刷プロトコルのデザイン目標」、RFC2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2568]Zilles、S.、「インターネット印刷プロトコルのための構造、モデル、およびプロトコルのための原理」、RFC2568、1999年4月。
Herriot, et al. Experimental [Page 23] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[23ページ]RFC2569
9. Authors' Addresses
9. 作者のアドレス
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
ロバートエリオ(エディタ)ゼロックス社3400のHillview Ave、パロアルト、Bldg#1カリフォルニア 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
以下に電話をしてください。 650-813-7696 Fax: 650-813-6860 メールしてください: rherriot@pahv.xerox.com
Norm Jacobs Sun Microsystems Inc. 1430 Owl Ridge Rd. Colorado Springs, CO 80919
標準ジェイコブズサン・マイクロシステムズ1430の一晩中動いているRidge通り コロラド・スプリングス、CO 80919
Phone: 719-532-9927 Fax: 719-535-0956 EMail: Norm.Jacobs@Central.sun.com
以下に電話をしてください。 719-532-9927 Fax: 719-535-0956 メールしてください: Norm.Jacobs@Central.sun.com
Thomas N. Hastings Xerox Corporation 701 S. Aviation Blvd., ESAE-231 El Segundo, CA 90245
ESAE-231エルセガンド、カリフォルニア 701秒間航空Blvd.、トーマスN.ヘイスティングズゼロックス社の90245
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
以下に電話をしてください。 310-333-6413 Fax: 310-333-5514 メールしてください: hastings@cp10.es.xerox.com
Jay Martin Underscore, Inc. 41-C Sagamore Park Road Hudson, NH 03051-4915
41Cのジェイ・マーチン・Underscore Inc.副酋長公園Roadハドソン、ニューハンプシャー03051-4915
Phone: 603-889-7000 Fax: 603-889-2699 EMail: jkm@underscore.com
以下に電話をしてください。 603-889-7000 Fax: 603-889-2699 メールしてください: jkm@underscore.com
Herriot, et al. Experimental [Page 24] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[24ページ]RFC2569
10. Appendix A: ABNF Syntax for response of Send-queue-state (short)
10. 付録A: Send待ち行列状態の応答のためのABNF Syntax(急に)
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
エラー状況OK-状態=プリンタOK-状態/名のSPの「準備ができていて印刷している」LF nonempty-待ち行列の空の空の待ち行列/待ち行列=「エントリーがありません」LF nonempty-待ち行列=プリンタ状態LF見出しLF*(仕事のLF)プリンタ状態応答=状態=エラー状況は<の依存する状態情報>見出し実現=「ランク」3SP「所有者」6SP「仕事」13SP「ファイル」23SP「総サイズ」LFと等しいです。 コラム見出しと以下のそれらの値はコラムで始まります。 1、8、19、35、および63仕事=ランク*SP所有者*SP仕事*SPファイル*SP総サイズ「バイト」。 仕事がランク=「アクティブ」最も新しい/「1番目」/「2番目」/「3番目」/整数“th"に最も古いことの順にあります。 印刷である仕事は「アクティブです」。 他の値は、= 仕事の>仕事を提出した人の<ユーザ名が1*3DIGITと等しいのを待ち行列所有者の位置に示します。 職務番号ファイルが<ファイル名>*と等しい、(「」、<ファイル名前>)、。 総サイズ=1*DIGITに24のキャラクタに先端を切らせます。 すべてのドキュメントのバイトで表現される結合したサイズ
Herriot, et al. Experimental [Page 25] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[25ページ]RFC2569
11. Appendix B: ABNF Syntax for response of Send-queue-state (long)
11. 付録B: Send待ち行列状態の応答のためのABNF Syntax(長い)
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.
「状態応答はnonempty-待ち行列の空の空の待ち行列/待ち行列=「エントリーがない<実現に依存する状態>仕事=LF情報エラー状況OK-状態=プリンタOK-状態/名のSPの「準備ができていて印刷している」LF」 LF nonempty-待ち行列=プリンタ状態LF*端物専門の印刷屋状態=エラー状況=線-1LF線-2LF線-1=所有者」と等しいです」 「SPが1*SPを格付けする、「[仕事の」 仕事のSPが接待する、」、]、」 1*SPドキュメントサイズ「バイト」という線-2=ファイル名。 仕事がランク=「アクティブ」最も新しい/「1番目」/「2番目」/「3番目」/整数“th"に最も古いことの順にあります。 印刷である仕事は「アクティブです」。 他の値は、= 1*3DIGIT仕事の>仕事を提出した人の<ユーザ名=ファイル名が<ファイル名前>と等しいのを[SPは1*DIGITについて「コピーされる」]待ち行列所有者の位置に示します。 24のキャラクタに先端を切られて、ドキュメントサイズは1*DIGITと等しいです; ドキュメントのただ一つのコピーのサイズ。
Herriot, et al. Experimental [Page 26] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[26ページ]RFC2569
12. Appendix C: Unsupported LPD functions
12. 付録C: サポートされないLPD機能
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
Cのクラス、印刷されたS Symbolicが2がtroffする出力1troff R字体のpr W WidthのためにデータT TitleをリンクするときのクライアントMメールのバナーページI Indent Printing H Hostのために、I字体3はB字体4troff S字体をtroffします。
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のKerberizedクライアントのために予約されたPrint DVIファイルg Plotファイルkとサーバn Print ditroff出力ファイルp Printは、FORTRAN改行制御t Print troff出力ファイルv Printラスタファイルzがパラディアム印刷システムによる今後の使用のために予約されている状態で印刷するために'pr'形式r Fileと共にファイルします。
Herriot, et al. Experimental [Page 27] RFC 2569 Mapping between LPD and IPP Protocols April 1999
エリオ、他 1999年4月にLPDとIPPの間でプロトコルを写像する実験的な[27ページ]RFC2569
13. Full Copyright Statement
13. 完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Herriot, et al. Experimental [Page 28]
エリオ、他 実験的[28ページ]
一覧
スポンサーリンク
