Subject: IPP> What is it we really need?

From: [email-masked] (JK Martin)
Date: Sat, 4 Jan 97 12:33 EST

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

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: Alex Bochannek <[email-masked]>
Date: Sat, 04 Jan 97 19:24:59 PST

> 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