rfc2569.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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.

   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.

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

   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


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.

   LPD function                       IPP
   name  value   description          name              value

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

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

   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

5.1 Print-Job

   The mapper SHALL send the following commands in the order listed
   below:

      - receive-a-printer-job command
      - both receive-control-file sub-command and receive-data-file
        sub-command (unspecified order, see Note below)
      - print-any-waiting-jobs command, except that if the mapper is
        sending a sequence of receive a printer-job commands, it MAY
        omit sending print-any-waiting-jobs after any receive a
        printer-job command that is neither the first nor last command
        in this sequence




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

   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.

   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.







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


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.

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.

5.4 Create-Job

   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.

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.

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.

5.7 Cancel-Job

   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


      - 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

   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

   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.

   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

   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

   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


   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.

   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.

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.

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

   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:






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.

   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

   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

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

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.

   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





Herriot, et al.               Experimental                     [Page 21]