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

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

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

Manros, Carl-Uno B (cmanros@cp10.es.xerox.com)
Wed, 16 Sep 1998 12:25:23 PDT

I sent the updated spec to the bake-off attendees last week, but could not
copy to the ftp server until today. We'd like to discuss at tomorrow's
(9/16/98) telecon if there are any remaining issues.

The same files as sent last week as attachments are now available in:


on the FTP server. The files are:

-rw-rw-r-- 1 pwg staff 80896 Sep 15 13:15
-rw-rw-r-- 1 pwg staff 35898 Sep 15 13:16
-rw-rw-r-- 1 pwg staff 36053 Sep 15 13:17
-rw-rw-r-- 1 pwg staff 99840 Sep 15 13:18
-rw-rw-r-- 1 pwg staff 52045 Sep 15 13:18

Here is the mail I sent last week to the bake-off attendees which describes
the changes:

>From: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: Updated IPP Set 1 operations spec (attached)
>I've updated the Set 1 operations (Hold-Job, Release-Job, Restart-Job,
>Pause-Printer, Resume-Printer, and Purge-Jobs) as result of the August
>20 Toronto meeting and the telecon, Wednesdayd, Sept 2 and 9.
>I've not been able to post them to the PWG server, so I've attached them
>as agreed on the Sept 9 telecon and sent this message to the 9/3 bakeoff
>mailing list. I'll also post them as soon as I can.
>Attached are the .doc file with revisions and the .pdf with revisions
>and the .pdf without revisions and the .txt without revisions.
>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
>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
>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
>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
>'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).