Re: Recommended way to manually add an undiscovered IPP printer in CUPS 3.x

Abdelrahman,

> On Aug 2, 2026, at 5:18=E2=80=AFAM, AbdElRahman Khalifa =
<[email protected]> wrote:
>=20
> Thank you for the explanations. I think I now understand the
> separation between printer profiles, the local server, and the sharing
> server.
>=20
> My current understanding is the following:
>=20
> 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.

Correct.

> 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.

The destinations returned by cupsEnumDests should have device-uri, =
printer-location, printer-make-and-model, printer-type, and printer-uuid =
as extracted from the TXT record.  Local queues will have more =
attributes (including printer-uri-supported which provides the local =
CUPS queue) but there should be no need to separately browse.

Also, the CUPS DNS-SD APIs are available and will isolate you from other =
OS changes below you. For example, the systemd folks have been trying to =
replace Avahi for several years now - it is possible they might actually =
succeed some day, and using the CUPS APIs will insulate you from that =
change...

> 3,. COSMIC Printers should not create or edit printer profile files.

You could conceptually provide an admin tool for "exporting" profiles to =
provide to end-users, but beyond that I don't think there is much point.

> 4. Profiles belong to the local-server/libcups discovery mechanism.
> When libcups supports them, profile-defined destinations should appear
> naturally through cupsEnumDests().

Correct.

> 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.

Correct.

> 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.

Correct.

> 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.

There may not be a sharing server.  There will always be a local server.

A "driverless" printer that has to be manually configured can be setup =
via a printer profile with the local server. The sharing server only =
needs to get involved if a) the printer is on a separate network that =
only the sharing server has access to or b) there is a need to =
control/monitor access to the printer as you detail in #5 above.

________________________
Michael Sweet