For those interested in the two new operations proposed in v0.8 of the draft
Standard for
Internet Printing Protocol (IPP): Production Printing Attributes - Set 2
that I posted earlier today, I've extracted Section 4 with the red ISSUE
comments:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-and-Resubmit-Job-spec-v8-200910
08.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-and-Resubmit-Job-spec-v8-200910
08.doc
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-and-Resubmit-Job-spec-v8-200910
08-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-and-Resubmit-Job-spec-v8-200910
08-rev.doc
There are 16 red ISSUE comments, most of which we resolved via the email
discussion between Michael, Ira, and myself, but I left in as red, in the
form of "ISSUE: Ok that .", so that we can have a wider review at the face
to face.
Here are the 16 red ISSUES. You may need to read the text that they refer
to in order to completely understand them:
ISSUE 1: Does the new Cancel-Jobs operations written in full look OK? The
change tracked version shows the changes from Cancel-Job.
ISSUE 2: OK that the new Cancel-Jobs operation lets the operator cancel all
jobs?
ISSUE 3: Is this conformance statement correct to reflect the agreement on
10/5/2009 that Cancel-Jobs is REQUIRED?
ISSUE 4: OK that the Printer MUST reject the entire Cancel-Jobs operation if
any of the specified jobs can't be canceled, rather than canceling the ones
that can be canceled and skipping the ones that can't?
ISSUE 5: What if there are also jobs that fail the job status check. Does
the Printer have to return those error "job-id" values too?
ISSUE 6: OK that the Printer MUST return the error "job-ids" even if the
client did NOT supply the "job-ids" attribute (independent of whether the
client supplied "my-jobs" with 'true', 'false' or not at all)?
See discussion of issue 6 below.
ISSUE 7: OK that we don't define a "job-uri" operation attribute?
ISSUE 8: OK that the Printer skips over any of the jobs that can't be
canceled according to Table 2? Otherwise, the operator can't use
Cancel-Jobs, if there are any 'completed' jobs around.
ISSUE 9: OK that the Printer skips over any of the user's jobs that can't be
canceled according to Table 2, rather than rejecting the job? Otherwise,
the user can't use Cancel-Jobs, if there are any of his 'completed' jobs
around.
ISSUE 10: OK that the Printer MUST return the
'client-error-conflicting-attributes' status code which requires that the
two conflicting attributes ("job-ids" and "my-jobs" be returned in the
Unsupported Attributes Group, rather than the simpler
"client-error-bad-request"?
ISSUE 11: Does the new Resubmit-Job operations written in full look OK?
The change tracked version shows the changes from Restart-Job defined in
[RFC2911]
ISSUE 12: Is this conformance statement correct to reflect the agreement on
10/5/2009 that Resubmit-Jobs is REQUIRED?
ISSUE 13: Is this conformance statement correct to reflect the agreement on
10/5/2009 that Resubmit-Jobs is REQUIRED?
IPP WG agreed on 10/5/2009: Looks OK. I moved this paragraph from section
3.3.1.2 Reprinting using the Resubmit-Job operation to the formal
specification here.
ISSUE 14: Is this description sufficient?
ISSUE 15: OK that we don't define a "job-uri" operation attribute?
ISSUE 16: OK that the Resubmit-Job operation doesn't discuss the
"job-hold-until" operation attribute, even though the Restart-Job operation
did?
Email replies on any of the issues are welcome or save them for the face to
face.
I have not made any changes from the v0.8 of the entire document that I
posted earlier today, just to keep the number of versions to a minimum for
our face to face next Wednesday. So I left in ISSUE [th6]:
ISSUE 6: OK that the Printer MUST return the error "job-ids" even if the
client did NOT supply the "job-ids" attribute (independent of whether the
client supplied "my-jobs" with 'true', 'false' or not at all)?
We can change it at the face to face meeting, since Ira and Michael both
suggest that the Printer NOT return any "job-ids" in error, if the client
had not supplied any "job-ids" in the request.
Tom
Here are Ira's and Michael's notes on issue 6.
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Friday, October 09, 2009 10:09
To: Michael Sweet; Ira McDonald
Cc: tom.hastings at alum.mit.edu; ipp at pwg.org
Subject: Re: [IPP] ISSUE: on Cancel-Jobs: what if some jobs are in
cancelablestate and some are not?
Hi,
I agree with Mike, on both historical practice (don't surprise
clients in responses) and the previous Get-Jobs context
that is an obvious predicate for Cancel-Jobs. If the client
says "job-ids", then he should know what he's doing.
Cheers,
- Ira
_____
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Friday, October 09, 2009 09:32
To: tom.hastings at alum.mit.edu
Cc: ipp at pwg.org
Subject: Re: [IPP] ISSUE: on Cancel-Jobs: what if some jobs are in
cancelable state and some are not?
On Oct 9, 2009, at 12:15 AM, Tom Hastings wrote:
One small nit:
Michael wrote:
That said, we should only include the job-ids attribute in the response if
it was supplied in the request, since otherwise we are only canceling jobs
that can be canceled at that moment.
However, if the unprivileged user supplies Cancel-Job with neither "job-ids"
and "my-jobs" (or "my-jobs" = 'false'), i.e., cancel all jobs that are in a
cancelable state, and there are jobs that are 'pending', 'pending-held',
'processing' that don't belong to the user, so that the Printer MUST reject
the Cancel-Jobs with client-error-not-authorized, why shouldn't the Printer
also return the list of "job-id" values of these jobs that didn't belong to
the user?
Two reasons: first, historically we have only returned unsupported
attributes for attributes that were provided in a request.
Second, because the client lacks the context information for a particular
job-ids value. Consider the following situation:
1. User foo submits job 123.
2. User bar does a Cancel-Jobs operation with no additional attributes
3. Cancel-Jobs returns client-error-not-authorized with job-ids=123
4. Job 123 completes and its history is aged out
5. User bar does a Get-Job-Attributes request to inspect job 123, which
fails with client-error-not-found.
There is also the case where local security policies do not allow user bar
to see (or get) user foo's job objects, so in that case the job-ids values
are not usable even when the job object is still around.
However, when the client provides a job-ids attribute, it must have already
gotten a list of valid job IDs (presumably with Get-Jobs) and so it has the
context for the jobs it is canceling.
--
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/20091009/703dda7c/attachment-0001.html>