Subject: IPP> IPP > FAQ - How should the server behave?

From: [email-masked]
Date: Mon, 2 Feb 1998 13:12:18 +0100

As mentioned in Maui I would like a FAQ list. Here is my questions when I
read the
IPP model & protocol document. I am looking forward to the 'developers
guide', which
should describe the behavior of the IPP printer when an IRQ occour etc.

1.   If an IPP-client transmit a request to the IPP-server and close the
tcp-connection, should the
     IPP-server open a new tcp-session and transmit the response?
2.   Must the IPP-server wait with the response, on a print-job request, to
the whole job is received?
3.   How should a non-spooling IPP-server handle concurrent print-job
requests?

Henrik Holst

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * *
* Henrik Holst	                               *
* Software engineer - developing embedded Printservers	*
* i-data International	                       *
* Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark	           *
* Voice:  (45) 44366271	                      *
* Fax:    (45) 44366111	                      *
* Email:  [email-masked]	            *
* WEB:    www.i-data.com	                          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * *

---

From: [email-masked]
Date: Wed, 11 Feb 1998 08:08:39 +0100

>Carl (or anyone else),

>Perhaps I wasn't asking the right question, or wasn't being
>explicit enough, so let me re-ask the question.

>Is IPP currently defined such that the "server-error-service-unavailable"
>(0x0502) error code is used EXCLUSIVELY for the "server too busy
>to accept your request" condition?

>In particular, I am hoping this (or some other IPP error code)
>can be used in an unoverloaded way to precisely mean one thing,
>and not a bushel-basket of various conditions.

 >...jay

If the "server-error-service-unavailable" (0x0502) error code means
"server too busy to accept your request" I think the error code should say
"server-warning-service-busy" or something like. However, I understands
that
the error code is the HTTP error code and in such case may the
"server-error-service-unavailable" (0x0502) error code means that no
IPP server is present at all!
I can't see it's an error the IPP server is busy, it's a normal condition.

/HOLST

___________________________________________________________
 Henrik Holst
 Software engineer - developing embedded Printservers
 i-data International
 Vadstrupvej 35-43, 2880 Bagsvaerd, Denmark
 Voice:  (+45) 44366271
 Fax:    (+45) 44366111
 Email:  [email-masked]
 WEB:    www.i-data.com

---

From: Carl Kugler <[email-masked]>
Date: Wed, 11 Feb 1998 12:24:25 -0500

I think would be a good idea to define a new *status* code for this purpose.
It could be an informational code, rather than an error code, if this condition
is considered normal.  It might also be worthwhile to invent an attribute to
codify the delay estimate.

 -Carl

[email-masked] on 02/11/98 09:42:40 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: Carl Kugler/Boulder/IBM@ibmus
Subject: Re: IPP> IPP > FAQ - How should the server behave?

Would it be too much to ask that IPP define a specific
error code for the "server to busy to accept requests"
condition?

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

Carl Kugler wrote:
> No.
>  -Carl
> [email-masked] on 02/10/98 02:13:27 PM
> Please respond to [email-masked] @ internet
> To: Carl Kugler/Boulder/IBM@ibmus
> cc: [email-masked] @ internet
> Subject: Re: IPP> IPP > FAQ - How should the server behave?
>
> Carl (or anyone else),
>
> ----------------------------------------------------------------------
> --  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   --
> ----------------------------------------------------------------------
>
> Carl Kugler wrote:
> >
> > The 0x0502 status code means "The IPP object is currently unable to handle
the
> > request due to a temporary overloading or maintenance of the IPP object. "
> So,
> > yes, it could also mean the IPP object is down for maintenance.
> >
> >  -Carl
> >
> > [email-masked] on 02/09/98 12:34:38 PM
> > Please respond to [email-masked] @ internet
> > To: Carl Kugler/Boulder/IBM@ibmus
> > cc: [email-masked] @ internet
> > Subject: Re: IPP> IPP > FAQ - How should the server behave?
> >
> > Carl Kugler wrote:
> >
> > > I'd be happier to get server-error-service-unavailable (0x0502) with an
> > > estimate of the the length of the delay indicated in the message.  A
client
> > > could then give a user the choice of canceling, retrying, or queuing
locally
> > > and retrying after delay.  At that point the user might decide to try
> another
> > > printer, or just queue the job locally (client side) and go on.
> >
> > Is the "server-error-service-unavailable" (0x0502) error code used
> > for any other type of error condition?
> >
> >  ...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: Jay Martin <[email-masked]>
Date: Wed, 11 Feb 1998 11:42:15 -0500

...jay

Carl Kugler wrote:
> > The 0x0502 status code means "The IPP object is currently unable to handle the
> > > estimate of the the length of the delay indicated in the message.  A client
> > > could then give a user the choice of canceling, retrying, or queuing locally