Subject: Re: [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]

From: Ira McDonald <[email-masked]>
Date: Sun, 1 Nov 2009 21:18:47 -0500

Hi Tom,

Comments on every one of your RED issues inline below.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: [email-masked]
winter:
 579 Park Place  Saline, MI  48176
 734-944-0094
summer:
 PO Box 221  Grand Marais, MI 49839
 906-494-2434

On Tue, Oct 27, 2009 at 4:46 PM, Tom Hastings <[email-masked]>wrote:

>  I’ve uploaded v0.10 of  IPP Job and Printer Extensions - Set 2 (aka
> Production Printing Attributes - Set 2) for the upcoming IPP WG telecon,
> Monday, Nov 2, 1:00 PM PST = 4:00 PM EST (Note we change from Daylight to
> Standard time over the weekend):
>
>
>
> *ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v10-20091025.doc**
> *
>
> *ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v10-20091025.pdf<ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippprodprintext10-v10-20091025.pdf>
> *
>
> *
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v10-20091025-rev.doc
> *
>
> *
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v10-20091025-rev.pdf
> ***
>
>
>
> Note: that this time I really did change the file name to agree with the
> new title, i.e., from wd-ippprodprintext10-xxx.yyy to
> wd-ippjobprinterext10-xxx.yyy.  The change tracking in the –rev documents
> are changes from v0.8, 2009-10-08 version.
>
>
>
> v0.10, 2009-10-25
>
> I made the edits that were agreed to at the 2009-10-14 face to face.  See
> Section 0 16 Appendix X - Change Log [*which I have copied at the end of
> this long email*].  Removed green ISSUE agreements from the previous
> (2009-10-05) meeting.  There are some red ISSUES to be reviewed.  This
> would also be a good time to read the whole spec.
>
>
>
> v0.9, 2009-10-14
>
> Agreements at the IPP face to face meeting.  See change tracking and
> MS-WORD comments.
>
> I added 2 fixes with change tracking for Cancel-Jobs for the issue on
> returning "job-ids" when jobs can't be canceled iff the client had supplied
> "jobs-id".
>
> I removed the green ISSUE agreements from the 2009-10-05 meetings.
>
>
>
> If you haven’t read the spec from front page to back page, this would be a
> good time to do so.  We’ve made significant progress and simplification to
> Cancel-Jobs and Cancel-My-Jobs operations.  So those are good to read.  But
> the rest of the spec hasn’t had much attention.  I’ve left in the green
> ISSUEs MS-WORD comments (agreements) from the face to face Oct 14 meeting,
> but removed the earlier green ISSUEs to reduce clutter.  I’ve added the
> following red ISSUES (new text I want everyone to check, even if reading
> the clean version).  Responses to these in the email thread will be
> appreciated, though I won’t make any changes to the document until after the
> telecon.
>
>
>
> [th2]: ISSUE: Abstract: Is this summary of the new operations OK?
>
>
>
> 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."

> [th3]: ISSUE: This updated text in the definition of Proof Print Job in
> Section 2.2 OK to indicate that Proof Print Jobs can be aged out?
>
>
>
> A Proof Print Job is a Retained Job that the Printer retains (until removed
> by a Delete-Job or Purge-Jobs operation or aged out by the Printer using a
> different policy than for ordinary completed jobs) after printing a proof so
> that a copy of it can be printed any time after it has been proofed using
> the Reprocess-Job or Resubmit-Job operations, rather than aging the job out
> after an implementation-defined period.
>
>
>
 [ira] Yes - this is good text.

> [th6]: ISSUE: Section 4 New Operations: Is this summary OK?
>
>
>
>    1. Cancel-Jobs - allows the operator or administrator for the Printer
>    to cancel selected or *all* Not Completed jobs.
>    2. Cancel-My-Jobs - allows a user to cancel selected or *all* his/her
>    Not Completed jobs.
>    3. 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"

> [th7]: ISSUE:  Does the new Cancel-Jobs operations written in full look OK
> now that Cancel-My-Jobs has been factored out into a new section 4.2 below?
>
>
>
> Please read section 4.1 Cancel-Jobs operation
>
> [ira] On line 434, change "Set 2 extension" to "Set 2 specification".  Otherwise,
it's fine.

> [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.

> [th11]: ISSUE: Is this precedence of error checking text OK as agreed to
> on 10/14/2009?
>
>
>
> First, the Printer MUST check the access rights of the requesting user to
> endure that it is the Operator or Administrator of the Printer (see *Access
> Rights* below).  If this check succeeds, then (and only then) the Printer
> MUST accept or reject the request based on the current state of each of the
> candidate jobs and transition each job to the indicated new state as shown
> in Table 2 (copied verbatim from [RFC2911], including the Rule 1 and 2 for
> the convenience of the reader).
>
>
>
[ira] Yes.

> [th12]:  ISSUE: Still OK that this table is copied verbatim from [RFC
> 2911] as agreed, rather than merely referencing?
>
>
>
[ira] Yes.

> [th15]: ISSUE:  Does this Access Rights section look OK?
>
>
>
> *Access Rights**:* The authenticated user (see [RFC2911] section 8.3)
> performing this operation MUST be an operator or administrator of the
> Printer object (see [RFC2911]Sections 1 and 8.5).  Otherwise, the IPP object
> MUST reject the operation without canceling any jobs and return:
> 'client-error-not-authorized' status code and MUST NOT return the "job-ids"
> operation attribute
>
> [ira] Yes, it's fine.

>
>
> [th17]: ISSUE:  OK that omitting "job-ids" in the Cancel-Jobs operation
> cancels all cancelable jobs?  (This makes "job-ids" consistent with
> Cancel-My-Jobs which cancels all owner's jobs, if omitted and with [RFC
> 2911] Purge-Jobs.)
>
>
>
[ira] Yes, it's OK - the consistency with classic Purge-Jobs is important.

> [th19]: ISSUE:  Does the new Cancel-My-Jobs operations written in full
> look OK?  The change tracked version shows the changes from Cancel-Jobs
> above (rather than being all change tracked, since this section was NOT in
> v9)
>
>
>
[ira] On line 510, change "Set 2 extension" to "Set 2 specification".
Otherwise,
it's fine.
>
> [th21]: ISSUE:  Does this text get across the precedence that access check
> is higher precedence than status check, so that "job-ids" never has a
> mixture of jobs that aren't the requesters and ones that are but are in the
> wrong state as agreed to be the IPP WG to keep the Printer error checking
> simple?
>
>
>
> First, the Printer MUST check the access rights of the requesting user
> against *all* of the candidate jobs (see *Access Rights* below).  If *any*of the candidate jobs are not owned by the requesting user, the Printer MUST
> NOT cancel any jobs and MUST return the 'client-error-not-authorized' error
> status code along with the list of offending “job-id” values in the
> “job-ids” operation attribute (see section 4.1.2).  If this check succeeds,
> then (and only then) the Printer MUST accept or reject the request based on
> the current state of each of the candidate jobs and transition each job to
> the indicated new state as shown in Table 2 above.  If any of the candidate
> jobs cannot be canceled, the Printer MUST NOT cancel any jobs and MUST
> return the indicated error status code along with the list of offending
> “job-id” values in the “job-ids” operation attribute (see section 4.1.2).
>
>
>
[ira] Yes, it's fine.
>
> [th22]: ISSUE: OK NOT to duplicate Table 2 again, but just refer to it
> above, since it has already been copied from [RFC2911]?
>
>
>
[ira] Yes - the first copy is necessary (though unfortunate) - but the
second would be overkill.
>
> [th23]: ISSUE: For Cancel-My-Jobs, if the user is the operator or
> administrator, the jobs still have to belong to the operator or
> administrator, right?  Otherwise, the Printer MUST return the
> 'not-authorized' error, right?
>
>
>
[ira] Yes - if they meant to ignore owner rights, they should have used
Cancel-Jobs.
>
> [th24]: ISSUE: Does this Access Rights section look OK for the new
> Cancel-My-Jobs operation?
>
> *Access Rights**:* If the client supplied the "job-ids" attribute, the
> authenticated user (see [RFC2911] section 8.3) performing this operation
> MUST be the job owner of *all* the candidate jobs.  If *any* of the
> supplied "job-ids" specify jobs that do *not* belong to the requesting
> user, the IPP object MUST (1) reject the operation without canceling any
> jobs, (2) return: 'client-error-not-authorized', and (3) MUST return the
> "job-ids" operation attribute with any specified jobs that are not owned by
> the requesting user (see section 4.2.2 below).
>
> [ira] Yes, it's fine.
>
>
>
> [th26]: ISSUE:  OK that omitting "job-ids" in the Cancel-My-Jobs operation
> cancels all of the user's cancelable jobs?  (This makes "job-ids" consistent
> with Cancel-Jobs which cancels all owner's jobs, if omitted and with [RFC
> 2911] Purge-Jobs.)
>
>
>
[ira] Yes, it's OK - the consistency with classic Purge-Jobs is important.
>
> [th30]: ISSUE:  OK for Resubmit-Jobs that the Printer MUST reject an
> aborted job (as agreed to in the minutes of 10/05/2009), i.e., removed the
> previous row that said 'aborted' to 'aborted'?
>
>
>
[ira] Yes, it's OK - the aborted job can't have been successfully
saved/proofed.
>
> [th35]: ISSUE: Is this conformance statement OK?
>
>
>
> A client MUST be able to supply and a Printer MUST support the "job-ids"
> operation attribute in a Get-Jobs operation in order to claim support of
> this Job and Printer Extensions - Set 2 extension, respectively.
>
>
>
[ira] Yes, it's OK - except, change "Set 2 extension" to "Set 2
specification".
>
> [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.
>
> [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.
>
> [th42]: ISSUE: Is this conformance statement OK?
>
>
>
> If a client or Printer support the Purge-Jobs operation, such a client MUST
> be able to supply and a Printer MUST support the "job-ids" operation in the
> Purge-Jobs operation in order to claim support of this Job and Printer
> Extensions - Set 2 extension, respectively.
>
>
>
[ira] Yes, it's OK - except, change "Set 2 extension" to "Set 2
specification".
>
> [th44 & th45]:  ISSUE: OK to add "job-saved-with-warnings' to the list of
> unsuccessful values or are warnings still successful saving?
>
>
>
[ira] Yes, it's OK - job save needs to be high-fidelity to be useful.

> [th48]: ISSUE: OK that this “save-name-subdirectory-supported” (boolean)
> Printer Description attribute is described here in section 6.7.1.2.3.2.3,
> instead of in section 8 Printer Description Attributes where all other
> Printer Description attributes are defined?
>
>
>
[ira] Yes, it's OK - it flows better here.

> [th52]: ISSUE: OK that this “pdl-init-file-name-subdirectory-supported”
> (boolean) Printer Description attribute is described here in section
> 6.8.1.2.2, instead of in section 8 Printer Description Attributes where
> all other Printer Description attributes are defined?
>
>
>
[ira] Yes, it's OK - it flows better here.
>
> [th58]: ISSUE: OK to clarify that that "jobs-ids-supported" only applies
> to the existing Purge-Jobs and Get-Jobs, since the two new operations
> (Cancel-Jobs and Cancel-My-Jobs REQUIRE the Printer to support "job-ids" if
> they support these new operations?
>
>
>
> The “job-ids-supported” (boolean) Printer Description attributes indicates
> whether the Printer supports the “job-ids” Operation in the following
> existing operations: Purge-Jobs (if supported), and Get-Jobs.
>
>
>
[ira] Yes, it's OK - but we should reiterate the Cancel-Jobs and
Cancel-My-Jobs requirement here, to avoid confusion.

> [th59]:  ISSUE: Is this conformance statement OK?
>
>
>
> A Printer MUST support the "job-ids-supported " Printer Description
> attribute in order to claim support of this Job and Printer Extensions - Set
> 2 extension.
>
>
>
[ira] Yes, it's OK - except, change "Set 2 extension" to "Set 2
specification".
>
> [th60 & 74:]  ISSUE: Ok to add a 'proof-print' keyword to “which-jobs’
> operation attribute in Get-Jobs so that a client can query which jobs have
> been retained for proofing, analogous to Saved Jobs?
>
>
>
[ira] Yes, it's OK - good idea.

> [th61R60]:  ISSUE:  Should we make the 'proof-print' value of "which-jobs"
> in Get-Jobs operation REQUIRED if "proof-print" is supported?
>
>
>
[ira] Yes, it's OK - good idea.
>
> [th62]: ISSUE:  Should we make the 'saved' value of "which-jobs" in
> Get-Jobs operation REQUIRED if "proof-print" is supported?
>
>
>
[ira] Yes, it's OK - good idea.
>
> [th64]: ISSUE:  All "job-state-reasons" values are OPTIONAL.  Should we
> make any of these "job-state-reasons" values REQUIRED or conditionally
> REQUIRED, if such and such attribute is supported?
>
>
>
[ira] Since job-state-reasons is REQUIRED in IPP/1.1 (RFC 2911), we should
make the appropriate job-state-reasons values REQUIRED or CONDITIONALLY
REQUIRED, as appropriate.

> [th67]: ISSUE:  There had been some mention of needing a Rationale
> section.  But I couldn't find out anything about what is needed?
>
> Where should it go?
>
>
>
[ira] There should be a new top-level section 3 Requirements that contains
(at a minimum) section 3.1 Rationale (for this spec), section 3.2 Use Cases
(at least two - can be brief), and section 3.3 Design Requirements (for this
spec).  IPP PSX (PWG 5100.9) has a good example.
I volunteered to write a first draft - I've just been very busy with Power
Model - but I'll look into it this coming week.

> [th68]: ISSUE: Is this new section which summarizes the REQUIRED items for
> client and Printer in order to conform to this Job and Printer Extensions
> - Set 2 document, OK?
>
> In order for a client and a Printer to claim conformance to this Job and
> Printer Extensions - Set 2 document a client MUST be able to supply and a
> Printer MUST support the following:
>
> 1.       The Cancel-Jobs operation (section 4.1)
>
> 2.       The Cancel-My-Jobs operation (section 4.2)
>
> 3.       The Resubmit-My-Jobs operation (section 4.3)
>
> 4.       The "job-ids" Operation attribute in the Get-Jobs operation
> (section 5.3)
>
> 5.       The "job-ids" Operation attribute in the Purge-Jobs operation, if
> supported (section 5.4)
>
> 6.       The Saved Job Capability using the "job-save-disposition" Job
> Template attribute (section 6.7), if the Proof Print Job Capability using
> the "proof-print" Job Template attribute (section 6.9) is supported.
>
> 7.       The Proof Print Job Capability using the "proof-print" Job
> Template attribute (section 6.9)
>
> 8.       The "job-ids-supported" Printer Description attribute (section
> 8.2)
>
 [ira] Yes, it's OK.

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

> [th70R69]: ISSUE:  Are there any additional attribute values that should
> be added, such as for "job-state-reasons" or "which-jobs", perhaps
> conditional on support of other attributes?
>
>
>
[ira] Not sure - over to Mike - job-state-reasons (i.e., specific values)?
>
> [th72]: ISSUE: OK to add 'job-saved-successfully' and
> 'job-saved-with-warnings' to the REQUIRED list if supporting
> "job-save-disposition"?
>
>
>
[ira] Yes, it's OK.

> [th73]: ISSUE:  Are all the attributes, operations, and values in this
> section that the spec defines?
>
>
>
> I did a check with the table of contents and added many attributes to the
> IANA Considerations that had been missed and deleted some that had been
> removed from the spec.
>
>
>
[ira] Not sure - should check in final draft (before working group last
call).

> [th75]: ISSUE:  The IPP 2.0 document doesn't include author's names in the
> References section, but IETF RFCs do as does this version of our Set 2
> spec.  What should we use here?
>
>
>
>
>
>
>
[ira] IPP/2.0 contains a later top-level section Editors' Addresses (which
is current best practice in PWG specs).  I prefer the word "Editor" to
"Author" (currently used in IPP JPS2 spec).

> Here is the detailed change log that is in Section 16 Appendix X - Change
> Log:
>
>
>
> 1. Abstract: added the two new operations: Cancel-Jobs and Resubmit-Job.
>
>
>
> 2. Section 3.3 Job Save and Reprint Capability: Added that a Printer that
> supports Job Save and Reprint, MUST support Proof Print.
>
>
>
> 3. Section 3.4 Job Proof Print Capability: If a Printer supports Proof
> Print, it NEED NOT support Job Save and Reprint Capability.
>
>
>
> 4. Section 4 New Operations: Added this new section with complete
> Cancel-Job and Resubmit-Job operations.
>
>
>
> 5. Section 5.3 job-ids (1setOf integer(1:MAX)) for the Get-Jobs operation:
> In the Get-Jobs operation, if the client supplies the “my-jobs” attribute
> with the ‘true’ value and also supplies, the “job-ids” operation attribute,
> the Printer MUST reject the request and return the
> ‘client-error-conflicting-attributes’ status code.
>
>
>
> 6. Section 6.7 job-save-disposition  (collection):  Added: If Printer
> support "job-save-disposition", then it MUST also support "proof-print", but
> not the converse.
>
>
>
> 7. Section 6.7.1.2.3.1 save-location (uri):  Changed conformance for
> 'file:' in "save-location" from SHOULD to MAY.
>
>
>
> 8. Section 6.7.1.2.3.2 save-name (name(MAX)):  Added reference to the new
> "save-name-subdirectory-supported" Printer attribute that indicates whether
> the Printer supports FORWARD-SLASH in the "save-name".
>
>
>
> 9. Section 6.8.1.2.2 pdl-init-file-name-subdirectory-supported (boolean):
> Added new "pdl-init-file-name-subdirectory-supported" Printer Description
> attribute to indicate whether or not FORWARD-SLASH was supported in the
> "pdl-init-file-name" member attribute.
>
>
>
> 10. Section 6.9 proof-print  (collection):  Added that Proof Print Jobs can
> be aged out, but MAY be longer than ordinary jobs.
>
>
>
> 11. Section 9.3 job-state-reasons (1setOf type2 keyword) Job Description
> attribute:  Removed 'job-proof-wait'.
>
>
>
> Tom
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/ipp
>
>

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

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 2 Nov 2009 10:13:46 -0800

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.

> 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.

and change "Resubmit-Jobs" to "Resubmit-Job"... :)
> [th10 and th71]: ISSUE (repeat):  The PWG now have 4 levels of context for IPP conformance:
> 
>  
> 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?
> 
>  

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?
> 
>  

client-error-conflicting-attributes

> [th69R68]: ISSUE:  Are there any additional attributes that should be added?
> 
>  

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