I've updated the Set 1 Operations spec for the bake-off as agreed to
at the telecon, Wednesday, 9/16/98:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909.txtftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909-rev.pdf
Note the shortened name so that the entire URL fits on a single e-mail line.
The changes are:
1. Changed Hold-Job, so that it does NOT return an error if the requester
specifies "job-hold-until"='no-hold', but rather puts the job into the
pending state. Same if the named time period has already started.
(The "job-hold-until" remains an OPTIONAL operation attribute to support).
2. Fixed the typo in the first line after the table in section 1, so that
it reads: "All of the operations in Set 1 ...", instead of "All of the
attributes in Set 1 ..."
3. Added the following Security section:
5 Security Considerations
For the job operations in Set 1 (Section 2), the requesting user must
either be the submitter of the job or an operator or administrator of the
Printer object (see [ipp-mod] Section 1). Otherwise, the IPP object MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate. See [ipp-mod] Section 8.3 on the two ways that the client
MUST specify the user who is performing each IPP operation.
For the printer operations in Set 1 (Section 4), the requesting user must
by an operator or administrator of the Printer object (see [ipp-mod]
Section 1). The means for authorizing an operator or administrator of the
Printer object are not specified in either [ipp-mod] or this document.
Here is a repeat of the changes that I sent two weeks ago based on the Toronto
meeting and the 9/2/98 and 9/9/98 telecons.
>>This spec is the one that will be used during the bake off for testing
>>these new OPTIONAL operations.
>>>>Please read and send any comments to the mailing list. We will also discuss
>>the spec at next Wednesday's telecon: 9/16, 10-12 PDT, 1(800)857-5607,
>>passcode: cmanros.
>>>>The changes are:
>>>>1. Changed the document from an IETF to a PWG DRAFT
>>>>2. Removed the Reprocess-Job operation altogether. We need to analyze
>>the accounting problem starting with requirements, rather than adding
>>the Reprocess-Job operation now in the name of helping accounting
>>applications.
>>>>3. I did not close up the opcode assignments, as agreed to on the telecon,
>>since Paul had already changed his code to agree with the previous version
>>(without implementing the Reprocess-Job operation).
>>>>4. Clarified that the job operations return the "job-state" and,
>>OPTIONALLY, "job-state-reasons" attributes as Group 3 Job Attributes.
>>>>5. Made the following changes to the Restart-Job operation:
>>>>a. added the OPTIONAL "job-held-until" operation attribute, so that the job
>>can be restarted but put into the 'pending-held' state immediately. (Then
>we
>>can add a Modify-Job operation in the future to modify other Job Template
>>attributes before the client releases the job using Release-Job).
>>>>b. Indicated that Restart-Job MAY be supported for jobs in the 'processing'
>>or 'processing-stopped' states.
>>>>c. Added the 'job-restartable' value to the "job-state-reasons" attribute
>>to indicate when a job is restartable using the Restart-Job operation.
>>>>6. Clarified the "job history" concept as an OPTIONAL sub-state of
>>'completed',
>>'aborted', or 'canceled' job states. If the "job history" concept is
>>supported, clients may query such jobs using the Get-Job-Attributes and
>>Get-Jobs operations.
>>>>7. Add a 'restartable' value to the "job-state-reasons" job attribute which
>>is present in the job's job-state-reasons attribute when the client is
>>able to restart the job using the Restart-Job operation and is absent
>>when the job cannot be restarted.
>>>>8. Added the picture to the Printer operations section, so that we can see
>>the source of print jobs to a device that do not come throuth the IPP
>>Printer object, so that we can talk about that other job source.
>>>>9. Indicated for Pause-Printer and Purge-Jobs, whether it affects job
>>submitted from other sources than the IPP Printer object in question,
>>depends on implementation.
>>>>10. Clarified that the Purge-Jobs operation deletes all jobs regardless of
>>state, including all jobs in the Printer object's "job-history". Indicated
>>that an operator can cancel all jobs and put them into the "job history",
>>by using the Cancel-Job operation on each job. Presumably a client that
>>shows the active jobs is likely to allow the operator to select some or
>>all of the jobs and hit the cancel button (cancelling the selected jobs).
>>>>Tom