The IPP spec supports metadata about each printer and it's capabilities. If the IPP "client driver" is written correctly, it takes this metadata, and turns it into user choices on screen. The IPP spec does not know/care about any capabilities of your printer directly, i.e. color v. b&w, page size, resolution - it's all sent through metadata.
Scott Severtson Software Developer Auragen Communications scotty@auragen.com
IPP is a communications protocol, which can be used to encapsulate a printer language. As I said during the original argument, the IPP spec lists a couple of "recommended" protocols, including Postscript, PCL, HTML, and plain text, however, any printer protocol can be used. Normally, no drivers are sent - the client "IPP driver" knows already how to communicate in most standard printer protocols, so there is no need for a special driver. If the client "driver" doesn't know a common protocol, then there is the possibility of sending a minidriver, although such capability is not explicitly defined in the original specification.
As to setting up multiple printers on the same print server, IPP is designed around that idea. The spec even hints toward advanced capabilities, such as connecting to the print server, telling it what type of job you have, and the print server seamlessly picks the best printer for the job.
Scott Severtson Software Developer Auragen Communications scotty@auragen.com
OK, a brief run down after speed reading the IPP specification:
IPP is secureThe protocol specifies that Transport Layer Security (TLS) Version 1.0 will be used to provided mutual authentication and encryption. Elsewhere in the documents, (optional) compression can be applied as well.
IPP is complexWith support for multiple document protocols, multiple documents per "job", and a fairly detailed client querying process, it also won't be cheap.
Document protocols are specified as MIME types, and they define a couple recommended ones: PCL, Postscript, HTML, and plain text.
Documents can be sent as a URI (i.e. an HTTP URL), which, if the IPP server supports it, can be used to go out and retrieve the document when the printer is available to print it, instead of holding it in spool.
Multiple configurations are specified, with just waiting to be created. For example, IPP allows a printer with an embedded spooler and internet interface, a printer hooked to a spooling server with an internet interface, and multiple printers hooked to a spooling, smart server with an internet interface, which routes the document to the printer best suited/least busy for the job.
Supports extended properties for client querying. The single biggest advantage of the system is that the client does not have to have any idea of what type of print it is printing to, i.e. no more specific printer drivers. Instead, the client connects to the printer/spooler, asks it what it can do, and sends the document in a compatable format. This should (hopefully) save a lot of hassle in the work place for configuring printers on thousands of desktops.
Just my two cents.
Scott Severtson Software Developer Auragen Communications scotty@auragen.com
How about a keyboard in your pants? That's what the wonderful dreamers over at MIT's Media Labs have come up with - washable keyboards stiched directly into fabric.
Scott Severtson Software Developer Auragen Communications scotty@auragen.com
Slashdot Mirror
The IPP spec supports metadata about each printer and it's capabilities. If the IPP "client driver" is written correctly, it takes this metadata, and turns it into user choices on screen. The IPP spec does not know/care about any capabilities of your printer directly, i.e. color v. b&w, page size, resolution - it's all sent through metadata.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
IPP is a communications protocol, which can be used to encapsulate a printer language. As I said during the original argument, the IPP spec lists a couple of "recommended" protocols, including Postscript, PCL, HTML, and plain text, however, any printer protocol can be used. Normally, no drivers are sent - the client "IPP driver" knows already how to communicate in most standard printer protocols, so there is no need for a special driver. If the client "driver" doesn't know a common protocol, then there is the possibility of sending a minidriver, although such capability is not explicitly defined in the original specification.
As to setting up multiple printers on the same print server, IPP is designed around that idea. The spec even hints toward advanced capabilities, such as connecting to the print server, telling it what type of job you have, and the print server seamlessly picks the best printer for the job.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
- IPP is secureThe protocol specifies that Transport Layer Security (TLS) Version 1.0 will be used to provided mutual authentication and encryption. Elsewhere in the documents, (optional) compression can be applied as well.
- IPP is complexWith support for multiple document protocols, multiple documents per "job", and a fairly detailed client querying process, it also won't be cheap.
- Document protocols are specified as MIME types, and they define a couple recommended ones: PCL, Postscript, HTML, and plain text.
- Documents can be sent as a URI (i.e. an HTTP URL), which, if the IPP server supports it, can be used to go out and retrieve the document when the printer is available to print it, instead of holding it in spool.
- Multiple configurations are specified, with just waiting to be created. For example, IPP allows a printer with an embedded spooler and internet interface, a printer hooked to a spooling server with an internet interface, and multiple printers hooked to a spooling, smart server with an internet interface, which routes the document to the printer best suited/least busy for the job.
- Supports extended properties for client querying. The single biggest advantage of the system is that the client does not have to have any idea of what type of print it is printing to, i.e. no more specific printer drivers. Instead, the client connects to the printer/spooler, asks it what it can do, and sends the document in a compatable format. This should (hopefully) save a lot of hassle in the work place for configuring printers on thousands of desktops.
Just my two cents.Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
The links above are just for the IPP URL naming convention. Check out http://www.pwg.org/ipp/ for a full list of documents that are available.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
The 1.0 IPP specifications are available in PDF or in TXT formats. I'll post more once I've read them myself...
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
How about a keyboard in your pants? That's what the wonderful dreamers over at MIT's Media Labs have come up with - washable keyboards stiched directly into fabric.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com