[要約] 要約：RFC 2569は、LPD（Line Printer Daemon）とIPP（Internet Printing Protocol）の間のマッピングに関する情報を提供しています。 目的：このRFCの目的は、LPDとIPPの間でのプリンターの互換性を向上させるために、プロトコル間のマッピングを定義することです。
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
LPDとIPPプロトコル間のマッピング
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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は、このプロトコルの改訂版が提案された標準プロトコルとして公開されることを期待しています。提案された標準は、公開された場合、このメモで定義されているプロトコルから変更されると予想されます。特に、プロトコルの標準トラックバージョンには、強力な認証とプライバシーの機能が組み込まれ、「IPP：」URLタイプがこれらのセキュリティ対策をサポートする「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は、このプロトコルの実験、特に輸送層セキュリティ（TLS）[RFC 2246]と組み合わせて、IPPのセキュリティ層としてTLSを効果的に使用する方法を判断するのに役立ちます。
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つであり、新しいインターネット印刷プロトコル（IPP）のすべての側面を一緒に説明しています。IPPは、インターネットツールとテクノロジーを使用した分散印刷に使用できるアプリケーションレベルのプロトコルです。このドキュメントは、IPPとLPD（Line Printer Daemon）の間のゲートウェイの実装者にいくつかのアドバイスを提供します。このドキュメントでは、（1）RFC 1179で指定された「Line Printer Daemon（LPD）プロトコル」のコマンドとオペランドの間のマッピングと、（2）インターネット印刷プロトコル/1.0の操作、操作属性、およびジョブテンプレート属性の間のマッピングについて説明します。）。このドキュメントの目的の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.
警告：RFC 1179はIETF標準トラックにはありませんでした。RFC 1179は既存の慣行を記録することを目的としていましたが、一部の分野では不足していました。ただし、この仕様は、（1）RFC 1179および（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)
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に定義されている属性の正式なマッピングです。「Application/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で説明されている機能のコンテキスト内で既存の実践に対処します。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.
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プロトコルへのマッピングと、LPDプロトコルへのIPPプロトコルのマッピング。前者は「LPD-to-Ippマッパー」と呼ばれ、後者は「IPP-to-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は、2つのコンテキストで「コマンド」という単語を使用します。これは、ワイヤ操作とコマンドファイル機能の場合です。このドキュメントは、前者に「コマンド」という単語を使用し、後者には「関数」というフレーズを使用するものとします。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は％x0a（linefeed）SPの略です。（スペース）桁は％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.
このセクションでは、LPDコマンドからIPP操作へのマッピングについて説明します。次の各サブセクションは、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:
次の表は、Mapperが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
Print-Any-Waiting-Jobs Receid-A-Printer-Job Print-JobまたはCreate-Job/Send-Documen
Command syntax:
コマンド構文：
print-waiting-jobs = %x01 printer-name 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コマンドを受信した場合、それを無視し、IPP操作を送信しません。
Command syntax:
コマンド構文：
receive-job = %x02 printer-name 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.
- 単一のデータファイルまたは - create-job操作を含むprint-job操作に続いて、各データファイルに1つの送信ドキュメント操作が続きます。
If the IPP printer supports both Create-Job and Send-Document, and if a job consists of:
IPPプリンターがCreate-JobとSend-Documentの両方をサポートしている場合、およびジョブが構成されている場合：
- 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.
- 単一のデータファイルであるマッパーは、print-job操作を使用する必要がありますが、Create-JobおよびSend-Document操作を使用する場合があります。 - 複数のデータファイルを使用すると、MapperはCreate-Jobを使用して、受信したLPDデータファイルごとに1つの送信ドキュメントが続きます。
If the IPP printer does not support both Create-Job and Send-Document, and if a job consists of:
IPPプリンターがCreate-JobとSend-Documentの両方をサポートしていない場合、およびジョブが構成されている場合：
- 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).
- 単一のデータファイル、マッパーはprintjob操作を使用するものとします。 - 複数のデータファイルであるマッパーは、受信した各LPDデータファイルを別の印刷操作として送信するものとします（それにより、単一のLPDジョブを複数のIPPジョブに変換します）。
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.
MapperがCreate-JobとSend-Documentを使用している場合、Create-Jobに属性を提供するLPD制御ファイルがすべてのLPDデータファイルの前または後に到着するかどうかにかかわらず、送信ドキュメント操作を送信する前にCreate-Job操作を送信する必要があります。
NOTE: This specification does not specify how the mapper maps: the LPD Printer-name operand to the IPP "printer-uri" operation attribute.
注：この仕様では、Mapperマップ：IPP「プリンター-Ri」操作属性への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.
次の3つのサブセクションは、LPD Receid-A-Printer-Jobサブコマンドからのマッピングに関する詳細を示しています。次の各サブセクションは、RFC 1179のセクション6のサブセクションとして表示されます。
Sub-command syntax:
サブコマンドの構文：
abort-job = %x1 LF
This sub-command of receive-a-printer-job is intended to abort any job transfer in process.
受信a-printer-jobのこのサブコマンドは、プロセスの任意の求人を中止することを目的としています。
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でキャンセルジョブ操作を実行することにより、ジョブを終了します。Create-Job操作。
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 Receid-A-Printer-Jobリクエストを介して転送される前に終了する場合に暗示されています。
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>
This sub-command is roughly equivalent to the IPP Create-Job
operation.
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.
マッパーは、受信したLPD制御ファイルのコンテンツを使用して、IPP操作属性およびジョブテンプレート属性の値を作成して、印刷ジョブまたはCreate-Job操作で送信するものとします。
Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
サブコマンドの構文：％x3-in-bytes-in-data-file name-of-data-file
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>
This sub-command is roughly equivalent to the IPP Send-Document operation.
このサブコマンドは、IPP Send-Document操作とほぼ同等です。
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.
Mapperは、受信したLPDデータファイルのコンテンツをデータとして使用して、IPP Print-JobまたはSend-Document操作で送信します。
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
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.
このコマンドに対するMapperの応答には、プリンターとそのジョブに関する情報が含まれています。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
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.
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-to-Ippマッパーは、Get-Printer-Attributes操作を使用してプリンターステータスを取得し、Get-Jobs操作を使用してすべてのジョブに関する情報を取得する必要があります。LPDコマンドにジョブ数またはユーザー名が含まれている場合、マッパーは応答のフィルタリングを処理できます。LPDコマンドにジョブ数が含まれているがユーザー名が含まれていない場合、マッパーはget-jobsではなく変換された各ジョブ番号でget-job-attributesを使用する場合があります。LPDコマンドに単一のユーザー名が含まれているがジョブ数が含まれていない場合、マッパーはサーバーがこのオプションをサポートし、サーバーがクライアントがLPDユーザーのプロキシになることを許可する場合、My-JobsオプションでGet-Jobsを使用する場合があります。
NOTE: This specification does not define how the mapper maps the LPD Printer-name operand to the IPP "printer-uri" operation attribute.
注：この仕様では、マッパーがLPDプリンターネームオペランドをIPP「プリンター-RI」操作属性にマッピングする方法を定義するものではありません。
Command syntax:
コマンド構文：
send-queue-long = %x04 printer-name *(SP(user-name / job-number)) 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.
このコマンドに対するMapperの応答には、プリンターとそのジョブに関する情報が含まれています。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タイガー] 2コピー602バイト
smith: 1st [job 124 snail]
2 copies of resume 7088 bytes
2 copies of foo 10200 bytes
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.
長いフォームの形式は短い形式の形式とは異なりますが、それらのフィールドはa）長い形式のみのコピーとホストフィールド、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.
NOTE: This specification does not define how the mapper maps the LPD Printer-name operand to the IPP printer-uri operation attribute.
注：この仕様では、MapperがLPDプリンターネームオペランドをIPPプリンター-RI操作属性にマッピングする方法を定義するものではありません。
Command syntax:
コマンド構文：
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.
エージェントオペランドは、remove-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.
マッパーは、remove-jobsコマンドが参照する各ジョブに対して1つのキャンセルジョブ操作を発行するものとします。remove-jobsコマンドの各ジョブ番号は、単一のジョブを参照します。remove-jobsコマンドの各ユーザー名は、指定されたユーザーが所有するすべてのジョブを暗黙的に参照します。アクティブなジョブは、remove-jobsコマンドにジョブ数もユーザー名も含まれていない場合に暗黙的に参照されます。マッパーは、get-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.
マッパーは、エンドユーザーが自分のジョブをキャンセルした場合、「ルート」のエージェント名を使用してはなりません。この規則の違反は、潜在的なセキュリティ違反を生み出し、プリンターがユーザーに誤解を招く他の人が仕事をキャンセルしたと考えさせる通知を発行する可能性があります。
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のremove-jobsコマンドのエージェントが、ジョブJのコントロールファイルの「P」関数で指定されたユーザー名と同じである場合、マッパーはキャンセルジョブコマンドのイニシエーターがジョブ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操作の開始者として受信者が知覚する人に一貫している必要があることを意味します。マッパーはそれ自体として動作するか、別のユーザーに代わって行動します。後者は可能であれば好ましい。この一貫性は、Cancel-Jobが機能するためには、Print-Job/Create-JobとCancel-Jobの間で必要ですが、他の操作にも望ましいです。たとえば、Get-Jobsは、この操作の開始者によって提出されたジョブに関する詳細情報を提供する場合があります。
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）IPP「プリンター-URI」のLPDプリンター名、または（2）IPP「Job-URI」への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.
注：この仕様では、マッパーがジョブで独自のユーザー名を使用する可能性があるため、MapperがLPDユーザー名をIPPジョブオリジングユーザーにマッピングする方法を指定しません。
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.
このセクションでは、LPD制御ファイル行（「関数」と呼ばれる）からIPP操作属性およびジョブテンプレート属性へのマッピングについて説明します。マッパーは、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.
LPD制御ファイルラインでは、テキストオペランドの最大長は31または99ですが、IPP操作属性とジョブテンプレートの属性値は、属性構文に応じて最大255または1023オクテットです。したがって、データは失われません。
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:
マッパーは、サポートされている各LPD関数を、以下のサブセクションのテーブルで定義されているように、対応するIPP操作またはジョブテンプレート属性に変換します。これらのサブセクションは、次のかどうかに応じて機能します。
- 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
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
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-aTtribute-fidelity = trueを含めるものとします。
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 Jジョブ名のジョブ名JバナーページこのLPD機能をサポートするには、Get-Job-Attributes操作を使用してゲートウェイを投票する必要があります。
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.
マッパーは、ドキュメントの各コピーで必要なドキュメント関数のセットを1セットに受け取り、各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
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.
注：実際には、「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」関数をサポートする実装はありませんでした。代わりに、「F」がPostScriptに使用されました。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」、「L」、および「O」関数の値「FFF」は、転送されたデータファイルの名前です。「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.
マッパーは、上記の低ケース関数の1つを使用して、各「FFF」ファイルの発生数をカウントすることにより、コピーの数を決定します。たとえば、「f dfa123woden」が4回発生した場合、コピーの値は4になります。LPDプロトコルはコピーの値をドキュメントごとに異なることを許可しますが、コマンドと受信プリントシステムはこれをサポートしません。
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.
マッパーは、各ドキュメントで推奨されるドキュメント関数の1セットを受け取る必要があり、各IPPドキュメントに操作またはジョブテンプレート属性として変換された情報を含める必要があります。関数は「u」と「n」という順序で受信する必要がありますが、任意の順序で到着する場合があります。
LPD function IPP
name value description name value
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-to-LPDマッパーがIPP操作を受信した場合、次の表は、使用するLPDコマンドを要約します。以下の各セクションは詳細を示します。次の各サブセクションは、ドキュメント「インターネット印刷プロトコル/1.0：モデルとセマンティクス」[RFC2566]のセクション3のサブセクションとして表示されます。
IPP operation LPD command
IPP Operation 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
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
- 受信-a-printer-jobコマンド - 両方とも受信制御ファイルサブコマンドと受信-data-fileサブコマンド（不特定の注文、以下の注を参照） - マッパーの場合を除いて、印刷-Any-Waiting-Jobsコマンド一連のシーケンスを送信しているプリンタージョブコマンドを受信しています。このシーケンスの最初でも最後も最後のコマンドでもないプリンタージョブコマンドを受信した後、印刷物のジョブを送信することを省略する場合があります
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.
注：一部の印刷システムでは、いずれかの注文が失敗するため、受信制御ファイルサブコマンドと受信-Data-Fileサブコマンドの順序を構成可能にすることをお勧めします。一部の印刷システムは、コントロールファイルがすべてのデータファイルに従い、コントロールファイルの受領時に直ちに印刷を開始すると想定しています。そのような印刷システムが到着していないデータファイルを印刷しようとすると、エラーが発生します。他の印刷システムは、データファイルの前にコントロールファイルが到着し、最初のデータファイルが到着したときに印刷を開始すると想定しています。このようなシステムは、バナーページやコピーなどの制御情報を無視します。
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.
Mapperは、LPD受信制御ファイルサブコマンドを使用して、操作から受信したIPP操作属性とジョブテンプレート属性をLPDプリンターに送信するものとします。マッパーは、コントロールファイル名で使用するためにLPDジョブ数を作成するものとしますが、受信プリンターは、状況によっては、ジョブに異なるジョブ数を割り当てる場合があります。マッパーは、IPPジョブIDを作成し、IPPジョブリは印刷ジョブの応答で返されます。
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.
注：この仕様では、マッパーがLPDジョブ番号、IPPジョブID、またはそれが作成するジョブのIPPジョブリをどのように決定するかを指定していません。-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.
Mapperは、LPD受信-Data-Fileサブコマンドを使用して、IPP操作で受信したデータをLPDプリンターに送信するものとします。マッパーは、受信-Data-Fileサブコマンドの平均数フィールドに送信される正確なバイト数を指定するものとします。このフィールドでは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.
Mapperが受信-a-Printer-Jobコマンドまたはサブコマンドを送信している場合、IPP接続が閉じたか、キャンセルジョブ操作を受信したことを検出する場合、マッパーはAbort subでLPDジョブを終了するものとします。-commandまたはremove-jobsコマンド。
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.
マッパーは、「ドキュメントウリ」操作属性によって参照されるデータを取得し、印刷ジョブ操作を介して受信されたかのようにそのデータを扱うことを除いて、印刷操作と同じ方法でこの操作を処理するものとします。。
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:
マッパーは、次のことを除いて、この操作をprint-jobのように処理するものとします。
- 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.
- Mapperは、制御ファイルに、送信ドキュメントおよび送信-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.
Mapperは、受信したデータで受信データファイルサブコマンドを実行します。詳細については、前のセクション5.4 "Create-Job"を参照してください。
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.
Mapperは、「Document-URI」操作属性によって参照されるデータを取得し、その後、そのデータを送信ドキュメント操作を介して受信したかのように扱います。詳細については、前のセクション5.5「送信ドキュメント」を参照してください。
The mapper SHALL perform a remove-jobs command with the following operation attributes:
マッパーは、次の操作属性を使用してremove-jobsコマンドを実行するものとします。
- 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-Numberは、Print-Jobコマンドによって返されたJob-IDです。つまり、LPDのJob-Numberは、実装の可能性が高い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.
マッパーは、「send queue State」コマンドの長い形式または短い形式を使用します。
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.
注：Mapperは、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.
マッパーは、「send queue State」コマンドの長い形式または短い形式を使用します。「job-k-octets」または「コピー」のリクエストを受け取り、属性をサポートする場合、長いフォームを使用する場合。それ以外の場合は、短いフォームを使用するものとします。
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.
注：Job-K-OCTETの値は、短い形式の値を、長い形式のみにある「コピー」の数で割ったものです。その値は、ジョブの各ドキュメントの「サイズ」フィールド値を長い形式で追加することで決定することもできます。
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.
注：MapperがLPDショートフォームを使用すると、Get-Job-Attributes操作によって指定されたジョブに関連する単一のLPDラインからの応答を決定できます。
Note: the mapper can use its correspondence between the IPP job-id, job-uri and the LPD job-number.
注：Mapperは、IPP Job-ID、Job-URI、およびLPD Job-Numberの間の対応を使用できます。
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-Job-Attributesと同じ方法でこの操作を実行するものとします。
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制御ファイル行（「関数」と呼ばれる）へのジョブテンプレート属性について説明します。Mapperは、IPP操作を介してIPP操作属性とジョブテンプレートの抑制を受信します。IPPモデルドキュメント[RFC2566]のセクション3および4.2のサブセクションとして表示されるIPP操作属性とジョブテンプレート属性は、それぞれ表示されます。
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.
LPD制御ファイルラインのコンテキストでは、テキストオペランドの最大長は31または99ですが、IPP操作属性とジョブテンプレート属性は、属性の構文に応じて最大255または1023オクテットを持ちます。したがって、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
(perhaps in security h H gateway host Originating Host layer) requesting-user-name u P u User identification and in the security layer
（おそらくセキュリティH H H H Gateway Hostのホスト層を生み出します）リクエスト - ユーザー名Uユーザー識別とセキュリティレイヤー
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-jobsコマンドが来るホストと同じであることを要求するため、マッパーはクライアントのホストではなく独自のホストを送信するものとします。マッパーは、クライアントユーザーではなくユーザー識別として独自のユーザー名を送信する場合があります。ただし、いずれにせよ、送信された値は、LPD remove-Jobs操作と互換性があります。
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
job-name j J j Job name for banner page job-sheets 'standard' L u Print banner page job-sheets 'none' omit 'L' function Note: 'L' has special meaning when it is omitted. If 'J' is omitted, some undefined behavior occurs with respect to the banner page.
ジョブ名J J Jジョブ名のジョブシート「標準」の標準 'l uプリントバナーページジョブシートなし'省略「l」機能注： '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」、次に「n」でなければなりません。ここで、各コピーに対して「f」が1回複製されます。
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
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
注：マッパーは「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-aTtribute-fidelitybest-effort」を受け取らない場合、またはfalseの値がある場合、マッパーは、上記の表でサポートされていない属性または属性値を指定した場合、ジョブを拒否するものとします。
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 U dfB123woden N bar
H Tiger P Jones F DFA123WODEN F DFA123WODEN F DFA123WODEN U DFA123WODEN N FOO F DFB123WODEN F DFB123WODEN F DFB123WODEN U DFB123WODEN N BAR
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エンコードドキュメント[RFC2565]、IPPモデルドキュメント[RFC2566]、LPDドキュメント[RFC1179]でカバーされているもの以外にセキュリティの問題はありません。
[ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0: Implementer's Guide", Work in Progress.
[IPP-IIG] Hasting、T.、et al。、「Internet Printing Protocol/1.0：実装者ガイド」、進行中の作業。
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1759] Smith、R.、Wright、F.、Hastings、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] Bradner、S。
[RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] D. Crocker et al。、「構文仕様のための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] Herriot、R。、Butler、S.、Moore、P。and R. Tuner、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、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.、Hastings、T.、Herriot、R.、Isaacson、S。、およびP. Powell、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2566、1999年4月。
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC2567] Wright、D。、「インターネット印刷プロトコルの設計目標」、RFC 2567、1999年4月。
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2568] Zilles、S。、「インターネット印刷プロトコルの構造とモデルとプロトコルの理論的根拠」、RFC 2568、1999年4月。
Robert Herriot (Editor) Xerox Corporation 3400 Hillview Ave., Bldg #1 Palo Alto, CA 94304
Robert Herriot（編集者）Xerox Corporation 3400 Hillview Ave.、Bldg＃1 Palo Alto、CA 94304
Phone: 650-813-7696 Fax: 650-813-6860 EMail: rherriot@pahv.xerox.com
電話：650-813-7696ファックス：650-813-6860メール：rherriot@pahv.xerox.com
Norm Jacobs Sun Microsystems Inc. 1430 Owl Ridge Rd. Colorado Springs, CO 80919
Norm Jacobs Sun Microsystems Inc. 1430 Owl Ridge Rd。コロラドスプリングス、コロラド州80919
Phone: 719-532-9927 Fax: 719-535-0956 EMail: Norm.Jacobs@Central.sun.com
電話：719-532-9927ファックス：719-535-0956メール：norm.jacobs@central.sun.com
Thomas N. Hastings Xerox Corporation 701 S. Aviation Blvd., ESAE-231 El Segundo, CA 90245
トーマス・N・ヘイスティングス・ゼロックス・コーポレーション701 S. Aviation Blvd.、ESAE-231 El Segundo、CA 90245
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
電話：310-333-6413ファックス：310-333-5514メール：hastings@cp10.es.xerox.com
Jay Martin Underscore, Inc. 41-C Sagamore Park Road Hudson, NH 03051-4915
Jay Martin Underscore、Inc。41-C Sagamore Park Road Hudson、NH 03051-4915
Phone: 603-889-7000 Fax: 603-889-2699 EMail: jkm@underscore.com
電話：603-889-7000ファックス：603-889-2699メール：jkm@underscore.com
The syntax in ABNF for the response to the LPD command 'send-queue-state (long)' is:
LPDコマンド「Send-Queue-state（long）」への応答の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
The syntax in ABNF for the response to the LPD command 'send-queue-state (long)' is:
LPDコマンド「Send-Queue-state（long）」への応答の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.
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-to-Ippマッパーはそれらを無視し、IPP-to-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バナーページのクラスIインデント印刷hクライアントMメールのホスト印刷時のシンボリックリンクデータタイト
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-to-Ipp Mapperは、そのようなドキュメント形式を要求するジョブを拒否し、IPP-to-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 kerberizedクライアントとサーバー用の予約n n印刷ditroff出力ファイルp印刷ファイルfortranキャリッジコントロールで印刷するrファイル。Palladium Print Systemで将来使用するため
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。