Subject: IPP> What is it we really need?

From: [email-masked]
Date: Mon, 6 Jan 1997 08:48:53 -0500

Classification:
Prologue:
Epilogue:

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 06:32
AM ---------------------------

        ipp-owner @ pwg.org
        01/04/97 10:33 AM

To: ipp @ pwg.org@internet
cc:
Subject: IPP> What is it we really need?

I, too, believe we have gotten a bit lost in the notion of "Internet
Printing" and all that it entails.

IMHO, this problem has been somwehat exacerbated by the trend to put
HTTP servers inside network printers.  Hence, the tendancy to say
"Let's do everything on top of HTTP", which naturally leads to
exploring the use of HTML and MIME as data encoding techniques, etc.

Can we use HTTP/HTML/MIME to effect network printing within "Internet"
(and intranet) environments?  Sure.  But should we?

What is it that we really need?

First and foremost, we need a solid, extensible host-to-printer network
printing protocol that provides:

  - Job submission
  - Job status
  - Job control
  - Basic security capabilities

And just for good measure, let's toss in some REAL criteria that
is seldom discussed in these circles:

  - It must be SIMPLE, both in concept and design

  - A typical reference implementation should be EASY to develop

  - The design should strive to optimize network performance...but
    not so as to preclude simplicity and ease of implementation

And last, but certainly not least:

  - The implementations must be ubiquitous

This implies that either some level of "buy in" from platform vendors
must exist, OR the design must be clearly integratable into the
existing platform printing systems...assuming the platform vendor
doesn't make the printing system a moving target (a clear concern
for some platforms, indeed).

<<RKD>> Jay, I think that you are right here -- the key to success
<<RKD>> will be buy-in from the platform vendors. From the mail
<<RKD>> that I've seen, I think I have a pretty clear notion of
<<RKD>> where Microsoft stands!  I am going to poll our OS
<<RKD>> communities and see if I can get a sense of where they
<<RKD>> woudl lean on this issue.  I'd like to see Bob Herriot
<<RKD>> do the same for Sun and Scott do the same for Novell,
<<RKD>> since they both represent platforms. I guess the question
<<RKD>> is, if there is a general consensus from the platform
<<RKD>> communities, are we willing to go along with it?

All of this is possible.  (And has been for quite some number of
years now.)  And it can be done quickly and relatively painlessly.

A network printing protocol design around the above criteria should
not in any way preclude the concepts of:

  - Printing URL references (ie, server-fetch, etc.)
  - Punching thru firewalls ;-)
  - Supporting multiple data formats in a single job
  - Automatic, transparent configuration of drivers

All of these things should be built on top of the network printing
protocol, and not be a part of that protocol.  (At least that's
what I thought folks have stated over the last few days.)

For those not present at the IETF BOF in San Jose last month,
it should be noted that there was *significant* concern that
the PWG was not addressing the potential for extending/standardizing
the LPD protocol (RFC 1179), nor addressing the basic need for a
simple network printing protocol.  Furthermore, a highly vocal
group (some of which were seasoned IETF veterans) spoke quite
negatively about the idea of basing printing upon HTTP/etc.

And I believe this is exactly what Alex Bochannek (Cisco) has
been talking about in his postings to the IPP mailing list.

Let's focus on a simple network printing protocol based on
the IP protocol suite.  Then, let's address the larger domain
of "Internet Printing"...whatever that may mean.

Sorry for the diatribe.  Just my $0.02 thrown into this sea
of enigma.

 ...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: [email-masked] (Caruso,Angelo)
Date: Mon, 6 Jan 1997 07:39:01 PST

Since I'm a real (printer) implementor I guess it's time I chimed in. I 
 believe there are many among us who are currently involved in web 
 based application development. As such, we are predisposed to think 
 that developing on top of HTTP is the way to go since we are currently 
 more comfortable with it. However, so called "low level sockets 
 programming" is not as bad as it is being made out to be. There are 
 well defined APIs for TCP level programming on EVERY major OS (what do 
 you think web browsers/servers use anyway?). Furthermore, having 
 recently implemented an embedded web server, I can tell you that there 
 is no such thing as CGI or ASAPI for low end embedded systems. For 
 these systems (and I mean real printers here) it's all C code and 
 there is no advantage to building on HTTP rather than TCP.

Angelo Caruso
Xerox Corp.

----------
From: [email-masked]
To: "[email-masked]"@??.ibm.com
Cc: [email-masked]; "[email-masked]"@??.ibm.com
Subject: Re: IPP> What is it we really need?
Date: Monday, January 06, 1997 6:16AM

Classification:
Prologue:
Epilogue:

Alex, in order to get a better handle on this issue, I'd appreciate some input
from
you that speaks to the implementation issues here.   I think that Babek makes
some
compelling arguments in his responses to your note when he says that (my
paraphrasing)

1) He's rather use CGI and ASAPI tools than low-level sockets programming

2) Basing IPP on HTTP (at least on Microsoft platforms) lets programmers take
advantage of many existing APIs and systems services, e.g. security.

As someone who represents a developer of network dexices, can you illuminate
the rest of us on
the pros and cons of an HTTP based protocol -- from an IMPLEMENTOR'S point of
view?
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 06:45
AM ---------------------------

        ipp-owner @ pwg.org
        01/04/97 08:25 PM

To: jkm @ underscore.com@internet
cc: ipp @ pwg.org@internet
Subject: Re: IPP> What is it we really need?

> of "Internet Printing"...whatever that may mean.

Jay,

I am very glad to see you summarizing the current situation like you
did. I certainly feel supported by you and Harald that a straight TCP
client-server model would be a better approach.

One comment I would like to make about people chanting the "Stock HTTP
Server" mantra:

"The Common Gateway Interface, or CGI, is a standard for external
gateway programs to interface with information servers such as HTTP
servers."

This is the definition to be found on the NCSA Web pages. And from all
the implementation suggestions, it sure sounds like HTTP is only going
to be used for hand-through to the "external gateway program". Not
much benefit in using the "Stock HTTP Server".

Babak from Microsoft has pretty much made the same point in his mail
from a couple of days ago.

--
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] (JK Martin)
Date: Mon, 6 Jan 97 12:34 EST

Angelo,

Outstanding comments, indeed.  As a real (protocol) implementor, I think
some folks may be sweeping a LOT of implementation realities under the
carpet in trying to leverage HTTP support.

	...jay

---

From: [email-masked]
Date: Mon, 6 Jan 1997 13:52:05 -0500

Classification:
Prologue:
Epilogue:

        ipp-owner @ pwg.org
        01/04/97 08:25 PM

Jay,

---

From: [email-masked]
Date: Mon, 6 Jan 1997 13:56:29 -0500

Classification:
Prologue:
Epilogue:

Thanks Angelo, it is good to get input from real developers.   However, given
your observation, I still don't know which side of the argument (use http vs.
develop a brand-new protocol) you would come down on.

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 10:54
AM ---------------------------

        ipp-owner @ pwg.org
        01/06/97 10:35 AM

To: Angelo_Caruso @ wb.xerox.com@internet
cc: ipp @ pwg.org@internet
Subject: Re: IPP> What is it we really need?

Angelo,

 ...jay

---

From: [email-masked]
Date: Mon, 6 Jan 1997 13:55:30 -0500

Classification:
Prologue:
Epilogue:

Alex,  I am desparately trying to get beyond what seem to me to be emotional
arguments.  I have heard a number of people decry the use of http as an
underlying protcol for intenet printing, but have not yet been able to get to
any substantive reasons why using http is a bad choice.  I may come across as
an HTTP bigot, but the fact of the matter is that the original proposal that we
(IBM) made to the Printer Working Group was to develop a brand new protocol.
It was only after many people suggested that using HTTP would be easier that we
agreed to pursue that direction.

I think that Jay Martin hit on a significant point when he said that the
protocol needed the buy-in of the platform vendors, and that the solution
needed to be ubiquitous.  It is critical that we agree on an approach that will
lead to wide-spread (easy) implementations, will be supported on the dominant
industry computing platforms, and will not create performance or security
problems in existing networks.   I have not heard anything yet that suggests
that defining a new protocol on TCP/IP makes the implemetation easier (Angelo's
comments only say it is no harder -- and once he has written an imbedded
server, why not reuse it as opposed to yet creating something new again?), will
get us support on the dominant platforms quicker, or  solve security or perform
ance problems.

Based on your experience, if you can provide real, concrete arguments for not
using HTTP,  I think that we would all be willing to listen to those arguments.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 11:05
AM ---------------------------

        abochann @ cisco.com
        01/06/97 09:55 AM

To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org@internet
Subject: Re: IPP> What is it we really need?

Well, I think it became quite clear from Angelo's email, that the
largest number of implementors (the folks who write the printer code)
will most likely not have the option of using anything even close to a
"stock HTTP server". They probably have better tools to write code
straight to a socket API than to their own HTTP server
implementation. And I can tell you from very recent experience that
printing directly to a printer, circumventing the intermediate step of
a print server, is not only something that small shops do since at a
certain point, print severs just don't scale anymore.

As far as the argument "existing system services", I am somewhat
concerned that this is oversimplified. One would have to look at this
on a case by case and protocol by protocol basis to see if this is
something that is applicable to IPP.

Lastly, from a router vendor's perspective, it is almost mandatory
that a new service is also implemented on a new port number if you
want to have any chance of filtering, prioritizing, or accounting for
it.

Alex.

> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97
06:45 > AM --------------------------- > >         ipp-owner @ pwg.org >
01/04/97 08:25 PM > > > To: jkm @ underscore.com@internet > cc: ipp @
pwg.org@internet > Subject: Re: IPP> What is it we really need? > > > Let's
focus on a simple network printing protocol based on > > the IP protocol suite.
Then, let's address the larger domain > > of "Internet Printing"...whatever that
may mean. > > Jay, > > I am very glad to see you summarizing the current
situation like you > did. I certainly feel supported by you and Harald that a
straight TCP > client-server model would be a better approach. > > One comment I
would like to make about people chanting the "Stock HTTP > Server" mantra: > >
"The Common Gateway Interface, or CGI, is a standard for external > gateway
programs to interface with information servers such as HTTP > servers." > > This
is the definition to be found on the NCSA Web pages. And from all > the
implementation suggestions, it sure sounds like HTTP is only going > to be used
for hand-through to the "external gateway program". Not > much benefit in using
the "Stock HTTP Server". > > Babak from Microsoft has pretty much made the same
point in his mail > from a couple of days ago. > > -- > 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: Babak Jahromi <[email-masked]>
Date: Mon, 6 Jan 1997 14:09:55 -0800

Couldn't agree more.

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Monday, January 06, 1997 10:49 AM
>To: 	[email-masked]
>Cc: 	[email-masked]
>Randy, can you help us all to understand the "cost" issues?  I for one do not
>know what the cost of implementing HTTP or HTTP-Lite would be.   What I do
>know
>is that there is lots of HTTP server code out there that I can re-use, thus
>substantially shortening my development time.  Furthermore, if a printer
>manufacturer puts HTTP in the printer to support configuration (as Tektronics
>has and others have said they will do) then it will be there anyway, so why
>not
>use it? And, while I agree that we need to be careful about tying printing
>protocols and the web together, I would hate to see us re-inventing (and
>reimplementing) everything that already exists in HTTP  when we need it.
>Finally, I think that the most compelling argument is the one of wanting to
>see
>ubiquitous support across the major industry platforms -- both as clients and
>as print servers.  HTTP  WILL BE supported on all of the interesting clients
>and server platforms!  How do we convince the platform vendors to build
>support
>for a new protocol???
>
>
>11:36
>        01/06/97 11:00 AM
>Please respond to [email-masked]@internet
>
>
>cc: moore @ cs.utk.edu@internet
>Keith Moore wrote:
>> ..snip..snip..
>> If nothing else, printing protocols and the web each need to evolve
>> separately; we need to be very careful about how we tie them together.
>>
>> Keith
>
>
>I think we need to decide whether or not we are doing IPP or WPP
>(Internet Printing Protocol or Web Printing Protocol)
>
>The statement made by Keith (included in this msg above) I think is
>crucial. I haven't thought about the ramifications (and permutations)
>of tying a printing protocol to another N-numbered set of technologies
>like HTTP, LDAP, CGI, and HTML (if we decide to use forms). It looks
>like it might be more than we want to get into, at least from an
>interoperability and maintenance standpoint.
>
>At any rate, we need to think about someone that wants to do
>printing across the internet, but does not want to be burdened with
>the cost of implementing HTTP (or even HTTP-lite).
>
>In this same vein, it would be very difficult to account for IPP
>usage if we "hide" the IPP protocol within a set of HTTP accesses,
>using the HTTP TCP port number, for example. This echoes the
>ideas expressed by Alex earlier, and would also allow net-admins to
>create policies that enable/disable HTTP and/or printing as
>separate applications, something that sounds desirable IMHO.
>
>Randy
>(Good luck sorting this out in New Mexico ;)
>
>--
>Randy Turner
>Network Architect
>Sharp Laboratories of America
>[email-masked]
>
>

---

From: Babak Jahromi <[email-masked]>
Date: Mon, 6 Jan 1997 14:18:52 -0800

All these complicated caching and proxying won't be implemented unless
they work with Netscape Navigator, and Internet Explorer. If you guys
write to the same APIs as these browsers do, you don't have to worry
about these usage models, since they will have to accomodate you, rather
than vice versa.

Babak

>There are also alot of other issues that may come up and bite us when we
>start
>layering on top of HTTP, like caching, proxies, and security models. It
>may end
>up that the usage model of how HTTP is used for the majority of the
>industry
>(Web page browsing) may conflict with how we want to implement printing.
>I heard
>some very complicated usage models come up at the HTTP working group
>meeting in
>San Jose, with regards to caching and proxying. These algorithms and
>configurations
>may conflict with our simple requirements of submitting a print job and
>checking
>status.

---

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Mon, 6 Jan 97 14:15:19 MST

Randy wrote...

>At least for printing, we ARE the platform vendors, so we would supply
>IPP service layers for the platforms we are interested in supporting.

One advantage I see to IPP, whether it's a new Internet protocol, a
HTTP based WEB printing protocol or a re-birth or LPR, is that it must
be STANDARD and integral to all major OS's.

I'm not sure who Randy is referring to... "we are the (printing) platform
vendors". If this refers to a scenario where every printer vendor has
to deliver unique services to the OS in order to gain basic print support,
I don't believe this is what we should be shooting for.

I think IPP should

 1. Raise the level of functionality available within the network

 2. Become a Standard, agreed upon by the industry

 3. Be supported as a reliable component of all major OS's

>We also have most (if not all) of the major commercial computing platform
>vendors as part of the committee, so the people we have to convince would
>basically be ourselves.

I agree, and, while we have a lot of control over 1 and 2 (above) there
is really nothing the PWG can do to force 3 to occur. I think that is
why Roger deBry has asked a rather compelling question...
If we poll Microsoft, Netscape, OS/2, SUN etc. and IF there's a
consensus, is the PWG willing to follow?

I think we got on the HTTP track by wanting to address timeliness
(an item I did not list) and chance for "ubiquitous" support. If we
can maintain these goals and develop ipp//: I'm all for it. On the
other hand, if an HTTP approach is the quickest path to 1, 2 AND 3
(above), I think this is compelling.

Harry Lewis - IBM Printing Systems

---

From: [email-masked] (Caruso,Angelo)
Date: Mon, 6 Jan 1997 14:56:42 PST

Babak,

I agree that a low-end printer can not be expected to provide the level 
 of job queueing and manipulation that a full blown server can provide. 
 But, ultimately one must transfer the job data to the "same old 
 printer box". How then do you propose we get the data to the printer? 
 Are you proposing that IPP be reserved for those customers who are 
 lucky enough to have a spare NT server off of which to run a parallel 
 cable to their printer?

Angelo

----------
From: [email-masked]
To: "[email-masked]'"; "'Alex Bochannek'"
Cc: Babak Jahromi; "[email-masked]'"
Subject: RE: IPP> What is it we really need?
Date: Monday, January 06, 1997 1:57PM

>----------
>From: 	Alex Bochannek[SMTP:[email-masked]]
>

How can the squeezed, embedded server code in a printer box ever be a
match for the kind of service a "print server implemented on a computer"
can provide? We just saw an example of why a print server trapped inside
a printer box can never match a print server inside a computer: The
"printer" guys have to laboriously write ancient C code on top of TCP,
while the "computer" guys have lavish tools and technology, like ISAPI,
ActiveX, Java, Denali, etc. available on their "computer" platform.

If anyone has solved a scaling problems with an NT 4.0 print server and
has got a better performance by removing the server and routing the
clients directly to the same old printer box, please send me the case
study. 

Babak

---

From: Babak Jahromi <[email-masked]>
Date: Mon, 6 Jan 1997 16:13:29 -0800

No, just make the IPP implementation easy enough, so most low end
printers can afford it. This again implies not re-inventing the wheel. I
also see nothing wrong with letting the server be hooked to Internet,
passing the data to the printer via USB, parallel port, Ethernet, etc. I
don't see a dying need for the printer boxes to be hoocked to the
Internet directly.

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Monday, January 06, 1997 2:56 PM
>To: 	[email-masked]

---

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Tue, 7 Jan 97 11:51:41 MST

>I did not say there is no need for stand alone network printers. I said
>there is no dying need for them to be connected to Internet. That does
>not mean they should not be connected to the private corporate networks.
>
>Babak

I thought the whole point was that there is less and less of a
distinction between the internet and the private corporate net!

I think "improving network printing" and "internet printing" are
inseparable due to the way networks are accessed, utilized and
portrayed to the user today.

---

From: [email-masked] (Bill Wagner)
Date: Tue, 7 Jan 1997 16:12:31 -0500

Harry,
     
     I agree with your observation. It is my underdstanding that the 
     internet is not a thing in itself, it is what results from the 
     interconnecting of individual networks. The idea of a printer on the 
     internet versus a printer on a corporate network with internet access 
     is very fuzzy. Perhaps the difference is the firewall. Many companies 
     have printers with IP addresses, but very few have them outside the 
     firewall (DPI does maintain one for remote demo purposes). Indeed, 
     even within a given network, routers may restrict access to certain 
     subnets. So perhaps a major distinction between IP printing  versus 
     the WEB printing is addressing the question of the firewall.
     
     Bill Wagner 

______________________________ Reply Separator _________________________________
Subject: RE: IPP> What is it we really need?
Author:  "Harry Lewis <[email-masked]>" <[email-masked]> at Internet
Date:    1/7/97 11:51 AM