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

Carl Kugler/Boulder/IBM kugler at us.ibm.com
Fri Nov 10 16:56:16 EST 2000


"McDonald, Ira" <imcdonald at 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 at p...]
> Sent: Wednesday, November 08, 2000 2:20 PM
> To: 'ipp at p...'
> Subject: RE: IPP> DRV - Client Print Support Files
> Internet-Draftdown-load ed
>
>
> > From: Manros, Carl-Uno B [mailto:cmanros at 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




More information about the Ipp mailing list