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

From: Don Wright <[email-masked]>
Date: 29 Jan 97 10:36:00 EST

>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.

My major goal is that all setup, configuration, status query, etc. can be
done from a browser with the assistance of plug-ins, CGI code, HTTP
re-directors, etc.  When time comes to print from my application, the
browser is completely out of the picture (unless of course the browser
is the application.) 

 As I said before, creating a new TCP stream starting with a blank 
sheet of paper will take a standards group 2 years to finish. If the 
group is constrained to use what already exists with perhaps minor
additions, the task stands a good chance of getting done much, much
sooner.  From my experience, never, never, never give a standards
body a blank sheet of paper.  It will be filled with doodles, not a standard
for years.

Don

---

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

> browser is completely out of the picture (unless of course the browser

Fair enough.  I still don't see why this mandates HTTP. For example,
web browsers are probably the single most used FTP client these days.

> body a blank sheet of paper.  It will be filled with doodles, not a standard

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.

--
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: Randy Turner <[email-masked]>
Date: Wed, 29 Jan 1997 10:02:06 -0800

To summarize alot of the debate about the use of HTTP for an 
IPP transport, my overall opinion is that if the only real
rationale we have for using it is to more easily slip through
firewalls, then I would be dead set against using it because
technically that argument won't hold water, given that we also
have to make some compromises for using HTTP.

However, if there are real compelling reasons that relate to
interoperability or the fact that we can leverage some part of
the HTTP-based WEB for some real functional advantage over 
"rolling our own", then I'm all for it. Actually, for purposes
of getting something done in a timely fashion, I think designing
IPP is the hard part; the selection of a transport would have no
real impact on the timeliness of getting the work done.

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

---

From: Larry Masinter <[email-masked]>
Date: Wed, 29 Jan 1997 22:02:01 PST

Let's suppose we have a more constrained notion of a "form" than "HTML
form". A form is a set of parameter names and constraints on parameter
types, with some default values filled in for some of the parameters.
Forms also have an "Action" (where does the form get sent) and maybe a
"Method" (how does the form get sent.)

Some forms even have 'hidden fields'. Maybe there's a description of
some of the form elements, too. There's a natural conversion from
"form" to "HTML form", and vice versa.

Let's imagine we have lots of kinds of forms, in fact: PDF forms, HTML
forms, and maybe a new kind of form which is a "simple form".

Let's suppose that job setup for printing consists of 
   a) get the form for this virtual printer
      Unless you say otherwise, the form you get is
      a simple form. (forms can be cached, getting
      the form for a virtual printer seems like it fits HTTP).
   b) assume that ONE of the parameters of the form is
      the "file-to-be-printed".

Then "submit print job" consists of "fill out form" and then "submit
form" (send the form data to the address given by the Action).

This actually fits nicely into HTTP-as-it-is. You don't need new kinds
of URLs, and, if you're willing to live with HTML forms (or perhaps a
stylized subset of them), you can both use a custom client and also a
standard browser to do job submission.

There's an operability issue of whether the form is filled out before
the application prints, or at the time the application starts to
print.

Maybe there are two forms, one for "generic setup" and another for
"particular job", and the printer gets to decide how the form data
gets split between them. The "generic setup" form is available from
"Page setup".

To get a good GUI for printing, you might need more form widgets
than are available in HTML, or at least some way of annotating them.

A printer could offer multiple kinds of forms, e.g., one for Java, one
for HTML, and one for simple clients.

Printers with lots of features would have complicated forms. Content
negotiation could allow the growth of custom kinds of forms with
access to printing functionality to a ubiquitous view of how forms get
filled out.

Larry

---

From: JK Martin <[email-masked]>
Date: Thu, 30 Jan 1997 02:40:24 -0500

Larry,

The scenarios and suppositions you've proposed are quite interesting.

> form" (send the form data to the address given by the Action).

If the user is supposed to enter the file (path) of the file (or files)
to be printed, how would you imagine the server would acquire the file
data?

In the case of a URL (ie, the file is accessible via the local server's
Web filesystem "view"), then it would seem obvious that the remote
server can just do a Get on the file.

But what if the file is not within the view of the local server?

Even more difficult, what if the client (local) system is not running
a server?

Perhaps I missed something in your descriptions?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Larry Masinter <[email-masked]>
Date: Thu, 30 Jan 1997 00:36:59 PST

# If the user is supposed to enter the file (path) of the file (or files)
# to be printed, how would you imagine the server would acquire the file
# data?

I'm presuming some analog to the capabilities of RFC 1867 ("Form-based
File Upload in HTML"), plus some special processing:

A to-be-printed form has a distinguished field, "print-file". If it's
a HTML form you'd write it

<INPUT TYPE=file ACCEPT=application/postscript NAME="print-file">

for example.

A smart print client ("IPP driver") would have to know about
"print-file", and OMIT the element that requests print-file, and
instead not actually submit the form until the print-file is ready.

A dumb print client would just submit it using their browser.
(ftp://ftp.parc.xerox.com/pub/masinter/file-upload-impl.txt).