On Sun 26 Feb 2023 at 17:09:51 +0300, Reco wrote: > Hi. > > On Sat, Feb 25, 2023 at 11:26:21PM +0000, Brian wrote: > > > It's interesting how you bring up DHCP, yet do not mention DHCP option 9 > > > (aka "option lpr-servers" in ISC lingo). > > > A proper implementation of DHCP options would make DNS-SD (and other > > > assorted kludges) completely redundant. > > > But that would be in an ideal world, and in the real world DNS-SD > > > serves its function (within its inherent limits of course). > > > If it works, that is. > > > > If the IP address changes, ipp://10.76.172.100/ipp/print as a > > URI becomes useless. DNS-SD ensures a reachable URI. Got it? > > There's no need to be rude.
Apologies if it came through like that. Note that rfc7472 says >...literal IPv4 or IPv6 addresses SHOULD NOT be used... > Leaving aside changing printer's IP (the main question here is why would > anyone would do it), how exactly DNS-SD helped Greg to print in that > environment? >From one of Greg Wooledge's previous mails: > + eno1 IPv4 Canon LBP712Cdn (db:c0:d3) > + eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] > + eno1 IPv4 hp LaserJet 4250 [621E13] He did not want to use these printers, but they would be shown in the print dialog of Evince (say), as would be the non-adverised printer if it had been set up correctly. A click or two to print. Alternatively, 'lpstat -l -e' and print with 'lp -d PRINTER FILE'. > > > > It would also be hoped that port numbers and resource > > > > paths are on the sheet of paper, otherwise a user will have a > > > > lot of guessing to do. > > > > > > Nope. RTFM would suffice, as always. > > > > I do not think you understand my argument. A port for an IPP > > printer need not be on 631 and the resource path need not be > > ipp/print. RTFM hardly helps when there is an immediate need > > to print. > > I wish you good luck in "convincing" typical dumb printer firmware in > performing such feats. Bonus points for "convincing" enterprise-grade > printer firmware to do the same. IPP printers need not be physical printers. > The main question here, of course, is why complicate things without the > need? > > > > RTFM? Which ones would you recommend? > > This one is good enough: > > https://www.pwg.org/ipp/ippguide.html > > > > Actually, CUPS performed splendidly. > > If CUPS in that configuration did not allow a user to print certain > amount of pages, then it cannot be called splendid. CUPS did not stop a user from printing. It knew of three printers (see above). The fourth was hidden from it. > > The OP was on a badly set up, unco-operative network. That was (and > > probably still is) the root of the issue. > > And here it's you who seem to misunderstand the issue. > It's a city hall, or something like it. People come there, some are in > the need of printing. > > We have a confirmed and documented case of CUPS failing to deliver the > desired result (i.e. printing something) in that environment. Without > additional user configuration, that is. > > Last time I've checked, they did not provide CUPS on any Android phone > out of the box, and probably it's the same for Apple phones. > It's likely that some visitor would bring a laptop with them, and it's > likely that said laptop would run M$ Windoze (or whatever that > shovelware is called these days). > If mobile users or M$ laptop users would encounter any trouble printing > - surely someone would make something to fix it. > > Yet is was not fixed (for a year at most), so it's likely *it works for > the users*, so there's nothing to fix. Some user configuration on their > device may be required, or not, it's not relevant here. > > Does that mean that CUPS is in need of fixing? Of course not. > Does that mean that DNS-SD is not needed? Of course not. > Does that mean that the only way of printing something via CUPS is to > use DNS-SD? You can guess it, it's also not. > > > Moreover, printing something at a city hall is a rare (although > periodic) task. If the printer's IP changes between Greg's vistits there > - so what? A few quotes from Greg Wooledge's first mail: > Whatever I managed to do last year... it's not working this > year. I can only assume that my workplace's lovely IT > department... > When I tried to print this year's tax form to my local > printer, I learned that the default print queue I had > set up last year is no longer there. > This led to a complete rerun of everything from last > year... You ask - "so what?" As can be seen, it hardly results in a happy camper! > > > > How would an ordinary user go on? "Give them a piece of paper" sounds > > > > awfully like "Let them eat cake". > > > > > > Easy, a user should RTFM. Failing that, a user can use a different > > > device or OS, or *gasp* - just use ipptool. Given the environment, a > > > creative use of samba suite would probably solve the problem too, but > > > let's not get into *that*. > > > And there's that last step - just ask somebody. > > > > You welcome Big Boss into your office for a $100M deal. > > Nope. Either it's the "ordinary user" or it's the "Big Boss". > Please choose one. Big Boss represents all ordinary users. She knows printing "just works" when set up correctly. -- Brian.