RFC 3196
Internet Printing Protocol/1.1: Implementor's Guide
3.1.3 Status codes returned by operation
This section corresponds to [RFC2911] section 3.1.6 "Operation Response Status Codes and Status Messages". This section lists all status codes once in the first operation (Print-Job). Then it lists the status codes that are different or specialized for subsequent operations under each operation.3.1.3.1 Printer Operations
3.1.3.1.1 Print-Job
The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 13 in [RFC2911] for a more complete description of each status code. For the following success status codes, the Job object has been created and the "job-id", and "job-uri" assigned and returned in the response: successful-ok: no request attributes were substituted or ignored. successful-ok-ignored-or-substituted-attributes: some supplied (1) attributes were ignored or (2) unsupported attribute syntaxes or values were substituted with supported values or were ignored. Unsupported attributes, attribute syntax's, or values MUST be returned in the Unsupported Attributes group of the response. successful-ok-conflicting-attributes: some supplied attribute values conflicted with the values of other supplied attributes and were either substituted or ignored. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response as supplied by the client. [RFC2911] section 3.1.6 Operation Status Codes and Messages states: If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 13 in [RFC2911]): 'client-error-bad-request', 'client-error- charset-not-supported', 'server-error-internal-error', 'server-
error-operation-not-supported', and 'server-error-version-not-
supported'. In this case, it MUST set the value of the
"attributes-charset" operation attribute to 'utf-8' in the error
response.
For the following error status codes, no job is created and no
"job-id" or "job-uri" is returned:
client-error-bad-request: The request syntax does not conform
to the specification.
client-error-forbidden: The request is being refused for
authorization or authentication reasons. The implementation
security policy is to not reveal whether the failure is one of
authentication or authorization.
client-error-not-authenticated: Either the request requires
authentication information to be supplied or the authentication
information is not sufficient for authorization.
client-error-not-authorized: The requester is not authorized
to perform the request on the target object.
client-error-not-possible: The request cannot be carried out
because of the state of the system. See also 'server-error-
not-accepting-jobs' status code, which MUST take precedence if
the Printer object's "printer-accepting-jobs" attribute is
'false'.
client-error-timeout: not applicable.
client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no
forwarding address is known.
client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to
process it.
client-error-request-value-too-long: the size of request
variable length attribute values, such as 'text' and 'name'
attribute syntax's, exceed the maximum length specified in
[RFC2911] for the attribute and MUST be returned in the
Unsupported Attributes Group.
supplied is not supported. The "document-format" attribute
with the unsupported value MUST be returned in the Unsupported
Attributes Group. This error SHOULD take precedence over any
other 'xxx-not-supported' error, except 'client-error-charset-
not-supported'.
client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntax's, or values are not
supported and the client supplied the "ipp-attributes-
fidelity" operation attribute with a 'true' value. They MUST
be returned in the Unsupported Attributes Group as explained
below.
client-error-uri-scheme-not-supported: not applicable.
client-error-charset-not-supported: the charset supplied in
the "attributes-charset" operation attribute is not supported.
The Printer's "configured-charset" MUST be returned in the
response as the value of the "attributes-charset" operation
attribute and used for any 'text' and 'name' attributes
returned in the error response. This error SHOULD take
precedence over any other error, unless the request syntax is
so bad that the client's supplied "attributes-charset" cannot
be determined.
client-error-conflicting-attributes: one or more supplied
attribute values conflicted with each other and the client
supplied the "ipp-attributes-fidelity" operation attribute with
a 'true' value. They MUST be returned in the Unsupported
Attributes Group as explained below.
server-error-internal-error: an unexpected condition prevents
the request from being fulfilled.
server-error-operation-not-supported: not applicable (since
Print-Job is REQUIRED).
server-error-service-unavailable: the service is temporarily
overloaded.
server-error-version-not-supported: the version in the request
is not supported. The "closest" version number supported MUST
be returned in the response.
server-error-device-error: a device error occurred while
receiving or spooling the request or document data or the IPP
Printer object can only accept one job at a time.
server-error-temporary-error: a temporary error such as a
buffer full write error, a memory overflow, or a disk full
condition occurred while receiving the request and/or the
document data.
server-error-not-accepting-jobs: the Printer object's
"printer-is-not-accepting-jobs" attribute is 'false'.
server-error-busy: the Printer is too busy processing jobs to
accept another job at this time.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
document data.
3.1.3.1.2 Print-URI
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Print-URI with the following
specializations and differences. See Section 14 for a more complete
description of each status code.
client-error-uri-scheme-not-supported: the URI scheme supplied
in the "document-uri" operation attribute is not supported and
is returned in the Unsupported Attributes group.
server-error-operation-not-supported: the Print-URI operation
is not supported.
3.1.3.1.3 Validate-Job
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Validate-Job. See Section 13 in
[RFC2911] for a more complete description of each status code.
3.1.3.1.4 Create-Job
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Create-Job with the following
specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code.
server-error-operation-not-supported: the Create-Job operation
is not supported.
client-error-multiple-document-jobs-not-supported: while the
Create-Job and Send-Document operations are supported, this
implementation doesn't support more than one document with
data.
3.1.3.1.5 Get-Printer-Attributes
All of the Print-Job status codes described in Section
3.1.3.1.1 Print-Job Response are applicable to the Get-
Printer-Attributes operation with the following
specialization's and differences. See Section 13 in [RFC2911]
for a more complete description of each status code.
For the following success status codes, the requested
attributes are returned in Group 3 in the response:
successful-ok: no operation attributes or values were
substituted or ignored (same as Print-Job) and no requested
attributes were unsupported.
successful-ok-ignored-or-substituted-attributes: The
"requested-attributes" operation attribute MAY, but NEED NOT,
be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, Group 3 is returned containing no
attributes or is not returned at all:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job,
except that no print data is involved.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since
Get-Printer-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that
no document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-busy: same as Print-Job, except the IPP object is
too busy to accept even query requests.
server-error-job-canceled: not applicable.
3.1.3.1.6 Get-Jobs
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to the Get-Jobs operation with the
following specialization's and differences. See Section 13 in
[RFC2911] for a more complete description of each status code.
For the following success status codes, the requested attributes are
returned in Group 3 in the response:
successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Get-
Printer-Attributes (see section 3.1.3.1.5).
successful-ok-conflicting-attributes: same as Get-Printer-
Attributes (see section 3.1.3.1.5).
For any error status codes, Group 3 is returned containing no
attributes or is not returned at all. The following brief error
status code descriptions contain unique information for use with
Get-Jobs operation. See section 14 for the other error status codes
that apply uniformly to all operations:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job,
except that no print data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since
Get-Jobs is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that
no document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.1.7 Pause-Printer
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Pause-Printer with the following
specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code.
For the following success status codes, the Printer object is being
stopped from scheduling jobs on all its devices.
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object has not been
stopped from scheduling jobs on all its devices.
client-error-not-possible: not applicable.
client-error-not-found: the target Printer object does not
exist.
client-error-gone: the target Printer object no longer exists
and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: the Pause-Printer
operation is not supported.
server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.1.8 Resume-Printer
All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Pause-
Printer are applicable to Resume-Printer. See Section 13 in
[RFC2911] for a more complete description of each status code.
For the following success status codes, the Printer object resumes
scheduling jobs on all its devices.
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object does not resume
scheduling jobs.
server-error-operation-not-supported: the Resume-Printer
operation is not supported.
3.1.3.1.8.1 What about Printers unable to change state due to an error condition? If, in case, the IPP printer is unable to change its state due to some problem with the actual printer device (say, it is shut down or there is a media-jam as indicated in [RFC2911]), what should be the result of the "Resume-Printer" operation? Should it still change the 'printer-state-reasons' and return success or should it fail ? The Resume-Printer operation must clear the 'paused' or 'moving-to- paused' 'printer-state-message'. The operation must return a 'successful-ok' status code.3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? If the Resume-Printer operation succeeds, what should be the value of "printer-state" and who should take care of the "printer-state" attribute value later on ? The Resume-Printer operation may change the "printer-state-reasons" value. The "printer-state" will change to one of three states: 1. 'idle' - no additional jobs and no error conditions present 2. 'processing' - job available and no error conditions present 3. current state (i.e. no change) an error condition is present (e.g. media jam) In the third case the "printer-state-reason" will be cleared by automata when it detects the error condition no longer exists. The "printer-state" will move to 'idle' or 'processing' when conditions permit. (i.e. no more error conditions)3.1.3.1.9 Purge-Printer
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response with the specialization's described for Pause- Printer are applicable to Purge-Printer. See Section 13 in [RFC2911] for a more complete description of each status code. For the following success status codes, the Printer object purges all it's jobs. successful-ok: no request attributes were substituted or ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object does not purge
any jobs.
server-error-operation-not-supported: the Purge-Printer
operation is not supported.
3.1.3.2 Job Operations
3.1.3.2.1 Send-Document
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to the Get-Printer-Attributes
operation with the following specialization's and differences. See
Section 13 in [RFC2911] for a more complete description of each
status code.
For the following success status codes, the document has been added
to the specified Job object and the job's "number-of-documents"
attribute has been incremented:
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, no document has been added to the Job
object and the job's "number-of-documents" attribute has not been
incremented:
client-error-not-possible: Same as Print-Job, except that the
Printer's "printer-is-accepting-jobs" attribute is not
involved, so that the client is able to finish submitting a job
that was created with a Create-Job operation after this
attribute has been set to 'true'. Another condition is that
the state of the job precludes Send-Document, i.e., the job has
already been closed out by the client. However, if the IPP
Printer closed out the job due to timeout, the 'client-error-
timeout' error status SHOULD be returned instead.
client-error-timeout: This request was sent after the Printer
closed the job, because it has not received a Send-Document or
Send-URI operation within the Printer's "multiple-operation-
time-out" period .
client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attributes-fidelity" operation attribute is not
involved..
server-error-operation-not-supported: the Send-Document
request is not supported.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
data.
3.1.3.2.2 Send-URI
All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Send-
Document are applicable to Send-URI. See Section 13 in [RFC2911] for
a more complete description of each status code.
client-error-uri-scheme-not-supported: the URI scheme supplied
in the "document-uri" operation attribute is not supported and
the "document-uri" attribute MUST be returned in the
Unsupported Attributes group.
server-error-operation-not-supported: the Send-URI operation is
not supported.
3.1.3.2.3 Cancel-Job
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Cancel-Job with the following
specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code.
For the following success status codes, the Job object is being
canceled or has been canceled:
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been
canceled or was previously canceled.
client-error-not-possible: The request cannot be carried out
because of the state of the Job object ('completed',
'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object
does not exist.
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and values
MUST be ignored.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: not applicable (Cancel-
Job is REQUIRED).
server-error-device-error: same as Print-Job, except no
document data is involved.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.4 Get-Job-Attributes
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Get-Job-Attributes with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code. For the following success status codes, the requested attributes are returned in Group 3 in the response: successful-ok: same as Get-Printer-Attributes (see section 3.1.3.1.5). successful-ok-ignored-or-substituted-attributes: same as Get- Printer-Attributes (see section 3.1.3.1.5). successful-ok-conflicting-attributes: same as Get-Printer- Attributes (see section 3.1.3.1.5). For the error status codes, Group 3 is returned containing no attributes or is not returned at all. client-error-not-possible: Same as Print-Job, in addition the Printer object is not accepting any requests. client-error-document-format-not-supported: not applicable. client-error-attributes-or-values-not-supported: not applicable. client-error-uri-scheme-not-supported: not applicable. client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above). client-error-conflicting-attributes: not applicable server-error-operation-not-supported: not applicable (since Get-Job-Attributes is REQUIRED). server-error-device-error: same as Print-Job, except no document data is involved. server-error-temporary-error: sane as Print-Job, except no document data is involved..
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.5 Hold-Job
All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Hold-Job with the following
specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code.
For the following success status codes, the Job object is being held
or has been held:
successful-ok: no request attributes were substituted or
ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been held
or was previously held.
client-error-not-possible: The request cannot be carried out
because of the state of the Job object ('completed',
'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object
does not exist.
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: the Hold-Job operation is
not supported.
server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.6 Release-Job
All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Hold-Job
are applicable to Release-Job. See Section 13 in [RFC2911] for a
more complete description of each status code.
server-error-operation-not-supported: the Release-Job operation
is not supported.
3.1.3.2.7 Restart-Job
All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Hold-Job
are applicable to Restart-Job. See Section 13 in [RFC2911] for a
more complete description of each status code.
server-error-operation-not-supported: the Restart-Job operation
is not supported.
3.1.3.2.7.1 Can documents be added to a restarted job?
Assume I give a Create-Job request along with a set of 5 documents.
All the documents get printed and the job state is moved to
completed. I issue a Restart-Job request on the job. Now the issue
is that, if I try to add new documents to the restarted job, will the
IPP Server permit me to do so or return "client-error-not-possible "
and again print those 5 jobs?
A job can not move to the 'completed' state until all the documents
have been processed. The 'last-document' flag indicates when the
last document for a job is being sent from the client. This is the
semantic equivalent of closing a job. No documents may be added once
a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
is moved to the 'pending' job state and restarts the beginning on the
same IPP Printer object with the same attribute values." 'number-
of-documents' is a job attribute.
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 1.18)
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes responses, the client cannot depend on getting unsupported attributes returned in the Unsupported Attributes group that the client requested, but are not supported by the IPP object. However, such unsupported requested attributes will not be returned in the Job Attributes or Printer Attributes group (since they are unsupported). Furthermore, the IPP object is REQUIRED to return the 'successful- ok-ignored-or-substituted-attributes' status code, so that the client knows that not all that was requested has been returned.3.1.5 Sending empty attribute groups
The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender not send an empty attribute group in a request or a response. However, they REQUIRE a receiver to accept an empty attribute group as equivalent to the omission of that group. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that is not supplying any Job Template attributes. Similarly, an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to be returned in a response. The [RFC2910] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them equivalently. The term "receiver" means an IPP object for a request and a client for a response. The term "sender' means a client for a request and an IPP object for a response. There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2910] contains the following paragraph: The syntax allows an xxx-attributes-tag to be present when the xxx- attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
3.2 Printer Operations
3.2.1 Print-Job operation
3.2.1.1 Flow controlling the data portion of a Print-Job request (Issue 1.22)
A paused printer, or one that is stopped due to paper out or jam or spool space full or buffer space full, may flow control the data of a Print-Job operation (at the TCP/IP layer), so that the client is not able to send all the document data. Consequently, the Printer will not return a response until the condition is changed. The Printer should not return a Print-Job response with an error code in any of these conditions, since either the printer will be resumed and/or the condition will be freed either by human intervention or as jobs print. In writing test scripts to test IPP Printers, the script must also be written not to expect a response, if the printer has been paused, until the printer is resumed, in order to work with all possible implementations.3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
An IPP client submits a small job via Print-Job. By the time the IPP printer/print server is putting together a response to the operation, the job has finished printing and been removed as an object from the print system. What should the job-state be in the response? The Model suggests that the Printer return a response before it even accepts the document content. The Job Object Attributes are returned only if the IPP object returns one of the success status codes. Then the job-state would always be "pending" or "pending-held". This issue comes up for the implementation of an IPP Printer object as a server that forwards jobs to devices that do not provide job status back to the server. If the server is reasonably certain that the job completed successfully, then it should return the job-state as 'completed'. Also the server can keep the job in its "job history" long after the job is no longer in the device. Then a user could query the server and see that the job was in the 'completed' state and completed as specified by the jobs "time-at-completed" time, which would be the same as the server submitted the job to the device.
An alternative is for the server to respond to the client before or while sending the job to the device, instead of waiting until the server has finished sending the job to the device. In this case, the server can return the job's state as 'pending' with the 'job- outgoing' value in the job's "job-state-reasons" attribute. If the server doesn't know for sure whether the job completed successfully (or at all), it could return the (out-of-band) 'unknown' value. On the other hand, if the server is able to query the device and/or setup some sort of event notification that the device initiates when the job makes state transitions, then the server can return the current job state in the Print-Job response and in subsequent queries because the server knows what the job state is in the device (or can query the device). All of these alternatives depend on implementation of the server and the device.3.2.2 Get-Printer-Attributes operation
If a Printer supports the "printer-make-and-model" attribute and returns the .INF file model name of the printer in that attribute, the Microsoft client will automatically install the correct driver (if available). Clients which poll periodically for printer status or queued-job- count should use the "requested-attributes" operation attribute to limit the scope of the query in order to save Printer and network resources.3.2.3 Get-Jobs operation
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 1.39)?
In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there too, and if it's not present what should the IPP printer do? [RFC2911] Section 8.3 describes the various cases of "requesting- user-name" being present or not for any operation. If the client does not supply a value for "requesting-user-name", the printer MUST assume that the client is supplying some anonymous name, such as "anonymous".
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
When using the Get-Jobs operation a client implementer might choose to limit the number of jobs that the client shows on the first screenful. For example, if its UI can only display 50 jobs, it can defend itself against a printer that would otherwise return 500 jobs, perhaps taking a long time on a slow dial-up line. The client can then go and ask for a larger number of jobs in the background, while showing the user the first 50 jobs. Since the job history is returned in reverse order, namely the most recently completed jobs are returned first, the user is most likely interested in the first jobs that are returned. Limiting the number of jobs may be especially useful for a client that is requesting 'completed' jobs from a printer that keeps a long job history. Clients that don't mind sometimes getting very large responses, can omit the "limit" attribute in their Get-Jobs requests.3.2.4 Create-Job operation
A Printer may respond to a Create-Job operation with "job-state" 'pending' or 'pending-held' and " job-state-reason" 'job-data- insufficient' to indicate that operation has been accepted by the Printer, but the Printer is expecting additional document data before it can move the job into the 'processing' state. Alternatively, it may respond with "job-state" 'processing' and "job-state-reason" 'job-incoming' to indicate that the Create-Job operation has been accepted by the Printer, but the Printer is expecting additional Send-Document and/or Send-URI operations and/or is accessing/accepting document data. The second alternative is for non-spooling Printers that don't implement the 'pending' state. Should the server wait for the "last-document" operation attribute set to 'true' before starting to "process" the job? It depends on implementation. Some servers spool the entire job, including all document data, before starting to process, so such an implementation would wait for the "last-document" before starting to process the job. If the time-out occurs without the "last-document", then the server takes one of the indicated actions in section 3.3.1 in the [RFC2911] document. Other servers will start to process document data as soon as they have some. These are the so-called "non-spooling" printers. Currently, there isn't a way for a client to determine whether the Printer will spool all the data or will start to process (and print) as soon as it has some data.
3.3 Job Operations
3.3.1 Validate-Job
The Validate-Job operation has been designed so that its implementation may be a part of the Print-Job operation. Therefore, requiring Validate-Job is not a burden on implementers. Also it is useful for client's to be able to count on its presence in all conformance implementations, so that the client can determine before sending a long document, whether the job will be accepted by the IPP Printer or not.3.3.2 Restart-Job
The Restart-Job operation allows the reprocessing of a completed job. Some jobs store the document data on the printer. Jobs created using the Print-Job operation are an example. It is required that the printer retains the job data after the job has moved to a 'completed state' in order for the Restart-Job operation to succeed. Some jobs contain only a reference to the job data. A job created using the Print-URI is an example of such a job. When the Restart- Job operation is issued the job is reprocessed. The job data MUST be retrieved again to print the job. It is possible that a job fails while attempting to access the print data. When such a job is the target of a Restart-Job the Printer SHALL attempt to retrieve the job data again.4 Object Attributes
4.1 Attribute Syntax's
4.1.1 The 'none' value for empty sets (Issue 1.37)
[RFC2911] states that the 'none' value should be used as the value of a 1setOf when the set is empty. In most cases, sets that are potentially empty contain keywords so the keyword 'none' is used, but for the 3 finishings attributes, the values are enums and thus the empty set is represented by the enum 3. Currently there are no other attributes with 1setOf values, which can be empty and can contain values that are not keywords. This exception requires special code and is a potential place for bugs. It would have been better if we had chosen an out-of-band value, either "no-value" or some new value, such as 'none'. Since we didn't, implementations have to deal with the different representations of 'none', depending on the attribute syntax.
4.1.2 Multi-valued attributes (Issue 1.31)
What is the attribute syntax for a multi-valued attribute? Since some attributes support values in more than one data type, such as "media", "job-hold-until", and "job-sheets", IPP semantics associate the attribute syntax with each value, not with the attribute as a whole. The protocol associates the attribute syntax tag with each value. Don't be fooled, just because the attribute syntax tag comes before the attribute keyword. All attribute values after the first have a zero length attribute keyword as the indication of a subsequent value of the same attribute.4.1.3 Case Sensitivity in URIs (issue 1.6)
IPP client and server implementations must be aware of the diverse uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and Host names as case insensitive but reminds us that the rest of the URL may well demonstrate case sensitivity. When creating URL's for fields where the choice is completely arbitrary, it is probably best to select lower case. However, this cannot be guaranteed and implementations MUST NOT rely on any fields being case-sensitive or case-insensitive in the URL beyond the URL scheme and host name fields. The reason that the IPP specification does not make any restrictions on URIs, is so that implementations of IPP may use off-the-shelf components that conform to the standards that define URIs, such as RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these specifications for rules of matching, comparison, and case- sensitivity. It is also recommended that System Administrators and implementations avoid creating URLs for different printers that differ only in their case. For example, don't have Printer1 and printer1 as two different IPP Printers. Example of equivalent URI's http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http:/ABC.com:/%7esmith/home.html Example of equivalent URI's using the IPP scheme ipp://abc.com:631/~smith/home.html
ipp://ABC.com/%7Esmith/home.html
http:/ABC.com:631/%7esmith/home.html
The HTTP/1.1 specification [RFC2616] contains more details on
comparing URLs.
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
that have two components. The first component is the 'language'
component that can contain up to 63 octets. The second component is
the 'text' or 'name' component. The maximum length of these are 1023
octets and 255 octets respectively. The definition of attributes
with either syntax may further restrict the length (e.g., printer-
name (name(127))).
The length of the 'language' component has no effect on the allowable
length of 'text' in 'textWithLanguage' or the length of 'name' in
'nameWithLanguage'
4.2 Job Template Attributes
4.2.1 multiple-document-handling(type2 keyword)
4.2.1.1 Support of multiple document jobs
IPP/1.0 is silent on which of the four effects an implementation
would perform if it supports Create-Job, but does not support
"multiple-document-handling" or multiple documents per job. IPP/1.1
was changed so that a Printer could support Create-Job without having
to support multiple document jobs. The "multiple-document-jobs-
supported" (boolean) Printer description attribute was added to
IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
supported' status code for a Printer to indicate whether or not it
supports multiple document jobs, when it supports the Create-Job
operation. Also IPP/1.1 was clarified that the Printer MUST support
the "multiple-document-handling" (type2 keyword) Job Template
attribute with at least one value if the Printer supports multiple
documents per job.
4.3 Job Description Attributes
4.3.1 Getting the date and time of day
The "date-time-at-creation", "date-time-at-processing", and "date-
time-at-completed" attributes are returned as dateTime syntax. These
attributes are OPTIONAL for a Printer to support. However, there are
various ways for a Printer to get the date and time of day. Some
suggestions:
1. A Printer can get time from an NTP timeserver if there's one
reachable on the network . See RFC 1305. Also DHCP option 32
in RFC 2132 returns the IP address of the NTP server.
2. Get the date and time at startup from a human operator
3. Have an operator set the date and time using a web
administrative interface
4. Get the date and time from incoming HTTP requests, though the
problems of spoofing need to be considered. Perhaps comparing
several HTTP requests could reduce the chances of spoofing.
5. Internal date time clock battery driven.
6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
4.4 Printer Description Attributes
4.4.1 queued-job-count (integer(0:MAX))
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
The reason that "queued-job-count" is RECOMMENDED, is that some
clients look at that attribute alone when summarizing the status of a
list of printers, instead of doing a Get-Jobs to determine the number
of jobs in the queue. Implementations that fail to support the
"queued-job-count" will cause that client to display 0 jobs when
there are actually queued jobs.
We would have made it a REQUIRED Printer attribute, but some
implementations had already been completed before the issue was
raised, so making it a SHOULD was a compromise.
4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
(Issue 1.15)?
The "queued-job-count" is not a good measure of how busy the printer
is when there are held jobs. A future registration could be to add a
"held-job-count" (or an "active-job-count") Printer Description
attribute if experience shows that such an attribute (combination) is
needed to quickly indicate how busy a printer really is.
4.4.2 printer-current-time (dateTime)
A Printer implementation MAY support this attribute by obtaining the date and time by any number of implementation-dependent means at startup or subsequently. Examples include: 1. an internal date time clock, 2. from the operator at startup using the console, 3. from an operator using an administrative web page, 4. from HTTP headers supplied in client requests, 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" 6. from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132] that returns the IP address of the NTP server. If an implementation supports this attribute by obtaining the current time from the network (at startup or later), but the time is not available, then the implementation MUST return the value of this attribute using the out-of-band 'no-value' meaning not configured. See the beginning of section 4.1. Since the new "date-and-time-at-xxx" Job Description attributes refer to the "printer-current-time", they will be covered also.4.4.3 Printer-uri
Must the operational attribute for printer-uri match one of the values in "printer-uri-supported"? A forgiving printer implementation would not reject the operation. But the implementation has its rights to reject a printer or job operation if the operational attribute printer-uri is not a value of the printer-uri-supported. The printer might not be improperly configured. The request obviously reached the printer. The printer could treat the printer-uri as the logical equivalent of a value in the printer-uri-supported. It would be implementation dependent for which value, and associated security policy, would apply. This does also apply to a job object specified with a printer-uri and job-id, or with a job-uri. See section 4.1.3 for how to compare URI's.
(next page on part 5)
