[MOD] STR #4106: "ipp" tries to query a CUPS server with lots of SNMP requests

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

The operating system on which I have observed this (with Wireshark) is
MacOS X 10.6.  It may or may not occur under different OSs.

Email exchange with Michael Sweet, part of which is relevant:

> I couldn't find it in the documentation, but it seems that using
"ipp://server/queuename" should be used to talk to printers, while
"http://server:631/printers/queuename" should be used to talk to a server.
 If this is documented, I would appreciate knowing where.

It isn't.  RFC 3510 is notably lacking in any conformance requirements for
the URI resource path, and RFC 2911 just talks about the printer URI in an
abstract sense.

CUPS and Windows use "/printers/queuename" and
"/printers/queuename/.printer", respectively, however there are printers
that use this form as well and are not CUPS or Windows-based.

Most printers use "/ipp" or something similar.

> "ipp" tries to query the printer with lots of SNMP requests.  If it's
used to talk to a server, and the server is not accepting SNMP requests,
then significant timeout delay occurs.

Please file a bug for this; we should be saving the lack of results to the
cache file so this only happens on the first print:

	http://www.cups.org/str.php

> "http" also generates SNMP requests, but only two.
http and ipp are the same backend and should be doing the same SNMP
queries.

> Is there any way to get the MacOS X CUPS client to _not_ generate SNMP
requests?
Add "*cupsSNMPSupplies: False" to the PPD file on the client. In this case
I'd file a bug with Apple to track adding this for all shared printers:

	http://bugreport.apple.com

Thanks!

Link: http://www.cups.org/str.php?L4106
Version: 1.4.7