"McDonald, Ira" wrote:
> ...
> ira> I agree with the caveat that the reused job-id MUST represent
> ira> a job which NEVER entered the 'processing' state on the
> ira> original Printer - otherwise it becomes an avenue for an
> ira> accounting exploit that runs a job twice and gets charged once.
True with some implementations (I don't this CUPS would fall for
this, since each page is logged individually as soon as it goes to
the printer)
> ...
> Which should be called "job-printer-uri" to avoid ambiguitity with
> the printer-uri used to identify the job.
>> ira> Not sure which Printer URI is being renamed above. I'd
> ira> suggest that an operation attribute in 'Move-Job' be called
> ira> 'target-printer-uri' or 'new-printer-uri' for clarity.
Right. My issue is just that the "printer-uri + job-id" method of
referencing a job means that the *new* target printer object needs
to be specified with a differently named attribute. Since
"job-printer-uri" is already spec'd as a job template attribute, we
can reuse it with Move-Job...
> ...
> I think we need it. If we end up requiring a new job-id (something
> I'd rather not do), then we also need to add a new job-state value
> for "job-moved", since "completed", "cancelled", and "aborted" do
> not make sense.
>> ira> I agree that we need 'job-moved' as an event AND also in
> ira> 'job-state-reasons'. We MUST NOT add a new 'job-state'.
> ira> This would break all existing IPP and Job Monitoring MIB
> ira> implementations. The Xerox MFP I worked with in the past
> ira> on this feature transitioned the 'old' job to 'job-state'
> ira> of 'cancelled' and 'job-state-reasons' of 'job-moved'.
OK, sounds good. Just as long as the state can be uniquely
identified...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com