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 - 17:02:34 EST

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

    > From: Michael Sweet [mailto:mike@easysw.com]
    > Mike Bartman wrote:
    > >
    > > 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
    > > ...
    >
    > The original purpose of IPP was to replace LPD, and LPD handled
    > a few printer administration issues as well as the mundane print
    > and cancel job type operations.

    Not from what I can see in RFC 1179. It has some job control functions, and
    status reporting, but nothing more than that. To be similar to this driver
    business it would have had to include functions to do things like create and
    delete remote print queues, install server-specific versions of LPR and LPQ,
    etc. on remote hosts, and I don't see anything like that.

    > Whether or not to address administration issues in IPP has been
    > an ongoing battle. IMHO *not* providing support for operations
    > and features needed beyond the printer will hurt IPP in the
    > long run. Network printing has always been a pain, and
    > providing a single, vendor-neutral protocol for all printing
    > stuff is the only way to fix that.

    I don't dispute the need for a vendor-neutral printing protocol, as I said,
    I've been battling the limitations of LPD for a couple of years now. I also
    don't dispute the possible need for a method of sending out safe and
    appropriate software to clients of servers. I'm just questioning whether
    every specialized area of network interest should "reinvent the wheel" in
    its own protocols. I think it might be better to have a "software
    distribution" protocol specifically to address that need, and then let
    printers, terminal servers, browsers, and anything else that needs that
    functionality implement the same thing...not several of them, one for each
    protocol it uses.

    > Will printer manufacturers include driver download support in
    > their products? I doubt it - too many driver revs, languages,
    > and OS's to fit in limited ROM/flash memory. More likely this
    > extension will be used by IPP-capable printing systems on desktop
    > or server machines.

    It seems most likely that the server will actually fetch the required
    software, in those cases where it exists, from some other server...probably
    at the manufacturer's site. That's the way the HP printer we have works
    now.

    -- Mike Bartman
       Process Software
       Principle Software Engineer



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