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>