Michael wrote:
We need to fully specify the Cancel-Jobs operation, as this is a new
operation and not an extension of an existing operation (just copy the
Cancel-Job description from RFC2911 and tweak...)
I'll do the same for the other new operation: Resubmit-Jobs as well.
Tom
_____
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Thursday, October 08, 2009 11:36
To: tom.hastings at alum.mit.edu
Cc: ipp at pwg.org
Subject: Re: [IPP] Updated (new) Cancel-Jobs, enhanced Get-Jobs and
Purge-Jobs uploaded - some issues needing resolution Thursday
We need to fully specify the Cancel-Jobs operation, as this is a new
operation and not an extension of an existing operation (just copy the
Cancel-Job description from RFC2911 and tweak...)
Also, "1.4 The job-ids (boolean) Printer Description attribute" should be
"1.4 The job-ids-supported (boolean) ...".
Anyways, comments inline...
On Oct 8, 2009, at 12:58 AM, Tom Hastings 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?
That sounds too ambiguous to me. We should return client-error-bad-request
if a client specifies both my-jobs and job-ids.
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?
No, Cancel-Jobs should cancel all jobs if my-jobs and job-ids are not
specified, just as Purge-Jobs does. The limitation is that only an
operator/administrator can cancel other users' jobs, so an ordinary user
sending a "Cancel-Jobs" operation without "my-jobs" or "job-ids" will only
work if there are only jobs owned by that user.
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
We want Cancel-Jobs to be atomic, so if any of the jobs (implicitly or
explicitly via job-ids) are not owned by the user and the user is not an
operator or administrator, the printer should return
client-error-not-authorized, just like Cancel-Job does today.
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?
As for Cancel-Jobs, I think we need to return client-error-bad-request
because of the ambiguity.
___________________________________________________
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/20091008/56dfc492/attachment-0001.html>