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: Manros, Carl-Uno B (cmanros@cp10.es.xerox.com)
Date: Wed Nov 08 2000 - 16:39:06 EST

  • Next message: Mike Bartman: "RE: IPP> DRV - Client Print Support Files Internet-Draftdown-load ed"

    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@cp10.es.xerox.com

    -----Original Message-----
    From: Mike Bartman [mailto:bartman@process.com]
    Sent: Wednesday, November 08, 2000 12:02 PM
    To: 'ipp@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@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 - 16:49:17 EST