Mike,
I am just responding to your very first question on why we want to do driver
download.
Your comparison of printers to servers and routers doesn't quite hold.
When we developed IPP we had somewhat different scenaios in mind than the
currently common ones where you might only be using a single networked
printer somewhere on your office floor, and maybe a more advanced color one
somewhere in the building where you work.
The Internet part of the IPP name means that we are serious about moving
network printing out of your own LAN and into the worldwide Internet. There
have been intensive discussions about IPP's ability to replace the current
use of fax, and the IEEE-ISTO PWG currently has a project on how to entend
IPP to gracefully handle TIFF/TIFF-FX negotiation in real time to relieve
users from having to download print drivers. In the meantime, and for
traditional print formats like Postscript and PCL we are still stuck with
the need to have a different print driver for almost every combination of
printer model and client platform. If you really want to use IPP as
replacement for fax and will start using it to send print data to a number
of different printers around the world every day, then you start realizing
why the IPP project sees the automatic download and installation of print
drivers as an important requirement.
Your points on the security aspects of downloading any code from a printer
(or some referenced server on the web) are well taken and we may need to
look more closely at that problem before we are done. Also, your point about
more generic drivers that might be platform independent or rely on scripting
or parameter files rather than complete unique drivers, needs to be taken
into consideration.
Thanks for your comments,
Carl-Uno
Carl-Uno Manros
Manager, Print Services
Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
-----Original Message-----
From: Mike Bartman [mailto:bartman at process.com]
Sent: Wednesday, November 08, 2000 12:02 PM
To: 'ipp at pwg.org'
Subject: RE: IPP> DRV - Client Print Support Files
Internet-Draftdown-load ed
I'm curious as to why this question of drivers and CPUs is part of IPP. It
seems to me that printer administration is a separate issue from printing,
and should be dealt with in a separate protocol...perhaps one more generic
to the question of networked machine interoperability. There's no basic
reason why printers should support distribution and installation of software
used to communicate with them in any different fashion than terminal
servers, firewalls, or modems, or anything else. If the IPP creates a
protocol for downloading printer firmware into hosts, and modem makers come
up with a different one for modems, and routers come up with one for
routers, etc., we'll have a new Tower of Babel. If there's a real need to
let network devices distribute their software automatically, or
semi-automatically, then there should be a separate protocol for doing so,
not a bump on the side of a printing protocol. There are already signs of
this problem developing with browsers and the ways they get and install
plug-ins.
Also, if you are going to try to name all the names of CPUs in this thing,
you might want to consider all the non-CPU-specific names that should be
included. There's no reason why future "drivers" will have to be limited to
specific CPU models. They could be written in scripting languages such as
Python, or distributed as source code to be compiled for the specific
system, or in some other fashion where the type of CPU making the request is
irrelevant. By trying to make the target a keyword, or even a mime type
(how did mail extensions get into this? :^) you let yourself, and future
generations, in for a major PITA every time technology advances. I've been
fighting with the total lack of foresight of those who created the LPD
protocol for years now, and I'd prefer that the replacement for such
protocols be a bit more automatically extensible to cut down on proprietary
variations created to work around limitations in the spec.
There's also the security factor. It's good to remember that not all
computers are single-user workstations that have no concept of security in
their OSs. Some are multi-user machines with OSs designed with security in
mind, where an average user will not be able to download and install
"printer drivers", even if the average printer had a driver for them...which
they don't tend to do (they are usually limited to Microsoft drivers only,
and not even all of Microsoft's OSs). Even those users with the account
privileges needed to install such software will have a STRONG aversion to
doing so. It's OK to take wild risks with your software when you are a
little sports car on the info superhighway, and quite another to drive so
recklessly when you are driving a fully loaded tour bus. ;^)
-- Mike Bartman
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> Sent: Wednesday, November 08, 2000 2:16 PM
> To: 'Michael Sweet'; Hugo Parra
> Cc: ipp at pwg.org> Subject: RE: IPP> DRV - Client Print Support Files
> Internet-Draftdown-load ed
>>> Hi Michael and Hugo,
>> Don't shoot at me yet...
>> I agree that there is real danger in fetching a whole driver
> without any guarantee of the integrity (and actual source)
> of the driver. An IPP Printer with weak security becomes an
> attractive target for trojan horse exploits.
>> Since all the drivers will be labelled MIME types, what about
> using an S/MIME (Secure MIME) wrapper to authenticate the driver?
>> See RFC 26333 (S/MIME v3 Messages) and RFC 2632 (S/MIME v3
> Certificate Handling)?
>> Comments?
>> Cheers,
> - Ira McDonald
>> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Wednesday, November 08, 2000 10:47 AM
> To: Hugo Parra
> Cc: ipp at pwg.org> Subject: Re: IPP> DRV - Client Print Support Files
> Internet-Draftdown-loaded
>>> Hugo Parra wrote:
> > ...
> > > I'm also confused about the use of a MIME type for the
> > > document-format value and a keyword for the file-type value...
> >
> > Michael, can you be more specific. It's not clear to me what is it
> > that you're finding confusing.
>> Well, the driver file will also have a MIME type, right? Why bother
> with a non-standard keyword value when a MIME type will do?
>> (this may mean registering MIME types for some of the types you
> have listed, but using a MIME type will allow you to use other
> types of driver files in the future without having to specify
> them in the spec...)
>> > ...
> > This field was added by the group in the Chicago meeting. We
> > looked at several scenarios where a user or program would need
> > this additional information to select the "right" print support
> > file. The value of this field may be populated by a printer
>> I wouldn't use "policy" as the name then; maybe a "preference"
> number, like the preference numbers used for mail exchangers?
>> The danger I see here is that a malicious user could provide a
> bogus printer driver or a manufacturer could have a buggy driver.
> Supporting a "policy" type of value implies that certain policies
> could force an automatic install of the driver (without user or
> admin approval), which opens the door to all sorts of problems.
> Without some sort of signature or certificate, you can't "trust"
> the driver you are downloading...
>> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mike at easysw.com> Printing Software for UNIX http://www.easysw.com>