Load cups into easysw/current.
[thirdparty/cups.git] / standards / rfc2569.txt
1
2
3
4
5
6
7 Network Working Group                                         R. Herriot
8 Request For Comments: 2569                             Xerox Corporation
9 Category: Experimental                                         N. Jacobs
10                                                   Sun Microsystems, Inc.
11                                                              T. Hastings
12                                                        Xerox Corporation
13                                                                J. Martin
14                                                         Underscore, Inc.
15                                                               April 1999
16
17
18                  Mapping between LPD and IPP Protocols
19
20 Status of this Memo
21
22    This memo defines an Experimental Protocol for the Internet
23    community.  It does not specify an Internet standard of any kind.
24    Discussion and suggestions for improvement are requested.
25    Distribution of this memo is unlimited.
26
27 Copyright Notice
28
29    Copyright (C) The Internet Society (1999).  All Rights Reserved.
30
31 IESG Note
32
33    This document defines an Experimental protocol for the Internet
34    community.  The IESG expects that a revised version of this protocol
35    will be published as Proposed Standard protocol.  The Proposed
36    Standard, when published, is expected to change from the protocol
37    defined in this memo.  In particular, it is expected that the
38    standards-track version of the protocol will incorporate strong
39    authentication and privacy features, and that an "ipp:" URL type will
40    be defined which supports those security measures.  Other changes to
41    the protocol are also possible.  Implementors are warned that future
42    versions of this protocol may not interoperate with the version of
43    IPP defined in this document, or if they do interoperate, that some
44    protocol features may not be available.
45
46    The IESG encourages experimentation with this protocol, especially in
47    combination with Transport Layer Security (TLS) [RFC 2246], to help
48    determine how TLS may effectively be used as a security layer for
49    IPP.
50
51
52
53
54
55
56
57
58 Herriot, et al.               Experimental                      [Page 1]
59 \f
60 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
61
62
63 Abstract
64
65    This document is one of a set of documents, which together describe
66    all aspects of a new Internet Printing Protocol (IPP). IPP is an
67    application level protocol that can be used for distributed printing
68    using Internet tools and technologies. This document gives some
69    advice to implementers of gateways between IPP and LPD (Line Printer
70    Daemon). This document describes the mapping between (1) the commands
71    and operands of the 'Line Printer Daemon (LPD) Protocol' specified in
72    RFC 1179 and (2) the operations, operation attributes and job
73    template attributes of the Internet Printing Protocol/1.0 (IPP).  One
74    of the purposes of this document is to compare the functionality of
75    the two protocols.  Another purpose is to facilitate implementation
76    of gateways between LPD and IPP.
77
78    WARNING: RFC 1179 was not on the IETF standards track.  While RFC
79    1179 was intended to record existing practice, it fell short in some
80    areas.  However, this specification maps between (1) the actual
81    current practice of RFC 1179 and (2) IPP.  This document does not
82    attempt to map the numerous divergent extensions to the LPD protocol
83    that have been made by many implementers.
84
85    The full set of IPP documents includes:
86
87       Design Goals for an Internet Printing Protocol [RFC2567]
88       Rationale for the Structure and Model and Protocol for the
89       Internet Printing Protocol [RFC2568]
90       Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
91       Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
92       Internet Printing Protocol/1.0: Implementors Guide [ipp-iig]
93       Mapping between LPD and IPP Protocols (this document)
94
95    The document, "Design Goals for an Internet Printing Protocol", takes
96    a broad look at distributed printing functionality, and it enumerates
97    real-life scenarios that help to clarify the features that need to be
98    included in a printing protocol for the Internet. It identifies
99    requirements for three types of users: end users, operators, and
100    administrators. It calls out a subset of end user requirements that
101    are satisfied in IPP/1.0. Operator and administrator requirements are
102    out of scope for version 1.0.
103
104    The document, "Rationale for the Structure and Model and Protocol for
105    the Internet Printing Protocol", describes IPP from a high level
106    view, defines a roadmap for the various documents that form the suite
107    of IPP specifications, and gives background and rationale for the
108    IETF working group's major decisions.
109
110
111
112
113
114 Herriot, et al.               Experimental                      [Page 2]
115 \f
116 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
117
118
119    The document, "Internet Printing Protocol/1.0: Model and Semantics",
120    describes a simplified model with abstract objects, their attributes,
121    and their operations. It introduces a Printer and a Job object. The
122    Job object supports multiple documents per Job. It also addresses
123    security, internationalization, and directory issues.
124
125    The document, "Internet Printing Protocol/1.0: Encoding and
126    Transport", is a formal mapping of the abstract operations and
127    attributes defined in the model document onto HTTP/1.1. It defines
128    the encoding rules for a new Internet media type called '
129    application/ipp'.
130
131    This document "Internet Printing Protocol/1.0: Implementer's Guide",
132    gives advice to implementers of IPP clients and IPP objects.
133
134 TABLE OF CONTENTS
135
136    1. Introduction.....................................................4
137    2. Terminology......................................................5
138    3. Mapping from LPD Commands to IPP Operations......................5
139    3.1 Print any waiting jobs..........................................6
140    3.2 Receive a printer job...........................................6
141    3.2.1 Abort job.....................................................7
142    3.2.2 Receive control file..........................................7
143    3.2.3 Receive data file.............................................8
144    3.3 Send queue state (short)........................................8
145    3.4 Send queue state (long)........................................10
146    3.5 Remove jobs....................................................12
147    4. Mapping of LPD Control File Lines to IPP Operation and Job
148       Template Attributes.............................................13
149    4.1 Required Job Functions.........................................13
150    4.2 Optional Job Functions.........................................14
151    4.3 Required Document Functions....................................14
152    4.4 Recommended Document Functions.................................16
153    5. Mapping from IPP operations to LPD commands.....................16
154    5.1 Print-Job......................................................16
155    5.2 Print-URI......................................................18
156    5.3 Validate-Job...................................................18
157    5.4 Create-Job.....................................................18
158    5.5 Send-Document..................................................18
159    5.6 Send-URI.......................................................18
160    5.7 Cancel-Job.....................................................18
161    5.8 Get-Printer-Attributes.........................................19
162    5.9 Get-Job-Attributes.............................................19
163    5.10 Get-Jobs......................................................20
164    6. Mapping of IPP Attributes to LPD Control File Lines.............20
165    6.1 Required Job Functions.........................................21
166    6.2 Optional Job Functions.........................................21
167
168
169
170 Herriot, et al.               Experimental                      [Page 3]
171 \f
172 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
173
174
175    6.3 Required Document Functions....................................22
176    7. Security Considerations.........................................23
177    8. References......................................................23
178    9. Authors' Addresses..............................................24
179    10.Appendix A: ABNF Syntax for response of Send-queue-state (short)25
180    11.Appendix B: ABNF Syntax for response of Send-queue-state (long) 26
181    12.Appendix C: Unsupported LPD functions...........................27
182    13.Full Copyright Statement........................................28
183
184 1. Introduction
185
186    The reader of this specification is expected to be familiar with the
187    IPP Model and Semantics specification [RFC2566], the IPP Encoding and
188    Transport [RF2565], and the Line Printer Daemon (LPD) protocol
189    specification [RFC1179] as described in RFC 1179.
190
191    RFC 1179 was written in 1990 in an attempt to document existing LPD
192    protocol implementations.  Since then, a number of undocumented
193    extensions have been made by vendors to support functionality
194    specific to their printing solutions.  All of these extensions
195    consist of additional control file commands.  This document does not
196    address any of these vendor extensions.  Rather it addresses existing
197    practice within the context of the features described by RFC 1179.
198    Deviations of existing practice from RFC 1179 are so indicated.
199
200    Other LPD control file commands in RFC 1179 are obsolete. They are
201    intended to work on "text" only formats and are inappropriate for
202    many contemporary document formats that completely specify each page.
203    This document does not address the support of these obsolete
204    features.
205
206    In the area of document formats, also known as page description
207    languages (PDL), RFC 1179 defines a fixed set with no capability for
208    extension.  Consequently, some new PDL's are not supported, and some
209    of those that are supported are sufficiently unimportant now that
210    they have not been registered for use with the Printer MIB [RFC1759]
211    and IPP [RFC2566] [RFC2565], though they could be registered if
212    desired.  See the Printer MIB specification [RFC1759] and/or the IPP
213    Model specification [RFC2566] for instructions for registration of
214    document-formats with IANA.  IANA lists the registered document-
215    formats as "printer languages".
216
217    This document addresses the protocol mapping for both directions:
218    mapping of the LPD protocol to the IPP protocol and mapping of the
219    IPP protocol to the LPD protocol. The former is called the "LPD-to-
220    IPP mapper" and the latter is called the "IPP-to-LPD mapper".
221
222
223
224
225
226 Herriot, et al.               Experimental                      [Page 4]
227 \f
228 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
229
230
231    This document is an informational document that is not on the
232    standards track.  It is intended to help implementers of gateways
233    between IPP and LPD.  It also provides an example, which gives
234    additional insight into IPP.
235
236 2. Terminology
237
238    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
239    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
240    document are to be interpreted as described in RFC 2119 [RFC2119].
241
242    RFC 1179 uses the word "command" in two contexts: for over-the-wire
243    operations and for command file functions. This document SHALL use
244    the word "command" for the former and the phrase "functions" for the
245    latter.  The syntax of the LPD commands is given using ABNF
246    [RFC2234].
247
248    The following tokens are used in order to make the syntax more
249    readable:
250
251       LF stands for %x0A (linefeed)
252       SP stands for %x20.  (space)
253       DIGIT stands for %x30-39 ("0" to "9")
254
255 3. Mapping from LPD Commands to IPP Operations
256
257    This section describes the mapping from LPD commands to IPP
258    operations.  Each of the following sub-sections appear as sub-
259    sections of section 5 of RFC 1179.
260
261    The following table summarizes the IPP operation that the mapper uses
262    when it receives an LPD command. Each section below gives more
263    detail:
264
265       LPD command                IPP operation
266
267
268       print-any-waiting-jobs     ignore
269       receive-a-printer-job      Print-Job or Create-Job/Send-Document
270             send queue state       Get-Printer-Attributes and Get-Jobs
271               (short or long)
272             remove-jobs          Cancel-Job
273
274
275
276
277
278
279
280
281
282 Herriot, et al.               Experimental                      [Page 5]
283 \f
284 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
285
286
287 3.1 Print any waiting jobs
288
289    Command syntax:
290
291      print-waiting-jobs = %x01 printer-name LF
292
293    This command causes the LPD daemon check its queue and print any
294    waiting jobs. An IPP printer handles waiting jobs without such a
295    nudge.
296
297    If the  mapper receives this LPD command, it SHALL ignore it and send
298    no IPP operation.
299
300 3.2 Receive a printer job
301
302    Command syntax:
303
304      receive-job = %x02 printer-name LF
305
306    The control file and data files mentioned in the following paragraphs
307    are received via LPD sub-commands that follow this command. Their
308    mapping to IPP commands and attributes is described later in this
309    section.
310
311    The mapper maps the 'Receive a printer job' command to either:
312
313       - the Print-Job operation which includes a single data file or
314       - the Create-Job operation followed by one Send-Document operation
315         for each data file.
316
317    If the IPP printer supports both Create-Job and Send-Document, and if
318    a job consists of:
319
320       - a single data file, the mapper SHOULD use the Print-Job
321         operation, but MAY use the Create-Job and Send-Document
322         operations.
323       - more than one data file, the mapper SHALL use Create-Job
324         followed by one Send-Document for each received LPD data file.
325
326    If the IPP printer does not support both Create-Job and Send-
327    Document, and if a job consists of:
328
329       - a single data file, the mapper SHALL use the PrintJob
330         operation.
331       - more than one data file, the mapper SHALL submit each received
332         LPD data file as a separate Print-Job operation (thereby
333         converting a single LPD job into multiple IPP jobs).
334
335
336
337
338 Herriot, et al.               Experimental                      [Page 6]
339 \f
340 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
341
342
343    If the mapper uses Create-Job and Send-Document, it MUST send the
344    Create-Job operation before it sends any Send-Document operations
345    whether the LPD control file, which supplies attributes for Create-
346    Job, arrives before or after all LPD data files.
347
348    NOTE: This specification does not specify how the mapper maps: the
349    LPD Printer-name operand to the IPP "printer-uri" operation
350    attribute.
351
352    The following three sub-sections gives further details about the
353    mapping from LPD receive-a-printer-job sub-commands.  Each of the
354    following subsections appear as sub-sections of section 6 of RFC
355    1179.
356
357 3.2.1 Abort job
358
359    Sub-command syntax:
360
361       abort-job = %x1 LF
362
363    This sub-command of receive-a-printer-job is intended to abort any
364    job transfer in process.
365
366    If the mapper receives this sub-command, it SHALL cancel the job that
367    it is in the process of transmitting.
368
369    If the mapper is in the process of sending a Print-Job or Create-Job
370    operation, it terminates the job either by closing the connection, or
371    performing the Cancel-Job operation with the job-uri that it received
372    from the Print-Job or Create-Job operation.
373
374    NOTE: This sub-command is implied if at any time the connection
375    between the LPD client and server is terminated before an entire
376    print job has been transferred via an LPD Receive-a-printer-job
377    request.
378
379 3.2.2 Receive control file
380
381    Sub-command syntax:
382
383    receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
384    number-of-bytes = 1*DIGIT
385    name-of-control-file = "cfA" job-number client-host-name
386                           ; e.g. "cfA123woden"
387    job-number = 3DIGIT
388    client-host-name = <a host name>
389
390
391
392
393
394 Herriot, et al.               Experimental                      [Page 7]
395 \f
396 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
397
398
399    This sub-command is roughly equivalent to the IPP Create-Job
400    operation.
401
402    The mapper SHALL use the contents of the received LPD control file to
403    create IPP operation attribute and job template attribute values to
404    transmit with the Print-Job or Create-Job operation.
405
406 3.2.3 Receive data file
407
408 Sub-command syntax:  %x3 number-of-bytes-in-data-file Name-of-data-file
409
410    receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
411    number-of-bytes = 1*DIGIT
412    name-of-data-file = "df" letter job-number client-host-name
413                ; e.g. "dfA123woden for the first file
414    letter = %x41-5A /  %x61-7A    ;  "A" to "Z", "a" to "z"
415                                   ;  first file is "A",
416                                   ; second "B", and  52nd file is "z"
417    job-number = 3DIGIT
418    client-host-name = <a host name>
419
420    This sub-command is roughly equivalent to the IPP Send-Document
421    operation.
422
423    The mapper SHALL use the contents of the received LPD data file as
424    the data to transmit with the IPP Print-Job or Send-Document
425    operation.
426
427    Although RFC 1179 alludes to a method for passing an unspecified
428    length data file by using an octet-count of zero, no implementations
429    support this feature. The mapper SHALL reject a job that has a value
430    of 0 in the number-of-bytes field.
431
432 3.3 Send queue state (short)
433
434    Command syntax:
435
436 send-queue-short  = %x03 printer-name *(SP(user-name / job-number)) LF
437
438    The mapper's response to this command includes information about the
439    printer and its jobs. RFC 1179 specifies neither the information nor
440    the format of its response. This document requires the mapper to
441    follow existing practice as specified in this document.
442
443    The mapper SHALL produce a response in the following format which
444    consists of a printer-status line optionally followed by a heading
445    line, and a list of jobs. This format is defined by examples below.
446    Appendix A contains the ABNF syntax.
447
448
449
450 Herriot, et al.               Experimental                      [Page 8]
451 \f
452 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
453
454
455    For an printer with no jobs, the response starts in column 1 and is:
456
457       no entries
458
459    For a printer with jobs, an example of the response is:
460
461      killtree is ready and printing
462      Rank   Owner      Job          Files             Total Size
463      active fred       123          stuff             1204 bytes
464      1st    smith      124          resume, foo       34576 bytes
465      2nd    fred       125          more              99 bytes
466      3rd    mary       126          mydoc             378 bytes
467      4th    jones      127          statistics.ps     4567 bytes
468      5th    fred       128          data.txt          9 bytes
469
470    The column numbers of above headings and job entries are:
471
472      |      |          |            |                 |
473      01     08         19           35                63
474
475    The mapper SHALL produce each field above from the following IPP
476    attribute:
477
478    LPD field IPP attribute          special conversion details
479
480    printer-  printer-state and      For a printer-state of idle or
481    status    printer-state-reasons  processing, the mapper SHALL use
482                                     the formats above.  For stopped,
483                                     the mapper SHALL use printer-
484                                     state-reasons to produce an
485                                     unspecified format for the error.
486    rank      number-of-             the mapper SHALL the format above
487              intervening-jobs
488    owner     job-originating-user-  unspecified conversion; job-
489              name                   originating-user-name may be the
490                                     mapper's user-name
491    job       job-id                 the mapper shall use the job-id
492    files     document-name          the mapper shall create a comma
493                                     separated list of the document-
494                                     names and then truncate this list
495                                     to the first 24 characters
496    total-    job-k-                 the mapper shall multiple the
497    size      octets*copies*1024     value of job-k-octets by 1024 and
498                                     by the value of the "copies"
499                                     attribute.
500
501
502
503
504
505
506 Herriot, et al.               Experimental                      [Page 9]
507 \f
508 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
509
510
511    A mapper SHOULD use the job attribute number-of-intervening-jobs
512    rather than the job's position in a list of jobs to determine 'rank'
513    because a Printer may omit jobs that it wants to keep secret. If a
514    printer doesn't support the job attribute number-of-intervening-jobs,
515    a mapper MAY use the job's position.
516
517    Note: a Printer may set the value of job-originating-user-name to the
518    authenticated user or to the value of "requesting-user-name",
519    depending on the implementation and configuration. For a gateway, the
520    authenticated user is the user-id of the gateway, but the
521    "requesting-user-name" may contain the name of the user who is the
522    gateway's client.
523
524    In order to obtain the information specified above, The LPD-to-IPP
525    mapper SHALL use the Get-Printer-Attributes operation to get
526    printer-status and SHOULD use the Get-Jobs operation to get
527    information about all of the jobs. If the LPD command contains job-
528    numbers or user-names, the mapper MAY handle the filtering of the
529    response. If the LPD command contains job-numbers but no user-names,
530    the mapper MAY use Get-Job-Attributes on each converted job-number
531    rather than Get-Jobs. If the LPD command contains a single user-name
532    but no job-numbers, the mapper MAY use Get-Jobs with the my-jobs
533    option if the server supports this option and if the server allows
534    the client to be a proxy for the LPD user.
535
536    NOTE: This specification does not define how the mapper maps the LPD
537    Printer-name operand to the IPP "printer-uri" operation attribute.
538
539 3.4 Send queue state (long)
540
541    Command syntax:
542
543    send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
544
545    The mapper's response to this command includes information about the
546    printer and its jobs. RFC 1179 specifies neither the information nor
547    the format of its response. This document requires the mapper to
548    follow existing practice as specified in this document.
549
550    The mapper SHALL produce a response in the following format which
551    consists of a printer-status line optionally followed a list of jobs,
552    where each job consists of a blank line, a description line, and one
553    line for each file. The description line contains the user-name,
554    rank, job-number and host. This format is defined by examples below.
555    Appendix B contain the ABNF syntax.
556
557
558
559
560
561
562 Herriot, et al.               Experimental                     [Page 10]
563 \f
564 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
565
566
567    For an printer with no jobs the response is:
568
569       no entries
570
571    For a printer with jobs, an example of the response is:
572
573       killtree is ready and printing
574
575       fred: active                        [job 123 tiger]
576               2 copies of stuff           602 bytes
577
578       smith: 1st                          [job 124 snail]
579               2 copies of resume          7088 bytes
580               2 copies of foo             10200 bytes
581
582       fred: 2nd                           [job 125 tiger]
583               more                        99 bytes
584
585       The column numbers of above headings and job entries are:
586
587       |       |                           |
588       01      09                          41
589
590    Although the format of the long form is different from the format of
591    the short form, their fields are identical except for a) the copies
592    and host fields which are only in the long form, and b) the "size"
593    field contains the single copy size of each file.  Thus the sum of
594    the file sizes in the "size" field times the value of the "copies"
595    field produces the value for the "Total Size" field in the short
596    form. For fields other than the host and copies fields, see the
597    preceding section.  For the host field see the table below.
598
599       LPD field IPP attribute        special conversion details
600
601       host                           unspecified conversion; job-
602                                      originating-host may be the
603                                      mapper's host
604       copies    copies               the mapper shall assume the
605                                      value of copies precedes the
606                                      string "copies of "; otherwise,
607                                      the value of copies is 1.
608
609    NOTE: This specification does not define how the mapper maps the LPD
610    Printer-name operand to the IPP printer-uri operation attribute.
611
612
613
614
615
616
617
618 Herriot, et al.               Experimental                     [Page 11]
619 \f
620 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
621
622
623 3.5 Remove jobs
624
625    Command syntax:
626
627       remove-jobs = %x05 printer-name SP agent
628                           *(SP(user-name / job-number)) LF
629
630    The agent operand is the user-name of the user initiating the
631    remove-jobs command. The special user-name 'root' indicates a
632    privileged user who can remove jobs whose user-name differs from the
633    agent.
634
635    The mapper SHALL issue one Cancel-Job operation for each job
636    referenced by the remove-jobs command. Each job-number in the
637    remove-jobs command references a single job. Each user-name in the
638    remove-jobs command implicitly references all jobs owned by the
639    specified user. The active job is implicitly referenced when the
640    remove-jobs command contains neither job-numbers nor user-names. The
641    mapper MAY use Get-Jobs to determine the job-uri of implicitly
642    referenced jobs.
643
644    The mapper SHALL not use the agent name of 'root' when end-users
645    cancel their own jobs.  Violation of this rule creates a potential
646    security violation, and it may cause the printer to issue a
647    notification that misleads a user into thinking that some other
648    person canceled the job.
649
650    If the agent of a remove-jobs command for a job J is the same as the
651    user name specified with the 'P' function in the control file for job
652    J, then the mapper SHALL ensure that the initiator of the Cancel-Job
653    command for job J is the same as job-originating-user for job J.
654
655    Note: This requirement means that a mapper must be consistent in who
656    the receiver perceives as the initiator of IPP operations. The mapper
657    either acts as itself or acts on behalf of another user. The latter
658    is preferable if it is possible. This consistency is necessary
659    between Print-Job/Create-Job and Cancel-Job in order for Cancel-Job
660    to work, but it is also desirable for other operations. For example,
661    Get-Jobs may give more information about job submitted by the
662    initiator of this operation.
663
664    NOTE: This specification does not define how the mapper maps: (1) the
665    LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number
666    to the IPP "job-uri".
667
668    NOTE: This specification does not specify how the mapper maps the LPD
669    user-name to the IPP job-originating-user because the mapper may use
670    its own user-name with jobs.
671
672
673
674 Herriot, et al.               Experimental                     [Page 12]
675 \f
676 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
677
678
679 4. Mapping of LPD Control File Lines to IPP Operation and Job Template
680    Attributes
681
682    This section describes the mapping from LPD control file lines
683    (called 'functions') to IPP operation attributes and job template
684    attributes.  The mapper receives the control file lines via the LPD
685    receive-control-file sub-command.  Each of the LPD functions appear
686    as sub-sections of section 7 of RFC 1179.
687
688    In LPD control file lines, the text operands have a maximum length of
689    31 or 99 while IPP operation attribute and job template attribute
690    values have a maximum of 255 or 1023 octets, depending on the
691    attribute syntax.  Therefore, no data is lost.
692
693    The mapper converts each supported LPD function to its corresponding
694    IPP operation or job template attribute as defined by tables in the
695    subsections that follow. These subsections group functions according
696    to whether they are:
697
698       - required with a job,
699       - optional with a job
700       - required with each document.
701
702    In the tables below, each LPD value is given a name, such as 'h'. If
703    an IPP value uses the LPD value, then the IPP value column contains
704    the LPD name, such as 'h' to denote this.  Otherwise, the IPP value
705    column specifies the literal value.
706
707 4.1 Required Job Functions
708
709    The following LPD functions MUST be in a received LPD job. The mapper
710    SHALL receive each of the following LPD functions and SHALL include
711    the information as a operation or job template attribute with each
712    IPP job.  The functions SHOULD be in the order 'H', 'P' and they
713    SHOULD be the first two functions in the control file, but they MAY
714    be anywhere in the control file and in any order:
715
716    LPD function                     IPP
717    name value   description         name          value
718
719    H    h       Originating Host                  h (in security layer)
720    P    u       User identification requesting-   u (and in security
721                                     user-name     layer)
722                 none                ipp-          'true'
723                                     attribute-
724                                     fidelity
725
726
727
728
729
730 Herriot, et al.               Experimental                     [Page 13]
731 \f
732 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
733
734
735    A mapper MAY send its own host rather than the client's host, and a
736    mapper MAY send its own user-name as user identification rather than
737    the client user. But in any case, the values sent SHALL be compatible
738    with the Cancel-Job operation. The IPP operation MAY have no way to
739    specify an originating host-name.
740
741    The mapper SHALL include ipp-attribute-fidelity = true so that it
742    doesn't have to determine which attributes a printer supports.
743
744 4.2 Optional Job Functions
745
746    The following LPD functions MAY be present in a received job. These
747    functions SHOULD follow the required job functions and precede the
748    document functions, but they MAY be anywhere in the control file.
749
750    If the mapper receives such an LPD function, the mapper SHALL include
751    the corresponding IPP attribute with the value converted as specified
752    in the table below.  If the mapper does not receive such an LPD
753    attribute, the mapper SHALL NOT include the corresponding IPP
754    attribute, except the 'L' LPD function whose absence has a special
755    meaning as noted in the table.
756
757    LPD function                  IPP
758    name value  description       name         value
759
760    J    j      Job name for      job-name     j
761                banner page
762    L    l      Print banner page job-sheets   'standard' if 'L' is
763                                               present
764                                               'none' if 'L' is present
765    M    m      Mail When Printed              IPP has no notification
766                                               mechanism. To support
767                                               this LPD feature, the
768                                               gateway must poll using
769                                               the Get-Job-Attributes
770                                               operation.
771
772 4.3 Required Document Functions
773
774    The mapper SHALL receive one set of the required document functions
775    with each copy of a document, and SHALL include the converted
776    information as operation or job template attributes with each IPP
777    document.
778
779    If the control file contains required and recommended document
780    functions, the required functions SHOULD precede the recommended ones
781    and if the job contains multiple documents, all the functions for
782
783
784
785
786 Herriot, et al.               Experimental                     [Page 14]
787 \f
788 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
789
790
791    each document are grouped together as shown in the example of section
792    6.3 "Required Document Functions". However, the document functions
793    MAY be in any order.
794
795    LPD function                   IPP
796    name value description         name             value
797
798    f     fff  Print formatted     document-format  'application/octet-
799               file                                 stream'
800    l     fff  Print file leaving  document-format  'application/octet-
801               control characters                   stream'
802    o     fff  Print Postscript    document-format  'application/PostScri
803               output file                          pt'
804                                   copies           see note
805
806    Note: In practice, the 'f' LPD function is often overloaded. It is
807    often used with any format of document data including PostScript and
808    PCL data.
809
810    Note: In practice, the 'l' LPD function is often used as a rough
811    equivalent to the 'f' function.
812
813    Note: When RFC 1179 was written, no implementation supported the 'o'
814    function; instead 'f' was used for PostScript. Windows NT now sends '
815    o' function for a PostScript file.
816
817    Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name
818    of the data file as transferred, e.g. "dfA123woden".
819
820    If the mapper receives any other lower case letter, the mapper SHALL
821    reject the job because the document contains a format that the mapper
822    does not support.
823
824    The mapper determines the number of copies by counting the number of
825    occurrences of each 'fff' file with one of the lower-case functions
826    above. For example, if 'f dfA123woden' occurs 4 times, then copies
827    has a value of 4. Although the LPD protocol allows the value of
828    copies to be different for each document, the commands and the
829    receiving print systems don't support this.
830
831
832
833
834
835
836
837
838
839
840
841
842 Herriot, et al.               Experimental                     [Page 15]
843 \f
844 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
845
846
847 4.4 Recommended Document Functions
848
849    The mapper SHOULD receive one set of the recommended document
850    functions with each document, and SHOULD include the converted
851    information as an operation or job template attribute with each IPP
852    document. The functions SHOULD be received in the order 'U' and 'N',
853    but they MAY arrive in any order.
854
855    LPD function                       IPP
856    name  value   description          name              value
857
858    U     fff                          ignored
859    N     n       Name of source file  document-name     n
860
861    Note: the value 'fff' of the 'U' function is the name of the data
862    file as transferred, e.g. "dfA123woden".
863
864 5. Mapping from IPP operations to LPD commands
865
866    If the IPP-to-LPD mapper receives an IPP operation, the following
867    table summarizes the LPD command that it uses. Each section below
868    gives the detail. Each of the following sub-sections appear as sub-
869    sections of section 3 in the document "Internet Printing
870    Protocol/1.0: Model and Semantics" [RFC2566].
871
872    IPP operation                     LPD command
873
874    Print-Job or Print-URI or         receive-a-printer-job
875    Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
876    Validate-Job                      implemented by the mapper
877    Cancel-Job                        remove-jobs
878    Get-Printer-Attributes, Get-Job-  send queue state (short or long)
879    Attributes or Get-Jobs
880
881 5.1 Print-Job
882
883    The mapper SHALL send the following commands in the order listed
884    below:
885
886       - receive-a-printer-job command
887       - both receive-control-file sub-command and receive-data-file
888         sub-command (unspecified order, see Note below)
889       - print-any-waiting-jobs command, except that if the mapper is
890         sending a sequence of receive a printer-job commands, it MAY
891         omit sending print-any-waiting-jobs after any receive a
892         printer-job command that is neither the first nor last command
893         in this sequence
894
895
896
897
898 Herriot, et al.               Experimental                     [Page 16]
899 \f
900 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
901
902
903    Note: it is recommended that the order of the receive-control-file
904    subcommand and the receive-data-file sub-command be configurable
905    because either order fails for some print systems. Some print systems
906    assume that the control file follows all data files and start
907    printing immediately on receipt of the control file. When such a
908    print system tries to print a data file that has not arrived, it
909    produces an error.  Other print systems assume that the control file
910    arrives before the data files and start printing when the first data
911    file arrives. Such a system ignores the control information, such as
912    banner page or copies.
913
914    NOTE: This specification does not define the mapping between the IPP
915    printer-uri and the LPD printer-name.
916
917    The mapper SHALL send the IPP operation attributes and job template
918    attributes received from the operation to the LPD printer by using
919    the LPD receive-control-file sub-command. The mapper SHALL create the
920    LPD job-number for use in the control file name, but the receiving
921    printer MAY, in some circumstances, assign a different job-number to
922    the job.  The mapper SHALL create the IPP job-id and IPP job-uri
923    returned in the Print-Job response.
924
925    NOTE: This specification does not specify how the mapper determines
926    the LPD job-number, the IPP job-id or the IPP job-uri of a job that
927    it creates nor does it specify the relationship between the IPP job-
928    uri, IPP the job-id and the LPD job-number, both of which the mapper
929    creates.  However, it is likely that the mapper will use the same
930    integer value for both the LPD job-number and the IPP job-id, and
931    that the IPP Job-uri is the printer's URI with the job-id
932    concatenated on the end.
933
934    The mapper SHALL send data received in the IPP operation to the LPD
935    printer by using the LPD receive-data-file sub-command. The mapper
936    SHALL specify the exact number of bytes being transmitted in the
937    number-of-bytes field of the receive-data-file sub-command. It SHALL
938    NOT use a value of 0 in this field.
939
940    If the mapper, while it is transmitting a receive-a-printer-job
941    command or sub-command, either detects that its IPP connection has
942    closed or receives a Cancel-Job operation, the mapper SHALL terminate
943    the LPD job either with the abort sub-command or the remove-jobs
944    command.
945
946    This document does not address error code conversion.
947
948
949
950
951
952
953
954 Herriot, et al.               Experimental                     [Page 17]
955 \f
956 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
957
958
959 5.2 Print-URI
960
961    The mapper SHALL handle this operation in the same way as a Print-Job
962    operation except that it SHALL obtain data referenced by the
963    "document-uri" operation attribute and SHALL then treat that data as
964    if it had been received via a Print-Job operation.
965
966 5.3 Validate-Job
967
968    The mapper SHALL perform this operation directly. Because LPD
969    supports very few attributes, this operation doesn't have much to
970    check.
971
972 5.4 Create-Job
973
974    The mapper SHALL handle this operation like Print-Job, except:
975
976       - the mapper SHALL send the control file after it has received the
977         last Send-Document or Send-URI operation because the control
978         file contains all the document-name and document-format values
979         specified in the Send-Document and Send-URI operations.
980       - the mapper SHALL perform one receive-data-file sub-command for
981         each Send-Document or Send-URI operation received and in the
982         same order received.
983       - the mapper SHALL send the control file either before all data
984         files or after all data files. (See the note in the section on
985         Print-Job about the dilemma of sending the control file either
986         before or after the data files.
987
988 5.5 Send-Document
989
990    The mapper performs a receive-data-file sub-command on the received
991    data. See the preceding section 5.4 "Create-Job" for the details.
992
993 5.6 Send-URI
994
995    The mapper SHALL obtain the data referenced by the "document-uri"
996    operation attribute, and SHALL then treat that data as if it had been
997    received via a Send-Document operation. See the preceding section 5.5
998    "Send-Document" for the details.
999
1000 5.7 Cancel-Job
1001
1002    The mapper SHALL perform a remove-jobs command with the following
1003    operation attributes:
1004
1005
1006
1007
1008
1009
1010 Herriot, et al.               Experimental                     [Page 18]
1011 \f
1012 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1013
1014
1015       - the printer is the one to which the job was submitted, that is
1016         the IPP printer-uri is mapped to an LPD printer-name by the same
1017         mechanism as for all commands
1018       - the agent is the authenticated user-name of the IPP client
1019       - the job-number is the job-id returned by the Print-Job command,
1020         that is, the LPD job-number has the same value as the IPP job-id
1021         for likely implementations
1022
1023 5.8 Get-Printer-Attributes
1024
1025    LPD severely limits the set of attributes that the mapper is able to
1026    return in its response for this operation. The mapper SHALL support,
1027    at most, the following printer attributes:
1028
1029       - printer-state
1030       - printer-state-reasons
1031
1032    The mapper uses either the long or short form of the "send queue
1033    state" command.
1034
1035    The mapper SHALL assume that the LPD response that it receives has
1036    the format and information specified in section 3.3 "Send queue state
1037    (short)" and section 3.4 "Send queue state (long)".  The mapper SHALL
1038    determine the value of each requested attribute by using the inverse
1039    of the mapping specified in the two aforementioned sections.
1040
1041    Note: the mapper can determine the response from the printer-status
1042    line without examining the rest of the LPD response.
1043
1044 5.9 Get-Job-Attributes
1045
1046    LPD severely limits the set of attributes that the mapper is able to
1047    return in its response for this operation. The mapper SHALL support,
1048    at most, the following job attributes:
1049
1050       - number-of-intervening-jobs
1051       - job-originating-user-name
1052       - job-id
1053       - document-name
1054       - job-k-octets
1055       - copies
1056
1057    The mapper uses either the long or short form of the "send queue
1058    state" command. If it receives a request for the "job-k-octets" or
1059    "copies" and supports the attribute it SHALL use the long form;
1060    otherwise, it SHALL use the short form.
1061
1062
1063
1064
1065
1066 Herriot, et al.               Experimental                     [Page 19]
1067 \f
1068 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1069
1070
1071    Note: the value of job-k-octets is the value in the short form
1072    divided by the number of "copies" which is on the long form only. Its
1073    value can also be determined by adding the "size" field values for
1074    each document in the job in the long form.
1075
1076    The mapper SHALL assume that the LPD response that it receives has
1077    the format and information specified in section 3.3 "Send queue state
1078    (short)" and section 3.4 "Send queue state (long)".  The mapper SHALL
1079    determine the value of each requested attribute by using the inverse
1080    of the mapping specified in the two aforementioned sections.
1081
1082    Note: when the mapper uses the LPD short form, it can determine the
1083    response from the single LPD line that pertains to the job specified
1084    by the Get-Job-Attributes operation.
1085
1086    Note: the mapper can use its correspondence between the IPP job-id,
1087    job-uri and the LPD job-number.
1088
1089 5.10 Get-Jobs
1090
1091    The mapper SHALL perform this operation in the same way as Get-Job-
1092    Attributes except that the mapper converts all the LPD job-lines, and
1093    the IPP response contains one job object for each job-line in the LPD
1094    response.
1095
1096 6. Mapping of IPP Attributes to LPD Control File Lines
1097
1098    This section describes the mapping from IPP operation attributes and
1099    job template attributes to LPD control file lines (called '
1100    functions'). The mapper receives the IPP operation attributes and job
1101    template atributes via the IPP operation.  Each of the IPP operation
1102    attributes and job template attributes appear as sub-sections of
1103    section 3 and 4.2 in the IPP model document [RFC2566].
1104
1105    In the context of LPD control file lines, the text operands have a
1106    maximum length of 31 or 99 while IPP operation attributes and job
1107    template attributes have a maximum of 255 or 1023 octets, depending
1108    on the attribute syntax.  Therefore, there may be some data loss if
1109    the IPP operation attribute and job template attribute values exceed
1110    the maximum length of the LPD equivalent operands.
1111
1112    The mapper converts each supported IPP operation attribute and job
1113    template attribute to its corresponding LPD function as defined by
1114    tables in the subsections that follow. These subsections group
1115    functions according to whether they are:
1116
1117
1118
1119
1120
1121
1122 Herriot, et al.               Experimental                     [Page 20]
1123 \f
1124 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1125
1126
1127       - required with a job,
1128       - optional with a job
1129       - required with each document.
1130
1131    In the tables below, each IPP value is given a name, such as 'h'. If
1132    an LPD value uses the IPP value, then the LPD value column contains
1133    the IPP name, such as 'h' to denote this.  Otherwise, the LPD value
1134    column specifies the literal value.
1135
1136 6.1 Required Job Functions
1137
1138    The mapper SHALL include the following LPD functions with each job,
1139    and they SHALL have the specified value. They SHALL be the first
1140    functions in the control file and they SHALL be in the order "H" and
1141    then "P".
1142
1143    IPP                           LPD function
1144    name                  value   name  value         description
1145
1146    (perhaps in security  h       H     gateway host  Originating Host
1147    layer)
1148    requesting-user-name  u       P     u             User identification
1149    and in the security
1150    layer
1151
1152    A mapper SHALL sends its own host rather than the client's host,
1153    because some LPD systems require that it be the same as the host from
1154    which the remove-jobs command comes.  A mapper MAY send its own user
1155    name as user identification rather than the client user. But in any
1156    case, the values sent SHALL be compatible with the LPD remove-jobs
1157    operation.
1158
1159 6.2 Optional Job Functions
1160
1161    The mapper MAY include the following LPD functions with each job.
1162    They SHALL have the specified value if they are sent. These
1163    functions, if present, SHALL follow the require job functions, and
1164    they SHALL precede the required document functions.
1165
1166    IPP attribute                      LPD function
1167    name           value               name value  description
1168
1169    job-name       j                   J    j      Job name for banner
1170                                                   page
1171    job-sheets     'standard'          L    u      Print banner page
1172    job-sheets     'none'                          omit 'L' function
1173
1174
1175
1176
1177
1178 Herriot, et al.               Experimental                     [Page 21]
1179 \f
1180 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1181
1182
1183    Note: 'L' has special meaning when it is omitted. If 'J' is omitted,
1184    some undefined behavior occurs with respect to the banner page.
1185
1186 6.3 Required Document Functions
1187
1188    The mapper SHALL include one set of the following LPD functions with
1189    each document, and they SHALL have the specified values. For each
1190    document, the order of the functions SHALL be 'f', 'U' and then 'N',
1191    where 'f' is replicated once for each copy.
1192
1193    IPP attribute                      LPD function
1194
1195    name        value                  name value  description
1196
1197    document-   'application/octet-    f    fff    Print formatted file
1198    format      stream' or
1199                'application/PostScript'
1200    copies      c                                  replicate 'f' 'c'
1201                                                   times
1202    none                               U    fff    Unlink data file
1203    document-   n                      N    n      Name of source file
1204    name
1205
1206    Note: the value 'fff' of the 'f' and 'U' functions is the name of the
1207    data file as transferred, e.g. "dfA123woden".
1208
1209    Note: the mapper SHALL not send the 'o' function
1210
1211    ISSUE: should we register DVI, troff or ditroff?
1212
1213    If the mapper receives no "ipp-attribute-fidelitybest-effort" or it
1214    has a value of false, then the mapper SHALL reject the job if it
1215    specifies attributes or attribute values that are not among those
1216    supported in the above tables.
1217
1218    Below is an example of the minimal control file for a job with three
1219    copies of two files 'foo' and 'bar':
1220
1221       H tiger
1222       P jones
1223       f dfA123woden
1224       f dfA123woden
1225       f dfA123woden
1226       U dfA123woden
1227       N foo
1228       f dfB123woden
1229       f dfB123woden
1230       f dfB123woden
1231
1232
1233
1234 Herriot, et al.               Experimental                     [Page 22]
1235 \f
1236 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1237
1238
1239       U dfB123woden
1240       N bar
1241
1242 7. Security Considerations
1243
1244    There are no security issues beyond those covered in the IPP Encoding
1245    and Transport document [RFC2565], the IPP model document [RFC2566]
1246    and the LPD document [RFC1179].
1247
1248 8. References
1249
1250    [ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0:
1251              Implementer's Guide", Work in Progress.
1252
1253    [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J.
1254              Gyllenskog, "Printer MIB", RFC 1759, March 1995.
1255
1256    [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
1257              August 1990.
1258
1259    [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
1260              Requirement Levels", BCP 14, RFC 2119, March 1997.
1261
1262    [RFC2234] D. Crocker et al., "Augmented BNF for Syntax
1263              Specifications:  ABNF", RFC 2234, November 1997.
1264
1265    [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
1266              Printing Protocol/1.0: Encoding and Transport", RFC 2565,
1267              April 1999.
1268
1269    [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P.
1270              Powell, "Internet Printing Protocol/1.0: Model and
1271              Semantics", RFC 2566, April 1999.
1272
1273    [RFC2567] Wright, D., "Design Goals for an Internet Printing
1274              Protocol", RFC 2567, April 1999.
1275
1276    [RFC2568] Zilles, S., "Rationale for the Structure and Model and
1277              Protocol for the Internet Printing Protocol", RFC 2568,
1278              April 1999.
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Herriot, et al.               Experimental                     [Page 23]
1291 \f
1292 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1293
1294
1295 9. Authors' Addresses
1296
1297    Robert Herriot (Editor)
1298    Xerox Corporation
1299    3400 Hillview Ave., Bldg #1
1300    Palo Alto, CA 94304
1301
1302    Phone: 650-813-7696
1303    Fax:  650-813-6860
1304    EMail:  rherriot@pahv.xerox.com
1305
1306
1307    Norm Jacobs
1308    Sun Microsystems Inc.
1309    1430 Owl Ridge Rd.
1310    Colorado Springs, CO 80919
1311
1312    Phone:  719-532-9927
1313    Fax:    719-535-0956
1314    EMail:  Norm.Jacobs@Central.sun.com
1315
1316
1317    Thomas N. Hastings
1318    Xerox Corporation
1319    701 S. Aviation Blvd., ESAE-231
1320    El Segundo, CA 90245
1321
1322    Phone: 310-333-6413
1323    Fax:   310-333-5514
1324    EMail: hastings@cp10.es.xerox.com
1325
1326
1327    Jay Martin
1328    Underscore, Inc.
1329    41-C Sagamore Park Road
1330    Hudson, NH 03051-4915
1331
1332    Phone:  603-889-7000
1333    Fax:  603-889-2699
1334    EMail:  jkm@underscore.com
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Herriot, et al.               Experimental                     [Page 24]
1347 \f
1348 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1349
1350
1351 10. Appendix A: ABNF Syntax for response of Send-queue-state (short)
1352
1353    The syntax in ABNF for the response to the LPD command 'send-queue-
1354    state (long)' is:
1355
1356     status-response = empty-queue / nonempty-queue
1357     empty-queue = "no-entries" LF
1358     nonempty-queue = printer-status LF heading LF *(job LF)
1359     printer-status =  OK-status / error-status
1360     OK-status = printer-name SP "ready and printing" LF
1361     error-status = < implementation dependent status information >
1362     heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files"
1363                     23SP "Total Size" LF
1364                        ; the column headings and their values below begin
1365     at the columns
1366                        ; 1, 8, 19, 35 and 63
1367     job = rank *SP owner *SP job *SP files *SP total-size "bytes"
1368                       ; jobs are in order of oldest to newest
1369     rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1370                       ; job that is printing is "active"
1371                       ; other values show position in the queue
1372     owner = <user name of person who submitted the job>
1373     job = 1*3DIGIT   ; job-number
1374     files = <file name> *( "," <file name>) ; truncated to 24 characters
1375     total-size = 1*DIGIT  ; combined size in bytes of all documents
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402 Herriot, et al.               Experimental                     [Page 25]
1403 \f
1404 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1405
1406
1407 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)
1408
1409    The syntax in ABNF for the response to the LPD command 'send-queue-
1410    state (long)' is:
1411
1412     status-response = empty-queue / nonempty-queue
1413     empty-queue = "no-entries" LF
1414     nonempty-queue = printer-status LF  *job
1415     printer-status =  OK-status / error-status
1416     OK-status = printer-name SP "ready and printing" LF
1417     error-status = < implementation dependent status information >
1418     job = LF line-1 LF line-2 LF
1419     line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
1420     line-2 =  file-name 1*SP document-size "bytes"
1421           ; jobs are in order of oldest to newest
1422     rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1423             ; job that is printing is "active"
1424             ; other values show position in the queue
1425     owner = <user name of person who submitted the job>
1426     job = 1*3DIGIT
1427     file-name = [ 1*DIGIT  "copies of" SP ] <file name>
1428                   ; truncated to 24 characters
1429     document-size = 1*DIGIT  ;size of single copy of the document.
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Herriot, et al.               Experimental                     [Page 26]
1459 \f
1460 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1461
1462
1463 12. Appendix C: Unsupported LPD functions
1464
1465    The follow LPD functions have no IPP equivalent. The LPD-to-IPP
1466    mapper ignores them and the IPP-to-LPD mapper does not send them.
1467
1468     LPD command
1469     name  description
1470
1471     C     Class for banner page
1472     I     Indent Printing
1473     H     Host of client
1474     M     Mail when printed
1475     S     Symbolic link data
1476     T     Title for pr
1477     W     Width of output
1478     1     troff R font
1479     2     troff I font
1480     3     troff B font
1481     4     troff S font
1482
1483    The follow LPD functions specify document-formats which have no IPP
1484    equivalent, unless someone registers them. The LPD-to-IPP mapper
1485    rejects jobs that request such a document format, and the IPP-to-LPD
1486    mapper does not send them.
1487
1488     LPD command
1489     name   description
1490
1491     c      Plot CIF file
1492     d      Print DVI file
1493     g      Plot file
1494     k      reserved for Kerberized clients and servers
1495     n      Print ditroff output file
1496     p      Print file with 'pr' format
1497     r      File to print with FORTRAN carriage control
1498     t      Print troff output file
1499     v      Print raster file
1500     z      reserved for future use with the Palladium
1501            print system
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Herriot, et al.               Experimental                     [Page 27]
1515 \f
1516 RFC 2569         Mapping between LPD and IPP Protocols        April 1999
1517
1518
1519 13.  Full Copyright Statement
1520
1521    Copyright (C) The Internet Society (1999).  All Rights Reserved.
1522
1523    This document and translations of it may be copied and furnished to
1524    others, and derivative works that comment on or otherwise explain it
1525    or assist in its implementation may be prepared, copied, published
1526    and distributed, in whole or in part, without restriction of any
1527    kind, provided that the above copyright notice and this paragraph are
1528    included on all such copies and derivative works.  However, this
1529    document itself may not be modified in any way, such as by removing
1530    the copyright notice or references to the Internet Society or other
1531    Internet organizations, except as needed for the purpose of
1532    developing Internet standards in which case the procedures for
1533    copyrights defined in the Internet Standards process must be
1534    followed, or as required to translate it into languages other than
1535    English.
1536
1537    The limited permissions granted above are perpetual and will not be
1538    revoked by the Internet Society or its successors or assigns.
1539
1540    This document and the information contained herein is provided on an
1541    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1542    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1543    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1544    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1545    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570 Herriot, et al.               Experimental                     [Page 28]
1571 \f