I think a PRINT method would be less breakage when you consider both the
true "internet" printing scenarios, as well as the "intranet" printing
scenarios. I think we're forgetting the simple case (direct client to
origin server) lately in our discussion. If I'm operating in an intranet,
running something like the Apache web server,then I don't care about
filtering issues (necessarily), so I would like to just work up a
server-side extension (CGI, NSAPI, servlet,etc.) that works with my
existing server. If I use a default port number for IPP that is different
than port 80, then some web servers (take your pick, either host-based or
embedded) would require that separate instances of the server be running,
which requires at least one extra configuration file,and possibly another
set of server log files.
If a single instance of a web service can "listen" on more than one port
number, then its not as bad, but I just thought a PRINT method would be
more straightforward. Playing devil's advocate for a moment against my own
proposal, I am aware that some pure firewall products do not have the
ability to filter on HTTP methods, rather they usually filter on port
number, and source/destination IP addresses/networks.
Basically, choosing a new default port number causes "everyone" to
reconfigure, even those that are not worried about filtering.
Randy