Roger,
I have replied to each of your comments below.
Bob Herriot
At 06:01 AM 5/14/98 , Roger K Debry wrote:
>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.
>
><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
>
>
>
>
>
>
>
>
--=====================_4010667==_.ALT
Content-Type: text/html; charset="us-ascii"
Roger,
--=====================_4010667==_.ALT--
I have replied to each of your comments below.
Bob Herriot
At 06:01 AM 5/14/98 , Roger K Debry wrote:
>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.
>
><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
>
>
>
>
>
>
>
>