We'd like to process these comments on tomorrow's telecon and via e-mail.
Each comment starts with THn>.
TH0> A number of us reviewed Carl's updated proposal and we support this
proposal for the registration of additional operations for use with IPP/1.0
and IPP/1.1. These operations are similar to the System Administration
operations that are in ISO DPA Part 3. Thus a number of companies have had
implementation experience with similar operations. Based on that experience
we'd like to see the IPP WG apply some of the same simplifying principles to
the DPA experience that we did for IPP/1.0 and IPP/1.1.
The revision marks show our comments on Carl's proposal.
First a comparison of this proposal and DPA:
This proposal DPA Comments
Set-Job-Attributes ModifyJob, Set
Set-Printer-Attributes Set
Cancel-Current-Job -- LPD has
Shutdown Shutdown
Backspace-Current-Job --
Enable Enable
Disable Disable
Possible additional operations:
Reprocess-Job Resubmit-job
We'd like to propose these new IPP operation extensions for registration.
--------------------------------------------------------------------------
Type of registration: operationProposed name of this operation:
Set-Job-Attributes (or Modify-Job)
TH1> We suggest that we adopt the name Set-Job-Attributes, rather than
Modify-Job. Set-Job-Attributes is more parallel to the IPP/1.0
Get-Job-Attributes and Get-Printer-Attributes operation names.
Object Target (Job, Printer, etc. that operation is upon): Job
Specification of this attribute (sic)(follow the style of IPP Model
Section 3):
TH2> I will fix the typo in IPP/1.1 Model Section 11.7 from "attribute" to
"operation"
This operation allows the client to modify attributes of previously
submitted jobs.
TH3> We suggest that the more usual use case will be modifying a job in the
'pending' or 'pending-held' job state. So add something like:
For example, if a 'pending' job has a "copies" Job Template
attribute with a value of '3', the client could change it to '2'. As
another example, if a 'pending' job did not have a 'finishings' Job Template
attribute, the client could modify the job to add the 'finishings' attribute
with a value of, say, 'staple'.
For example, if a large job aborts in the middle,
"page-ranges" or "copies" could be modified and the job restarted.
TH4> Whether modification of a job while it is in 'processing' state needs
to be implementation-dependent and MAY depend on the attribute being
modified as well. More importantly we need a state table, like we have
introduced in IPP/1.1. How about:
The IPP object MUST accept or reject the request based on the job's current
state and transition the job to the indicated new state as follows:
Current "job-state" New "job-state" IPP object's response status code
and action:
'pending' 'pending' 'successful-ok'
'pending' 'pending-held' 'successful-ok' - needed resources are not
ready
'pending-held' 'pending-held' 'successful-ok'
'pending-held' 'pending' 'successful-ok' - needed resources are ready
'processing' 'processing' 'successful-ok' or
'client-error-not-possible' depending on the attributes being set and/or
implementation
'processing-stopped' 'processing-stopped' 'successful-ok' or
'client-error-not-possible' depending on the attributes being set and/or
implementation
'completed' 'completed' 'client-error-not-possible' - see Rule 1
'canceled' 'canceled' 'client-error-not-possible' - see Rule 1
'aborted' 'aborted' 'client-error-not-possible' - see Rule 1
Rule 1: The operation MAY be able to modify a job in the 'completed',
'canceled', and/or 'aborted' state before redoing the job using the
Restart-Job operation.
Printers that support Restart-Job should allow Job attributes to be set
(changed) when the Job is in the Job Retention phase. (Job Retention:
When a job enters one of the three terminal job states: 'completed',
'canceled', or 'aborted', the IPP Printer object MAY "retain" the job in a
restartable condition for an implementation-defined time period. ) Job
accounting must take into account any changed attributes when a retained
Job is restarted.
TH5> We have the following concerns about allowing an end-user modify
his/her retained job:
Problem 1: If the help desk is trying to help a user understand why the job
did what it did, but the user could have changed the attributes while it was
in the Job Retention Phase.
Problem 2: Also for accounting that polls for jobs in the Retention Phase,
it would get the changed attributes of the job, not the original ones used
during processing. Note: we think that the IPP Model needs to incorporate
both push and pull type of accounting. The push would use reliable
notification. But we can't rule out "pull" accounting.
Possible solutions:
Solution 1: We suggest re-introducing into the proposal the Reprocess-Job
operation that was in the proposal last year. Reprocess-Job differs from
Restart-Job in that Reprocess-Job creates a new job with a new job ID. Also
we would allow the user to modify any job attributes as part of the
Reprocess-Job operation which modifies the copy, but not the original job.
Solution 2: Re-introduce the Reprocess-Job, but more simply only allow the
"job-hold-until" operation attribute on the new Reprocess-Job operation.
Then the user uses the Set-Job-Attributes to modify the job while in the
'pending-held' state and releases the job using the IPP/1.1 Release-Job
operation.
Solution 3: Allow an implementer option on the current IPP/1.1 Restart-Job
operation to generate a new Job ID, though this might cause existing clients
difficulty.
Variant on any of the above: We could allow an operator to modify a job in
the 'completed', 'aborted', or 'canceled' state and restart the job using
the current Restart-Job operation, since the operator may be attempting to
re-do something that wasn't done right the first time.
TH6> Need to add the same Access Rights section as for Cancel-Job:
Access Rights: The authenticated user (see section 8.3)
performing this operation must either be the job owner or an operator or
administrator of the Printer object (see Sections 1 and 8.5). Otherwise,
the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated', or
'client-error-not-authorized' as appropriate.
Set-Job-Attributes Request:Group 1: Operation Attributes
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: Either (1) the "printer-uri" (uri) plus "job-id"
(integer(1:MAX)) or (2) the "job-uri" (uri) operation attribute(s)
which define the target for this operation as described in section
3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
Attribute Fidelity: The "attribute-fidelity" operation attribute is used
to specify whether or not the sets are atomic or not. If false, or not
present, the Printer sets what it can and returns the unset attribute/value
pairs in Unsupported Attributes group. If true, either all sets succeed or
the
operation is rejected and none of the attributes are changed.
TH7> Add the usual conformance sentences to the beginning of this operation
attribute:
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute.
TH8> Explain the setting of attributes:
Each Job attribute supplied in Group 2 replaces the value(s)
of the corresponding Job attribute on the target Job object. For attributes
that can have multiple values (1setOf), all values supplied by the client
replace all values of the corresponding Job object attribute. If a
supported attribute did not exist on the Job object, the Printer object adds
the supplied attribute with the supplied value(s) to the Job object.
TH9> Clarify that the validation is like in DPA, by adding the following:
The validation is performed as if the job had been submitted
originally with the new values. If such a create job operation would have
been accepted, then the Set-Job-Attributes MUST be accepted. If such a
create job operation would have been rejected, then the Set-Job-Attributes
MUST be rejected and the Job MUST be unchanged.
Group 2: Job Attributes
This is the group of attributes to be set and their requested new values.
The following tables show which Job attributes can be set, which can be
reset, and which are read-only.
TH10> Not clear what "reset" means? There doesn't seem to be any reason to
complicate the specification by supporting the setting of a Job attribute
back to the Printer's default value. We suggest deleting "which can be
reset"."Set?" Legend:
TH11> Need conformance language on the S, P, and N notation:
N means that the value MUST NOT be settable, no matter what the state of the
Job object is.
P means set when the Job object is created, but MUST NOT be settable
subsequently.
However, for the S case, most attributes MUST be settable, some SHOULD be
settable, and some MAY be settable. We've taken a strawman proposal on the
MUST, SHOULD, and MAY cases for S. Also we have some minor disagreements on
which attributes are N.
S = Settable: attribute value can be set or modified any time the object
is in appropriate state.
P = Specifiable: attribute value can be specified when object is created,
but not subsequently.
N = Non-settable: Read-only.
TH12> Add a comments column. See below.
IPP Job Description Attributes
+----------------------------+------+
| IPP Job Attribute | Set? |
+----------------------------+------+
| job-uri | N |
+----------------------------+------+
| job-id | N |
+----------------------------+------+
| job-printer-uri | N |
+----------------------------+------+
| job-more-info | N |
+----------------------------+------+
| job-name | S | MUST
+----------------------------+------+
| job-originating-user-name | P |
+----------------------------+------+
| job-state | N |
+----------------------------+------+
| job-state-reasons | N |
+----------------------------+------+
| job-state-message | N |
+----------------------------+------+
| number-of-documents | N |
+----------------------------+------+
| output-device-assigned | N |
+----------------------------+------+
| time-at-creation | N |
+----------------------------+------+
| time-at-processing | N |
+----------------------------+------+
| time-at-completed | N |
+----------------------------+------+
| job-printer-up-time | N |
+----------------------------+------+
| number-of-intervening-jobs | N |
+----------------------------+------+
| job-message-from-operator | S | MUST if attr supported. Add comment:
+----------------------------+------+ Needs operator access rights.
| job-k-octets | N |
+----------------------------+------+
| job-impressions | S | SHOULD if attr supported. However,
an
an implementation refuse to allow "job-impressions" to be set, if it knows
better from the document content.
+----------------------------+------+
| job-media-sheets | S | SHOULD if attr supported. However,
an
an implementation refuse to allow "job-media-sheets" to be set, if it knows
better from the document content.
+----------------------------+------+
| job-k-octets-processed | N |
+----------------------------+------+
| job-impressions-completed | N |
+----------------------------+------+
| job-media-sheets-completed | N |
+----------------------------+------+
| attributes-charset | P |
+----------------------------+------+
| attributes-natural-language| P |
+----------------------------+------+
IPP Job Template Attributes
+============================+===+
| IPP Job Attribute |Set|
| | ? |
+============================+===+
| job-priority | S | MUST if attribute supported.
+----------------------------+---+
| job-hold-until | S | MUST if attribute supported.
+----------------------------+---+
| job-sheets | S | MUST if attribute supported.
+----------------------------+---+
|multiple-document-handling | S | MUST if attribute supported.
+----------------------------+---+
| copies | S | MUST if attribute supported.
+----------------------------+---+
| finishings | S | MUST if attribute supported.
+----------------------------+---+
| page-ranges | S | MUST if attribute supported.
+----------------------------+---+
| sides | S | MUST if attribute supported.
+----------------------------+---+
| number-up | S | MUST if attribute supported.
+----------------------------+---+
| orientation-requested | S | MUST if attribute supported.
+----------------------------+---+
| media | S | MUST if attribute supported.
+----------------------------+---+
| printer-resolution | S | MUST if attribute supported.
+----------------------------+---+
| print-quality | S | MUST if attribute supported.
+----------------------------+---+
Set-Job-Attributes Response:
Printer should validate new attribute set and return
'successful-ok-conflicting-attributes',
or
'client-error-conflicting-attributes'
depending on "attribute-fidelity".
Group 1: Operation Attributes
Status Message: In addition to the REQUIRED status code returned in
every response, the response OPTIONALLY includes a "status-message"
(text) and/or a "detailed-status-message" (text(MAX)) operation attribute as
described in sections 1 and 8.5.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
TH13> However, for attributes that are 'not-settable', we need to add an
out-of-band value: 'not-settable' for returning in the Unsupported
Attributes group. Then add the following sentence here:
In the case of attributes that are not settable, the Printer
object returns the client-supplied attribute(s) with a substituted value of
'not-settable'. This value's syntax type is "out-of-band" and its encoding
is defined by special rules for "out-of-band" values in the "Encoding and
Transport" document [IPP-PRO]. Its value indicates that the attribute is
not settable.
Status codes:
'successful-ok'
'client-error-not-possible'
'successful-ok-ignored-or-substituted-attributes',
'successful-ok-conflicting-attributes',
'client-error-attributes-or-values-not-supported'
'client-error-conflicting-attributes'
'client-error-attribute-read-only' .
--------------------------------------------------------------------------
Type of registration: operationProposed name of this operation:
Set-Printer-Attributes (or Modify-Printer)TH14> We suggest that we adopt the
name Set-Job-Attributes. Its more parallel
to Get-Job-Attributes and Get-Printer-Attributes.
Object Target: PrinterSpecification of this operation:TH15> Will fix the
typo in IPP/1.1 Model Section 11.7 from "attribute" to
"operation"
This operation allows the client to modify attributes of a Printer.
TH16> We don't need a Printer state transition diagram here. Instead, add:
The Printer MUST accept this operation in any of the values of the Printer
object's "printer-state".
TH17> Need to add the same Access Rights section as for Pause-Printer:
Access Rights: The authenticated user (see section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
TH18> Most Printer attributes will require administrator privileges to set,
such as "xxx-supported", while some will only require operator privileges,
such as "media-ready" and "printer-message-from-operator". So add the
following sentence to the Access Rights paragraph:
Most Printer attributes will require administrator
privileges to set, such as "xxx-supported", while some will only require
operator privileges, such as "media-ready" and
"printer-message-from-operator". Which attributes require which privileges
depends on implementation and MAY depend on site policy.
Set-Printer-Attributes Request:
Group 1: Operation Attributes:
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: The "printer-uri" (uri) operation attribute which is the
target for this operation as described in section 3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
"document-format" (mimeMediaType) : The client OPTIONALLY supplies
this attribute. This is used to select the interpreter to which these
attributes should be applied.
TH19> Add the usual conformance sentences to the beginning of this operation
attribute:
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute.
Attribute Fidelity: The "attribute-fidelity" operation attribute is used
to specify whether or not the sets are atomic or not. If false, or not
present, Printer sets what it can and returns the unset attribute/value
pairs in Unsupported Attributes group. If true, either all sets succeed or
operation is rejected.
TH20> Add the usual conformance sentences to the beginning of this operation
attribute:
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute.
Group 2: Printer Attributes:
This is the set of attributes to be set and their requested new values.
Not all attributes are settable. The following tables show which Printer
attributes can be set, which can be reset, and which are read-only.
TH21> Not clear what "reset" means? We suggest deleting "which can be
reset".
TH22> Explain the setting of attributes:
Each Printer attribute supplied in Group 2 replace the
value(s) of the corresponding Printer attribute on the target Printer
object. If a Printer object attribute had not been configured yet and so
had the 'no-value' out-of-band value (see [ipp-mod] 4.1), the supplied
value(s) replace the 'no-value' value. For attributes that can have
multiple values (1setOf), all values supplied by the client replace all
values of the corresponding Printer object attribute.
TH23> Clarify that the validation, by adding the following:
How the Printer object validates the client-supplied
attributes in the Set-Printer-Attributes request is
implementation-dependent, since there are no corresponding Printer
attributes that specify the allowed values that may be set on the Printer
object.
TH24> Add to the Implementer's Guide about validation of
Set-Printer-Attributes:
For example, an operator or system administrator may change
the value of an "xxx-supported" Printer attribute to a subset of the values
that the implementation contains code for. How does the operator or system
administrator restore such a removed value? Presumably, the client fetches
the current values for the "xxx-supported" attribute and displays them to
the operator/administrator. The operator/administrator can remove values
and then issue the Set-Printer-Attributes operation. To add values back the
operator/administrator types in additional value(s) and does the
Set-Printer-Attributes operation. The implementation MAY perform some sort
of validation on such values by some implementation-defined means, including
not performing any validation.
"Set?" Legend:
TH25> Need conformance language on the S, P, and N notation:
N means that the value MUST NOT be settable, no matter what
the state of the Job object is.
P means set when object is created, but MUST NOT be settable
subsequently.
However, for the S case, most attributes MUST be settable,
some SHOULD be settable, and some MAY be settable. We've taken a strawman
proposal on the MUST, SHOULD, and MAY cases for S. Also we have some minor
disagreements on which attributes are N.
S = Settable: attribute value can be set or modified any time the object
is in appropriate state.
P = Specifiable: attribute value can be specified when object is created,
but not subsequently.
N = Non-settable: Read-only.
TH26> Add a comments column. See below.
IPP Printer Job Template Attributes
+======================+===+
|Printer: Default Value|Set|
| Attribute | ? |
+======================+===+
| job-priority-default | S | MUST if attribute supported.
+----------------------+---+
| job-hold-until- | S | MUST if attribute supported.
| default | |
+----------------------+---+
| job-sheets-default | S | MUST if attribute supported.
+----------------------+---+
|multiple-document- | S | MUST if attribute supported.
| handling-default | |
+----------------------+---+
| copies-default | S | MUST if attribute supported.
+----------------------+---+
| finishings-default | S | MUST if attribute supported.
+----------------------+---+
| sides-default | S | MUST if attribute supported.
+----------------------+---+
| number-up-default | S | MUST if attribute supported.
+----------------------+---+
|orientation-requested-| S | MUST if attribute supported.
| default | |
+----------------------+---+
| media-default | S | MUST if attribute supported.
+----------------------+---+
| printer-resolution- | S | MUST if attribute supported.
| default | |
+----------------------+---+
| print-quality-default| S | MUST if attribute supported.
+----------------------+---+
+======================+===+
| Printer: Supported |Set|
| Values Attribute | ? |
+======================+===+
|job-priority-supported| S | SHOULD if attribute supported.
TH27> Why not allow the administrator to change whether job priorities are
supported or not?+----------------------+---+
|job-hold-until- | S | SHOULD if attribute supported.
| supported | |
+----------------------+---+
|job-sheets-supported | S | SHOULD if attribute supported.
+----------------------+---+
|multiple-document- | S | SHOULD if attribute supported.
|handling-supported | |
+----------------------+---+
| copies-supported | S | SHOULD if attribute supported.
+----------------------+---+
| finishings-supported | S | SHOULD if attribute supported.
| | |
+----------------------+---+
| page-ranges- | S | SHOULD if attribute supported.
| supported | |
+----------------------+---+
| sides-supported | S | SHOULD if attribute supported.
+----------------------+---+
| number-up-supported | S | SHOULD if attribute supported.
+----------------------+---+
|orientation-requested-| S | SHOULD if attribute supported.
| supported | |
+----------------------+---+
| media-supported | S | SHOULD if attribute supported.
+----------------------+---+
| media-ready |S| SHOULD if attribute supported.
TH28> Make SHOULD be settable.
TH29> ISSUE: For the future Notification specification: which attributes
MUST generate a configuration change event, which SHOULD, which MAY, and
which MUST NOT.
We suggest that all xxx-default, xxx-supported, and xxx-ready changes MUST
generate a configuration change event, so that clients that have cached
these values can go get the new values. Such clients have to do a slow poll
(5-15 minutes) anyway, since the event may have been lost.
For the other attributes that have an S, need to indicate whether they MAY
generate a configuration change or MUST NOT. For example, a set to the
"printer-message-from-operator" MAY generate a configuration change event.
+----------------------+---+
| printer-resolution- | S | SHOULD if attribute supported.
| supported | |
+----------------------+---+
| print-quality- | S | SHOULD if attribute supported.
| supported | |
+----------------------+---+
TH30> There seems to be several attributes that have N indicated when the
administrator could usefully change the policy to be a subset of the
contained code in the implementation. For example, "versions-supported".
Why not allow implementations to set them by change the N to S MAY.
Implementations can still refuse to accept a change on an S MAY.
IPP Printer Description Attributes
+----------------------------+---+
| IPP Printer Attribute |Set|
| | ? |
+============================+---+
| printer-uri-supported | S | MUST
+----------------------------+---+
| uri-security-supported | S | MUST
+----------------------------+---+
|uri-authentication-supported| S | MUST
+----------------------------+---+
| printer-name | S | MUST
TH31> Why not allow this to be set. Its the administratively set name.
+----------------------------+---+
| printer-location | S | MUST if attr supported
+----------------------------+---+
| printer-info | S | MUST if attr supported
+----------------------------+---+
| printer-more-info | S | MUST if attr supported
+----------------------------+---+
| printer-driver-installer | S | SHOULD if attr supported
+----------------------------+---+
| printer-make-and-model | S | MAY if attr supported
+----------------------------+---+
| printer-more-info- | S | MAY if attr supported
| manufacturer | |
+----------------------------+---+
| printer-state | N |
+----------------------------+---+
| printer-state-reasons | N |
+----------------------------+---+
| printer-state-message | N |
TH32> According to [ipp-mod] this attribute is only a text form of
"printer-state" and/or "printer-state-reasons". Therefore, it MUST NOT be
settable. Change to N. There is a "printer-message-from-operator" that is
a separate attribute.
+----------------------------+---+
| ipp-versions-supported | S | MAY
TH33> Why not MAY be settable?
+----------------------------+---+
| operations-supported | S | SHOULD
+----------------------------+---+
| ipp-multiple-document-jobs-| N |
| supported | |
+----------------------------+---+
| charset-configured | S | MAY
+----------------------------+---+
| charset-supported | N |
+----------------------------+---+
| natural-language-configured| S | SHOULD
TH34> Change to MUST be settable, since an implementation that supports more
than one natural language ought to allow the SA to change the
default.+----------------------------+---+
| generated-natural-language-| S | MAY
| supported | |
+----------------------------+---+
| document-format-default | S | MUST
+----------------------------+---+
| document-format-supported | S | SHOULD
+----------------------------+---+
| printer-is-accepting-jobs | N | Add comment: See
Enable-Printer/Disable-Printer operations
+----------------------------+---+
| queued-job-count | N |
+----------------------------+---+
| printer-message-from- | S | MUST if attr supported
| operator | |
+----------------------------+---+
| color-supported | S | MAY if attr supported
+----------------------------+---+
| reference-uri-schemes- | S | MAY if attr supported
| supported | |
+----------------------------+---+
| pdl-override-supported | N |
+----------------------------+---+
| printer-up-time | N |
+----------------------------+---+
| printer-current-time | S | MAY if attr supported
TH35> Why not MAY be settable, so the operator could correct the time if it
was wrong (or daylight savings just happened and printer wasn't changed or
the offset from Grenwich time wasn't set properly.
+----------------------------+---+
| multiple-operation-time-out| S | SHOULD if attr supported
+----------------------------+---+
| compression-supported | S | MAY
+----------------------------+---+
| job-k-octets-supported | S | SHOULD if attr supported
+----------------------------+---+
| job-impressions-supported | S | SHOULD if attr supported
+----------------------------+---+
| job-media-sheets-supported | S | SHOULD if attr supported
+----------------------------+---+
| pages-per-minute | N |
+----------------------------+---+
| pages-per-minute-color | N |
+----------------------------+---+
Set-Printer-Attributes Response:
Group 1: Operation Attributes:
Status Message: In addition to the REQUIRED status code returned in
every response, the response OPTIONALLY includes a "status-message"
(text) operation attribute.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes:
See section 3.1.7 for details on returning Unsupported Attributes.
TH36> However, for attributes that are 'not-settable', we need to add an
out-of-band value: 'not-settable' for returning in the Unsupported
Attributes group. Then add the following sentence here:
In the case of attributes that are not settable, the Printer
object returns the client-supplied attribute(s) with a substituted value of
'not-settable'. This value's syntax type is "out-of-band" and its encoding
is defined by special rules for "out-of-band" values in the "Encoding and
Transport" document [IPP-PRO]. Its value indicates that the attribute is
not settable.
Status codes:
'successful-ok'
'client-error-not-possible'
'successful-ok-ignored-or-substituted-attributes',
'successful-ok-conflicting-attributes',
'client-error-attributes-or-values-not-supported'
'client-error-conflicting-attributes'.
'client-error-attribute-read-only' .
--------------------------------------------------------------------------
Type of registration: operation
Proposed name of this operation: Cancel-Current-Job
Object Target: Printer
Specification of this attribute:
This operation allows a client to cancel the currently printing job
without having to specify the job-id or job-uri.
TH37> Since LPD has this operation and can be useful on a printer that only
has one user, its ok to have this operation. However, need to add a warning
about the race on a shared printer. Add something like:
Warning: On a shared printer, there is a race condition.
Between the time that a user issues this operation and its acceptance, the
current job might change to a different job. If the user has the access
rights to the new job, the wrong job is canceled.
TH38> Need to add the same Access Rights section as for Cancel-Job:
Access Rights: The authenticated user (see section 8.3)
performing this operation must either be the job owner or an operator or
administrator of the Printer object (see Sections 1 and 8.5). Otherwise,
the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated', or
'client-error-not-authorized' as appropriate.
Cancel-Current-Job Request:
Group 1: Operation Attributes
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: The "printer-uri" (uri) operation attribute which is the
target for this operation as described in section 3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
TH39> Add the usual access rights specification as in Cancel-Job:
Access Rights: The authenticated user (see section 8.3)
performing this operation must either be the job owner or an operator or
administrator of the Printer object (see Sections 1 and 8.5). Otherwise,
the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated', or
'client-error-not-authorized' as appropriate.
Cancel-Current-Job Response:Group 1: Operation AttributesStatus Message: In
addition to the REQUIRED status code returned in every response, the
response OPTIONALLY includes a "status-message"
(text) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
Status codes:
'successful-ok'
'client-error-not-possible'
--------------------------------------------------------------------------
Type of registration: operation
Proposed name of this operation: Shutdown-Printer
TH40> We suggest that the suffix '-Printer' be added to the name of the
operation for consistency with our other IPP operations and to clarify that
jobs are not being shutdown, only the Printer.
Object Target: PrinterSpecification of this operation: Shutdown-Printer
applies only to Printer, not to Job. This operation allows a client to shut
down a Printer. Specifically,
this operation:
- Terminates all communication with the Printer
- Disables the Printer (prevents a Printer from accepting new Jobs).
TH41> Need to add the same Access Rights section as for Pause-Printer:
Access Rights: The authenticated user (see section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
Shutdown-Printer Request:
Group 1: Operation Attributes
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: The "printer-uri" (uri) operation attribute which is the
target for this operation as described in section 3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
When: (Keyword) "when" indicates when to shutdown the printer.
TH42> Add the usual conformance sentences to the beginning of this operation
attribute:
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute and all its values.
Standard values:
'now': cancel any currently printing jobs and shut down the Printer.
'after-current': continue to accept requests other than print
requests until the currently printing Jobs finish printing.
'after-all': continue to accept all requests except print requests
until all scheduled jobs finish printing.
TH43> What is the behavior if the client omits this attribute? We suggest
'after-current', since it doesn't do any harm. So add the following
sentence:
If the client omits this attribute, the Printer assumes the
'after-current' value.
TH44> Add the following semantics:
The Printer adds the 'shutdown' value (see [ipp-mod] section
4.4.11) to its "printer-state-reasons" read-only Printer Description
attribute immediately. The Printer sets its "printer-is-accepting-jobs"
read-only Printer Description attribute to 'false' immediately, to indicate
that it is no longer accepting create requests (see [ipp-mod] section
4.4.23). All other requests continue to be accepted until the printer is
shutdown, depending on the value of the "when" operation attribute supplied
by the client.
Shutdown-Printer Response:Group 1: Operation AttributesStatus Message: In
addition to the REQUIRED status code returned in every response, the
response OPTIONALLY includes a "status-message"
(text) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
Status codes:
'successful-ok'
'client-error-not-possible'
--------------------------------------------------------------------------
Type of registration: operation
Proposed name of this operation: Backspace-Current-Job
TH45> Need a better name, something like Redo-Last-Impressions.
TH46> Can job be spaced forward too?
TH47> Is this operation useful on cut sheet printers, or it is only
roll-fed?
Object Target: Printer
Specification of this attribute:
Backspaces the currently printing job a given number of impressions. For
example, if you specify that the job is to be backspaced 10 impressions
and the 14th impression was the last buffered impression to be printed,
the job starts printing with the fifth impression. Backspace is typically
desired in a continuous forms environment for synchronizing the web after
forms run out or media change.
TH48> Need to add the same Access Rights section as for Pause-Printer:
Access Rights: The authenticated user (see section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
Backspace-Current-Job Request:
Group 1: Operation Attributes
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: The "printer-uri" (uri) operation attribute which is the
target for this operation as described in section 3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
Job Impressions: "job-impressions": the number of impressions to
backspace before continuing to print.
Backspace-Current-Job Response:
Group 1: Operation Attributes
Status Message: In addition to the REQUIRED status code returned in
every response, the response OPTIONALLY includes a "status-message"
(text) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
Status codes:
'successful-ok'
'client-error-not-possible'
--------------------------------------------------------------------------
Type of registration: operation
Proposed name of this operation: Enable-Printer
TH49> We suggest that the suffix '-Printer' be added to the name of the
operation for consistency with our other IPP operations and to clarify that
jobs are not being shutdown, only the Printer.
Object Target: Printer
Specification of this attribute:
Enable-Printer applies only to Printer, not to Job.
This operation allows a Printer to accept Jobs.
Note: Use the Disable operation to prevent a Printer from accepting Jobs.
Note: Use Enable-Printer and Disable-Printer to allow or prevent input to a
Printer. Use Pause-Printer and Resume-Printer to prevent or allow output
from the Printer.
TH50> Need to add the same Access Rights section as for Pause-Printer:
Access Rights: The authenticated user (see section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
Enable-Printer Request:
Group 1: Operation Attributes
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: The "printer-uri" (uri) operation attribute which is the
target for this operation as described in section 3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
TH51> Add:
The Printer sets the value of its
"printer-is-accepting-jobs" read-only Printer Description attribute to
'true' (see [ipp-mod] section 4.4.20), no matter what the previous value
was.
Enable-Printer Response:Group 1: Operation AttributesStatus Message: In
addition to the REQUIRED status code returned in every response, the
response OPTIONALLY includes a "status-message" (text) operation attribute
as described in sections 13 and 3.1.6.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
Status codes:
'successful-ok'
'client-error-not-possible'
--------------------------------------------------------------------------
Type of registration: operationProposed name of this operation:
Disable-Printer
TH52> We suggest that the suffix '-Printer' be added to the name of the
operation for consistency with our other IPP operations and to clarify that
jobs are not being shutdown, only the Printer.
Object Target: PrinterSpecification of this attribute:
Disable-Printer applies only to Printer, not to Job.
This operation stops a Printer from accepting Jobs. The Printer still
accepts other Operations. All previously submitted Jobs and currently
processing Jobs continue unaffected.
TH53> Add:
The Printer sets the value of its
"printer-is-accepting-jobs" read-only Printer Description attribute to
'false' (see [ipp-mod] section 4.4.20), no matter what the previous value
was.
Note: Use the Enable-Printer operation to enable a Printer to accept Jobs
again.
Note: Use Enable-Printer and Disable-Printer to allow or prevent input to a
Printer. Use Pause-Printer and Resume-Printer to prevent or allow output
from the Printer.
TH54> Need to add the same Access Rights section as for Pause-Printer:
Access Rights: The authenticated user (see section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
Disable-Printer Request:
Group 1: Operation Attributes
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.1.
Target: The "printer-uri" (uri) operation attribute which is the
target for this operation as described in section 3.1.5.
Requesting User Name: The "requesting-user-name" (name(MAX)) attribute
SHOULD be supplied by the client as described in section 8.3.
Disable-Printer Response:
Group 1: Operation Attributes
Status Message: In addition to the REQUIRED status code returned in
every response, the response OPTIONALLY includes a "status-message"
(text) operation attribute as described in sections 13 and 3.1.6.
Natural Language and Character Set: The "attributes-charset" and
"attributes-natural-language" attributes as described in section
3.1.4.2.
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes.
Status codes:
'successful-ok'
'client-error-not-possible'