Add IPP operations to request discovered devices and available drivers from Printer Application as server

[tillkamppeter]

Usually a Printer Application runs as a system daemon, especially if a Snap of the Printer Application is used. Then one can discover the running daemon via DNS-SD, as one can discover a network printer.

I am working on a Printer Application support for the GNOME Control Center, in its "Printers" module, mentoring a GSoC contributor to implement it. One part of his work is to let each already installed Printer Application discover the devices (printers on network, USB, ...) it supports.

For this he discovers at first the running Printer Applications via DNS-SD. They appear as IPP or IPPS network printers. Now he wants to make the Printer Application list the devices it discovers. A known and documented way to do so is to run the command line interface of the Printer Application, but there are two reasons why this is not a good idea:

1. From the DNS-SD record of the Printer Application one cannot determine its executable's path and name, so one could not call its command line interface.
2. If one could determine the name somehow (for example if you add an IPP operation to poll this name from the Printer Application) the Printer Application in CLI mode runs as a normal user (the one executing the GNOME Control Center) and as it does the discovery by itself when calling it with the "devices" sub-command, the discovery is performed as normal user and not as root, and so perhaps some devices do not get discovered, devices with which the actual Printer Application (the server running as root) can cope with.

Same problem with the driver list, at least (1) applies here. Not knowing the executable name one cannot use the "drivers" sub-command to list all drivers or to get the correct driver for a given device ID.

Therefore I want to request a new feature for PAPPL-based Printer Applications: IPP operations for getting the discovered printers (equivalent to the "devices" sub-command with all its options) and to list available drivers or find a driver for a given device ID (equivalent to the "drivers" sub-command with all its options), ideally even IPP operations for all sub-commands.

The IPP operations do not need to be defined in the IPP standard, if they get documented in the PAPPL documentation. AFAIK, CUPS also has non-standard IPP operations. If G-C-C uses them and fails with them on an IPP service, it knows that this service is not a PAPPL-based Printer Application but an actual network or IPP-over-USB printer.

I am very grateful if we could get this implemented still during this year's Google Summer of Code, which ends mid-September.

[michaelrsweet]

@tillkamppeter First, it is highly unlikely that I'll have time to implement this before the end of GSoC 2022. I won't rush it.

If the intent is to be able to automatically download and install a printer application for a given printer, this won't help. For USB-connected printers, we have already done the work for auto-adding printers. For network printers, the majority are IPP Everywhere/AirPrint already while the legacy ones don't always do anything useful (i.e. mDNS/DNS-SD or SNMP) that would allow for automatic printer application identification/usage. A central printer management/discovery GUI could certainly find these printers and then look for a printer application that can support them...

Regarding custom IPP operations, it is acceptable to define new vendor operation codes, though you still want to register them with the PWG to avoid stepping on other vendor extensions - CUPS has done this, for example. Ira and I manage the vendor extension registry on pwg.org...

The CUPS-Get-Devices operation is pretty close to what we need for the "devices" sub-command, but needs to be updated to operate on the IPP system object which didn't exist when I defined it for CUPS.

The CUPS-Get-PPDs operation is close to what we need for the "drivers" sub-command, but is sufficiently different that I'd want to design a new operation better suited for the purpose. Again, we need something that targets the system object and that can ask the printer application whether it has a driver for a given device URI, 1284 device ID, PostScript product name, or other identifier.

As for IPP operations for other subcommands, I will note that most of them already have standard operations - "submit" is Create-Job + Send-Document, "jobs" is Get-Jobs, "printers" is Get-Printers, etc. "autoadd" would use the "devices" and "printers" operations to do its thing. So really it is just "devices" and "drivers" that need to be supported.

[michaelrsweet]

OK, adding this to the 1.3 milestone now that I've pushed out proxy and OAuth to 1.4.

[michaelrsweet]

Proposed IPP extension:

[master 7fdb3d9] Add new IPP extensions documentation (Issue #214)

IPP-EXTENSIONS.md

[michaelrsweet]

Implemented w/unit tests.