"McDonald, Ira" <imcdonald@s...> wrote:
> Hi Mike,
>
> I originally thought we should just make available standard
> (not 'ipp:') URLs for driver software (like 'ftp:', 'http:')
> and let the client fetch the driver by conventional file
> transfer.
>
> But the waters get muddy. Because IPP aspires to operate
> over the public Internet and because it chose HTTP as the
> transport substrate (largely to try to punch through firewalls
> - which didn't work out, by the way),
>
I wouldn't say that. IPP through firewalls worked fine at the Bakeoff. I
think the key advantage of having HTTP as the substrate is that the
firewall issues are well known and understood from HTTP experience. You
can allow outbound print through a firewall with no more risk than allowing
HTTP POST. You can set up a secure inbound IPP gateway with no more risk
than running a secure web server.
> some IPP WG members
> believe that it's important to hide file transfer of drivers
> inside the SAME IPP session already established out onto
> the Internet and back into some other (target printers)
> private net.
>
I don't think its a desire to hide anything, just a desire to provide a
positive "user experience". Hunting down and installing drivers is a
notorious PITA. Supporting multiple protocols through firewalls, etc., is
also a pain. If it takes two protocols to print (one for obtaining the
driver, one for submitting the job), the chances of success get cut in
half.
-Carl
> Since the OSF, W3C, IETF, DMTF, and several others are already
> trying to promote various software distibution protocols (which
> are much more than just file transfer, as you indicated), I
> agree the whole IPP driver download feature is dubious.
>
> Cheers,
> - Ira McDonald, consulting architect at Xerox and Sharp
> High North
>
> -----Original Message-----
> From: Mike Bartman [mailto:bartman@p...]
> Sent: Wednesday, November 08, 2000 2:20 PM
> To: 'ipp@p...'
> Subject: RE: IPP> DRV - Client Print Support Files
> Internet-Draftdown-load ed
>
>
> > From: Manros, Carl-Uno B [mailto:cmanros@c...]
>
> > 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 : Fri Nov 10 2000 - 17:06:30 EST