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), 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.
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 process.com]
Sent: Wednesday, November 08, 2000 2:20 PM
To: 'ipp at pwg.org'
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