IPP> MOD optional attributes for more info and driver

IPP> MOD optional attributes for more info and driver

IPP> MOD optional attributes for more info and driver

Scott A. Isaacson Scott_Isaacson at novell.com
Thu Feb 27 14:35:48 EST 1997


I agree with most of your comments. Thanks for trying to take some
vague, handwaving, out of scope issues and creating a simple
compromising proposal.  I still have some questions though:


>>> Zehler,Peter <Peter_Zehler at wb.xerox.com> 02/26/97 09:16am >>>
> Driver installer obtained from URI in non-IPP fashion. Issue an 
> HTTP Get to the URI from the  printer-driver-installer attribute to 
> get the appropriate driver.  The Installer provider can provide service in
> an implementation specific fashion.  It may just default to some specific
> installer(eg NT 5.0).  A super-Installer could be downloaded.  This
> would be responsible for obtaining the parameters required to 
> install the
> appropriate driver in the client environment.  The third way a
> provider may download the appropriate driver Installer is to look at 
>  the product tokens in the HTTP Get request.  The tokens
> and their formats are not standard and vary from browser to browser.


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?




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


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?


Scott



More information about the Ipp mailing list