Subject: IPP> Automated IPP printer installation

From: "Zehler, Peter " <[email-masked]>
Date: Fri, 13 Feb 1998 07:20:04 PST

ALL,
One of the requirements for IPP was "All necessary decompressing,
unpacking, and other installation actions should occur without end-user
interaction or intervention excepting initial approval by the end-user."
I hope the time has come to start discussing this feature of IPP.  I
have created a new directory on the IPP site called "new_INST".  In the
directory I have placed a write up of this IPP extension.  The write up
is ID style. The url  for it is
"ftp://www.pwg.org/pub/pwg/ipp/new_INST/ ipp-printer-install-980213.pdf"
Below is the quick "manager" level explanation.  This is just  a
straw-man proposal to open discussions.  Comments are welcome and
encouraged.
Automated printer installation is intended accommodate multiple client
platforms, multiple drivers per printer and internationalization.
Automated IPP printer installation takes advantage of a printer
attribute that is a URL to a driver installer.  I have changed the
semantics slightly of this optional attribute to be a link to an IPP
Installer object.
Installer objects contain installer components.  Installer components
are executable images.   They automate the installation of a printer
driver, creation of a print queue or spooler, and any the installation
or configuration of associated system components specific to a client
OS.  The installer components are provided by the printer manufacturer
for target operating systems. The installer components could also be
made available through an embedded web server or corporate homepage.  
The Installer object can be anywhere.  It is a URI which can be
preconfigured in printers to point back to a Manufacturer supported IPP
Installer object or refer to the printer itself.  A Manufacturer
supported IPP Installer objects would contain installer components for
all their printers.  An embedded IPP Installer object would contain only
the installer components for that printer.

How it works.
1)	User obtains IPP Printer URL.(word of mouth, search engine,
LDAP, webpage link).
2)	IPP protocol is native to client environment(future) or
explicitly installed(providing "add printer" functionality where non
exists).
3)	End user begins client OS specific "add printer" feature
entering in the URL of the target printer.
4)	Client software sends IPP request to the printer object to
retrieve the URL of the installer object and printer
identification(supported PDL can also be retrieved).
5)	Client software sends query request to Installer object
providing printer identification.
6)	Installer object returns the supported client OSs, languages,
character sets, PDLs and the default PDL for that printer. The installer
object also returns the date/time for the installer.(installer
components are versioned, not individual subcomponents (i.e.drivers))
7)	Client software selects appropriate client OS, language, and
character set(PDL can be specified or defaulted).
8)	Client software send a request to retrieve installer component
specifying printer identification as well as above information.
9)	Installer object responds by downloading installer component.
10)	Installer component is temporarily stored.(date/time stamp
should be held for later comparison to detect new installer component)
11)	Installer component is executed.  This installs the printer in
the client environment.
12)	End user prints from application
Note: IPP client environment can take advantage of information provided
in #9 to automatically(or explicitly) update client.
Note: TLS authentication can be used providing mutual authentication to
insure installer component is legitimate.

Pete

Email: [email-masked]
US Mail: Peter Zehler
	Xerox Corp.
	800 Phillips Rd.
	M/S 111-02J
	Webster NY, 14580-9701
Voice:   (716) 265-8755
FAX:     (716)265-8792