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