Re: Printer's IPP response declares AirPrint, but it's missing urf-supported - workaround?

Zdenek,

> On Jan 19, 2024, at 2:02 AM, Zdenek Dohnal <[email protected]> wrote:
> ...
>> AirPrint *does* require firmware updates for broken implementations and security issues, so just because this printer isn't reporting everything doesn't mean it won't get a firmware update.
> Aha, I thought that if the printer is older and manufacturer decides to no longer support it, then there won't no firmware updates.

Well, that can still happen.  The idea is that if a vendor releases a firmware update that breaks AirPrint, they are on the hook to fix it.  But they aren't on the hook to support a printer indefinitely, just to ensure that AirPrint continues to function while they are doing updates.

> But it only applies when the model uses AirPrint right? We can't make a point like this if printer supports other driverless standards, like IPP Everywhere, right?

Correct, although I'm not aware of any printers that only support IPP Everywhere and not AirPrint.

> From the another side - one more question about AirPrint/driverless support - is it standardized how printer says the fact "I support AirPrint, but it is currently disabled in settings" in IPP response to Get-Printer-Attributes request?

Conceptually you could look for the 'airprint-N.N' keywords in the "ipp-features-supported" attribute, but in practice that isn't 100% reliable because disabling AirPrint might also disable IPP support.

> So if the printer follows the standards, I can tell it is configuration error from IPP response?
> The mentioned model showed image/urf in document-format-supported, but no urf-supported in response when AirPrint was disabled - once we found out the connection between those two facts (AirPrint was disabled), it appears to me like a good way how to say something is disabled in the response.

Possibly, but that is just an implementation detail and not standardized.

________________________
Michael Sweet