Subject: Re: SDP> Suggestions for discussion at SDP session next week

From: Roger K Debry <[email-masked]>
Date: Thu, 14 May 1998 09:01:43 -0400

Bob Herriot wrote ...
   snip ...

    b) the primary issue is being able to determine the printer status, i.e.
        did the connection fail because the printer is down or just busy.  One
        simple solution is to have a printer read on a UDP port dedicated to
        returning a status summary whenever it receives a request on the port.
If
        the incoming bytes are limited and have simple options, the printer
will
        never be tied up for long on each transaction and will always be able
to let
        a client know if it is alive and whether there are any problems

---

From: Robert Herriot <[email-masked]>
Date: Thu, 14 May 1998 13:19:35 -0700

Roger,

I have replied to each of your comments below.

Bob Herriot

At 06:01 AM 5/14/98 , Roger K Debry wrote:
>        returning a status summary whenever it receives a request on the
port.If
will
to let
>        a client know if it is alive and whether there are any problems.
>
><RKD> Is this a "new" protocol, or part of IPP? Do these responses always
flow?

Yes, I would consider it part of the IPP solution space and I would assume that
requests
and reponses would contain IPP compatible data.  If "always flow" means that an
alive printer
always returns a reponse, the answer is yes, at least 99.9% of the time.

><RKD> Can the client tell the Printer what kinds of status to return? How is
this
><RKD> different from an SNMP alert?

I would expect that this mechanism would return very limited and fixed 
information so that processing is kept to the minimum. Perhaps there are no 
options. A client can always use GetPrinterAttributes for a full set of 
attributes.  Since the intention of this operation is for a client (print 
server) to determine why a connection failed or a write is hanging or 
failed, the information returned should include printer state, printer-state 
reasons, number of pages printed for the current "job" and number of bytes 
received by each "job" (at least those in the process of being received).  
There are probably a few other properties as well. But what I am listing is 
information that would let a client (print server) determine whether a 
printer is making progress or seems to be hung.

>
>   c) this is essentially the same problem as b) and has the same
solution.Namely,
>       if a write times out, the client can query status and determine the
problem.
>
><RKD> How does the client query, if the pipeline is full, or clogged with
other
><RKD> traffic? 

Since this operation is reading from its own port using UDP, there shouldn't 
be clogging problems even if the other ports are rejecting connections. If 
someone disagrees with this, tell my why.

> <RKD>One of Paul's other requiremetns, which you do not mention, is to
><RKD> have a separate data channel. How do you propose to do this? If you use
another
><RKD> route, as suggested below, to issue the request for status, how do you
know
><RKD> what the otehr route is?

In my conversations with Paul, he had no requirement for a separate data 
channel.  One of the benefits of sockets is that each 
open socket is a separate data channel into the printer  So if several 
clients (print servers) connect to the well-known IPP port, the printer 
effectively creates a separate socket for each. So a client (print server) 
can use its socket to transmit an entire operation, short or long, to the 
printer.  The one limitation is the number of sockets that the printer is 
willing to have open at any time.  

This perhaps suggests that job submission operations should be on a 
different port from the querying and cancel job operations so that printer 
can accept connections for these operations while not accepting new jobs.  
There is still a need for the "printer status" port that I have proposed 
because even a separate querying port could get clogged with several long 
GetJobs requests.

>
>   d) I think that we should rely on TCP/IP to get the bytes to their
>       destination.  The most likely failure between client and paper is the
>       network.  Loss of data inside the printer seems like such a remote
problem
>       that it isn't worth making the protocol more complicated to solve this
problem.
>
><RKD> What about non-TCP connected printers?

All of the other likely connections, parallel, USB and 1394 have either 
defined or are likely to define a socket-like mechanism. In any case, socket 
support is the next layer down, and any protocol IPP defines should be 
multilayered. The IPP should be at the top and kept as a simple stream ,as 
it currently is. Issues about multiplexing and packetizing should be left to 
a lower layer which some other standards body defines. We should define such 
a lower layer only if the USB and 1394 people fail to define such a layer.

>
>I hope that we can discuss these ideas via the DL and next week in DC.
>
>The solution that I suggest with b) is a new IPP operation over a different
route from
>other IPP operations, so the syntax for request and reponse could be similar
or different.
>This solution allow IPP for other operations to remain unchanged.
>
>Bob Herriot
>
>
>
>
>
>
>
>