Subject: RE: IPP> MOD optional attributes for more info and driver, inst

From: [email-masked] (Zehler,Peter)
Date: Fri, 28 Feb 1997 09:27:53 PST

All,
Scott responded to the "Example of multiple levels of driver 
 installation service
using IPP and HTTP" section of my mailnote

Scott wrote:
>You suggest "issuing an HTTP Get" on the URI.  This implies that the URI
>may only be an HTTP scheme URI.  What about some other scheme?
>Should we force it to be an HTTP scheme URI?

I took HTTP as an example.  FTP could also be a valid scheme.  I selected
HTTP as an example because its transfer response is immediate. HTTP
has the capability of informing the server of the client environment built in.
I don't think we should force driver installation services to be an HTTP
scheme.  I want to see how the prototypes handle it and evaluate the solutions
at that time.

Scott also question the following section in my mailnote:
PZ> Driver installer obtained from URI in IPP fashion.   Issue an HTTP
PZ> Get to the URI from the  printer-driver-installer attribute to get the
PZ>  appropriate driver.  Included in the Get will be  IPP specific product
PZ> tags.  The Installer will use IPP product tags in the HTTP Get request to
PZ> determine which installer to download to the client.

Scott wrote:
>This implies some sort of tags in HTML?  Do we need to define the new
>tags?  How is this different than the Super Installer from the section
>before?  Isn't the this "IPP fashion" just the super installer?

I am implying that when IPP takes up driver installation one solution would
be to define IPP specific tag(s) to enable the retrieval the correct 
 variant of a
driver installer.  There are other solutions.  In my example I needed IPP
specific tags to convey variant selection criteria unambiguously.
The difference between this case and the superinstaller case is how the
client environment is determined.  The superinstaller executes on the client
machine.  This could be accomplished using Java.  The superinstaller
determines the client environment locally and installs the driver in a platform
specific manner.  In my HTTP Get example the client send its environment
information in the request and the installation service uses the tags to return
the correct variant.

---

From: Randy Turner <[email-masked]>
Date: Fri, 28 Feb 1997 12:06:47 -0800

I wouldn't go any further with standardizing driver installation
than the following paragraph:

"The directory entry for printers will contain one or more URLs
that contain locations for drivers for one or more different
platforms or operating environments".

What protocol you use to obtain the driver will depend upon the
URL "protocol" field (HTTP:, FTP:, etc.). The URL should provide
enough context information for an unambiguous retrieval of the
driver. To talk about "Well, you issue an HTTP GET request..."
I think goes into more detail than we need to specify in order
to obtain an IPP driver for a particular device.

Randy

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]