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: Thu Nov 09 2000 - 11:54:06 EST

  • Next message: Manros, Carl-Uno B: "IPP> FW: [ietf-tls] I-D ACTION:draft-ietf-tls-kerb-00.txt"

    I understand. Yet another case of "the right way vs. the possible ways".
    Sigh.

    -- Mike Bartman

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

    > 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 : Thu Nov 09 2000 - 12:04:15 EST