CHAPTER 40. Network Printing Protocols
SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE
Printing Protocols and Printing Languages 750
Data Link Control Protocol (DLC) 752
Internet Printing Protocol (IPP) 752
The most basic functions provided by a LAN are the file and print services. A print server is a computer or a networked device that has one or more physical printers attached and that accepts data for printing from other computers. You can learn more about print servers in the next chapter.
A parallel port, USB port, or even FireWire (IEEE 1394, also called iLink) port can be used to directly connect a printer to a single computer. The parallel port provides a high-speed connection on a set of wires used exclusively by the printer and the computer for this communication path. USB and FireWire provide much faster communication links between the computer and the printer. Most small-scale printers today support both parallel connections and USB connections. Larger printers intended for enterprise environments also include network adapters, so you can access them from multiple clients on the network without having to send a print job through a server that is directly connected to the printer. Instead, the printer is just like another member of the network.
Tip
When you have a few hundred or thousand (or many more) employees, it is just not economically feasible to give each user a printer. In these large environments, a server is often dedicated to the sole task of processing print jobs. You could audit the print jobs to determine who was making use of the printer, among other features. Now, configuring a client to use a printer directly connected to the network is often a better, less expensive way of providing print services to clients. This doesn’t mean that you have to choose one or the other. You can have networked printers, as well as printers connected to computers on the network at the same time.
Most networked printers also support logging their activity to a syslog daemon. That is, they can send their operational and auditing information to a syslog daemon running on another Unix/Linux computer, and thus provide you, to some degree, an audit trail as well as report errors. Windows servers can record printing events in the system error log files for printers that are connected to the server, which you can view using the Event Viewer. You can also use Windows server computers to make a connection to networked printers, acting as a gateway for clients. In this manner, the Windows error logs can also record information about print jobs for the networked printers they manage.
In anything but a very small network, you will also find that it is more efficient to connect a printer to the network, instead of a computer. This can be done in two ways: purchase a printer that comes with a network connection (such as the HP Jetdirect external print server), or use a small print server device that connects one or more printers to the network.
In this chapter, we’ll look primarily at the protocols used to communicate with a printer, or a print server, to exchange data and command information.
Printing Protocols and Printing Languages
A printer language is not the same as a printer protocol. For example, PostScript and PCL (Printer Control Language) are languages that describe how a document is to be rendered into the final printed product by the printer. When a printer is directly connected to a printer port on a computer, the printer language is important and is used by the software driver to format the information being sent to the printer.
A printer protocol, however, is used to send the formatted job, both data and instructions compiled using the printer language, to the print device. A few protocols will be detailed here that are more specific in their use and implementation; that is, they generally are used for communicating with a printer.
Several protocols are used for network printing. Some are proprietary protocols used by only one computer or network operating system (NOS). Others, such as lpr/lpd—which was first developed for use on Unix systems—have been implemented in many environments. Data Link Control (DLC) is an IBM protocol that has been adapted for use on many printers although it is not used much today. This chapter covers the basics of these major protocols, with examples from Unix, Windows, and NetWare servers and systems.
Also covered is the newest printing protocol: the Internet Printing Protocol (IPP), which was created by a working committee of the Internet Engineering Task Force (IETF). Development is underway for standards to further define this new protocol. You will find, however, that both Windows 2000/2003/XP and NetWare 6.x already support IPP. Novell even sells its iPrint as a separate product that can be used in a non-NetWare environment.
Note
The abbreviation IPP is also used in some books to mean Internet Presence Provider. If you are studying for a certification exam, be sure to interpret the usage of this term by the context in which it is used.
Using lpr/lpd and the TCP Stream Protocols
TCP/IP was originally developed for the Unix operating system (OS), of which there are several flavors. Depending on the version of Unix (as well as Linux) running on a workstation or server, you will find that TCP/IP printing falls into one of two major types:
BSD (Berkeley System Distribution) Spooling System
SVR4 (System V, Release 4) Printing System
The BSD system uses the lpr (line printer remote) program to send files to printers. The printers can be connected to a network, or to a computer. Whichever way, the lpd (line printer daemon) receives these print requests and interacts with the lpr to send the print job to the printer. The /etc/printcap text file is used to set up characteristics for each printer. The SVR4 Unix system uses the lp (line printer) program and the lpsched daemon (printer scheduler) to print files. Although the SVR4 system is considered more sophisticated because it has several utility commands for managing the system, the BSD system probably is easier to manage in a networked environment.
When using either of these methods, the actual print commands and data are sent to the printer in the payload section of a TCP/IP packet.
Although all Unix and Linux systems support TCP/IP printing, many support other protocols as well. For example, Red Hat Linux can also be configured to use SMB (Server Message Block) to connect to a Windows server (or a Unix/Linux computer configured to offer printing services using SMB).
The lpr/lpd protocols work well, but are mostly used by older operating systems. In the next chapter, “Print Servers,” you can learn about how to configure lpr/lpd printing on Unix/Linux servers, as well as Windows systems.
TCP/IP stream sockets the Unix provide yet another way to use TCP/IP to connect to a printer. Streams are a two-way communication TCP/IP session between the computer (or print server). When using TCP/IP streams, you need to specify a port (also known as a socket in Windows terminology). Thus the address of the networked printer, paired with a port number, provides a unique address so that the data exchange can be accomplished.
Note
The TCP/IP suite includes protocols (such as TCP, UDP, and IP) and a set of services and utilities based on them. For more information about TCP/IP, see Chapter 24, “Overview of the TCP/IP Protocol Suite.”
Data Link Control Protocol (DLC)
For all practical purposes, DLC is rarely found anymore within today’s networks, although it might still be found on legacy systems. This IBM protocol was widely used during the early days of networked printing, as well as for other applications. However, more robust protocols, such as TCP/IP, have made this protocol a less desirable solution for network printing.
The DLC protocol was developed by IBM primarily for use in connecting to mainframe computers as part of its Systems Network Architecture (SNA) specifications. DLC can also be used to establish terminal sessions with AS/400 computers. In addition to the HP Jet Direct card, you will find that other vendors also make network cards for printers that can use DLC. For example, the Brother NC-600X and NC-2010h network cards both can be used for this purpose. However, you’ll find that DLC no longer is present in Windows systems starting with Windows) XP.
Internet Printing Protocol (IPP)
The Internet Printing Protocol (IPP) has gained high visibility as more computers become dependent on LAN as well as Internet resources. Although most network servers and clients can be configured to use the lpr/lpd, Telnet, or DLC protocols, there are still many other protocols that can be used to send data to printers, such as SPX/IPX. The driving force of the Internet is making many vendors conscious of the need for more unified standards for basic functions, such as file and print sharing, and new protocols are being developed to meet those needs.
In 1996, several groups were developing a new standard. Novell and Xerox were working on a protocol that was titled Lightweight Document Printing Application (LDPA), IBM was developing the Hypertext Printing Protocol (HTPP), and Microsoft and HP were working on still another new protocol. Finally, a working group was formed under the auspices of the Internet Engineering Task Force (IETF) to work on a new standard. IPP uses the Hypertext Transfer Protocol (v. 1.1) as the underlying transport protocol.
Note
When an important new network protocol is developed, it is usually the case that the Institute of Electrical and Electronics Engineers (IEEE) will create a working committee and establish a standard for that protocol. Keep in mind that Request for Comments (RFC) documents—discussed throughout this book—are issued under the auspices of the IETF, and many of these RFCs are used, along with other input, to develop an IEEE standard. To continue this process, other international standards organizations usually cooperate to produce standards that are used worldwide.
If you want to keep up-to-date with the latest developments of the IEEE in regard to IPP, visit the IEEE Printer Working Group (PWG) at its Web site, www.pwg.org/ipp.
The goals of the first) efforts of the project were to develop a protocol that defines the user end of the printing process and includes the following capabilities, as well as a few other features:
Allow the user to discover the capabilities of a particular printer.
Allow the user to submit jobs to the printer.
Allow the user to get the status of the printer or a print job.
Allow the user to cancel a print job.
Define a set of directory attributes that make it easy to find a printer in a directory database.
All these are standard items incorporated into the first version of the standard (1.0).
Security and authentication mechanisms are also being created for IPP—just as for many other protocols that access the Internet.
The newest version of this protocol is 1.1. It is being developed by the RFC process, as well as the IEEE standards process. Following is a list of RFCs that have been written (as either a draft or an established standard) for version 1.2 of IPP:
The work of the original IPP group so far was defined by several RFCs. Version 1.0 RFCs include the following
RFC 2565, “Internet Printing Protocol/1.0: Encoding and Transport”
RFC 2566, “Internet Printing Protocol/1.0: Model and Semantics”
RFC 2567, “Design Goals for an Internet Printing Protocol”
RFC 2568, “Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol”
RFC 2569, “Mapping Between LPD and IPP Protocols”
RFC 2639, “Internet Printing Protocol/1.0: Implementers Guide”
Version 1.1 of IPP is defined (at this time) by the following RFCs:
RFC 2910, “IPP/1.1: Encoding and Transport”
RFC 2911, “IPP/1.1: Model and Semantics”
RFC 3196, “Internet Printing Protocol/1.1: Implementer’s Guide”
Additional Internet Draft documents are still in the review stage and will add additional functionality to the protocol. For example, see also the following RFCs:
RFC 3239, “IPP Requirements for Job, Printer, and Device Administrative Operations”
RFC 3380, “IPP: Job and Printer Set Operations”
RFC 3381, “IPP: Job Progress Attributes”
RFC 3382, “IPP: The ‘collection’ Attribute Syntax”
Although standards bodies continue to refine and add new functionality to IPP, that has not stopped software vendors from using the protocol. If you want to keep abreast of newer developments in the IPP standards process, search for IPP at www.rfc-editor.org, as well as the previously mentioned Web site of the IEEE working committee.
IPP Object Types
In the first version of this protocol, two basic object types are defined: printer and print job. The printer object encompasses the functions that are accomplished by the actual physical printer, rendering the printed page, as well as some of the functions that are traditionally performed by the print server, such as spooling the print file and handling scheduling procedures. The functions of the printer object can be implemented in a print server or on the printer itself. The printer object can be used to send output to a single physical printer or to more than one device.
When a user sends a document to a printer, the printer object creates a new object called a print job. The print job object contains the document to be printed and can contain more than one document per job. The printer object manipulates the print job and handles how it is sent to the physical printer.
IPP Operations
The protocol defines several operations, which consist of a request and a response. The operation allows the client to communicate with the object.
These are the operations defined in the first version of the protocol that can be used with the printer object:
Print-Job
Print-URI
Validate-Job
Create-Job
Get-Printer-Attributes
Get-Jobs
The operations that can be used with the print job object are as defined here:
Send-Document
Send-URI
Cancel-Job
Get-Job-Attributes
Note
The term URI used in these operations refers to Uniform Resource Identifier, which is described in RFC 2396. URIs are used to unambiguously identify an object. You might be familiar with the term URL, which stands for Uniform Resource Locator, another standardized term that can unambiguously identify a location for a resource. The concept here is similar in that a unique identifier is assigned to the print job.
A client submits a document to print by using the Print-Job request. Using this operation, the client “pushes” or sends the text to be printed. A client also can submit a job using the Print-URI operation, in which the client sends only the URI reference for the data to be printed and the printer object “pulls” the data itself. To send multiple documents to be printed, the client uses the Create-Job operation followed by multiple Send-Document or Send-URI operations, which also operate in a push-pull fashion.
The printer object responds to Validate-Job requests from the client depending on the current state of the printing job (pending, processing, and so on). For example, the printer object might return a message to the client indicating that the URI is no longer valid. Or the printer object might return error messages to the client.
Other operations are fairly self-explanatory. The Get-Printer-Attributes and Get-Job-Attributes operations return information about the printer or the print job. The Get-Jobs operation allows the client to get a list of job objects that are being processed by the particular Printer object. The Cancel-Job operation is used by the client to remove a job from the Printer object, basically just stopping a job from printing.
The RFCs also go into detail describing the attributes of each object, some of which are required and some of which are optional. These attributes include information about the job, such as its name, time stamps for different parts of the printing process, and the output device assigned to print the job. Attributes for the printer object include the name of the printer, its location, the location of the printer driver for the printer, and other information, such as the make and model of the printer.
What’s New in Version 1.1?
Version 1.1 of IPP has added more functionality to the protocol. Several new operations have been defined:
Pause-Printer
Resume-Printer
Purge-Printer
In addition, Version 1.1 suggests the order in which steps should be taken by an IPP 1.1 implementation. In general, these are as listed here:
- Validate the protocol version.
- Validate the requested operation.
- Validate the presence of operation attributes.
- Validate the values of operation attributes.
- Validate the attribute values against the object’s supported values.
- Validate any optional operation attributes.
For each request or response, the protocol version number must be included. This value and its semantics are kept in the same place in the packet for future versions to provide for backward compatibility. Next, the operation identifier must be validated against the printer object’s operations-supported attribute. The presence of operation attributes and their values are then evaluated, followed by the validation of optional attributes.
If the IPP object receives from a client a request message that is missing a required attribute, or the attribute groups are presented out of order, the object rejects the request.
The IPP protocol has already been widely adopted by major operating vendors, such as Microsoft and Novell NetWare. It will solve a lot of problems for both end users and vendors of printing equipment. Many companies are beginning to use the Internet to create virtual private networks (VPNs) instead of creating WANs using leased lines and other dedicated links. As the Internet continues to weave itself into every nook and cranny of the modern business world, standards such as IPP will generate new types of services. It is easy to foresee a business segment that will take over handling some, or all, of the aspects of printing for a large organization. Standards such as IPP will make implementation of these sorts of services much easier because it won’t rely on multiple proprietary protocols and skill sets.
In addition to helping you manage printing across your own private network, IPP might provide some promising business opportunities for those who are clever enough to take advantage of them. For example, using IPP, you could set up a printer to allow your clients to send purchase orders and other documents straight to your desktop. Or you could use IPP to “publish” your product sales literature, catalogs, and documentation, directly to a customer’s printer.
Where Can You Find IPP?
A large number of vendors have adopted the IPP protocol, most notably Windows 2000 (Server and Workstation), Windows 2003 and XP Professional, and NetWare 6.x (iPrint). You can submit a job to a printer on the Internet by specifying the URL for the printer.
In the next chapter are a few examples of how to configure, manage, and use IPP.