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