Re: IPP> MS-new-operations.htm uploaded [some questions/answers]

[Tom Hastings <[e-mail]>]

At 10:49 6/29/98 PDT, Paul Moore wrote:
>to ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/
>Describes 7 new operations that MS may be using for IPP1.0
>
>We should discuss whther we want to make any of these standard extensions

I welcome the proposal for new operations.  These look very reasonable and
useful.  ISO DPA has had them as well.  Implementations of ISO DPA have had
experience with their implementations that can be brought to bear (and to
simplify IPP).

However, in order to gain full interoperability between various
implementations there are a number of questions that need to be answered
and the agreements added to the specification of these operations.  I have
indicated the questions and suggested answers with highlighting like this.
See if you think if answering such questions is a good way to nail down the
details, rather than review the details of a (longer) specification.

Occasionally, I have an issue with what is being proposed.  That is
indicated as ISSUE, instead of QUESTION.

I've uploaded my questions on the new operations:

ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ms-new-operations-questions.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ms-new-operations-questions.pdf

Here is that document in plain text:



Questions and answers about proposed new operations
From:  Tom Hastings
Date:   7/6/1998
File:  ms-ipp-operations-questions.doc
I welcome the proposal for new operations.  These look very reasonable and
useful.  ISO DPA has had them as well.  Implementations of ISO DPA have had
experience with their implementations that can be brought to bear (and to
simplify IPP).
However, in order to gain full interoperability between various
implementations there are a number of questions that need to be answered
and the agreements added to the specification of these operations.  I have
indicated the questions and suggested answers with highlighting like this.
See if you think if answering such questions is a good way to nail down the
details, rather than review the details of a (longer) specification.
Occasionally, I have an issue with what is being proposed.  That is
indicated as ISSUE, instead of QUESTION.

New IPP 1.0 Operations
Microsoft has added several new operations to its implementation of IPP
1.0. They are currently added in the private extension space but we believe
that they are generally useful and so propose that some (if not all) of
them are moved into the main operation set.
[model] refers to the current IPP model and semantics document.
Operation attributes and responses
Job Operations
The operation attributes and responses for the job operations are the same
as the standard Cancel-Job operation (see [model] 3.3.3).
QUESTION 1:  Shouldn't we use the hyphenation conventions for these
operatioins?
SUGGESTED ANSWER:  Yes, so Hold-Job, Pause-Printer, Release-Job,
Resume-Printer, Purge-Printer, Reprint-Job.
QUESTION 2:  Which operations are Job operations:
SUGGESTED ANSWEr:  Hold-Job, Release-Job, Reprint-Job
Printer Operations
QUESTION 3:  Which operations are Printer operations:
SUGGESTED ANSWER:  Pause-Printer, Resume-Printer, Purge-Printer
The operation attributes for the printer operations are as follows:-
Target: 
Printer-URI - see 3.1.3 of [model]
Natural Language and Charset:
See 3.1.4.1 of [model]
Requesting User Name:
Should be supplied - see [model] 8.3
Response:
Status code and message as described in [model]3.1.5
HoldJob
Requests that a job be held in the queue - that means it is not eligible
for scheduling. If the job is not waiting to be printed than this operation
has no effect (but completes successfully).
QUESTION 4:  What state does the job go into after the operation?
SUGGESTED ANSWER:  I suggest that the job go into the 'pending-held' job
state.
QUESTION 5:  What job-state-reason is set, if the job-state-reasons
attribute is supported?
SUGGESTED ANSWER:  Add two new job state reason keywords:
'job-held-by-user', and 'job-held-by-operation' (analogous to Cancel-Job). 
Also use the current 'processing-to-stop-point', as in the Cancel-Job, if
the operation is accepted, but the job is not able to be put into the
'pending-held' state immediately.
ISSUE 1:  I suggest that the request be rejected if the implementation
cannot or does not put the job into the 'pending-held' state, rather than
just accepting the operation.
SUGGESTED FIX:  For authorized users, I suggest that an IPP object:
For a job in the  'pending' or 'pending-held' state, MUST accept the
request and move the job into the 'pending-held' state.  
For a job in the 'pending' or 'pending-stopped' states, an implementation
MAY either (1) accept the operation and move the job to the 'pending-held'
state if the implementation can process other jobs on that Printer and
later support the Release-Job operation for this job or (2) reject the
operation with the 'client-error-not-possible', depending on implementation.  
NOTE:  The former is ISO DPA Pause-Job semantics, but is hard to implement
we have found.  Stopping a job in the middle and then resuming it later is
difficult.
For a job in the 'completed', 'aborted', or 'canceled' states, MUST reject
the operation with the 'client-error-not-possible' status code.
Current Code: 0X4000
Access Rights: The requesting user must either be the submitter of the job
or an administrator of the printer
QUESTION 6:  What error codes if the access rights aren't satisfied?
SUGGESTED ANSWER:  Return:  client-error-forbidden,
client-error-not-authenticated, and client-error-not-authorized.
ReleaseJob
Requests that a previously held job be made eligible for scheduling once more.
QUESTION 7:  What job states MUST the job be in in order to accept this
operation?
SUGGESTED ANSWER:  The IPP object MUST reject this operation, unless the
identified job is in the 'pending-held' state and, if implemented, the
'held-by-user' or 'held-by-operation' value is present in the job's
"job-state-reasons" attribute, if the user is the submitter of the job or
an administrator, respectively .  If the job is not in the 'pending-held'
state, the IPP object MUST reject the request and return the
'client-error-not-possible' status code.
QUESTION 8:  What happens to the job's job state?
SUGGESTED ANSWER:  If there are no other reasons to hold the job, such as
the "job-hold-until" specifies a period of time in the future, the IPP
object MUST move the job from the 'pending-held' state to the 'pending'
state, whereupon it MAY move immediately to the 'processing' state, if
there are no other jobs pending with a higher priority.
Current Code: 0X4002
Access Rights: The requesting user must either be the submitter of the job
or an administrator of the printer
QUESTION 9:  What error codes if the access rights aren't satisfied?
SUGGESTED ANSWER:  Return:  client-error-forbidden,
client-error-not-authenticated, and client-error-not-authorized.
PausePrinter
Requests that the printer stops scheduling new jobs. Any job that is
currently being printed is completed. The printer will still accept new jobs.
QUESTION 10:  What state does the Printer go into?
SUGGESTED ANSWER:  The Printer goes into the 'stopped' state 
QUESTION 11:  What printer-state-reason is set, if the
printer-state-reasons attribute is supported?
SUGGESTED ANSWER:  The 'paused' value is added to the Printer object's
"printer-state-reasons" attribute.
ISSUE 2:  Why does the current job continue printing?  This doesn't sound
like pushing the pause button on the device.  The name suggests that the
IPP Printer should go into the 'stopped' state and, if implemented, the
'paused' value added to the Printer object's "printer-state-reasons"
attribute.  Also the current job go into the 'processing-stopped' state
and, if implemented, the 'printer-stopped' value added to the job object's
"job-state-reasons" attribute.  The user can go look at the Printer's
"printer-state-reasons" attribute to see why the printer is stopped.
SUGGESTED FIX:  Either require the above, or rename this operation to
something like Stop-Scheduling-Jobs, so that we can also have a
Pause-Printer operation that does the above.
QUESTION 13:  What states must the Printer be in/not it in order to
accept/reject the Pause-Printer?
SUGGESTED ANSWER:  The Printer object MUST accept this operation if the
Printer is in the 'idle' or 'processing' state.  The Printer object MUST
reject the operation if the Printer has previously accepted a Pause-Printer
operation without an intervening Resume-Printer, i.e., if the ' paused'
value, if supported, is present in the Printer's "printer-state-reasons"
attribute.
Current Code: 0X4001
Access Rights: The requesting user must be an administrator of the printer
ResumePrinter
Un-pauses a printer (see PausePrinter).
QUESTION 14:  What states must the Printer be in/not it in order to
accept/reject the Resume-Printer operation?
SUGGESTED ANSWER:  The Printer object MUST accept this operation if the
Printer has previously accepted a Pause-Printer operation without an
intervening Resume-Printer, i.e., if the ' paused' value, if supported, is
present in the Printer's "printer-state-reasons" attribute.  Otherwise, the
Printer object MUST reject the operation and return the
'client-error-not-possible' status code.
Current Code: 0X4003
Access Rights: The requesting user must be an administrator of the printer
PurgePrinter
Removes all jobs queued for a printer. Any job that is currently printing
is also cancelled.
Current Code: 0X4004
Access Rights: The requesting user must be an administrator of the printer
ReprintJob
Requests that a print job that is retained in the queue be (re)printed. In
this case the job is sent to the printer from the beginning.
QUESTION 15:  Is this operation also used to move a job to another printer
(after printing)?
SUGGESTED ANSWER:  No.  ISO DPA has a very complicated operation called
ResubmitJob, which works before or after the job has been printed and
allows the printer to be specified as a different one.
QUESTION 16:  What states must the Job be in/not it in order to
accept/reject the Reprint operation?
SUGGESTED ANSWER:  The IPP object MUST accept this operation if the Job is
in the 'completed', 'aborted', or 'canceled' job states.  If the job is in
another other state ('pending-held', 'pending', 'processing', or
'processing-stopped'), the IPP object MUST reject the operation and return
the 'client-error-not-possible' status code.

Current Code: 0X4005
Access Rights: The requesting user must either be the submitter of the job
or an administrator of the printer