[IPP] v0.10 Draft of IPP Job and Printer Extensions - Set 2 uploaded for IPP WG telecon, Mon, Nov 2, 1:00 PST = 4:00 EST [we're off daylight time next week]

Mon Nov 2 18:13:46 UTC 2009

and my comments inline with Ira's...

On Nov 1, 2009, at 6:18 PM, Ira McDonald wrote:
> This document also defines three new operations:  Cancel-Jobs, Cancel-My-Jobs, and Resubmit-Job.  Cancel-Jobs allows an operator/administrator to cancel a list of Not Completed jobs or all Not Completed jobs on the Printer.  Cancel-My-Jobs allows a user to cancel a list of their Not Completed jobs or all their Not Completed jobs.  Resubmit-Job allows a user to re-process a modified copy of a Retained Job.  A new “job-ids” operation attribute is added to Purge-Jobs and Get-Jobs, as well, to operate on a specified list of jobs, instead of on all jobs.
> 
> [ira] Yes - this is a good summary.  I might invert the last sentence to say "This document also extends two existing operations:  Purge-Jobs and Get-Jobs both have an optional "job-ids" operation attribute added to operate on a specific list of jobs, instead of on all jobs."
> 

Or :

This document also defines three new operations - Cancel-Jobs, Cancel-My-Jobs, and Resubmit-Job - and a new "job-ids" operation attribute to be used with the existing Get-Jobs and Purge-Jobs operations. Cancel-Jobs allows an operator/administrator to cancel a list of Not Completed jobs or all Not Completed jobs on the Printer. Cancel-My-Jobs allows a user to cancel a list of their Not Completed jobs or all their Not Completed jobs. Resubmit-Job allows a user to re-process a modified copy of a Retained Job. Get-Jobs with the "job-ids" attribute allows a user to get a list of jobs. Purge-Jobs with the "job-ids" attribute allows an operator/administrator to purge a list of jobs.

> [th6]: ISSUE: Section 4 New Operations: Is this summary OK?
> 
>  
> Cancel-Jobs - allows the operator or administrator for the Printer to cancel selected or all Not Completed jobs.
> Cancel-My-Jobs - allows a user to cancel selected or all his/her Not Completed jobs.
> Resubmit-Jobs - allows a user to request the printer to process a copy of a Retained Job with possibly additional or modified attributes.
> [ira] Yes - fine.  Except change "possibly" in (3) to "optional" 

and change "Resubmit-Jobs" to "Resubmit-Job"... :)
> [th10 and th71]: ISSUE (repeat):  The PWG now have 4 levels of context for IPP conformance:
> 
>  
> Level 1: IPP 1.0, 1.1, 1.2, 2.0, 2.1, 2.2.
> 
> Level 2: this extension spec (new)
> 
> Level 3: Xxx Capability, i.e., Job Save and Reprint Capability and Job Proof Print Capability.
> 
> Level 4: an operation.
> 
>  
> Do we really want to introduce this level 2 conformance, i.e., conformance to this spec, or just rely on the IPP m.n specs to group sets of attributes and operations?
> 
>  
> [ira] Each IPP spec (including this one) needs to define conformance ONLY to itself (without reference to any IPP/1.1 or IPP/2.x level at all).  IPP/2.2 is NOT currently defined, but will include this spec and four others (PWG 5100.3, .5, .6, and .8) and a number of new required operations and attributes. 

Right, and you can probably expect that some IPP/2.1 implementations might implement this spec but not the others. So, what Ira said... :)
> [th36]: ISSUE:  What happens if the client also supplies "which-jobs" (type2 keyword) in the Get-Jobs request along with "job-ids"?  If some of the specified jobs are NOT in the states requested, are they just ignored or is that an error?
> 
>  
> [ira] I think that "which-jobs" and "job-ids" should be mutually exclusive.

Right, you can't combine a list of jobs with any of the other selectors, so combining "job-ids" with "limit", "my-jobs", or "which-jobs" should result in a client-error-conflicting-attributes status code.
> [th37R36]: ISSUE:  What happens if the client also supplies "my-jobs" (type2 keyword) = 'true' in the Get-Jobs request along with "job-ids"?  If some of the specified jobs are NOT the user's jobs are they just ignored or is that an error?
> 
>  
> [ira] I think that "my-jobs" and "job-ids" should be mutually exclusive.

client-error-conflicting-attributes

> [th69R68]: ISSUE:  Are there any additional attributes that should be added?
> 
>  
> [ira] Not sure - over to Mike - job-state-reasons (i.e., specific values)?

Yeah, I think that is appropriate - require the job-printed-* and conditionally require the job-saved-* "job-state-reasons" keywords. Similarly, require the all but the saved "which-jobs" keywords, where saved is conditionally required.

job-state-reasons: job-printed-successfully, job-printed-with-errors, job-printed-with-warnings, job-resuming, job-scheduling, job-spooling, job-streaming, job-suspended-by-operator, job-suspended-by-system, job-suspended-by-user, and job-suspending are all REQUIRED. job-saved-successfully, job-saved-with-errors, and job-saved-with-warnings are REQUIRED if job save is supported

which-jobs: aborted, all, canceled, pending, pending-held, processing, processing-stopped, proof-print are all REQUIRED. saved is REQUIRED if job save is supported

___________________________________________________
Michael Sweet, Senior Printing System Engineer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20091102/d3a9bfca/attachment-0001.html>