Subject: IPP> NOT - device-to-host events, not end-user events

From: Tom Hastings <[email-masked]>
Date: Wed, 11 Mar 1998 09:32:13 PST

In discussing the host-to-device requirements, we came up with a requirement
that the printer be able to feed back information about whether it was
choked up with data or needed more data for the current job.

So we could have events like:

   Slow down data transfer
   Speed up data transfer

There is an even more important event for a device to send to a host:

    Ready for another job

This event is useful for a number of configurations:

1. Such an event could anticipate the completion of the current job, so that
the devices could overlap jobs.  Printers that completely interpret a
job or document before marking would want to indicate that they are ready 
for the next job much sooner that printers that mark as they interpret.  
Printers with a long output paper path may want to ask for the next job 
while the output paper path is being emptied, so that the printer doesn't 
slow down between jobs.  A host that has a job would then be advised
that this device could accept it now.  If the host did not have a job,
the host could still keep an indication that this device is a candidate
for a job when a new job is submitted to the host.

2. This event is especially useful for the IPP fan-out case of a server/host 
that controls multiple devices represented by a single IPP Printer object.

3. This event is also useful for the simpler case where a device is 
controlled by more than one host and the device wants to indicate that it 
is ready for another job from any of the hosts (or from a particular one, 
if the device is trying to be fair).

I just read the current Notification Requirements and it is focused on
events that end users needs, so the above event are ones that hosts
need, not end-users.  But these events are NOT events that administrators
need.  Usually in the IPP WG, we have been making the distinction between
end-users vs. system operators/adminstrators, not between end-users versus
servers/hosts that are submitting jobs to devices on behalf of end-users.

So are the above events in-scope for our IPP notification effort or
out of scope?  I think the answer depends on whether the IPP WG is going
to tackle the host-to-device requirements for IPP.

Tom

---

From: Jay Martin <[email-masked]>
Date: Wed, 11 Mar 1998 13:42:39 -0500

> So we could have events like:

This doesn't quite sound right.  I mean, flow control should be mandated
by the underlying transport, right?  We certainly don't want to reinvent
such a key aspect of end-to-end communications within IPP.

	...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: Ron Bergman <[email-masked]>
Date: Wed, 11 Mar 1998 11:10:20 -0800 (Pacific Standard Time)

Tom,

I certainly agree with Jay on this subject.  I don't know of any transport
that does not provide some method of flow control.  Certainly TCP provides
an excellent flow control mechanism.

I don't recall this requirement discussed in any of the meetings in
Austin.  Where did this come from?

	Ron Bergman
	Dataproducts Corp.

---

From: James Walker <[email-masked]>
Date: Wed, 11 Mar 1998 16:18:44 -0600

> So we could have events like:

I agree with others comments regarding these events... I think that
is an issue for the underlying transport.

However...

> There is an even more important event for a device to send to a host:

I think that this could/would be a very useful event.  As Tom pointed
out, it is another case of something that is more appropriate for the
host->device protocol than it is for a client application (I know that
I am probably starting to sound like a broken record, but I think that
it is important to point out these differences, as there are some who
believe that there are none).

The one point that I would add about a "ready for job" event is that,
unless we make notifications absolutely reliable (very unlikely), an
application could not rely on just this event to know that a printer
was ready to accept another job.  In that case, we would also want to
model this piece of information as an attribute (or some sort of state
value) for the printer.  That way, if the server application missed the
"ready for job" event, it would still be able to pick up this information
by polling the printer object.

...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: Tom Hastings <[email-masked]>
Date: Wed, 11 Mar 1998 17:20:44 PST

>Austin.  Where did this come from?

Paul Moore suggested this.  It is NOT flow control but rather
advisory to a host that is controlling a large number of devices
at once.  Paul says he has NT systems that control a large number of
devices, like 500, so that knowing which devices the host is getting
ahead and which devices the host is falling behind in getting PDL data 
to the device would be useful.  My understanding of what Paul was saying
was that the host would then increase the priority of the threads that
were getting behind and lower the priority of the threads that were
getting ahead.

Or does TCP/IP have such advisory events (as opposed to stop sending
and start sending)?

Tom

---

From: Jay Martin <[email-masked]>
Date: Thu, 12 Mar 1998 11:02:54 -0500

Tom,

No, most (all?) TCP stack implementations do not expose
data throttling events to the client.  (That is one of
the several "transparent" things the stream-like TCP
design gives the client.)

While it wouldn't be trivial, I suppose a client app could
make some thread priority adjustments based on detecting a
"blocked" outbound stream.  That is, upon trying to send a
buffer, the client would reduce the thread priority if the
API write function returned the (UNIX) equivalent of EWOULDBLOCK
(assuming the socket was setup for non-blocking I/O support).

While I understand Paul Moore's situation, I still don't think
it's a good idea to introduce this kind of communications
status in an application-level protocol such as IPP.

Does anyone disagree?

	...jay