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

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

[Zdenek Dohnal]

Hi,

I have user with HP Color Laser MFP M178nw (probably rebranded Samsung 
device, user made it work ULD drivers, which IIRC are from Samsung), 
which passes ipptool test for get-printer-attributes 2.0 and claims it 
supports image/urf and application/PCLm - image/urf is chosen - but 
CUPS' everywhere and cups-filters driverless fails to create PPD because 
'urf-supported' attribute is missing in response. Only 
printer-resolution-default is provided.

It looks the device worked at some point both via driverless ( 
https://github.com/apple/cups/issues/6031#issuecomment-1139556275 ) and 
IPP Everywhere (https://bugs.launchpad.net/hplip/+bug/1863316/comments/2) .

Is it possible to use printer-resolution-default and others as fallback 
when generating PPD, or is it against standards and can bring additional 
issues?

If it is rebranded model, IMHO there won't be any updates for firmware - 
there is one firmware update and user will try to install it, but in 
case it does not fix the issue, it would be interesting to see what we 
can do.


Thank you in advance,


Zdenek


[1] attr log of ipptool https://gitlab.gnome.org/-/snippets/6419

-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

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

[Michael Sweet]

Zdenek,

> On Jan 18, 2024, at 9:28 AM, Zdenek Dohnal <zdohnal@redhat.com> wrote:
> ...
> Is it possible to use printer-resolution-default and others as fallback when generating PPD, or is it against standards and can bring additional issues?

Not generally, since the supported raster resolutions are usually less/lower than the printer's supported resolutions.

> If it is rebranded model, IMHO there won't be any updates for firmware - there is one firmware update and user will try to install it, but in case it does not fix the issue, it would be interesting to see what we can do.

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.

Can you try the following test:

{
    NAME "Get urf-supported"
    OPERATION Get-Printer-Attributes
    GROUP operation-attributes-tag
    ATTR charset attributes-charset utf-8
    ATTR language attributes-natural-language en
    ATTR uri printer-uri $uri
    ATTR keyword requested-attributes urf-supported
    STATUS successful-ok
    EXPECT urf-supported
}

________________________
Michael Sweet

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

[Michael Sweet]

Zdenek,

> On Jan 19, 2024, at 2:02 AM, Zdenek Dohnal <zdohnal@redhat.com> 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

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

[Kennedy, Smith (Wireless & IPP Standards)]

Hi Zdenek,

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

> On Jan 19, 2024, at 12:02 AM, Zdenek Dohnal <zdohnal@redhat.com> 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.