IPP is the Internet Printing Protocol, implemented by CUPS, running on macOS and most Linux system for printing. IPP is specified and standardized by the ISTO PWG (Printer Working Group).

The newest incarnation of IPP, called "IPP Everywhere", is designed to bring "driverless" printing to the world, across all major operating system platforms.

How does this work? Simple:

1. There are no longer any "proprietary" printer languages exclusive for a printer. IPP-enabled printers MUST support PWG Raster and JPEG as print job spooling formats and MUST support PDF as a print job spooling format when the printer uses IPP/2.1 and IPP/2.2. (PDF support is optional for a printer using IPP/2.0).

2. IPP-enabled printers are able to respond to queries investigating about their capabilities. (Can they print duplex? Can they print in color? Do they support stapling? Have they paper with A3 dimensions loaded? How much ink do they have left? etc.pp.)

3. IPP-enabled clients are able to query printers prior to any print job submissals. Thusly they "learn" about a target printer's capabilities. Now they can offer only these job options for users' selection which are supported.

4. IPP clients sends job as PDF (or PWG-Raster), alongside the desired job options expressed as "IPP Job Attributes".

Have you ever used iPads or iPhones to print via "AirPrint"? Then you've experienced an incarnation of driverless printing which was inspired by the PWG's earlier efforts for IPP Everywhere!

This software is a sample implementation for the IPP Everywhere specification. Its source code repository is here:

• https://github.com/istopwg/ippsample

The current version is not yet the final release, but identifies as Beta 1 ("v1.0b1").

Of course you are free to build the software on your own system and use it from there.

If you are a Linux user, the following gives you a much faster and easier access. (IPP Sample has not yet landed in most distribution's repositories.) The tipp for an easy access is this:

• Use the ready made, pre-compiled binaries in the AppImage the handling of which is introduced below.

AppImages are a way to package applications in a very elegant and efficient way to make them run across a large range of Linux distributions. They sport the following features:

• They follow the paradigm "One App == One File" which makes handling them super-easy.
• No need to install ANY framework or install a new "package manager" prior to use them.
• No need for root privileges.
• No need to "install" an AppImage. Simply run it. (Just make it executable first.)
• Runs from any location (including USB thumb drives or Windows/SMB/Samba network shares).
• Can auto-update to newer version via "binary delta" downloads to save bandwidth and time. (Requires the AppImage packager to have correctly followed a few rules.)
• Can run multiple versions of the same software side by side.
• Integrate into desktop environment (add menu entries, use correct icons, etc.) when (optional) appimaged daemon is running. (This daemon will auto-discover additions and removals of AppImages on a system.)

You can read more about AppImages here:

• Website: https://appimage.org/
• Github repos: https://github.com/AppImage/AppImageKit
• Github Wiki: https://github.com/AppImage/AppImageKit/wiki

How you can use this AppImage is demo-ed in the ASCIIcast below. Click to run it:

Three initial tipps for watching the ASCIIcast:

1. You can pause it any time you want, and later continue it, should it run too fast for you.
2. You can copy'n'past stuff from the viewer window.
3. Use [ctrl]+[-] to zoom out if your screen doesn't show the complete viewer window.

You can re-duplicate what is demo-ed in the ASCIIcast by downloading the latest AppImage (only available for 64bit Linux systems) of the IPP Sample Software:

 wget -c https://github.com/KurtPfeifle/ippsample/releases/download/continuous/ippsample-xperimental-x86_64.AppImage

(Or just click this link to download it with the help of your browser: https://github.com/KurtPfeifle/ippsample/releases/download/continuous/ippsample-xperimental-x86_64.AppImage )

If you are familiar with AppImages already -- this one pushes the envelope and is a bit "unusual":

1. It has not a GUI application embedded, but works with the IPP Sample CLI.
2. It does not follow the "One File == One App" paradigm, but rather a "One File == Multiple Apps".

Hence, the main name of the AppImage, 'ippsample' is not an App or embedded executable by itself. Instead it is used to let you run the four embedded CLI utilities (ippfind, ippserver, ipptool and ippproxy) as 'sub-commands' (similar as busybox works, if you are familiar with that).

After download, you have to make the AppImage executable:

 chmod +x ippsample-xperimental-x86_64.AppImage

Now you can already start to use it:

 ./ippsample-xperimental-x86_64.AppImage

However, in the long run, always typing ippsample-xperimental-x86_64.AppImage feels awkward... We recommend you to either symlink to or re-name the original AppImage to something shorter, like ippsample. Then, to run ippfind without additional arguments, simply type:

 ippsample ippfind [ENTER]

The same applies to any of the other sub-commands:

 ippsample ippserver [ENTER]
 ippsample ippproxy [ENTER]
 ippsample ipptool [ENTER]

If you run ippsample without any sub-command, it is falling back to the default sub-command, ippserver, and runs just that.

To see an overview of all the options you have which are specific to this AppImage, run

 ippsample --help

Here's an overview about the most important ones:

  ippsample --listman                           # List all embedded manual pages
  ippsample --man ippfind                       # Show manual page for ippfind
  ippsample --man ippserver                     # Show manual page for ippserver
  ippsample --man ippproxy                      # Show manual page for ippproxy
  ippsample --man ipptool                       # Show manual page for ipptool

  ippsample --html ippfind                      # Open HTML version of manpage in default browser
  ippsample --html [ippserver|ippproxy]         # Open other manpages as HTML
  ippsample --html [ipptoolfile|ipptool]        # Open other manpages as HTML
  
  ippsample --listtest                          # List all .test files which are embedded in AppImage
  ippsample --cat get-printer-attributes.test   # Print contents of 'get-printer-attributes.test' file
  ippsample --listtestdoc                       # List all embedded .pdf, .jpg, .pcl, .pwg-raster, .ps, .3mf, .sla, .scad and .stl test docs
  ippsample --extracttestdoc <filename>         # Extract and save named test document from AppImage
                              
  ippsample --appimage-help                     # Show options which are common to ALL recent AppImages
  ippsample --appimage-extract                  # Unpack AppImage contents into AppDir 'squashfs-root'

You want to re-duplicate and then play on your own with what this tutorial demo-es? Then prepare TWO terminals and place them next to each other on your screen.

In the FIRST terminal you should now run this command:

 ippsample ippserver -v -p 22222 "MyIPPSampleTestServer"
 
 --
 #    -v         - For SOME verbosity (needed to see / note down the ipp:https:// URI you need to use to query this ippserver process)
 #    -p 22222   - Specify a port number for ippserver to use (optional)
 #    "NAME"     - Pick your own (required).

Now cancel the process again ([ctrl]+[c]), and restart it with increased verbosity:

 ippsample ippserver -vv -p 22222 "MyIPPSampleTestServer"
 
 --
 #    -vv        - For maximum verbosity (optional; without it you won't see much)

In the SECOND terminal, run:

 ippsample ippfind

The output should show AT LEAST a line with an URI using "22222" port. Use this line whenever you are asked to use an "IPP URI". If you have shared CUPS queues or IPP-enabled printers in your LAN, these will show up as well. In MY case (as can be seen in the ASCIIcast above, this IPP URI was:

 ipp:https://lenjessie2.local:22222/ipp/print

You may want to watch what happens in the first terminal, whenever you fire a command in your second...

The built-in utility ipptool can do all kinds of typical IPP client stuff when communicating with another IPP endpoint (IPP print server or IPP-capable printer).

The IPP is a protocol which is largely based on HTTP (limiting itself to POST operations), but uses binary encodings for all of its operation codes.

This poses a little problem for humans: they will have a lot of problems to learn and specify any binary encoded HTTP POST operations on the command line.

Along comes ipptool: this utility can translate clear-text instructions it reads from a text file into the binary encodings used by IPP and send them to the other IPP end point. The only requirement is that these clear-text instructions are written in a specific syntax (which can be mastered more easily by human testers).

The specific syntax/language for ipptool is well defined. There are different ways provided by the AppImage enabling you to learn about it:

1. To read its manpage, run:

    ippsample --man ipptoolfile
   

2. Look at the list of usable example text files (usually suffixed as .test) by running:

    ippsample --listtest
   

3. Look at the content of such a .test file by running:

    ippsample --cat create-job.test
   

To query the IPP capabilities of the newly started ippserver process faking one (default) IPP printer, try this:

 ippsample ipptool -t -v ipp:https://<your-uri-from-above>/ipp/print get-printer-attributes.test

 ippsample ipptool -f color.jpg       -t -v ipp:https://<your-host-spec-from-above>/ipp/print  print-job.test  # send embedded 'color.jpg' to print
 ippsample ipptool -f document-a4.pdf -t -v ipp:https://<your-host-spec-from-above>/ipp/print  print-job.test  # send embedded 'document-a4.pdf'
 ippsample ipptool -f ./mylocal.pdf   -t -v ipp:https://<your-host-spec-from-above>/ipp/print  print-job.test  # use path to PDF (outside AppImage)

 ippsample ipptool                    -t -v ipp:https://<your-host-spec-from-above>/ipp/print  get-completed-jobs.test

Has your ippsample ippfind command from above discovered IPP-capable printers in your network? Even some you didn't know about previously?

This happened to two different friends of mine recently, after I had let them play with a preview version of my AppImage. One of them had bought his printer already three years ago. He was utterly shocked to learn that his printer could consume PDF files and that it supported IPP. Nobody at MediaMarkt had told him, and neither had it been advertised by the respective vendor. Which is a big, big shame... To me this is not so heavy a surprise, because MOST consumer printers which appeared on the market in the last few years already support PDF-direct and IPP printing (albeit maybe not to the fullest extend) -- but vendors almost never talk about it.

You now know how to run the get-printer-attributes.test and get-printer-attributes-2.0.test queries against the respective IPP URIs of your devices. Make use of them. Test your printers!

Let's see how IPP- and PDF-compliant they are... Complain to the vendors if they didn't implement IPP correctly... Let's make IPP Everywhere more popular!

From here, you may already be able to start learning to "walk the IPP walk" on your own... :-)

^{(Tutorial written by Kurt Pfeifle in private capacity. Not endorsed by the PWG.)}