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

From: "Turner, Randy" <[email-masked]>
Date: Wed, 11 Feb 1998 08:22:39 -0800

I'm wondering if a new mapping document for IPP directly over TCP/IP (no
HTTP) would be one way to attack this lighter weight host-to-device
printing protocol?

I think our model document stands as a way to do printing, over
internets and intranets. We have taken a lot of strides to make sure
that the model document was transport-independent.

What I would like to avoid is producing yet another printing protocol
(YAPP).

Considering that the number of mandatory stuff in IPP is pretty light,
it seems like taking this minimal IPP capability and using just TCP/IP
as a transport would be a good first strike against this
"host-to-device" protocol.

Also, concerning the notification problem, my earlier proposal (using
lightweight, acknowledged datagrams) would be
mapping-document-independent and would be "the" way to do notifications
regardless of mapping document. Of course this assumes that all
potential mapping documents would share a common TCP/IP transport
somewhere in their design.

Just my $0.02

Randy

	-----Original Message-----
	From:	Jay Martin [SMTP:[email-masked]]
	Sent:	Wednesday, February 11, 1998 8:01 AM
	To:	Turner, Randy
	Cc:	[email-masked]'
	Subject:	Re: IPP> Does the world need a robust
host-to-device network printing protocol?

	Randy,

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

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

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

---

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

Randy,

> HTTP) would be one way to attack this lighter weight host-to-device

Sure, we could try to do this.  Were you thinking of trying your
hand at this, or have someone take a stab?  Personally, I would
have to decline the opportunity, since (as I mentioned before),
IPP is way too closely tied to the contraints of HTTP.

> that the model document was transport-independent.

Some may view IPP as being very transport-independent, but that
doesn't mean it is the *right* kind of protocol for the job.
Again, the power and simplicity of the side-band "data chennel"
(ala FTP) would greatly enhance network printing, IMHO.

Can IPP (as currently defined) support such a data channel?

> What I would like to avoid is producing yet another printing protocol

I certainly understand your concern here.  I, too, wish to
absolutely minimize the number of supported protocols.

However, the avid proponents of IPP steadfastly stated early
on that IPP was for Internet use, and not necessarily for
Intranet use.

Yet, here we are, some 15 months later and some folks (such
as Microsoft) believe this is the Last Great Protocol for
network printing.  And hence, this is why people are now
(finally) coming out of the woodwork on this topic.

> "host-to-device" protocol.

I look forward to seeing such a mapping document, in whatever form.

> somewhere in their design.

We are in sync 100% on this topic, Randy.

I'd just like to note, however, that a real, robust network
printing protocol would provide for such notifications as
part of the protocol itself, and not rely on separate (external)
protocol mechanisms as is required with IPP today.

Incidentally, most folks have long forgotten something about
how and why the SENSE project was started in the first place.

As IEEE 1284.1 (TIPSI) was coming to a close, the issue of scalability
arose with respect to async device/job notifications.  I had
suggested that the group augment the stream-like protocol
with a sort of "side-band-like" UDP service to solve the
scalability problem.

The notion was very warmly received by the TIPSI group,
so much so that the group strongly suggested that this
approach be presented to the PWG for general consideration.

And hence, the birth of SENSE way back in October, 1995.

Now, will the PWG do anything with it?

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