(see Section 3.1.4.1).
3.1.2.3.13 Natural Language Override (NLO)
The 'text' and 'name' attributes each have two forms. One has an
implicit natural language, and the other has an explicit natural
language. The 'textWithoutLanguage' and 'textWithLanguage' are the
two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage
are the two 'name' forms. If a receiver (IPP object or IPP client)
supports an attribute with attribute syntax 'text', it MUST support
both forms in a request and a response. A sender (IPP client or IPP
object) MAY send either form for any such attribute. When a sender
sends a WithoutLanguage form, the implicit natural language is
specified in the "attributes-natural-language" operation attribute,
which all senders MUST include in every request and response.
When a sender sends a WithLanguage form, it MAY be different from the
implicit natural language supplied by the sender or it MAY be the
same. The receiver MUST treat either form equivalently.
There is an implementation decision for senders, whether to always
send the WithLanguage forms or use the WithoutLanguage form when the
attribute's natural language is the same as the request or response.
The former approach makes the sender implementation simpler. The
latter approach is more efficient on the wire and allows inter-
working with non-conforming receivers that fail to support the
WithLanguage forms. As each approach have advantages, the choice is
completely up to the implementer of the sender.
Furthermore, when a client receives a 'text' or 'name' job attribute
that it had previously supplied, that client MUST NOT expect to see
the attribute in the same form, i.e., in the same WithoutLanguage or
WithLanguage form as the client supplied when it created the job.
The IPP object is free to transform the attribute from the
WithLanguage form to the WithoutLanguage form and vice versa, as long
as the natural language is preserved. However, in order to meet this
latter requirement, it is usually simpler for the IPP object
implementation to store the natural language explicitly with the
attribute value, i.e., to store using an internal representation that
resembles the WithLanguage form.
The IPP Printer MUST copy the natural language of a job, i.e., the
value of the "attributes-natural-language" operation attribute
supplied by the client in the create operation, to the Job object as
a Job Description attribute, so that a client is able to query it.
In returning a Get-Job-Attributes response, the IPP object MAY return
one of three natural language values in the responses "attributes-
natural-language" operation attribute: (1) that requested by the
requester, (2) the natural language of the job, or (3) the configured
natural language of the IPP Printer, if the requested language is not
supported by the IPP Printer.
This "attributes-natural-language" Job Description attribute is
useful for an IPP object implementation that prints start sheets in
the language of the user who submitted the job. This same Job
Description attribute is useful to a multi-lingual operator who has
to communicate with different job submitters in different natural
languages. This same Job Description attribute is expected to be
used in the future to generate notification messages in the natural
language of the job submitter.
Early drafts of [RFC2911] contained a job-level natural language
override (NLO) for the Get-Jobs response. A job-level (NLO) is an
(unrequested) Job Attribute which then specified the implicit natural
language for any other WithoutLanguage job attributes returned in the
response for that job. Interoperability testing of early
implementations showed that no one was implementing the job-level NLO
in Get-Job responses. So the job-level NLO was eliminated from the
Get-Jobs response. This simplification makes all requests and
responses consistent in that the implicit natural language for any
WithoutLanguage 'text' or 'name' form is always supplied in the
request's or response's "attributes-natural-language" operation
attribute.
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. RFC2396 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
RFC2396 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 RFC1305. Also DHCP option 32
in RFC2132 returns the IP address of the NTP server.
2. Get the date and time at startup from a human operator