Well, at least this printer does not support PostScript, otherwise it
is a real security hole. I do not understand why there is a desire to
have this class of printer be _fully_ compliant with IPP in order to
do most IPP things. It would seem to me that nobody is forcing a
printer to full compliance, only that a non-compliant printer must not
claim compliance. This is pretty common in the real world with other
protocols. Most machines don't comply in so way or another, but
then they don't claim compliance (well, some do -- grrrr).
I think that it would be fine to build such a printer. I would buy one for
home, even. I would think twice about it, even for home, if it supported
a language like PostScript, and was more than just a dumb printer.
Of course, I'm a little confused as to what constitutes a *real* IPP
printer. If you built something like a Netport device that was attached
to a dumb printer, but "did" IPP, is the combination an IPP device?
How about a driver on a host attached to a dumb printer? If the first
is acceptable, then the second should be as well, since it is effectively
the same thing -- just that the host box runs more stuff.
Can a dumb printer, that does not support all of IPP gain full compliance
by using a host-side driver to handle the difficult stuff? For instance, it is
true that you can't store an endlessly long password file in NVROM, but
you can create a secure connection to a host machine that can. These
are all networked devices, so they are never in isolation. Can an existing
printer "become" an IPP device simply by having a dedicated server host
these functions? Is a NIC card that does IPP any different than this?
I would hope so.
I live in an area that is considered "safe" -- nobody locks their doors, and
most people leave their keys in the ignition so they are easy to find. But
bad things can happen. Just because it does not seem likely, or has not
happened yet is no assurance, and a standard must be stronger than it
needs to be. Cars *need* locks, even if nobody where I live uses them.
Currently, most "enterprise" printers connected to networks have _no_
security. Most are PostScript devices. The company I work for has
thousands of them. You can damage all of them, and cause lots of
work for the administrators by sending a single line of PostScript:
0 setcolor {clippath fill showpage} loop
This would cause physical damage to most laser printers, and run through
amazing quantities of consumables -- and money. Such an attack
would be extremely difficult to absorb for most companies today, but they
generally have their doors wide open for this.
IPP should not sidestep this issue -- there will certainly be a market for
simple non-IPP compliant printers well into the future. Personally, I think
that stronger security is desireable.
I would rather build a stupid device, that had a simple secure connection
to a strong host, and have the host implement IPP and be "seen" outside
as the IPP printer, rather than trying to stuff more crap into one of the most
cost-reduced items in computing today. I would believe than most small
printers are already sold below cost. Adding more to them is generally a
loss.
Flame away -- I usually deserve it.
Malcolm Holser