File: rfc2569.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1571 lines) | stat: -rw-r--r-- 57,886 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
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
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
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
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
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
1571






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>





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


   This sub-command is roughly equivalent to the IPP Create-Job
   operation.

   The mapper SHALL use the contents of the received LPD control file to
   create IPP operation attribute and job template attribute values to
   transmit with the Print-Job or Create-Job operation.

3.2.3 Receive data file

Sub-command syntax:  %x3 number-of-bytes-in-data-file Name-of-data-file

   receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
   number-of-bytes = 1*DIGIT
   name-of-data-file = "df" letter job-number client-host-name
               ; e.g. "dfA123woden for the first file
   letter = %x41-5A /  %x61-7A    ;  "A" to "Z", "a" to "z"
                                  ;  first file is "A",
                                  ; second "B", and  52nd file is "z"
   job-number = 3DIGIT
   client-host-name = <a host name>

   This sub-command is roughly equivalent to the IPP Send-Document
   operation.

   The mapper SHALL use the contents of the received LPD data file as
   the data to transmit with the IPP Print-Job or Send-Document
   operation.

   Although RFC 1179 alludes to a method for passing an unspecified
   length data file by using an octet-count of zero, no implementations
   support this feature. The mapper SHALL reject a job that has a value
   of 0 in the number-of-bytes field.

3.3 Send queue state (short)

   Command syntax:

send-queue-short  = %x03 printer-name *(SP(user-name / job-number)) LF

   The mapper's response to this command includes information about the
   printer and its jobs. RFC 1179 specifies neither the information nor
   the format of its response. This document requires the mapper to
   follow existing practice as specified in this document.

   The mapper SHALL produce a response in the following format which
   consists of a printer-status line optionally followed by a heading
   line, and a list of jobs. This format is defined by examples below.
   Appendix A contains the ABNF syntax.



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


   For an printer with no jobs, the response starts in column 1 and is:

      no entries

   For a printer with jobs, an example of the response is:

     killtree is ready and printing
     Rank   Owner      Job          Files             Total Size
     active fred       123          stuff             1204 bytes
     1st    smith      124          resume, foo       34576 bytes
     2nd    fred       125          more              99 bytes
     3rd    mary       126          mydoc             378 bytes
     4th    jones      127          statistics.ps     4567 bytes
     5th    fred       128          data.txt          9 bytes

   The column numbers of above headings and job entries are:

     |      |          |            |                 |
     01     08         19           35                63

   The mapper SHALL produce each field above from the following IPP
   attribute:

   LPD field IPP attribute          special conversion details

   printer-  printer-state and      For a printer-state of idle or
   status    printer-state-reasons  processing, the mapper SHALL use
                                    the formats above.  For stopped,
                                    the mapper SHALL use printer-
                                    state-reasons to produce an
                                    unspecified format for the error.
   rank      number-of-             the mapper SHALL the format above
             intervening-jobs
   owner     job-originating-user-  unspecified conversion; job-
             name                   originating-user-name may be the
                                    mapper's user-name
   job       job-id                 the mapper shall use the job-id
   files     document-name          the mapper shall create a comma
                                    separated list of the document-
                                    names and then truncate this list
                                    to the first 24 characters
   total-    job-k-                 the mapper shall multiple the
   size      octets*copies*1024     value of job-k-octets by 1024 and
                                    by the value of the "copies"
                                    attribute.






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


   A mapper SHOULD use the job attribute number-of-intervening-jobs
   rather than the job's position in a list of jobs to determine 'rank'
   because a Printer may omit jobs that it wants to keep secret. If a
   printer doesn't support the job attribute number-of-intervening-jobs,
   a mapper MAY use the job's position.

   Note: a Printer may set the value of job-originating-user-name to the
   authenticated user or to the value of "requesting-user-name",
   depending on the implementation and configuration. For a gateway, the
   authenticated user is the user-id of the gateway, but the
   "requesting-user-name" may contain the name of the user who is the
   gateway's client.

   In order to obtain the information specified above, The LPD-to-IPP
   mapper SHALL use the Get-Printer-Attributes operation to get
   printer-status and SHOULD use the Get-Jobs operation to get
   information about all of the jobs. If the LPD command contains job-
   numbers or user-names, the mapper MAY handle the filtering of the
   response. If the LPD command contains job-numbers but no user-names,
   the mapper MAY use Get-Job-Attributes on each converted job-number
   rather than Get-Jobs. If the LPD command contains a single user-name
   but no job-numbers, the mapper MAY use Get-Jobs with the my-jobs
   option if the server supports this option and if the server allows
   the client to be a proxy for the LPD user.

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

3.4 Send queue state (long)

   Command syntax:

   send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF

   The mapper's response to this command includes information about the
   printer and its jobs. RFC 1179 specifies neither the information nor
   the format of its response. This document requires the mapper to
   follow existing practice as specified in this document.

   The mapper SHALL produce a response in the following format which
   consists of a printer-status line optionally followed a list of jobs,
   where each job consists of a blank line, a description line, and one
   line for each file. The description line contains the user-name,
   rank, job-number and host. This format is defined by examples below.
   Appendix B contain the ABNF syntax.






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


   For an printer with no jobs the response is:

      no entries

   For a printer with jobs, an example of the response is:

      killtree is ready and printing

      fred: active                        [job 123 tiger]
              2 copies of stuff           602 bytes

      smith: 1st                          [job 124 snail]
              2 copies of resume          7088 bytes
              2 copies of foo             10200 bytes

      fred: 2nd                           [job 125 tiger]
              more                        99 bytes

      The column numbers of above headings and job entries are:

      |       |                           |
      01      09                          41

   Although the format of the long form is different from the format of
   the short form, their fields are identical except for a) the copies
   and host fields which are only in the long form, and b) the "size"
   field contains the single copy size of each file.  Thus the sum of
   the file sizes in the "size" field times the value of the "copies"
   field produces the value for the "Total Size" field in the short
   form. For fields other than the host and copies fields, see the
   preceding section.  For the host field see the table below.

      LPD field IPP attribute        special conversion details

      host                           unspecified conversion; job-
                                     originating-host may be the
                                     mapper's host
      copies    copies               the mapper shall assume the
                                     value of copies precedes the
                                     string "copies of "; otherwise,
                                     the value of copies is 1.

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







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


3.5 Remove jobs

   Command syntax:

      remove-jobs = %x05 printer-name SP agent
                          *(SP(user-name / job-number)) LF

   The agent operand is the user-name of the user initiating the
   remove-jobs command. The special user-name 'root' indicates a
   privileged user who can remove jobs whose user-name differs from the
   agent.

   The mapper SHALL issue one Cancel-Job operation for each job
   referenced by the remove-jobs command. Each job-number in the
   remove-jobs command references a single job. Each user-name in the
   remove-jobs command implicitly references all jobs owned by the
   specified user. The active job is implicitly referenced when the
   remove-jobs command contains neither job-numbers nor user-names. The
   mapper MAY use Get-Jobs to determine the job-uri of implicitly
   referenced jobs.

   The mapper SHALL not use the agent name of 'root' when end-users
   cancel their own jobs.  Violation of this rule creates a potential
   security violation, and it may cause the printer to issue a
   notification that misleads a user into thinking that some other
   person canceled the job.

   If the agent of a remove-jobs command for a job J is the same as the
   user name specified with the 'P' function in the control file for job
   J, then the mapper SHALL ensure that the initiator of the Cancel-Job
   command for job J is the same as job-originating-user for job J.

   Note: This requirement means that a mapper must be consistent in who
   the receiver perceives as the initiator of IPP operations. The mapper
   either acts as itself or acts on behalf of another user. The latter
   is preferable if it is possible. This consistency is necessary
   between Print-Job/Create-Job and Cancel-Job in order for Cancel-Job
   to work, but it is also desirable for other operations. For example,
   Get-Jobs may give more information about job submitted by the
   initiator of this operation.

   NOTE: This specification does not define how the mapper maps: (1) the
   LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number
   to the IPP "job-uri".

   NOTE: This specification does not specify how the mapper maps the LPD
   user-name to the IPP job-originating-user because the mapper may use
   its own user-name with jobs.



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


4. Mapping of LPD Control File Lines to IPP Operation and Job Template
   Attributes

   This section describes the mapping from LPD control file lines
   (called 'functions') to IPP operation attributes and job template
   attributes.  The mapper receives the control file lines via the LPD
   receive-control-file sub-command.  Each of the LPD functions appear
   as sub-sections of section 7 of RFC 1179.

   In LPD control file lines, the text operands have a maximum length of
   31 or 99 while IPP operation attribute and job template attribute
   values have a maximum of 255 or 1023 octets, depending on the
   attribute syntax.  Therefore, no data is lost.

   The mapper converts each supported LPD function to its corresponding
   IPP operation or job template attribute as defined by tables in the
   subsections that follow. These subsections group functions according
   to whether they are:

      - required with a job,
      - optional with a job
      - required with each document.

   In the tables below, each LPD value is given a name, such as 'h'. If
   an IPP value uses the LPD value, then the IPP value column contains
   the LPD name, such as 'h' to denote this.  Otherwise, the IPP value
   column specifies the literal value.

4.1 Required Job Functions

   The following LPD functions MUST be in a received LPD job. The mapper
   SHALL receive each of the following LPD functions and SHALL include
   the information as a operation or job template attribute with each
   IPP job.  The functions SHOULD be in the order 'H', 'P' and they
   SHOULD be the first two functions in the control file, but they MAY
   be anywhere in the control file and in any order:

   LPD function                     IPP
   name value   description         name          value

   H    h       Originating Host                  h (in security layer)
   P    u       User identification requesting-   u (and in security
                                    user-name     layer)
                none                ipp-          'true'
                                    attribute-
                                    fidelity





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


   A mapper MAY send its own host rather than the client's host, and a
   mapper MAY send its own user-name as user identification rather than
   the client user. But in any case, the values sent SHALL be compatible
   with the Cancel-Job operation. The IPP operation MAY have no way to
   specify an originating host-name.

   The mapper SHALL include ipp-attribute-fidelity = true so that it
   doesn't have to determine which attributes a printer supports.

4.2 Optional Job Functions

   The following LPD functions MAY be present in a received job. These
   functions SHOULD follow the required job functions and precede the
   document functions, but they MAY be anywhere in the control file.

   If the mapper receives such an LPD function, the mapper SHALL include
   the corresponding IPP attribute with the value converted as specified
   in the table below.  If the mapper does not receive such an LPD
   attribute, the mapper SHALL NOT include the corresponding IPP
   attribute, except the 'L' LPD function whose absence has a special
   meaning as noted in the table.

   LPD function                  IPP
   name value  description       name         value

   J    j      Job name for      job-name     j
               banner page
   L    l      Print banner page job-sheets   'standard' if 'L' is
                                              present
                                              'none' if 'L' is present
   M    m      Mail When Printed              IPP has no notification
                                              mechanism. To support
                                              this LPD feature, the
                                              gateway must poll using
                                              the Get-Job-Attributes
                                              operation.

4.3 Required Document Functions

   The mapper SHALL receive one set of the required document functions
   with each copy of a document, and SHALL include the converted
   information as operation or job template attributes with each IPP
   document.

   If the control file contains required and recommended document
   functions, the required functions SHOULD precede the recommended ones
   and if the job contains multiple documents, all the functions for




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


   each document are grouped together as shown in the example of section
   6.3 "Required Document Functions". However, the document functions
   MAY be in any order.

   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]

RFC 2569         Mapping between LPD and IPP Protocols        April 1999


   Note: 'L' has special meaning when it is omitted. If 'J' is omitted,
   some undefined behavior occurs with respect to the banner page.

6.3 Required Document Functions

   The mapper SHALL include one set of the following LPD functions with
   each document, and they SHALL have the specified values. For each
   document, the order of the functions SHALL be 'f', 'U' and then 'N',
   where 'f' is replicated once for each copy.

   IPP attribute                      LPD function

   name        value                  name value  description

   document-   'application/octet-    f    fff    Print formatted file
   format      stream' or
               'application/PostScript'
   copies      c                                  replicate 'f' 'c'
                                                  times
   none                               U    fff    Unlink data file
   document-   n                      N    n      Name of source file
   name

   Note: the value 'fff' of the 'f' and 'U' functions is the name of the
   data file as transferred, e.g. "dfA123woden".

   Note: the mapper SHALL not send the 'o' function

   ISSUE: should we register DVI, troff or ditroff?

   If the mapper receives no "ipp-attribute-fidelitybest-effort" or it
   has a value of false, then the mapper SHALL reject the job if it
   specifies attributes or attribute values that are not among those
   supported in the above tables.

   Below is an example of the minimal control file for a job with three
   copies of two files 'foo' and 'bar':

      H tiger
      P jones
      f dfA123woden
      f dfA123woden
      f dfA123woden
      U dfA123woden
      N foo
      f dfB123woden
      f dfB123woden
      f dfB123woden



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


      U dfB123woden
      N bar

7. Security Considerations

   There are no security issues beyond those covered in the IPP Encoding
   and Transport document [RFC2565], the IPP model document [RFC2566]
   and the LPD document [RFC1179].

8. References

   [ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0:
             Implementer's Guide", Work in Progress.

   [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J.
             Gyllenskog, "Printer MIB", RFC 1759, March 1995.

   [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
             August 1990.

   [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234] D. Crocker et al., "Augmented BNF for Syntax
             Specifications:  ABNF", RFC 2234, November 1997.

   [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
             April 1999.

   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P.
             Powell, "Internet Printing Protocol/1.0: Model and
             Semantics", RFC 2566, April 1999.

   [RFC2567] Wright, D., "Design Goals for an Internet Printing
             Protocol", RFC 2567, April 1999.

   [RFC2568] Zilles, S., "Rationale for the Structure and Model and
             Protocol for the Internet Printing Protocol", RFC 2568,
             April 1999.











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


9. Authors' Addresses

   Robert Herriot (Editor)
   Xerox Corporation
   3400 Hillview Ave., Bldg #1
   Palo Alto, CA 94304

   Phone: 650-813-7696
   Fax:  650-813-6860
   EMail:  rherriot@pahv.xerox.com


   Norm Jacobs
   Sun Microsystems Inc.
   1430 Owl Ridge Rd.
   Colorado Springs, CO 80919

   Phone:  719-532-9927
   Fax:    719-535-0956
   EMail:  Norm.Jacobs@Central.sun.com


   Thomas N. Hastings
   Xerox Corporation
   701 S. Aviation Blvd., ESAE-231
   El Segundo, CA 90245

   Phone: 310-333-6413
   Fax:   310-333-5514
   EMail: hastings@cp10.es.xerox.com


   Jay Martin
   Underscore, Inc.
   41-C Sagamore Park Road
   Hudson, NH 03051-4915

   Phone:  603-889-7000
   Fax:  603-889-2699
   EMail:  jkm@underscore.com











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


10. Appendix A: ABNF Syntax for response of Send-queue-state (short)

   The syntax in ABNF for the response to the LPD command 'send-queue-
   state (long)' is:

    status-response = empty-queue / nonempty-queue
    empty-queue = "no-entries" LF
    nonempty-queue = printer-status LF heading LF *(job LF)
    printer-status =  OK-status / error-status
    OK-status = printer-name SP "ready and printing" LF
    error-status = < implementation dependent status information >
    heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files"
                    23SP "Total Size" LF
                       ; the column headings and their values below begin
    at the columns
                       ; 1, 8, 19, 35 and 63
    job = rank *SP owner *SP job *SP files *SP total-size "bytes"
                      ; jobs are in order of oldest to newest
    rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
                      ; job that is printing is "active"
                      ; other values show position in the queue
    owner = <user name of person who submitted the job>
    job = 1*3DIGIT   ; job-number
    files = <file name> *( "," <file name>) ; truncated to 24 characters
    total-size = 1*DIGIT  ; combined size in bytes of all documents


























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


11. Appendix B: ABNF Syntax for response of Send-queue-state (long)

   The syntax in ABNF for the response to the LPD command 'send-queue-
   state (long)' is:

    status-response = empty-queue / nonempty-queue
    empty-queue = "no-entries" LF
    nonempty-queue = printer-status LF  *job
    printer-status =  OK-status / error-status
    OK-status = printer-name SP "ready and printing" LF
    error-status = < implementation dependent status information >
    job = LF line-1 LF line-2 LF
    line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
    line-2 =  file-name 1*SP document-size "bytes"
          ; jobs are in order of oldest to newest
    rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
            ; job that is printing is "active"
            ; other values show position in the queue
    owner = <user name of person who submitted the job>
    job = 1*3DIGIT
    file-name = [ 1*DIGIT  "copies of" SP ] <file name>
                  ; truncated to 24 characters
    document-size = 1*DIGIT  ;size of single copy of the document.




























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


12. Appendix C: Unsupported LPD functions

   The follow LPD functions have no IPP equivalent. The LPD-to-IPP
   mapper ignores them and the IPP-to-LPD mapper does not send them.

    LPD command
    name  description

    C     Class for banner page
    I     Indent Printing
    H     Host of client
    M     Mail when printed
    S     Symbolic link data
    T     Title for pr
    W     Width of output
    1     troff R font
    2     troff I font
    3     troff B font
    4     troff S font

   The follow LPD functions specify document-formats which have no IPP
   equivalent, unless someone registers them. The LPD-to-IPP mapper
   rejects jobs that request such a document format, and the IPP-to-LPD
   mapper does not send them.

    LPD command
    name   description

    c      Plot CIF file
    d      Print DVI file
    g      Plot file
    k      reserved for Kerberized clients and servers
    n      Print ditroff output file
    p      Print file with 'pr' format
    r      File to print with FORTRAN carriage control
    t      Print troff output file
    v      Print raster file
    z      reserved for future use with the Palladium
           print system












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


13.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Herriot, et al.               Experimental                     [Page 28]