IPP> DRV - Client Print Support Files Internet-Draftdown-load ed

IPP> DRV - Client Print Support Files Internet-Draftdown-load ed

IPP> DRV - Client Print Support Files Internet-Draftdown-load ed

Mike Bartman bartman at process.com
Thu Nov 9 11:54:06 EST 2000


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
> 



More information about the Ipp mailing list