IPP Mail Archive: RE: IPP> DRV - Client Print Support Files

IPP Mail Archive: RE: IPP> DRV - Client Print Support Files

RE: IPP> DRV - Client Print Support Files Internet-Draftdown-load ed

From: Mike Bartman (bartman@process.com)
Date: Wed Nov 08 2000 - 15:01:58 EST

  • Next message: Michael Sweet: "Re: IPP> DRV - Client Print Support Files Internet-Draftdown-loaded"

    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@sharplabs.com]
    > Sent: Wednesday, November 08, 2000 2:16 PM
    > To: 'Michael Sweet'; Hugo Parra
    > Cc: ipp@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@easysw.com]
    > Sent: Wednesday, November 08, 2000 10:47 AM
    > To: Hugo Parra
    > Cc: ipp@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@easysw.com
    > Printing Software for UNIX http://www.easysw.com
    >



    This archive was generated by hypermail 2b29 : Wed Nov 08 2000 - 15:12:08 EST