IPP> OPS - I've re-posted updated Set 1 IPP Ops spec for the bake-off

IPP> OPS - I've re-posted updated Set 1 IPP Ops spec for the bake-off

Tom Hastings hastings at cp10.es.xerox.com
Sun Sep 20 19:15:42 EDT 1998


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.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980909-rev.doc
ftp://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




More information about the Ipp mailing list