 |
|
|
 |
|
|
|
|
RFC Index
rfc3196
Network Working Group T. Hastings
Request for Comments: 3196 C. Manros
Obsoletes: 2639 P. Zehler
Category: Informational Xerox Corporation
C. Kugler
IBM Printing Systems Co
H. Holst
i-data Printing Systems
November 2001
Internet Printing Protocol/1.1: Implementor's Guide
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document is one of a set of documents, which together describe
all aspects of a new Internet Printing Protocol (IPP).
Table of Contents
1 Introduction................................................... 4
1.1 Conformance language........................................ 5
1.2 Other terminology........................................... 6
1.3 Issues Raised from Interoperability Testing Events.......... 6
2 IPP Objects.................................................... 6
3 IPP Operations................................................. 7
3.1 Common Semantics............................................ 7
3.1.1 Summary of Operation Attributes............................ 8
3.1.2 Suggested Operation Processing Steps for IPP Objects....... 16
3.1.2.1 Suggested Operation Processing Steps for all Operations. 17
3.1.2.1.1 Validate version number............................... 18
3.1.2.1.2 Validate operation identifier......................... 20
3.1.2.1.3 Validate the request identifier....................... 20
3.1.2.1.4 Validate attribute group and attribute presence and
order................................................. 20
3.1.2.1.4.1 Validate the presence and order of attribute groups. 20
3.1.2.1.4.2 Ignore unknown attribute groups in the expected
position............................................ 21
Hastings, et al. Informational [Page 1]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.2.1.4.3 Validate the presence of a single occurrence of
required Operation attributes....................... 21
3.1.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................ 29
3.1.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................ 33
3.1.2.2 Suggested Additional Processing Steps for Operations
that Create/Validate Jobs and Add Documents............. 37
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
3.1.2.2.3 Validate the values of the Job Template attributes.... 38
3.1.2.3 Algorithm for job validation............................ 39
3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
3.1.2.3.2 Decide whether to REJECT the request.................. 46
3.1.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes.................................. 48
3.1.2.3.4 Create the Job object with attributes to support...... 48
3.1.2.3.5 Return one of the success status codes................ 50
3.1.2.3.6 Accept appended Document Content...................... 50
3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
3.1.2.3.8 Completing the Job.................................... 50
3.1.2.3.9 Destroying the Job after completion................... 51
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
3.1.2.3.11 Character set code conversion support................. 51
3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?....... ....................... 52
3.1.2.3.13 Natural Language Override (NLO)....................... 53
3.1.3 Status codes returned by operation......................... 55
3.1.3.1 Printer Operations...................................... 55
3.1.3.1.1 Print-Job............................................. 55
3.1.3.1.2 Print-URI............................................. 58
3.1.3.1.3 Validate-Job.......................................... 58
3.1.3.1.4 Create-Job............................................ 58
3.1.3.1.5 Get-Printer-Attributes................................ 59
3.1.3.1.6 Get-Jobs.............................................. 60
3.1.3.1.7 Pause-Printer......................................... 61
3.1.3.1.8 Resume-Printer........................................ 62
3.1.3.1.8.1 What about Printers unable to change state due to
an error condition?................................. 63
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
3.1.3.1.9 Purge-Printer......................................... 63
3.1.3.2 Job Operations.......................................... 64
3.1.3.2.1 Send-Document......................................... 64
3.1.3.2.2 Send-URI.............................................. 65
3.1.3.2.3 Cancel-Job............................................ 65
3.1.3.2.4 Get-Job-Attributes.................................... 67
3.1.3.2.5 Hold-Job.............................................. 68
3.1.3.2.6 Release-Job........................................... 69
Hastings, et al. Informational [Page 2]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.3.2.7 Restart-Job........................................... 69
3.1.3.2.7.1 Can documents be added to a restarted job?.......... 69
3.1.4 Returning unsupported attributes in Get-Xxxx responses
(Issue 1.18)............................................... 70
3.1.5 Sending empty attribute groups............................. 70
3.2 Printer Operations.......................................... 71
3.2.1 Print-Job operation........................................ 71
3.2.1.1 Flow controlling the data portion of a Print-Job
request (Issue 1.22).................................... 71
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
3.2.2 Get-Printer-Attributes operation........................... 72
3.2.3 Get-Jobs operation......................................... 72
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
(Issue 1.39)?.......................................... 72
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
operation?.............................................. 73
3.2.4 Create-Job operation....................................... 73
3.3 Job Operations.............................................. 74
3.3.1 Validate-Job............................................... 74
3.3.2 Restart-Job................................................ 74
4 Object Attributes.............................................. 74
4.1 Attribute Syntax's.......................................... 74
4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
4.2 Job Template Attributes..................................... 76
4.2.1 multiple-document-handling(type2 keyword).................. 76
4.2.1.1 Support of multiple document jobs....................... 76
4.3 Job Description Attributes.................................. 76
4.3.1 Getting the date and time of day........................... 76
4.4 Printer Description Attributes.............................. 77
4.4.1 queued-job-count (integer(0:MAX)).......................... 77
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
4.4.1.2 Is "queued-job-count" a good measure of how busy a
printer is (Issue 1.15)?................................ 77
4.4.2 printer-current-time (dateTime)............................ 78
4.4.3 Printer-uri................................................ 78
4.5 Empty Jobs.................................................. 79
5 Directory Considerations....................................... 79
5.1 General Directory Schema Considerations..................... 79
5.2 IPP Printer with a DNS name................................. 79
6 Security Considerations........................................ 80
6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32)........................... 80
7 Encoding and Transport......................................... 81
7.1 General Headers............................................. 83
7.2 Request Headers............................................ 84
Hastings, et al. Informational [Page 3]
RFC 3196 Internet Printing Protocol/1.1 November 2001
7.3 Response Headers............................................ 86
7.4 Entity Headers............................................. 87
7.5 Optional support for HTTP/1.0............................... 88
7.6 HTTP/1.1 Chunking........................................... 88
7.6.1 Disabling IPP Server Response Chunking..................... 88
7.6.2 Warning About the Support of Chunked Requests.............. 88
8 References..................................................... 89
9 Authors' Addresses............................................. 91
10 Description of the Base IPP Documents.......................... 94
11 Full Copyright Statement....................................... 96
Tables
Table 1 - Summary of Printer operation attributes that sender MUST
supply ................................................. 8
Table 2 - Summary of Printer operation attributes that sender MAY
supply ................................................. 10
Table 3 - Summary of Job operation attributes that sender MUST
supply.................................................. 12
Table 4 - Summary of Job operation attributes that sender MAY
supply.................................................. 14
Table 5 - Printer operation response attributes................... 16
Table 6 - Examples of validating IPP version...................... 19
Table 7 - Rules for validating single values X against Z.......... 40
1. Introduction
IPP is an application level protocol that can be used for distributed
printing using Internet tools and technologies. This document
contains information that supplements the IPP Model and Semantics
[RFC2911] and the IPP Transport and Encoding [RFC2910] documents. It
is intended to help implementers understand IPP/1.1, as well as
IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may
assist them in the design of their client and/or IPP object
implementation. For example, a typical order of processing requests
is given, including error checking. Motivation for some of the
specification decisions is also included.
This document obsoletes RFC 2639 which was the Implementor's Guide
for IPP/1.0. The IPP Implementor's Guide (IIG) (this document)
contains information that supplements the IPP Model and Semantics
[RFC2911] and the IPP Transport and Encoding [RFC2910] documents.
This document is just one of a suite of documents that fully define
IPP. The base set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC2568]
Hastings, et al. Informational [Page 4]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementor's Guide (this
document)
Mapping between LPD and IPP Protocols [RFC2569]
See section 10 for a description of these base IPP documents. Anyone
reading these documents for the first time is strongly encouraged to
read the IPP documents in the above order.
As such the information in this document is not part of the formal
specification of IPP/1.1. Instead information is presented to help
implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565,
RFC2566], including some of the motivation for decisions taken by the
committee in developing the specification. Some of the
implementation considerations are intended to help implementers
design their client and/or IPP object implementations. If there are
any contradictions between this document and [RFC2911] or [RFC2910],
those documents take precedence over this document.
Platform-specific implementation considerations will be included in
this guide as they become known.
Note: In order to help the reader of the IIG and the IPP Model and
Semantics document, the sections in this document parallel the
corresponding sections in the Model document and are numbered the
same for ease of cross reference. The sections that correspond to
the IPP Transport and Encoding are correspondingly offset.
1.1 Conformance language
Usually, this document does not contain the terminology MUST, MUST
NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
However, when those terms do appear in this document, their intent is
to repeat what the [RFC2911] and [RFC2910] documents require and
allow, rather than specifying additional conformance requirements.
These terms are defined in section 12 on conformance terminology in
[RFC2911], most of which is taken from RFC 2119 [RFC2119].
Implementers should read section 12 (APPENDIX A) in [RFC2911] in
order to understand these capitalized words. The words MUST, MUST
NOT, and REQUIRED indicate what implementations are required to
support in a client or IPP object in order to be conformant to
[RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is
merely allowed as an implementer option. The verbs SHOULD and SHOULD
NOT indicate suggested behavior, but which is not required or
disallowed, respectively, in order to conform to the specification.
Hastings, et al. Informational [Page 5]
RFC 3196 Internet Printing Protocol/1.1 November 2001
1.2 Other terminology
This document uses other terms, such as "attributes", "operation",
and "Printer" as defined in [RFC2911] section 12. In addition, the
term "sender" refers to the client that sends a request or an IPP
object that returns a response. The term "receiver" refers to the
IPP object that receives a request and to a client that receives a
response.
1.3 Issues Raised from Interoperability Testing Events
The IPP WG has conducted three open Interoperability Testing Events.
The first one was held in September 1998, the second one was held in
March 1999, and the third one was held in October 2000. See the
summary reports in:
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
The issues raised from the first Interoperability Testing Event are
numbered 1.n in this document and have been incorporated into
"IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
Transport" [RFC2565] documents. However, some of the discussion is
left here in the Implementor's Guide to help understanding.
The issues raised from the second Interoperability Testing Event are
numbered 2.n in this document have been incorporated into "IPP/1.1
Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
Transport" [RFC2910] documents. However, some of the discussion is
left here in the Implementor's Guide to help understanding.
The issues raised from the third Interoperability Testing Event are
numbered 3.n in this document and are described in:
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
Off3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
Off3.doc
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
Off3.txt
Hastings, et al. Informational [Page 6]
RFC 3196 Internet Printing Protocol/1.1 November 2001
2. IPP Objects
The term "client" in IPP is intended to mean any client that issues
IPP operation requests and accepts IPP operation responses, whether
it be a desktop or a server. In other words, the term "client" does
not just mean end-user clients, such as those associated with
desktops.
The term "IPP Printer" in IPP is intended to mean an object that
accepts IPP operation requests and returns IPP operation responses,
whether implemented in a server or a device. An IPP Printer object
MAY, if implemented in a server, turn around and forward received
jobs (and other requests) to other devices and print
servers/services, either using IPP or some other protocol.
3 IPP Operations
This section corresponds to Section 3 "IPP Operations" in the
IPP/1.1 Model and Semantics document [RFC2911].
3.1 Common Semantics
This section discusses semantics common to all operations.
Hastings, et al. Informational [Page 7]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.1 Summary of Operation Attributes
Table 1 - Summary of Printer operation attributes that sender MUST
supply
Printer Operations
Requests Responses
Operation PJ, PU CJ GPA GJ PP, All
Attributes VJ (O) (O) (R) (R) RP, Operations
(R) PP
(O+)
Operation parameters--REQUIRED to be supplied by the sender:
operation-id R R R R R R
status-code R
request-id R R R R R R R
version-number R R R R R R R
Operation attributes--REQUIRED to be supplied by the sender:
attributes- R R R R R R R
charset
attributes- R R R R R R R
natural-
language
document-uri R
job-id*
job-uri*
Hastings, et al. Informational [Page 8]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Printer Operations
Requests Responses
Operation PJ, PU CJ GPA GJ PP, All
Attributes VJ (O) (O) (R) (R) RP, Operations
(R) PP
(O+)
last-document
printer-uri R R R R R R
Operation attributes--RECOMMENDED to be supplied by the
sender:
job-name R R R
requesting-user- R R R R R R
name
Legend:
PJ, VJ: Print-Job, Validate-Job
PU: Print-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
Hastings, et al. Informational [Page 9]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Table 2 - Summary of Printer operation attributes that sender MAY
supply
Printer Operations
Requests Respon-
ses
Operation Attributes PJ, PU CJ GPA GJ PP, All
VJ (O) (O) (R) (R) RP, Opera
(R) PP tions
(O+)
Operation attributes--OPTIONAL to be supplied by the sender:
status-message O
detailed-status- O
message
document-access- O**
error
compression R R
document-format R R R
document-name O O
document-natural- O O
language
ipp-attribute- R R R
fidelity
job-impressions O O O
job-k-octets O O O
job-media-sheets O O O
Hastings, et al. Informational [Page 10]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Printer Operations
Requests Respon-
ses
Operation Attributes PJ, PU CJ GPA GJ PP, All
VJ (O) (O) (R) (R) RP, Opera
(R) PP tions
(O+)
limit R
message
my-jobs R
requested-attributes R R
which-jobs R
Legend:
PJ, VJ: Print-Job, Validate-Job
PU: Print-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Print-URI response only.
Hastings, et al. Informational [Page 11]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Table 3 - Summary of Job operation attributes that sender MUST supply
Job Operations
Requests Responses
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
Operation parameters--REQUIRED to be supplied by the sender:
operation-id R R R R R
status-code R
request-id R R R R R R
version-number R R R R R R
Operation attributes--REQUIRED to be supplied by the sender:
attributes-charset R R R R R R
attributes-natural- R R R R R R
language
document-uri R
job-id* R R R R R
job-uri* R R R R R
last-document R R
printer-uri R R R R R
Operation attributes--RECOMMENDED to be supplied by the sender:
job-name
Hastings, et al. Informational [Page 12]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Job Operations
Requests Responses
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
requesting-user- R R R R R
name
Legend:
SD: Send-Document
SU: Send-URI
CJ: Cancel-Job
GJA: Get-Job-Attributes
HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.
Hastings, et al. Informational [Page 13]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Table 4 - Summary of Job operation attributes that sender MAY supply
Job Operations
Requests Responses
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
Operation attributes--OPTIONAL to be supplied by the sender:
status-message O
detailed-status- O
message
document-access- O**
error
compression R R
document-format R R
document-name O O
document-natural- O O
language
ipp-attribute-
fidelity
job-impressions
job-k-octets
job-media-sheets
Hastings, et al. Informational [Page 14]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Job Operations
Requests Responses
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
limit
message O O O
job-hold-until R
my-jobs
requested- R
attributes
which-jobs
Legend:
SD: Send-Document
SU: Send-URI
CJ: Cancel-Job
GJA: Get-Job-Attributes
HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Send-URI operation only
Hastings, et al. Informational [Page 15]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Table 5 - Printer operation response attributes
Printer Operations
Response
Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP,
Attributes SD (O) SU (O) (R) RP, PP
(O+)
job-uri R R R
job-id R R R
job-state R R R
job-state- R+ R+ R+
reasons
number-of- O O O
intervening-
jobs
document- O
access-
error+
Legend:
PJ, SJ: Print-Job, Send-Document
VJ: Validate-Job
PU, SU: Print-URI, Send-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
3.1.2 Suggested Operation Processing Steps for IPP Objects
This section suggests the steps and error checks that an IPP object
MAY perform when processing requests and returning responses. An IPP
object MAY perform some or all of the error checks. However, some
Hastings, et al. Informational [Page 16]
RFC 3196 Internet Printing Protocol/1.1 November 2001
implementations MAY choose to be more forgiving than the error checks
shown here, in order to be able to accept requests from non-
conforming clients. Not performing all of these error checks is a
so-called "forgiving" implementation. On the other hand, clients
that successfully submit requests to IPP objects that do perform all
the error checks will be more likely to be able to interoperate with
other IPP object implementations. Thus an implementer of an IPP
object needs to decide whether to be a "forgiving" or a "strict"
implementation. Therefore, the error status codes returned may
differ between implementations. Consequentially, client SHOULD NOT
expect exactly the error code processing described in this section.
When an IPP object receives a request, the IPP object either accepts
or rejects the request. In order to determine whether or not to
accept or reject the request, the IPP object SHOULD execute the
following steps. The order of the steps may be rearranged and/or
combined, including making one or multiple passes over the request.
A client MUST supply requests that would pass all of the error checks
indicated here in order to be a conforming client. Therefore, a
client SHOULD supply requests that are conforming, in order to avoid
being rejected by some IPP object implementations and/or risking
different semantics by different implementations of forgiving
implementations. For example, a forgiving implementation that
accepts multiple occurrences of the same attribute, rather than
rejecting the request might use the first occurrences, while another
might use the last occurrence. Thus such a non-conforming client
would get different results from the two forgiving implementations.
In the following, processing continues step by step until a "RETURNS
the xxx status code ..." statement is encountered. Error returns are
indicated by the verb: "REJECTS". Since clients have difficulty
getting the status code before sending all of the document data in a
Print-Job request, clients SHOULD use the Validate-Job operation
before sending large documents to be printed, in order to validate
whether the IPP Printer will accept the job or not.
It is assumed that security authentication and authorization has
already taken place at a lower layer.
3.1.2.1 Suggested Operation Processing Steps for all Operations
This section is intended to apply to all operations. The next
section contains the additional steps for the Print-Job, Validate-
Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
that create jobs, adds documents, and validates jobs.
Hastings, et al. Informational [Page 17]
RFC 3196 Internet Printing Protocol/1.1 November 2001
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v err
3.1.2.1.1 <Validate version> --> server-error-version-not-
supported
ok|
v err
3.1.2.1.2 <Validate operation> --> server-error-operation-not-
supported
ok|
v err
3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
3.1.2.1.4.2 <of attributes>
ok|
v err
3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
<of operation attr>
ok|
v err
3.1.2.1.5 <Validate values of> --> client-error-bad-request
<operation attrs> client-error-request-value-
too-long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.1.5 <Validate values> --> client-error-bad-request
<with supported values> client-error-charset-not-
supported
ok| client-error-attributes-or-
values-
| not-supported
v err
3.1.2.1.6 <Validate optionally> --> client-error-bad-request
<operation attr> client-error-natural-language-
not-supported
| client-error-request-value-
too-long
| client-error-attributes-or-
values-not-supported
3.1.2.1.1 Validate version number
Every request and every response contains the "version-number"
attribute. The value of this attribute is the major and minor
version number of the syntax and semantics that the client and IPP
object is using, respectively. The "version-number" attribute
Hastings, et al. Informational [Page 18]
RFC 3196 Internet Printing Protocol/1.1 November 2001
remains in a fixed position across all future versions so that all
clients and IPP object that support future versions can determine
which version is being used. The IPP object checks to see if the
major version number supplied in the request is supported. If not,
the Printer object REJECTS the request and RETURNS the 'server-
error-version-not-supported' status code in the response. The IPP
object returns in the "version-number" response attribute the major
and minor version for the error response. Thus the client can learn
at least one major and minor version that the IPP object supports.
The IPP object is encouraged to return the closest version number to
the one supplied by the client.
The checking of the minor version number is implementation dependent,
however if the client-supplied minor version is explicitly supported,
the IPP object MUST respond using that identical minor version
number. If the major version number matches, but the minor version
number does not, the Printer SHOULD accept and attempt to process the
request, or MAY reject the request and return the 'server-error-
version-not-supported' status code. In all cases, the Printer MUST
return the nearest version number that it supports. For example,
suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
The following responses are conforming:
Table 6 - Examples of validating IPP version
Client supplies Printer Accept Request? Printer returns
1.0 yes (SHOULD) 1.1
1.0 no (SHOULD NOT) 1.1
1.1 yes (MUST) 1.1
1.2 yes (MUST) 1.2
1.3 yes (SHOULD) 1.2
1.3 no (SHOULD NOT) 1.2
It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
so that they can interoperate with either client implementations.
Some implementations may allow an Administrator to explicitly disable
support for one or the other by setting the "ipp-versions-supported"
Printer description attribute.
Hastings, et al. Informational [Page 19]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Likewise, it is advantageous for clients to support both versions to
allow interoperability with new and legacy Printers.
3.1.2.1.2 Validate operation identifier
The Printer object checks to see if the "operation-id" attribute
supplied by the client is supported as indicated in the Printer
object's "operations-supported" attribute. If not, the Printer
REJECTS the request and returns the 'server-error-operation-not-
supported' status code in the response.
3.1.2.1.3 Validate the request identifier
The Printer object SHOULD NOT check to see if the "request-id"
attribute supplied by the client is in range: between 1 and 2**31 - 1
(inclusive), but copies all 32 bits.
Note: The "version-number", "operation-id", and the "request-id"
parameters are in fixed octet positions in the IPP/1.1 encoding. The
"version-number" parameter will be the same fixed octet position in
all versions of the protocol. These fields are validated before
proceeding with the rest of the validation.
3.1.2.1.4 Validate attribute group and attribute presence and order
The order of the following validation steps depends on
implementation.
3.1.2.1.4.1 Validate the presence and order of attribute groups
Client requests and IPP object responses contain attribute groups
that Section 3 requires to be present and in a specified order. An
IPP object verifies that the attribute groups are present and in the
correct order in requests supplied by clients (attribute groups
without an * in the following tables).
If an IPP object receives a request with (1) required attribute
groups missing, or (2) the attributes groups are out of order, or (3)
the groups are repeated, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' status code. For example, it
is an error for the Job Template Attributes group to occur before the
Operation Attributes group, for the Operation Attributes group to be
omitted, or for an attribute group to occur more than once, except in
the Get-Jobs response.
Since this kind of attribute group error is most likely to be an
error detected by a client developer rather than by a customer, the
IPP object NEED NOT return an indication of which attribute group was
Hastings, et al. Informational [Page 20]
RFC 3196 Internet Printing Protocol/1.1 November 2001
in error in either the Unsupported Attributes group or the Status
Message. Also, the IPP object NEED NOT find all attribute group
errors before returning this error.
3.1.2.1.4.2 Ignore unknown attribute groups in the expected position
Future attribute groups may be added to the specification at the end
of requests just before the Document Content and at the end of
response, except for the Get-Jobs response, where it maybe there or
before the first job attributes returned. If an IPP object receives
an unknown attribute group in these positions, it ignores the entire
group, rather than returning an error, since that group may be a new
group in a later minor version of the protocol that can be ignored.
(If the new attribute group cannot be ignored without confusing the
client, the major version number would have been increased in the
protocol document and in the request). If the unknown group occurs
in a different position, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' status code.
Clients also ignore unknown attribute groups returned in a response.
Note: By validating that requests are in the proper form, IPP
objects force clients to use the proper form which, in turn,
increases the chances that customers will be able to use such clients
from multiple vendors with IPP objects from other vendors.
3.1.2.1.4.3 Validate the presence of a single occurrence of required
Operation attributes
Client requests and IPP object responses contain Operation attributes
that [RFC2911] Section 3 requires to be present. Attributes within a
group may be in any order, except for the ordering of target,
charset, and natural languages attributes. These attributes MUST be
first, and MUST be supplied in the following order: charset, natural
language, and then target. An IPP object verifies that the
attributes that Section 4 requires to be supplied by the client have
been supplied in the request (attributes without an * in the
following tables). An asterisk (*) indicates groups and Operation
attributes that the client may omit in a request or an IPP object may
omit in a response.
If an IPP object receives a request with required attributes missing
or repeated from a group or in the wrong position, the behavior of
the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
implementations are:
REJECTS the request and RETURNS the 'client-error-bad-request'
status code
Hastings, et al. Informational [Page 21]
RFC 3196 Internet Printing Protocol/1.1 November 2001
accepts the request and uses the first occurrence of the attribute
no matter where it is
accepts the request and uses the last occurrence of the attribute
no matter where it is
accept the request and assume some default value for the missing
attribute
Therefore, client MUST send conforming requests, if they want to
receive the same behavior from all IPP object implementations. For
example, it is an error for the "attributes-charset" or "attributes-
natural-language" attribute to be omitted in any operation request,
or for an Operation attribute to be supplied in a Job Template group
or a Job Template attribute to be supplied in an Operation Attribute
group in a create request. It is also an error to supply the
"attributes-charset" attribute twice.
Since these kinds of attribute errors are most likely to be detected
by a client developer rather than by a customer, the IPP object NEED
NOT return an indication of which attribute was in error in either
the Unsupported Attributes group or the Status Message. Also, the
IPP object NEED NOT find all attribute errors before returning this
error.
The following tables list all the attributes for all the operations
by attribute group in each request and each response. The order of
the groups is the order that the client supplies the groups as
specified in [RFC2911] Section 3. The order of the attributes within
a group is arbitrary, except as noted for some of the special
operation attributes (charset, natural language, and target). The
tables below use the following notation:
R indicates a REQUIRED attribute or operation that an IPP
object MUST support
O indicates an OPTIONAL attribute or operation that an IPP
object NEED NOT support
* indicates that a client MAY omit the attribute in a request
and that an IPP object MAY omit the attribute in a response.
The absence of an * means that a client MUST supply the
attribute in a request and an IPP object MUST supply the
attribute in a response.
+ indicates that this is not a IPP/1.0 operation, but is only
a part of IPP/1.1 and future versions of IPP.
Hastings, et al. Informational [Page 22]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Operation Requests
The tables below show the attributes in their proper attribute groups
for operation requests:
Note: All operation requests contain "version-number", "operation-
id", and "request-id" parameters.
Print-Job Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2911] Section 4.2)
Group 3: Document Content (R)
<document content>
Validate-Job Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2911] Section 4.2)
Hastings, et al. Informational [Page 23]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Print-URI Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
document-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2911] Section 4.2)
Create-Job Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2911] Section 4.2)
Get-Printer-Attributes Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
document-format (R*)
Get-Jobs Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
Hastings, et al. Informational [Page 24]
RFC 3196 Internet Printing Protocol/1.1 November 2001
printer-uri (R)
requesting-user-name (R*)
limit (R*)
requested-attributes (R*)
which-jobs (R*)
my-jobs (R*)
Send-Document Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
Group 2: Document Content (R*)
<document content>
Send-URI Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
document-uri (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
Cancel-Job Request (R):
Release-Job Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
message (O*)
Hastings, et al. Informational [Page 25]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Get-Job-Attributes Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
Pause-Printer Request (O+):
Resume-Printer Request (O+):
Purge-Printer Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
Hold-Job Request (O+):
Restart-Job Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
job-hold-until (R*)
message (O*)
Operation Responses
The tables below show the response attributes in their proper
attribute groups for responses.
Note: All operation responses contain "version-number", "status-
code", and "request-id" parameters.
Print-Job Response (R):
Create-Job Response (O):
Send-Document Response (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
n <unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
Hastings, et al. Informational [Page 26]
RFC 3196 Internet Printing Protocol/1.1 November 2001
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
Validate-Job Response (R):
Cancel-Job Response (R):
Hold-Job Response (O+):
Release-Job Response (O+):
Restart-Job Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Print-URI Response (O):
Send-URI Response (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
document-access-error (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
Get-Printer-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Hastings, et al. Informational [Page 27]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Get-Jobs Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*)
Get-Job-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Pause-Printer Response (O+):
Resume-Printer Response (O+):
Purge-Printer Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Note 2 - the Job Object Attributes and Printer Object Attributes are
returned only if the IPP object returns one of the success status
codes.
Note 3 - the Unsupported Attributes Group is present only if the
client included some Operation and/or Job Template attributes or
values that the Printer doesn't support whether a success or an error
return.
Note 4 - the Unsupported Attributes Group is present only if the
client included some Operation attributes that the Printer doesn't
support whether a success or an error return.
Hastings, et al. Informational [Page 28]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Note 5: for the Get-Jobs operation the response contains a separate
Job Object Attributes group 3 to N containing requested-attributes
for each job object in the response.
3.1.2.1.5 Validate the values of the REQUIRED Operation attributes
An IPP object validates the values supplied by the client of the
REQUIRED Operation attribute that the IPP object MUST support. The
next section specifies the validation of the values of the OPTIONAL
Operation attributes that IPP objects MAY support.
The IPP object performs the following syntactic validation checks of
each Operation attribute value:
a) that the length of each Operation attribute value is correct
for the attribute syntax tag supplied by the client according
to [RFC2911] Section 4.1,
b) that the attribute syntax tag is correct for that Operation
attribute according to [RFC2911] Section 3,
c) that the value is in the range specified for that Operation
attribute according to [RFC2911] Section 3,
d) that multiple values are supplied by the client only for
operation attributes that are multi-valued, i.e., that are
1setOf X according to [RFC2911] Section 3.
If any of these checks fail, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' or the 'client-error-request-
value-too-long' status code. Since such an error is most likely to
be an error detected by a client developer, rather than by an end-
user, the IPP object NEED NOT return an indication of which attribute
had the error in either the Unsupported Attributes Group or the
Status Message. The description for each of these syntactic checks
is explicitly expressed in the first IF statement in the following
table.
In addition, the IPP object checks each Operation attribute value
against some Printer object attribute or some hard-coded value if
there is no "xxx-supported" Printer object attribute defined. If its
value is not among those supported or is not in the range supported,
then the IPP object REJECTS the request and RETURNS the error status
code indicated in the table by the second IF statement. If the value
of the Printer object's "xxx-supported" attribute is 'no-value'
(because the system administrator hasn't configured a value), the
check always fails.
Hastings, et al. Informational [Page 29]
RFC 3196 Internet Printing Protocol/1.1 November 2001
-----------------------------------------------
attributes-charset (charset)
IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported".
attributes-natural-language(naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
ACCEPT the request even if not a member of the set in the Printer
object's "generated-natural-language-supported" attribute. If the
supplied value is not a member of the Printer object's
"generated-natural-language-supported" attribute, use the Printer
object's "natural-language- configured" value.
requesting-user-name
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the IPP object can obtain a better-authenticated name, use it
instead.
job-name(name)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT supplied by the client, the Printer object creates a name
from the document-name or document-uri.
Hastings, et al. Informational [Page 30]
RFC 3196 Internet Printing Protocol/1.1 November 2001
document-name (name)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
ipp-attribute-fidelity (boolean)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the value
'false'.
document-format (mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "document-format-supported"
attribute, REJECT/RETURN 'client-error-document-format-not-
supported'
IF NOT supplied by the client, the IPP object assumes the value of
the Printer object's "document-format-default" attribute.
document-uri (uri)
IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
request'.
If the client-supplied URI scheme is not supported, i.e., the
value is not in the Printer object's referenced-uri-scheme-
supported" attribute, the Printer object MUST reject the request
Hastings, et al. Informational [Page 31]
RFC 3196 Internet Printing Protocol/1.1 November 2001
and return the 'client-error-uri-scheme-not-supported' status
code. The Printer object MAY check to see if the document exists
and is accessible. If the document is not found or is not
accessible, REJECT/RETURN 'client-error-not found'.
last-document (boolean)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
job-id (integer(1:MAX))
IF NOT an single 'integer' value equal to 4 octets AND in the
range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
error-not-found' or 'client-error-gone' status code, if keep track
of recently deleted jobs.
requested-attributes (1setOf keyword)
IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
Ignore unsupported values, which are the keyword names of
unsupported attributes. Don't bother to copy such requested
(unsupported) attributes to the Unsupported Attribute response
group since the response will not return them.
which-jobs (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
the unsupported value to the Unsupported Attributes response group
and REJECT/RETURN 'client-error-attributes-or-values-not-
supported'.
Hastings, et al. Informational [Page 32]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Note: a Printer still supports the 'completed' value even if it
keeps no completed/canceled/aborted jobs: by returning no jobs
when so queried.
IF NOT supplied by the client, the IPP object assumes the 'not-
completed' value.
my-jobs (boolean)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the 'false'
value.
limit (integer(1:MAX))
IF NOT a single 'integer' value equal to 4 octets AND in the range
1 to MAX, REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, the IPP object returns all jobs, no
matter how many.
-----------------------------------------------
3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
OPTIONAL Operation attributes are those that an IPP object MAY
support. An IPP object validates the values of the OPTIONAL
attributes supplied by the client. The IPP object performs the same
syntactic validation checks for each OPTIONAL attribute value as in
Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP
object REJECTS the request and RETURNS the 'client-error-bad-request'
or the 'client-error-request-value-too-long' status code.
In addition, the IPP object checks each Operation attribute value
against some Printer attribute or some hard-coded value if there is
no "xxx-supported" Printer attribute defined. If its value is not
among those supported or is not in the range supported, then the IPP
object REJECTS the request and RETURNS the error status code
indicated in the table. If the value of the Printer object's "xxx-
supported" attribute is 'no-value' (because the system administrator
hasn't configured a value), the check always fails.
Hastings, et al. Informational [Page 33]
RFC 3196 Internet Printing Protocol/1.1 November 2001
If the IPP object doesn't recognize/support an attribute, the IPP
object treats the attribute as an unknown or unsupported attribute
(see the last row in the table below).
-----------------------------------------------
document-natural-language (naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT a value that the Printer object supports in document
formats, (no corresponding "xxx-supported" Printer attribute),
REJECT/RETURN 'client-error-natural-language-not-supported'.
compression (type3 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "compression-supported" attribute,
REJECT/RETURN 'client-error-compression-not-supported'.
Note to IPP/1.0 implementers: Support for the "compression"
attribute was optional in IPP/1.0 and was changed to REQUIRED in
IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the
"compression" attribute being present and reject the create
request, if they don't support "compression". Not checking is a
bug, since the data will be unintelligible.
job-k-octets (integer(0:MAX))
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-k-octets-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
Hastings, et al. Informational [Page 34]
RFC 3196 Internet Printing Protocol/1.1 November 2001
job-impressions (integer(0:MAX))
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-impressions-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
job-media-sheets (integer(0:MAX))
IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-media-sheets-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
message (text(127))
IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 127 octets, REJECT/RETURN
'client-error-request-value-too-long'.
unknown or unsupported attribute
IF the attribute syntax supplied by the client is supported but
the length is not legal for that attribute syntax, REJECT/RETURN
'client-error-request-value-too-long'.
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-band"
'unsupported' value, but otherwise ignore the attribute.
Note: Future Operation attributes may be added to the protocol
specification that may occur anywhere in the specified group. When
the operation is otherwise successful, the IPP object returns the
'successful-ok-ignored-or-substituted-attributes' status code.
Ignoring unsupported Operation attributes in all operations is
analogous to the handling of unsupported Job Template attributes in
the create and Validate-Job operations when the client supplies the
"ipp-attribute-fidelity" Operation attribute with the 'false' value.
This last rule is so that we can add OPTIONAL Operation attributes to
future versions of IPP so that older clients can inter-work with new
Hastings, et al. Informational [Page 35]
RFC 3196 Internet Printing Protocol/1.1 November 2001
IPP objects and newer clients can inter-work with older IPP objects.
(If the new attribute cannot be ignored without performing
unexpectedly, the major version number would have been increased in
the protocol document and in the request). This rule for Operation
attributes is independent of the value of the "ipp-attribute-
fidelity" attribute. For example, if an IPP object doesn't support
the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-
k-octets" as an unknown attribute and only checks the length for the
'integer' attribute syntax supplied by the client. If it is not four
octets, the IPP object REJECTS the request and RETURNS the 'client-
error-bad-request' status code, else the IPP object copies the
attribute to the Unsupported Attribute response group, setting the
value to the "out-of-band" 'unsupported' value, but otherwise ignores
the attribute.
Hastings, et al. Informational [Page 36]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents
This section in combination with the previous section recommends the
processing steps for the Print-Job, Validate-Job, Print-URI, Create-
Job, Send-Document, and Send-URI operations that IPP objects SHOULD
use. These are the operations that create jobs, validate a Print-Job
request, and add documents to a job.
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v No
3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
<supplied?> |
Yes| |
| ipp-attribute-fidelity = no |
|<------------------------------+
v No
3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
<accepting jobs?>
Yes|
v err
3.1.2.3 <Validate values of> --> client-error-bad-request
<Job template attributes> client-error-request-value-too-
long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.3 <Validate values with> --> client-error-bad-request
<supported values> client-error-attributes-or-
| values-not-supported
v err
3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
attributes
<Job Template attr values> client-error-attributes-or-
values-not-supported
v
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied
The Printer object checks to see if the client supplied an "ipp-
attribute-fidelity" Operation attribute. If the attribute is not
supplied by the client, the IPP object assumes that the value is
'false'.
Hastings, et al. Informational [Page 37]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.2.2.2 Check that the Printer object is accepting jobs
If the value of the Printer objects "printer-is-accepting-jobs" is
'false', the Printer object REJECTS the request and RETURNS the
'server-error-not-accepting-jobs' status code.
3.1.2.2.3 Validate the values of the Job Template attributes
An IPP object validates the values of all Job Template attribute
supplied by the client. The IPP object performs the analogous
syntactic validation checks of each Job Template attribute value that
it performs for Operation attributes (see Section 3.1.2.1.5.):
a) that the length of each value is correct for the attribute
syntax tag supplied by the client according to [RFC2911]
Section 4.1.
b) that the attribute syntax tag is correct for that attribute
according to [RFC2911] Sections 4.2 to 4.4.
c) that multiple values are supplied only for multi-valued
attributes, i.e., that are 1setOf X according to [RFC2911]
Sections 4.2 to 4.4.
As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
IPP object REJECTS the request and RETURNS the 'client-error-bad-
request' or 'client-error-request-value-too-long' status code as
appropriate, independent of the value of the "ipp-attribute-
fidelity". Since such an error is most likely to be an error
detected by a client developer, rather than by an end-user, the IPP
object NEED NOT return an indication of which attribute had the error
in either the Unsupported Attributes Group or the Status Message.
The description for each of these syntactic checks is explicitly
expressed in the first IF statement in the following table.
Each Job Template attribute MUST occur no more than once. If an IPP
Printer receives a create request with multiple occurrences of a Job
Template attribute, it MAY:
1. reject the operation and return the 'client-error-bad-request'
error status code
2. accept the operation and use the first occurrence of the
attribute
3. accept the operation and use the last occurrence of the
attribute
Hastings, et al. Informational [Page 38]
RFC 3196 Internet Printing Protocol/1.1 November 2001
depending on implementation. Therefore, clients MUST NOT supply
multiple occurrences of the same Job Template attribute in the Job
Attributes group in the request.
3.1.2.3 Algorithm for job validation
The process of validating a Job-Template attribute "xxx" against a
Printer attribute "xxx-supported" can use the following validation
algorithm (see section 3.2.1.2 in [RFC2911]).
To validate the value U of Job-Template attribute "xxx" against the
value V of Printer "xxx-supported", perform the following algorithm:
1. If U is multi-valued, validate each value X of U by performing the
algorithm in Table 7 with each value X. Each validation is
separate from the standpoint of returning unsupported values.
Example: If U is "finishings" that the client supplies with
'staple', 'bind' values, then X takes on the successive values:
'staple', then 'bind'
2. If V is multi-valued, validate X against each Z of V by performing
the algorithm in Table 7 with each value Z. If a value Z
validates, the validation for the attribute value X succeeds. If
it fails, the algorithm is applied to the next value Z of V. If
there are no more values Z of V, validation fails. Example" If V
is "sides-supported" with values: 'one- sided', 'two-sided-long',
and 'two-sided-short', then Z takes on the successive values:
'one-sided', 'two-sided-long', and 'two-sided-short'. If the
client supplies "sides" with 'two-sided- long', the first
comparison fails ('one-sided' is not equal to 'two-sided-long'),
the second comparison succeeds ('two-sided-long' is equal to
'two-sided-long"), and the third comparison ('two-sided-short'
with 'two-sided-long') is not even performed.
3. If both U and V are single-valued, let X be U and Z be V and use
the validation rules in Table 7.
Hastings, et al. Informational [Page 39]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Table 7 - Rules for validating single values X against Z
Attribute syntax attribute syntax validated if:
of X of Z
integer rangeOfInteger X is within the range of Z
uri uriScheme the uri scheme in X is equal to
Z
any boolean the value of Z is TRUE
any any X and Z are of the same type
and are equal.
If the value of the Printer object's "xxx-supported" attribute is
'no-value' (because the system administrator hasn't configured a
value), the check always fails. If the check fails, the IPP object
copies the attribute to the Unsupported Attributes response group
with its unsupported value. If the attribute contains more than one
value, each value is checked and each unsupported value is separately
copied, while supported values are not copied. If an IPP object
doesn't recognize/support a Job Template attribute, i.e., there is no
corresponding Printer object "xxx-supported" attribute, the IPP
object treats the attribute as an unknown or unsupported attribute
(see the last row in the table below).
If some Job Template attributes are supported for some document
formats and not for others or the values are different for different
document formats, the IPP object SHOULD take that into account in
this validation using the value of the "document-format" supplied by
the client (or defaulted to the value of the Printer's "document-
format-default" attribute, if not supplied by the client). For
example, if "number-up" is supported for the 'text/plain' document
format, but not for the 'application/postscript' document format, the
check SHOULD (though it NEED NOT) depend on the value of the
"document-format" operation attribute. See "document-format" in
[RFC2911] section 3.2.1.1 and 3.2.5.1.
Note: whether the request is accepted or rejected is determined by
the value of the "ipp-attribute-fidelity" attribute in a subsequent
step, so that all Job Template attribute supplied are examined and
all unsupported attributes and/or values are copied to the
Unsupported Attributes response group.
-----------------------------------------------
Hastings, et al. Informational [Page 40]
RFC 3196 Internet Printing Protocol/1.1 November 2001
job-priority (integer(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, use the value of the Printer
object's "job-priority-default" attribute at job submission time.
IF NOT in the range 1 to 100, inclusive, copy the attribute and
the unsupported value to the Unsupported Attributes response
group.
Map the value to the nearest supported value in the range 1:100 as
specified by the number of discrete values indicated by the value
of the Printer's "job-priority-supported" attribute. See the
formula in [RFC2911] Section 4.2.1.
job-hold-until (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT supplied by the client, use the value of the Printer
object's "job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
job-sheets (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "job-sheets-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
multiple-document-handling (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
Hastings, et al. Informational [Page 41]
RFC 3196 Internet Printing Protocol/1.1 November 2001
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "multiple-document-handling-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group.
copies (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in range of the Printer object's "copies-supported"
attribute
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
finishings (1setOf type2 enum)
IF NOT an 'enum' value(s) each with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "finishings-supported" attribute,
copy the attribute and the unsupported value(s), but not any
supported values, to the Unsupported Attributes response group.
page-ranges (1setOf rangeOfInteger(1:MAX))
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
octets, REJECT/RETURN 'client-error-bad-request'.
IF first value is greater than second value in any range, the
ranges are not in ascending order, or ranges overlap,
REJECT/RETURN 'client-error-bad-request'.
IF the value of the Printer object's "page-ranges-supported"
attribute is 'false', copy the attribute to the Unsupported
Attributes response group and set the value to the "out-of-band"
'unsupported' value.
sides (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
Hastings, et al. Informational [Page 42]
RFC 3196 Internet Printing Protocol/1.1 November 2001
IF NOT in the Printer object's "sides-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
number-up (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT a value or in the range of one of the values of the Printer
object's "number-up-supported" attribute, copy the attribute and
value to the Unsupported Attribute response group.
orientation-requested (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "orientation-requested-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
media (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "media-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
printer-resolution (resolution)
IF NOT a single 'resolution' value with a length equal to 9
octets, REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "printer-resolution-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
print-quality (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
Hastings, et al. Informational [Page 43]
RFC 3196 Internet Printing Protocol/1.1 November 2001
IF NOT in the Printer object's "print-quality-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
unknown or unsupported attribute (i.e., there is no corresponding
Printer object "xxx-supported" attribute)
IF the attribute syntax supplied by the client is supported but
the length is not legal for that attribute syntax,
REJECT/RETURN 'client-error-bad-request' if the length of the
attribute syntax is fixed or 'client-error-request-value-too-long'
if the length of the attribute syntax is variable.
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-band"
'unsupported' value. Any remaining Job Template Attributes are
either unknown or unsupported Job Template attributes and are
validated algorithmically according to their attribute syntax for
proper length (see below).
-----------------------------------------------
If the attribute syntax is supported AND the length check fails,
the IPP object REJECTS the request and RETURNS the 'client-error-
bad-request' if the length of the attribute syntax is fixed or the
'client-error-request-value-too-long' status code if the length of
the attribute syntax is variable. Otherwise, the IPP object copies
the unsupported Job Template attribute to the Unsupported
Attributes response group and changes the attribute value to the
"out-of-band" 'unsupported' value. The following table shows the
length checks for all attribute syntaxes. In the following table:
"<=" means less than or equal, "=" means equal to:
Hastings, et al. Informational [Page 44]
RFC 3196 Internet Printing Protocol/1.1 November 2001
Name Octet length check for read-write attributes
---------- ---------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
'textWithoutLanguage' <= 1023
'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
'nameWithoutLanguage' <= 255
'keyword' <= 255
'enum' = 4
'uri' <= 1023
'uriScheme' <= 63
'charset' <= 63
'naturalLanguage' <= 63
'mimeMediaType' <= 255
'octetString' <= 1023
'boolean' = 1
'integer' = 4
'rangeOfInteger' = 8
'dateTime' = 11
'resolution' = 9
'1setOf X'
Note: It's possible for a Printer to receive a zero length keyword
in a request. Since this is a keyword, its value needs to be
compared with the supported values. Assuming that the printer
doesn't have any values in its corresponding "xxx-supported"
attribute that are keywords of zero length, the comparison will fail.
Then the request will be accepted or rejected depending on the value
of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
No special handling is required for
3.1.2.3.1 Check for conflicting Job Template attributes values
Once all the Operation and Job Template attributes have been checked
individually, the Printer object SHOULD check for any conflicting
values among all the supported values supplied by the client. For
example, a Printer object might be able to staple and to print on
transparencies, however due to physical stapling constraints, the
Printer object might not be able to staple transparencies. The IPP
object copies the supported attributes and their conflicting
attribute values to the Unsupported Attributes response group. The
Printer object only copies over those attributes that the Printer
object either ignores or substitutes in order to resolve the
conflict, and it returns the original values which were supplied by
the client. For example suppose the client supplies "finishings"
equals 'staple' and "media" equals 'transparency', but the Printer
object does not support stapling transparencies. If the Printer
chooses to ignore the stapling request in order to resolve the
Hastings, et al. Informational [Page 45]
RFC 3196 Internet Printing Protocol/1.1 November 2001
conflict, the Printer objects returns "finishings" equal to 'staple'
in the Unsupported Attributes response group. If any attributes are
multi-valued, only the conflicting values of the attributes are
copied.
Note: The decisions made to resolve the conflict (if there is a
choice) is implementation dependent.
3.1.2.3.2 Decide whether to REJECT the request
If there were any unsupported Job Template attributes or
unsupported/conflicting Job Template attribute values and the client
supplied the "ipp-attribute-fidelity" attribute with the 'true'
value, the Printer object REJECTS the request and return the status
code:
1.'client-error-conflicting-attributes' status code, if there were
any conflicts between attributes supplied by the client.
2.'client-error-attributes-or-values-not-supported' status code,
otherwise.
Note: Unsupported Operation attributes or values that are returned
do not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious
errors.
In general, the final results of Job processing are unknown at Job
submission time. The client has to rely on notifications or polling
to find out what happens at Job processing time. However, there are
cases in which some Printers can determine at Job submission time
that Job processing is going to fail. As an optimization, we'd like
to have the Printer reject the Job in these cases.
There are three types of "processing" errors that might be detectable
at Job submission time:
1. 'client-error-document-format-not-supported' : For the Print-
Job, Send-Document, Print-URI, and Send-URI operations, if all these
conditions are true:
- the Printer supports auto-sensing,
- the request "document-format" operation attribute is
'application/octet-stream',
- the Printer receives document data before responding,
- the Printer auto-senses the document format before responding,
Hastings, et al. Informational [Page 46]
RFC 3196 Internet Printing Protocol/1.1 November 2001
- the sensed document format is not supported by the Printer
then the Printer should respond with 'client-error-document-format-
not-supported' status.
2. 'client-error-compression-error': For the Print-Job, Send-
Document, Print-URI, and Send-URI operations, if all these
conditions are true:
- the client supplies a supported value for the "compression"
operation attribute in the request
- the Printer receives document data before responding,
- the Printer attempts to decompress the document data before
responding,
- the document data cannot be decompressed using the algorithm
specified by the "compression" operation attribute
then the Printer should respond with 'client-error-compression-error'
status.
3. 'client-error-document-access-error': For the Print-URI, and
Send-URI operations, if the Printer attempts and fails to pull the
referenced document data before responding, it should respond with
'client-error-document-access-error' status.
Some Printers are not able to detect these errors until Job
processing time. In that case, the errors are recorded in the
corresponding job-state and job-state reason attributes. (There is
no standard way for a client to determine whether a Printer can
detect these errors at Job submission time.) For example, if auto-
sensing happens AFTER the job is accepted (as opposed to auto-sensing
at submit time before returning the response), the implementation
aborts the job, puts the job in the 'aborted' state and sets the
'unsupported-document-format' value in the job's "job-state-reasons".
A client should always provide a valid "document-format" operation
attribute whenever practical. In the absence of other information, a
client itself may sniff the document data to determine document
format.
Auto sensing at Job submission time may be more difficult for the
Printer when combined with compression. For auto-sensed Jobs, a
client may be better off deferring compression to the transfer
protocol layer, e.g.; by using the HTTP Content-Encoding header.
Hastings, et al. Informational [Page 47]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
status codes
If the requested operation is the Validate-Job operation, the Printer
object returns:
1. the "successful-ok" status code, if there are no unsupported or
conflicting Job Template attributes or values.
2. the "successful-ok-conflicting-attributes, if there are any
conflicting Job Template attribute or values.
3. the "successful-ok-ignored-or-substituted-attributes, if there
are only unsupported Job Template attributes or values.
Note: Unsupported Operation attributes or values that are returned
do not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious
errors.
3.1.2.3.4 Create the Job object with attributes to support
If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
by the client), the Printer object:
1. creates a Job object, assigns a unique value to the job's
"job-uri" and "job-id" attributes, and initializes all of the
job's other supported Job Description attributes.
2. removes all unsupported attributes from the Job object.
3. for each unsupported value, removes either the unsupported
value or substitutes the unsupported attribute value with some
supported value. If an attribute has no values after removing
unsupported values from it, the attribute is removed from the
Job object (so that the normal default behavior at job
processing time will take place for that attribute).
4. for each conflicting value, removes either the conflicting
value or substitutes the conflicting attribute value with some
other supported value. If an attribute has no values after
removing conflicting values from it, the attribute is removed
from the Job object (so that the normal default behavior at job
processing time will take place for that attribute).
If there were no attributes or values flagged as unsupported, or the
value of 'ipp-attribute-fidelity" was 'false', the Printer object is
able to accept the create request and create a new Job object. If
the "ipp-attribute-fidelity" attribute is set to 'true', the Job
Template attributes that populate the new Job object are necessarily
all the Job Template attributes supplied in the create request. If
Hastings, et al. Informational [Page 48]
RFC 3196 Internet Printing Protocol/1.1 November 2001
the "ipp-attribute-fidelity" attribute is set to 'false', the Job
Template attributes that populate the new Job object are all the
client supplied Job Template attributes that are supported or that
have value substitution. Thus, some of the requested Job Template
attributes will not appear in the Job object because the Printer
object did not support those attributes. The attributes that
populate the Job object are persistently stored with the Job object
for that Job. A Get-Job-Attributes operation on that Job object will
return only those attributes that are persistently stored with the
Job object.
Note: All Job Template attributes that are persistently stored with
the Job object are intended to be "override values"; that is, they
that take precedence over whatever other embedded instructions might
be in the document data itself. However, it is not possible for all
Printer objects to realize the semantics of "override". End users
may query the Printer's "pdl-override-supported" attribute to
determine if the Printer either attempts or does not attempt to
override document data instructions with IPP attributes.
There are some cases, where a Printer supports a Job Template
attribute and has an associated default value set for that attribute.
In the case where a client does not supply the corresponding
attribute, the Printer does not use its default values to populate
Job attributes when creating the new Job object; only Job Template
attributes actually in the create request are used to populate the
Job object. The Printer's default values are only used later at Job
processing time if no other IPP attribute or instruction embedded in
the document data is present.
Note: If the default values associated with Job Template attributes
that the client did not supply were to be used to populate the Job
object, then these values would become "override values" rather than
defaults. If the Printer supports the 'attempted' value of the
"pdl-override-supported" attribute, then these override values could
replace values specified within the document data. This is not the
intent of the default value mechanism. A default value for an
attribute is used only if the create request did not specify that
attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
being 'false') and no value was provided within the content of the
document data.
If the client does not supply a value for some Job Template
attribute, and the Printer does not support that attribute, as far as
IPP is concerned, the result of processing that Job (with respect to
the missing attribute) is undefined.
Hastings, et al. Informational [Page 49]
RFC 3196 Internet Printing Protocol/1.1 November 2001
3.1.2.3.5 Return one of the success status codes
Once the Job object has been created, the Printer object accepts the
request and returns to the client:
1. the 'successful-ok' status code, if there are no unsupported or
conflicting Job Template attributes or values.
2. the 'successful-ok-conflicting-attributes' status code, if
there are any conflicting Job Template attribute or values.
3. the 'successful-ok-ignored-or-substituted-attributes' status
code, if there are only unsupported Job Template attributes or
values.
Note: Unsupported Operation attributes or values that are returned
do not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious
errors.
The Printer object also returns Job status attributes that indicate
the initial state of the Job ('pending', 'pending-held',
'processing', etc.), etc. See Print-Job Response, [RFC2911] section
3.2.1.2.
3.1.2.3.6 Accept appended Document Content
The Printer object accepts the appended Document Content data and
either starts it printing, or spools it for later processing.
3.1.2.3.7 Scheduling and Starting to Process the Job
The Printer object uses its own configuration and implementation
specific algorithms for scheduling the Job in the correct processing
order. Once the Printer object begins processing the Job, the
Printer changes the Job's state to 'processing'. If the Printer
object supports PDL override (the "pdl-override-supported" attribute
set to 'attempted'), the implementation does its best to see that IPP
attributes take precedence over embedded instructions in the document
data.
3.1.2.3.8 Completing the Job
The Printer object continues to process the Job until it can move the
Job into the 'completed' state. If an Cancel-Job operation is
received, the implementation eventually moves the Job into the
'canceled' state. If the system encounters errors during processing
that do not allow it to progress the Job into a completed state, the
Hastings, et al. Informational [Page 50]
RFC 3196 Internet Printing Protocol/1.1 November 2001
implementation halts all processing, cleans up any resources, and
moves the Job into the 'aborted' state.
3.1.2.3.9 Destroying the Job after completion
Once the Job moves to the 'completed', 'aborted', or 'canceled'
state, it is an implementation decision as to when to destroy the Job
object and release all associated resources. Once the Job has been
destroyed, the Printer would return either the "client-error-not-
found" or "client-error-gone" status codes for operations directed at
that Job.
Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
value for a sufficiently long time after a job has been destroyed, so
that stale references kept by clients are less likely to access the
wrong (newer) job.
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"
Some Printer object implementations may support "ipp-attribute-
fidelity" set to 'true' and "pdl-override-supported" set to
'attempted' and yet still not be able to realize exactly what the
client specifies in the create request. This is due to legacy
decisions and assumptions that have been made about the role of job
instructions embedded within the document data and external job
instructions that accompany the document data and how to handle
conflicts between such instructions. The inability to be 100%
precise about how a given implementation will behave is also
compounded by the fact that the two special attributes, "ipp-
attribute-fidelity" and "pdl-"override-supported", apply to the whole
job rather than specific values for each attribute. For example, some
implementations may be able to override almost all Job Template
attributes except for "number-up". Character Sets, natural
languages, and internationalization
This section discusses character set support, natural language
support and internationalization.
3.1.2.3.11 Character set code conversion support
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY
support additional charsets. It is RECOMMENDED that an IPP object
also support US-ASCII, since many clients support US-ASCII, and
indicate that UTF-8 and US-ASCII are supported by populating the
Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An
IPP object is required to code covert with as little loss as possible
between the charsets that it supports, as indicated in the Printer's
"charsets-supported" attribute.
Hastings, et al. Informational [Page 51]
RFC 3196 Internet Printing Protocol/1.1 November 2001
How should the server handle the situation where the "attributes-
charset" of the response itself is "us-ascii", but one or more
attributes in that response is in the "utf-8" format?
Example: Consider a case where a client sends a Print-Job request
with "utf-8" as the value of "attributes-charset" and with the "job-
name" attribute supplied. Later another client submits a Get-Job-
Attribute or Get-Jobs request. This second request contains the
"attributes-charset" with value "us-ascii" and "requested-attributes"
attribute with exactly one value "job-name".
According to the RFC2911 document (section 3.1.4.2), the value of the
"attributes-charset" for the response of the second request must be
"us-ascii" since that is the charset specified in the request. The
"job-name" value, however, is in "utf-8" format. Should the request
be rejected even though both "utf-8" and "us-ascii" charsets are
supported by the server? or should the "job-name" value be converted
to "us-ascii" and return "successful-ok-conflicting-attributes"
(0x0002) as the status code?
Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
ascii, the second paragraph of section 3.1.4.2 applies so that the
IPP object MUST accept the request, perform code set conversion
between these two charsets with "the highest fidelity possible" and
return 'successful-ok', rather than a warning 'successful-ok-
conflicting-attributes, or an error. The printer will do the best it
can to convert between each of the character sets that it supports --
even if that means providing a string of question marks because none
of the characters are representable in US ASCII. If it can't perform
such conversion, it MUST NOT advertise us-ascii as a value of its
"attributes-charset-supported" and MUST reject any request that
requests 'us-ascii'.
One IPP object implementation strategy is to convert all request text
and name values to a Unicode internal representation. This is 16-bit
and virtually universal. Then convert to the specified operation
attributes-charset on output.
Also it would be smarter for a client to ask for 'utf-8', rather than
'us-ascii' and throw away characters that it doesn't understand,
rather than depending on the code conversion of the IPP object.
3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?
Section 3.1.4.1 Request Operation attributes was clarified in
November 1998 as follows:
Hastings, et al. Informational [Page 52]
RFC 3196 Internet Printing Protocol/1.1 November 2001
All clients and IPP objects MUST support the 'utf-8' charset
[RFC2044] and MAY support additional charsets provided that they are
registered with IANA [IANA-CS]. If the Printer object does not
support the client supplied charset value, the Printer object MUST
reject the request, set the "attributes-charset" to 'utf-8' in the
response, and return the 'client-error-charset-not-supported' status
code and any 'text' or 'name' attributes using the 'utf-8' charset.
Since the client and IPP object MUST support UTF-8, returning any
text or name attributes in UTF-8 when the client requests a charset
that is not supported should allow the client to display the text or
name.
Since such an error is a client error, rather than a user error, the
client should check the status code first so that it can avoid
displaying any other returned 'text' and 'name' attributes that are
not in the charset requested.
Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
supported (0x040D) was clarified in November 1998 as follows:
For any operation, if the IPP Printer does not support the charset
supplied by the client in the "attributes-charset" operation
attribute, the Printer MUST reject the operation and return this
status and any 'text' or 'name' attributes using the 'utf-8' charset
(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.
Hastings, et al. Informational [Page 53]
RFC 3196 Internet Printing Protocol/1.1 November 2001
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
Hastings, et al. Informational [Page 54]
RFC 3196 Internet Printing Protocol/1.1 November 2001
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-
Hastings, et al. Informational [Page 55]
RFC 3196 Internet Printing Protocol/1.1 November 2001
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.
Hastings, et al. Informational [Page 56]
RFC 3196 Internet Printing Protocol/1.1 November 2001
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.
Hastings, et al. Informational [Page 57]
RFC 3196 Internet Printing Protocol/1.1 November 2001
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.
Hastings, et al. Informational [Page 58]
RFC 3196 Internet Printing Protocol/1.1 November 2001
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.
Hastings | |