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

From: Robert Herriot <[email-masked]>
Date: Wed, 13 May 1998 20:04:58 -0700

I talked to Paul Moore yesterday to learn what problems IPP doesn't 
currently solve.

There were four main problems:

    a) no notification 
    b) if a connection fails, there is no way to know if it because the printer 
        is down or just busy.
    c) if a write times out, there is no way to know if it because the 
        printer is down or just busy.
    d) if a write operation succeeds, there is no way to be 100% sure that 
         the bytes made it to their final destination  The success of a write only 
         means that the TCP/IP layer succeeded.

The solutions:
    a) notification: the IPP group is close to a solution
    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. Then if the 
        connection fails, it is because the printer is down or the IP address is bad.
   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.
   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.
   
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

---

From: Jay Martin <[email-masked]>
Date: Wed, 13 May 1998 23:15:58 -0400

>         connection fails, it is because the printer is down or the IP address is bad.

Sounds like a fixed SNMP query.  Why don't we just use
SNMP and the Printer MIB for this kind of thing?

	...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: Robert Herriot <[email-masked]>
Date: Thu, 14 May 1998 12:37:39 -0700

In my solution, I assume that there is a port dedicated to returning printer 
status only and it has higher priority for processing than the normal IPP 
port or the SNMP port.  I want to keep the probability of a reply near 100% 
even when the printer is very busy with other network requests.  

The concern I have about SNMP is that a client's "get status" query could be
behind
several GetBulk requests and thus not get processed fast enough for the client
to
determine that the printer is alive but very busy.

Can an SNMP request have as good a guarantee of a quick response as a 
dedicated port?

Also in my proposal, I assume that the data returned is in an IPP compatible
format.

Bob Herriot