RFC 3196
Internet Printing Protocol/1.1: Implementor's Guide
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
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
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
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.......... 401. 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]
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.
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
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.
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*
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.
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
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.
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
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.
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
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
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
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.
(page 17 continued on part 2)
