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

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

Randy,

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

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.

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

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

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.

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

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

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

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