Subject: IPP> PRO,MOD> User model for clients

From: Randy Turner <[email-masked]>
Date: Tue, 28 Jan 1997 09:50:14 -0800

I was wondering if anyone has modeled the user interface side of
browser-based printing using IPP. One of the fundamental reasons
we are thinking about HTTP is the existing installed base of
browsers. I think we have accepted the fact that we will require
additional capability on HTTP servers that also host IPP print
services; however, since there are far more client browsers than
HTTP servers, this wasn't a bad trade-off, so really what we are
doing is leveraging the installed base of browsers on the net.

The protocol/white paper that Roger published talked about using
the HTTP "POST" method for job submission, and I think that is 
what most of us assumed would be used for IPP. The existing 
installed base of browsers have designed their printing subsystems
to be platform-independent (i.e, under Sunos/Solaris they default
to lpr/lp, and under Win95/NT, they use the windows print system).

When the user is looking at a particular page (any page from any
content hierarchy) and wants to print a particular page, he/she
will be very tempted (using the currently installed base of
browsers) to print the way they are used to printing pages, via
a "Print" windows control or from the "File" pull-down menu. If 
we are using the "POST" method, and utilizing some form of 
multipart FORM "POST" through IPP, how do we enable this for any
page the user might be viewing? If I'm looking at a copy of the
online Wall Street Journal and want to print information about
a particular companies earnings report on a remote IPP printer,
using the built-in "Print" facility within the browser will not
work, unless the user has previously installed some type of 
Windows networked IPP redirector in the system, but I don't think
we can require this, at least in the prioritized set of things we
want to do, the driver loading has been moved down the list. And
this would not be a cross-platform, open way of handling this.

Maybe I'm missing something very simple, but we are modeling this
type of usage model and I'm having some concerns about not being
able to "tailor" the client environment for IPP printing, which
would all but eliminate alot of the rationale for using HTTP.

Let me know if I've completely forgotten something that we've 
already worked on, I have missed a couple of teleconferences.

Randy

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

---

From: Babak Jahromi <[email-masked]>
Date: Tue, 28 Jan 1997 10:32:29 -0800

The issue you are raising is a valid one. The problem is not just
printing from the borwser. What it you want to print an Excel spread
sheet to your favorite IPP printer? Even though IPP printing can be
centered around the browsers, we still need to let other apps print as
well. Which implies that the IPP printing capability has to be
implemented as an OS extension, which all apps, including the browsers,
can take advantage of. Since we cannot expect the appsto be modified,
the OS would have to encapulate the knowledge.

Babak

>-----Original Message-----
>From:	Randy Turner [SMTP:[email-masked]]
>Sent:	Tuesday, January 28, 1997 9:50 AM
>To:	[email-masked]
>Subject:	IPP> PRO,MOD> User model for clients
>

---

From: Don Wright <[email-masked]>
Date: 29 Jan 97 7:56:47 EST

> > 1) Browsing for printer status, queue status, etc. requires
> >      nothing additional on the client.

>I believe this to be incorrect. If I recall the protocol specification
>correctly, you planned on using POST for everything. I would be
>curious to find out how the client will create the IPP command
>string that is sent in the POST.

Here you are clearly wrong.  Lexmark's MarkVision for
the WEB is able to provide printer and printer Queue status
on unmodified, unassisted browsers today.  If our scenarios
and models do not support this mode of operation then a
grave design error has been made.

> > 2) Printing to a remote printer from an application on the
> >      client (eg Word, Lotus 123, etc.) requires something
> >      I'll call an IPP driver to be installed on the client.  Perhaps

>Exactly! And that was my counterargument against the "we can use
>standard Web servers and browsers." You simply cannot.

Again, you are flat wrong in assuming that adding a redirector means
I can't use the existing browser.  Once I have users accustomed to an 
interface i.e. a browser, then adding a plug-in or a new redirector 
(replacing or supplementing their IPX/SPX, NetBEUI, etc. redirector) 
why not stick with it?

Call me a fool, but I have no interest in inventing a new TCP stream
and requiring firewall makers to open up that stream for clients
inside a firewall.  While "public" printers will need to be outside
the firewall for this HTTP mapping to work.  Clients can be anywhere.

Don

---

From: Don Wright <[email-masked]>
Date: 29 Jan 97 8:03:11 EST

JK Martin said:

>Perhaps an intermediate mail transfer agent ate up Don's smiley
>faces on this response.  ;-)  Seriously, the printer vendors I
>have spoken with consistently bemoan the continued give-away of
>such printer drivers.

Insuring there are appropriate printer drivers for a printer is part
of delivering the printer.  Making sure the unique attributes of the
printer are available from the driver enable the printer manufacturer
to differentiate its product from another's.  Writing drivers is a fact
of life for a printer manufacturer.  We all know this and accept it.
Therefore we give our drivers away and as far as I know that will
not change in the near future.

Don

---

From: Alex Bochannek <[email-masked]>
Date: Wed, 29 Jan 97 07:22:06 PST

Don,

> grave design error has been made.

I hate to tell you Don, but with IPP, the way it is specified right
now, you DO need some assistant to your Web browser to query
status. How else would your client create the POST?

> (replacing or supplementing their IPX/SPX, NetBEUI, etc. redirector) 

OK, I think I finally figured out were our disconnect is. When you say
"standard browser" you are talking about a UI paradigm while I assume
you mean a standard HTTP client. Rememeber I proposed a while back
that the TCP mapping could use a URL scheme of "ipp://..."? Well,
there you go, you keep your UI paradigm, and I keep the transport
mapping.

> the firewall for this HTTP mapping to work.  Clients can be anywhere.

Call me a fool (one that has to maintain a firewall), but I would be
more than happy if I can filter print requests by port number.

--
Alex Bochannek                 Phone & Fax : +1 408 526 51 91
Senior Network Analyst         Pager       : +1 408 485 90 92
Engineering Services           Alpha Pager : (800) 225-0256 PIN 104536
Cisco Systems, Inc.            Email       : [email-masked]
170 West Tasman Drive, Bldg. E Pager Email : [email-masked]
San Jose, CA 95134-1706, USA

---

From: [email-masked] (Bill Wagner)
Date: Wed, 29 Jan 1997 11:23:20 -0500

These interchanges show confusion in semantics and word-games that are 
     misdirecting attention from the main objective.
     
     1. Browsing for status using a standard IP browser is done now, by DPI 
     (http server in the NIC) as well as Lexmark and others. If the spec 
     says that "all" interaction is done via POST, I think that is an error 
     in the spec; that is neither reasonable nor workable. 
     
     For general access, it does require that the printer be outside of the 
     firewall. DPI's is accessible with a URL derived from the IP address 
     (http://199.93.124.110/)
     
     2.  Printing is a different question. It seems particularly cumbersome 
     to use a browser to submit print jobs (print to file using the 
     appropriate driver, and then transfer the file using the browser??) 
     Except for some  special cases where the print file is already 
     available, this mechanism seems unreasonable. Users will expect job 
     delivery to be seamlessly linked to their application (Indeed they may 
     also expect printer selection to be done automatically.) I don't think 
     that there is any argument but that this requires a redirector either 
     built in or loaded.
     
     I would expect that this redirector could be obtained directly or 
     indirectly from the printer accessed for status/configuration 
     information by a standard browser.
     
     I think there is agreement on these points.
     
     Then, the question might be, once you have loaded a redirector, why 
     continue to use HTTP for job delivery? Why not FTP, or some new custom 
     built layer? The primary argument for HTTP appears to be to evade the 
     firewalls. But I suspect that:
        a. the vast majority of printing is done locally, so getting past 
     firewalls is inapplicable for most print jobs
        b. if there is some perceived reason to keep print jobs from going 
     out, then the use of HTTP will not prevent firewalls from being 
     enhanced to fill this loophole
        c. even stating this as an objective is regarded as a challenge to 
     the keepers of the firewalls
     
     Is there some other compelling functional reason to use HTTP for job 
     delivery? 
     
     Bill Wagner, DPI

______________________________ Reply Separator _________________________________
Subject: Re: IPP> PRO,MOD> User model for clients
Author:  Don Wright <[email-masked]> at Internet
Date:    1/29/97 7:56 AM

Don

---

From: Babak Jahromi <[email-masked]>
Date: Wed, 29 Jan 1997 10:57:40 -0800

>
>OK, so what you are saying then is:
>
> - A specialized print client is required on the client side
> - A specialized print server is required on the server side
>
>And why do you think again that using HTTP is such a great idea?
>
>Because you are playing with words again. As I said before, this thing we
>call a "driver" is far easier to write when you have all the underlying
>functionailty available on your stock Internet-capable PC software. Ditto for
>the server.
>
>Come on people, it should be totally obvious by now that the
>modifications necessary to "stock" software is just as much, if not
>more than writing the driver to use a socket directly PLUS you have to
>consider all the possible corner cases of what happens with special
>HTTP handling (like caches) and new versions of HTTP.
>
>Not obvious at all! I know becasue I am writing one! Caching and new versins
>of HTTP are all taken care of by the lower level APIs we use.
>
>I am not sure why Babak keeps arguing that implementing to a socket
>API is so much harder than some other, higher level API. If that's the
>case for the particular platform he is concerned about, then one must
>wonder about the platform he is using. Without diving into the "NT
>print servers are going to take over the World"-discussion, I do want
>to point out that at least one developer of printer drivers (Hi
>Angelo!)  is perfectly happy to write to the socket layer since the
>much touted development tools simply are not available in that case.
>
>The platform I am writing to provides both sockets interface, and a much
>higher level, more abstract, more friendly interface on top of HTTP (among
>others). Which one do you think I ended up using? :-)
>

---

From: [email-masked]
Date: Wed, 29 Jan 1997 14:12:06 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-772-2479

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/29/97 11:23
AM ---------------------------
Bill Wagner wrote:

RKD> If we decide to use HTTP, than I believe that the only
RKD> reasonable and workable solution for IPP protocol operations
RKD> is to use POST. You may have existing schemes to browse
RKD> for status, but that's outside of IPP.

Printing is a different question. It seems particularly cumbersome
to use a browser to submit print jobs (print to file using the
appropriate driver, and then transfer the file using the browser??)

RKD> I would hope there is no argument on this!

Then, the question might be, once you have loaded a redirector, why
continue to use HTTP for job delivery?

RKD> One might also ask "Why not!

---

From: [email-masked]
Date: Wed, 29 Jan 1997 14:19:10 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/29/97 12:14
PM ---------------------------
Alex Bochannek wrote:

Also fair, but you overlook one important aspect: You already have
designed a brand new protocol on a clean sheet of paper! It's called
IPP. All we are arguing about is that you think it should be
transported in another application protocol while I say you should use
a transport protocol with more than 15 years of use behind it. Not
only your favorite, HTTP, uses it, but also a whole range of
others. Look at RFC821, dated August 1982. It describes the mapping of
SMTP onto the TCP transport in about one dozen lines of text. And it
is still working today.

RKD> I have updated the protocol paper to show both an HTTP
RKD> mapping and one using TCP sockets, per Alex's suggestion
RKD> of a few days ago.  I hope this allows us to carry on
RKD> a reasonable debate on the guts of the the IPP protocol
RKD> without getting bogged down on the transport. In the
RKD> meantime we seem to be running our prototype very nicely
RKD> on HTTP. I'd like to see more implementation experience
RKD> before we cast the transport mapping in concrete.

RKD> I'll post the updated version tomorrow after some
RKD> internal review on clarity and readability.

---

From: [email-masked]
Date: Wed, 29 Jan 1997 14:33:00 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

Don Wright wrote:

RKD> Don, I'm not sure what you mean here. Clearly one can
RKD> continue to use existing browsers as you have in
RKD> MarkVision for the web. However, you can't, in my mind,
RKD> mix the two.  For example, the following seems to be
RKD> difficult, if not impossible:

Client                                    Printer

 --------------------------------------------->
   get printer capabilities (IPP request)

 <--------------------------------------------
   capabilities (html ala MarkVision)

 --------------------------------------------->
   print request, using capabilities (IPP)

---

From: [email-masked] (Bill Wagner)
Date: Wed, 29 Jan 1997 16:45:36 -0500

Roger, I am obviously missing your points. Understanding that the use 
     of HTTP for IPP is under consideration and is not yet 'cast in stone'
     
     1. Could you be more explicit on why Post must be used for status 
     query, considering that this does appear to make impossible the use of 
     unmodified, un-embellished browsers and the function can be performed 
     quite well with existing browsers?
     
     2. I think there has been much discussion on why HTTP may not be ideal 
     for job delivery. I am sure you did not mean to be flippant in saying 
     'why not', but I think a more positive reason might be helpful to 
     understanding.
     
     3. It was my understanding that HTTP was transaction based, and 
     therefore the scenario outlined below, if HTTP were the transport,  
     would require two connections. There would also, presumably, be a 
     response to delivery of the job. If therefore, the query for 
     capabilities and job delivery are different connections, why the 
     constraints on the HTTP used for capabilities query? Indeed, there 
     appears to be no need to require that the same transport be used.
     
     Bill Wagner, DPI

______________________________ Reply Separator _________________________________
Subject: Re: IPP> PRO,MOD> User model for clients
Author:  [email-masked] at Internet
Date:    1/29/97 2:33 PM

Classification:
Prologue:
Epilogue: Roger K deBry

Don Wright wrote:

Client                                    Printer

---

From: [email-masked]
Date: Wed, 29 Jan 1997 17:49:00 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

Bill Wagner Wrote:

RKD> It does not have to be used for status query. My point is that
RKD> if you generate html in the printer to report status, you are
RKD> are not using IPP - - you are using something else.

RKD> We have prototyped a lot of the IPP function using http.
RKD> Since it seems to work well, I don't know why it should
RKD> be an option.

RKD> The reason I don't think the flow doesn't work is that the
RKD> HTML is meant to be human readable, not parsable
RKD> programmatically.  Therefore the client cannot use
RKD> the information that comes back on subsequent
RKD tranactions.

---

From: [email-masked] (Robert Herriot)
Date: Thu, 30 Jan 1997 18:01:59 -0800

Roger, 

What did you mean by your comment below? HTML certainly is parseable
programmatically for displaying. Web browsers do it all the time.

Is there something more that you expect the client to do with HTML?

Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Thu, 30 Jan 1997 18:10:01 -0800

Roger,

With your example below, I would expect that the html response could
be a collection of attribute values to display -- the supported values
and each default.  The user can then make changes and when the user
clicks the submit button, the client returns a list of values, one for each
field, i.e. attribute.

In the general sense, HTML forms are just another language for describing
a GUI. Any program, including a Web Browser can display an HTML form.

If the program displaying the HTML is something other than a Web Browser,
then users will probably view it as a dialog box and not realize that
HTML is underneath. HTML needs a few more features before it can describe
all the GUI features we might want, but I expect that will happen in time.

So, I think that HTML is quite adequate to handle your job submission
scenario below.

Bob Herriot