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 at 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: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------