Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol?

From: "Turner, Randy" <[email-masked]>
Date: Tue, 10 Feb 1998 22:14:17 -0800

I'm curious how this host-to-device protocol for printing would differ
from IPP 1.0?

Randy

	-----Original Message-----
	From:	Jay Martin [SMTP:[email-masked]]
	Sent:	Tuesday, February 10, 1998 2:53 PM
	To:	[email-masked]
	Cc:	Paul Moore; 'Harry Lewis'
	Subject:	IPP> Does the world need a robust host-to-device
network printing protocol?

	Paul Moore wrote in the "Submission vs. Monitoring and
Management"
	thread:

	> Now if somebody wants to have a separate debate about writing
a really
	> robust protocol for interfacing to printers (and I mean the
real hardware
	> not some logical abstraction) then that will suit me fine.
Lets start a new
	> track and call it, say, NLS (Not LPD and SNMP). This is what I
initially
	> wanted to do but could not persuade enough people.

	Paul, what people were you unable to persuade?  Internal
Microsoft
	folks, or PWG folks, or both or what?

	For fear of sounding as if I'm beating a dead horse to death:

	  Enterprise environments desparately need a fully functional
	  host-to-device protocol for network printing.

	Am I alone in this belief???  (I know for a fact I am NOT
along.)

	Will others in the PWG share their views using this new thread?
	If this belief turns out to be a minority view, then I'd
certainly
	like to know (so I can drop the subject once and for all, if
so).

		...jay

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

----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Wed, 11 Feb 1998 11:00:56 -0500

Randy,

> I'm curious how this host-to-device protocol for printing would differ

Excellent question.  Right off the top of my head...

For one thing, such a protocol would be one heck of a lot more
efficient than IPP-over-HTTP.  Anytime you frame bulk data within
a transaction protocol, you lose bigtime in terms of performance.

The CPAP designers learned this many years ago; the implementation
of an FTP-like side-band "data channel" is one of the big features
of CPAP v2.  Also note that IEEE 1284.1 (aka "TIPSI", aka "NPAP")
added similar support for a separate data-only channel near the
end of that protocol's development.

In addition to the significant increase in performance, we found
that implementing such a protocol was a lot easier in terms of
structure and complexity.  Always a nice win, to be sure.

Another way the protocol would differ from IPP is in the area
of async messages during the transaction.  As the client submits
a job, the server can inform the client of any number of events
that occur during the transaction, such as device alerts and
other things the client may (or may not, granted) be interested
in.

Using CPAP as an example of this kind of protocol, CPAP has the
ability for the server to convey to the client that the client's
job was terminated (either via the front panel, or by a remote
management app communicating with the server).  Furthermore,
the "job kill" message to the client can include exactly WHO
killed the job, thereby allowing the client to provide an
excellent level of detail to the job submitter as to why the
job failed.

There's more I can say here, but this is at least a start.
I anxiously await comments from others, particularly from you,
Randy!  I'd really like to get this kind of thread rolling.

	...jay

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