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 at 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 at cp10.es.xerox.com>>> -----Original Message-----
> From: Mike Bartman [mailto:bartman at 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 at 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
>