rfc2569.txt

RFC 的详细文档！

Network Working Group                                         R. Herriot
Request For Comments: 2569                             Xerox Corporation
Category: Experimental                                         N. Jacobs
                                                  Sun Microsystems, Inc.
                                                             T. Hastings
                                                       Xerox Corporation
                                                               J. Martin
                                                        Underscore, Inc.
                                                              April 1999


                 Mapping between LPD and IPP Protocols

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   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.

   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.








Herriot, et al.               Experimental                      [Page 1]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


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.

   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.

   The full set of IPP documents includes:

      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.

   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.





Herriot, et al.               Experimental                      [Page 2]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


   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.

   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'.

   This document "Internet Printing Protocol/1.0: Implementer's Guide",
   gives advice to implementers of IPP clients and IPP objects.

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



Herriot, et al.               Experimental                      [Page 3]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


   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

1. Introduction

   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 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.

   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.

   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".

   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".





Herriot, et al.               Experimental                      [Page 4]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


   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.

2. Terminology

   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].

   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].

   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")

3. Mapping from LPD Commands to IPP Operations

   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.

   The following table summarizes the IPP operation that the mapper uses
   when it receives an LPD command. Each section below gives more
   detail:

      LPD command                IPP operation


      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









Herriot, et al.               Experimental                      [Page 5]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


3.1 Print any waiting jobs

   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.

   If the  mapper receives this LPD command, it SHALL ignore it and send
   no IPP operation.

3.2 Receive a printer job

   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.

   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.

   If the IPP printer supports both Create-Job and Send-Document, and if
   a job consists of:

      - 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.

   If the IPP printer does not support both Create-Job and Send-
   Document, and if a job consists of:

      - 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).




Herriot, et al.               Experimental                      [Page 6]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


   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.

   NOTE: This specification does not specify how the mapper maps: the
   LPD Printer-name operand to the IPP "printer-uri" operation
   attribute.

   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.2.1 Abort job

   Sub-command syntax:

      abort-job = %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.

   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.

   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.

3.2.2 Receive control file

   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>