I made a mistake in my proposal below about re-using the same job-id
on a Reprint-Job (and adding the "number-of-reprints" Job Description
attribute). Presumably, the job description attributes, like
"job-media-sheets-completed", "job-k-octets-processed", and
"job-impressions-completed" are reset on a Reprint-Job. But if the
accounting hasn't copied
the data, the accounting program has lost some valuable charges.
Not resetting such progress attributes doesn't seem to be a good solution.
To fix this problem, we should do what ISO DPA finally had to do, namely,
have the Printer use a new job-id for the new job (and make a copy of the
old job attributes, but not the document data). Then the old job remains
in the 'completed', 'aborted', or 'cancelled' state and its Job Description
attributes do not get reset. The new job starts off with these job
progress job description attributes set to 0, such as
"job-media-sheets-completed".
Ok?
Tom
At 22:38 07/06/98 PDT, Tom Hastings wrote:
>At 16:20 7/6/98 PDT, Tom Hastings wrote:
>>At 10:49 6/29/98 PDT, Paul Moore wrote:
>>>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/>>>Describes 7 new operations that MS may be using for IPP1.0
>>>>>>We should discuss whther we want to make any of these standard extensions
>>>>One further question about Reprint-Job:
>>For ISO DPA Resubmit-Job, we finally decided that a new copy of the job
>should be created and assigned a new job-identifier. This was so that
>accounting would not get confused with a job that was resubmitted several
>times. Also by making a copy, any accounting done using the PWG Job
>Monitoring MIB, can be safely done while the job is in the 'completed'
>state, even if the job is resubmitted immediately before the accounting
>can be gathered for the job just completed, since a new job is created
>with a copy of all of the originally submitted attributes.
>>For the Reprint-Job, we could do the same and require that the IPP object
>return a new job-id and make a copy of the job. On the other hand, since
>the user cannot modify the job, a simpler approach to keep the accounting
>straight (and reflect the true state of the job), would be to add a Job
>Description attribute which is a count
>of the number of Reprint-Job operations performed. This
"number-of-reprints"
>Job Description attribute would be REQUIRED to be supported, if the IPP
>object
>supports the Reprint-Job operation. An accounting application would take
>note of the value for the "number-of-reprints" which is normally 0 if
>no Reprint-Job operation has been performed.
>>So we can save the harder ISO DPA Modify-Job and Resubmit-Job operations
>which modify the job to later.
>>Thanks,
>Tom
>>