Ira,
Thanks for the replies.
So the Printer MUST check all of the jobs that have been requested, BEFORE
canceling any to see if any are NOT owned by the user. If any are NOT owned
by the user, then NONE are canceled. Sounds good and that check doesn't
have any race conditions.
ISSUE: OK to say that the Printer MUST return the list that are NOT owned in
the same "job-ids" (1setOf integer(1:MAX)) operation attribute in the
response?
There is a second kind of error that could occur for a subset of the
specified jobs that are owned by the user. The jobs could be in the wrong
state. RFC 2911 Cancel-Job has the following error table based on the state
of the specified job:
The IPP object MUST accept or reject the request based on the job's current
state and transition the job to the indicated new state as follows:
Current "job-state"
New "job-state"
IPP object's response status code and action:
'pending'
'canceled'
'successful-ok'
'pending-held'
'canceled'
'successful-ok'
'processing'
'canceled'
'successful-ok'
'processing'
'processing'
'successful-ok' See Rule 1
'processing'
'processing'
'client-error-not-possible'
See Rule 2
'processing-stopped'
'canceled'
'successful-ok'
'processing-stopped'
'processing-stopped'
'successful-ok' See Rule 1
'processing-stopped'
'processing-stopped'
'client-error-not-possible'
See Rule 2
'completed'
'completed'
'client-error-not-possible'
'canceled'
'canceled'
'client-error-not-possible'
'aborted'
'aborted'
'client-error-not-possible'
Rule 1: If the implementation requires some measurable time to cancel the
job in the 'processing' or 'processing-stopped' job states, the IPP object
MUST add the 'processing-to-stop-point' value to the job's
"job-state-reasons" attribute and then transition the job to the 'canceled'
state when the processing ceases (see section 4.3.8).
Rule 2: If the Job object already has the 'processing-to-stop-point' value
in its "job-state-reasons" attribute, then the Printer object MUST reject a
Cancel-Job operation.
Access Rights: The authenticated user (see section 8.3) performing this
operation must either be the job owner or an operator or administrator of
the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
ISSUE: OK to say that after checking that all of the jobs are owned by the
requesting user (unless the requesting user is the operator), the Printer
MUST return the 'client-error-not-possible' for any jobs that are not in a
state that [RFC 2911] Section 3.3.3 Cancel-Job allows to be canceled and
MUST indicate which jobs cannot be canceled in the "job-ids" operation
attribute return in the response.
Or should we say that all of the jobs MUST be in a cancelable state, else
none of the jobs are canceled (but still the Printer MUST return the list
that are not cancelable in "job-ids"). I favor the former, since one of the
jobs that the user wants to cancel may have just completed, so the user
would have to resupply the request removing those jobs that have completed.
Thanks,
Tom
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Thursday, October 08, 2009 10:32
To: tom.hastings at alum.mit.edu; Ira McDonald
Cc: ipp at pwg.org
Subject: Re: [IPP] Updated (new) Cancel-Jobs, enhanced Get-Jobs and
Purge-Jobs uploaded - some issues needing resolution Thursday
Hi Tom,
My comments are inline below.
Except to note that the operation attribute
is correctly named "job-ids" (singular "job"
and plural "ids"). Please make sure to get
this right.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Thu, Oct 8, 2009 at 3:58 AM, Tom Hastings <tom.hastings at verizon.net>
wrote:
> I've uploaded v8 of the new Cancel-Jobs, enhanced Get-Jobs and Purge-Jobs
> uploaded at:
>
>ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-Get-Jobs-Purge-Jobs-enhancement
s-v8-20091007.doc
>
>ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-Get-Jobs-Purge-Jobs-enhancement
s-v8-20091007.pdf
>
>
>
> I'd like to get resolutions Thursday, as I finish the rest of Set 2 on
> Thursday.
>
>
>
> ISSUES for the new Cancel-Jobs operation are:
>
>
>
> ISSUE: OK that the Printer MUST ignore "jobs-ids" if "my-jobs" = 'true' is
> supplied, rather than reject the request and return the
> 'client-error-bad-request" status?
>
<ira> Yes, OK - a legacy Printer wouldn't understand "job-ids" (in Get-Jobs)
and would ignore it, so the above is the right behavior.
</ira>
>
>
> ISSUE: OK that the Printer MUST reject a request that does NOT specify a
> list of jobs and does NOT specify "my-jobs" = 'true'? What if the
> requesting user is the operator? Should this case cancel all jobs?
>
> In other words, is it OK that the Cancel-Jobs operation does not allow the
> Operator to cancel all jobs?
>
<ira> Cancel-Jobs is NEW, so we can make it solid. Missing required
operation attributes must be a client error - it's NOT desirable that
Cancel-Jobs be able to cancel *all* jobs.
</ira>
>
>
> ISSUE: OK that the Printer cancels the ones owned, but not the ones not
> owned? Then the Printer can repeatedly perform Cancel-Job operations on
> each job in the list, rather than checking the entire list before
canceling
> any
>
<ira> No, bad choice. The Printer MUST immediately check that all members
of "job-ids" are owned by the end user (if not operator or admin requester),
so that it returns a privilege error and does NOT cancel ANY jobs.
</ira>
>
>
>
>
> ISSUES for the Get-Jobs enhancement:
>
>
>
> ISSUE: OK that the Printer MUST ignore "jobs-ids" if "my-jobs" = 'true' is
> supplied, rather than reject the request and return the
> 'client-error-bad-request" status?
>
<ira> Yes, OK - this is compatibile with legacy Printers that don't
understand
(and must ignore) "job-ids".
</ira>
>
>
> Thanks,
>
> Tom
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> _______________________________________________
> ipp mailing list
>ipp at pwg.org
>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20091008/c411296f/attachment-0001.html>