I am debugging some printing issues on a small LAN, and although I'm fairly sure the issues I'm facing are not related to cups itself, I have been tinkering with the printing protocols that both CUPS and my printers (Konica Minolta Bizhub C224E and C3350) understand.

That made me wonder: is it just a matter of knowing which protocols your printers support, or is there any hierarchy between them? From the extensive reading I did, I seem to be able to deduce that LPD is fairly old and IPP(14) the 'new kid on the block', but does this new protocol offer real benefits or not?

Thx to @RuiFRibeiro I found some resources on the AskUbuntu site and one of them was pointing to an obsolete cups.org FAQ, which led me to a link that I had missed before: https://www.cups.org/doc/network.html . This page lists the most important differences:

AppSocket Protocol

The AppSocket protocol (sometimes also called the JetDirect protocol, owing to its origins with the HP JetDirect network interfaces) is the simplest, fastest, and generally the most reliable network protocol used for printers. AppSocket printing normally happens over port 9100 and uses the socket URI scheme:

socket://ip-address-or-hostname

Internet Printing Protocol (IPP)

IPP is the only protocol that CUPS supports natively and is supported by most network printers and print servers. IPP printing normally happens over port 631 and uses the http (Windows), ipp, and ipps URI schemes:

http://ip-address-or-hostname:port-number/resource
ipp://ip-address-or-hostname:port-number/resource
ipps://ip-address-or-hostname:port-number/resource

Line Printer Daemon (LPD) Protocol

LPD is the original network printing protocol and is supported by many network printers. Due to limitations in the LPD protocol, we do not recommend using it if the printer or server supports one of the other protocols. LPD printing normally happens over port 515 and uses the lpd URI scheme:

lpd://ip-address-or-hostname/queue

The main advantage of IPP over JetDirect/AppSocket are these:

• AppSocket is a "fire and forget" protocol. IPP(S) can give a very detailed backchannel info about the current state of job processing (which page is currently printed), and more (like query about past, completed or cancelled jobs).




• AppSocket is a very simple protocol, so everybody could reverse engineer it after HP introduced it and even though it never was an official standard; it's also quite reliable and robust (with all this empty set of 'features' it supports) -- which is why it was widely used and supported by virtually every network printer out there.




• IPP is standardized by the ISTO Printer Working Group (PWG), which is a representation of practically every single printer manufacturer around the world. HP themselves even have embraced IPP quite closely, having more than 350 of their newest printer models self-certified to be consistent with the new IPP Everywhere Standard.




• With IPP(S) you have much better options related to security: authentication/authorization, encryption of transferred data, access control, etc.




• With IPP you have a specified set of names and values for print job options. Duplex printing is either one of 'sides=two-sided-long-edge' or '...=two-sided-short-edge', whereas before, you could have up to ten or more ways to specify a duplex printout (because every vendor was free to use his own naming scheme). The same holds true for many other print parameters.




• IPP(S) allow you query an IPP-enabled printer (and more than 90% of devices sold in the last 10 years can talk IPP -- because AirPrint can only work because of it; and more than half of these can directly consume PDF too) about its specific capabilities: Can it do color? Which paper sizes does it support? Does it do duplex prints? Can it staple, punch, fold? Which IPP versions does it support? Which Page Description Language (PDL -- PostScript, PDF, PCL, JPEG, etc) can I send to it? Etc.pp. ...




• With the latest evolution of the IPP Standard, aptly called 'IPP Everywhere', finally driverless printing starts to work. CUPS can do it! Whenever it encounters an IPP Everywhere printer, it does not need any driver and/or device specific PPD prepared or pre-installed by the administrator any longer: it knows it can send one of the standard page description formats (either of JPEG, PWG-Raster, URF-Raster or PDF which don't require a proprietary driver to generate), it can query the device about its specific capabilities and it will auto-create a PPD reflecting these capabilities so even non-IPP-enabled applications can still print the traditional way (these 'legacy' apps don't talk IPP yet and are used to look for PPDs -- apps like LibreOffice or Firefox or what-not do).

IPP is the future, and the future is already here. (AppSocket is the past, but it is not yet completely gone. Most IPP printers still talk AppSocket too....)