>> >-----Original Message-----
> >From: Carl Kugler [mailto:kugler at us.ibm.com]
> >Sent: Thursday, October 15, 1998 09:05
> >To: ipp at pwg.org> >Subject: Re: IPP> Minutes from IPP - IPP 2 IFAX
> >
> >
> >
> >> I'm assuming IPP clients can query that the job was actually
> >printed but in
> >> most cases the fact that "it got there" is enough. The IPP
> >transaction
> >> model in many ways resembles the network fax server model
> >where the fax may
> >> have hit the server on the LAN successfully but had not been
> >routed to the
> >> desktop.
> >>
> >In general, that's not a safe assumption.
>> While I agree that it is not a "safe assumption", the FAX market place has
> proven that it is good enough. Perhaps the reason that successful receipt
> of the bits is safe enough for FAX, is because FAX is only bits. The chance
> for errors, such as font not found, or unsupported PDL operator can't occur.
>
But I'm saying that there's no guarantee that you can even verify that the bits (the document data) were successfully received. The Printer may respond after processing the IPP attributes, before the document data was even transmitted.
> >"At job processing
> >time, since the Printer object has already responded with a
> >successful status code in the response to the create request,
> >if the Printer object detects an error, the Printer object is
> >unable to inform the end user of the error with an operation
> >status code. In this case, the Printer, depending on the
> >error, can set the "job-state", "job-state-reasons", or
> >"job-state-message" attributes to the appropriate value(s) so
> >that later queries can report the correct job status... The
> >final value for this attribute [job-state] MUST be one of:
> >'completed', 'canceled', or 'aborted' before the Printer
> >removes the job altogether. The length of time that jobs
> >remain in the 'canceled', 'aborted', and 'completed' states
> >depends on implementation."
> >
> >I think that some implementors have argued recently that it's
> >best for a job to go away as soon as it's completed, aborted,
> >or cancelled. So there's no guarantee that a client can query
> >whether the job was actually printed.
>> What were these arguments?
At the bakeoff, I seem to remember that a certain client implementation was confused when jobs that had been canceled hung around. Maybe this recollection is faulty. Anyway, there is no guarantee in the standard that completed, aborted, or cancelled jobs will be retained for any length of time.
>> I think that the best answer is to finish reviewing and approving our
> notification proposal in which the notificaiton that the job had completed
> successfully (or otherwise) would get to the sender or whom ever the sender
> indicates in the subscription.
>> >
> > -Carl
> >
> >-----
> >See the original message at http://www.egroups.com/list/ipp/?start=4636> >--
> >Free e-mail group hosting at http://www.eGroups.com/> >
>>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4728
--
Free e-mail group hosting at http://www.eGroups.com/