Supported job attributes in printer clusters

[kabassanov]

Hello,

On linux clients when the same printer is defined through different uris ( like ipps://... vs ipp:// ) a check is made in order to verify whether the printer supports the requested job attributes (supports_job_attributes_requested in cups-browsed.c). But there is a problem because human readable values are compared to internal ones. Example: SinglePortrait vs staple-top-left. I'm not sure which one should be remapped before comparison...

[deepak0405]

Hey @kabassanov, Thanks for reporting the issue. Can you please share how can I reproduce this issue ?

[kabassanov]

Hi @deepak0405,

Everything started when I tried to implement the same behavior as the one of some AirPrint printers registering ipp and ipps on separate tcp ports (631 and 443 for instance). The reason, there was an error with some terminal clients and I supposed that there was a mess with the SSL/NO SSL switching on the server port 631. I opened an issue about this: OpenPrinting/cups#638, but it seemed that it was not easy to validate.

Anyway, I patched in a testbed my cupsd code in order to annonce and send ipps traffic to tcp port 632.
dirsvc.c.diff.txt

with in addition:
SSLListen myhost:632 in the cupsd config file.

With this, on the client side, I started receiving two different annonces for the same printer, thus creating a printer cluster. But it was impossible to use it, because the attribute mismatch was leading to the conclusion that both printers were not supporting the requested option.

I have no idea how to reproduce the issue otherwise. If possible, see if an AirPrint printer with ipp and ipps enabled leads to the same cluster creation...