[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]
[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]
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.docftp://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.docftp://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
[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.
[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.
[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
[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?
[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).
[th12]: ISSUE: Still OK that this table is copied verbatim from [RFC 2911]
as agreed, rather than merely referencing?
[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
[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.)
[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)
[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).
[th22]: ISSUE: OK NOT to duplicate Table 2 again, but just refer to it
above, since it has already been copied from [RFC2911]?
[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?
[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).
[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.)
[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'?
[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.
[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?
[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?
[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.
[th44 & th45]: ISSUE: OK to add "job-saved-with-warnings' to the list of
unsuccessful values or are warnings still successful saving?
[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?
[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?
[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.
[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.
[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?
[th61R60]: ISSUE: Should we make the 'proof-print' value of "which-jobs"
in Get-Jobs operation REQUIRED if "proof-print" is supported?
[th62]: ISSUE: Should we make the 'saved' value of "which-jobs" in Get-Jobs
operation REQUIRED if "proof-print" is supported?
[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?
[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?
[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)
[th69R68]: ISSUE: Are there any additional attributes that should be added?
[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?
[th72]: ISSUE: OK to add 'job-saved-successfully' and
'job-saved-with-warnings' to the REQUIRED list if supporting
"job-save-disposition"?
[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.
[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?
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, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20091027/e5b464e3/attachment-0001.html>