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

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 12 Feb 1998 16:38:03 -0800

I agree with Carl-Uno that we did what we said we were going  to do. And
I, for one, am optimistic about what we have done for both intranets and
internets. We have a model and framework for printing, and outside of
more advanced job management and async notifications (which we clearly
knew from the get-go we wouldn't do for 1.0), we've got a very good
printing solution.

Randy

	-----Original Message-----
	From:	Carl-Uno Manros [SMTP:[email-masked]]
	Sent:	Thursday, February 12, 1998 4:04 PM
	To:	[email-masked]
	Subject:	RE: IPP> Does the world need a robust
host-to-device network printing protocol?

	At 03:10 PM 2/12/98 PST, Wagner, William wrote:
	>Considering the depth of feeling about IPP inadequacy, I
suggest that
	>some attempt be made to more clearly identify the perceived
problems...
	>Is it because IPP does not address the published requirements
or because
	>the requirements were inadequate (or changed).
	>
	>It seems, for example, that Mr. Walker feels that IPP is not
adequate
	>for the Internet because too many compromises were made for the
embedded
	>implementation. Mr. Moore, on the other hand, seems to suggest
that IPP
	>may be fine for the internet but is inappropriate for an
intranet.
	>(because too many compromises were made). Jay seems to be just
unhappy
	>with IPP, suggesting perhaps that it is not good for anything
(because
	>to many compromises were made?)
	>
	>The positions  point to at least four different protocols;
Internet
	>client to server; Intranet client to server, server to printer,
and  a
	>client to printer. Is this what is necessary? Is it not
possible to come
	>up with a sufficiently extensible protocol to handle all of
these?
	>
	>W. A. Wagner (Bill Wagner)
	>OSICOM/DPI
	>

	I want to remind you all that we stated as our intent when we
started
	work on IPP V1.0, that we were trying to solve 80% of the
problem in
	the first version, which means that we conciously left out a
number of
	things to be resolved later.

	We also stated that we were trying to concentrate on solving the
user
	to what-ever problem in our first version, leaving some of the
device
	and management type problems for a future version.

	Also remember, that some of the intial reactions in the IETF was
that 
	we were trying to do far too MUCH in IPP V1.0, while now we seem
to be
	hearing that there is too much missing. 
	You cannot have your cake and eat it.....

	I do not buy the argument that HTTP is bad, even if you choose
to
	use IPP to acces your print device. I think there is enough
evidence
	from prototyping at that stage to show that it works pretty
well.
	Some printer vendors started putting in HTTP in their printers
to
	do configuration and management even before we started talking
about
	using it for IPP.

	I would hope that the current IPP approach can be used as a
common 
	basis for developing both client to print server and print
server to
	device communication, even though I agree that IPP V1.0 was
developed 
	to primarily support the former. If this results in an
additional 
	protocol optimized for print server to device, so be it. I
expect that 
	any printer that is aimed for shared use on the network would
want to 
	include the IPP server functionality anyway, so that leaves the
	discussion about how big a share of remaining printers would
really 
	need an additional simpler protocol that is optimized for the
device.

	My 2 cents...

	Carl-Uno

	Carl-Uno Manros
	Principal Engineer - Advanced Printing Standards - Xerox
Corporation
	701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
	Phone +1-310-333 8273, Fax +1-310-333 5514
	Email: [email-masked]

---

From: "Wagner, William" <[email-masked]>
Date: Fri, 13 Feb 1998 14:59:32 -0500

I appreciate Carl-Uno's statement. (I also happen to agree) . Much of
the traffic on the list of late has been negative to the extent that
many observers who have not actively participated  get the impression
that IPP is beyond recovery. I know that people are more inclined to
voice objections than support, but I think that some more supporting
comments  (rather than just defensive responses) might put the actual
situation in better perspective.

> Sent:	Thursday, February 12, 1998 7:04 PM
> To:	[email-masked]
> Subject:	RE: IPP> Does the world need a robust host-to-device
> network printing protocol?
> 
> 
> I want to remind you all that we stated as our intent when we started
> work on IPP V1.0, that we were trying to solve 80% of the problem in
> the first version, which means that we conciously left out a number of
> We also stated that we were trying to concentrate on solving the user
> to what-ever problem in our first version, leaving some of the device
> Also remember, that some of the intial reactions in the IETF was that 
> we were trying to do far too MUCH in IPP V1.0, while now we seem to be
> I do not buy the argument that HTTP is bad, even if you choose to
> use IPP to acces your print device. I think there is enough evidence
> from prototyping at that stage to show that it works pretty well.
> Some printer vendors started putting in HTTP in their printers to
> do configuration and management even before we started talking about
> using it for IPP.
> 
> I would hope that the current IPP approach can be used as a common 
> basis for developing both client to print server and print server to
> device communication, even though I agree that IPP V1.0 was developed 
> to primarily support the former. If this results in an additional 
> protocol optimized for print server to device, so be it. I expect that
> 
> any printer that is aimed for shared use on the network would want to 
> discussion about how big a share of remaining printers would really 
> need an additional simpler protocol that is optimized for the device.
> 
> My 2 cents...
> 
> Carl-Uno
> 
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation

---

From: "Wagner, William" <[email-masked]>
Date: Fri, 13 Feb 1998 15:53:25 -0500

Jay,

Thanks for the clarification. And I haven't missed your expressed
concerns, which is where I sensed somewhat negative vibes v-v IPP. 

> From:	Jay Martin [SMTP:[email-masked]]
> Sent:	Friday, February 13, 1998 3:43 PM
> To:	Wagner, William
> Cc:	[email-masked]
> Subject:	Re: IPP> Does the world need a robust host-to-device
> network prin ting protocol?
> 
> Bill,
> 
> > Jay seems to be just unhappy
> Aw now, c'mon.  I have pointed out several specific concerns I
> have with IPP--in the role of a host-to-device protocol--on this
> DL.  Perhaps you've missed them?
> 
> I think a lot off pro-IPP folks are perhaps missing the point,
> at least with regard to my concerns, and probably Paul Moore's
> concerns.
> 
> Paul has repeatedly pointed out the problem of asymmetry of
> IPP-over-HTTP in the context of host-to-device support.  This
> is a big concern for me, also (both of us being "driver"
> developers that need a good "host-to-device" protocol).
> 
> The lack of symmetry in the protocol makes life unnecessarily
> difficult to develop robust, highly functional drivers.  For
> example, during the job submission transaction with the printer,
> the driver needs to be able to asynchronously receive events
> from the printer that may cause a change in the transaction,
> or at least cause the driver to "pass along" information to
> the originator in a timely and reasonable simple manner (eg,
> "Paper out", "PDL error", etc.)
> 
> IPP as currently defined (over HTTP) does not provide this
> kind of protocol interaction...at least not very easily.
> Or more specifically, not as easy as it should be when
> compared to similar protocols in the Internet.
> 
> Hopefully Paul Moore will comment a bit about this,
> but at least this describes one of my concerns about IPP.
> Please don't say "Jay doesn't think IPP is good for anything".
> 
> 	...jay
>