Re: Recommended way to manually add an undiscovered IPP printer in CUPS 3.x
AbdElRahman Khalifa <[email protected]> Sun, 2 Aug 2026 12:18:37 +0300
| Newsgroups | dev.linux.lists.printing-architecture |
|---|---|
| Message-ID | <CAHK3-aqHugD6ZAjMSaOZadNrWZ6F5M=bKmUbWpDXN6c9yeVNyA@mail.gmail.com> |
Thank you for the explanations. I think I now understand the separation between printer profiles, the local server, and the sharing server. My current understanding is the following: 1. cupsEnumDests() should be the source of truth for the destinations displayed on the main Printers page. It can return automatically discovered IPP destinations, remote CUPS queues, Printer Application destinations, and eventually destinations supplied through profiles. Therefore, a destination must still be displayed even when I cannot find a corresponding local DNS-SD advertisement. 2. DNS-SD should be an enrichment and grouping source, rather than the authoritative destination list. I currently use Avahi to obtain information such as the service instance, hostname, port, resource path, TXT UUID, and the relationship between _ipp._tcp and _ipps._tcp advertisements. I will correlate this information with the destinations returned by cupsEnumDests() and use it for physical-device grouping. Where possible. 3,. COSMIC Printers should not create or edit printer profile files. 4. Profiles belong to the local-server/libcups discovery mechanism. When libcups supports them, profile-defined destinations should appear naturally through cupsEnumDests(). Queues owned by the sharing server are a separate concept. I should query the sharing server using its IPP System Service operations, such as Get-Printers, when I specifically need to list or administer the queues owned by that server. I should not infer that every destination returned by cupsEnumDests() is a configured sharing-server queue. 5. A normal driverless destination returned by cupsEnumDests() is already usable and does not require an Add operation. A queue on the sharing server should only be created if the user explicitly requests server-side sharing, relaying, accounting, access control, or similar policies, for example, when the user opens the Add Printer dialog and selects that printer. 6. For an undiscovered driverless printer entered manually via IP address or hostname, printer setup tool should probe it using Get-Printer-Attributes and then create a queue for it on the sharing server. Thanks, Abdelrahman