I know that some feel that IPP is intended only for Internet (as
distinguished from intranet) printing; but I would suggest that IPP only
makes sense as a common IP printing service, indeed supplanting LPD and
the myriad of proprietary TCP/IP print services. It we structure IPP as
intended primarily for cross firewall communications, we are severely
limiting its applicability.
Considering that (to pick out a number), something in excess of 95% of
IP Printing will be within a local environment, coming up with a
printing protocol aimed at less then 5% of the traffic seems
inefficient.
Also, there are those who intend the IPP server to be implemented in a
stand-alone HTTP server; mandating some degree of security may have
little impact upon them since the servers are intended for non-local
communication.
However, a large potential class of IPP user would be constituted of the
smaller network printer which for cost effectiveness has an embedded IPP
capability. For this potentially predominant product class, security of
this sort is superfluous. To identify a mechanism for secure IPP is
necessary; to make it mandatory so as to burden the majority of the
units with something needed by relatively few does not seem reasonable
(although it perhaps smacks of the IETF rational that does not recognize
the intranet environment).
Also, as is pointed out, requiring SSL3 makes little sense since it is
an interim solution. Requiring TLS is unfeasible since it is not final.
Mandating a capability which is still in such flux does not seem
appropriate to getting IPP up and running. We should again consider
whether our objective is just to create a specification, or to enable
the inclusion of a new, necessary and viable printing service in printer
products.
Bill Wagner
DPI/Osicom