On Sat 17 Aug 2019 at 12:59:16 +0300, Reco wrote: > On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote: > > > > ipptool depends on libcups2. > > Which does not make it require CUPS on the other side - [2]. > And note - a conventional RFC1918 IP is used there. No "discovery" > involved.
Anything from Kurt Pfeifle is always a worthwhile read. > > DNS-SD/Bonjour not scaling on typical multi-segment networks is a > > recognised issue by CUPS upstream. > > An interesting example of corporate doublespeak, but it does not change > what I wrote - you need multicasts working - you put both sender and > receiver in a single network segment. > And that's bad for security, and is so last century. I don't think the principal upstream CUPS developer is given to speaking with a forked tongue or pulling the wool over people's eyes, > > Anyway, the secretary has knocked off and I am left to instruct my VIP > > how to use his Android phone to type the printer location without a > > mistype: > > > > dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 > > You overcomplicate things without the need. Neither myself nor my VIP know what we are doing. We just wish the sysadmin had had the commensense to set up printing so a tap on a queue/printer name would have sufficed. > ipp://<ur_printer> is all you need. Eventually we hit on ipp://<IP_address>/<resource>. The resource name format depends on whether a queue or printer is being printed to. -- Brian.
