draft-ietf-ipp-implementers-guide-v11-02.txt   rfc3196.txt 
INTERNET-DRAFT Network Working Group T. Hastings
draft-ietf-ipp-implementers-guide-v11-02.txt Request for Comments: 3196 C. Manros
[Obsoletes RFC 2639] T. Hastings Obsoletes: 2639 P. Zehler
Xerox Corporation Category: Informational Xerox Corporation
C. Manros
Xerox Corporation
C. Kugler C. Kugler
IBM Printing Systems Co IBM Printing Systems Co
H. Holst H. Holst
i-data Printing Systems i-data Printing Systems
P. Zehler November 2001
Xerox Corporation
January 25, 2001
Internet Printing Protocol/1.1: Implementer's Guide
Copyright (C) The Internet Society (2001). All Rights Reserved. Internet Printing Protocol/1.1: Implementor's Guide
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of [RFC2026]. Internet-Drafts are not specify an Internet standard of any kind. Distribution of this
working documents of the Internet Engineering Task Force (IETF), its memo is unlimited.
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document is one of a set of documents, which together describe
all aspects of a new Internet Printing Protocol (IPP). 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,
and some of the considerations that may assist them in the design of
their client and/or IPP object implementations. 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 Implementer's Guide This document is one of a set of documents, which together describe
for IPP/1.0. all aspects of a new Internet Printing Protocol (IPP).
The full 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]
Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes
a broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. The design goal document calls out a subset of end
user requirements that are satisfied in IPP/1.1. Operator and
administrator requirements are out of scope for version 1.1.
The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specifications, and gives background and rationale for the
IETF working group's major decisions.
The document, "Internet Printing Protocol/1.1: Model and Semantics",
describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues
are addressed.
The document, "Internet Printing Protocol/1.1: Encoding and
Transport", is a formal mapping of the abstract operations and
attributes defined in the model document onto HTTP/1.1. It also
defines the encoding rules for a new Internet media type called
"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some
advice to implementers of gateways between IPP and LPD (Line Printer
Daemon) implementations.
TABLE OF CONTENTS
1 Introduction....................................................7 Table of Contents
1.1 Conformance language.........................................7
1.2 Other terminology............................................8
1.3 Issues Raised from Interoperability Testing Events...........8
2 IPP Objects.....................................................8 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 IPP Operations.................................................10 3.1.2.1.4.3 Validate the presence of a single occurrence of
3.1 Common Semantics............................................10 required Operation attributes....................... 21
3.1.1 Summary of Operation Attributes............................10 3.1.2.1.5 Validate the values of the REQUIRED Operation
3.1.2 Suggested Operation Processing Steps for IPP Objects.......16 attributes............................................ 29
3.1.2.1 Suggested Operation Processing Steps for all Operations ..17 3.1.2.1.6 Validate the values of the OPTIONAL Operation
3.1.2.1.1 Validate version number...............................18 attributes............................................ 33
3.1.2.1.2 Validate operation identifier.........................19 3.1.2.2 Suggested Additional Processing Steps for Operations
3.1.2.1.3 Validate the request identifier.......................19 that Create/Validate Jobs and Add Documents............. 37
3.1.2.1.4 Validate attribute group and attribute presence and order 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
19 3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
3.1.2.1.4.1 Validate the presence and order of attribute groups .19 3.1.2.2.3 Validate the values of the Job Template attributes.... 38
3.1.2.1.4.2 Ignore unknown attribute groups in the expected 3.1.2.3 Algorithm for job validation............................ 39
position 20 3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
3.1.2.1.4.3 Validate the presence of a single occurrence of 3.1.2.3.2 Decide whether to REJECT the request.................. 46
required Operation attributes.....................................21 3.1.2.3.3 For the Validate-Job operation, RETURN one of the
3.1.2.1.5 Validate the values of the REQUIRED Operation attributes success status codes.................................. 48
28 3.1.2.3.4 Create the Job object with attributes to support...... 48
3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes 3.1.2.3.5 Return one of the success status codes................ 50
32 3.1.2.3.6 Accept appended Document Content...................... 50
3.1.2.2 Suggested Additional Processing Steps for Operations that 3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
Create/Validate Jobs and Add Documents............................35 3.1.2.3.8 Completing the Job.................................... 50
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied......35 3.1.2.3.9 Destroying the Job after completion................... 51
3.1.2.2.2 Check that the Printer object is accepting jobs.......36 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
3.1.2.2.3 Validate the values of the Job Template attributes....36 3.1.2.3.11 Character set code conversion support................. 51
3.1.2.3 Algorithm for job validation .............................37
3.1.2.3.1 Check for conflicting Job Template attributes values..43
3.1.2.3.2 Decide whether to REJECT the request..................43
3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
status codes......................................................45
3.1.2.3.4 Create the Job object with attributes to support......45
3.1.2.3.5 Return one of the success status codes................47
3.1.2.3.6 Accept appended Document Content......................48
3.1.2.3.7 Scheduling and Starting to Process the Job............48
3.1.2.3.8 Completing the Job....................................48
3.1.2.3.9 Destroying the Job after completion...................48
3.1.2.3.10 Interaction with "ipp-attribute-fidelity".............49
3.1.2.3.11 Character set code conversion support.................49
3.1.2.3.12 What charset to return when an unsupported charset is 3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?...........................................50 requested (Issue 1.19)?....... ....................... 52
3.1.2.3.13 Natural Language Override (NLO).......................51 3.1.2.3.13 Natural Language Override (NLO)....................... 53
3.1.3 Status codes returned by operation.........................53 3.1.3 Status codes returned by operation......................... 55
3.1.3.1 Printer Operations .......................................53 3.1.3.1 Printer Operations...................................... 55
3.1.3.1.1 Print-Job.............................................53 3.1.3.1.1 Print-Job............................................. 55
3.1.3.1.2 Print-URI.............................................55 3.1.3.1.2 Print-URI............................................. 58
3.1.3.1.3 Validate-Job..........................................56 3.1.3.1.3 Validate-Job.......................................... 58
3.1.3.1.4 Create-Job............................................56 3.1.3.1.4 Create-Job............................................ 58
3.1.3.1.5 Get-Printer-Attributes................................56 3.1.3.1.5 Get-Printer-Attributes................................ 59
3.1.3.1.6 Get-Jobs..............................................57 3.1.3.1.6 Get-Jobs.............................................. 60
3.1.3.1.7 Pause-Printer.........................................58 3.1.3.1.7 Pause-Printer......................................... 61
3.1.3.1.8 Resume-Printer........................................59 3.1.3.1.8 Resume-Printer........................................ 62
3.1.3.1.8.1 What about Printers unable to change state due to an 3.1.3.1.8.1 What about Printers unable to change state due to
error condition?..................................................59 an error condition?................................. 63
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? ...59 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
3.1.3.1.9 Purge-Printer.........................................60 3.1.3.1.9 Purge-Printer......................................... 63
3.1.3.2 Job Operations ...........................................60 3.1.3.2 Job Operations.......................................... 64
3.1.3.2.1 Send-Document.........................................60 3.1.3.2.1 Send-Document......................................... 64
3.1.3.2.2 Send-URI..............................................61 3.1.3.2.2 Send-URI.............................................. 65
3.1.3.2.3 Cancel-Job............................................62 3.1.3.2.3 Cancel-Job............................................ 65
3.1.3.2.4 Get-Job-Attributes....................................62 3.1.3.2.4 Get-Job-Attributes.................................... 67
3.1.3.2.5 Hold-Job..............................................63 3.1.3.2.5 Hold-Job.............................................. 68
3.1.3.2.6 Release-Job...........................................64 3.1.3.2.6 Release-Job........................................... 69
3.1.3.2.7 Restart-Job...........................................64 3.1.3.2.7 Restart-Job........................................... 69
3.1.3.2.7.1 Can documents be added to a restarted job? ..........65 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 3.1.4 Returning unsupported attributes in Get-Xxxx responses
1.18) 65 (Issue 1.18)............................................... 70
3.1.5 Sending empty attribute groups.............................65 3.1.5 Sending empty attribute groups............................. 70
3.2 Printer Operations..........................................66 3.2 Printer Operations.......................................... 71
3.2.1 Print-Job operation........................................66 3.2.1 Print-Job operation........................................ 71
3.2.1.1 Flow controlling the data portion of a Print-Job request 3.2.1.1 Flow controlling the data portion of a Print-Job
(Issue 1.22)......................................................66 request (Issue 1.22).................................... 71
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) ...66 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
3.2.2 Get-Printer-Attributes operation...........................67 3.2.2 Get-Printer-Attributes operation........................... 72
3.2.3 Get-Jobs operation.........................................67 3.2.3 Get-Jobs operation......................................... 72
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
1.39)? 67 (Issue 1.39)?.......................................... 72
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
68 operation?.............................................. 73
3.2.4 Create-Job operation.......................................68 3.2.4 Create-Job operation....................................... 73
3.3 Job Operations..............................................69 3.3 Job Operations.............................................. 74
3.3.1 Validate-Job...............................................69 3.3.1 Validate-Job............................................... 74
3.3.2 Restart-Job................................................69 3.3.2 Restart-Job................................................ 74
4 Object Attributes.............................................. 74
4 Object Attributes..............................................70 4.1 Attribute Syntax's.......................................... 74
4.1 Attribute Syntax's..........................................70 4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
4.1.1 The 'none' value for empty sets (Issue 1.37)...............70 4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
4.1.2 Multi-valued attributes (Issue 1.31).......................70 4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
4.1.3 Case Sensitivity in URIs (issue 1.6).......................70 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage..71 4.2 Job Template Attributes..................................... 76
4.2 Job Template Attributes.....................................72 4.2.1 multiple-document-handling(type2 keyword).................. 76
4.2.1 multiple-document-handling(type2 keyword)..................72 4.2.1.1 Support of multiple document jobs....................... 76
4.2.1.1 Support of multiple document jobs ........................72 4.3 Job Description Attributes.................................. 76
4.3 Job Description Attributes..................................72 4.3.1 Getting the date and time of day........................... 76
4.3.1 Getting the date and time of day...........................72 4.4 Printer Description Attributes.............................. 77
4.4 Printer Description Attributes..............................73 4.4.1 queued-job-count (integer(0:MAX)).......................... 77
4.4.1 queued-job-count (integer(0:MAX))..........................73 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? ......73 4.4.1.2 Is "queued-job-count" a good measure of how busy a
4.4.1.2 Is "queued-job-count" a good measure of how busy a printer printer is (Issue 1.15)?................................ 77
is (Issue 1.15)?..................................................73 4.4.2 printer-current-time (dateTime)............................ 78
4.4.2 printer-current-time (dateTime)............................73 4.4.3 Printer-uri................................................ 78
4.4.3 Printer-uri................................................74 4.5 Empty Jobs.................................................. 79
4.5 Empty Jobs..................................................74 5 Directory Considerations....................................... 79
5.1 General Directory Schema Considerations..................... 79
5 Directory Considerations.......................................75 5.2 IPP Printer with a DNS name................................. 79
5.1 General Directory Schema Considerations.....................75 6 Security Considerations........................................ 80
5.2 IPP Printer with a DNS name.................................75
6 Security Considerations........................................75
6.1 Querying jobs with IPP that were submitted using other job 6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32).................................75 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
7 Encoding and Transport.........................................76 Tables
7.1 General Headers.............................................78
7.2 Request Headers............................................79
7.3 Response Headers............................................81
7.4 Entity Headers.............................................81
7.5 Optional support for HTTP/1.0...............................82
7.6 HTTP/1.1 Chunking...........................................83
7.6.1 Disabling IPP Server Response Chunking.....................83
7.6.2 Warning About the Support of Chunked Requests..............83
8 References.....................................................84 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
9 Authors' Address...............................................85 1. Introduction
10 Full Copyright Statement.......................................86 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.
TABLES 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:
Table 1 - Summary of Printer operation attributes that sender MUST Design Goals for an Internet Printing Protocol [RFC2567]
supply ........................................................11 Rationale for the Structure and Model and Protocol for the
Table 2 - Summary of Printer operation attributes that sender MAY Internet Printing Protocol [RFC2568]
supply ........................................................12 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Table 3 - Summary of Job operation attributes that sender MUST supply Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
..............................................................13 Internet Printing Protocol/1.1: Implementor's Guide (this
Table 4 - Summary of Job operation attributes that sender MAY supply document)
..............................................................14 Mapping between LPD and IPP Protocols [RFC2569]
Table 5 - Printer operation response attributes...................15
Table 6 - Examples of validating IPP version......................18
Table 7 - Rules for validating single values X against Z..........38
1 Introduction 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.
The IPP Implementer's Guide (IIG) (this document) contains As such the information in this document is not part of the formal
information that supplements the IPP Model and Semantics [RFC2911] specification of IPP/1.1. Instead information is presented to help
and the IPP Transport and Encoding [RFC2910] documents. As such this implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565,
information is not part of the formal specifications. Instead RFC2566], including some of the motivation for decisions taken by the
information is presented to help implementers understand the committee in developing the specification. Some of the
specification, 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 implementation considerations are intended to help implementers
design their client and/or IPP object implementations. If there are design their client and/or IPP object implementations. If there are
any contradictions between this document and [RFC2911] or [RFC2910], any contradictions between this document and [RFC2911] or [RFC2910],
those documents take precedence over this document. those documents take precedence over this document.
Platform-specific implementation considerations will be included in Platform-specific implementation considerations will be included in
this guide as they become known. this guide as they become known.
In order to help the reader of the IIG and the IPP Model and Note: In order to help the reader of the IIG and the IPP Model and
Semantics document, the sections in this document parallel the Semantics document, the sections in this document parallel the
corresponding sections in the Model document and are numbered the corresponding sections in the Model document and are numbered the
same for ease of cross reference. The sections that correspond to same for ease of cross reference. The sections that correspond to
the IPP Transport and Encoding are correspondingly offset. the IPP Transport and Encoding are correspondingly offset.
1.1 Conformance language 1.1 Conformance language
Usually, this document does not contain the terminology MUST, MUST Usually, this document does not contain the terminology MUST, MUST
NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
However, when those terms do appear in this document, their intent is However, when those terms do appear in this document, their intent is
to repeat what the [RFC2911] and [RFC2910] documents require and to repeat what the [RFC2911] and [RFC2910] documents require and
allow, rather than specifying additional conformance requirements. allow, rather than specifying additional conformance requirements.
These terms are defined in section 12 on conformance terminology in These terms are defined in section 12 on conformance terminology in
[RFC2911], most of which is taken from RFC 2119 [RFC2119]. [RFC2911], most of which is taken from RFC 2119 [RFC2119].
Implementers should read section 12 (APPENDIX A) in [RFC2911] in Implementers should read section 12 (APPENDIX A) in [RFC2911] in
order to understand these capitalized words. The words MUST, MUST order to understand these capitalized words. The words MUST, MUST
NOT, and REQUIRED indicate what implementations are required to NOT, and REQUIRED indicate what implementations are required to
support in a client or IPP object in order to be conformant 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 [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is
merely allowed as an implementer option. The verbs SHOULD and SHOULD merely allowed as an implementer option. The verbs SHOULD and SHOULD
NOT indicate suggested behavior, but which is not required or NOT indicate suggested behavior, but which is not required or
disallowed, respectively, in order to conform to the specification. disallowed, respectively, in order to conform to the specification.
1.2 Other terminology 1.2 Other terminology
This document uses other terms, such as "attributes", "operation", This document uses other terms, such as "attributes", "operation",
and "Printer" as defined in [RFC2911] section 12. In addition, the and "Printer" as defined in [RFC2911] section 12. In addition, the
term "sender" refers to the client that sends a request or an IPP term "sender" refers to the client that sends a request or an IPP
object that returns a response. The term "receiver" refers to the object that returns a response. The term "receiver" refers to the
IPP object that receives a request and to a client that receives a IPP object that receives a request and to a client that receives a
response. response.
1.3 Issues Raised from Interoperability Testing Events 1.3 Issues Raised from Interoperability Testing Events
The IPP WG has conducted three open 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 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 March 1999, and the third one was held in October 2000. See the
summary reports in: summary reports in:
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/ ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
The issues raised from the first Interoperability Testing Event are The issues raised from the first Interoperability Testing Event are
numbered 1.n in this document and have been incorporated into 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 "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
Transport" [RFC2565] documents. However, some of the discussion is Transport" [RFC2565] documents. However, some of the discussion is
left here in the Implementer's Guide to help understanding. left here in the Implementor's Guide to help understanding.
The issues raised from the second Interoperability Testing Event are The issues raised from the second Interoperability Testing Event are
numbered 2.n in this document have been incorporated into "IPP/1.1 numbered 2.n in this document have been incorporated into "IPP/1.1
Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
Transport" [RFC2910] documents. However, some of the discussion is Transport" [RFC2910] documents. However, some of the discussion is
left here in the Implementer's Guide to help understanding. left here in the Implementor's Guide to help understanding.
The issues raised from the third Interoperability Testing Event are The issues raised from the third Interoperability Testing Event are
numbered 3.n in this document and are described in: 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-
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc Off3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
2 IPP Objects 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 The term "client" in IPP is intended to mean any client that issues
IPP operation requests and accepts IPP operation responses, whether IPP operation requests and accepts IPP operation responses, whether
it be a desktop or a server. In other words, the term "client" does 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 not just mean end-user clients, such as those associated with
desktops. desktops.
The term "IPP Printer" in IPP is intended to mean an object that The term "IPP Printer" in IPP is intended to mean an object that
accepts IPP operation requests and returns IPP operation responses, accepts IPP operation requests and returns IPP operation responses,
whether implemented in a server or a device. An IPP Printer object whether implemented in a server or a device. An IPP Printer object
MAY, if implemented in a server, turn around and forward received MAY, if implemented in a server, turn around and forward received
jobs (and other requests) to other devices and print jobs (and other requests) to other devices and print
servers/services, either using IPP or some other protocol. servers/services, either using IPP or some other protocol.
3 IPP Operations 3 IPP Operations
This section corresponds to Section 3 "IPP Operations" in the This section corresponds to Section 3 "IPP Operations" in the
IPP/1.1 Model and Semantics document [RFC2911]. IPP/1.1 Model and Semantics document [RFC2911].
3.1 Common Semantics 3.1 Common Semantics
This section discusses semantics common to all operations. This section discusses semantics common to all operations.
3.1.1 Summary of Operation Attributes 3.1.1 Summary of Operation Attributes
Legend for the following table: Table 1 - Summary of Printer operation attributes that sender MUST
supply
R indicates a REQUIRED operation that MUST be supported by the IPP Printer Operations
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be Requests Responses
supported by the IPP object (Printer or Job). Operation PJ, PU CJ GPA GJ PP, All
Attributes VJ (O) (O) (R) (R) RP, Operations
(R) PP
(O+)
+ indicates that this is not an IPP/1.0 feature, but is only a part Operation parameters--REQUIRED to be supplied by the sender:
of IPP/1.1 and future versions of IPP.
Table 1 - Summary of Printer operation attributes that sender MUST operation-id R R R R R R
supply
Printer Operations status-code R
Requests Response
s
Operation Print- Pri Crea Get- Get Pause- All request-id R R R R R R R
Attributes Job, te- Printer- - Printer Operatio
Validate URI Job Attribut Job , ns version-number R R R R R R R
-Job (R) (O) (O) es (R) s Resume-
(R) Printer Operation attributes--REQUIRED to be supplied by the sender:
,
Purge- attributes- R R R R R R R
nt- Printer charset
(O+)
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.
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- R R R R R R R
number
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*
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- R R R R R R
user-name
Table 2 - Summary of Printer operation attributes that sender MAY Table 2 - Summary of Printer operation attributes that sender MAY
supply supply
Printer Operations Printer Operations
Requests Respo
nses
Operation Print- Prin Crea Get- Get Pause- All Requests Respon-
Attributes Job, t- te- Printer - Printer Opera ses
Valida URI Job - Job , tions Operation Attributes PJ, PU CJ GPA GJ PP, All
te-Job (O) (O) Attribu s Resume- VJ (O) (O) (R) (R) RP, Opera
(R) tes (R) (R) Printer (R) PP tions
, (O+)
Purge-
Printer
(O+)
Operation attributes--OPTIONAL to be supplied by the sender: Operation attributes--OPTIONAL to be supplied by the sender:
status-message O
detailed-status- O status-message O
message
document-access- O** detailed-status- O
error message
compression O O
document-format R R R document-access- O**
document-name O O error
document-natural- O O
language compression R R
ipp-attribute- R R R
fidelity document-format R R R
job-impressions O O O
job-k-octets O O O document-name O O
job-media-sheets O O O
limit R document-natural- O O
message language
my-jobs R
requested- R R ipp-attribute- R R R
attributes fidelity
which-jobs R
* "job-id" is REQUIRED only if used together with "printer-uri" job-impressions O O O
to identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Print-URI response job-k-octets O O O
only.
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 Table 3 - Summary of Job operation attributes that sender MUST supply
Job Operations Job Operations
Requests Respons
es
Operation Send- Send Cance Get- All Requests Responses
Attributes Docume -URI l-Job Job- Job, Operatio Operation SD SU CJ GJA HJ All
nt (O) (R) Attrib Release ns Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O) utes -Job, (O+) tions
(R) Restart
-Job Operation parameters--REQUIRED to be supplied by the sender:
(O+)
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.
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
requesting-user- R R R R R
name
Table 4 - Summary of Job operation attributes that sender MAY supply Table 4 - Summary of Job operation attributes that sender MAY supply
Job Operations Job Operations
Requests Respo
nses
Operation Send- Sen Cance Hold- Relea All Requests Responses
Attributes Documen d- l-Job Get- Job, se- Opera
t URI (R) Attrib Restar Job tions
(O) (O) utes t-Job (O+)
(R) (O+)
Operation attributes--OPTIONAL to be supplied by the sender: Operation SD SU CJ GJA HJ, SD All
status-message O Attributes (O) (O) (R) (R) RJ, (O) Opera-
detailed-status- O RJ tions
message (O+)
document-access- O**
error Operation attributes--OPTIONAL to be supplied by the sender:
compression O O
document-format R R status-message O
document-name O O
document-natural- O O detailed-status- O
language message
ipp-attribute-
fidelity document-access- O**
job-impressions error
job-k-octets
job-media-sheets compression R R
limit
message O O O document-format R R
job-hold-until R
my-jobs document-name O O
requested- R
attributes document-natural- O O
which-jobs language
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED. ipp-attribute-
** "document-access-error" applies to the Send-URI operation only. 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 Table 5 - Printer operation response attributes
Printer Operations Printer Operations
Response
Operation Print- Validat Prin Create Get- Get- Pause- Response
Attributes Job e-Job t- -Job Printe Jobs Printer
(R),Send (R) URI (O) r- (R) ,
- (O), Attrib Resume-
Document Send utes Printer
(O) -URI (R) ,
(O) Purge-
Printer
(O+)
job-uri R R R Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP,
job-id R R R Attributes SD (O) SU (O) (R) RP, PP
job-state R R R (O+)
job-state- R+ R+ R+
reasons
number-of- O O O
intervening-
jobs
document- O
access-error+
3.1.2 Suggested Operation Processing Steps for IPP Objects 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 This section suggests the steps and error checks that an IPP object
MAY perform when processing requests and returning responses. An IPP MAY perform when processing requests and returning responses. An IPP
object MAY perform some or all of the error checks. However, some object MAY perform some or all of the error checks. However, some
implementations MAY choose to be more forgiving than the error checks implementations MAY choose to be more forgiving than the error checks
shown here, in order to be able to accept requests from non- shown here, in order to be able to accept requests from non-
conforming clients. Not performing all of these error checks is a conforming clients. Not performing all of these error checks is a
so-called "forgiving" implementation. On the other hand, clients so-called "forgiving" implementation. On the other hand, clients
that successfully submit requests to IPP objects that do perform all that successfully submit requests to IPP objects that do perform all
the error checks will be more likely to be able to interoperate with the error checks will be more likely to be able to interoperate with
other IPP object implementations. Thus an implementer of an IPP other IPP object implementations. Thus an implementer of an IPP
object needs to decide whether to be a "forgiving" or a "strict" object needs to decide whether to be a "forgiving" or a "strict"
implementation. Therefore, the error status codes returned may implementation. Therefore, the error status codes returned may
differ between implementations. Consequentially, client SHOULD NOT differ between implementations. Consequentially, client SHOULD NOT
expect exactly the error code processing described in this section. expect exactly the error code processing described in this section.
When an IPP object receives a request, the IPP object either accepts When an IPP object receives a request, the IPP object either accepts
or rejects the request. In order to determine whether or not to or rejects the request. In order to determine whether or not to
accept or reject the request, the IPP object SHOULD execute the accept or reject the request, the IPP object SHOULD execute the
following steps. The order of the steps may be rearranged and/or following steps. The order of the steps may be rearranged and/or
combined, including making one or multiple passes over the request. combined, including making one or multiple passes over the request.
A client MUST supply requests that would pass all of the error checks A client MUST supply requests that would pass all of the error checks
indicated here in order to be a conforming client. Therefore, a indicated here in order to be a conforming client. Therefore, a
skipping to change at page 17, line 5 skipping to change at page 17, line 44
the xxx status code ..." statement is encountered. Error returns are the xxx status code ..." statement is encountered. Error returns are
indicated by the verb: "REJECTS". Since clients have difficulty indicated by the verb: "REJECTS". Since clients have difficulty
getting the status code before sending all of the document data in a getting the status code before sending all of the document data in a
Print-Job request, clients SHOULD use the Validate-Job operation Print-Job request, clients SHOULD use the Validate-Job operation
before sending large documents to be printed, in order to validate before sending large documents to be printed, in order to validate
whether the IPP Printer will accept the job or not. whether the IPP Printer will accept the job or not.
It is assumed that security authentication and authorization has It is assumed that security authentication and authorization has
already taken place at a lower layer. already taken place at a lower layer.
3.1.2.1 Suggested Operation Processing Steps for all Operations 3.1.2.1 Suggested Operation Processing Steps for all Operations
This section is intended to apply to all operations. The next This section is intended to apply to all operations. The next
section contains the additional steps for the Print-Job, Validate- section contains the additional steps for the Print-Job, Validate-
Job, Print-URI, Create-Job, Send-Document, and Send-URI operations Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
that create jobs, adds documents, and validates jobs. that create jobs, adds documents, and validates jobs.
IIG Sect # Flow IPP error status codes IIG Sect # Flow IPP error status codes
---------- ---- ---------------------- ---------- ---- ----------------------
| |
v err v err
skipping to change at page 17, line 32 skipping to change at page 18, line 25
ok| ok|
v err v err
3.1.2.1.4.1- <Validate presence> --> client-error-bad-request 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
3.1.2.1.4.2 <of attributes> 3.1.2.1.4.2 <of attributes>
ok| ok|
v err v err
3.1.2.1.4.3 <Validate presence> --> client-error-bad-request 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
<of operation attr> <of operation attr>
ok| ok|
v err v err
3.1.2.1.5 <Valied values of> --> client-error-bad-request 3.1.2.1.5 <Validate values of> --> client-error-bad-request
<operation attrs> client-error-request-value- <operation attrs> client-error-request-value-
too-long too-long
<(length, tag, range,> <(length, tag, range,>
<multi-value)> <multi-value)>
ok| ok|
v err v err
3.1.2.1.5 <Validate values> --> client-error-bad-request 3.1.2.1.5 <Validate values> --> client-error-bad-request
<with supported values> client-error-charset-not- <with supported values> client-error-charset-not-
supported supported
ok| client-error-attributes-or- ok| client-error-attributes-or-
skipping to change at page 18, line 5 skipping to change at page 18, line 47
| not-supported | not-supported
v err v err
3.1.2.1.6 <Validate optionally> --> client-error-bad-request 3.1.2.1.6 <Validate optionally> --> client-error-bad-request
<operation attr> client-error-natural-language- <operation attr> client-error-natural-language-
not-supported not-supported
| client-error-request-value- | client-error-request-value-
too-long too-long
| client-error-attributes-or- | client-error-attributes-or-
values-not-supported values-not-supported
3.1.2.1.1 Validate version number 3.1.2.1.1 Validate version number
Every request and every response contains the "version-number" Every request and every response contains the "version-number"
attribute. The value of this attribute is the major and minor attribute. The value of this attribute is the major and minor
version number of the syntax and semantics that the client and IPP version number of the syntax and semantics that the client and IPP
object is using, respectively. The "version-number" attribute object is using, respectively. The "version-number" attribute
remains in a fixed position across all future versions so that all remains in a fixed position across all future versions so that all
clients and IPP object that support future versions can determine clients and IPP object that support future versions can determine
which version is being used. The IPP object checks to see if the which version is being used. The IPP object checks to see if the
major version number supplied in the request is supported. If not, major version number supplied in the request is supported. If not,
the Printer object REJECTS the request and RETURNS the 'server-error- the Printer object REJECTS the request and RETURNS the 'server-
version-not-supported' status code in the response. The IPP object error-version-not-supported' status code in the response. The IPP
returns in the "version-number" response attribute the major and object returns in the "version-number" response attribute the major
minor version for the error response. Thus the client can learn at and minor version for the error response. Thus the client can learn
least one major and minor version that the IPP object supports. The at least one major and minor version that the IPP object supports.
IPP object is encouraged to return the closest version number to the The IPP object is encouraged to return the closest version number to
one supplied by the client. the one supplied by the client.
The checking of the minor version number is implementation dependent, The checking of the minor version number is implementation dependent,
however if the client supplied minor version is explicitly supported, however if the client-supplied minor version is explicitly supported,
the IPP object MUST respond using that identical minor version the IPP object MUST respond using that identical minor version
number. If the major version number matches, but the minor version number. If the major version number matches, but the minor version
number does not, the Printer SHOULD accept and attempt to process number does not, the Printer SHOULD accept and attempt to process the
the request, or MAY reject the request and return the 'server-error- request, or MAY reject the request and return the 'server-error-
version-not-supported' status code. In all cases, the Printer MUST version-not-supported' status code. In all cases, the Printer MUST
return the nearest version number that it supports. For example, return the nearest version number that it supports. For example,
suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'. suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
The following responses are conforming: The following responses are conforming:
Table 6 - Examples of validating IPP version Table 6 - Examples of validating IPP version
Client supplies Printer Accept Request? Printer returns Client supplies Printer Accept Request? Printer returns
1.0 yes (SHOULD) 1.1 1.0 yes (SHOULD) 1.1
1.0 no (SHOULD NOT) 1.1 1.0 no (SHOULD NOT) 1.1
1.1 yes (MUST) 1.1 1.1 yes (MUST) 1.1
1.2 yes (MUST) 1.2 1.2 yes (MUST) 1.2
skipping to change at page 19, line 14 skipping to change at page 20, line 8
It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
so that they can interoperate with either client implementations. so that they can interoperate with either client implementations.
Some implementations may allow an Administrator to explicitly disable Some implementations may allow an Administrator to explicitly disable
support for one or the other by setting the "ipp-versions-supported" support for one or the other by setting the "ipp-versions-supported"
Printer description attribute. Printer description attribute.
Likewise, it is advantageous for clients to support both versions to Likewise, it is advantageous for clients to support both versions to
allow interoperability with new and legacy Printers. allow interoperability with new and legacy Printers.
3.1.2.1.2 Validate operation identifier 3.1.2.1.2 Validate operation identifier
The Printer object checks to see if the "operation-id" attribute The Printer object checks to see if the "operation-id" attribute
supplied by the client is supported as indicated in the Printer supplied by the client is supported as indicated in the Printer
object's "operations-supported" attribute. If not, the Printer object's "operations-supported" attribute. If not, the Printer
REJECTS the request and returns the 'server-error-operation-not- REJECTS the request and returns the 'server-error-operation-not-
supported' status code in the response. supported' status code in the response.
3.1.2.1.3 Validate the request identifier 3.1.2.1.3 Validate the request identifier
The Printer object SHOULD NOT check to see if the "request-id" 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 attribute supplied by the client is in range: between 1 and 2**31 - 1
(inclusive), but copies all 32 bits. (inclusive), but copies all 32 bits.
Note: The "version-number", "operation-id", and the "request-id" Note: The "version-number", "operation-id", and the "request-id"
parameters are in fixed octet positions in the IPP/1.1 encoding. The parameters are in fixed octet positions in the IPP/1.1 encoding. The
"version-number" parameter will be the same fixed octet position in "version-number" parameter will be the same fixed octet position in
all versions of the protocol. These fields are validated before all versions of the protocol. These fields are validated before
proceeding with the rest of the validation. proceeding with the rest of the validation.
3.1.2.1.4 Validate attribute group and attribute presence and order 3.1.2.1.4 Validate attribute group and attribute presence and order
The order of the following validation steps depends on The order of the following validation steps depends on
implementation. implementation.
3.1.2.1.4.1 Validate the presence and order of attribute groups 3.1.2.1.4.1 Validate the presence and order of attribute groups
Client requests and IPP object responses contain attribute groups Client requests and IPP object responses contain attribute groups
that Section 3 requires to be present and in a specified order. An 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 IPP object verifies that the attribute groups are present and in the
correct order in requests supplied by clients (attribute groups correct order in requests supplied by clients (attribute groups
without an * in the following tables). without an * in the following tables).
If an IPP object receives a request with (1) required attribute If an IPP object receives a request with (1) required attribute
groups missing, or (2) the attributes groups are out of order, or (3) groups missing, or (2) the attributes groups are out of order, or (3)
the groups are repeated, the IPP object REJECTS the request and the groups are repeated, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' status code. For example, it RETURNS the 'client-error-bad-request' status code. For example, it
skipping to change at page 20, line 21 skipping to change at page 21, line 8
omitted, or for an attribute group to occur more than once, except in omitted, or for an attribute group to occur more than once, except in
the Get-Jobs response. the Get-Jobs response.
Since this kind of attribute group error is most likely to be an 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 error detected by a client developer rather than by a customer, the
IPP object NEED NOT return an indication of which attribute group was IPP object NEED NOT return an indication of which attribute group was
in error in either the Unsupported Attributes group or the Status in error in either the Unsupported Attributes group or the Status
Message. Also, the IPP object NEED NOT find all attribute group Message. Also, the IPP object NEED NOT find all attribute group
errors before returning this error. errors before returning this error.
3.1.2.1.4.2 Ignore unknown attribute groups in the expected position 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 Future attribute groups may be added to the specification at the end
of requests just before the Document Content and at the end of of requests just before the Document Content and at the end of
response, except for the Get-Jobs response, where it maybe there or response, except for the Get-Jobs response, where it maybe there or
before the first job attributes returned. If an IPP object receives before the first job attributes returned. If an IPP object receives
an unknown attribute group in these positions, it ignores the entire 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, 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. group in a later minor version of the protocol that can be ignored.
(If the new attribute group cannot be ignored without confusing the (If the new attribute group cannot be ignored without confusing the
client, the major version number would have been increased in the client, the major version number would have been increased in the
protocol document and in the request). If the unknown group occurs protocol document and in the request). If the unknown group occurs
in a different position, the IPP object REJECTS the request and in a different position, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' status code. RETURNS the 'client-error-bad-request' status code.
Clients also ignore unknown attribute groups returned in a response. Clients also ignore unknown attribute groups returned in a response.
Note: By validating that requests are in the proper form, IPP Note: By validating that requests are in the proper form, IPP
objects force clients to use the proper form which, in turn, objects force clients to use the proper form which, in turn,
increases the chances that customers will be able to use such clients increases the chances that customers will be able to use such clients
from multiple vendors with IPP objects from other vendors. from multiple vendors with IPP objects from other vendors.
3.1.2.1.4.3 Validate the presence of a single occurrence of required 3.1.2.1.4.3 Validate the presence of a single occurrence of required
Operation attributes Operation attributes
Client requests and IPP object responses contain Operation attributes Client requests and IPP object responses contain Operation attributes
that [RFC2911] Section 3 requires to be present. Attributes within a that [RFC2911] Section 3 requires to be present. Attributes within a
group may be in any order, except for the ordering of target, group may be in any order, except for the ordering of target,
charset, and natural languages attributes. These attributes MUST be charset, and natural languages attributes. These attributes MUST be
first, and MUST be supplied in the following order: charset, natural first, and MUST be supplied in the following order: charset, natural
language, and then target. An IPP object verifies that the attributes language, and then target. An IPP object verifies that the
that Section 4 requires to be supplied by the client have been attributes that Section 4 requires to be supplied by the client have
supplied in the request (attributes without an * in the following been supplied in the request (attributes without an * in the
tables). An asterisk (*) indicates groups and Operation attributes following tables). An asterisk (*) indicates groups and Operation
that the client may omit in a request or an IPP object may omit in a attributes that the client may omit in a request or an IPP object may
response. omit in a response.
If an IPP object receives a request with required attributes missing If an IPP object receives a request with required attributes missing
or repeated from a group or in the wrong position, the behavior of or repeated from a group or in the wrong position, the behavior of
the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
implementations are: implementations are:
REJECTS the request and RETURNS the 'client-error-bad-request' REJECTS the request and RETURNS the 'client-error-bad-request'
status code status code
accepts the request and uses the first occurrence of the attribute
accepts the request and uses the first occurrence of the no matter where it is
attribute no matter where it is
accepts the request and uses the last occurrence of the accepts the request and uses the last occurrence of the attribute
attribute no matter where it is no matter where it is
accept the request and assume some default value for the accept the request and assume some default value for the missing
missing attribute attribute
Therefore, client MUST send conforming requests, if they want to Therefore, client MUST send conforming requests, if they want to
receive the same behavior from all IPP object implementations. For receive the same behavior from all IPP object implementations. For
example, it is an error for the "attributes-charset" or "attributes- example, it is an error for the "attributes-charset" or "attributes-
natural-language" attribute to be omitted in any operation request, natural-language" attribute to be omitted in any operation request,
or for an Operation attribute to be supplied in a Job Template group 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 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 group in a create request. It is also an error to supply the
"attributes-charset" attribute twice. "attributes-charset" attribute twice.
skipping to change at page 22, line 13 skipping to change at page 22, line 37
error. error.
The following tables list all the attributes for all the operations The following tables list all the attributes for all the operations
by attribute group in each request and each response. The order of by attribute group in each request and each response. The order of
the groups is the order that the client supplies the groups as the groups is the order that the client supplies the groups as
specified in [RFC2911] Section 3. The order of the attributes within specified in [RFC2911] Section 3. The order of the attributes within
a group is arbitrary, except as noted for some of the special a group is arbitrary, except as noted for some of the special
operation attributes (charset, natural language, and target). The operation attributes (charset, natural language, and target). The
tables below use the following notation: tables below use the following notation:
R indicates a REQUIRED attribute or operation that an IPP object R indicates a REQUIRED attribute or operation that an IPP
MUST support object MUST support
O indicates an OPTIONAL attribute or operation that an IPP O indicates an OPTIONAL attribute or operation that an IPP
object NEED NOT support object NEED NOT support
* indicates that a client MAY omit the attribute in a request * indicates that a client MAY omit the attribute in a request
and that an IPP object MAY omit the attribute in a and that an IPP object MAY omit the attribute in a response.
response. The absence of an * means that a client MUST The absence of an * means that a client MUST supply the
supply the attribute in a request and an IPP object attribute in a request and an IPP object MUST supply the
MUST supply the attribute in a response. attribute in a response.
+ indicates that this is not a IPP/1.0 operation, but is only a + indicates that this is not a IPP/1.0 operation, but is only
part of IPP/1.1 and future versions of IPP. a part of IPP/1.1 and future versions of IPP.
Operation Requests Operation Requests
The tables below show the attributes in their proper attribute groups The tables below show the attributes in their proper attribute groups
for operation requests: for operation requests:
Note: All operation requests contain "version-number", "operation- Note: All operation requests contain "version-number", "operation-
id", and "request-id" parameters. id", and "request-id" parameters.
Print-Job Request (R): Print-Job Request (R):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) printer-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
job-name (R*) job-name (R*)
ipp-attribute-fidelity (R*) ipp-attribute-fidelity (R*)
document-name (R*) document-name (R*)
document-format (R*) document-format (R*)
document-natural-language (O*) document-natural-language (O*)
compression (O*) compression (R*)
job-k-octets (O*) job-k-octets (O*)
job-impressions (O*) job-impressions (O*)
job-media-sheets (O*) job-media-sheets (O*)
Group 2: Job Template Attributes (R*) Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) <Job Template attributes> (O*)
(see [RFC2911] Section 4.2) (see [RFC2911] Section 4.2)
Group 3: Document Content (R) Group 3: Document Content (R)
<document content> <document content>
Validate-Job Request (R): Validate-Job Request (R):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) printer-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
job-name (R*) job-name (R*)
ipp-attribute-fidelity (R*) ipp-attribute-fidelity (R*)
document-name (R*) document-name (R*)
document-format (R*) document-format (R*)
document-natural-language (O*) document-natural-language (O*)
compression (O*) compression (R*)
job-k-octets (O*) job-k-octets (O*)
job-impressions (O*) job-impressions (O*)
job-media-sheets (O*) job-media-sheets (O*)
Group 2: Job Template Attributes (R*) Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) <Job Template attributes> (O*)
(see [RFC2911] Section 4.2) (see [RFC2911] Section 4.2)
Print-URI Request (O): Print-URI Request (O):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) printer-uri (R)
document-uri (R) document-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
job-name (R*) job-name (R*)
ipp-attribute-fidelity (R*) ipp-attribute-fidelity (R*)
document-name (R*) document-name (R*)
document-format (R*) document-format (R*)
document-natural-language (O*) document-natural-language (O*)
compression (O*) compression (R*)
job-k-octets (O*) job-k-octets (O*)
job-impressions (O*) job-impressions (O*)
job-media-sheets (O*) job-media-sheets (O*)
Group 2: Job Template Attributes (R*) Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see <Job Template attributes> (O*) (see
(see [RFC2911] Section 4.2) (see [RFC2911] Section 4.2)
Create-Job Request (O): Create-Job Request (O):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
skipping to change at page 24, line 39 skipping to change at page 25, line 21
Send-Document Request (O): Send-Document Request (O):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R) (printer-uri & job-id) | job-uri (R)
last-document (R) last-document (R)
requesting-user-name (R*) requesting-user-name (R*)
document-name (R*) document-name (R*)
document-format (R*) document-format (R*)
document-natural-language (O*) document-natural-language (O*)
compression (O*) compression (R*)
Group 2: Document Content (R*) Group 2: Document Content (R*)
<document content> <document content>
Send-URI Request (O): Send-URI Request (O):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R) (printer-uri & job-id) | job-uri (R)
last-document (R) last-document (R)
document-uri (R) document-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
document-name (R*) document-name (R*)
document-format (R*) document-format (R*)
document-natural-language (O*) document-natural-language (O*)
compression (O*) compression (R*)
Cancel-Job Request (R): Cancel-Job Request (R):
Release-Job Request (O+): Release-Job Request (O+):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R) (printer-uri & job-id) | job-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
message (O*) message (O*)
skipping to change at page 26, line 4 skipping to change at page 26, line 43
The tables below show the response attributes in their proper The tables below show the response attributes in their proper
attribute groups for responses. attribute groups for responses.
Note: All operation responses contain "version-number", "status- Note: All operation responses contain "version-number", "status-
code", and "request-id" parameters. code", and "request-id" parameters.
Print-Job Response (R): Print-Job Response (R):
Create-Job Response (O): Create-Job Response (O):
Send-Document Response (O): Send-Document Response (O):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
status-message (O*) status-message (O*)
detailed-status-message (O*) detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3) Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*) n <unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2) Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R) job-uri (R)
job-id (R) job-id (R)
job-state (R) job-state (R)
job-state-reasons (O* | R+) job-state-reasons (O* | R+)
job-state-message (O*) job-state-message (O*)
number-of-intervening-jobs (O*) number-of-intervening-jobs (O*)
Validate-Job Response (R): Validate-Job Response (R):
Cancel-Job Response (R): Cancel-Job Response (R):
skipping to change at page 28, line 13 skipping to change at page 29, line 9
return. return.
Note 4 - the Unsupported Attributes Group is present only if the Note 4 - the Unsupported Attributes Group is present only if the
client included some Operation attributes that the Printer doesn't client included some Operation attributes that the Printer doesn't
support whether a success or an error return. support whether a success or an error return.
Note 5: for the Get-Jobs operation the response contains a separate Note 5: for the Get-Jobs operation the response contains a separate
Job Object Attributes group 3 to N containing requested-attributes Job Object Attributes group 3 to N containing requested-attributes
for each job object in the response. for each job object in the response.
3.1.2.1.5 Validate the values of the REQUIRED Operation attributes 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 An IPP object validates the values supplied by the client of the
REQUIRED Operation attribute that the IPP object MUST support. The REQUIRED Operation attribute that the IPP object MUST support. The
next section specifies the validation of the values of the OPTIONAL next section specifies the validation of the values of the OPTIONAL
Operation attributes that IPP objects MAY support. Operation attributes that IPP objects MAY support.
The IPP object performs the following syntactic validation checks of The IPP object performs the following syntactic validation checks of
each Operation attribute value: each Operation attribute value:
a) that the length of each Operation attribute value is a) that the length of each Operation attribute value is correct
correct for the attribute syntax tag supplied by the client for the attribute syntax tag supplied by the client according
according to [RFC2911] Section 4.1, to [RFC2911] Section 4.1,
b) that the attribute syntax tag is correct for that Operation b) that the attribute syntax tag is correct for that Operation
attribute according to [RFC2911] Section 3, attribute according to [RFC2911] Section 3,
c) that the value is in the range specified for that Operation c) that the value is in the range specified for that Operation
attribute according to [RFC2911] Section 3, attribute according to [RFC2911] Section 3,
d) that multiple values are supplied by the client only for d) that multiple values are supplied by the client only for
operation attributes that are multi-valued, i.e., that are 1setOf operation attributes that are multi-valued, i.e., that are
X according to [RFC2911] Section 3. 1setOf X according to [RFC2911] Section 3.
If any of these checks fail, the IPP object REJECTS the request and If any of these checks fail, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' or the 'client-error-request- RETURNS the 'client-error-bad-request' or the 'client-error-request-
value-too-long' status code. Since such an error is most likely to 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- 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 user, the IPP object NEED NOT return an indication of which attribute
had the error in either the Unsupported Attributes Group or the had the error in either the Unsupported Attributes Group or the
Status Message. The description for each of these syntactic checks Status Message. The description for each of these syntactic checks
is explicitly expressed in the first IF statement in the following is explicitly expressed in the first IF statement in the following
table. table.
In addition, the IPP object checks each Operation attribute value In addition, the IPP object checks each Operation attribute value
against some Printer object attribute or some hard-coded value if against some Printer object attribute or some hard-coded value if
there is no "xxx-supported" Printer object attribute defined. If its there is no "xxx-supported" Printer object attribute defined. If its
value is not among those supported or is not in the range supported, 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 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 code indicated in the table by the second IF statement. If the value
of the Printer object's "xxx-supported" attribute is 'no-value' of the Printer object's "xxx-supported" attribute is 'no-value'
(because the system administrator hasn't configured a value), the (because the system administrator hasn't configured a value), the
check always fails. check always fails.
----------------------------------------------- -----------------------------------------------
attributes-charset (charset) attributes-charset (charset)
IF NOT a single non-empty 'charset' value, REJECT/RETURN IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
'client-error-bad-request'. error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 63 octets, REJECT/RETURN
IF NOT in the Printer object's "charset-supported" attribute, 'client-error-request-value-too-long'.
REJECT/RETURN "client-error-charset-not-supported".
IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported".
attributes-natural-language(naturalLanguage) attributes-natural-language(naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'. 'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 63 octets, REJECT/RETURN
ACCEPT the request even if not a member of the set in the 'client-error-request-value-too-long'.
Printer object's "generated-natural-language-supported"
attribute. If the supplied value is not a member of the ACCEPT the request even if not a member of the set in the Printer
Printer object's "generated-natural-language-supported" object's "generated-natural-language-supported" attribute. If the
attribute, use the Printer object's "natural-language- supplied value is not a member of the Printer object's
configured" value. "generated-natural-language-supported" attribute, use the Printer
object's "natural-language- configured" value.
requesting-user-name requesting-user-name
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'. request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF the IPP object can obtain a better-authenticated name, use it 'client-error-request-value-too-long'.
instead.
IF the IPP object can obtain a better-authenticated name, use it
instead.
job-name(name) job-name(name)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'. 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 IF the value length is greater than 255 octets, REJECT/RETURN
from the document-name or document-uri. '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.
document-name (name) document-name (name)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'. request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
ipp-attribute-fidelity (boolean) ipp-attribute-fidelity (boolean)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'. 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 the value length is NOT equal to 1 octet, REJECT/RETURN
IF NOT supplied by the client, the IPP object assumes the value 'client-error-request-value-too-long'
'false'.
IF NOT supplied by the client, the IPP object assumes the value
'false'.
document-format (mimeMediaType) document-format (mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
'client-error-bad-request'. 'client-error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NOT in the Printer object's "document-format-supported" 'client-error-request-value-too-long'.
attribute, REJECT/RETURN 'client-error-document-format-not-
supported' IF NOT in the Printer object's "document-format-supported"
IF NOT supplied by the client, the IPP object assumes the value attribute, REJECT/RETURN 'client-error-document-format-not-
of the Printer object's "document-format-default" supported'
attribute.
IF NOT supplied by the client, the IPP object assumes the value of
the Printer object's "document-format-default" attribute.
document-uri (uri) document-uri (uri)
IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client- IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
error-bad-request'. error-bad-request'.
IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 1023 octets, REJECT/RETURN
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad- 'client-error-request-value-too-long'.
request'.
If the client-supplied URI scheme is not supported, i.e. the IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
value is not in the Printer object's referenced-uri-scheme- request'.
supported" attribute, the Printer object MUST reject the
request and return the 'client-error-uri-scheme-not- If the client-supplied URI scheme is not supported, i.e., the
supported' status code. The Printer object MAY check to see value is not in the Printer object's referenced-uri-scheme-
if the document exists and is accessible. If the document supported" attribute, the Printer object MUST reject the request
is not found or is not accessible, REJECT/RETURN 'client- and return the 'client-error-uri-scheme-not-supported' status
error-not found'. code. The Printer object MAY check to see if the document exists
last-document (boolean) and is accessible. If the document is not found or is not
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, accessible, REJECT/RETURN 'client-error-not found'.
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN last-document (boolean)
'client-error-request-value-too-long'
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)) job-id (integer(1:MAX))
IF NOT an single 'integer' value equal to 4 octets AND in the IF NOT an single 'integer' value equal to 4 octets AND in the
range 1 to MAX, REJECT/RETURN 'client-error-bad-request'. 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 IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
code, if keep track of recently deleted jobs. error-not-found' or 'client-error-gone' status code, if keep track
of recently deleted jobs.
requested-attributes (1setOf keyword) requested-attributes (1setOf keyword)
IF NOT one or more 'keyword' values, REJECT/RETURN 'client- IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
error-bad-request'. error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
Ignore unsupported values, which are the keyword names of 'client-error-request-value-too-long'.
unsupported attributes. Don't bother to copy such
requested (unsupported) attributes to the Unsupported Ignore unsupported values, which are the keyword names of
Attribute response group since the response will not return unsupported attributes. Don't bother to copy such requested
them. (unsupported) attributes to the Unsupported Attribute response
group since the response will not return them.
which-jobs (type2 keyword) which-jobs (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error- IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
bad-request'. request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NEITHER 'completed' NOR 'not-completed', copy the attribute 'client-error-request-value-too-long'.
and the unsupported value to the Unsupported Attributes
response group and REJECT/RETURN 'client-error-attributes- IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
or-values-not-supported'. the unsupported value to the Unsupported Attributes response group
Note: a Printer still supports the 'completed' value even if it and REJECT/RETURN 'client-error-attributes-or-values-not-
keeps no completed/canceled/aborted jobs: by returning no supported'.
jobs when so queried.
IF NOT supplied by the client, the IPP object assumes the 'not- Note: a Printer still supports the 'completed' value even if it
completed' value. 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) my-jobs (boolean)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'. 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 the value length is NOT equal to 1 octet, REJECT/RETURN
IF NOT supplied by the client, the IPP object assumes the 'client-error-request-value-too-long'
'false' value.
IF NOT supplied by the client, the IPP object assumes the 'false'
value.
limit (integer(1:MAX)) limit (integer(1:MAX))
IF NOT a single 'integer' value equal to 4 octets AND in the IF NOT a single 'integer' value equal to 4 octets AND in the range
range 1 to MAX, REJECT/RETURN 'client-error-bad-request'. 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. 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 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
OPTIONAL Operation attributes are those that an IPP object MAY OPTIONAL Operation attributes are those that an IPP object MAY
support. An IPP object validates the values of the OPTIONAL support. An IPP object validates the values of the OPTIONAL
attributes supplied by the client. The IPP object performs the same attributes supplied by the client. The IPP object performs the same
syntactic validation checks for each OPTIONAL attribute value as in 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 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' object REJECTS the request and RETURNS the 'client-error-bad-request'
or the 'client-error-request-value-too-long' status code. or the 'client-error-request-value-too-long' status code.
In addition, the IPP object checks each Operation attribute value In addition, the IPP object checks each Operation attribute value
against some Printer attribute or some hard-coded value if there is against some Printer attribute or some hard-coded value if there is
no "xxx-supported" Printer attribute defined. If its value is not no "xxx-supported" Printer attribute defined. If its value is not
among those supported or is not in the range supported, then the IPP among those supported or is not in the range supported, then the IPP
object REJECTS the request and RETURNS the error status code object REJECTS the request and RETURNS the error status code
indicated in the table. If the value of the Printer object's "xxx- indicated in the table. If the value of the Printer object's "xxx-
supported" attribute is 'no-value' (because the system administrator supported" attribute is 'no-value' (because the system administrator
hasn't configured a value), the check always fails. hasn't configured a value), the check always fails.
If the IPP object doesn't recognize/support an attribute, the IPP If the IPP object doesn't recognize/support an attribute, the IPP
object treats the attribute as an unknown or unsupported attribute object treats the attribute as an unknown or unsupported attribute
(see the last row in the table below). (see the last row in the table below).
----------------------------------------------- -----------------------------------------------
document-natural-language (naturalLanguage) document-natural-language (naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'. 'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 63 octets, REJECT/RETURN
IF NOT a value that the Printer object supports in document 'client-error-request-value-too-long'.
formats, (no corresponding "xxx-supported" Printer attribute),
REJECT/RETURN 'client-error-natural-language-not-supported'. 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) compression (type3 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'. request'.
IF the value length is greater than 255 octets, REJECT/RETURN IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
IF NOT in the Printer object's "compression-supported" attribute,
copy the attribute and the unsupported value to the IF NOT in the Printer object's "compression-supported" attribute,
Unsupported Attributes response group and REJECT/RETURN REJECT/RETURN 'client-error-compression-not-supported'.
'client-error-attributes-or-values-not-supported'.
Note to IPP/1.0 implementers: Support for the "compression" Note to IPP/1.0 implementers: Support for the "compression"
attribute was optional in IPP/1.0 and was changed to REQUIRED attribute was optional in IPP/1.0 and was changed to REQUIRED in
in IPP/1.1. However, an IPP/1.0 object SHOULD at least check IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the
for the "compression" attribute being present and reject the "compression" attribute being present and reject the create
create request, if they don't support "compression". Not request, if they don't support "compression". Not checking is a
checking is a bug, since the data will be unintelligible. bug, since the data will be unintelligible.
job-k-octets (integer(0:MAX)) job-k-octets (integer(0:MAX))
IF NOT a single 'integer' value equal to 4 octets, IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
REJECT/RETURN 'client-error-bad-request'. '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 IF NOT in the range of the Printer object's "job-k-octets-
value to the Unsupported Attributes response group and supported" attribute, copy the attribute and the unsupported value
REJECT/RETURN 'client-error-attributes-or-values-not- to the Unsupported Attributes response group and REJECT/RETURN
supported'. 'client-error-attributes-or-values-not-supported'.
job-impressions (integer(0:MAX)) job-impressions (integer(0:MAX))
IF NOT a single 'integer' value equal to 4 octets, IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
REJECT/RETURN 'client-error-bad-request'. 'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-impressions-
supported" attribute, copy the attribute and the unsupported IF NOT in the range of the Printer object's "job-impressions-
value to the Unsupported Attributes response group and supported" attribute, copy the attribute and the unsupported value
REJECT/RETURN 'client-error-attributes-or-values-not- to the Unsupported Attributes response group and REJECT/RETURN
supported'. 'client-error-attributes-or-values-not-supported'.
job-media-sheets (integer(0:MAX)) job-media-sheets (integer(0:MAX))
IF NOT a single 'integer' value equal to 4 octets, IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
REJECT/RETURN 'client-error-bad-request'. '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 IF NOT in the range of the Printer object's "job-media-sheets-
value to the Unsupported Attributes response group and supported" attribute, copy the attribute and the unsupported value
REJECT/RETURN 'client-error-attributes-or-values-not- to the Unsupported Attributes response group and REJECT/RETURN
supported'. 'client-error-attributes-or-values-not-supported'.
message (text(127)) message (text(127))
IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
request'. request'.
IF the value length is greater than 127 octets,
REJECT/RETURN 'client-error-request-value-too-long'. IF the value length is greater than 127 octets, REJECT/RETURN
'client-error-request-value-too-long'.
unknown or unsupported attribute unknown or unsupported attribute
IF the attribute syntax supplied by the client is supported but the IF the attribute syntax supplied by the client is supported but
length is not legal for that attribute syntax, REJECT/RETURN the length is not legal for that attribute syntax, REJECT/RETURN
'client-error-request-value-too-long'. '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- ELSE copy the attribute and value to the Unsupported Attributes
band" 'unsupported' value, but otherwise ignore the attribute. 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 Note: Future Operation attributes may be added to the protocol
specification that may occur anywhere in the specified group. When specification that may occur anywhere in the specified group. When
the operation is otherwise successful, the IPP object returns the the operation is otherwise successful, the IPP object returns the
'successful-ok-ignored-or-substituted-attributes' status code. 'successful-ok-ignored-or-substituted-attributes' status code.
Ignoring unsupported Operation attributes in all operations is Ignoring unsupported Operation attributes in all operations is
analogous to the handling of unsupported Job Template attributes in analogous to the handling of unsupported Job Template attributes in
the create and Validate-Job operations when the client supplies the the create and Validate-Job operations when the client supplies the
"ipp-attribute-fidelity" Operation attribute with the 'false' value. "ipp-attribute-fidelity" Operation attribute with the 'false' value.
This last rule is so that we can add OPTIONAL Operation attributes to 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 future versions of IPP so that older clients can inter-work with new
IPP objects and newer clients can inter-work with older IPP objects. IPP objects and newer clients can inter-work with older IPP objects.
(If the new attribute cannot be ignored without performing (If the new attribute cannot be ignored without performing
unexpectedly, the major version number would have been increased in unexpectedly, the major version number would have been increased in
the protocol document and in the request). This rule for Operation the protocol document and in the request). This rule for Operation
attributes is independent of the value of the "ipp-attribute- attributes is independent of the value of the "ipp-attribute-
fidelity" attribute. For example, if an IPP object doesn't support fidelity" attribute. For example, if an IPP object doesn't support
the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k- the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-
octets" as an unknown attribute and only checks the length for the 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 'integer' attribute syntax supplied by the client. If it is not four
octets, the IPP object REJECTS the request and RETURNS the 'client- octets, the IPP object REJECTS the request and RETURNS the 'client-
error-bad-request' status code, else the IPP object copies the error-bad-request' status code, else the IPP object copies the
attribute to the Unsupported Attribute response group, setting the attribute to the Unsupported Attribute response group, setting the
value to the "out-of-band" 'unsupported' value, but otherwise ignores value to the "out-of-band" 'unsupported' value, but otherwise ignores
the attribute. the attribute.
3.1.2.2 Suggested Additional Processing Steps for Operations that 3.1.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents Create/Validate Jobs and Add Documents
This section in combination with the previous section recommends the This section in combination with the previous section recommends the
processing steps for the Print-Job, Validate-Job, Print-URI, Create- processing steps for the Print-Job, Validate-Job, Print-URI, Create-
Job, Send-Document, and Send-URI operations that IPP objects SHOULD Job, Send-Document, and Send-URI operations that IPP objects SHOULD
use. These are the operations that create jobs, validate a Print-Job use. These are the operations that create jobs, validate a Print-Job
request, and add documents to a job. request, and add documents to a job.
IIG Sect # Flow IPP error status codes IIG Sect # Flow IPP error status codes
---------- ---- ---------------------- ---------- ---- ----------------------
| |
skipping to change at page 35, line 43 skipping to change at page 37, line 43
ok| ok|
v err v err
3.1.2.3 <Validate values with> --> client-error-bad-request 3.1.2.3 <Validate values with> --> client-error-bad-request
<supported values> client-error-attributes-or- <supported values> client-error-attributes-or-
| values-not-supported | values-not-supported
v err v err
3.1.2.3.1 <Any conflicting> --> client-error-conflicting- 3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
attributes attributes
<Job Template attr values> client-error-attributes-or- <Job Template attr values> client-error-attributes-or-
values-not-supported values-not-supported
v v
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied
The Printer object checks to see if the client supplied an "ipp- The Printer object checks to see if the client supplied an "ipp-
attribute-fidelity" Operation attribute. If the attribute is not attribute-fidelity" Operation attribute. If the attribute is not
supplied by the client, the IPP object assumes that the value is supplied by the client, the IPP object assumes that the value is
'false'. 'false'.
3.1.2.2.2 Check that the Printer object is accepting jobs 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 If the value of the Printer objects "printer-is-accepting-jobs" is
'false', the Printer object REJECTS the request and RETURNS the 'false', the Printer object REJECTS the request and RETURNS the
'server-error-not-accepting-jobs' status code. 'server-error-not-accepting-jobs' status code.
3.1.2.2.3 Validate the values of the Job Template attributes 3.1.2.2.3 Validate the values of the Job Template attributes
An IPP object validates the values of all Job Template attribute An IPP object validates the values of all Job Template attribute
supplied by the client. The IPP object performs the analogous supplied by the client. The IPP object performs the analogous
syntactic validation checks of each Job Template attribute value that syntactic validation checks of each Job Template attribute value that
it performs for Operation attributes (see Section 3.1.2.1.5.): it performs for Operation attributes (see Section 3.1.2.1.5.):
a) that the length of each value is correct for the attribute a) that the length of each value is correct for the attribute
syntax tag supplied by the client according to [RFC2911] Section syntax tag supplied by the client according to [RFC2911]
4.1. Section 4.1.
b) that the attribute syntax tag is correct for that attribute b) that the attribute syntax tag is correct for that attribute
according to [RFC2911] Sections 4.2 to 4.4. according to [RFC2911] Sections 4.2 to 4.4.
c) that multiple values are supplied only for multi-valued c) that multiple values are supplied only for multi-valued
attributes, i.e., that are 1setOf X according to [RFC2911] attributes, i.e., that are 1setOf X according to [RFC2911]
Sections 4.2 to 4.4. Sections 4.2 to 4.4.
As in Section 3.1.2.1.5, if any of these syntactic checks fail, the 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- IPP object REJECTS the request and RETURNS the 'client-error-bad-
request' or 'client-error-request-value-too-long' status code as request' or 'client-error-request-value-too-long' status code as
appropriate, independent of the value of the "ipp-attribute- appropriate, independent of the value of the "ipp-attribute-
fidelity". Since such an error is most likely to be an error 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 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 object NEED NOT return an indication of which attribute had the error
in either the Unsupported Attributes Group or the Status Message. in either the Unsupported Attributes Group or the Status Message.
The description for each of these syntactic checks is explicitly The description for each of these syntactic checks is explicitly
expressed in the first IF statement in the following table. expressed in the first IF statement in the following table.
Each Job Template attribute MUST occur no more than once. If an IPP Each Job Template attribute MUST occur no more than once. If an IPP
Printer receives a create request with multiple occurrences of a Job Printer receives a create request with multiple occurrences of a Job
Template attribute, it MAY: Template attribute, it MAY:
1. reject the operation and return the 'client-error-bad-request' 1. reject the operation and return the 'client-error-bad-request'
error status code error status code
2. accept the operation and use the first occurrence of the 2. accept the operation and use the first occurrence of the
attribute attribute
3. accept the operation and use the last occurrence of the 3. accept the operation and use the last occurrence of the
attribute attribute
depending on implementation. Therefore, clients MUST NOT supply depending on implementation. Therefore, clients MUST NOT supply
multiple occurrences of the same Job Template attribute in the Job multiple occurrences of the same Job Template attribute in the Job
Attributes group in the request. Attributes group in the request.
3.1.2.3 Algorithm for job validation 3.1.2.3 Algorithm for job validation
The process of validating a Job-Template attribute "xxx" against a The process of validating a Job-Template attribute "xxx" against a
Printer attribute "xxx-supported" can use the following validation Printer attribute "xxx-supported" can use the following validation
algorithm (see section 3.2.1.2 in [RFC2911]). algorithm (see section 3.2.1.2 in [RFC2911]).
To validate the value U of Job-Template attribute "xxx" against the To validate the value U of Job-Template attribute "xxx" against the
value V of Printer "xxx-supported", perform the following value V of Printer "xxx-supported", perform the following algorithm:
algorithm:
1.If U is multi-valued, validate each value X of U by performing 1. If U is multi-valued, validate each value X of U by performing the
the algorithm in Table 7 with each value X. Each validation is algorithm in Table 7 with each value X. Each validation is
separate from the standpoint of returning unsupported values. separate from the standpoint of returning unsupported values.
Example: If U is "finishings" that the client supplies with Example: If U is "finishings" that the client supplies with
'staple', 'bind' values, then X takes on the successive values: 'staple', 'bind' values, then X takes on the successive values:
'staple', then 'bind' 'staple', then 'bind'
2.If V is multi-valued, validate X against each Z of V by 2. If V is multi-valued, validate X against each Z of V by performing
performing the algorithm in Table 7 with each value Z. If a the algorithm in Table 7 with each value Z. If a value Z
value Z validates, the validation for the attribute value X validates, the validation for the attribute value X succeeds. If
succeeds. If it fails, the algorithm is applied to the next it fails, the algorithm is applied to the next value Z of V. If
value Z of V. If there are no more values Z of V, validation there are no more values Z of V, validation fails. Example" If V
fails. Example" If V is "sides-supported" with values: 'one- is "sides-supported" with values: 'one- sided', 'two-sided-long',
sided', 'two-sided-long', and 'two-sided-short', then Z takes on and 'two-sided-short', then Z takes on the successive values:
the successive values: 'one-sided', 'two-sided-long', and 'two- 'one-sided', 'two-sided-long', and 'two-sided-short'. If the
sided-short'. If the client supplies "sides" with 'two-sided- client supplies "sides" with 'two-sided- long', the first
long', the first comparison fails ('one-sided' is not equal to comparison fails ('one-sided' is not equal to 'two-sided-long'),
'two-sided-long'), the second comparison succeeds ('two-sided- the second comparison succeeds ('two-sided-long' is equal to
long' is equal to 'two-sided-long"), and the third comparison 'two-sided-long"), and the third comparison ('two-sided-short'
('two-sided-short' with 'two-sided-long') is not even performed. 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 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. the validation rules in Table 7.
Table 7 - Rules for validating single values X against Z Table 7 - Rules for validating single values X against Z
Attribute syntax attribute syntax validated if: Attribute syntax attribute syntax validated if:
of X of Z of X of Z
integer rangeOfInteger X is within the range of Z integer rangeOfInteger X is within the range of Z
uri uriScheme the uri scheme in X is equal to uri uriScheme the uri scheme in X is equal to
Z Z
skipping to change at page 39, line 6 skipping to change at page 41, line 4
"document-format" operation attribute. See "document-format" in "document-format" operation attribute. See "document-format" in
[RFC2911] section 3.2.1.1 and 3.2.5.1. [RFC2911] section 3.2.1.1 and 3.2.5.1.
Note: whether the request is accepted or rejected is determined by Note: whether the request is accepted or rejected is determined by
the value of the "ipp-attribute-fidelity" attribute in a subsequent the value of the "ipp-attribute-fidelity" attribute in a subsequent
step, so that all Job Template attribute supplied are examined and step, so that all Job Template attribute supplied are examined and
all unsupported attributes and/or values are copied to the all unsupported attributes and/or values are copied to the
Unsupported Attributes response group. Unsupported Attributes response group.
----------------------------------------------- -----------------------------------------------
job-priority (integer(1:100)) job-priority (integer(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets, IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. 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 IF NOT supplied by the client, use the value of the Printer
time. 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 IF NOT in the range 1 to 100, inclusive, copy the attribute and
group. the unsupported value to the Unsupported Attributes response
Map the value to the nearest supported value in the range 1:100 as group.
specified by the number of discrete values indicated by the
value of the Printer's "job-priority-supported" attribute. Map the value to the nearest supported value in the range 1:100 as
See the formula in [RFC2911] Section 4.2.1. 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) job-hold-until (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'. error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NOT supplied by the client, use the value of the Printer 'client-error-request-value-too-long'.
object's "job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported" IF NOT supplied by the client, use the value of the Printer
attribute, copy the attribute and the unsupported value to the object's "job-hold-until" attribute at job submission time.
Unsupported Attributes response group.
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) job-sheets (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'. error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NOT in the Printer object's "job-sheets-supported" attribute, 'client-error-request-value-too-long'.
copy the attribute and the unsupported value to the
Unsupported Attributes response group. 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) multiple-document-handling (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'. request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NOT in the Printer object's "multiple-document-handling- 'client-error-request-value-too-long'.
supported" attribute, copy the attribute and the unsupported
value to the Unsupported Attributes response group. 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)) 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 a single 'integer' value with a length equal to 4 octets,
IF NOT in range of the Printer object's "copies-supported" REJECT/RETURN 'client-error-bad-request'.
attribute
copy the attribute and the unsupported value to the Unsupported IF NOT in range of the Printer object's "copies-supported"
Attributes response group. attribute
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
finishings (1setOf type2 enum) finishings (1setOf type2 enum)
IF NOT an 'enum' value(s) each with a length equal to 4 octets, IF NOT an 'enum' value(s) each with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. 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 IF NOT in the Printer object's "finishings-supported" attribute,
supported values, to the Unsupported Attributes response copy the attribute and the unsupported value(s), but not any
group. supported values, to the Unsupported Attributes response group.
page-ranges (1setOf rangeOfInteger(1:MAX)) page-ranges (1setOf rangeOfInteger(1:MAX))
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
octets, REJECT/RETURN 'client-error-bad-request'. 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, IF first value is greater than second value in any range, the
REJECT/RETURN 'client-error-bad-request'. ranges are not in ascending order, or ranges overlap,
IF the value of the Printer object's "page-ranges-supported" REJECT/RETURN 'client-error-bad-request'.
attribute is 'false', copy the attribute to the Unsupported
Attributes response group and set the value to the "out-of- IF the value of the Printer object's "page-ranges-supported"
band" 'unsupported' value. 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) sides (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'. request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NOT in the Printer object's "sides-supported" attribute, copy 'client-error-request-value-too-long'.
the attribute and the unsupported value to the Unsupported
Attributes response group. 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)) number-up (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets, IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. 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 IF NOT a value or in the range of one of the values of the Printer
and value to the Unsupported Attribute response group. object's "number-up-supported" attribute, copy the attribute and
value to the Unsupported Attribute response group.
orientation-requested (type2 enum) orientation-requested (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets, IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "orientation-requested-supported" IF NOT in the Printer object's "orientation-requested-supported"
attribute, copy the attribute and the unsupported value to the attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group. Unsupported Attributes response group.
media (type3 keyword | name) media (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'. error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. IF the value length is greater than 255 octets, REJECT/RETURN
IF NOT in the Printer object's "media-supported" attribute, copy 'client-error-request-value-too-long'.
the attribute and the unsupported value to the Unsupported
Attributes response group. 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) printer-resolution (resolution)
IF NOT a single 'resolution' value with a length equal to 9 octets, IF NOT a single 'resolution' value with a length equal to 9
REJECT/RETURN 'client-error-bad-request'. 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 IF NOT in the Printer object's "printer-resolution-supported"
Unsupported Attributes response group. attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
print-quality (type2 enum) print-quality (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets, IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
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 IF NOT in the Printer object's "print-quality-supported"
Printer object "xxx-supported" attribute) attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
IF the attribute syntax supplied by the client is supported but the unknown or unsupported attribute (i.e., there is no corresponding
length is not legal for that attribute syntax, Printer object "xxx-supported" attribute)
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:
Name Octet length check for read-write attributes IF the attribute syntax supplied by the client is supported but
----------- -------------------------------------------- the length is not legal for that attribute syntax,
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
'textWithoutLanguage' <= 1023 REJECT/RETURN 'client-error-bad-request' if the length of the
'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 attribute syntax is fixed or 'client-error-request-value-too-long'
'nameWithoutLanguage' <= 255 if the length of the attribute syntax is variable.
'keyword' <= 255
'enum' = 4 ELSE copy the attribute and value to the Unsupported Attributes
'uri' <= 1023 response group and change the attribute value to the "out-of-band"
'uriScheme' <= 63 'unsupported' value. Any remaining Job Template Attributes are
'charset' <= 63 either unknown or unsupported Job Template attributes and are
'naturalLanguage' <= 63 validated algorithmically according to their attribute syntax for
'mimeMediaType' <= 255 proper length (see below).
'octetString' <= 1023
'boolean' = 1 -----------------------------------------------
'integer' = 4
'rangeOfInteger' = 8 If the attribute syntax is supported AND the length check fails,
'dateTime' = 11 the IPP object REJECTS the request and RETURNS the 'client-error-
'resolution' = 9 bad-request' if the length of the attribute syntax is fixed or the
'1setOf X' '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:
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 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 in a request. Since this is a keyword, its value needs to be
compared with the supported values. Assuming that the printer compared with the supported values. Assuming that the printer
doesn't have any values in its corresponding "xxx-supported" doesn't have any values in its corresponding "xxx-supported"
attribute that are keywords of zero length, the comparison will fail. attribute that are keywords of zero length, the comparison will fail.
Then the request will be accepted or rejected depending on the value Then the request will be accepted or rejected depending on the value
of "ipp-attributes-fidelity" being 'false' or 'true', respectively. of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
No special handling is required for No special handling is required for
3.1.2.3.1 Check for conflicting Job Template attributes values 3.1.2.3.1 Check for conflicting Job Template attributes values
Once all the Operation and Job Template attributes have been checked Once all the Operation and Job Template attributes have been checked
individually, the Printer object SHOULD check for any conflicting individually, the Printer object SHOULD check for any conflicting
values among all the supported values supplied by the client. For values among all the supported values supplied by the client. For
example, a Printer object might be able to staple and to print on example, a Printer object might be able to staple and to print on
transparencies, however due to physical stapling constraints, the transparencies, however due to physical stapling constraints, the
Printer object might not be able to staple transparencies. The IPP Printer object might not be able to staple transparencies. The IPP
object copies the supported attributes and their conflicting object copies the supported attributes and their conflicting
attribute values to the Unsupported Attributes response group. The attribute values to the Unsupported Attributes response group. The
Printer object only copies over those attributes that the Printer Printer object only copies over those attributes that the Printer
object either ignores or substitutes in order to resolve the object either ignores or substitutes in order to resolve the
conflict, and it returns the original values which were supplied by conflict, and it returns the original values which were supplied by
the client. For example suppose the client supplies "finishings" the client. For example suppose the client supplies "finishings"
equals 'staple' and "media" equals 'transparency', but the Printer equals 'staple' and "media" equals 'transparency', but the Printer
object does not support stapling transparencies. If the Printer object does not support stapling transparencies. If the Printer
chooses to ignore the stapling request in order to resolve the chooses to ignore the stapling request in order to resolve the
conflict, the Printer objects returns "finishings" equal to 'staple' conflict, the Printer objects returns "finishings" equal to 'staple'
in the Unsupported Attributes response group. If any attributes are in the Unsupported Attributes response group. If any attributes are
multi-valued, only the conflicting values of the attributes are multi-valued, only the conflicting values of the attributes are
copied. copied.
Note: The decisions made to resolve the conflict (if there is a Note: The decisions made to resolve the conflict (if there is a
choice) is implementation dependent. choice) is implementation dependent.
3.1.2.3.2 Decide whether to REJECT the request 3.1.2.3.2 Decide whether to REJECT the request
If there were any unsupported Job Template attributes or If there were any unsupported Job Template attributes or
unsupported/conflicting Job Template attribute values and the client unsupported/conflicting Job Template attribute values and the client
supplied the "ipp-attribute-fidelity" attribute with the 'true' supplied the "ipp-attribute-fidelity" attribute with the 'true'
value, the Printer object REJECTS the request and return the status value, the Printer object REJECTS the request and return the status
code: code:
1. 'client-error-conflicting-attributes' status code, if there were 1.'client-error-conflicting-attributes' status code, if there were
any conflicts between attributes supplied by the client. any conflicts between attributes supplied by the client.
2. 'client-error-attributes-or-values-not-supported' status code,
otherwise. 2.'client-error-attributes-or-values-not-supported' status code,
otherwise.
Note: Unsupported Operation attributes or values that are returned Note: Unsupported Operation attributes or values that are returned
do not affect the status returned in this step. If the unsupported do not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with the request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious unsupported Operation attributes being returned, they are not serious
errors. errors.
In general, the final results of Job processing are unknown at Job In general, the final results of Job processing are unknown at Job
submission time. The client has to rely on notifications or polling submission time. The client has to rely on notifications or polling
skipping to change at page 44, line 19 skipping to change at page 46, line 47
that Job processing is going to fail. As an optimization, we'd like that Job processing is going to fail. As an optimization, we'd like
to have the Printer reject the Job in these cases. to have the Printer reject the Job in these cases.
There are three types of "processing" errors that might be detectable There are three types of "processing" errors that might be detectable
at Job submission time: at Job submission time:
1. 'client-error-document-format-not-supported' : For the Print- 1. 'client-error-document-format-not-supported' : For the Print-
Job, Send-Document, Print-URI, and Send-URI operations, if all these Job, Send-Document, Print-URI, and Send-URI operations, if all these
conditions are true: conditions are true:
- the Printer supports auto-sensing, - the Printer supports auto-sensing,
- the request "document-format" operation attribute is - the request "document-format" operation attribute is
'application/octet-stream', 'application/octet-stream',
- the Printer receives document data before responding, - the Printer receives document data before responding,
- the Printer auto-senses the document format before responding, - the Printer auto-senses the document format before responding,
- the sensed document format is not supported by the Printer - the sensed document format is not supported by the Printer
then the Printer should respond with 'client-error-document-format- then the Printer should respond with 'client-error-document-format-
not-supported' status. not-supported' status.
2. 'client-error-compression-error': For the Print-Job, Send- 2. 'client-error-compression-error': For the Print-Job, Send-
Document, Print-URI, and Send-URI operations, if all these Document, Print-URI, and Send-URI operations, if all these
conditions are true: conditions are true:
- the client supplies a supported value for the "compression" - the client supplies a supported value for the "compression"
operation attribute in the request operation attribute in the request
- the Printer receives document data before responding, - the Printer receives document data before responding,
- the Printer attempts to decompress the document data before - the Printer attempts to decompress the document data before
responding, responding,
- the document data cannot be decompressed using the algorithm - the document data cannot be decompressed using the algorithm
specified by the "compression" operation attribute specified by the "compression" operation attribute
then the Printer should respond with 'client-error-compression-error' then the Printer should respond with 'client-error-compression-error'
status. status.
3. 'client-error-document-access-error': For the Print-URI, and 3. 'client-error-document-access-error': For the Print-URI, and
Send-URI operations, if the Printer attempts and fails to pull the Send-URI operations, if the Printer attempts and fails to pull the
referenced document data before responding, it should respond with referenced document data before responding, it should respond with
'client-error-document-access-error' status. 'client-error-document-access-error' status.
Some Printers are not able to detect these errors until Job Some Printers are not able to detect these errors until Job
processing time. In that case, the errors are recorded in the processing time. In that case, the errors are recorded in the
skipping to change at page 45, line 25 skipping to change at page 48, line 5
A client should always provide a valid "document-format" operation A client should always provide a valid "document-format" operation
attribute whenever practical. In the absence of other information, a attribute whenever practical. In the absence of other information, a
client itself may sniff the document data to determine document client itself may sniff the document data to determine document
format. format.
Auto sensing at Job submission time may be more difficult for the Auto sensing at Job submission time may be more difficult for the
Printer when combined with compression. For auto-sensed Jobs, a Printer when combined with compression. For auto-sensed Jobs, a
client may be better off deferring compression to the transfer client may be better off deferring compression to the transfer
protocol layer, e.g.; by using the HTTP Content-Encoding header. protocol layer, e.g.; by using the HTTP Content-Encoding header.
3.1.2.3.3 For the Validate-Job operation, RETURN one of the success 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
status codes status codes
If the requested operation is the Validate-Job operation, the Printer If the requested operation is the Validate-Job operation, the Printer
object returns: object returns:
1. the "successful-ok" status code, if there are no unsupported or 1. the "successful-ok" status code, if there are no unsupported or
conflicting Job Template attributes or values. conflicting Job Template attributes or values.
2. the "successful-ok-conflicting-attributes, if there are any 2. the "successful-ok-conflicting-attributes, if there are any
conflicting Job Template attribute or values. conflicting Job Template attribute or values.
3. the "successful-ok-ignored-or-substituted-attributes, if there 3. the "successful-ok-ignored-or-substituted-attributes, if there
are only unsupported Job Template attributes or values. are only unsupported Job Template attributes or values.
Note: Unsupported Operation attributes or values that are returned Note: Unsupported Operation attributes or values that are returned
do not affect the status returned in this step. If the unsupported do not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with the request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious unsupported Operation attributes being returned, they are not serious
errors. errors.
3.1.2.3.4 Create the Job object with attributes to support 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 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
by the client), the Printer object: by the client), the Printer object:
1. creates a Job object, assigns a unique value to the job's "job- 1. creates a Job object, assigns a unique value to the job's
uri" and "job-id" attributes, and initializes all of the job's "job-uri" and "job-id" attributes, and initializes all of the
other supported Job Description attributes. job's other supported Job Description attributes.
2. removes all unsupported attributes from the Job object. 2. removes all unsupported attributes from the Job object.
3. for each unsupported value, removes either the unsupported value 3. for each unsupported value, removes either the unsupported
or substitutes the unsupported attribute value with some value or substitutes the unsupported attribute value with some
supported value. If an attribute has no values after removing supported value. If an attribute has no values after removing
unsupported values from it, the attribute is removed from the unsupported values from it, the attribute is removed from the
Job object (so that the normal default behavior at job Job object (so that the normal default behavior at job
processing time will take place for that attribute). processing time will take place for that attribute).
4. for each conflicting value, removes either the conflicting value 4. for each conflicting value, removes either the conflicting
or substitutes the conflicting attribute value with some other value or substitutes the conflicting attribute value with some
supported value. If an attribute has no values after removing other supported value. If an attribute has no values after
conflicting values from it, the attribute is removed from the removing conflicting values from it, the attribute is removed
Job object (so that the normal default behavior at job from the Job object (so that the normal default behavior at job
processing time will take place for that attribute). processing time will take place for that attribute).
If there were no attributes or values flagged as unsupported, or the If there were no attributes or values flagged as unsupported, or the
value of 'ipp-attribute-fidelity" was 'false', the Printer object is value of 'ipp-attribute-fidelity" was 'false', the Printer object is
able to accept the create request and create a new Job object. If able to accept the create request and create a new Job object. If
the "ipp-attribute-fidelity" attribute is set to 'true', the Job the "ipp-attribute-fidelity" attribute is set to 'true', the Job
Template attributes that populate the new Job object are necessarily Template attributes that populate the new Job object are necessarily
all the Job Template attributes supplied in the create request. If all the Job Template attributes supplied in the create request. If
the "ipp-attribute-fidelity" attribute is set to 'false', the Job the "ipp-attribute-fidelity" attribute is set to 'false', the Job
Template attributes that populate the new Job object are all the Template attributes that populate the new Job object are all the
client supplied Job Template attributes that are supported or that client supplied Job Template attributes that are supported or that
skipping to change at page 47, line 11 skipping to change at page 49, line 30
may query the Printer's "pdl-override-supported" attribute to may query the Printer's "pdl-override-supported" attribute to
determine if the Printer either attempts or does not attempt to determine if the Printer either attempts or does not attempt to
override document data instructions with IPP attributes. override document data instructions with IPP attributes.
There are some cases, where a Printer supports a Job Template There are some cases, where a Printer supports a Job Template
attribute and has an associated default value set for that attribute. attribute and has an associated default value set for that attribute.
In the case where a client does not supply the corresponding In the case where a client does not supply the corresponding
attribute, the Printer does not use its default values to populate attribute, the Printer does not use its default values to populate
Job attributes when creating the new Job object; only Job Template Job attributes when creating the new Job object; only Job Template
attributes actually in the create request are used to populate the attributes actually in the create request are used to populate the
Job object. The Printer's default values are only used later at Job Job object. The Printer's default values are only used later at Job
processing time if no other IPP attribute or instruction embedded in processing time if no other IPP attribute or instruction embedded in
the document data is present. the document data is present.
Note: If the default values associated with Job Template attributes Note: If the default values associated with Job Template attributes
that the client did not supply were to be used to populate the Job that the client did not supply were to be used to populate the Job
object, then these values would become "override values" rather than object, then these values would become "override values" rather than
defaults. If the Printer supports the 'attempted' value of the "pdl- defaults. If the Printer supports the 'attempted' value of the
override-supported" attribute, then these override values could "pdl-override-supported" attribute, then these override values could
replace values specified within the document data. This is not the replace values specified within the document data. This is not the
intent of the default value mechanism. A default value for an intent of the default value mechanism. A default value for an
attribute is used only if the create request did not specify that attribute is used only if the create request did not specify that
attribute (or it was ignored when allowed by "ipp-attribute-fidelity" attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
being 'false') and no value was provided within the content of the being 'false') and no value was provided within the content of the
document data. document data.
If the client does not supply a value for some Job Template If the client does not supply a value for some Job Template
attribute, and the Printer does not support that attribute, as far as attribute, and the Printer does not support that attribute, as far as
IPP is concerned, the result of processing that Job (with respect to IPP is concerned, the result of processing that Job (with respect to
the missing attribute) is undefined. the missing attribute) is undefined.
3.1.2.3.5 Return one of the success status codes 3.1.2.3.5 Return one of the success status codes
Once the Job object has been created, the Printer object accepts the Once the Job object has been created, the Printer object accepts the
request and returns to the client: request and returns to the client:
1. the 'successful-ok' status code, if there are no unsupported or 1. the 'successful-ok' status code, if there are no unsupported or
conflicting Job Template attributes or values. conflicting Job Template attributes or values.
2. the 'successful-ok-conflicting-attributes' status code, if there 2. the 'successful-ok-conflicting-attributes' status code, if
are any conflicting Job Template attribute or values. there are any conflicting Job Template attribute or values.
3. the 'successful-ok-ignored-or-substituted-attributes' status 3. the 'successful-ok-ignored-or-substituted-attributes' status
code, if there are only unsupported Job Template attributes or code, if there are only unsupported Job Template attributes or
values. values.
Note: Unsupported Operation attributes or values that are returned Note: Unsupported Operation attributes or values that are returned
do not affect the status returned in this step. If the unsupported do not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with the request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious unsupported Operation attributes being returned, they are not serious
errors. errors.
The Printer object also returns Job status attributes that indicate The Printer object also returns Job status attributes that indicate
the initial state of the Job ('pending', 'pending-held', the initial state of the Job ('pending', 'pending-held',
'processing', etc.), etc. See Print-Job Response, [RFC2911] section 'processing', etc.), etc. See Print-Job Response, [RFC2911] section
3.2.1.2. 3.2.1.2.
3.1.2.3.6 Accept appended Document Content 3.1.2.3.6 Accept appended Document Content
The Printer object accepts the appended Document Content data and The Printer object accepts the appended Document Content data and
either starts it printing, or spools it for later processing. either starts it printing, or spools it for later processing.
3.1.2.3.7 Scheduling and Starting to Process the Job 3.1.2.3.7 Scheduling and Starting to Process the Job
The Printer object uses its own configuration and implementation The Printer object uses its own configuration and implementation
specific algorithms for scheduling the Job in the correct processing specific algorithms for scheduling the Job in the correct processing
order. Once the Printer object begins processing the Job, the order. Once the Printer object begins processing the Job, the
Printer changes the Job's state to 'processing'. If the Printer Printer changes the Job's state to 'processing'. If the Printer
object supports PDL override (the "pdl-override-supported" attribute object supports PDL override (the "pdl-override-supported" attribute
set to 'attempted'), the implementation does its best to see that IPP set to 'attempted'), the implementation does its best to see that IPP
attributes take precedence over embedded instructions in the document attributes take precedence over embedded instructions in the document
data. data.
3.1.2.3.8 Completing the Job 3.1.2.3.8 Completing the Job
The Printer object continues to process the Job until it can move the The Printer object continues to process the Job until it can move the
Job into the 'completed' state. If an Cancel-Job operation is Job into the 'completed' state. If an Cancel-Job operation is
received, the implementation eventually moves the Job into the received, the implementation eventually moves the Job into the
'canceled' state. If the system encounters errors during processing 'canceled' state. If the system encounters errors during processing
that do not allow it to progress the Job into a completed state, the that do not allow it to progress the Job into a completed state, the
implementation halts all processing, cleans up any resources, and implementation halts all processing, cleans up any resources, and
moves the Job into the 'aborted' state. moves the Job into the 'aborted' state.
3.1.2.3.9 Destroying the Job after completion 3.1.2.3.9 Destroying the Job after completion
Once the Job moves to the 'completed', 'aborted', or 'canceled' Once the Job moves to the 'completed', 'aborted', or 'canceled'
state, it is an implementation decision as to when to destroy the Job state, it is an implementation decision as to when to destroy the Job
object and release all associated resources. Once the Job has been object and release all associated resources. Once the Job has been
destroyed, the Printer would return either the "client-error-not- destroyed, the Printer would return either the "client-error-not-
found" or "client-error-gone" status codes for operations directed at found" or "client-error-gone" status codes for operations directed at
that Job. that Job.
Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" 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 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 that stale references kept by clients are less likely to access the
wrong (newer) job. wrong (newer) job.
3.1.2.3.10 Interaction with "ipp-attribute-fidelity" 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"
Some Printer object implementations may support "ipp-attribute- Some Printer object implementations may support "ipp-attribute-
fidelity" set to 'true' and "pdl-override-supported" set to fidelity" set to 'true' and "pdl-override-supported" set to
'attempted' and yet still not be able to realize exactly what the 'attempted' and yet still not be able to realize exactly what the
client specifies in the create request. This is due to legacy client specifies in the create request. This is due to legacy
decisions and assumptions that have been made about the role of job decisions and assumptions that have been made about the role of job
instructions embedded within the document data and external job instructions embedded within the document data and external job
instructions that accompany the document data and how to handle instructions that accompany the document data and how to handle
conflicts between such instructions. The inability to be 100% conflicts between such instructions. The inability to be 100%
precise about how a given implementation will behave is also precise about how a given implementation will behave is also
compounded by the fact that the two special attributes, "ipp- compounded by the fact that the two special attributes, "ipp-
attribute-fidelity" and "pdl-"override-supported", apply to the whole attribute-fidelity" and "pdl-"override-supported", apply to the whole
job rather than specific values for each attribute. For example, some job rather than specific values for each attribute. For example, some
implementations may be able to override almost all Job Template implementations may be able to override almost all Job Template
attributes except for "number-up". Character Sets, natural languages, attributes except for "number-up". Character Sets, natural
and internationalization languages, and internationalization
This section discusses character set support, natural language This section discusses character set support, natural language
support and internationalization. support and internationalization.
3.1.2.3.11 Character set code conversion support 3.1.2.3.11 Character set code conversion support
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY
support additional charsets. It is RECOMMENDED that an IPP object support additional charsets. It is RECOMMENDED that an IPP object
also support US-ASCII, since many clients support US-ASCII, and also support US-ASCII, since many clients support US-ASCII, and
indicate that UTF-8 and US-ASCII are supported by populating the indicate that UTF-8 and US-ASCII are supported by populating the
Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An 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 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 between the charsets that it supports, as indicated in the Printer's
"charsets-supported" attribute. "charsets-supported" attribute.
How should the server handle the situation where the "attributes- How should the server handle the situation where the "attributes-
charset" of the response itself is "us-ascii", but one or more charset" of the response itself is "us-ascii", but one or more
attributes in that response is in the "utf-8" format? attributes in that response is in the "utf-8" format?
Example: Consider a case where a client sends a Print-Job request 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- with "utf-8" as the value of "attributes-charset" and with the "job-
name" attribute supplied. Later another client submits a Get-Job- name" attribute supplied. Later another client submits a Get-Job-
Attribute or Get-Jobs request. This second request contains the Attribute or Get-Jobs request. This second request contains the
"attributes-charset" with value "us-ascii" and "requested-attributes" "attributes-charset" with value "us-ascii" and "requested-attributes"
attribute with exactly one value "job-name". attribute with exactly one value "job-name".
According to the RFC2911 document (section 3.1.4.2), the value of the 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 "attributes-charset" for the response of the second request must be
"us-ascii" since that is the charset specified in the request. The "us-ascii" since that is the charset specified in the request. The
"job-name" value, however, is in "utf-8" format. Should the request "job-name" value, however, is in "utf-8" format. Should the request
be rejected even though both "utf-8" and "us-ascii" charsets are be rejected even though both "utf-8" and "us-ascii" charsets are
supported by the server? or should the "job-name" value be converted supported by the server? or should the "job-name" value be converted
to "us-ascii" and return "successful-ok-conflicting-attributes" to "us-ascii" and return "successful-ok-conflicting-attributes"
(0x0002) as the status code? (0x0002) as the status code?
Answer: An IPP object that supports both utf-8 (REQUIRED) and us- 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 ascii, the second paragraph of section 3.1.4.2 applies so that the
IPP object MUST accept the request, perform code set conversion IPP object MUST accept the request, perform code set conversion
between these two charsets with "the highest fidelity possible" and between these two charsets with "the highest fidelity possible" and
return 'successful-ok', rather than a warning 'successful-ok- return 'successful-ok', rather than a warning 'successful-ok-
conflicting-attributes, or an error. The printer will do the best it conflicting-attributes, or an error. The printer will do the best it
can to convert between each of the character sets that it supports-- can to convert between each of the character sets that it supports --
even if that means providing a string of question marks because none 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 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 such conversion, it MUST NOT advertise us-ascii as a value of its
"attributes-charset-supported" and MUST reject any request that "attributes-charset-supported" and MUST reject any request that
requests 'us-ascii'. requests 'us-ascii'.
One IPP object implementation strategy is to convert all request text One IPP object implementation strategy is to convert all request text
and name values to a Unicode internal representation. This is 16-bit and name values to a Unicode internal representation. This is 16-bit
and virtually universal. Then convert to the specified operation and virtually universal. Then convert to the specified operation
attributes-charset on output. attributes-charset on output.
Also it would be smarter for a client to ask for 'utf-8', rather than 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, 'us-ascii' and throw away characters that it doesn't understand,
rather than depending on the code conversion of the IPP object. 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 3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)? requested (Issue 1.19)?
Section 3.1.4.1 Request Operation attributes was clarified in Section 3.1.4.1 Request Operation attributes was clarified in
November 1998 as follows: November 1998 as follows:
All clients and IPP objects MUST support the 'utf-8' charset All clients and IPP objects MUST support the 'utf-8' charset
[RFC2044] and MAY support additional charsets provided that they are [RFC2044] and MAY support additional charsets provided that they are
registered with IANA [IANA-CS]. If the Printer object does not registered with IANA [IANA-CS]. If the Printer object does not
support the client supplied charset value, the Printer object MUST support the client supplied charset value, the Printer object MUST
reject the request, set the "attributes-charset" to 'utf-8' in the reject the request, set the "attributes-charset" to 'utf-8' in the
response, and return the 'client-error-charset-not-supported' status response, and return the 'client-error-charset-not-supported' status
skipping to change at page 51, line 19 skipping to change at page 53, line 32
Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not- Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
supported (0x040D) was clarified in November 1998 as follows: supported (0x040D) was clarified in November 1998 as follows:
For any operation, if the IPP Printer does not support the charset For any operation, if the IPP Printer does not support the charset
supplied by the client in the "attributes-charset" operation supplied by the client in the "attributes-charset" operation
attribute, the Printer MUST reject the operation and return this attribute, the Printer MUST reject the operation and return this
status and any 'text' or 'name' attributes using the 'utf-8' charset status and any 'text' or 'name' attributes using the 'utf-8' charset
(see Section 3.1.4.1). (see Section 3.1.4.1).
3.1.2.3.13 Natural Language Override (NLO) 3.1.2.3.13 Natural Language Override (NLO)
The 'text' and 'name' attributes each have two forms. One has an The 'text' and 'name' attributes each have two forms. One has an
implicit natural language, and the other has an explicit natural implicit natural language, and the other has an explicit natural
language. The 'textWithoutLanguage' and 'textWithLanguage' are the language. The 'textWithoutLanguage' and 'textWithLanguage' are the
two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage
are the two 'name' forms. If a receiver (IPP object or IPP client) are the two 'name' forms. If a receiver (IPP object or IPP client)
supports an attribute with attribute syntax 'text', it MUST support supports an attribute with attribute syntax 'text', it MUST support
both forms in a request and a response. A sender (IPP client or IPP 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 object) MAY send either form for any such attribute. When a sender
sends a WithoutLanguage form, the implicit natural language is sends a WithoutLanguage form, the implicit natural language is
skipping to change at page 52, line 22 skipping to change at page 54, line 28
latter requirement, it is usually simpler for the IPP object latter requirement, it is usually simpler for the IPP object
implementation to store the natural language explicitly with the implementation to store the natural language explicitly with the
attribute value, i.e., to store using an internal representation that attribute value, i.e., to store using an internal representation that
resembles the WithLanguage form. resembles the WithLanguage form.
The IPP Printer MUST copy the natural language of a job, i.e., the The IPP Printer MUST copy the natural language of a job, i.e., the
value of the "attributes-natural-language" operation attribute value of the "attributes-natural-language" operation attribute
supplied by the client in the create operation, to the Job object as 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. 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 In returning a Get-Job-Attributes response, the IPP object MAY return
one of three natural language values in the response's "attributes- one of three natural language values in the responses "attributes-
natural-language" operation attribute: (1) that requested by the natural-language" operation attribute: (1) that requested by the
requester, (2) the natural language of the job, or (3) the configured requester, (2) the natural language of the job, or (3) the configured
natural language of the IPP Printer, if the requested language is not natural language of the IPP Printer, if the requested language is not
supported by the IPP Printer. supported by the IPP Printer.
This "attributes-natural-language" Job Description attribute is This "attributes-natural-language" Job Description attribute is
useful for an IPP object implementation that prints start sheets in useful for an IPP object implementation that prints start sheets in
the language of the user who submitted the job. This same Job the language of the user who submitted the job. This same Job
Description attribute is useful to a multi-lingual operator who has Description attribute is useful to a multi-lingual operator who has
to communicate with different job submitters in different natural to communicate with different job submitters in different natural
skipping to change at page 53, line 5 skipping to change at page 55, line 8
language for any other WithoutLanguage job attributes returned in the language for any other WithoutLanguage job attributes returned in the
response for that job. Interoperability testing of early response for that job. Interoperability testing of early
implementations showed that no one was implementing the job-level NLO implementations showed that no one was implementing the job-level NLO
in Get-Job responses. So the job-level NLO was eliminated from the in Get-Job responses. So the job-level NLO was eliminated from the
Get-Jobs response. This simplification makes all requests and Get-Jobs response. This simplification makes all requests and
responses consistent in that the implicit natural language for any responses consistent in that the implicit natural language for any
WithoutLanguage 'text' or 'name' form is always supplied in the WithoutLanguage 'text' or 'name' form is always supplied in the
request's or response's "attributes-natural-language" operation request's or response's "attributes-natural-language" operation
attribute. attribute.
3.1.3 Status codes returned by operation 3.1.3 Status codes returned by operation
This section corresponds to [RFC2911] section 3.1.6 "Operation This section corresponds to [RFC2911] section 3.1.6 "Operation
Response Status Codes and Status Messages". This section lists all Response Status Codes and Status Messages". This section lists all
status codes once in the first operation (Print-Job). Then it lists status codes once in the first operation (Print-Job). Then it lists
the status codes that are different or specialized for subsequent the status codes that are different or specialized for subsequent
operations under each operation. operations under each operation.
3.1.3.1 Printer Operations 3.1.3.1 Printer Operations
3.1.3.1.1 Print-Job 3.1.3.1.1 Print-Job
The Printer object MUST return one of the following "status-code" The Printer object MUST return one of the following "status-code"
values for the indicated reason. Whether all of the document data values for the indicated reason. Whether all of the document data
has been accepted or not before returning the success or error has been accepted or not before returning the success or error
response depends on implementation. See Section 13 in [RFC2911] for response depends on implementation. See Section 13 in [RFC2911] for
a more complete description of each status code. a more complete description of each status code.
For the following success status codes, the Job object has been For the following success status codes, the Job object has been
created and the "job-id", and "job-uri" assigned and returned in the created and the "job-id", and "job-uri" assigned and returned in the
response: response:
successful-ok: no request attributes were substituted or ignored. 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 successful-ok-ignored-or-substituted-attributes: some supplied
values were substituted with supported values or were ignored. (1) attributes were ignored or (2) unsupported attribute syntaxes
Unsupported attributes, attribute syntax's, or values MUST be or values were substituted with supported values or were ignored.
returned in the Unsupported Attributes group of the response. Unsupported attributes, attribute syntax's, or values MUST be
successful-ok-conflicting-attributes: some supplied attribute returned in the Unsupported Attributes group of the response.
values conflicted with the values of other supplied attributes
and were either substituted or ignored. Attributes or values successful-ok-conflicting-attributes: some supplied attribute
which conflict with other attributes and have been substituted values conflicted with the values of other supplied attributes and
or ignored MUST be returned in the Unsupported Attributes group were either substituted or ignored. Attributes or values which
of the response as supplied by the client. 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: [RFC2911] section 3.1.6 Operation Status Codes and Messages states:
If the Printer object supports the "status-message" operation If the Printer object supports the "status-message" operation
attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
status message for the following error status codes (see section 13 status message for the following error status codes (see section
in [RFC2911]): 'client-error-bad-request', 'client-error-charset- 13 in [RFC2911]): 'client-error-bad-request', 'client-error-
not-supported', 'server-error-internal-error', 'server-error- charset-not-supported', 'server-error-internal-error', 'server-
operation-not-supported', and 'server-error-version-not-supported'. error-operation-not-supported', and 'server-error-version-not-
In this case, it MUST set the value of the "attributes-charset" supported'. In this case, it MUST set the value of the
operation attribute to 'utf-8' in the error response. "attributes-charset" operation attribute to 'utf-8' in the error
response.
For the following error status codes, no job is created and no For the following error status codes, no job is created and no
"job-id" or "job-uri" is returned: "job-id" or "job-uri" is returned:
client-error-bad-request: The request syntax does not conform client-error-bad-request: The request syntax does not conform
to the specification. 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.
client-error-document-format-not-supported: the document format
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 client-error-forbidden: The request is being refused for
"attributes-charset" operation attribute is not supported. authorization or authentication reasons. The implementation
The Printer's "configured-charset" MUST be returned in the security policy is to not reveal whether the failure is one of
response as the value of the "attributes-charset" operation authentication or authorization.
attribute and used for any 'text' and 'name' attributes
returned in the error response. This error SHOULD take
precedence over any other error, unless the request syntax is
so bad that the client's supplied "attributes-charset" cannot
be determined.
client-error-conflicting-attributes: one or more supplied
attribute values conflicted with each other and the client
supplied the "ipp-attributes-fidelity" operation attribute
with a 'true' value. They MUST be returned in the Unsupported
Attributes Group as explained below.
server-error-internal-error: an unexpected condition prevents
the request from being fulfilled.
server-error-operation-not-supported: not applicable (since
Print-Job is REQUIRED).
server-error-service-unavailable: the service is temporarily
overloaded.
server-error-version-not-supported: the version in the request
is not supported. The "closest" version number supported MUST
be returned in the response.
server-error-device-error: a device error occurred while
receiving or spooling the request or document data or the IPP
Printer object can only accept one job at a time.
server-error-temporary-error: a temporary error such as a
buffer full write error, a memory overflow, or a disk full
condition occurred while receiving the request and/or the
document data.
server-error-not-accepting-jobs: the Printer object's "printer-
is-not-accepting-jobs" attribute is 'false'.
server-error-busy: the Printer is too busy processing jobs to
accept another job at this time.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
document data.
3.1.3.1.2 Print-URI client-error-not-authenticated: Either the request requires
authentication information to be supplied or the authentication
information is not sufficient for authorization.
client-error-not-authorized: The requester is not authorized
to perform the request on the target object.
client-error-not-possible: The request cannot be carried out
because of the state of the system. See also 'server-error-
not-accepting-jobs' status code, which MUST take precedence if
the Printer object's "printer-accepting-jobs" attribute is
'false'.
client-error-timeout: not applicable.
client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no
forwarding address is known.
client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to
process it.
client-error-request-value-too-long: the size of request
variable length attribute values, such as 'text' and 'name'
attribute syntax's, exceed the maximum length specified in
[RFC2911] for the attribute and MUST be returned in the
Unsupported Attributes Group.
supplied is not supported. The "document-format" attribute
with the unsupported value MUST be returned in the Unsupported
Attributes Group. This error SHOULD take precedence over any
other 'xxx-not-supported' error, except 'client-error-charset-
not-supported'.
client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntax's, or values are not
supported and the client supplied the "ipp-attributes-
fidelity" operation attribute with a 'true' value. They MUST
be returned in the Unsupported Attributes Group as explained
below.
client-error-uri-scheme-not-supported: not applicable.
client-error-charset-not-supported: the charset supplied in
the "attributes-charset" operation attribute is not supported.
The Printer's "configured-charset" MUST be returned in the
response as the value of the "attributes-charset" operation
attribute and used for any 'text' and 'name' attributes
returned in the error response. This error SHOULD take
precedence over any other error, unless the request syntax is
so bad that the client's supplied "attributes-charset" cannot
be determined.
client-error-conflicting-attributes: one or more supplied
attribute values conflicted with each other and the client
supplied the "ipp-attributes-fidelity" operation attribute with
a 'true' value. They MUST be returned in the Unsupported
Attributes Group as explained below.
server-error-internal-error: an unexpected condition prevents
the request from being fulfilled.
server-error-operation-not-supported: not applicable (since
Print-Job is REQUIRED).
server-error-service-unavailable: the service is temporarily
overloaded.
server-error-version-not-supported: the version in the request
is not supported. The "closest" version number supported MUST
be returned in the response.
server-error-device-error: a device error occurred while
receiving or spooling the request or document data or the IPP
Printer object can only accept one job at a time.
server-error-temporary-error: a temporary error such as a
buffer full write error, a memory overflow, or a disk full
condition occurred while receiving the request and/or the
document data.
server-error-not-accepting-jobs: the Printer object's
"printer-is-not-accepting-jobs" attribute is 'false'.
server-error-busy: the Printer is too busy processing jobs to
accept another job at this time.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
document data.
3.1.3.1.2 Print-URI
All of the Print-Job status codes described in Section 3.1.3.1.1 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 Print-Job Response are applicable to Print-URI with the following
specializations and differences. See Section 14 for a more complete specializations and differences. See Section 14 for a more complete
description of each status code. description of each status code.
client-error-uri-scheme-not-supported: the URI scheme supplied in client-error-uri-scheme-not-supported: the URI scheme supplied
the "document-uri" operation attribute is not supported and is in the "document-uri" operation attribute is not supported and
returned in the Unsupported Attributes group. 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 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 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 Print-Job Response are applicable to Validate-Job. See Section 13 in
[RFC2911] for a more complete description of each status code. [RFC2911] for a more complete description of each status code.
3.1.3.1.4 Create-Job 3.1.3.1.4 Create-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 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 Print-Job Response are applicable to Create-Job with the following
specializations and differences. See Section 13 in [RFC2911] for a specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code. more complete description of each status code.
server-error-operation-not-supported: the Create-Job operation is server-error-operation-not-supported: the Create-Job operation
not supported. is not supported.
client-error-multiple-document-jobs-not-supported: while the
Create-Job and Send-Document operations are supported, this
implementation doesn't support more than one document with data.
3.1.3.1.5 Get-Printer-Attributes 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.
All of the Print-Job status codes described in Section 3.1.3.1.1 3.1.3.1.5 Get-Printer-Attributes
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 All of the Print-Job status codes described in Section
returned in Group 3 in the response: 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.
successful-ok: no operation attributes or values were substituted For the following success status codes, the requested
or ignored (same as Print-Job) and no requested attributes were attributes are returned in Group 3 in the response:
unsupported.
successful-ok-ignored-or-substituted-attributes: The "requested- successful-ok: no operation attributes or values were
attributes" operation attribute MAY, but NEED NOT, be returned substituted or ignored (same as Print-Job) and no requested
with the unsupported values. attributes were unsupported.
successful-ok-conflicting-attributes: same as Print-Job.
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 For the error status codes, Group 3 is returned containing no
attributes or is not returned at all: attributes or is not returned at all:
client-error-not-possible: Same as Print-Job, in addition the client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests. 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, client-error-request-entity-too-large: same as Print-job,
since unsupported operation attributes and/or values MUST be except that no print data is involved.
ignored and an appropriate success code returned (see above).
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get-
Printer-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-busy: same as Print-Job, except the IPP object is too
busy to accept even query requests.
server-error-job-canceled: not applicable.
3.1.3.1.6 Get-Jobs client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since
Get-Printer-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that
no document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-busy: same as Print-Job, except the IPP object is
too busy to accept even query requests.
server-error-job-canceled: not applicable.
3.1.3.1.6 Get-Jobs
All of the Print-Job status codes described in Section 3.1.3.1.1 All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to the Get-Jobs operation with the Print-Job Response are applicable to the Get-Jobs operation with the
following specialization's and differences. See Section 13 in following specialization's and differences. See Section 13 in
[RFC2911] for a more complete description of each status code. [RFC2911] for a more complete description of each status code.
For the following success status codes, the requested attributes are For the following success status codes, the requested attributes are
returned in Group 3 in the response: returned in Group 3 in the response:
successful-ok: same as Get-Printer-Attributes (see section successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5). 3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Get-
Printer-Attributes (see section 3.1.3.1.5). successful-ok-ignored-or-substituted-attributes: same as Get-
successful-ok-conflicting-attributes: same as Get-Printer- Printer-Attributes (see section 3.1.3.1.5).
Attributes (see section 3.1.3.1.5).
successful-ok-conflicting-attributes: same as Get-Printer-
Attributes (see section 3.1.3.1.5).
For any error status codes, Group 3 is returned containing no For any error status codes, Group 3 is returned containing no
attributes or is not returned at all. The following brief error attributes or is not returned at all. The following brief error
status code descriptions contain unique information for use with Get- status code descriptions contain unique information for use with
Jobs operation. See section 14 for the other error status codes that Get-Jobs operation. See section 14 for the other error status codes
apply uniformly to all operations: that apply uniformly to all operations:
client-error-not-possible: Same as Print-Job, in addition the client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests. Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job,
except that no print data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code
returned (see above).
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since client-error-request-entity-too-large: same as Print-job,
Get-Jobs is REQUIRED). except that no print data is involved.
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.1.7 Pause-Printer client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since
Get-Jobs is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that
no document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.1.7 Pause-Printer
All of the Print-Job status codes described in Section 3.1.3.1.1 All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Pause-Printer with the following Print-Job Response are applicable to Pause-Printer with the following
specializations and differences. See Section 13 in [RFC2911] for a specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code. more complete description of each status code.
For the following success status codes, the Printer object is being For the following success status codes, the Printer object is being
stopped from scheduling jobs on all its devices. stopped from scheduling jobs on all its devices.
successful-ok: no request attributes were substituted or successful-ok: no request attributes were substituted or
ignored (same as Print-Job). ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job. successful-ok-ignored-or-substituted-attributes: same as
successful-ok-conflicting-attributes: same as Print-Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object has not been For any of the error status codes, the Printer object has not been
stopped from scheduling jobs on all its devices. stopped from scheduling jobs on all its devices.
client-error-not-possible: not applicable. client-error-not-possible: not applicable.
client-error-not-found: the target Printer object does not
exist.
client-error-gone: the target Printer object no longer exists
and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is
not involved.
server-error-operation-not-supported: the Pause-Printer
operation is not supported.
server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.1.8 Resume-Printer client-error-not-found: the target Printer object does not
exist.
client-error-gone: the target Printer object no longer exists
and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: the Pause-Printer
operation is not supported.
server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.1.8 Resume-Printer
All of the Print-Job status code descriptions in Section 3.1.3.1.1 All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Pause- Print-Job Response with the specialization's described for Pause-
Printer are applicable to Resume-Printer. See Section 13 in Printer are applicable to Resume-Printer. See Section 13 in
[RFC2911] for a more complete description of each status code. [RFC2911] for a more complete description of each status code.
For the following success status codes, the Printer object resumes For the following success status codes, the Printer object resumes
scheduling jobs on all its devices. scheduling jobs on all its devices.
successful-ok: no request attributes were substituted or successful-ok: no request attributes were substituted or
ignored (same as Print-Job). ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job. successful-ok-ignored-or-substituted-attributes: same as
successful-ok-conflicting-attributes: same as Print-Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object does not resume For any of the error status codes, the Printer object does not resume
scheduling jobs. scheduling jobs.
server-error-operation-not-supported: the Resume-Printer server-error-operation-not-supported: the Resume-Printer
operation is not supported. operation is not supported.
3.1.3.1.8.1 What about Printers unable to change state due to an error
condition?
3.1.3.1.8.1 What about Printers unable to change state due to an error
condition?
If, in case, the IPP printer is unable to change its state due to If, in case, the IPP printer is unable to change its state due to
some problem with the actual printer device (say, it is shut down or some problem with the actual printer device (say, it is shut down or
there is a media-jam as indicated in [RFC2911]), what should be the there is a media-jam as indicated in [RFC2911]), what should be the
result of the "Resume-Printer" operation? Should it still change the result of the "Resume-Printer" operation? Should it still change the
'printer-state-reasons' and return success or should it fail ? 'printer-state-reasons' and return success or should it fail ?
The Resume-Printer operation must clear the 'paused' or 'moving-to- The Resume-Printer operation must clear the 'paused' or 'moving-to-
paused' 'printer-state-message'. The operation must return a paused' 'printer-state-message'. The operation must return a
'successful-ok' status code. 'successful-ok' status code.
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?
If the Resume-Printer operation succeeds, what should be the value of If the Resume-Printer operation succeeds, what should be the value of
"printer-state" and who should take care of the "printer-state" "printer-state" and who should take care of the "printer-state"
attribute value later on ? attribute value later on ?
The Resume-Printer operation may change the "printer-state-reasons" The Resume-Printer operation may change the "printer-state-reasons"
value. value.
The "printer-state" will change to one of three states: The "printer-state" will change to one of three states:
1. 'idle' - no additional jobs and no error conditions present 1. 'idle' - no additional jobs and no error conditions present
2. 'processing' - job available and no error conditions present
3. current state (i.e. no change) an error condition is present 2. 'processing' - job available and no error conditions present
(e.g. media jam)
3. current state (i.e. no change) an error condition is present
(e.g. media jam)
In the third case the "printer-state-reason" will be cleared by In the third case the "printer-state-reason" will be cleared by
automata when it detects the error condition no longer exists. The automata when it detects the error condition no longer exists. The
"printer-state" will move to 'idle' or 'processing' when conditions "printer-state" will move to 'idle' or 'processing' when conditions
permit. (i.e. no more error conditions) permit. (i.e. no more error conditions)
3.1.3.1.9 Purge-Printer 3.1.3.1.9 Purge-Printer
All of the Print-Job status code descriptions in Section 3.1.3.1.1 All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Pause- Print-Job Response with the specialization's described for Pause-
Printer are applicable to Purge-Printer. See Section 13 in [RFC2911] Printer are applicable to Purge-Printer. See Section 13 in [RFC2911]
for a more complete description of each status code. for a more complete description of each status code.
For the following success status codes, the Printer object purges all For the following success status codes, the Printer object purges all
it's jobs. it's jobs.
successful-ok: no request attributes were substituted or successful-ok: no request attributes were substituted or
ignored (same as Print-Job). ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job. successful-ok-ignored-or-substituted-attributes: same as
successful-ok-conflicting-attributes: same as Print-Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object does not purge For any of the error status codes, the Printer object does not purge
any jobs. any jobs.
server-error-operation-not-supported: the Purge-Printer server-error-operation-not-supported: the Purge-Printer
operation is not supported. operation is not supported.
3.1.3.2 Job Operations 3.1.3.2 Job Operations
3.1.3.2.1 Send-Document 3.1.3.2.1 Send-Document
All of the Print-Job status codes described in Section 3.1.3.1.1 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 Print-Job Response are applicable to the Get-Printer-Attributes
operation with the following specialization's and differences. See operation with the following specialization's and differences. See
Section 13 in [RFC2911] for a more complete description of each Section 13 in [RFC2911] for a more complete description of each
status code. status code.
For the following success status codes, the document has been added For the following success status codes, the document has been added
to the specified Job object and the job's "number-of-documents" to the specified Job object and the job's "number-of-documents"
attribute has been incremented: attribute has been incremented:
successful-ok: no request attributes were substituted or successful-ok: no request attributes were substituted or
ignored (same as Print-Job). ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print- successful-ok-ignored-or-substituted-attributes: same as
Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, no document has been added to the Job For the error status codes, no document has been added to the Job
object and the job's "number-of-documents" attribute has not been object and the job's "number-of-documents" attribute has not been
incremented: incremented:
client-error-not-possible: Same as Print-Job, except that the client-error-not-possible: Same as Print-Job, except that the
Printer's "printer-is-accepting-jobs" attribute is not Printer's "printer-is-accepting-jobs" attribute is not
involved, so that the client is able to finish submitting a involved, so that the client is able to finish submitting a job
job that was created with a Create-Job operation after this that was created with a Create-Job operation after this
attribute has been set to 'true'. Another condition is that attribute has been set to 'true'. Another condition is that
the state of the job precludes Send-Document, i.e., the job the state of the job precludes Send-Document, i.e., the job has
has already been closed out by the client. However, if the already been closed out by the client. However, if the IPP
IPP Printer closed out the job due to timeout, the 'client- Printer closed out the job due to timeout, the 'client-error-
error-timeout' error status SHOULD be returned instead. timeout' error status SHOULD be returned instead.
client-error-timeout: This request was sent after the Printer
closed the job, because it has not received a Send-Document or
Send-URI operation within the Printer's "multiple-operation-
time-out" period .
client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attributes-fidelity" operation attribute is not
involved..
server-error-operation-not-supported: the Send-Document request
is not supported.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
data.
3.1.3.2.2 Send-URI client-error-timeout: This request was sent after the Printer
closed the job, because it has not received a Send-Document or
Send-URI operation within the Printer's "multiple-operation-
time-out" period .
client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attributes-fidelity" operation attribute is not
involved..
server-error-operation-not-supported: the Send-Document
request is not supported.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
data.
3.1.3.2.2 Send-URI
All of the Print-Job status code descriptions in Section 3.1.3.1.1 All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Send- Print-Job Response with the specialization's described for Send-
Document are applicable to Send-URI. See Section 13 in [RFC2911] for Document are applicable to Send-URI. See Section 13 in [RFC2911] for
a more complete description of each status code. a more complete description of each status code.
client-error-uri-scheme-not-supported: the URI scheme supplied client-error-uri-scheme-not-supported: the URI scheme supplied
in the "document-uri" operation attribute is not supported and in the "document-uri" operation attribute is not supported and
the "document-uri" attribute MUST be returned in the the "document-uri" attribute MUST be returned in the
Unsupported Attributes group. Unsupported Attributes group.
server-error-operation-not-supported: the Send-URI operation is
not supported.
3.1.3.2.3 Cancel-Job server-error-operation-not-supported: the Send-URI operation is
not supported.
3.1.3.2.3 Cancel-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Cancel-Job with the following Print-Job Response are applicable to Cancel-Job with the following
specializations and differences. See Section 13 in [RFC2911] for a specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code. more complete description of each status code.
For the following success status codes, the Job object is being For the following success status codes, the Job object is being
canceled or has been canceled: canceled or has been canceled:
successful-ok: no request attributes were substituted or successful-ok: no request attributes were substituted or
ignored (same as Print-Job). ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job. successful-ok-ignored-or-substituted-attributes: same as
successful-ok-conflicting-attributes: same as Print-Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been For any of the error status codes, the Job object has not been
canceled or was previously canceled. canceled or was previously canceled.
client-error-not-possible: The request cannot be carried out client-error-not-possible: The request cannot be carried out
because of the state of the Job object ('completed', because of the state of the Job object ('completed',
'canceled', or 'aborted') or the state of the system. 'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object
does not exist.
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and values
MUST be ignored.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is
not involved.
server-error-operation-not-supported: not applicable (Cancel-
Job is REQUIRED).
server-error-device-error: same as Print-Job, except no
document data is involved.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable..
server-error-job-canceled: not applicable.
3.1.3.2.4 Get-Job-Attributes client-error-not-found: the target Printer and/or Job object
does not exist.
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and values
MUST be ignored.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: not applicable (Cancel-
Job is REQUIRED).
server-error-device-error: same as Print-Job, except no
document data is involved.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.4 Get-Job-Attributes
All of the Print-Job status codes described in Section 3.1.3.1.1 All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Get-Job-Attributes with the Print-Job Response are applicable to Get-Job-Attributes with the
following specializations and differences. See Section 13 in following specializations and differences. See Section 13 in
[RFC2911] for a more complete description of each status code. [RFC2911] for a more complete description of each status code.
For the following success status codes, the requested attributes are For the following success status codes, the requested attributes are
returned in Group 3 in the response: returned in Group 3 in the response:
successful-ok: same as Get-Printer-Attributes (see section successful-ok: same as Get-Printer-Attributes (see section
3.1.3.1.5). 3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Get-
Printer-Attributes (see section 3.1.3.1.5). successful-ok-ignored-or-substituted-attributes: same as Get-
successful-ok-conflicting-attributes: same as Get-Printer- Printer-Attributes (see section 3.1.3.1.5).
Attributes (see section 3.1.3.1.5).
successful-ok-conflicting-attributes: same as Get-Printer-
Attributes (see section 3.1.3.1.5).
For the error status codes, Group 3 is returned containing no For the error status codes, Group 3 is returned containing no
attributes or is not returned at all. attributes or is not returned at all.
client-error-not-possible: Same as Print-Job, in addition the client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests. Printer object is not accepting any requests.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable.
client-error-uri-scheme-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code
returned (see above).
client-error-conflicting-attributes: not applicable
server-error-operation-not-supported: not applicable (since
Get-Job-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no
document data is involved.
server-error-temporary-error: sane as Print-Job, except no
document data is involved..
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.5 Hold-Job client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable.
client-error-uri-scheme-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
applicable, since unsupported operation attributes and/or
values MUST be ignored and an appropriate success code returned
(see above).
client-error-conflicting-attributes: not applicable
server-error-operation-not-supported: not applicable (since
Get-Job-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no
document data is involved.
server-error-temporary-error: sane as Print-Job, except no
document data is involved..
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.5 Hold-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 All of the Print-Job status codes described in Section 3.1.3.1.1
Print-Job Response are applicable to Hold-Job with the following Print-Job Response are applicable to Hold-Job with the following
specializations and differences. See Section 13 in [RFC2911] for a specializations and differences. See Section 13 in [RFC2911] for a
more complete description of each status code. more complete description of each status code.
For the following success status codes, the Job object is being held For the following success status codes, the Job object is being held
or has been held: or has been held:
successful-ok: no request attributes were substituted or successful-ok: no request attributes were substituted or
ignored (same as Print-Job). ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as
Print-Job. successful-ok-ignored-or-substituted-attributes: same as
successful-ok-conflicting-attributes: same as Print-Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been held For any of the error status codes, the Job object has not been held
or was previously held. or was previously held.
client-error-not-possible: The request cannot be carried out client-error-not-possible: The request cannot be carried out
because of the state of the Job object ('completed', because of the state of the Job object ('completed',
'canceled', or 'aborted') or the state of the system. 'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object
does not exist.
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is
not involved.
server-error-operation-not-supported: the Hold-Job operation is
not supported.
server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.6 Release-Job client-error-not-found: the target Printer and/or Job object
does not exist.
client-error-gone: the target Printer and/or Job object no
longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job,
except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except
that the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: the Hold-Job operation is
not supported.
server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
3.1.3.2.6 Release-Job
All of the Print-Job status code descriptions in Section 3.1.3.1.1 All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Hold-Job Print-Job Response with the specialization's described for Hold-Job
are applicable to Release-Job. See Section 13 in [RFC2911] for a are applicable to Release-Job. See Section 13 in [RFC2911] for a
more complete description of each status code. more complete description of each status code.
server-error-operation-not-supported: the Release-Job operation server-error-operation-not-supported: the Release-Job operation
is not supported. is not supported.
3.1.3.2.7 Restart-Job 3.1.3.2.7 Restart-Job
All of the Print-Job status code descriptions in Section 3.1.3.1.1 All of the Print-Job status code descriptions in Section 3.1.3.1.1
Print-Job Response with the specialization's described for Hold-Job Print-Job Response with the specialization's described for Hold-Job
are applicable to Restart-Job. See Section 13 in [RFC2911] for a are applicable to Restart-Job. See Section 13 in [RFC2911] for a
more complete description of each status code. more complete description of each status code.
server-error-operation-not-supported: the Restart-Job operation server-error-operation-not-supported: the Restart-Job operation
is not supported. is not supported.
3.1.3.2.7.1 Can documents be added to a restarted job? 3.1.3.2.7.1 Can documents be added to a restarted job?
Assume I give a Create-Job request along with a set of 5 documents .
All the documents get printed and the job state is moved to completed Assume I give a Create-Job request along with a set of 5 documents.
. I issue a Restart-Job request on the job. Now the issue is that, if All the documents get printed and the job state is moved to
I try to add new documents to the restarted job, will the IPP Server completed. I issue a Restart-Job request on the job. Now the issue
permit me to do so or return "client-error-not-possible " and again is that, if I try to add new documents to the restarted job, will the
print those 5 jobs? IPP Server permit me to do so or return "client-error-not-possible "
and again print those 5 jobs?
A job can not move to the 'completed' state until all the documents A job can not move to the 'completed' state until all the documents
have been processed. The 'last-document' flag indicates when the have been processed. The 'last-document' flag indicates when the
last document for a job is being sent from the client. This is the last document for a job is being sent from the client. This is the
semantic equivalent of closing a job. No documents may be added once semantic equivalent of closing a job. No documents may be added once
a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
is moved to the 'pending' job state and restarts the beginning on the is moved to the 'pending' job state and restarts the beginning on the
same IPP Printer object with the same attribute values." 'number-of- same IPP Printer object with the same attribute values." 'number-
documents' is a job attribute. of-documents' is a job attribute.
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
1.18) 1.18)
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
responses, the client cannot depend on getting unsupported attributes responses, the client cannot depend on getting unsupported attributes
returned in the Unsupported Attributes group that the client returned in the Unsupported Attributes group that the client
requested, but are not supported by the IPP object. However, such requested, but are not supported by the IPP object. However, such
unsupported requested attributes will not be returned in the Job unsupported requested attributes will not be returned in the Job
Attributes or Printer Attributes group (since they are unsupported). Attributes or Printer Attributes group (since they are unsupported).
Furthermore, the IPP object is REQUIRED to return the 'successful-ok- Furthermore, the IPP object is REQUIRED to return the 'successful-
ignored-or-substituted-attributes' status code, so that the client ok-ignored-or-substituted-attributes' status code, so that the client
knows that not all that was requested has been returned. knows that not all that was requested has been returned.
3.1.5 Sending empty attribute groups 3.1.5 Sending empty attribute groups
The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender
not send an empty attribute group in a request or a response. not send an empty attribute group in a request or a response.
However, they REQUIRE a receiver to accept an empty attribute group However, they REQUIRE a receiver to accept an empty attribute group
as equivalent to the omission of that group. So a client SHOULD omit as equivalent to the omission of that group. So a client SHOULD omit
the Job Template Attributes group entirely in a create operation that the Job Template Attributes group entirely in a create operation that
is not supplying any Job Template attributes. Similarly, an IPP is not supplying any Job Template attributes. Similarly, an IPP
object SHOULD omit an empty Unsupported Attributes group if there are object SHOULD omit an empty Unsupported Attributes group if there are
no unsupported attributes to be returned in a response. no unsupported attributes to be returned in a response.
skipping to change at page 66, line 17 skipping to change at page 71, line 5
paragraph: paragraph:
The syntax allows an xxx-attributes-tag to be present when the xxx- The syntax allows an xxx-attributes-tag to be present when the xxx-
attribute-sequence that follows is empty. The syntax is defined this attribute-sequence that follows is empty. The syntax is defined this
way to allow for the response of Get-Jobs where no attributes are way to allow for the response of Get-Jobs where no attributes are
returned for some job-objects. Although it is RECOMMENDED that the returned for some job-objects. Although it is RECOMMENDED that the
sender not send an xxx-attributes-tag if there are no attributes sender not send an xxx-attributes-tag if there are no attributes
(except in the Get-Jobs response just mentioned), the receiver MUST (except in the Get-Jobs response just mentioned), the receiver MUST
be able to decode such syntax. be able to decode such syntax.
3.2 Printer Operations 3.2 Printer Operations
3.2.1 Print-Job operation 3.2.1 Print-Job operation
3.2.1.1 Flow controlling the data portion of a Print-Job request 3.2.1.1 Flow controlling the data portion of a Print-Job request (Issue
(Issue 1.22) 1.22)
A paused printer, or one that is stopped due to paper out or jam or A paused printer, or one that is stopped due to paper out or jam or
spool space full or buffer space full, may flow control the data of a spool space full or buffer space full, may flow control the data of a
Print-Job operation (at the TCP/IP layer), so that the client is not Print-Job operation (at the TCP/IP layer), so that the client is not
able to send all the document data. Consequently, the Printer will able to send all the document data. Consequently, the Printer will
not return a response until the condition is changed. not return a response until the condition is changed.
The Printer should not return a Print-Job response with an error code The Printer should not return a Print-Job response with an error code
in any of these conditions, since either the printer will be resumed in any of these conditions, since either the printer will be resumed
and/or the condition will be freed either by human intervention or as and/or the condition will be freed either by human intervention or as
jobs print. jobs print.
In writing test scripts to test IPP Printers, the script must also be In writing test scripts to test IPP Printers, the script must also be
written not to expect a response, if the printer has been paused, written not to expect a response, if the printer has been paused,
until the printer is resumed, in order to work with all possible until the printer is resumed, in order to work with all possible
implementations. implementations.
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
An IPP client submits a small job via Print-Job. By the time the IPP An IPP client submits a small job via Print-Job. By the time the IPP
printer/print server is putting together a response to the operation, printer/print server is putting together a response to the operation,
the job has finished printing and been removed as an object from the the job has finished printing and been removed as an object from the
print system. What should the job-state be in the response? print system. What should the job-state be in the response?
The Model suggests that the Printer return a response before it even The Model suggests that the Printer return a response before it even
accepts the document content. The Job Object Attributes are returned accepts the document content. The Job Object Attributes are returned
only if the IPP object returns one of the success status codes. Then only if the IPP object returns one of the success status codes. Then
the job-state would always be "pending" or "pending-held". the job-state would always be "pending" or "pending-held".
skipping to change at page 67, line 36 skipping to change at page 72, line 25
On the other hand, if the server is able to query the device and/or On the other hand, if the server is able to query the device and/or
setup some sort of event notification that the device initiates when setup some sort of event notification that the device initiates when
the job makes state transitions, then the server can return the the job makes state transitions, then the server can return the
current job state in the Print-Job response and in subsequent queries current job state in the Print-Job response and in subsequent queries
because the server knows what the job state is in the device (or can because the server knows what the job state is in the device (or can
query the device). query the device).
All of these alternatives depend on implementation of the server and All of these alternatives depend on implementation of the server and
the device. the device.
3.2.2 Get-Printer-Attributes operation 3.2.2 Get-Printer-Attributes operation
If a Printer supports the "printer-make-and-model" attribute and If a Printer supports the "printer-make-and-model" attribute and
returns the .INF file model name of the printer in that attribute, returns the .INF file model name of the printer in that attribute,
the Microsoft client will automatically install the correct driver the Microsoft client will automatically install the correct driver
(if available). (if available).
Clients which poll periodically for printer status or queued-job- Clients which poll periodically for printer status or queued-job-
count should use the "requested-attributes" operation attribute to count should use the "requested-attributes" operation attribute to
limit the scope of the query in order to save Printer and network limit the scope of the query in order to save Printer and network
resources. resources.
3.2.3 Get-Jobs operation 3.2.3 Get-Jobs operation
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
1.39)? 1.39)?
In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute
'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
attribute be there too, and if it's not present what should the IPP attribute be there too, and if it's not present what should the IPP
printer do? printer do?
[RFC2911] Section 8.3 describes the various cases of "requesting- [RFC2911] Section 8.3 describes the various cases of "requesting-
user-name" being present or not for any operation. If the client user-name" being present or not for any operation. If the client
does not supply a value for "requesting-user-name", the printer MUST does not supply a value for "requesting-user-name", the printer MUST
assume that the client is supplying some anonymous name, such as assume that the client is supplying some anonymous name, such as
"anonymous". "anonymous".
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
When using the Get-Jobs operation a client implementer might choose When using the Get-Jobs operation a client implementer might choose
to limit the number of jobs that the client shows on the first to limit the number of jobs that the client shows on the first
screenful. For example, if its UI can only display 50 jobs, it can screenful. For example, if its UI can only display 50 jobs, it can
defend itself against a printer that would otherwise return 500 jobs, defend itself against a printer that would otherwise return 500 jobs,
perhaps taking a long time on a slow dial-up line. The client can perhaps taking a long time on a slow dial-up line. The client can
then go and ask for a larger number of jobs in the background, while then go and ask for a larger number of jobs in the background, while
showing the user the first 50 jobs. Since the job history is returned showing the user the first 50 jobs. Since the job history is returned
in reverse order, namely the most recently completed jobs are in reverse order, namely the most recently completed jobs are
returned first, the user is most likely interested in the first jobs returned first, the user is most likely interested in the first jobs
that are returned. Limiting the number of jobs may be especially that are returned. Limiting the number of jobs may be especially
useful for a client that is requesting 'completed' jobs from a useful for a client that is requesting 'completed' jobs from a
printer that keeps a long job history. Clients that don't mind printer that keeps a long job history. Clients that don't mind
sometimes getting very large responses, can omit the "limit" sometimes getting very large responses, can omit the "limit"
attribute in their Get-Jobs requests. attribute in their Get-Jobs requests.
3.2.4 Create-Job operation 3.2.4 Create-Job operation
A Printer may respond to a Create-Job operation with "job-state" A Printer may respond to a Create-Job operation with "job-state"
'pending' or 'pending-held' and " job-state-reason" 'job-data- 'pending' or 'pending-held' and " job-state-reason" 'job-data-
insufficient' to indicate that operation has been accepted by the insufficient' to indicate that operation has been accepted by the
Printer, but the Printer is expecting additional document data before Printer, but the Printer is expecting additional document data before
it can move the job into the 'processing' state. Alternatively, it it can move the job into the 'processing' state. Alternatively, it
may respond with "job-state" 'processing' and "job-state-reason" may respond with "job-state" 'processing' and "job-state-reason"
'job-incoming' to indicate that the Create-Job operation has been 'job-incoming' to indicate that the Create-Job operation has been
accepted by the Printer, but the Printer is expecting additional accepted by the Printer, but the Printer is expecting additional
Send-Document and/or Send-URI operations and/or is Send-Document and/or Send-URI operations and/or is
skipping to change at page 69, line 15 skipping to change at page 74, line 5
including all document data, before starting to process, so such an including all document data, before starting to process, so such an
implementation would wait for the "last-document" before starting to implementation would wait for the "last-document" before starting to
process the job. If the time-out occurs without the "last-document", process the job. If the time-out occurs without the "last-document",
then the server takes one of the indicated actions in section 3.3.1 then the server takes one of the indicated actions in section 3.3.1
in the [RFC2911] document. Other servers will start to process in the [RFC2911] document. Other servers will start to process
document data as soon as they have some. These are the so-called document data as soon as they have some. These are the so-called
"non-spooling" printers. Currently, there isn't a way for a client to "non-spooling" printers. Currently, there isn't a way for a client to
determine whether the Printer will spool all the data or will start determine whether the Printer will spool all the data or will start
to process (and print) as soon as it has some data. to process (and print) as soon as it has some data.
3.3 Job Operations 3.3 Job Operations
3.3.1 Validate-Job 3.3.1 Validate-Job
The Validate-Job operation has been designed so that its The Validate-Job operation has been designed so that its
implementation may be a part of the Print-Job operation. Therefore, implementation may be a part of the Print-Job operation. Therefore,
requiring Validate-Job is not a burden on implementers. Also it is requiring Validate-Job is not a burden on implementers. Also it is
useful for client's to be able to count on its presence in all useful for client's to be able to count on its presence in all
conformance implementations, so that the client can determine before conformance implementations, so that the client can determine before
sending a long document, whether the job will be accepted by the IPP sending a long document, whether the job will be accepted by the IPP
Printer or not. Printer or not.
3.3.2 Restart-Job 3.3.2 Restart-Job
The Restart-Job operation allows the reprocessing of a completed job. The Restart-Job operation allows the reprocessing of a completed job.
Some jobs store the document data on the printer. Jobs created using Some jobs store the document data on the printer. Jobs created using
the Print-Job operation are an example. It is required that the the Print-Job operation are an example. It is required that the
printer retains the job data after the job has moved to a 'completed printer retains the job data after the job has moved to a 'completed
state' in order for the Restart-Job operation to succeed. state' in order for the Restart-Job operation to succeed.
Some jobs contain only a reference to the job data. A job created Some jobs contain only a reference to the job data. A job created
using the Print-URI is an example of such a job. When the Restart- using the Print-URI is an example of such a job. When the Restart-
Job operation is issued the job is reprocessed. The job data MUST be Job operation is issued the job is reprocessed. The job data MUST be
retrieved again to print the job. retrieved again to print the job.
It is possible that a job fails while attempting to access the print It is possible that a job fails while attempting to access the print
data. When such a job is the target of a Restart-Job the Printer data. When such a job is the target of a Restart-Job the Printer
SHALL attempt to retrieve the job data again. SHALL attempt to retrieve the job data again.
4 Object Attributes 4 Object Attributes
4.1 Attribute Syntax's 4.1 Attribute Syntax's
4.1.1 The 'none' value for empty sets (Issue 1.37) 4.1.1 The 'none' value for empty sets (Issue 1.37)
[RFC2911] states that the 'none' value should be used as the value of [RFC2911] states that the 'none' value should be used as the value of
a 1setOf when the set is empty. In most cases, sets that are a 1setOf when the set is empty. In most cases, sets that are
potentially empty contain keywords so the keyword 'none' is used, but potentially empty contain keywords so the keyword 'none' is used, but
for the 3 finishings attributes, the values are enums and thus the for the 3 finishings attributes, the values are enums and thus the
empty set is represented by the enum 3. Currently there are no other empty set is represented by the enum 3. Currently there are no other
attributes with 1setOf values, which can be empty and can contain attributes with 1setOf values, which can be empty and can contain
values that are not keywords. This exception requires special code values that are not keywords. This exception requires special code
and is a potential place for bugs. It would have been better if we and is a potential place for bugs. It would have been better if we
had chosen an out-of-band value, either "no-value" or some new value, had chosen an out-of-band value, either "no-value" or some new value,
such as 'none'. Since we didn't, implementations have to deal with such as 'none'. Since we didn't, implementations have to deal with
the different representations of 'none', depending on the attribute the different representations of 'none', depending on the attribute
syntax. syntax.
4.1.2 Multi-valued attributes (Issue 1.31) 4.1.2 Multi-valued attributes (Issue 1.31)
What is the attribute syntax for a multi-valued attribute? Since What is the attribute syntax for a multi-valued attribute? Since
some attributes support values in more than one data type, such as some attributes support values in more than one data type, such as
"media", "job-hold-until", and "job-sheets", IPP semantics associate "media", "job-hold-until", and "job-sheets", IPP semantics associate
the attribute syntax with each value, not with the attribute as a the attribute syntax with each value, not with the attribute as a
whole. The protocol associates the attribute syntax tag with each whole. The protocol associates the attribute syntax tag with each
value. Don't be fooled, just because the attribute syntax tag comes value. Don't be fooled, just because the attribute syntax tag comes
before the attribute keyword. All attribute values after the first before the attribute keyword. All attribute values after the first
have a zero length attribute keyword as the indication of a have a zero length attribute keyword as the indication of a
subsequent value of the same attribute. subsequent value of the same attribute.
4.1.3 Case Sensitivity in URIs (issue 1.6) 4.1.3 Case Sensitivity in URIs (issue 1.6)
IPP client and server implementations must be aware of the diverse IPP client and server implementations must be aware of the diverse
uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and
Host names as case insensitive but reminds us that the rest of the Host names as case insensitive but reminds us that the rest of the
URL may well demonstrate case sensitivity. When creating URL's for URL may well demonstrate case sensitivity. When creating URL's for
fields where the choice is completely arbitrary, it is probably best fields where the choice is completely arbitrary, it is probably best
to select lower case. However, this cannot be guaranteed and to select lower case. However, this cannot be guaranteed and
implementations MUST NOT rely on any fields being case-sensitive or implementations MUST NOT rely on any fields being case-sensitive or
case-insensitive in the URL beyond the URL scheme and host name case-insensitive in the URL beyond the URL scheme and host name
fields. fields.
skipping to change at page 71, line 28 skipping to change at page 76, line 4
http://abc.com:80/~smith/home.html http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html http://ABC.com/%7Esmith/home.html
http:/ABC.com:/%7esmith/home.html http:/ABC.com:/%7esmith/home.html
Example of equivalent URI's using the IPP scheme Example of equivalent URI's using the IPP scheme
ipp://abc.com:631/~smith/home.html ipp://abc.com:631/~smith/home.html
ipp://ABC.com/%7Esmith/home.html ipp://ABC.com/%7Esmith/home.html
http:/ABC.com:631/%7esmith/home.html http:/ABC.com:631/%7esmith/home.html
The HTTP/1.1 specification [RFC2616] contains more details on The HTTP/1.1 specification [RFC2616] contains more details on
comparing URLs. comparing URLs.
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
that have two components. The first component is the 'language' that have two components. The first component is the 'language'
component that can contain up to 63 octets. The second component is component that can contain up to 63 octets. The second component is
the 'text' or 'name' component. The maximum length of these are 1023 the 'text' or 'name' component. The maximum length of these are 1023
octets and 255 octets respectively. The definition of attributes octets and 255 octets respectively. The definition of attributes
with either syntax may further restrict the length. (e.g. printer- with either syntax may further restrict the length (e.g., printer-
name (name(127))) name (name(127))).
The length of the 'language' component has no effect on the allowable The length of the 'language' component has no effect on the allowable
length of 'text' in 'textWithLanguage' or the length of 'name' in length of 'text' in 'textWithLanguage' or the length of 'name' in
'nameWithLanguage' 'nameWithLanguage'
4.2 Job Template Attributes 4.2 Job Template Attributes
4.2.1 multiple-document-handling(type2 keyword) 4.2.1 multiple-document-handling(type2 keyword)
4.2.1.1 Support of multiple document jobs 4.2.1.1 Support of multiple document jobs
IPP/1.0 is silent on which of the four effects an implementation IPP/1.0 is silent on which of the four effects an implementation
would perform if it supports Create-Job, but does not support would perform if it supports Create-Job, but does not support
"multiple-document-handling" or multiple documents per job. IPP/1.1 "multiple-document-handling" or multiple documents per job. IPP/1.1
was changed so that a Printer could support Create-Job without having was changed so that a Printer could support Create-Job without having
to support multiple document jobs. The "multiple-document-jobs- to support multiple document jobs. The "multiple-document-jobs-
supported" (boolean) Printer description attribute was added to supported" (boolean) Printer description attribute was added to
IPP/1.1 along with the 'server-error-multiple-document-jobs-not- IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
supported' status code for a Printer to indicate whether or not it supported' status code for a Printer to indicate whether or not it
supports multiple document jobs, when it supports the Create-Job supports multiple document jobs, when it supports the Create-Job
operation. Also IPP/1.1 was clarified that the Printer MUST support operation. Also IPP/1.1 was clarified that the Printer MUST support
the "multiple-document-handling" (type2 keyword) Job Template the "multiple-document-handling" (type2 keyword) Job Template
attribute with at least one value if the Printer supports multiple attribute with at least one value if the Printer supports multiple
documents per job. documents per job.
4.3 Job Description Attributes 4.3 Job Description Attributes
4.3.1 Getting the date and time of day 4.3.1 Getting the date and time of day
The "date-time-at-creation", "date-time-at-processing", and "date- The "date-time-at-creation", "date-time-at-processing", and "date-
time-at-completed" attributes are returned as dateTime syntax. time-at-completed" attributes are returned as dateTime syntax. These
These attributes are OPTIONAL for a Printer to support. However, attributes are OPTIONAL for a Printer to support. However, there are
there are various ways for a Printer to get the date and time of day. various ways for a Printer to get the date and time of day. Some
Some suggestions: suggestions:
1. A Printer can get time from an NTP timeserver if there's one 1. A Printer can get time from an NTP timeserver if there's one
reachable on the network . See RFC 1305. Also DHCP option 32 in reachable on the network . See RFC 1305. Also DHCP option 32
RFC 2132 returns the IP address of the NTP server. in RFC 2132 returns the IP address of the NTP server.
2. Get the date and time at startup from a human operator 2. Get the date and time at startup from a human operator
3. Have an operator set the date and time using a web 3. Have an operator set the date and time using a web
administrative interface administrative interface
4. Get the date and time from incoming HTTP requests, though the 4. Get the date and time from incoming HTTP requests, though the
problems of spoofing need to be considered. Perhaps comparing problems of spoofing need to be considered. Perhaps comparing
several HTTP requests could reduce the chances of spoofing. several HTTP requests could reduce the chances of spoofing.
5. Internal date time clock battery driven. 5. Internal date time clock battery driven.
6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
4.4 Printer Description Attributes 4.4 Printer Description Attributes
4.4.1 queued-job-count (integer(0:MAX)) 4.4.1 queued-job-count (integer(0:MAX))
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
The reason that "queued-job-count" is RECOMMENDED, is that some The reason that "queued-job-count" is RECOMMENDED, is that some
clients look at that attribute alone when summarizing the status of a clients look at that attribute alone when summarizing the status of a
list of printers, instead of doing a Get-Jobs to determine the number list of printers, instead of doing a Get-Jobs to determine the number
of jobs in the queue. Implementations that fail to support the of jobs in the queue. Implementations that fail to support the
"queued-job-count" will cause that client to display 0 jobs when "queued-job-count" will cause that client to display 0 jobs when
there are actually queued jobs. there are actually queued jobs.
We would have made it a REQUIRED Printer attribute, but some We would have made it a REQUIRED Printer attribute, but some
implementations had already been completed before the issue was implementations had already been completed before the issue was
raised, so making it a SHOULD was a compromise. raised, so making it a SHOULD was a compromise.
4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
(Issue 1.15)? (Issue 1.15)?
The "queued-job-count" is not a good measure of how busy the printer The "queued-job-count" is not a good measure of how busy the printer
is when there are held jobs. A future registration could be to add a is when there are held jobs. A future registration could be to add a
"held-job-count" (or an "active-job-count") Printer Description "held-job-count" (or an "active-job-count") Printer Description
attribute if experience shows that such an attribute (combination) is attribute if experience shows that such an attribute (combination) is
needed to quickly indicate how busy a printer really is. needed to quickly indicate how busy a printer really is.
4.4.2 printer-current-time (dateTime) 4.4.2 printer-current-time (dateTime)
A Printer implementation MAY support this attribute by obtaining the A Printer implementation MAY support this attribute by obtaining the
date and time by any number of implementation-dependent means at date and time by any number of implementation-dependent means at
startup or subsequently. Examples include: startup or subsequently. Examples include:
1. an internal date time clock, 1. an internal date time clock,
2. from the operator at startup using the console, 2. from the operator at startup using the console,
3. from an operator using an administrative web page, 3. from an operator using an administrative web page,
4. from HTTP headers supplied in client requests, 4. from HTTP headers supplied in client requests,
5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
6. from the network, using NTP [RFC1305] or DHCP option 32
[RFC2132] that returns the IP address of the NTP server. 6. from the network, using NTP [RFC1305] or DHCP option 32
[RFC2132] that returns the IP address of the NTP server.
If an implementation supports this attribute by obtaining the current If an implementation supports this attribute by obtaining the current
time from the network (at startup or later), but the time is not time from the network (at startup or later), but the time is not
available, then the implementation MUST return the value of this available, then the implementation MUST return the value of this
attribute using the out-of-band 'no-value' meaning not configured. attribute using the out-of-band 'no-value' meaning not configured.
See the beginning of section 4.1. See the beginning of section 4.1.
Since the new "date-and-time-at-xxx" Job Description attributes refer Since the new "date-and-time-at-xxx" Job Description attributes refer
to the "printer-current-time", they will be covered also. to the "printer-current-time", they will be covered also.
4.4.3 Printer-uri 4.4.3 Printer-uri
Must the operational attribute for printer-uri match one of the Must the operational attribute for printer-uri match one of the
values in "printer-uri-supported"? values in "printer-uri-supported"?
A forgiving printer implementation would not reject the operation. A forgiving printer implementation would not reject the operation.
But the implementation has its rights to reject a printer or job But the implementation has its rights to reject a printer or job
operation if the operational attribute printer-uri is not a value of operation if the operational attribute printer-uri is not a value of
the printer-uri-supported. The printer might not be improperly the printer-uri-supported. The printer might not be improperly
configured. The request obviously reached the printer. The printer configured. The request obviously reached the printer. The printer
could treat the printer-uri as the logical equivalent of a value in could treat the printer-uri as the logical equivalent of a value in
the printer-uri-supported. It would be implementation dependent for the printer-uri-supported. It would be implementation dependent for
which value, and associated security policy, would apply. This does which value, and associated security policy, would apply. This does
also apply to a job object specified with a printer-uri and job-id, also apply to a job object specified with a printer-uri and job-id,
or with a job-uri. See section 4.1.3 for how to compare URI's. or with a job-uri. See section 4.1.3 for how to compare URI's.
4.5 Empty Jobs 4.5 Empty Jobs
The IPP object model does not prohibit a job that contains no The IPP object model does not prohibit a job that contains no
documents. Such a job may be created in a number of ways including a documents. Such a job may be created in a number of ways including a
'create-job' followed by an 'add-document' that contains no data and 'create-job' followed by an 'add-document' that contains no data and
has the 'last-document' flag set. has the 'last-document' flag set.
An empty job is processed just as any other job. The operation that An empty job is processed just as any other job. The operation that
"closes" an empty job is not rejected because the job is empty. If "closes" an empty job is not rejected because the job is empty. If
no other conditions exist, other than the job is empty, the response no other conditions exist, other than the job is empty, the response
to the operation will indicate success. After the job is scheduled to the operation will indicate success. After the job is scheduled
skipping to change at page 74, line 48 skipping to change at page 79, line 21
An empty job is processed just as any other job. The operation that An empty job is processed just as any other job. The operation that
"closes" an empty job is not rejected because the job is empty. If "closes" an empty job is not rejected because the job is empty. If
no other conditions exist, other than the job is empty, the response no other conditions exist, other than the job is empty, the response
to the operation will indicate success. After the job is scheduled to the operation will indicate success. After the job is scheduled
and processed, the job state SHALL be 'completed'. and processed, the job state SHALL be 'completed'.
There will be some variation in the value(s) of the "job-state- There will be some variation in the value(s) of the "job-state-
reasons" attribute. It is required that if no conditions, other than reasons" attribute. It is required that if no conditions, other than
the job being empty, exist the "job-state-reasons" SHALL include the the job being empty, exist the "job-state-reasons" SHALL include the
'completed-successfully'. If other conditions existed, the 'completed-successfully'. If other conditions existed, the
'completed-with-warnings' or 'completed-with-errors' values may be 'completed-with-warnings' or 'completed-with-errors' values may be
used. used.
5 Directory Considerations 5 Directory Considerations
5.1 General Directory Schema Considerations 5.1 General Directory Schema Considerations
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
attributes for directory schemas. See [RFC2911] APPENDIX E: Generic attributes for directory schemas. See [RFC2911] APPENDIX E: Generic
Directory Schema. Directory Schema.
The SLP printer template is defined in the "Definition of the Printer The SLP printer template is defined in the "Definition of the Printer
Abstract Service Type v2.0" document [svrloc-printer]. The LDAP Abstract Service Type v2.0" document [svrloc-printer]. The LDAP
printer template is defined in the "Internet Printing Protocol (IPP): printer template is defined in the "Internet Printing Protocol (IPP):
LDAP Schema for Printer Services" document [ldap-printer]. Both LDAP Schema for Printer Services" document [ldap-printer]. Both
documents systematically add "printer-" to any attribute that doesn't documents systematically add "printer-" to any attribute that doesn't
already start with "printer-" in order to keep the printer directory already start with "printer-" in order to keep the printer directory
attributes distinct from other directory attributes. Also, instead attributes distinct from other directory attributes. Also, instead
of using "printer-uri-supported", "uri-authentication-supported", and of using "printer-uri-supported", "uri-authentication-supported", and
"uri-security-supported", they use a "printer-xri-supported" "uri-security-supported", they use a "printer-xri-supported"
attribute with special syntax to contain all of the same information attribute with special syntax to contain all of the same information
in a single attribute. in a single attribute.
5.2 IPP Printer with a DNS name 5.2 IPP Printer with a DNS name
If the IPP printer has a DNS name should there be at least two values If the IPP printer has a DNS name should there be at least two values
for the printer-uri-supported attribute. One URL with the fully for the printer-uri-supported attribute. One URL with the fully
qualified DNS name the other with the IP address in the URL? qualified DNS name the other with the IP address in the URL?
The printer may contain one or the other or both. It's up to the
The printer may contain one or the other or both. It's up to the
administrator to configure this attribute. administrator to configure this attribute.
6 Security Considerations 6 Security Considerations
This section corresponds to the RFC2911 Section 8 "Security The security considerations given in [RFC2911] Section 8 "Security
Considerations. Considerations" all apply to this document. In addition, the
following sub-sections describes security consideration that have
arisen as a result of implementation testing.
6.1 Querying jobs with IPP that were submitted using other job 6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32) submission protocols (Issue 1.32)
The following clarification was added to [RFC2911] section 8.5: The following clarification was added to [RFC2911] section 8.5:
8.5 Queries on jobs submitted using non-IPP protocols 8.5 Queries on jobs submitted using non-IPP protocols If the
If the device that an IPP Printer is representing is able to accept device that an IPP Printer is representing is able to accept jobs
jobs using other job submission protocols in addition to IPP, it is using other job submission protocols in addition to IPP, it is
RECOMMEND that such an implementation at least allow such "foreign" RECOMMEND that such an implementation at least allow such
jobs to be queried using Get-Jobs returning "job-id" and "job-uri" "foreign" jobs to be queried using Get-Jobs returning "job-id" and
as 'unknown'. Such an implementation NEED NOT support all of the "job-uri" as 'unknown'. Such an implementation NEED NOT support
same IPP job attributes as for IPP jobs. The IPP object returns all of the same IPP job attributes as for IPP jobs. The IPP
the 'unknown' out-of-band value for any requested attribute of a object returns the 'unknown' out-of-band value for any requested
foreign job that is supported for IPP jobs, but not for foreign attribute of a foreign job that is supported for IPP jobs, but not
jobs. for foreign jobs.
It is further RECOMMENDED, that the IPP Printer generate "job-id" It is further RECOMMENDED, that the IPP Printer generate "job-id"
and "job-uri" values for such "foreign jobs", if possible, so that and "job-uri" values for such "foreign jobs", if possible, so that
they may be targets of other IPP operations, such as Get-Job- they may be targets of other IPP operations, such as Get-Job-
Attributes and Cancel-Job. Such an implementation also needs to Attributes and Cancel-Job. Such an implementation also needs to
deal with the problem of authentication of such foreign jobs. One deal with the problem of authentication of such foreign jobs. One
approach would be to treat all such foreign jobs as belonging to approach would be to treat all such foreign jobs as belonging to
users other than the user of the IPP client. Another approach users other than the user of the IPP client. Another approach
would be for the foreign job to belong to 'anonymous'. Only if the would be for the foreign job to belong to 'anonymous'. Only if
IPP client has been authenticated as an operator or administrator the IPP client has been authenticated as an operator or
of the IPP Printer object, could the foreign jobs be queried by an administrator of the IPP Printer object, could the foreign jobs be
IPP request. Alternatively, if the security policy were to allow queried by an IPP request. Alternatively, if the security policy
users to query other users' jobs, then the foreign jobs would also were to allow users to query other users' jobs, then the foreign
be visible to an end-user IPP client using Get-Jobs and Get-Job- jobs would also be visible to an end-user IPP client using Get-
Attributes. Jobs and Get-Job- Attributes.
Thus IPP MAY be implemented as a "universal" protocol that provides Thus IPP MAY be implemented as a "universal" protocol that
access to jobs submitted with any job submission protocol. As IPP provides access to jobs submitted with any job submission
becomes widely implemented, providing a more universal access makes protocol. As IPP becomes widely implemented, providing a more
sense. universal access makes sense.
7 Encoding and Transport 7 Encoding and Transport
This section discusses various aspects of IPP/1.1 Encoding and This section discusses various aspects of IPP/1.1 Encoding and
Transport [RFC2910]. Transport [RFC2910].
A server is not required to send a response until after it has A server is not required to send a response until after it has
received the client's entire request. Hence, a client must not received the client's entire request. Hence, a client must not
expect a response until after it has sent the entire request. expect a response until after it has sent the entire request.
However, we recommend that the server return a response as soon as However, we recommend that the server return a response as soon as
possible if an error is detected while the client is still sending possible if an error is detected while the client is still sending
the data, rather than waiting until all of the data is received. the data, rather than waiting until all of the data is received.
Therefore, we also recommend that a client listen for an error Therefore, we also recommend that a client listen for an error
response that an IPP server MAY send before it receives all the data. response that an IPP server MAY send before it receives all the data.
In this case a client, if chunking the data, can send a premature In this case a client, if chunking the data, can send a premature
zero-length chunk to end the request before sending all the data (and zero-length chunk to end the request before sending all the data (and
so the client can keep the connection open for other requests, rather so the client can keep the connection open for other requests, rather
than closing it). If the request is blocked for some reason, a client than closing it). If the request is blocked for some reason, a
MAY determine the reason by opening another connection to query the client MAY determine the reason by opening another connection to
server using Get-Printer-Attributes. query the server using Get-Printer-Attributes.
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
to throttle clients when Printers are busy. Therefore, it is to throttle clients when Printers are busy. Therefore, it is
perfectly normal for an IPP client transmitting a Job to be blocked perfectly normal for an IPP client transmitting a Job to be blocked
for a really long time. Accordingly, socket timeouts must be for a really long time. Accordingly, socket timeouts must be
avoided. Some socket implementations have a timeout option, which avoided. Some socket implementations have a timeout option, which
specifies how long a write operation on a socket can be blocked specifies how long a write operation on a socket can be blocked
before it times out and the blocking ends. A client should set this before it times out and the blocking ends. A client should set this
option for infinite timeout when transmitting Job submissions. option for infinite timeout when transmitting Job submissions.
skipping to change at page 78, line 19 skipping to change at page 83, line 5
relevant to an IPP implementation. relevant to an IPP implementation.
The following is an explanation of the values in the The following is an explanation of the values in the
"response/client" and "request/ server" columns. "response/client" and "request/ server" columns.
- must: the client or server MUST support the header, - must: the client or server MUST support the header,
- may: the client or server MAY support the header - may: the client or server MAY support the header
- not: the client or server SHOULD NOT support the header. It is - not: the client or server SHOULD NOT support the header. It is
not relevant to an IPP implementation. not relevant to an IPP implementation.
7.1 General Headers 7.1 General Headers
The following is a table for the general headers. The following is a table for the general headers.
General- Request Response Values and Conditions General- Request Response Values and Conditions
Header Header
Client Server Server Client Client Server Server Client
Cache- must not must not "no-cache" only Cache- not must not "no-cache" only
Control Control must
Connection must- must must- must "close" only. Both Connection must- must must- must "close" only. Both
if if client and server SHOULD if if client and server
keep a connection for SHOULD keep a
the duration of a connection for the
sequence of operations. duration of a sequence
The client and server of operations. The
MUST include this header client and server MUST
for the last operation include this header
in such a sequence. for the last operation
in such a sequence.
Date may may must may per RFC 1123 [RFC1123] Date may may must may per RFC 1123 [RFC1123]
from RFC 2616 [RFC2616] from RFC 2616
[RFC2616]
Pragma must not must not "no-cache" only Pragma must not must not "no-cache" only
Transfer- must- must must- must "chunked" only . Header Transfer- must- must must- must "chunked" only. Header
Encoding if if MUST be present if Encoding if if MUST be present if
Content-Length is Content-Length is
absent. absent.
Upgrade not not not not Upgrade not not not not
Via not not not not Via not not not not
7.2 Request Headers 7.2 Request Headers
The following is a table for the request headers. The following is a table for the request headers.
Request- Client Server Request Values and Conditions Request- Client Server Request Values and Conditions
Header Header
Request- Client Server Request Values and Conditions
Header
Accept may must "application/ipp" only. This Accept may must "application/ipp" only. This
value is the default if the client value is the default if the
omits it client omits it
Accept- not not Charset information is within the Accept- not not Charset information is within the
Charset application/ipp entity Charset application/ipp entity
Accept- may must empty and per RFC 2616 [RFC2616] Accept- may must empty and per RFC 2616 [RFC2616]
Encoding and IANA registry for content- Encoding and IANA registry for content-
codings codings
Accept- not not language information is within the Accept- not not language information is within the
Language application/ipp entity Language application/ipp entity
Authorization must- must per RFC 2616. A client MUST send Authorization must- must per RFC 2616. A client MUST send
if this header when it receives a 401 if this header when it receives a
"Unauthorized" response and does 401 "Unauthorized" response and
not receive a "Proxy- does not receive a "Proxy-
Authenticate" header. Authenticate" header.
From not not per RFC 2616. Because RFC From not not per RFC 2616. Because RFC
recommends sending this header recommends sending this header
only with the user's approval, it only with the user's approval,
is not very useful it is not very useful
Host must must per RFC 2616 Host must must per RFC 2616
If-Match not not If-Match not not
If-Modified- not not If-Modified- not not
Since Since
If-None-Match not not If-None-Match not not
If-Range not not If-Range not not
If- not not If- not not
Unmodified- Unmodified-
Since Since
Max-Forwards not not
Proxy- must- not per RFC 2616. A client MUST send
Authorization if this header when it receives a 401
"Unauthorized" response and a
Request- Client Server Request Values and Conditions Request- Client Server Request Values and Conditions
Header Header
"Proxy-Authenticate" header. Max-Forwards not not
Proxy- must- not per RFC 2616. A client MUST send
Authorizati if this header when it receives a
on 401 "Unauthorized" response and
a "Proxy-Authenticate" header.
Range not not Range not not
Referrer not not Referrer not not
User-Agent not not User-Agent not not
7.3 Response Headers 7.3 Response Headers
The following is a table for the request headers. The following is a table for the request headers.
Response- Server Client Response Values and Conditions Response- Server Client Response Values and Conditions
Header Header
Accept-Ranges not not Accept-Ranges not not
Age not not Age not not
Location must- may per RFC 2616. When URI needs Location must- may per RFC 2616. When URI needs
if redirection. if redirection.
Proxy- not must per RFC 2616 Proxy- must per RFC 2616
Authenticate Authenticat
e not
Public may may per RFC 2616 Public may may per RFC 2616
Retry-After may may per RFC 2616 Retry-After may may per RFC 2616
Server not not Server not not
Vary not not Vary not not
Warning may may per RFC 2616 Warning may may per RFC 2616
WWW- must- must per RFC 2616. When a server needs WWW- must- must per RFC 2616. When a server needs
Authenticate if to authenticate a client. Authenticate if to authenticate a client.
7.4 Entity Headers 7.4 Entity Headers
The following is a table for the entity headers. The following is a table for the entity headers.
Entity-Header Request Response Values and Entity-Header Request Response Values and
Conditions Conditions
Client Server Server Client Client Server Server Client
Allow not not not not Allow not not not not
Content-Base not not not not Content-Base not not not not
Content- may must must must per RFC 2616 and Content- may must must must per RFC 2616 and
Encoding IANA registry for Encoding IANA registry for
content codings. content codings.
Content- not not not not Application/ipp Content- not not not not Application/ipp
Language handles language Language handles language
Content- must- must must- must the length of the Content- must- must must- must the length of the
Length if if message-body per Length if if message-body per
RFC 2616. Header RFC 2616. Header
MUST be present if MUST be present
Transfer-Encoding if Transfer-
is absent.. Encoding is
absent..
Content- not not not not Content- not not not not
Location Location
Content-MD5 may may may may per RFC 2616 Content-MD5 may may may may per RFC 2616
Content-Range not not not not Content-Range not not not not
Content-Type must must must must "application/ipp" Content-Type must must must must "application/ipp"
only only
ETag not not not not ETag not not not not
Expires not not not not Expires not not not not
Last-Modified not not not not Last-Modified not not not not
7.5 Optional support for HTTP/1.0 7.5 Optional support for HTTP/1.0
IPP implementations consist of an HTTP layer and an IPP layer. In IPP implementations consist of an HTTP layer and an IPP layer. In
the following discussion, the term "client" refers to the HTTP client the following discussion, the term "client" refers to the HTTP client
layer and the term "server" refers to the HTTP server layer. The layer and the term "server" refers to the HTTP server layer. The
Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
be supported by all clients and all servers. However, a client be supported by all clients and all servers. However, a client
and/or a server implementation may choose to also support HTTP 1.0. and/or a server implementation may choose to also support HTTP 1.0.
This option means that a server may choose to communicate with a This option means that a server may choose to communicate with a
(non-conforming) client that only supports HTTP 1.0. In such cases (non-conforming) client that only supports HTTP 1.0. In such cases
the server should not use any HTTP 1.1 specific parameters or the server should not use any HTTP 1.1 specific parameters or
features and should respond using HTTP version number 1.0. features and should respond using HTTP version number 1.0.
This option also means that a client may choose to communicate with a This option also means that a client may choose to communicate with a
(non-conforming) server that only supports HTTP 1.0. In such cases, (non-conforming) server that only supports HTTP 1.0. In such cases,
if the server responds with an HTTP 'unsupported version number' to if the server responds with an HTTP 'unsupported version number' to
an HTTP 1.1 request, the client should retry using HTTP version an HTTP 1.1 request, the client should retry using HTTP version
number 1.0. number 1.0.
7.6 HTTP/1.1 Chunking 7.6 HTTP/1.1 Chunking
7.6.1 Disabling IPP Server Response Chunking 7.6.1 Disabling IPP Server Response Chunking
Clients MUST anticipate that the HTTP/1.1 server may chunk responses Clients MUST anticipate that the HTTP/1.1 server may chunk responses
and MUST accept them in responses. However, a (non-conforming) HTTP and MUST accept them in responses. However, a (non-conforming) HTTP
client that is unable to accept chunked responses may attempt to client that is unable to accept chunked responses may attempt to
request an HTTP 1.1 server not to use chunking in its response to an request an HTTP 1.1 server not to use chunking in its response to an
operation by using the following HTTP header: operation by using the following HTTP header:
TE: identity TE: identity
This mechanism should not be used by a server to disable a client This mechanism should not be used by a server to disable a client
from chunking a request, since chunking of document data is an from chunking a request, since chunking of document data is an
important feature for clients to send long documents. important feature for clients to send long documents.
7.6.2 Warning About the Support of Chunked Requests 7.6.2 Warning About the Support of Chunked Requests
This section describes some problems with the use of chunked requests This section describes some problems with the use of chunked requests
and HTTP/1.1 servers. and HTTP/1.1 servers.
The HTTP/1.1 standard [RFC2616] requires that conforming servers The HTTP/1.1 standard [RFC2616] requires that conforming servers
support chunked requests for any method. However, in spite of this support chunked requests for any method. However, in spite of this
requirement, some HTTP/1.1 implementations support chunked responses requirement, some HTTP/1.1 implementations support chunked responses
in the GET method, but do not support chunked POST method requests. in the GET method, but do not support chunked POST method requests.
Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
servlets [Servlet] require that the client supply a Content-Length. servlets [Servlet] require that the client supply a Content-Length.
skipping to change at page 84, line 16 skipping to change at page 89, line 19
standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP
Printer object implementation support chunked requests and that Printer object implementation support chunked requests and that
conforming clients accept chunked responses. Therefore, IPP object conforming clients accept chunked responses. Therefore, IPP object
implementers are warned to seek HTTP server implementations that implementers are warned to seek HTTP server implementations that
support chunked POST requests in order to conform to the IPP standard support chunked POST requests in order to conform to the IPP standard
and/or use implementation techniques that support chunked POST and/or use implementation techniques that support chunked POST
requests. requests.
8 References 8 References
[CGI] [CGI] CGI/1.1 (http://www.w3.org/CGI/).
CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11-
00.txt).
[ldap-printer] [IANA-CS] IANA Registry of Coded Character Sets:
Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing http://www.iana.org/assignments/character-sets
Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp-
ldap-printer-schema-01.txt>, work in progress, April 27, 2000.
[RFC793] [ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald,
J. Postel, "Transmission Control Protocol", RFC 793. "Internet Printing Protocol (IPP): LDAP Schema for
Printer Services", Work in Progress.
[RFC1123] [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
Braden, S., "Requirements for Internet Hosts - Application and RFC 793, September 1981.
Support", RFC 1123, October, 1989.
[RFC2026] [RFC1123] Braden, R., "Requirements for Internet Hosts -
S. Bradner, "The Internet Standards Process -- Revision 3", RFC Application and Support", RFC 1123, October, 1989.
2026, October 1996.
[RFC2119] [RFC2026] Bradner, S., "The Internet Standards Process --
S. Bradner, "Key words for use in RFCs to Indicate Requirement Revision 3", BCP 9, RFC 2026, October 1996.
Levels", RFC 2119 , March 1997.
[RFC2396] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Requirement Levels", BCP 14, RFC 2119 , March 1997.
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2565] [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Uniform Resource Identifiers (URI): Generic
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, Syntax", RFC 2396, August 1998.
April 1999.
[RFC2566] [RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing and P. Powell, "Internet Printing Protocol/1.0:
Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. Model and Semantics", RFC 2566, April 1999.
[RFC2567] [RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner,
Wright, D., "Design Goals for an Internet Printing Protocol", "Internet Printing Protocol/1.0: Encoding and
draft-ietf-ipp-req-03.txt, November, 1998. Transport", RFC 2565, April 1999.
[RFC2568 [RFC2567] Wright, D., "Design Goals for an Internet Printing
Zilles, S., "Rationale for the Structure and Model and Protocol for Protocol", RFC 2567, April 1999.
the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2569] [RFC2568] Zilles, S., "Rationale for the Structure and Model
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between and Protocol for the Internet Printing Protocol",
LPD and IPP Protocols", RFC 2569, April 1999. RFC 2568, April 1999.
[RFC2616] [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J.
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Martin, "Mapping between LPD and IPP Protocols",
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2569, April 1999.
RFC 2616, June 1999.
[RFC2910] [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing Masinter, L., Leach, P. and T. Berners-Lee,
Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000. "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
June 1999.
[RFC2911] [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner,
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Encoding and
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, Transport", RFC 2910, September, 2000.
September, 2000.
[Servlet] [RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
Servlet Specification Version 2.1 and P. Powell, "Internet Printing Protocol/1.0:
(http://java.sun.com/products/servlet/2.1/index.html). Model and Semantics", RFC 2911, September, 2000.
[svrloc-printer] [Servlet] Servlet Specification Version 2.1
St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the (http://java.sun.com/products/servlet/2.1/
Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer- index.html).
scheme-06.txt>, work in progress, March 8, 2000.
[SSL] [svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I.,
Netscape, The SSL Protocol, Version 3, (Text version 3.02), "Definition of the Printer Abstract Service Type
November 1996. v2.0", http://www.isi.edu/in-
notes/iana/assignments/svrloc-
templates/printer.2.0.en (IANA Registered, May 27,
2000).
9 Authors' Address [SSL] Netscape, The SSL Protocol, Version 3, (Text
version 3.02), November 1996.
9. Authors' Addresses
Thomas N. Hastings Thomas N. Hastings
Xerox Corporation Xerox Corporation
701 Aviation Blvd. 701 Aviation Blvd.
El Segundo, CA 90245 El Segundo, CA 90245
hastings@cp10.es.xerox.com
EMail: hastings@cp10.es.xerox.com
Carl-Uno Manros Carl-Uno Manros
Xerox Corporation Independent Consultant
701 Aviation Blvd. 1601 N. Sepulveda Blvd. #505
El Segundo, CA 90245 Manhattan Beach, CA 90266
manros@cp10.es.xerox.com
Email: carl@manros.com
Carl Kugler Carl Kugler
Mail Stop 003G Mail Stop 003G
IBM Printing Systems Co IBM Printing Systems Co
6300 Diagonal Hwy 6300 Diagonal Hwy
Boulder CO 80301 Boulder CO 80301
Kugler@us.ibm.com
EMail: Kugler@us.ibm.com
Henrik Holst Henrik Holst
i-data Printing Systems i-data Printing Systems
Vadstrupvej 35-43 Vadstrupvej 35-43
2880 Bagsvaerd, Denmark 2880 Bagsvaerd, Denmark
hh@I-data.com
EMail: hh@I-data.com
Peter Zehler Peter Zehler
Xerox Corporation Xerox Corporation
800 Philips Road 800 Philips Road
Webster, NY 14580 Webster, NY 14580
peter.zehler@usa.xerox.com
10 Full Copyright Statement EMail: PZehler@crt.xerox.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
Copyright (C) The Internet Society (1999). All Rights Reserved To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end
Implementers of this specification document are encouraged to join
the IPP Mailing List in order to participate in any discussions of
clarification issues and review of registration proposals for
additional attributes and values. In order to reduce spam the
mailing list rejects mail from non-subscribers, so you must subscribe
to the mailing list in order to send a question or comment to the
mailing list.
Other Participants:
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Dennis Carney - IBM
Imaging Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Toshiba Lloyd Young - Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon
Information Systems
10. Description of the Base IPP Documents
In addition to this document, 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]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that
are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator
operations have been added to IPP/1.1 [RFC2911, RFC2910].
The "Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol" document describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specification documents, and gives background and rationale
for the IETF IPP working group's major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues
are addressed.
The "Internet Printing Protocol/1.1: Encoding and Transport" document
is a formal mapping of the abstract operations and attributes defined
in the model document onto HTTP/1.1 [RFC2616]. It also defines the
encoding rules for a new Internet MIME media type called
"application/ipp". This document also defines the rules for
transporting a message body over HTTP whose Content-Type is
"application/ipp". This document defines the 'ipp' scheme for
identifying IPP printers and jobs.
The "Mapping between LPD and IPP Protocols" document gives some
advice to implementers of gateways between IPP and LPD (Line Printer
Daemon) implementations.
11 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 359 change blocks.