If this is true, then the error return should be the infamous
"too busy" error code, the one that Randy is working on (I believe).
...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 --
----------------------------------------------------------------------
Tom Hastings wrote:
>
> At 12:04 03/12/1998 PST, Puru Bish wrote:
> >
> >Thanks, Tom for clarifying the issue.
> >
> >I still have a question - should an IPP server behave the same
> >way even when it does not spool any job?
>
> You mean what should an IPP Printer object implemented in a server
> that does not spool jobs, but forwards jobs onto a single device directly
> (perhaps using IPP or some other device protocol), but the device
> to which it forwards jobs is shutdown?
>
> I would think that the following response might be the best:
>
> The server would reject the Create-Job and return the error code:
> 'server-error-service-unavailable'.
> Then the client could query the Printer's "printer-state" and see 'stopped'
> and the Printer's "printer-state-reasons" and see 'error-shutdown'.
>
> Do others agree?
>
> Tom
>
> >
> >-PB
> >
> >>From hastings@cp10.es.xerox.com Wed Mar 11 17:57:09 1998
> >
> >>Yes, the Printer object implemented in a server object does accept the
> >>job even though the device is powered down.
> >>
> >>And the requester MAY get an indication that there is a problem,
> >because
> >>the job's OPTIONAL "job-state-reason" attribute that MAY be returned in
> >the
> >>Print-Job response containing the value: 'printer-stopped'
> >>(or 'printer-stopped-partly' in the case that only some of the fan-out
> >>printers are stopped). Unfortunately, the requeseter will NOT get this
> >>indication in the response, if the IPP Printer object does not
> >implement
> >>the OPTIONAL "job-state-reasons" attribute.
> >>
> >>The client can then query the Printer's "printer-state"
> >>and "printer-state-reasons" attribute and see that the "printer-state"
> >>is 'stopped' and the "printer-state-reasons" is 'error-shutdown'
> >>('warning-shutdown' if only some of the fan-out printers are shutdown).
> >>
> >>
> >>The explanation of the 'stopped' state on page 89 of the Model document
> >>says (in its entirity of two paragraphs):
> >>
> >>'5' 'stopped': If a Printer receives a job (whose required resources
> >are
> >>ready) while in this state, such a job SHALL transit into the pending
> >state
> >>immediately. Such a job SHALL transit into the processing state only
> >after
> >>some human fixes the problem that stopped the printer and after jobs
> >ahead
> >>of it complete printing. The "printer-state-reasons" attribute SHALL
> >>contain at least one reason, e.g. media-jam, which prevents it from
> >either
> >>processing the current job or transitioning a pending job to the
> >processing
> >>state.
> >>
> >>Note: if a Printer controls more than one output device, the above
> >>definition implies that a Printer is stopped only if all output devices
> >are
> >>stopped. Also, it is tempting to define stopped as when a sufficient
> >>number of output devices are stopped and leave it to an implementation
> >to
> >>define the sufficient number. But such a rule complicates the
> >definition
> >>of stopped and processing. For example, with this alternate definition
> >of
> >>stopped, a job can move from idle to processing without human
> >intervention,
> >>even though the Printer is stopped.
> >>
> >>
> >>
> >>Does the Model document need any futher clarification?
> >>
> >>Tom
> >
> >
> >
> >
> >______________________________________________________
> >Get Your Private, Free Email at http://www.hotmail.com
> >
> >