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

Hi Zdenek,

(Resending because the list rejected an HTML email message.)

> On Jan 19, 2024, at 12:02 AM, Zdenek Dohnal <[email protected]> wrote:
> 
> CAUTION: External Email Mike,
> the issue became only theoretical - user found out the printer has Airprint settings and it was disabled. Enabling fixed the issue.
> Nevertheless it is still an interesting question for me (we might encounter a similar problem in other device, where firmware updates are not planned...), so thank you for the answer!
> On 1/18/24 22:56, Michael Sweet wrote:
>> Not generally, since the supported raster resolutions are usually less/lower than the printer's supported resolutions.
> So it is degradation in functionality, but not completely out of equation for breaking standards - that's useful.
>> 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.
> So IIUC as part of AirPrint certification AirPrint requires firmware updates for broken implementations and security issues, otherwise the model loses AirPrint certification? If so, that's a great thing to know - it is good argument which users can use when talking with manufacturer support.
> 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?
> 
> 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? So if the printer follows the standards, I can tell it is configuration error from IPP response?

I cannot think of any certification program that has a set of tests that validate such a state, IPP or otherwise.

I have found that the most robust and appropriate methodology for enabling any feature is to identify the set of requirements that must be met for that feature to be enabled. If those requirements aren't met then the feature is just not enabled. If the logic keys off of a subset of the required attributes, you will have false positives.

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

That does seem a bit buggy, but again, if the set of requirements for enabling URF output support is "document-format-supported" includes 'image/urf' and "urf-supported" is present then you wouldn't have a false positive.