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.
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:
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
Version 1.1 of IPP is defined (at this time) by the following RFCs:
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:
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 TypesIn 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 OperationsThe 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:
The operations that can be used with the print job object are as defined here:
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 in Store for Version 1.1?Version 1.1 of IPP has added more functionality to the protocol. Several new operations have been defined:
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:
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.  |
EAN: 2147483647
Pages: 434