[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]
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: 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 Tue, Oct 27, 2009 at 4:46 PM, Tom Hastings <tom.hastings at verizon.net>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
>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/20091101/6e822367/attachment-0001.html>