>>"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?
>
>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.
The FAX WG has struggled with a similar issue based on SMTP. Is delivery
to the last hop [DSN] sufficient notification .. or is actual
processing/viewing of the message necessary [MDN].
Current IPP notification looks like DSN to me while the advanced IPP
notification proposals more closely match MDN.
I do agree that the IPP notification proposal that is on the table would
satisify any reasonable requirement for notification.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
Fax 314.918.9015
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<