ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980920.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980920.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980920.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980920-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set1-980920-rev.pdf
Sorry,
Tom
> -----Original Message-----
> From: Tom Hastings [mailto:hastings@cp10.es.xerox.com]
> Sent: Sunday, September 20, 1998 16:16
> To: ipp@pwg.org
> Subject: IPP> OPS - I've re-posted updated Set 1 IPP Ops spec for the
> bake-off
>
>
> 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
>