> -----Original Message-----
> From: Jay Martin [SMTP:jkm@underscore.com]
> Sent: Saturday, February 07, 1998 10:33 AM
> To: ipp@pwg.org
> Cc: Puru Bish
> Subject: Re: IPP> Re: How should the server behave
>
> Puru Bish's scenario and questions strike a strong chord
> with me, having long been involved in protocol design and
> development.
>
> A robust protocol should allow a client to easily distinguish
> the difference between these two situations:
>
> 1) The server is not available (program not running,
> host not on the network, or unreachable in someway).
>
> 2) The server is "too busy" to handle the client's request
> at the moment; the client should try again "in the near
> future" when the server has finished its current load.
>
> All too many times the "too busy" situation is handled by
> a "silent" approach by the server...making it very, very
> difficult for the client to determine if a process problem
> exists (ie, a system component--the server--is not available,
> thereby making the "system" unusable), or if the client must
> "throttle back" and repeat the request at a later time.
>
> I hope we don't suggest the "silent" approach for IPP,
> especially if we're interested in a "much happier experience"
> for the end-user (as Tom Hastings has pointed out).
>
> In the case of an "IPP server too busy" situation, Carl Kugler
> has suggested:
>
> > Return server-error-service-unavailable (0x0502) to indicate
> > that the server is temporarily unable to handle a request.
>
> This is fine by me IFF that error code has precisely (and ONLY)
> the semantics of "too busy, try back later". Otherwise, if
> this error code is overloaded, we should define a different
> and unique error code to declare the "too busy" condition.
>
> I know it may be asking too much (particularly at this late
> stage), but it would be ideal if, for a "too busy" condition,
> the server not only returns a distinguishing error code, but
> also returns some sort of "hint" as to when the client should
> try again (eg, 5 minutes, 3 hours, etc.). In doing so, the
> IPP protocol would be helping to reduce network traffic, as
> well as improving the predictability of the printing process.
>
> Comments?
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>
>
> Puru Bish wrote:
> >
> > :: >> 3. How should a non-spooling IPP-server handle concurrent
> > ::print-job
> > ::>> requests?
> > :: >
> > ::>Return server-error-service-unavailable (0x0502) to indicate that the
> > server is
> > >temporarily unable to handle a request.
> > >
> >
> > >We also discussed that a server MAY keep a list of clients that are
> > trying
> > >to connect in a "queue", and then serve each one one at a time. Then
> > the
> > >client doesn't receive an error (except if the "queue" is filled).
> > This
> > >gives the end-user a much happier experience.
> >
> > Consider the scenario:
> > An IPP Client tries to print a job to an IPP server. A
> non-spooling
> > HTTP/IPP server received TCP SYN pkt on port 80
> > from the IPP
> > client, responded back with a TCP SYN-ACK pkt, and then received
> > an ACK pkt from the IPP client. At this point, the HTTP/IPP
> > server does not know whether the next pkt is going to be an IPP request
> > or a simple HTTP operation for its embedded web.
> > Next comes the first HTTP POST
> > pkt with IPP header and IPP data. However, at this time, the
> > HTTP/IPP server realized that another IPP job is in the process
> > of printing. What will the IPP server do? if we follow the first
> > recommendation, it will immediately send a 0x0502 IPP status
> > to indicate that the service is temporarily. However, if we follow the
> > second recommendation, should the non-spooling IPP server just sit
> > idle and not respond to the new HTTP POST operation?
> >
> > Thanks,
> > PB
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com