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

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

FW: 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 - 18:04:04 EST

  • Next message: Carl-Uno Manros: "RE: IPP> DRV - Client Print Support Files Internet-Draft down-loaded"

    Mike,

    History in the IETF has shown that if you try to take on a task that has too
    wide a scope it simply cannot be done. The IPP project waited for two years
    while other people in the IETF tried to come up with a generic solution to
    notifications and later also for immediate messaging. Both these areas have
    been stalled without progress, the notification one seems to be closed down
    for good, and the immediate messaging one is just barely still alive. Hence,
    IPP developed it's own solution to subscription for events and alternative
    notification delivery methods. This was not our choice, but became a
    necessity!

    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 2:18 PM
    To: 'Manros, Carl-Uno B'
    Subject: RE: IPP> DRV - Client Print Support Files
    Internet-Draftdown-load ed

    > From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]

    > I am just responding to your very first question on why we
    > want to do driver
    > download.

    Thank you for your reply. I understand why you might want the capability, I
    was mostly questioning whether it should be a part of IPP, or be a seperate
    protocol effort that IPP would then use, along with other protocols that
    need that functionality. Having every protocol define its own method of
    doing essentially the same task (selecting the right file to download and
    the processing to be done when it arrives) seems redundant to me.
    Redundancy of this sort is bad, unlike redundancy of connections or
    computers. :^)

    The security aspects would be critical for our market (OpenVMS), and
    probably for others as well. I expect security to become a bigger factor in
    everything net-related as more and more people and functions are shifted to
    cyberspace.

    > 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,

    You are welcome. Glad I could contribute something.

    -- Mike Bartman
       Process Software
       Principle Software Engineer



    This archive was generated by hypermail 2b29 : Wed Nov 08 2000 - 18:14:14 EST