draft-ietf-ipp-implementers-guide-v11-01.txt   draft-ietf-ipp-implementers-guide-v11-02.txt 
INTERNET-DRAFT INTERNET-DRAFT
draft-ietf-ipp-implementers-guide-v11-01.txt draft-ietf-ipp-implementers-guide-v11-02.txt
T. Hastings [Obsoletes RFC 2639] T. Hastings
Xerox Corporation Xerox Corporation
C. Manros C. Manros
Xerox Corporation 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 P. Zehler
Xerox Corporation Xerox Corporation
May 30, 2000 January 25, 2001
Internet Printing Protocol/1.1: Implementer's Guide Internet Printing Protocol/1.1: Implementer's Guide
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of [RFC2026]. Internet-Drafts are working all provisions of Section 10 of [RFC2026]. Internet-Drafts are
documents of the Internet Engineering Task Force (IETF), its areas, and working documents of the Internet Engineering Task Force (IETF), its
its working groups. Note that other groups may also distribute working areas, and its working groups. Note that other groups may also
documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document is one of a set of documents, which together describe
This document is one of a set of documents, which together describe all all aspects of a new Internet Printing Protocol (IPP). IPP is an
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing application level protocol that can be used for distributed printing
using Internet tools and technologies. This document contains using Internet tools and technologies. This document contains
information that supplements the IPP Model and Semantics [IPP-MOD] and information that supplements the IPP Model and Semantics [RFC2911]
the IPP Transport and Encoding [IPP-PRO] documents. It is intended to and the IPP Transport and Encoding [RFC2910] documents. It is
intended to help implementers understand IPP/1.1, as well as IPP/1.0,
Expires November 30, 2000 and some of the considerations that may assist them in the design of
their client and/or IPP object implementations. For example, a
help implementers understand IPP/1.1, as well as IPP/1.0, and some of typical order of processing requests is given, including error
the considerations that may assist them in the design of their client checking. Motivation for some of the specification decisions is also
and/or IPP object implementations. For example, a typical order of included.
processing requests is given, including error checking. Motivation for
some of the specification decisions is also included.
Expires November 30, 2000 This document obsoletes RFC 2639 which was the Implementer's Guide
for IPP/1.0.
The full set of IPP documents includes: The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567] Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568] Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [IPP-MOD] Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Mapping between LPD and IPP Protocols [RFC2569] Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes
The document, "Design Goals for an Internet Printing Protocol", takes a a broad look at distributed printing functionality, and it enumerates
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and requirements for three types of users: end users, operators, and
administrators. The design goal document calls out a subset of end user administrators. The design goal document calls out a subset of end
requirements that are satisfied in IPP/1.1. Operator and administrator user requirements that are satisfied in IPP/1.1. Operator and
requirements are out of scope for version 1.1. administrator requirements are out of scope for version 1.1.
The document, "Rationale for the Structure and Model and Protocol for The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level view, the Internet Printing Protocol", describes IPP from a high level
defines a roadmap for the various documents that form the suite of IPP view, defines a roadmap for the various documents that form the suite
specifications, and gives background and rationale for the IETF working of IPP specifications, and gives background and rationale for the
group's major decisions. IETF working group's major decisions.
The document, "Internet Printing Protocol/1.1: Model and Semantics", The document, "Internet Printing Protocol/1.1: Model and Semantics",
describes a simplified model with abstract objects, their attributes, describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues are addresses how security, internationalization, and directory issues
addressed. are addressed.
The document, "Internet Printing Protocol/1.1: Encoding and Transport", The document, "Internet Printing Protocol/1.1: Encoding and
is a formal mapping of the abstract operations and attributes defined in Transport", is a formal mapping of the abstract operations and
the model document onto HTTP/1.1. It also defines the encoding rules attributes defined in the model document onto HTTP/1.1. It also
for a new Internet media type called "application/ipp". defines the encoding rules for a new Internet media type called
"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice The document, "Mapping between LPD and IPP Protocols", gives some
to implementers of gateways between IPP and LPD (Line Printer Daemon) advice to implementers of gateways between IPP and LPD (Line Printer
implementations. Daemon) implementations.
Expires November 30, 2000
TABLE OF CONTENTS TABLE OF CONTENTS
1 INTRODUCTION.......................................................8 1 Introduction....................................................7
1.1 Conformance language.........................................7
1.1 Conformance language.............................................8 1.2 Other terminology............................................8
1.2 Other terminology................................................9 1.3 Issues Raised from Interoperability Testing Events...........8
1.3 Issues Raised from Interoperability Bake Offs....................9
2 IPP OBJECTS........................................................9
3 IPP OPERATIONS....................................................10 2 IPP Objects.....................................................8
3.1 Common Semantics................................................10 3 IPP Operations.................................................10
3.1.1 Summary of Operation Attributes.............................10 3.1 Common Semantics............................................10
3.1.2 Suggested Operation Processing Steps for IPP Objects........16 3.1.1 Summary of Operation Attributes............................10
3.1.2.1 Suggested Operation Processing Steps for all Operations.17 3.1.2 Suggested Operation Processing Steps for IPP Objects.......16
3.1.2.1.1 Validate version number............................17 3.1.2.1 Suggested Operation Processing Steps for all Operations ..17
3.1.2.1.2 Validate operation identifier......................19 3.1.2.1.1 Validate version number...............................18
3.1.2.1.3 Validate the request identifier....................19 3.1.2.1.2 Validate operation identifier.........................19
3.1.2.1.4 Validate attribute group and attribute presence and 3.1.2.1.3 Validate the request identifier.......................19
order 19 3.1.2.1.4 Validate attribute group and attribute presence and order
3.1.2.1.4.1 Validate the presence and order of attribute 19
groups 19 3.1.2.1.4.1 Validate the presence and order of attribute groups .19
3.1.2.1.4.2 Ignore unknown attribute groups in the expected 3.1.2.1.4.2 Ignore unknown attribute groups in the expected
position 20 position 20
3.1.2.1.4.3 Validate the presence of a single occurrence of 3.1.2.1.4.3 Validate the presence of a single occurrence of
required Operation attributes................................20 required Operation attributes.....................................21
3.1.2.1.5 Validate the values of the REQUIRED Operation 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes
attributes 27 28
3.1.2.1.6 Validate the values of the OPTIONAL Operation 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
attributes 31 32
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..........................35 Create/Validate Jobs and Add Documents............................35
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...35 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied......35
3.1.2.2.2 Check that the Printer object is accepting jobs....35 3.1.2.2.2 Check that the Printer object is accepting jobs.......36
3.1.2.2.3 Validate the values of the Job Template attributes.36 3.1.2.2.3 Validate the values of the Job Template attributes....36
3.1.2.3 Algorithm for job validation............................37 3.1.2.3 Algorithm for job validation .............................37
3.1.2.3.1 Check for conflicting Job Template attributes values42 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.2 Decide whether to REJECT the request..................43
3.1.2.3.3 For the Validate-Job operation, RETURN one of the 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
success status codes...........................................44 status codes......................................................45
3.1.2.3.4 Create the Job object with attributes to support...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.............46 3.1.2.3.5 Return one of the success status codes................47
3.1.2.3.6 Accept appended Document Content...................47 3.1.2.3.6 Accept appended Document Content......................48
3.1.2.3.7 Scheduling and Starting to Process the Job.........47 3.1.2.3.7 Scheduling and Starting to Process the Job............48
3.1.2.3.8 Completing the Job.................................47 3.1.2.3.8 Completing the Job....................................48
3.1.2.3.9 Destroying the Job after completion................47 3.1.2.3.9 Destroying the Job after completion...................48
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"..........48 3.1.2.3.10 Interaction with "ipp-attribute-fidelity".............49
3.1.2.3.11 Character set code conversion support..............48 3.1.2.3.11 Character set code conversion support.................49
Expires November 30, 2000
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)?........................................49 requested (Issue 1.19)?...........................................50
3.1.2.3.13 Natural Language Override (NLO)....................50 3.1.2.3.13 Natural Language Override (NLO).......................51
3.1.3 Status codes returned by operation..........................52 3.1.3 Status codes returned by operation.........................53
3.1.3.1 Printer Operations......................................52 3.1.3.1 Printer Operations .......................................53
3.1.3.1.1 Print-Job..........................................52 3.1.3.1.1 Print-Job.............................................53
3.1.3.1.2 Print-URI..........................................54 3.1.3.1.2 Print-URI.............................................55
3.1.3.1.3 Validate-Job.......................................54 3.1.3.1.3 Validate-Job..........................................56
3.1.3.1.4 Create-Job.........................................55 3.1.3.1.4 Create-Job............................................56
3.1.3.1.5 Get-Printer-Attributes.............................55 3.1.3.1.5 Get-Printer-Attributes................................56
3.1.3.1.6 Get-Jobs...........................................56 3.1.3.1.6 Get-Jobs..............................................57
3.1.3.1.7 Pause-Printer......................................57 3.1.3.1.7 Pause-Printer.........................................58
3.1.3.1.8 Resume-Printer.....................................57 3.1.3.1.8 Resume-Printer........................................59
3.1.3.1.8.1 What about Printers unable to change state due to 3.1.3.1.8.1 What about Printers unable to change state due to an
an error condition?..........................................58 error condition?..................................................59
3.1.3.1.8.2 How is 'printer-state' handled on Resume-Printer?58 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? ...59
3.1.3.1.9 Purge-Printer......................................59 3.1.3.1.9 Purge-Printer.........................................60
3.1.3.2 Job Operations..........................................59 3.1.3.2 Job Operations ...........................................60
3.1.3.2.1 Send-Document......................................59 3.1.3.2.1 Send-Document.........................................60
3.1.3.2.2 Send-URI...........................................60 3.1.3.2.2 Send-URI..............................................61
3.1.3.2.3 Cancel-Job.........................................60 3.1.3.2.3 Cancel-Job............................................62
3.1.3.2.4 Get-Job-Attributes.................................61 3.1.3.2.4 Get-Job-Attributes....................................62
3.1.3.2.5 Hold-Job...........................................62 3.1.3.2.5 Hold-Job..............................................63
3.1.3.2.6 Release-Job........................................63 3.1.3.2.6 Release-Job...........................................64
3.1.3.2.7 Restart-Job........................................63 3.1.3.2.7 Restart-Job...........................................64
3.1.3.2.7.1 Can documents be added to a restarted job?.......63 3.1.3.2.7.1 Can documents be added to a restarted job? ..........65
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
1.18) 63 1.18) 65
3.1.5 Sending empty attribute groups..............................64 3.1.5 Sending empty attribute groups.............................65
3.2 Printer Operations..............................................64 3.2 Printer Operations..........................................66
3.2.1 Print-Job operation.........................................64 3.2.1 Print-Job operation........................................66
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 1.22)....................................................64 (Issue 1.22)......................................................66
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)..65 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) ...66
3.2.2 Get-Printer-Attributes operation............................66 3.2.2 Get-Printer-Attributes operation...........................67
3.2.3 Get-Jobs operation..........................................66 3.2.3 Get-Jobs operation.........................................67
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
(Issue 1.39)?...................................................66 1.39)? 67
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
operation?......................................................66 68
3.2.4 Create-Job operation........................................67 3.2.4 Create-Job operation.......................................68
3.3 Job Operations..................................................67 3.3 Job Operations..............................................69
3.3.1 Validate-Job................................................67 3.3.1 Validate-Job...............................................69
3.3.2 Restart-Job.................................................67 3.3.2 Restart-Job................................................69
4 OBJECT ATTRIBUTES.................................................68
4.1 Attribute Syntax's..............................................68
4.1.1 The 'none' value for empty sets (Issue 1.37)................68
Expires November 30, 2000 4 Object Attributes..............................................70
4.1.2 Multi-valued attributes (Issue 1.31)........................68 4.1 Attribute Syntax's..........................................70
4.1.3 Case Sensitivity in URIs (issue 1.6)........................69 4.1.1 The 'none' value for empty sets (Issue 1.37)...............70
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage...69 4.1.2 Multi-valued attributes (Issue 1.31).......................70
4.2 Job Template Attributes.........................................70 4.1.3 Case Sensitivity in URIs (issue 1.6).......................70
4.2.1 multiple-document-handling(type2 keyword)...................70 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage..71
4.2.1.1 Support of multiple document jobs.......................70 4.2 Job Template Attributes.....................................72
4.3 Job Description Attributes......................................70 4.2.1 multiple-document-handling(type2 keyword)..................72
4.4 Printer Description Attributes..................................71 4.2.1.1 Support of multiple document jobs ........................72
4.4.1 queued-job-count............................................71 4.3 Job Description Attributes..................................72
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?.....71 4.3.1 Getting the date and time of day...........................72
4.4 Printer Description Attributes..............................73
4.4.1 queued-job-count (integer(0:MAX))..........................73
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 printer 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer
is (Issue 1.15)?................................................71 is (Issue 1.15)?..................................................73
4.4.2 printer-current-time (dateTime).............................71 4.4.2 printer-current-time (dateTime)............................73
4.4.3 'Printer-uri................................................72 4.4.3 Printer-uri................................................74
4.5 Empty Jobs......................................................72 4.5 Empty Jobs..................................................74
5 DIRECTORY CONSIDERATIONS..........................................73
5.1 General Directory Schema Considerations.........................73
5.2 IPP Printer with a DNS name.....................................73
6 SECURITY CONSIDERATIONS...........................................73 5 Directory Considerations.......................................75
5.1 General Directory Schema Considerations.....................75
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)...................................73 submission protocols (Issue 1.32).................................75
7 ENCODING AND TRANSPORT............................................74
7.1 General Headers.................................................76 7 Encoding and Transport.........................................76
7.2 Request Headers................................................77 7.1 General Headers.............................................78
7.3 Response Headers................................................78 7.2 Request Headers............................................79
7.4 Entity Headers.................................................79 7.3 Response Headers............................................81
7.5 Optional support for HTTP/1.0...................................80 7.4 Entity Headers.............................................81
7.6 HTTP/1.1 Chunking...............................................80 7.5 Optional support for HTTP/1.0...............................82
7.6.1 Disabling IPP Server Response Chunking......................80 7.6 HTTP/1.1 Chunking...........................................83
7.6.2 Warning About the Support of Chunked Requests...............80 7.6.1 Disabling IPP Server Response Chunking.....................83
7.6.2 Warning About the Support of Chunked Requests..............83
8 REFERENCES........................................................81 8 References.....................................................84
9 AUTHORS' ADDRESS..................................................82 9 Authors' Address...............................................85
10 NOTICES..........................................................83 10 Full Copyright Statement.......................................86
TABLES TABLES
Table 1 - Summary of Printer operation attributes that sender MUST Table 1 - Summary of Printer operation attributes that sender MUST
supply............................................................10 supply ........................................................11
Table 2 - Summary of Printer operation attributes that sender MAY
Table 2 - Summary of Printer operation attributes that sender MAY supply supply ........................................................12
.................................................................11 Table 3 - Summary of Job operation attributes that sender MUST supply
..............................................................13
Expires November 30, 2000 Table 4 - Summary of Job operation attributes that sender MAY supply
..............................................................14
Table 3 - Summary of Job operation attributes that sender MUST supply13 Table 5 - Printer operation response attributes...................15
Table 6 - Examples of validating IPP version......................18
Table 4 - Summary of Job operation attributes that sender MAY supply.14 Table 7 - Rules for validating single values X against Z..........38
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.............37
Expires November 30, 2000
1 Introduction 1 Introduction
The IPP Implementer's Guide (IIG) (this document) contains information The IPP Implementer's Guide (IIG) (this document) contains
that supplements the IPP Model and Semantics [IPP-MOD] and the IPP information that supplements the IPP Model and Semantics [RFC2911]
Transport and Encoding [IPP-PRO] documents. As such this information is and the IPP Transport and Encoding [RFC2910] documents. As such this
not part of the formal specifications. Instead information is presented information is not part of the formal specifications. Instead
to help implementers understand the specification, including some of the information is presented to help implementers understand the
motivation for decisions taken by the committee in developing the specification, including some of the motivation for decisions taken
specification. Some of the implementation considerations are intended by the committee in developing the specification. Some of the
to help implementers design their client and/or IPP object implementation considerations are intended to help implementers
implementations. If there are any contradictions between this document design their client and/or IPP object implementations. If there are
and [IPP-MOD] or [IPP-PRO], those documents take precedence over this any contradictions between this document and [RFC2911] or [RFC2910],
document. those documents take precedence over this document.
Platform-specific implementation considerations will be included in this Platform-specific implementation considerations will be included in
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 Semantics In order to help the reader of the IIG and the IPP Model and
document, the sections in this document parallel the corresponding Semantics document, the sections in this document parallel the
sections in the Model document and are numbered the same for ease of corresponding sections in the Model document and are numbered the
cross reference. The sections that correspond to the IPP Transport and same for ease of cross reference. The sections that correspond to
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 NOT, Usually, this document does not contain the terminology MUST, MUST
MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
when those terms do appear in this document, their intent is to repeat However, when those terms do appear in this document, their intent is
what the [IPP-MOD] and [IPP-PRO] documents require and allow, rather to repeat what the [RFC2911] and [RFC2910] documents require and
than specifying additional conformance requirements. These terms are allow, rather than specifying additional conformance requirements.
defined in section 13 on conformance terminology in [IPP-MOD], most of These terms are defined in section 12 on conformance terminology in
which is taken from RFC 2119 [RFC2119]. [RFC2911], most of which is taken from RFC 2119 [RFC2119].
Implementers should read section 13 (APPENDIX A) in [IPP-MOD] in order
to understand these capitalized words. The words MUST, MUST NOT, and
REQUIRED indicate what implementations are required to support in a
client or IPP object in order to be conformant to [IPP-MOD] and [IPP-
PRO]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed as an
implementer option. The verbs SHOULD and SHOULD NOT indicate suggested
behavior, but which is not required or disallowed, respectively, in
order to conform to the specification.
Expires November 30, 2000 Implementers should read section 12 (APPENDIX A) in [RFC2911] in
order to understand these capitalized words. The words MUST, MUST
NOT, and REQUIRED indicate what implementations are required to
support in a client or IPP object in order to be conformant to
[RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is
merely allowed as an implementer option. The verbs SHOULD and SHOULD
NOT indicate suggested behavior, but which is not required or
disallowed, respectively, in order to conform to the specification.
1.2 Other terminology 1.2 Other terminology
The term "sender" refers to the client that sends a request or an IPP This document uses other terms, such as "attributes", "operation",
object that returns a response. The term "receiver" refers to the IPP and "Printer" as defined in [RFC2911] section 12. In addition, the
object that receives a request and to a client that receives a response. term "sender" refers to the client that sends a request or an IPP
object that returns a response. The term "receiver" refers to the
IPP object that receives a request and to a client that receives a
response.
1.3 Issues Raised from Interoperability Bake Offs 1.3 Issues Raised from Interoperability Testing Events
The IPP WG has conducted two open interoperability "Bake Offs". The The IPP WG has conducted three open Interoperability Testing Events.
first bake off was held in September 1998 and Bake Off2 was held in The first one was held in September 1998, the second one was held in
March 1999. See the summary reports in: March 1999, and the third one was held in October 2000. See the
summary reports in:
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/ ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
The issues raised from the first bake off are numbered 1.n in this The issues raised from the first Interoperability Testing Event are
document and are described in: 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
ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ipp-agreed-fixes- Transport" [RFC2565] documents. However, some of the discussion is
981030.pdf left here in the Implementer's Guide to help understanding.
These issue resolutions have been incorporated into the November 16, The issues raised from the second Interoperability Testing Event are
"IPP/1.0 Model and Semantics" [ipp-mod] and the "IPP/1.0 Encoding and numbered 2.n in this document have been incorporated into "IPP/1.1
Transport" [IPP-PRO] documents. However, some of the discussion is left Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
here in the Implementer's Guide to help understanding. Transport" [RFC2910] documents. However, some of the discussion is
left here in the Implementer's Guide to help understanding.
The issues raised from Bake Off2 are numbered 2.n in this document and The issues raised from the third Interoperability Testing Event are
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-off2.pdf ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
2 IPP Objects 2 IPP Objects
The term "client" in IPP is intended to mean any client that issues IPP The term "client" in IPP is intended to mean any client that issues
operation requests and accepts IPP operation responses, whether it be a IPP operation requests and accepts IPP operation responses, whether
desktop or a server. In other words, the term "client" does not just it be a desktop or a server. In other words, the term "client" does
mean end-user clients, such as those associated with desktops. not just mean end-user clients, such as those associated with
desktops.
The term "IPP Printer" in IPP is intended to mean an object that accepts
IPP operation requests and returns IPP operation responses, whether
implemented in a server or a device. An IPP Printer object MAY, if
implemented in a server, turn around and forward received jobs (and
other requests) to other devices and print servers/services, either
using IPP or some other protocol.
Expires November 30, 2000 The term "IPP Printer" in IPP is intended to mean an object that
accepts IPP operation requests and returns IPP operation responses,
whether implemented in a server or a device. An IPP Printer object
MAY, if implemented in a server, turn around and forward received
jobs (and other requests) to other devices and print
servers/services, either using IPP or some other protocol.
3 IPP Operations 3 IPP Operations
This section corresponds to Section 3 "IPP Operations" in the IPP/1.1 This section corresponds to Section 3 "IPP Operations" in the
Model and Semantics document [IPP-MOD]. 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: Legend for the following table:
R indicates a REQUIRED operation that MUST be supported by the IPP R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the attribute object (Printer or Job). For attributes, R indicates that the
MUST be supported by the IPP object supports the associated operation. attribute MUST be supported by the IPP object supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported by O indicates an OPTIONAL operation or attribute that MAY be
the IPP object (Printer or Job). supported by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part of + indicates that this is not an IPP/1.0 feature, but is only a part
IPP/1.1 and future versions of IPP. of IPP/1.1 and future versions of IPP.
Table 1 - Summary of Printer operation attributes that sender MUST Table 1 - Summary of Printer operation attributes that sender MUST
supply supply
Printer Operations Printer Operations
Requests Respo Requests Response
nses s
Operation Print- Pri Crea Get- Get Pause- All Operation Print- Pri Crea Get- Get Pause- All
Attributes Job, nt- te- Printer- - Printer Opera Attributes Job, te- Printer- - Printer Operatio
Validate URI Job Attribut Job , tions Validate URI Job Attribut Job , ns
-Job (R) (O) (O) es (R) s Resume- -Job (R) (O) (O) es (R) s Resume-
(R) Printer (R) Printer
, ,
Purge- Purge-
Printer nt- Printer
(O+) (O+)
Operation parameters--REQUIRED to be supplied by the sender: Operation parameters--REQUIRED to be supplied by the sender:
operation-id R R R R R R operation-id R R R R R R
status-code R status-code R
request-id R R R R R R R request-id R R R R R R R
version-number 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: Operation attributes--REQUIRED to be supplied by the sender:
attributes-charset R R R R R R R
attributes- R R R R R R R attributes- R R R R R R R
natural-language charset
attributes- R R R R R R R
Expires November 30, 2000 natural-
Printer Operations language
Requests Respo
nses
Operation Print- Pri Crea Get- Get Pause- All
Attributes Job, nt- te- Printer- - Printer Opera
Validate URI Job Attribut Job , tions
-Job (R) (O) (O) es (R) s Resume-
(R) Printer
,
Purge-
Printer
(O+)
document-uri R document-uri R
job-id* job-id*
job-uri* job-uri*
last-document last-
document
printer-uri R R R R R R printer-uri R R R R R R
Operation attributes--RECOMMENDED to be supplied by the sender: Operation attributes--RECOMMENDED to be supplied by the sender:
job-name R R R job-name R R R
requesting-user- R R R R R R requesting- R R R R R R
name 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 Requests Respo
nses nses
Operation Attributes Print- Prin Crea Get- Get Pause- All
Job, t- te- Printer - Printer Opera Operation Print- Prin Crea Get- Get Pause- All
Attributes Job, t- te- Printer - Printer Opera
Valida URI Job - Job , tions Valida URI Job - Job , tions
te-Job (O) (O) Attribu s Resume- te-Job (O) (O) Attribu s Resume-
(R) tes (R) (R) Printer (R) tes (R) (R) Printer
, ,
Purge- Purge-
Printer Printer
(O+) (O+)
Operation attributes--OPTIONAL to be supplied by the sender: Operation attributes--OPTIONAL to be supplied by the sender:
status-message O status-message O
detailed-status- O detailed-status- O
message message
document-access- O** document-access- O**
error error
compression O O compression O O
document-format R R R document-format R R R
document-name O O document-name O O
document-natural- O O document-natural- O O
skipping to change at page 12, line 4 skipping to change at page 12, line 32
status-message O status-message O
detailed-status- O detailed-status- O
message message
document-access- O** document-access- O**
error error
compression O O compression O O
document-format R R R document-format R R R
document-name O O document-name O O
document-natural- O O document-natural- O O
language language
Expires November 30, 2000
Printer Operations
Requests Respo
nses
Operation Attributes Print- Prin Crea Get- Get Pause- All
Job, t- te- Printer - Printer Opera
Valida URI Job - Job , tions
te-Job (O) (O) Attribu s Resume-
(R) tes (R) (R) Printer
,
Purge-
Printer
(O+)
ipp-attribute- R R R ipp-attribute- R R R
fidelity fidelity
job-impressions O O O job-impressions O O O
job-k-octets O O O job-k-octets O O O
job-media-sheets O O O job-media-sheets O O O
limit R limit R
message message
my-jobs R my-jobs R
requested-attributes R R requested- R R
attributes
which-jobs R which-jobs R
* "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.
* "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.
Expires November 30, 2000
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 Requests Respons
es es
Operation Attributes Send- Send Cance Get- Hold- All
Docume -URI l-Job Job- Job, Operati Operation Send- Send Cance Get- All
nt (O) (R) Attrib Release ons Attributes Docume -URI l-Job Job- Job, Operatio
nt (O) (R) Attrib Release ns
(O) utes -Job, (O) utes -Job,
(R) Restart (R) Restart
-Job -Job
(O+) (O+)
Operation parameters--REQUIRED to be supplied by the sender: Operation parameters--REQUIRED to be supplied by the sender:
operation-id R R R R R operation-id R R R R R
status-code R status-code R
request-id R R R R R R request-id R R R R R R
version-number R R R R R R version-number R R R R R R
Operation attributes--REQUIRED to be supplied by the sender: Operation attributes--REQUIRED to be supplied by the sender:
attributes-charset R R R R R R attributes-charset R R R R R R
attributes-natural- R R R R R R attributes-natural- R R R R R R
language language
document-uri R document-uri R
skipping to change at page 13, line 34 skipping to change at page 13, line 35
attributes-charset R R R R R R attributes-charset R R R R R R
attributes-natural- R R R R R R attributes-natural- R R R R R R
language language
document-uri R document-uri R
job-id* R R R R R job-id* R R R R R
job-uri* R R R R R job-uri* R R R R R
last-document R R last-document R R
printer-uri R R R R R printer-uri R R R R R
Operation attributes--RECOMMENDED to be supplied by the sender: Operation attributes--RECOMMENDED to be supplied by the sender:
job-name job-name
requesting-user-name R R R R R requesting-user- R R R R R
name
Expires November 30, 2000
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 Requests Respo
nses nses
Operation Attributes Send- Sen Cance Get- Hold- Relea All
Documen d- l-Job Job- Job, se- Opera Operation Send- Sen Cance Hold- Relea All
Attributes Documen d- l-Job Get- Job, se- Opera
t URI (R) Attrib Restar Job tions t URI (R) Attrib Restar Job tions
(O) (O) utes t-Job (O+) (O) (O) utes t-Job (O+)
(R) (O+) (R) (O+)
Operation attributes--OPTIONAL to be supplied by the sender: Operation attributes--OPTIONAL to be supplied by the sender:
status-message O status-message O
detailed-status- O detailed-status- O
message message
document-access-error O** document-access- O**
error
compression O O compression O O
document-format R R document-format R R
document-name O O document-name O O
document-natural- O O document-natural- O O
language language
ipp-attribute- ipp-attribute-
fidelity fidelity
job-impressions job-impressions
job-k-octets job-k-octets
job-media-sheets job-media-sheets
limit limit
message O O O message O O O
job-hold-until R job-hold-until R
my-jobs my-jobs
requested-attributes R requested- R
attributes
which-jobs which-jobs
* "job-id" is REQUIRED only if used together with "printer-uri" to * "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED. identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Send-URI operation only. ** "document-access-error" applies to the Send-URI operation only.
Expires November 30, 2000
Table 5 - Printer operation response attributes Table 5 - Printer operation response attributes
Printer Operations Printer Operations
Response Response
Operation Print- Validat Prin Create Get- Get- Pause- Operation Print- Validat Prin Create Get- Get- Pause-
Attributes Job e-Job t- -Job Printe Jobs Printer Attributes Job e-Job t- -Job Printe Jobs Printer
(R),Send (R) URI (O) r- (R) , (R),Send (R) URI (O) r- (R) ,
- (O), Attrib Resume- - (O), Attrib Resume-
Document Send utes Printer Document Send utes Printer
(O) -URI (R) , (O) -URI (R) ,
(O) Purge- (O) Purge-
Printer Printer
(O+) (O+)
job-uri R R R job-uri R R R
job-id R R R job-id R R R
job-state R R R job-state R R R
job-state- R+ R+ R+ job-state- R+ R+ R+
reasons reasons
number-of- O O O number-of- O O O
intervening- intervening-
jobs jobs
document- O document- O
access-error+ access-error+
skipping to change at page 16, line 5 skipping to change at page 16, line 5
job-id R R R job-id R R R
job-state R R R job-state R R R
job-state- R+ R+ R+ job-state- R+ R+ R+
reasons reasons
number-of- O O O number-of- O O O
intervening- intervening-
jobs jobs
document- O document- O
access-error+ access-error+
Expires November 30, 2000
3.1.2 Suggested Operation Processing Steps for IPP Objects 3.1.2 Suggested Operation Processing Steps for IPP Objects
This section suggests the steps and error checks that an IPP object MAY This section suggests the steps and error checks that an IPP object
perform when processing requests and returning responses. An IPP object MAY perform when processing requests and returning responses. An IPP
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-conforming shown here, in order to be able to accept requests from non-
clients. Not performing all of these error checks is a so-called conforming clients. Not performing all of these error checks is a
"forgiving" implementation. On the other hand, clients that so-called "forgiving" implementation. On the other hand, clients
successfully submit requests to IPP objects that do perform all the that successfully submit requests to IPP objects that do perform all
error checks will be more likely to be able to interoperate with other the error checks will be more likely to be able to interoperate with
IPP object implementations. Thus an implementer of an IPP object needs other IPP object implementations. Thus an implementer of an IPP
to decide whether to be a "forgiving" or a "strict" implementation. object needs to decide whether to be a "forgiving" or a "strict"
Therefore, the error status codes returned may differ between implementation. Therefore, the error status codes returned may
implementations. Consequentially, client SHOULD NOT expect exactly the differ between implementations. Consequentially, client SHOULD NOT
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 or When an IPP object receives a request, the IPP object either accepts
rejects the request. In order to determine whether or not to accept or or rejects the request. In order to determine whether or not to
reject the request, the IPP object SHOULD execute the following steps. accept or reject the request, the IPP object SHOULD execute the
The order of the steps may be rearranged and/or combined, including following steps. The order of the steps may be rearranged and/or
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 client indicated here in order to be a conforming client. Therefore, a
SHOULD supply requests that are conforming, in order to avoid being client SHOULD supply requests that are conforming, in order to avoid
rejected by some IPP object implementations and/or risking different being rejected by some IPP object implementations and/or risking
semantics by different implementations of forgiving implementations. different semantics by different implementations of forgiving
For example, a forgiving implementation that accepts multiple implementations. For example, a forgiving implementation that
occurrences of the same attribute, rather than rejecting the request accepts multiple occurrences of the same attribute, rather than
might use the first occurrences, while another might use the last rejecting the request might use the first occurrences, while another
occurrence. Thus such a non-conforming client would get different might use the last occurrence. Thus such a non-conforming client
results from the two forgiving implementations. would get different results from the two forgiving implementations.
In the following, processing continues step by step until a "RETURNS the
xxx status code ..." statement is encountered. Error returns are
indicated by the verb: "REJECTS". Since clients have difficulty getting
the status code before sending all of the document data in a Print-Job
request, clients SHOULD use the Validate-Job operation before sending
large documents to be printed, in order to validate whether the IPP
Printer will accept the job or not.
It is assumed that security authentication and authorization has already In the following, processing continues step by step until a "RETURNS
taken place at a lower layer. the xxx status code ..." statement is encountered. Error returns are
indicated by the verb: "REJECTS". Since clients have difficulty
getting the status code before sending all of the document data in a
Print-Job request, clients SHOULD use the Validate-Job operation
before sending large documents to be printed, in order to validate
whether the IPP Printer will accept the job or not.
Expires November 30, 2000 It is assumed that security authentication and authorization has
already taken place at a lower layer.
3.1.2.1 Suggested Operation Processing Steps for all Operations 3.1.2.1 Suggested Operation Processing Steps for all Operations
This section is intended to apply to all operations. The next section This section is intended to apply to all operations. The next
contains the additional steps for the Print-Job, Validate-Job, Print- section contains the additional steps for the Print-Job, Validate-
URI, Create-Job, Send-Document, and Send-URI operations that create Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
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
3.1.2.1.1 <Validate version> --> server-error-version-not-supported 3.1.2.1.1 <Validate version> --> server-error-version-not-
supported
ok| ok|
v err v err
3.1.2.1.2 <Validate operation> --> server-error-operation-not-supported 3.1.2.1.2 <Validate operation> --> server-error-operation-not-
supported
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 <Valied values of> --> client-error-bad-request
<operation attrs> client-error-request-value-too-long <operation attrs> client-error-request-value-
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-supported <with supported values> client-error-charset-not-
ok| client-error-attributes-or-values- supported
ok| client-error-attributes-or-
values-
| 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-not- <operation attr> client-error-natural-language-
ok| supported not-supported
| client-error-request-value-too-long | client-error-request-value-
| client-error-attributes-or-values- too-long
v not-supported | client-error-attributes-or-
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 version attribute. The value of this attribute is the major and minor
version number of the syntax and semantics that the client and IPP
Expires November 30, 2000 object is using, respectively. The "version-number" attribute
remains in a fixed position across all future versions so that all
number of the syntax and semantics that the client and IPP object is clients and IPP object that support future versions can determine
using, respectively. The "version-number" attribute remains in a fixed which version is being used. The IPP object checks to see if the
position across all future versions so that all clients and IPP object major version number supplied in the request is supported. If not,
that support future versions can determine which version is being used. the Printer object REJECTS the request and RETURNS the 'server-error-
The IPP object checks to see if the major version number supplied in the version-not-supported' status code in the response. The IPP object
request is supported. If not, the Printer object REJECTS the request returns in the "version-number" response attribute the major and
and RETURNS the 'server-error-version-not-supported' status code in the minor version for the error response. Thus the client can learn at
response. The IPP object returns in the "version-number" response least one major and minor version that the IPP object supports. The
attribute the major and minor version for the error response. Thus the IPP object is encouraged to return the closest version number to the
client can learn at least one major and minor version that the IPP one supplied by the client.
object supports. The IPP object is encouraged to return the closest
version number to the one supplied by the client.
The checking of the minor version number is implementation dependent, 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 number. the IPP object MUST respond using that identical minor version
If the major version number matches, but the minor version number does number. If the major version number matches, but the minor version
not, the Printer SHOULD accept and attempt to process the request, or number does not, the Printer SHOULD accept and attempt to process
MAY reject the request and return the 'server-error-version-not- the request, or MAY reject the request and return the 'server-error-
supported' status code. In all cases, the Printer MUST return the version-not-supported' status code. In all cases, the Printer MUST
nearest version number that it supports. For example, suppose that an return the nearest version number that it supports. For example,
IPP/1.2 Printer supports versions '1.1' and '1.2'. The following suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
responses are conforming: The following responses are conforming:
Table 6 - Examples of validating IPP version Table 6 - Examples of validating IPP version
Client Printer Accept Request? Printer returns Client supplies Printer Accept Request? Printer returns
supplies
1.0 yes (SHOULD) 1.1 1.0 yes (SHOULD) 1.1
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
1.3 yes (SHOULD) 1.2 1.3 yes (SHOULD) 1.2
no (SHOULD NOT) 1.2 1.3 no (SHOULD NOT) 1.2
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 so that they can interoperate with either client implementations.
that they can interoperate with either client implementations. Some Some implementations may allow an Administrator to explicitly disable
implementations may allow an Administrator to explicitly disable support support for one or the other by setting the "ipp-versions-supported"
for one or the other by setting the "ipp-versions-supported" Printer Printer description attribute.
description attribute.
Expires November 30, 2000
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 object's supplied by the client is supported as indicated in the Printer
"operations-supported" attribute. If not, the Printer REJECTS the object's "operations-supported" attribute. If not, the Printer
request and returns the 'server-error-operation-not-supported' status REJECTS the request and returns the 'server-error-operation-not-
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" attribute The Printer object SHOULD NOT check to see if the "request-id"
supplied by the client is in range: between 1 and 2**31 - 1 (inclusive), attribute supplied by the client is in range: between 1 and 2**31 - 1
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 all "version-number" parameter will be the same fixed octet position in
versions of the protocol. These fields are validated before proceeding all versions of the protocol. These fields are validated before
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 implementation. The order of the following validation steps depends on
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
that Section 3 requires to be present and in a specified order. An
IPP object verifies that the attribute groups are present and in the
correct order in requests supplied by clients (attribute groups
without an * in the following tables).
Client requests and IPP object responses contain attribute groups that If an IPP object receives a request with (1) required attribute
Section 3 requires to be present and in a specified order. An IPP groups missing, or (2) the attributes groups are out of order, or (3)
object verifies that the attribute groups are present and in the correct the groups are repeated, the IPP object REJECTS the request and
order in requests supplied by clients (attribute groups without an * in RETURNS the 'client-error-bad-request' status code. For example, it
the following tables). is an error for the Job Template Attributes group to occur before the
Operation Attributes group, for the Operation Attributes group to be
If an IPP object receives a request with (1) required attribute groups omitted, or for an attribute group to occur more than once, except in
missing, or (2) the attributes groups are out of order, or (3) the the Get-Jobs response.
groups are repeated, the IPP object REJECTS the request and RETURNS the
'client-error-bad-request' status code. For example, it is an error for
the Job Template Attributes group to occur before the Operation
Attributes group, for the Operation Attributes group to be omitted, or
for an attribute group to occur more than once, except in the Get-Jobs
response.
Expires November 30, 2000
Since this kind of attribute group error is most likely to be an error Since this kind of attribute group error is most likely to be an
detected by a client developer rather than by a customer, the IPP object error detected by a client developer rather than by a customer, the
NEED NOT return an indication of which attribute group was in error in IPP object NEED NOT return an indication of which attribute group was
either the Unsupported Attributes group or the Status Message. Also, in error in either the Unsupported Attributes group or the Status
the IPP object NEED NOT find all attribute group errors before returning Message. Also, the IPP object NEED NOT find all attribute group
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 of requests just before the Document Content and at the end of
requests just before the Document Content and at the end of response, response, except for the Get-Jobs response, where it maybe there or
except for the Get-Jobs response, where it maybe there or before the before the first job attributes returned. If an IPP object receives
first job attributes returned. If an IPP object receives an unknown an unknown attribute group in these positions, it ignores the entire
attribute group in these positions, it ignores the entire group, rather group, rather than returning an error, since that group may be a new
than returning an error, since that group may be a new group in a later group in a later minor version of the protocol that can be ignored.
minor version of the protocol that can be ignored. (If the new (If the new attribute group cannot be ignored without confusing the
attribute group cannot be ignored without confusing the client, the client, the major version number would have been increased in the
major version number would have been increased in the protocol document protocol document and in the request). If the unknown group occurs
and in the request). If the unknown group occurs in a different in a different position, the IPP object REJECTS the request and
position, the IPP object REJECTS the request and RETURNS the 'client- RETURNS the 'client-error-bad-request' status code.
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 objects Note: By validating that requests are in the proper form, IPP
force clients to use the proper form which, in turn, increases the objects force clients to use the proper form which, in turn,
chances that customers will be able to use such clients from multiple increases the chances that customers will be able to use such clients
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 [IPP-MOD] 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, charset, group may be in any order, except for the ordering of target,
and natural languages attributes. These attributes MUST be first, and charset, and natural languages attributes. These attributes MUST be
MUST be supplied in the following order: charset, natural language, and first, and MUST be supplied in the following order: charset, natural
then target. An IPP object verifies that the attributes that Section 4 language, and then target. An IPP object verifies that the attributes
requires to be supplied by the client have been supplied in the request that Section 4 requires to be supplied by the client have been
(attributes without an * in the following tables). An asterisk (*) supplied in the request (attributes without an * in the following
indicates groups and Operation attributes that the client may omit in a tables). An asterisk (*) indicates groups and Operation attributes
request or an IPP object may omit in a response. that the client may omit in a request or an IPP object may omit in a
response.
If an IPP object receives a request with required attributes missing or If an IPP object receives a request with required attributes missing
repeated from a group or in the wrong position, the behavior of the IPP or repeated from a group or in the wrong position, the behavior of
object is IMPLEMENTATION DEPENDENT. Some of the possible the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
implementations are: implementations are:
Expires November 30, 2000 REJECTS the request and RETURNS the 'client-error-bad-request'
1. REJECTS the request and RETURNS the 'client-error-bad-request'
status code status code
2. 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
3. accepts the request and uses the last occurrence of the attribute accepts the request and uses the last occurrence of the
no matter where it is attribute no matter where it is
4. accept the request and assume some default value for the missing accept the request and assume some default value for the
attribute missing attribute
Therefore, client MUST send conforming requests, if they want to receive Therefore, client MUST send conforming requests, if they want to
the same behavior from all IPP object implementations. For example, it receive the same behavior from all IPP object implementations. For
is an error for the "attributes-charset" or "attributes-natural- example, it is an error for the "attributes-charset" or "attributes-
language" attribute to be omitted in any operation request, or for an natural-language" attribute to be omitted in any operation request,
Operation attribute to be supplied in a Job Template group or a Job or for an Operation attribute to be supplied in a Job Template group
Template attribute to be supplied in an Operation Attribute group in a or a Job Template attribute to be supplied in an Operation Attribute
create request. It is also an error to supply the "attributes-charset" group in a create request. It is also an error to supply the
attribute twice. "attributes-charset" attribute twice.
Since these kinds of attribute errors are most likely to be detected by Since these kinds of attribute errors are most likely to be detected
a client developer rather than by a customer, the IPP object NEED NOT by a client developer rather than by a customer, the IPP object NEED
return an indication of which attribute was in error in either the NOT return an indication of which attribute was in error in either
Unsupported Attributes group or the Status Message. Also, the IPP the Unsupported Attributes group or the Status Message. Also, the
object NEED NOT find all attribute errors before returning this error. IPP object NEED NOT find all attribute errors before returning this
error.
The following tables list all the attributes for all the operations by The following tables list all the attributes for all the operations
attribute group in each request and each response. The order of the by attribute group in each request and each response. The order of
groups is the order that the client supplies the groups as specified in the groups is the order that the client supplies the groups as
[IPP-MOD] Section 3. The order of the attributes within a group is specified in [RFC2911] Section 3. The order of the attributes within
arbitrary, except as noted for some of the special operation attributes a group is arbitrary, except as noted for some of the special
(charset, natural language, and target). The tables below use the operation attributes (charset, natural language, and target). The
following notation: tables below use the following notation:
R indicates a REQUIRED attribute or operation that an IPP object MUST R indicates a REQUIRED attribute or operation that an IPP object
support MUST support
O indicates an OPTIONAL attribute or operation that an IPP object O indicates an OPTIONAL attribute or operation that an IPP
NEED NOT support object NEED NOT support
* indicates that a client MAY omit the attribute in a request and * indicates that a client MAY omit the attribute in a request
that an IPP object MAY omit the attribute in a response. and that an IPP object MAY omit the attribute in a
The absence of an * means that a client MUST supply the response. The absence of an * means that a client MUST
attribute in a request and an IPP object MUST supply the supply the attribute in a request and an IPP object
attribute in a response. MUST supply the attribute in a response.
+ indicates that this is not a IPP/1.0 operation, but is only a part + indicates that this is not a IPP/1.0 operation, but is only a
of IPP/1.1 and future versions of IPP. part of IPP/1.1 and future versions of IPP.
Operation Requests Operation Requests
Expires November 30, 2000
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-id", Note: All operation requests contain "version-number", "operation-
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 (O*)
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 [IPP-MOD] 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*)
skipping to change at page 22, line 51 skipping to change at page 23, line 21
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 (O*)
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 [IPP-MOD] Section 4.2) (see [RFC2911] Section 4.2)
Expires November 30, 2000
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 (O*)
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 [IPP-MOD] 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)
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*)
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 [IPP-MOD] Section 4.2) (see [RFC2911] Section 4.2)
Get-Printer-Attributes Request (R): Get-Printer-Attributes 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*)
requested-attributes (R*) requested-attributes (R*)
document-format (R*) document-format (R*)
Get-Jobs Request (R): Get-Jobs 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)
Expires November 30, 2000
printer-uri (R) printer-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
limit (R*) limit (R*)
requested-attributes (R*) requested-attributes (R*)
which-jobs (R*) which-jobs (R*)
my-jobs (R*) my-jobs (R*)
Send-Document Request (O): Send-Document Request (O):
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
skipping to change at page 25, line 4 skipping to change at page 25, line 20
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*)
Get-Job-Attributes Request (R): Get-Job-Attributes 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 & job-id) | job-uri (R) (printer-uri & job-id) | job-uri (R)
Expires November 30, 2000
requesting-user-name (R*) requesting-user-name (R*)
requested-attributes (R*) requested-attributes (R*)
Pause-Printer Request (O+): Pause-Printer Request (O+):
Resume-Printer Request (O+): Resume-Printer Request (O+):
Purge-Printer Request (O+): Purge-Printer 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)
skipping to change at page 25, line 30 skipping to change at page 25, line 44
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*)
job-hold-until (R*) job-hold-until (R*)
message (O*) message (O*)
Operation Responses Operation Responses
The tables below show the response attributes in their proper attribute The tables below show the response attributes in their proper
groups for responses. attribute groups for responses.
Note: All operation responses contain "version-number", "status-code", Note: All operation responses contain "version-number", "status-
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*) <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)
skipping to change at page 26, line 5 skipping to change at page 26, line 20
Group 2: Unsupported Attributes (R*) (see Note 3) Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*) <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*)
Expires November 30, 2000
Validate-Job Response (R): Validate-Job Response (R):
Cancel-Job Response (R): Cancel-Job Response (R):
Hold-Job Response (O+): Hold-Job Response (O+):
Release-Job Response (O+): Release-Job Response (O+):
Restart-Job Response (O+): Restart-Job 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*)
skipping to change at page 27, line 4 skipping to change at page 27, line 16
Group 2: Unsupported Attributes (R*) (see Note 4) Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*) <unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2) Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*) <requested attributes> (R*)
Get-Jobs Response (R): Get-Jobs Response (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)
status-message (O*) status-message (O*)
Expires November 30, 2000
detailed-status-message (O*) detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4) Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*) <unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5) Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*) <requested attributes> (R*)
Get-Job-Attributes Response (R): Get-Job-Attributes Response (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)
skipping to change at page 27, line 35 skipping to change at page 27, line 45
Purge-Printer Response (O+): Purge-Printer 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 4) Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*) <unsupported attributes> (R*)
Note 2 - the Job Object Attributes and Printer Object Attributes are Note 2 - the Job Object Attributes and Printer Object Attributes are
returned only if the IPP object returns one of the success status codes. returned only if the IPP object returns one of the success status
codes.
Note 3 - the Unsupported Attributes Group is present only if the client Note 3 - the Unsupported Attributes Group is present only if the
included some Operation and/or Job Template attributes or values that client included some Operation and/or Job Template attributes or
the Printer doesn't support whether a success or an error return. values that the Printer doesn't support whether a success or an error
return.
Note 4 - the Unsupported Attributes Group is present only if the client Note 4 - the Unsupported Attributes Group is present only if the
included some Operation attributes that the Printer doesn't support client included some Operation attributes that the Printer doesn't
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 Job Note 5: for the Get-Jobs operation the response contains a separate
Object Attributes group 3 to N containing requested-attributes for each Job Object Attributes group 3 to N containing requested-attributes
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 next REQUIRED Operation attribute that the IPP object MUST support. The
next section specifies the validation of the values of the OPTIONAL
Expires November 30, 2000 Operation attributes that IPP objects MAY support.
section specifies the validation of the values of the OPTIONAL Operation
attributes that IPP objects MAY support.
The IPP object performs the following syntactic validation checks of 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 correct for a) that the length of each Operation attribute value is
the attribute syntax tag supplied by the client according to [IPP- correct for the attribute syntax tag supplied by the client
MOD] Section 4.1, according 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 [IPP-MOD] 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 [IPP-MOD] 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 X operation attributes that are multi-valued, i.e., that are 1setOf
according to [IPP-MOD] Section 3. 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 be value-too-long' status code. Since such an error is most likely to
an error detected by a client developer, rather than by an end-user, the be an error detected by a client developer, rather than by an end-
IPP object NEED NOT return an indication of which attribute had the user, the IPP object NEED NOT return an indication of which attribute
error in either the Unsupported Attributes Group or the Status Message. had the error in either the Unsupported Attributes Group or the
The description for each of these syntactic checks is explicitly Status Message. The description for each of these syntactic checks
expressed in the first IF statement in the following table. is explicitly expressed in the first IF statement in the following
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 there against some Printer object attribute or some hard-coded value if
is no "xxx-supported" Printer object attribute defined. If its value is there is no "xxx-supported" Printer object attribute defined. If its
not among those supported or is not in the range supported, then the IPP value is not among those supported or is not in the range supported,
object REJECTS the request and RETURNS the error status code indicated then the IPP object REJECTS the request and RETURNS the error status
in the table by the second IF statement. If the value of the Printer code indicated in the table by the second IF statement. If the value
object's "xxx-supported" attribute is 'no-value' (because the system of the Printer object's "xxx-supported" attribute is 'no-value'
administrator hasn't configured a value), the check always fails. (because the system administrator hasn't configured a value), the
check always fails.
----------------------------------------------- -----------------------------------------------
attributes-charset (charset) attributes-charset (charset)
IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client- IF NOT a single non-empty 'charset' value, REJECT/RETURN
error-bad-request'. 'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
Expires November 30, 2000
IF NOT in the Printer object's "charset-supported" attribute, IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported". 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 IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
ACCEPT the request even if not a member of the set in the Printer ACCEPT the request even if not a member of the set in the
object's "generated-natural-language-supported" attribute. If Printer object's "generated-natural-language-supported"
the supplied value is not a member of the Printer object's attribute. If the supplied value is not a member of the
"generated-natural-language-supported" attribute, use the Printer object's "generated-natural-language-supported"
Printer object's "natural-language-configured" value. 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 IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
IF the IPP object can obtain a better-authenticated name, use it IF the IPP object can obtain a better-authenticated name, use it
instead. instead.
skipping to change at page 29, line 50 skipping to change at page 30, line 19
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 IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. '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- IF the value length is NOT equal to 1 octet, REJECT/RETURN
error-request-value-too-long' 'client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the value IF NOT supplied by the client, the IPP object assumes the value
'false'. 'false'.
Expires November 30, 2000
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 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 "document-format-supported" IF NOT in the Printer object's "document-format-supported"
attribute, REJECT/RETURN 'client-error-document-format-not- attribute, REJECT/RETURN 'client-error-document-format-not-
supported' supported'
IF NOT supplied by the client, the IPP object assumes the value of IF NOT supplied by the client, the IPP object assumes the value
the Printer object's "document-format-default" attribute. 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-error- IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
bad-request'. error-bad-request'.
IF the value length is greater than 1023 octets, REJECT/RETURN IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad- IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
request'. request'.
If the client-supplied URI scheme is not supported, i.e. the value If the client-supplied URI scheme is not supported, i.e. the
is not in the Printer object's referenced-uri-scheme- value is not in the Printer object's referenced-uri-scheme-
supported" attribute, the Printer object MUST reject the supported" attribute, the Printer object MUST reject the
request and return the 'client-error-uri-scheme-not-supported' request and return the 'client-error-uri-scheme-not-
status code. The Printer object MAY check to see if the supported' status code. The Printer object MAY check to see
document exists and is accessible. If the document is not if the document exists and is accessible. If the document
found or is not accessible, REJECT/RETURN 'client-error-not is not found or is not accessible, REJECT/RETURN 'client-
found'. error-not found'.
last-document (boolean) last-document (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- IF the value length is NOT equal to 1 octet, REJECT/RETURN
error-request-value-too-long' '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 range IF NOT an single 'integer' value equal to 4 octets AND in the
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- IF NOT a job-id of an existing Job object, REJECT/RETURN
error-not-found' or 'client-error-gone' status code, if keep 'client-error-not-found' or 'client-error-gone' status
track of recently deleted jobs. 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-error- IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
bad-request'. error-bad-request'.
Expires November 30, 2000
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'.
Ignore unsupported values, which are the keyword names of Ignore unsupported values, which are the keyword names of
unsupported attributes. Don't bother to copy such requested unsupported attributes. Don't bother to copy such
(unsupported) attributes to the Unsupported Attribute response requested (unsupported) attributes to the Unsupported
group since the response will not return them. 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-bad- IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-
request'. bad-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 NEITHER 'completed' NOR 'not-completed', copy the attribute and IF NEITHER 'completed' NOR 'not-completed', copy the attribute
the unsupported value to the Unsupported Attributes response and the unsupported value to the Unsupported Attributes
group and REJECT/RETURN 'client-error-attributes-or-values- response group and REJECT/RETURN 'client-error-attributes-
not-supported'. or-values-not-supported'.
Note: a Printer still supports the 'completed' value even if it Note: a Printer still supports the 'completed' value even if it
keeps no completed/canceled/aborted jobs: by returning no keeps no completed/canceled/aborted jobs: by returning no
jobs when so queried. jobs when so queried.
IF NOT supplied by the client, the IPP object assumes the 'not- IF NOT supplied by the client, the IPP object assumes the 'not-
completed' value. 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- IF the value length is NOT equal to 1 octet, REJECT/RETURN
error-request-value-too-long' 'client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the 'false' IF NOT supplied by the client, the IPP object assumes the
value. 'false' value.
limit (integer(1:MAX)) limit (integer(1:MAX))
IF NOT a single 'integer' value equal to 4 octets AND in the range IF NOT a single 'integer' value equal to 4 octets AND in the
1 to MAX, REJECT/RETURN 'client-error-bad-request'. range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, the IPP object returns all jobs, no IF NOT supplied by the client, the IPP object returns all jobs,
matter how many. 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 or MAY OPTIONAL Operation attributes are those that an IPP object MAY
NOT 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
Expires November 30, 2000
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 object Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP
REJECTS the request and RETURNS the 'client-error-bad-request' or the object REJECTS the request and RETURNS the 'client-error-bad-request'
'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 no against some Printer attribute or some hard-coded value if there is
"xxx-supported" Printer attribute defined. If its value is not among no "xxx-supported" Printer attribute defined. If its value is not
those supported or is not in the range supported, then the IPP object among those supported or is not in the range supported, then the IPP
REJECTS the request and RETURNS the error status code indicated in the object REJECTS the request and RETURNS the error status code
table. If the value of the Printer object's "xxx-supported" attribute indicated in the table. If the value of the Printer object's "xxx-
is 'no-value' (because the system administrator hasn't configured a supported" attribute is 'no-value' (because the system administrator
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 object If the IPP object doesn't recognize/support an attribute, the IPP
treats the attribute as an unknown or unsupported attribute (see the object treats the attribute as an unknown or unsupported attribute
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 IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
IF NOT a value that the Printer object supports in document IF NOT a value that the Printer object supports in document
skipping to change at page 32, line 55 skipping to change at page 33, line 19
Unsupported Attributes response group and REJECT/RETURN Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-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 IPP/1.1. However, an IPP/1.0 object SHOULD at least check in IPP/1.1. However, an IPP/1.0 object SHOULD at least check
for the "compression" attribute being present and reject the for the "compression" attribute being present and reject the
create request, if they don't support "compression". Not create request, if they don't support "compression". Not
checking is a bug, since the data will be unintelligible. checking is a 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,
Expires November 30, 2000 IF NOT a single 'integer' value equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-k-octets- IF NOT in the range of the Printer object's "job-k-octets-
supported" attribute, copy the attribute and the unsupported supported" attribute, copy the attribute and the unsupported
value to the Unsupported Attributes response group and value to the Unsupported Attributes response group and
REJECT/RETURN 'client-error-attributes-or-values-not- REJECT/RETURN 'client-error-attributes-or-values-not-
supported'. 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,
skipping to change at page 33, line 50 skipping to change at page 34, line 15
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 the
length is not legal for that attribute syntax, REJECT/RETURN 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 ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of- response group and change the attribute value to the "out-of-
band" 'unsupported' value, but otherwise ignore the attribute. 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 the specification that may occur anywhere in the specified group. When
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. Ignoring 'successful-ok-ignored-or-substituted-attributes' status code.
unsupported Operation attributes in all operations is analogous to the Ignoring unsupported Operation attributes in all operations is
analogous to the handling of unsupported Job Template attributes in
Expires November 30, 2000 the create and Validate-Job operations when the client supplies the
"ipp-attribute-fidelity" Operation attribute with the 'false' value.
handling of unsupported Job Template attributes in the create and This last rule is so that we can add OPTIONAL Operation attributes to
Validate-Job operations when the client supplies the "ipp-attribute- future versions of IPP so that older clients can inter-work with new
fidelity" Operation attribute with the 'false' value. This last rule is IPP objects and newer clients can inter-work with older IPP objects.
so that we can add OPTIONAL Operation attributes to future versions of (If the new attribute cannot be ignored without performing
IPP so that older clients can inter-work with new IPP objects and newer unexpectedly, the major version number would have been increased in
clients can inter-work with older IPP objects. (If the new attribute the protocol document and in the request). This rule for Operation
cannot be ignored without performing unexpectedly, the major version attributes is independent of the value of the "ipp-attribute-
number would have been increased in the protocol document and in the fidelity" attribute. For example, if an IPP object doesn't support
request). This rule for Operation attributes is independent of the the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k-
value of the "ipp-attribute-fidelity" attribute. For example, if an octets" as an unknown attribute and only checks the length for the
IPP object doesn't support the OPTIONAL "job-k-octets" attribute', the 'integer' attribute syntax supplied by the client. If it is not four
IPP object treats "job-k-octets" as an unknown attribute and only checks octets, the IPP object REJECTS the request and RETURNS the 'client-
the length for the 'integer' attribute syntax supplied by the client. error-bad-request' status code, else the IPP object copies the
If it is not four octets, the IPP object REJECTS the request and RETURNS attribute to the Unsupported Attribute response group, setting the
the 'client-error-bad-request' status code, else the IPP object copies
the attribute to the Unsupported Attribute response group, setting the
value to the "out-of-band" 'unsupported' value, but otherwise ignores value to the "out-of-band" 'unsupported' value, but otherwise ignores
the attribute. the attribute.
Expires November 30, 2000
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-Job, processing steps for the Print-Job, Validate-Job, Print-URI, Create-
Send-Document, and Send-URI operations that IPP objects SHOULD use. Job, Send-Document, and Send-URI operations that IPP objects SHOULD
These are the operations that create jobs, validate a Print-Job request, use. These are the operations that create jobs, validate a Print-Job
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
---------- ---- ---------------------- ---------- ---- ----------------------
| |
v No v No
3.1.2.2.1 <ipp-attribute-fidelity> ------------------+ 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
<supplied?> | <supplied?> |
Yes| | Yes| |
| ipp-attribute-fidelity = no | | ipp-attribute-fidelity = no |
|<------------------------------+ |<------------------------------+
v No v No
3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs 3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
<accepting jobs?> <accepting jobs?>
Yes| Yes|
v err v err
3.1.2.3 <Validate values of> --> client-error-bad-request 3.1.2.3 <Validate values of> --> client-error-bad-request
<Job template attributes> client-error-request-value-too-long <Job template attributes> client-error-request-value-too-
long
<(length, tag, range,> <(length, tag, range,>
<multi-value)> <multi-value)>
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-values- <supported values> client-error-attributes-or-
ok| not-supported | values-not-supported
v err v err
3.1.2.3.1 <Any conflicting> --> client-error-conflicting-attributes 3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
<Job Template attr values> client-error-attributes-or-values- attributes
ok| not-supported <Job Template attr values> client-error-attributes-or-
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
Expires November 30, 2000
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 'server- 'false', the Printer object REJECTS the request and RETURNS the
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 syntactic supplied by the client. The IPP object performs the analogous
validation checks of each Job Template attribute value that it performs syntactic validation checks of each Job Template attribute value that
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 [IPP-MOD] Section 4.1. syntax tag supplied by the client according to [RFC2911] 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 [IPP-MOD] 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 [IPP-MOD] Sections attributes, i.e., that are 1setOf X according to [RFC2911]
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 IPP As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
object REJECTS the request and RETURNS the 'client-error-bad-request' or IPP object REJECTS the request and RETURNS the 'client-error-bad-
'client-error-request-value-too-long' status code as appropriate, request' or 'client-error-request-value-too-long' status code as
independent of the value of the "ipp-attribute-fidelity". Since such an appropriate, independent of the value of the "ipp-attribute-
error is most likely to be an error detected by a client developer, fidelity". Since such an error is most likely to be an error
rather than by an end-user, the IPP object NEED NOT return an indication detected by a client developer, rather than by an end-user, the IPP
of which attribute had the error in either the Unsupported Attributes object NEED NOT return an indication of which attribute had the error
Group or the Status Message. The description for each of these in either the Unsupported Attributes Group or the Status Message.
syntactic checks is explicitly expressed in the first IF statement in The description for each of these syntactic checks is explicitly
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
Expires November 30, 2000
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 [ipp-mod]). 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 algorithm: value V of Printer "xxx-supported", perform the following
algorithm:
1.If U is multi-valued, validate each value X of U by performing the 1.If U is multi-valued, validate each value X of U by performing
algorithm in Table 7 with each value X. Each validation is separate the algorithm in Table 7 with each value X. Each validation is
from the standpoint of returning unsupported values. Example: If U separate from the standpoint of returning unsupported values.
is "finishings" that the client supplies with 'staple', 'bind' Example: If U is "finishings" that the client supplies with
values, then X takes on the successive values: 'staple', then 'bind' 'staple', 'bind' values, then X takes on the successive values:
'staple', then 'bind'
2.If V is multi-valued, validate X against each Z of V by performing 2.If V is multi-valued, validate X against each Z of V by
the algorithm in Table 7 with each value Z. If a value Z validates, performing the algorithm in Table 7 with each value Z. If a
the validation for the attribute value X succeeds. If it fails, the value Z validates, the validation for the attribute value X
algorithm is applied to the next value Z of V. If there are no more succeeds. If it fails, the algorithm is applied to the next
values Z of V, validation fails. Example" If V is "sides-supported" value Z of V. If there are no more values Z of V, validation
with values: 'one-sided', 'two-sided-long', and 'two-sided-short', fails. Example" If V is "sides-supported" with values: 'one-
then Z takes on the successive values: 'one-sided', 'two-sided- sided', 'two-sided-long', and 'two-sided-short', then Z takes on
long', and 'two-sided-short'. If the client supplies "sides" with the successive values: 'one-sided', 'two-sided-long', and 'two-
'two-sided-long', the first comparison fails ('one-sided' is not sided-short'. If the client supplies "sides" with 'two-sided-
equal to 'two-sided-long'), the second comparison succeeds ('two- long', the first comparison fails ('one-sided' is not equal to
sided-long' is equal to 'two-sided-long"), and the third comparison 'two-sided-long'), the second comparison succeeds ('two-sided-
long' is equal to 'two-sided-long"), and the third comparison
('two-sided-short' with 'two-sided-long') is not even performed. ('two-sided-short' with 'two-sided-long') is not even performed.
3.If both U and V are single-valued, let X be U and Z be V and use the 3.If both U and V are single-valued, let X be U and Z be V and use
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 attribute validated if: Attribute syntax attribute syntax validated if:
syntax of X syntax 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 Z
uri uriScheme the uri scheme in X is equal to
Z
any boolean the value of Z is TRUE any boolean the value of Z is TRUE
any any X and Z are of the same type and are
equal.
Expires November 30, 2000 any any X and Z are of the same type
and are equal.
If the value of the Printer object's "xxx-supported" attribute is 'no- If the value of the Printer object's "xxx-supported" attribute is
value' (because the system administrator hasn't configured a value), the 'no-value' (because the system administrator hasn't configured a
check always fails. If the check fails, the IPP object copies the value), the check always fails. If the check fails, the IPP object
attribute to the Unsupported Attributes response group with its copies the attribute to the Unsupported Attributes response group
unsupported value. If the attribute contains more than one value, each with its unsupported value. If the attribute contains more than one
value is checked and each unsupported value is separately copied, while value, each value is checked and each unsupported value is separately
supported values are not copied. If an IPP object doesn't copied, while supported values are not copied. If an IPP object
recognize/support a Job Template attribute, i.e., there is no doesn't recognize/support a Job Template attribute, i.e., there is no
corresponding Printer object "xxx-supported" attribute, the IPP object corresponding Printer object "xxx-supported" attribute, the IPP
treats the attribute as an unknown or unsupported attribute (see the object treats the attribute as an unknown or unsupported attribute
last row in the table below). (see the last row in the table below).
If some Job Template attributes are supported for some document formats If some Job Template attributes are supported for some document
and not for others or the values are different for different document formats and not for others or the values are different for different
formats, the IPP object SHOULD take that into account in this validation document formats, the IPP object SHOULD take that into account in
using the value of the "document-format" supplied by the client (or this validation using the value of the "document-format" supplied by
defaulted to the value of the Printer's "document-format-default" the client (or defaulted to the value of the Printer's "document-
attribute, if not supplied by the client). For example, if "number-up" format-default" attribute, if not supplied by the client). For
is supported for the 'text/plain' document format, but not for the example, if "number-up" is supported for the 'text/plain' document
'application/postscript' document format, the check SHOULD (though it format, but not for the 'application/postscript' document format, the
NEED NOT) depend on the value of the "document-format" operation check SHOULD (though it NEED NOT) depend on the value of the
attribute. See "document-format" in [IPP-MOD] section 3.2.1.1 and "document-format" operation attribute. See "document-format" in
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 the Note: whether the request is accepted or rejected is determined by
value of the "ipp-attribute-fidelity" attribute in a subsequent step, so the value of the "ipp-attribute-fidelity" attribute in a subsequent
that all Job Template attribute supplied are examined and all step, so that all Job Template attribute supplied are examined and
unsupported attributes and/or values are copied to the Unsupported all unsupported attributes and/or values are copied to the
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 IF NOT supplied by the client, use the value of the Printer
object's "job-priority-default" attribute at job submission object's "job-priority-default" attribute at job submission
time. time.
IF NOT in the range 1 to 100, inclusive, copy the attribute and the IF NOT in the range 1 to 100, inclusive, copy the attribute and the
unsupported value to the Unsupported Attributes response unsupported value to the Unsupported Attributes response
group. group.
Map the value to the nearest supported value in the range 1:100 as Map the value to the nearest supported value in the range 1:100 as
specified by the number of discrete values indicated by the specified by the number of discrete values indicated by the
value of the Printer's "job-priority-supported" attribute. value of the Printer's "job-priority-supported" attribute.
See the formula in [IPP-MOD] Section 4.2.1. See the formula in [RFC2911] Section 4.2.1.
Expires November 30, 2000
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 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 supplied by the client, use the value of the Printer IF NOT supplied by the client, use the value of the Printer
object's "job-hold-until" attribute at job submission time. object's "job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported" IF NOT in the Printer object's "job-hold-until-supported"
skipping to change at page 40, line 4 skipping to change at page 40, line 17
attribute attribute
copy the attribute and the unsupported value to the Unsupported copy the attribute and the unsupported value to the Unsupported
Attributes response group. 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, IF NOT in the Printer object's "finishings-supported" attribute,
copy the attribute and the unsupported value(s), but not any copy the attribute and the unsupported value(s), but not any
Expires November 30, 2000
supported values, to the Unsupported Attributes response supported values, to the Unsupported Attributes response
group. 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 IF first value is greater than second value in any range, the
ranges are not in ascending order, or ranges overlap, ranges are not in ascending order, or ranges overlap,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
skipping to change at page 41, line 4 skipping to change at page 41, line 15
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 IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'. 'client-error-request-value-too-long'.
Expires November 30, 2000
IF NOT in the Printer object's "media-supported" attribute, copy IF NOT in the Printer object's "media-supported" attribute, copy
the attribute and the unsupported value to the Unsupported the attribute and the unsupported value to the Unsupported
Attributes response group. 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 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "printer-resolution-supported" IF NOT in the Printer object's "printer-resolution-supported"
attribute, copy the attribute and the unsupported value to the attribute, copy the attribute and the unsupported value to the
skipping to change at page 41, line 40 skipping to change at page 41, line 49
length is not legal for that attribute syntax, length is not legal for that attribute syntax,
REJECT/RETURN 'client-error-bad-request' if the length of the REJECT/RETURN 'client-error-bad-request' if the length of the
attribute syntax is fixed or 'client-error-request-value-too- attribute syntax is fixed or 'client-error-request-value-too-
long' if the length of the attribute syntax is variable. long' if the length of the attribute syntax is variable.
ELSE copy the attribute and value to the Unsupported Attributes ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of- response group and change the attribute value to the "out-of-
band" 'unsupported' value. Any remaining Job Template band" 'unsupported' value. Any remaining Job Template
Attributes are either unknown or unsupported Job Template Attributes are either unknown or unsupported Job Template
attributes and are validated algorithmically according to attributes and are validated algorithmically according to
their attribute syntax for proper length (see below). their attribute syntax for proper length (see below).
----------------------------------------------- -----------------------------------------------
If the attribute syntax is supported AND the length check fails, the
If the attribute syntax is supported AND the length check fails, the IPP IPP object REJECTS the request and RETURNS the 'client-error-bad-
object REJECTS the request and RETURNS the 'client-error-bad-request' if request' if the length of the attribute syntax is fixed or the
the length of the attribute syntax is fixed or the 'client-error- 'client-error-request-value-too-long' status code if the length of
request-value-too-long' status code if the length of the attribute the attribute syntax is variable. Otherwise, the IPP object copies
syntax is variable. Otherwise, the IPP object copies the unsupported Job the unsupported Job Template attribute to the Unsupported Attributes
Template attribute to the Unsupported Attributes response group and response group and changes the attribute value to the "out-of-band"
changes the attribute value to the "out-of-band" 'unsupported' value. 'unsupported' value. The following table shows the length checks for
The following table shows the length checks for all attribute syntaxes. all attribute syntaxes. In the following table: "<=" means less
In the following table: "<=" means less than or equal, "=" means equal than or equal, "=" means equal to:
to:
Name Octet length check for read-write attributes Name Octet length check for read-write attributes
Expires November 30, 2000
----------- -------------------------------------------- ----------- --------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
'textWithoutLanguage' <= 1023 'textWithoutLanguage' <= 1023
'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
'nameWithoutLanguage' <= 255 'nameWithoutLanguage' <= 255
'keyword' <= 255 'keyword' <= 255
'enum' = 4 'enum' = 4
'uri' <= 1023 'uri' <= 1023
'uriScheme' <= 63 'uriScheme' <= 63
'charset' <= 63 'charset' <= 63
'naturalLanguage' <= 63 'naturalLanguage' <= 63
'mimeMediaType' <= 255 'mimeMediaType' <= 255
'octetString' <= 1023 'octetString' <= 1023
'boolean' = 1 'boolean' = 1
'integer' = 4 'integer' = 4
'rangeOfInteger' = 8 'rangeOfInteger' = 8
'dateTime' = 11 'dateTime' = 11
'resolution' = 9 'resolution' = 9
'1setOf X' '1setOf X'
Note: It's possible for a Printer to receive a zero length keyword in a Note: It's possible for a Printer to receive a zero length keyword
request. Since this is a keyword, its value needs to be compared with in a request. Since this is a keyword, its value needs to be
the supported values. Assuming that the printer doesn't have any values compared with the supported values. Assuming that the printer
in its corresponding "xxx-supported" attribute that are keywords of zero doesn't have any values in its corresponding "xxx-supported"
length, the comparison will fail. Then the request will be accepted or attribute that are keywords of zero length, the comparison will fail.
rejected depending on the value of "ipp-attributes-fidelity" being Then the request will be accepted or rejected depending on the value
'false' or 'true', respectively. No special handling is required for of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
No special handling is required for
3.1.2.3.1 Check for conflicting Job Template attributes values 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 values individually, the Printer object SHOULD check for any conflicting
among all the supported values supplied by the client. For example, a values among all the supported values supplied by the client. For
Printer object might be able to staple and to print on transparencies, example, a Printer object might be able to staple and to print on
however due to physical stapling constraints, the Printer object might transparencies, however due to physical stapling constraints, the
not be able to staple transparencies. The IPP object copies the Printer object might not be able to staple transparencies. The IPP
supported attributes and their conflicting attribute values to the object copies the supported attributes and their conflicting
Unsupported Attributes response group. The Printer object only copies attribute values to the Unsupported Attributes response group. The
over those attributes that the Printer object either ignores or Printer object only copies over those attributes that the Printer
substitutes in order to resolve the conflict, and it returns the object either ignores or substitutes in order to resolve the
original values which were supplied by the client. For example suppose conflict, and it returns the original values which were supplied by
the client supplies "finishings" equals 'staple' and "media" equals the client. For example suppose the client supplies "finishings"
'transparency', but the Printer object does not support stapling equals 'staple' and "media" equals 'transparency', but the Printer
transparencies. If the Printer chooses to ignore the stapling request object does not support stapling transparencies. If the Printer
in order to resolve the conflict, the Printer objects returns chooses to ignore the stapling request in order to resolve the
"finishings" equal to 'staple' in the Unsupported Attributes response conflict, the Printer objects returns "finishings" equal to 'staple'
in the Unsupported Attributes response group. If any attributes are
Expires November 30, 2000 multi-valued, only the conflicting values of the attributes are
copied.
group. If any attributes are multi-valued, only the conflicting values
of the attributes are copied.
Note: The decisions made to resolve the conflict (if there is a choice) Note: The decisions made to resolve the conflict (if there is a
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' value, supplied the "ipp-attribute-fidelity" attribute with the 'true'
the Printer object REJECTS the request and return the status code: value, the Printer object REJECTS the request and return the status
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, 2. 'client-error-attributes-or-values-not-supported' status code,
otherwise. otherwise.
Note: Unsupported Operation attributes or values that are returned do Note: Unsupported Operation attributes or values that are returned
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 the Operation attribute was a serious error, the above already rejected
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 to submission time. The client has to rely on notifications or polling
find out what happens at Job processing time. However, there are cases to find out what happens at Job processing time. However, there are
in which some Printers can determine at Job submission time that Job cases in which some Printers can determine at Job submission time
processing is going to fail. As an optimization, we'd like to have the that Job processing is going to fail. As an optimization, we'd like
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 at There are three types of "processing" errors that might be detectable
Job submission time: at Job submission time:
1. 'client-error-document-format-not-supported' : For the Print-Job, 1. 'client-error-document-format-not-supported' : For the Print-
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-not- then the Printer should respond with 'client-error-document-format-
supported' status. not-supported' status.
Expires November 30, 2000
2. 'client-error-compression-error': For the Print-Job, Send-Document, 2. 'client-error-compression-error': For the Print-Job, Send-
Print-URI, and Send-URI operations, if all these conditions are true: Document, Print-URI, and Send-URI operations, if all these
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 Send- 3. 'client-error-document-access-error': For the Print-URI, and
URI operations, if the Printer attempts and fails to pull the referenced Send-URI operations, if the Printer attempts and fails to pull the
document data before responding, it should respond with 'client-error- referenced document data before responding, it should respond with
document-access-error' status. 'client-error-document-access-error' status.
Some Printers are not able to detect these errors until Job processing Some Printers are not able to detect these errors until Job
time. In that case, the errors are recorded in the corresponding job- processing time. In that case, the errors are recorded in the
state and job-state reason attributes. (There is no standard way for a corresponding job-state and job-state reason attributes. (There is
client to determine whether a Printer can detect these errors at Job no standard way for a client to determine whether a Printer can
submission time.) For example, if auto-sensing happens AFTER the job is detect these errors at Job submission time.) For example, if auto-
accepted (as opposed to auto-sensing at submit time before returning the sensing happens AFTER the job is accepted (as opposed to auto-sensing
response), the implementation aborts the job, puts the job in the at submit time before returning the response), the implementation
'aborted' state and sets the 'unsupported-document-format' value in the aborts the job, puts the job in the 'aborted' state and sets the
job's "job-state-reasons". 'unsupported-document-format' value in the job's "job-state-reasons".
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 format. client itself may sniff the document data to determine document
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 client Printer when combined with compression. For auto-sensed Jobs, a
may be better off deferring compression to the transfer protocol layer, client may be better off deferring compression to the transfer
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
are only unsupported Job Template attributes or values.
Expires November 30, 2000 Note: Unsupported Operation attributes or values that are returned
3. the "successful-ok-ignored-or-substituted-attributes, if there are do not affect the status returned in this step. If the unsupported
only unsupported Job Template attributes or values. Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with
Note: Unsupported Operation attributes or values that are returned do
not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected the
request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious 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 by If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
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 "job-
uri" and "job-id" attributes, and initializes all of the job's uri" and "job-id" attributes, and initializes all of the job's
other supported Job Description attributes. 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 value
or substitutes the unsupported attribute value with some supported or substitutes the unsupported attribute value with some
value. If an attribute has no values after removing unsupported supported value. If an attribute has no values after removing
values from it, the attribute is removed from the Job object (so unsupported values from it, the attribute is removed from the
that the normal default behavior at job processing time will take Job object (so that the normal default behavior at job
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 value
or substitutes the conflicting attribute value with some other or substitutes the conflicting attribute value with some other
supported value. If an attribute has no values after removing supported value. If an attribute has no values after removing
conflicting values from it, the attribute is removed from the Job conflicting values from it, the attribute is removed from the
object (so that the normal default behavior at job processing time Job object (so that the normal default behavior at job
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 the able to accept the create request and create a new Job object. If
"ipp-attribute-fidelity" attribute is set to 'true', the Job Template the "ipp-attribute-fidelity" attribute is set to 'true', the Job
attributes that populate the new Job object are necessarily all the Job Template attributes that populate the new Job object are necessarily
Template attributes supplied in the create request. If the "ipp- all the Job Template attributes supplied in the create request. If
attribute-fidelity" attribute is set to 'false', the Job Template the "ipp-attribute-fidelity" attribute is set to 'false', the Job
attributes that populate the new Job object are all the client supplied Template attributes that populate the new Job object are all the
Job Template attributes that are supported or that have value client supplied Job Template attributes that are supported or that
substitution. Thus, some of the requested Job Template attributes may have value substitution. Thus, some of the requested Job Template
not appear in the Job object because the Printer object did not support attributes will not appear in the Job object because the Printer
those attributes. The attributes that populate the Job object are object did not support those attributes. The attributes that
persistently stored with the Job object for that Job. A Get-Job- populate the Job object are persistently stored with the Job object
for that Job. A Get-Job-Attributes operation on that Job object will
Expires November 30, 2000 return only those attributes that are persistently stored with the
Job object.
Attributes operation on that Job object will return only those
attributes that are persistently stored with the Job object.
Note: All Job Template attributes that are persistently stored with the Note: All Job Template attributes that are persistently stored with
Job object are intended to be "override values"; that is, they that take the Job object are intended to be "override values"; that is, they
precedence over whatever other embedded instructions might be in the that take precedence over whatever other embedded instructions might
document data itself. However, it is not possible for all Printer be in the document data itself. However, it is not possible for all
objects to realize the semantics of "override". End users may query the Printer objects to realize the semantics of "override". End users
Printer's "pdl-override-supported" attribute to determine if the Printer may query the Printer's "pdl-override-supported" attribute to
either attempts or does not attempt to override document data determine if the Printer either attempts or does not attempt to
instructions with IPP attributes. override document data instructions with IPP attributes.
There are some cases, where a Printer supports a Job Template attribute There are some cases, where a Printer supports a Job Template
and has an associated default value set for that attribute. In the case attribute and has an associated default value set for that attribute.
where a client does not supply the corresponding attribute, the Printer In the case where a client does not supply the corresponding
does not use its default values to populate Job attributes when creating attribute, the Printer does not use its default values to populate
the new Job object; only Job Template attributes actually in the create Job attributes when creating the new Job object; only Job Template
request are used to populate the Job object. The Printer's default attributes actually in the create request are used to populate the
values are only used later at Job processing time if no other IPP Job object. The Printer's default values are only used later at Job
attribute or instruction embedded in the document data is present. processing time if no other IPP attribute or instruction embedded in
the document data is present.
Note: If the default values associated with Job Template attributes that Note: If the default values associated with Job Template attributes
the client did not supply were to be used to populate the Job object, that the client did not supply were to be used to populate the Job
then these values would become "override values" rather than defaults. object, then these values would become "override values" rather than
If the Printer supports the 'attempted' value of the "pdl-override- defaults. If the Printer supports the 'attempted' value of the "pdl-
supported" attribute, then these override values could replace values override-supported" attribute, then these override values could
specified within the document data. This is not the intent of the replace values specified within the document data. This is not the
default value mechanism. A default value for an attribute is used only intent of the default value mechanism. A default value for an
if the create request did not specify that attribute (or it was ignored attribute is used only if the create request did not specify that
when allowed by "ipp-attribute-fidelity" being 'false') and no value was attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
provided within the content of the document data. being 'false') and no value was provided within the content of the
document data.
If the client does not supply a value for some Job Template attribute, If the client does not supply a value for some Job Template
and the Printer does not support that attribute, as far as IPP is attribute, and the Printer does not support that attribute, as far as
concerned, the result of processing that Job (with respect to the IPP is concerned, the result of processing that Job (with respect to
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 there
are any conflicting Job Template attribute or values. are any conflicting Job Template attribute or values.
3. the 'successful-ok-ignored-or-substituted-attributes' status
code, if there are only unsupported Job Template attributes or
values.
Expires November 30, 2000 Note: Unsupported Operation attributes or values that are returned
3. the 'successful-ok-ignored-or-substituted-attributes' status code, do not affect the status returned in this step. If the unsupported
if there are only unsupported Job Template attributes or values. Operation attribute was a serious error, the above already rejected
the request in a previous step. If control gets to this step with
Note: Unsupported Operation attributes or values that are returned do
not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected the
request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious unsupported Operation attributes being returned, they are not serious
errors. errors.
The Printer object also returns Job status attributes that indicate the The Printer object also returns Job status attributes that indicate
initial state of the Job ('pending', 'pending-held', 'processing', the initial state of the Job ('pending', 'pending-held',
etc.), etc. See Print-Job Response, [IPP-MOD] section 3.2.1.2. 'processing', etc.), etc. See Print-Job Response, [RFC2911] section
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 either The Printer object accepts the appended Document Content data and
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 Printer order. Once the Printer object begins processing the Job, the
changes the Job's state to 'processing'. If the Printer object supports Printer changes the Job's state to 'processing'. If the Printer
PDL override (the "pdl-override-supported" attribute set to object supports PDL override (the "pdl-override-supported" attribute
'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 received, Job into the 'completed' state. If an Cancel-Job operation is
the implementation eventually moves the Job into the 'canceled' state. received, the implementation eventually moves the Job into the
If the system encounters errors during processing that do not allow it 'canceled' state. If the system encounters errors during processing
to progress the Job into a completed state, the implementation halts all that do not allow it to progress the Job into a completed state, the
processing, cleans up any resources, and moves the Job into the implementation halts all processing, cleans up any resources, and
'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' state, Once the Job moves to the 'completed', 'aborted', or 'canceled'
it is an implementation decision as to when to destroy the Job object state, it is an implementation decision as to when to destroy the Job
object and release all associated resources. Once the Job has been
Expires November 30, 2000 destroyed, the Printer would return either the "client-error-not-
found" or "client-error-gone" status codes for operations directed at
and release all associated resources. Once the Job has been destroyed, that Job.
the Printer would return either the "client-error-not-found" or "client-
error-gone" status codes for operations directed at that Job.
Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" 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-fidelity" Some Printer object implementations may support "ipp-attribute-
set to 'true' and "pdl-override-supported" set to 'attempted' and yet fidelity" set to 'true' and "pdl-override-supported" set to
still not be able to realize exactly what the client specifies in the 'attempted' and yet still not be able to realize exactly what the
create request. This is due to legacy decisions and assumptions that client specifies in the create request. This is due to legacy
have been made about the role of job instructions embedded within the decisions and assumptions that have been made about the role of job
document data and external job instructions that accompany the document instructions embedded within the document data and external job
data and how to handle conflicts between such instructions. The instructions that accompany the document data and how to handle
inability to be 100% precise about how a given implementation will conflicts between such instructions. The inability to be 100%
behave is also compounded by the fact that the two special attributes, precise about how a given implementation will behave is also
"ipp-attribute-fidelity" and "pdl-"override-supported", apply to the compounded by the fact that the two special attributes, "ipp-
whole job rather than specific values for each attribute. For example, attribute-fidelity" and "pdl-"override-supported", apply to the whole
some implementations may be able to override almost all Job Template job rather than specific values for each attribute. For example, some
implementations may be able to override almost all Job Template
attributes except for "number-up". Character Sets, natural languages, attributes except for "number-up". Character Sets, natural languages,
and internationalization and internationalization
This section discusses character set support, natural language support This section discusses character set support, natural language
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 also support additional charsets. It is RECOMMENDED that an IPP object
support US-ASCII, since many clients support US-ASCII, and indicate that also support US-ASCII, since many clients support US-ASCII, and
UTF-8 and US-ASCII are supported by populating the Printer's "charset- indicate that UTF-8 and US-ASCII are supported by populating the
supported" with 'utf-8' and 'us-ascii' values. An IPP object is Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An
required to code covert with as little loss as possible between the IPP object is required to code covert with as little loss as possible
charsets that it supports, as indicated in the Printer's "charsets- between the charsets that it supports, as indicated in the Printer's
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?
Expires November 30, 2000 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-
Example: Consider a case where a client sends a Print-Job request with name" attribute supplied. Later another client submits a Get-Job-
"utf-8" as the value of "attributes-charset" and with the "job-name" Attribute or Get-Jobs request. This second request contains the
attribute supplied. Later another client submits a Get-Job-Attribute or "attributes-charset" with value "us-ascii" and "requested-attributes"
Get-Jobs request. This second request contains the "attributes-charset" attribute with exactly one value "job-name".
with value "us-ascii" and "requested-attributes" attribute with exactly
one value "job-name".
According to the IPP-Mod 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 "us- "attributes-charset" for the response of the second request must be
ascii" since that is the charset specified in the request. The "job- "us-ascii" since that is the charset specified in the request. The
name" value, however, is in "utf-8" format. Should the request be "job-name" value, however, is in "utf-8" format. Should the request
rejected even though both "utf-8" and "us-ascii" charsets are supported be rejected even though both "utf-8" and "us-ascii" charsets are
by the server? or should the "job-name" value be converted to "us-ascii" supported by the server? or should the "job-name" value be converted
and return "successful-ok-conflicting-attributes" (0x0002) as the to "us-ascii" and return "successful-ok-conflicting-attributes"
status code? (0x0002) as the status code?
Answer: An IPP object that supports both utf-8 (REQUIRED) and us-ascii, Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
the second paragraph of section 3.1.4.2 applies so that the IPP object ascii, the second paragraph of section 3.1.4.2 applies so that the
MUST accept the request, perform code set conversion between these two IPP object MUST accept the request, perform code set conversion
charsets with "the highest fidelity possible" and return 'successful- between these two charsets with "the highest fidelity possible" and
ok', rather than a warning 'successful-ok-conflicting-attributes, or an return 'successful-ok', rather than a warning 'successful-ok-
error. The printer will do the best it can to convert between each of conflicting-attributes, or an error. The printer will do the best it
the character sets that it supports--even if that means providing a can to convert between each of the character sets that it supports--
string of question marks because none of the characters are even if that means providing a string of question marks because none
representable in US ASCII. If it can't perform such conversion, it MUST of the characters are representable in US ASCII. If it can't perform
NOT advertise us-ascii as a value of its "attributes-charset-supported" such conversion, it MUST NOT advertise us-ascii as a value of its
and MUST reject any request that requests 'us-ascii'. "attributes-charset-supported" and MUST reject any request that
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, rather 'us-ascii' and throw away characters that it doesn't understand,
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 November Section 3.1.4.1 Request Operation attributes was clarified in
1998 as follows: November 1998 as follows:
All clients and IPP objects MUST support the 'utf-8' charset [RFC2044]
and MAY support additional charsets provided that they are registered
with IANA [IANA-CS]. If the Printer object does not support the client
supplied charset value, the Printer object MUST reject the request, set
Expires November 30, 2000
the "attributes-charset" to 'utf-8' in the response, and return the All clients and IPP objects MUST support the 'utf-8' charset
'client-error-charset-not-supported' status code and any 'text' or [RFC2044] and MAY support additional charsets provided that they are
'name' attributes using the 'utf-8' charset. registered with IANA [IANA-CS]. If the Printer object does not
support the client supplied charset value, the Printer object MUST
reject the request, set the "attributes-charset" to 'utf-8' in the
response, and return the 'client-error-charset-not-supported' status
code and any 'text' or 'name' attributes using the 'utf-8' charset.
Since the client and IPP object MUST support UTF-8, returning any text Since the client and IPP object MUST support UTF-8, returning any
or name attributes in UTF-8 when the client requests a charset that is text or name attributes in UTF-8 when the client requests a charset
not supported should allow the client to display the text or name. that is not supported should allow the client to display the text or
name.
Since such an error is a client error, rather than a user error, the Since such an error is a client error, rather than a user error, the
client should check the status code first so that it can avoid client should check the status code first so that it can avoid
displaying any other returned 'text' and 'name' attributes that are not displaying any other returned 'text' and 'name' attributes that are
in the charset requested. not in the charset requested.
Furthermore, [ipp-mod] 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 attribute, supplied by the client in the "attributes-charset" operation
the Printer MUST reject the operation and return this status and any attribute, the Printer MUST reject the operation and return this
'text' or 'name' attributes using the 'utf-8' charset (see Section status and any 'text' or 'name' attributes using the 'utf-8' charset
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 two language. The 'textWithoutLanguage' and 'textWithLanguage' are the
'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are the two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage
two 'name' forms. If a receiver (IPP object or IPP client) supports an are the two 'name' forms. If a receiver (IPP object or IPP client)
attribute with attribute syntax 'text', it MUST support both forms in a supports an attribute with attribute syntax 'text', it MUST support
request and a response. A sender (IPP client or IPP object) MAY send both forms in a request and a response. A sender (IPP client or IPP
either form for any such attribute. When a sender sends a object) MAY send either form for any such attribute. When a sender
WithoutLanguage form, the implicit natural language is specified in the sends a WithoutLanguage form, the implicit natural language is
"attributes-natural-language" operation attribute, which all senders specified in the "attributes-natural-language" operation attribute,
MUST include in every request and response. which all senders MUST include in every request and response.
When a sender sends a WithLanguage form, it MAY be different from the When a sender sends a WithLanguage form, it MAY be different from the
implicit natural language supplied by the sender or it MAY be the same. implicit natural language supplied by the sender or it MAY be the
The receiver MUST treat either form equivalently. same. The receiver MUST treat either form equivalently.
There is an implementation decision for senders, whether to always send There is an implementation decision for senders, whether to always
the WithLanguage forms or use the WithoutLanguage form when the send the WithLanguage forms or use the WithoutLanguage form when the
attribute's natural language is the same as the request or response. attribute's natural language is the same as the request or response.
The former approach makes the sender implementation simpler. The latter The former approach makes the sender implementation simpler. The
approach is more efficient on the wire and allows inter-working with latter approach is more efficient on the wire and allows inter-
non-conforming receivers that fail to support the WithLanguage forms. working with non-conforming receivers that fail to support the
WithLanguage forms. As each approach have advantages, the choice is
Expires November 30, 2000 completely up to the implementer of the sender.
As each approach have advantages, the choice is completely up to the
implementer of the sender.
Furthermore, when a client receives a 'text' or 'name' job attribute Furthermore, when a client receives a 'text' or 'name' job attribute
that it had previously supplied, that client MUST NOT expect to see the that it had previously supplied, that client MUST NOT expect to see
attribute in the same form, i.e., in the same WithoutLanguage or the attribute in the same form, i.e., in the same WithoutLanguage or
WithLanguage form as the client supplied when it created the job. The WithLanguage form as the client supplied when it created the job.
IPP object is free to transform the attribute from the WithLanguage form The IPP object is free to transform the attribute from the
to the WithoutLanguage form and vice versa, as long as the natural WithLanguage form to the WithoutLanguage form and vice versa, as long
language is preserved. However, in order to meet this latter as the natural language is preserved. However, in order to meet this
requirement, it is usually simpler for the IPP object implementation to latter requirement, it is usually simpler for the IPP object
store the natural language explicitly with the attribute value, i.e., to implementation to store the natural language explicitly with the
store using an internal representation that resembles the WithLanguage attribute value, i.e., to store using an internal representation that
form. resembles the WithLanguage form.
The IPP Printer MUST copy the natural language of a job, i.e., the value The IPP Printer MUST copy the natural language of a job, i.e., the
of the "attributes-natural-language" operation attribute supplied by the value of the "attributes-natural-language" operation attribute
client in the create operation, to the Job object as a Job Description supplied by the client in the create operation, to the Job object as
attribute, so that a client is able to query it. In returning a Get- a Job Description attribute, so that a client is able to query it.
Job-Attributes response, the IPP object MAY return one of three natural In returning a Get-Job-Attributes response, the IPP object MAY return
language values in the response's "attributes-natural-language" one of three natural language values in the response's "attributes-
operation attribute: (1) that requested by the requester, (2) the natural-language" operation attribute: (1) that requested by the
natural language of the job, or (3) the configured natural language of requester, (2) the natural language of the job, or (3) the configured
the IPP Printer, if the requested language is not supported by the IPP natural language of the IPP Printer, if the requested language is not
Printer. supported by the IPP Printer.
This "attributes-natural-language" Job Description attribute is useful This "attributes-natural-language" Job Description attribute is
for an IPP object implementation that prints start sheets in the useful for an IPP object implementation that prints start sheets in
language of the user who submitted the job. This same Job Description the language of the user who submitted the job. This same Job
attribute is useful to a multi-lingual operator who has to communicate Description attribute is useful to a multi-lingual operator who has
with different job submitters in different natural languages. This same to communicate with different job submitters in different natural
Job Description attribute is expected to be used in the future to languages. This same Job Description attribute is expected to be
generate notification messages in the natural language of the job used in the future to generate notification messages in the natural
submitter. language of the job submitter.
Early drafts of [IPP-MOD] contained a job-level natural language Early drafts of [RFC2911] contained a job-level natural language
override (NLO) for the Get-Jobs response. A job-level (NLO) is an override (NLO) for the Get-Jobs response. A job-level (NLO) is an
(unrequested) Job Attribute which then specified the implicit natural (unrequested) Job Attribute which then specified the implicit natural
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 in implementations showed that no one was implementing the job-level NLO
Get-Job responses. So the job-level NLO was eliminated from the Get- in Get-Job responses. So the job-level NLO was eliminated from the
Jobs response. This simplification makes all requests and responses Get-Jobs response. This simplification makes all requests and
consistent in that the implicit natural language for any WithoutLanguage responses consistent in that the implicit natural language for any
'text' or 'name' form is always supplied in the request's or response's WithoutLanguage 'text' or 'name' form is always supplied in the
"attributes-natural-language" operation attribute. request's or response's "attributes-natural-language" operation
attribute.
Expires November 30, 2000
3.1.3 Status codes returned by operation 3.1.3 Status codes returned by operation
This section corresponds to [IPP-MOD] section 3.1.6 "Operation Response This section corresponds to [RFC2911] section 3.1.6 "Operation
Status Codes and Status Messages". This section lists all status codes Response Status Codes and Status Messages". This section lists all
once in the first operation (Print-Job). Then it lists the status codes status codes once in the first operation (Print-Job). Then it lists
that are different or specialized for subsequent operations under each the status codes that are different or specialized for subsequent
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" values The Printer object MUST return one of the following "status-code"
for the indicated reason. Whether all of the document data has been values for the indicated reason. Whether all of the document data
accepted or not before returning the success or error response depends has been accepted or not before returning the success or error
on implementation. See Section 13 in [IPP-MOD] for a more complete response depends on implementation. See Section 13 in [RFC2911] for
description of each status code. a more complete description of each status code.
For the following success status codes, the Job object has been created For the following success status codes, the Job object has been
and the "job-id", and "job-uri" assigned and returned in the response: created and the "job-id", and "job-uri" assigned and returned in the
response:
successful-ok: no request attributes were substituted or ignored. successful-ok: no request attributes were substituted or ignored.
successful-ok-ignored-or-substituted-attributes: some supplied (1) successful-ok-ignored-or-substituted-attributes: some supplied (1)
attributes were ignored or (2) unsupported attribute syntaxes or attributes were ignored or (2) unsupported attribute syntaxes or
values were substituted with supported values or were ignored. values were substituted with supported values or were ignored.
Unsupported attributes, attribute syntax's, or values MUST be Unsupported attributes, attribute syntax's, or values MUST be
returned in the Unsupported Attributes group of the response. returned in the Unsupported Attributes group of the response.
successful-ok-conflicting-attributes: some supplied attribute values successful-ok-conflicting-attributes: some supplied attribute
conflicted with the values of other supplied attributes and were values conflicted with the values of other supplied attributes
either substituted or ignored. Attributes or values which conflict and were either substituted or ignored. Attributes or values
with other attributes and have been substituted or ignored MUST be which conflict with other attributes and have been substituted
returned in the Unsupported Attributes group of the response as or ignored MUST be returned in the Unsupported Attributes group
supplied by the client. of the response as supplied by the client.
[ipp-mod] section 3.1.6 Operation Status Codes and Messages states:
If the Printer object supports the "status-message" operation attribute, [RFC2911] section 3.1.6 Operation Status Codes and Messages states:
it SHOULD use the REQUIRED 'utf-8' charset to return a status message
for the following error status codes (see section 13 in [IPP-MOD]):
'client-error-bad-request', 'client-error-charset-not-supported',
'server-error-internal-error', 'server-error-operation-not-supported',
and 'server-error-version-not-supported'. In this case, it MUST set the
value of the "attributes-charset" operation attribute to 'utf-8' in the
error response.
Expires November 30, 2000 If the Printer object supports the "status-message" operation
attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
status message for the following error status codes (see section 13
in [RFC2911]): 'client-error-bad-request', 'client-error-charset-
not-supported', 'server-error-internal-error', 'server-error-
operation-not-supported', and 'server-error-version-not-supported'.
In this case, it MUST set the value of the "attributes-charset"
operation attribute to 'utf-8' in the error response.
For the following error status codes, no job is created and no "job-id" For the following error status codes, no job is created and no
or "job-uri" is returned: "job-id" or "job-uri" is returned:
client-error-bad-request: The request syntax does not conform to the client-error-bad-request: The request syntax does not conform
specification. to the specification.
client-error-forbidden: The request is being refused for client-error-forbidden: The request is being refused for
authorization or authentication reasons. The implementation authorization or authentication reasons. The implementation
security policy is to not reveal whether the failure is one of security policy is to not reveal whether the failure is one of
authentication or authorization. authentication or authorization.
client-error-not-authenticated: Either the request requires client-error-not-authenticated: Either the request requires
authentication information to be supplied or the authentication authentication information to be supplied or the
information is not sufficient for authorization. authentication information is not sufficient for
authorization.
client-error-not-authorized: The requester is not authorized to client-error-not-authorized: The requester is not authorized to
perform the request on the target object. perform the request on the target object.
client-error-not-possible: The request cannot be carried out because client-error-not-possible: The request cannot be carried out
of the state of the system. See also 'server-error-not-accepting- because of the state of the system. See also 'server-error-
jobs' status code, which MUST take precedence if the Printer not-accepting-jobs' status code, which MUST take precedence if
object's "printer-accepting-jobs" attribute is 'false'. the Printer object's "printer-accepting-jobs" attribute is
'false'.
client-error-timeout: not applicable. client-error-timeout: not applicable.
client-error-not-found: the target object does not exist. client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no client-error-gone: the target object no longer exists and no
forwarding address is known. forwarding address is known.
client-error-request-entity-too-large: the size of the request client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to and/or print data exceeds the capacity of the IPP Printer to
process it. process it.
client-error-request-value-too-long: the size of request variable client-error-request-value-too-long: the size of request
length attribute values, such as 'text' and 'name' attribute variable length attribute values, such as 'text' and 'name'
syntax's, exceed the maximum length specified in [IPP-MOD] for the attribute syntax's, exceed the maximum length specified in
attribute and MUST be returned in the Unsupported Attributes Group. [RFC2911] for the attribute and MUST be returned in the
Unsupported Attributes Group.
client-error-document-format-not-supported: the document format client-error-document-format-not-supported: the document format
supplied is not supported. The "document-format" attribute with supplied is not supported. The "document-format" attribute
the unsupported value MUST be returned in the Unsupported with the unsupported value MUST be returned in the Unsupported
Attributes Group. This error SHOULD take precedence over any other Attributes Group. This error SHOULD take precedence over any
'xxx-not-supported' error, except 'client-error-charset-not- other 'xxx-not-supported' error, except 'client-error-charset-
supported'. not-supported'.
client-error-attributes-or-values-not-supported: one or more client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntax's, or values are not supplied attributes, attribute syntax's, or values are not
supported and the client supplied the "ipp-attributes-fidelity" supported and the client supplied the "ipp-attributes-
operation attribute with a 'true' value. They MUST be returned in fidelity" operation attribute with a 'true' value. They MUST
the Unsupported Attributes Group as explained below. be returned in the Unsupported Attributes Group as explained
below.
client-error-uri-scheme-not-supported: not applicable. 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,
Expires November 30, 2000 client-error-charset-not-supported: the charset supplied in the
unless the request syntax is so bad that the client's supplied "attributes-charset" operation attribute is not supported.
"attributes-charset" cannot be determined. The Printer's "configured-charset" MUST be returned in the
client-error-conflicting-attributes: one or more supplied attribute response as the value of the "attributes-charset" operation
values conflicted with each other and the client supplied the "ipp- attribute and used for any 'text' and 'name' attributes
attributes-fidelity" operation attribute with a 'true' value. They returned in the error response. This error SHOULD take
MUST be returned in the Unsupported Attributes Group as explained precedence over any other error, unless the request syntax is
below. so bad that the client's supplied "attributes-charset" cannot
server-error-internal-error: an unexpected condition prevents the be determined.
request from being fulfilled. client-error-conflicting-attributes: one or more supplied
server-error-operation-not-supported: not applicable (since Print- attribute values conflicted with each other and the client
Job is REQUIRED). 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 server-error-service-unavailable: the service is temporarily
overloaded. overloaded.
server-error-version-not-supported: the version in the request is server-error-version-not-supported: the version in the request
not supported. The "closest" version number supported MUST be is not supported. The "closest" version number supported MUST
returned in the response. be returned in the response.
server-error-device-error: a device error occurred while receiving server-error-device-error: a device error occurred while
or spooling the request or document data or the IPP Printer object receiving or spooling the request or document data or the IPP
can only accept one job at a time. Printer object can only accept one job at a time.
server-error-temporary-error: a temporary error such as a buffer server-error-temporary-error: a temporary error such as a
full write error, a memory overflow, or a disk full condition buffer full write error, a memory overflow, or a disk full
occurred while receiving the request and/or the document data. condition occurred while receiving the request and/or the
server-error-not-accepting-jobs: the Printer object's "printer-is- document data.
not-accepting-jobs" attribute is 'false'. server-error-not-accepting-jobs: the Printer object's "printer-
server-error-busy: the Printer is too busy processing jobs to accept is-not-accepting-jobs" attribute is 'false'.
another job at this time. server-error-busy: the Printer is too busy processing jobs to
server-error-job-canceled: the job has been canceled by an operator accept another job at this time.
or the system while the client was transmitting the document data. 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 3.1.3.1.2 Print-URI
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
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 in
the "document-uri" operation attribute is not supported and is the "document-uri" operation attribute is not supported and is
returned in the Unsupported Attributes group. returned in the Unsupported Attributes group.
server-error-operation-not-supported: the Print-URI operation is not server-error-operation-not-supported: the Print-URI operation is
supported. not supported.
3.1.3.1.3 Validate-Job 3.1.3.1.3 Validate-Job
Expires November 30, 2000 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
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- [RFC2911] for a more complete description of each status code.
Job Response are applicable to Validate-Job. See Section 13 in [IPP-
MOD] 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 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
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 [IPP-MOD] for a more specializations and differences. See Section 13 in [RFC2911] for a
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 is
not supported. not supported.
client-error-multiple-document-jobs-not-supported: while the Create- client-error-multiple-document-jobs-not-supported: while the
Job and Send-Document operations are supported, this implementation Create-Job and Send-Document operations are supported, this
doesn't support more than one document with data. implementation doesn't support more than one document with data.
3.1.3.1.5 Get-Printer-Attributes 3.1.3.1.5 Get-Printer-Attributes
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
Job Response are applicable to the Get-Printer-Attributes operation with Print-Job Response are applicable to the Get-Printer-Attributes
the following specialization's and differences. See Section 13 in operation with the following specialization's and differences. See
[IPP-MOD] for a more complete description of each status code. Section 13 in [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: no request attributes were substituted or ignored successful-ok: no operation attributes or values were substituted
(same as Print-Job) and no requested attributes were unsupported. or ignored (same as Print-Job) and no requested attributes were
successful-ok-ignored-or-substituted-attributes: same as Print-Job, unsupported.
except the "requested-attributes" operation attribute MAY, but NEED successful-ok-ignored-or-substituted-attributes: The "requested-
NOT, be returned with the unsupported values. attributes" operation attribute MAY, but NEED NOT, be returned
with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job. successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, Group 3 is returned containing no attributes For the error status codes, Group 3 is returned containing no
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 client-error-request-entity-too-large: same as Print-job, except
that no print data is involved. that no print data is involved.
client-error-attributes-or-values-not-supported: not applicable, client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes MUST be ignored and since unsupported operation attributes and/or values MUST be
'successful-ok-ignored-or-substituted-attributes' returned. ignored and an appropriate success code returned (see above).
client-error-conflicting-attributes: same as Print-Job, except that client-error-conflicting-attributes: same as Print-Job, except
"ipp-attribute-fidelity" is not involved. that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get- server-error-operation-not-supported: not applicable (since Get-
Printer-Attributes is REQUIRED). Printer-Attributes is REQUIRED).
Expires November 30, 2000
server-error-device-error: same as Print-Job, except that no server-error-device-error: same as Print-Job, except that no
document data is involved. document data is involved.
server-error-temporary-error: same as Print-Job, except that no server-error-temporary-error: same as Print-Job, except that no
document data is involved. document data is involved.
server-error-not-accepting-jobs: not applicable.. server-error-not-accepting-jobs: not applicable.
server-error-busy: same as Print-Job, except the IPP object is too server-error-busy: same as Print-Job, except the IPP object is too
busy to accept even query requests. busy to accept even query requests.
server-error-job-canceled: not applicable.. server-error-job-canceled: not applicable.
3.1.3.1.6 Get-Jobs 3.1.3.1.6 Get-Jobs
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
Job Response are applicable to the Get-Jobs operation with the following Print-Job Response are applicable to the Get-Jobs operation with the
specialization's and differences. See Section 13 in [IPP-MOD] for a following specialization's and differences. See Section 13 in
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: no request attributes were substituted or ignored successful-ok: same as Get-Printer-Attributes (see section
(same as Print-Job) and no requested attributes were unsupported. 3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Print-Job, successful-ok-ignored-or-substituted-attributes: same as Get-
except the "requested-attributes" operation attribute MAY, but NEED Printer-Attributes (see section 3.1.3.1.5).
NOT, be returned with the unsupported values. successful-ok-conflicting-attributes: same as Get-Printer-
successful-ok-conflicting-attributes: same as Print-Job. Attributes (see section 3.1.3.1.5).
For any error status codes, Group 3 is returned containing no attributes For any error status codes, Group 3 is returned containing no
or is not returned at all. The following brief error status code attributes or is not returned at all. The following brief error
descriptions contain unique information for use with Get-Jobs operation. status code descriptions contain unique information for use with Get-
See section 14 for the other error status codes that apply uniformly to Jobs operation. See section 14 for the other error status codes that
all operations: 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 client-error-request-entity-too-large: same as Print-job,
that no print data is involved. except that no print data is involved.
client-error-document-format-not-supported: not applicable. client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable, client-error-attributes-or-values-not-supported: not
since unsupported operation attributes MUST be ignored and applicable, since unsupported operation attributes and/or
'successful-ok-ignored-or-substituted-attributes' returned. values MUST be ignored and an appropriate success code
client-error-conflicting-attributes: same as Print-Job, except that returned (see above).
"ipp-attribute-fidelity" is not involved. client-error-conflicting-attributes: same as Print-Job, except
server-error-operation-not-supported: not applicable (since Get-Jobs that "ipp-attribute-fidelity" is not involved.
is REQUIRED).
server-error-operation-not-supported: not applicable (since
Get-Jobs is REQUIRED).
server-error-device-error: same as Print-Job, except that no server-error-device-error: same as Print-Job, except that no
document data is involved. document data is involved.
server-error-temporary-error: same as Print-Job, except that no server-error-temporary-error: same as Print-Job, except that no
document data is involved. document data is involved.
server-error-not-accepting-jobs: not applicable. server-error-not-accepting-jobs: not applicable.
Expires November 30, 2000
server-error-job-canceled: not applicable. server-error-job-canceled: not applicable.
3.1.3.1.7 Pause-Printer 3.1.3.1.7 Pause-Printer
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
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 [IPP-MOD] for a more specializations and differences. See Section 13 in [RFC2911] for a
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 ignored successful-ok: no request attributes were substituted or
(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
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job. successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object has not been 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-not-found: the target Printer object does not
client-error-gone: the target Printer object no longer exists and no exist.
forwarding address is known. client-error-gone: the target Printer object no longer exists
client-error-request-entity-too-large: same as Print-Job, except no and no forwarding address is known.
document data is involved. 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-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except that client-error-conflicting-attributes: same as Print-Job, except
the Printer's "printer-is-accepting-jobs" attribute is not that the Printer's "printer-is-accepting-jobs" attribute is
involved. not involved.
server-error-operation-not-supported: the Pause-Printer operation is server-error-operation-not-supported: the Pause-Printer
not supported. operation is not supported.
server-error-device-error: not applicable. server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no document server-error-temporary-error: same as Print-Job, except no
data is involved. document data is involved.
server-error-not-accepting-jobs: not applicable. server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable. server-error-job-canceled: not applicable.
3.1.3.1.8 Resume-Printer 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-Printer Print-Job Response with the specialization's described for Pause-
are applicable to Resume-Printer. See Section 13 in [IPP-MOD] for a Printer are applicable to Resume-Printer. See Section 13 in
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.
Expires November 30, 2000 successful-ok: no request attributes were substituted or
successful-ok: no request attributes were substituted or ignored ignored (same as Print-Job).
(same as Print-Job). successful-ok-ignored-or-substituted-attributes: same as
successful-ok-ignored-or-substituted-attributes: same as Print-Job. Print-Job.
successful-ok-conflicting-attributes: same as Print-Job. successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object does not resume 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 operation is server-error-operation-not-supported: the Resume-Printer
not supported. operation is not supported.
3.1.3.1.8.1 What about Printers unable to change state due to an error 3.1.3.1.8.1 What about Printers unable to change state due to an error
condition? condition?
If, in case, the IPP printer is unable to change its state due to
some problem with the actual printer device (say, it is shut down or
there is a media-jam as indicated in [RFC2911]), what should be the
result of the "Resume-Printer" operation? Should it still change the
'printer-state-reasons' and return success or should it fail ?
If, in case, the IPP printer is unable to change its state due to some The Resume-Printer operation must clear the 'paused' or 'moving-to-
problem with the actual printer device (say, it is shut down or there is
a media-jam as indicated in [ipp-mod]), what should be the result of the
"Resume-printer" operation? Should it still change the 'printer-state-
reasons' and return success or should it fail ?
The 'resume-printer' operation must clear the 'paused' or 'moving-to-
paused' 'printer-state-message'. The operation must return a 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 "Resume-Printer" succeeds, what should be the value of 'Printer- If the Resume-Printer operation succeeds, what should be the value of
state' and who should take care of the 'Printer-state' later on ? "printer-state" and who should take care of the "printer-state"
attribute value later on ?
The "Resume-Printer" operation may change the "printer-state-reasons" 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 2. 'processing' - job available and no error conditions present
3. current state (i.e. no change) an error condition is present (e.g. 3. current state (i.e. no change) an error condition is present
media jam) (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)
Expires November 30, 2000
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-Printer Print-Job Response with the specialization's described for Pause-
are applicable to Purge-Printer. See Section 13 in [IPP-MOD] for a more Printer are applicable to Purge-Printer. See Section 13 in [RFC2911]
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 ignored successful-ok: no request attributes were substituted or
(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
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job. successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Printer object does not purge any For any of the error status codes, the Printer object does not purge
jobs. any jobs.
server-error-operation-not-supported: the Purge-Printer operation is server-error-operation-not-supported: the Purge-Printer
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 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
Job Response are applicable to the Get-Printer-Attributes operation with Print-Job Response are applicable to the Get-Printer-Attributes
the following specialization's and differences. See Section 13 in operation with the following specialization's and differences. See
[IPP-MOD] for a more complete description of each status code. Section 13 in [RFC2911] for a more complete description of each
status code.
For the following success status codes, the document has been added to For the following success status codes, the document has been added
the specified Job object and the job's "number-of-documents" attribute to the specified Job object and the job's "number-of-documents"
has been incremented: attribute has been incremented:
successful-ok: no request attributes were substituted or ignored successful-ok: no request attributes were substituted or
(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 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 object For the error status codes, no document has been added to the Job
and the job's "number-of-documents" attribute has not been incremented: object and the job's "number-of-documents" attribute has not been
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 involved, so Printer's "printer-is-accepting-jobs" attribute is not
that the client is able to finish submitting a job that was created involved, so that the client is able to finish submitting a
with a Create-Job operation after this attribute has been set to job that was created with a Create-Job operation after this
'true'. Another condition is that the state of the job precludes attribute has been set to 'true'. Another condition is that
Send-Document, i.e., the job has already been closed out by the the state of the job precludes Send-Document, i.e., the job
client. However, if the IPP Printer closed out the job due to has already been closed out by the client. However, if the
IPP Printer closed out the job due to timeout, the 'client-
Expires November 30, 2000 error-timeout' error status SHOULD be returned instead.
timeout, the 'client-error-timeout' error status SHOULD be client-error-timeout: This request was sent after the Printer
returned instead. closed the job, because it has not received a Send-Document or
client-error-timeout: This request was sent after the Printer closed Send-URI operation within the Printer's "multiple-operation-
the job, because it has not received a Send-Document or Send-URI time-out" period .
operation within the Printer's "multiple-operation-time-out" period
.
client-error-request-entity-too-large: same as Print-Job. client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except that client-error-conflicting-attributes: same as Print-Job, except
"ipp-attributes-fidelity" operation attribute is not involved.. that "ipp-attributes-fidelity" operation attribute is not
server-error-operation-not-supported: the Send-Document request is involved..
not supported. server-error-operation-not-supported: the Send-Document request
is not supported.
server-error-not-accepting-jobs: not applicable. server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an operator server-error-job-canceled: the job has been canceled by an
or the system while the client was transmitting the data. operator or the system while the client was transmitting the
data.
3.1.3.2.2 Send-URI 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-Document Print-Job Response with the specialization's described for Send-
are applicable to Send-URI. See Section 13 in [IPP-MOD] for a more Document are applicable to Send-URI. See Section 13 in [RFC2911] for
complete description of each status code. a more complete 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 the in the "document-uri" operation attribute is not supported and
"document-uri" attribute MUST be returned in the Unsupported the "document-uri" attribute MUST be returned in the
Attributes group. Unsupported Attributes group.
server-error-operation-not-supported: the Send-URI operation is not server-error-operation-not-supported: the Send-URI operation is
supported. not supported.
3.1.3.2.3 Cancel-Job 3.1.3.2.3 Cancel-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
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 [IPP-MOD] for a more specializations and differences. See Section 13 in [RFC2911] for a
complete description of each status code. more complete description of each status code.
For the following success status codes, the Job object is being canceled For the following success status codes, the Job object is being
or has been canceled: canceled or has been canceled:
successful-ok: no request attributes were substituted or ignored successful-ok: no request attributes were substituted or
(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
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job. successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been canceled For any of the error status codes, the Job object has not been
or was previously canceled. canceled or was previously canceled.
Expires November 30, 2000 client-error-not-possible: The request cannot be carried out
client-error-not-possible: The request cannot be carried out because because of the state of the Job object ('completed',
of the state of the Job object ('completed', 'canceled', or 'canceled', or 'aborted') or the state of the system.
'aborted') or the state of the system. client-error-not-found: the target Printer and/or Job object
client-error-not-found: the target Printer and/or Job object does does not exist.
not exist. client-error-gone: the target Printer and/or Job object no
client-error-gone: the target Printer and/or Job object no longer longer exists and no forwarding address is known.
exists and no forwarding address is known. client-error-request-entity-too-large: same as Print-Job,
client-error-request-entity-too-large: same as Print-Job, except no except no document data is involved.
document data is involved.
client-error-document-format-not-supported: not applicable. client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable, client-error-attributes-or-values-not-supported: not
since unsupported operation attributes and values MUST be ignored. applicable, since unsupported operation attributes and values
client-error-conflicting-attributes: same as Print-Job, except that MUST be ignored.
the Printer's "printer-is-accepting-jobs" attribute is not client-error-conflicting-attributes: same as Print-Job, except
involved. that the Printer's "printer-is-accepting-jobs" attribute is
server-error-operation-not-supported: not applicable (Cancel-Job is not involved.
REQUIRED). server-error-operation-not-supported: not applicable (Cancel-
server-error-device-error: same as Print-Job, except no document Job is REQUIRED).
data is involved. server-error-device-error: same as Print-Job, except no
server-error-temporary-error: same as Print-Job, except no document document data is involved.
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-not-accepting-jobs: not applicable..
server-error-job-canceled: not applicable. server-error-job-canceled: not applicable.
3.1.3.2.4 Get-Job-Attributes 3.1.3.2.4 Get-Job-Attributes
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
Job Response are applicable to Get-Job-Attributes with the following Print-Job Response are applicable to Get-Job-Attributes with the
specializations and differences. See Section 13 in [IPP-MOD] for a more following specializations and differences. See Section 13 in
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: no request attributes were substituted or ignored successful-ok: same as Get-Printer-Attributes (see section
(same as Print-Job) and no requested attributes were unsupported. 3.1.3.1.5).
successful-ok-ignored-or-substituted-attributes: same as Print-Job, successful-ok-ignored-or-substituted-attributes: same as Get-
except the "requested-attributes" operation attribute MAY, but NEED Printer-Attributes (see section 3.1.3.1.5).
NOT, be returned with the unsupported values. successful-ok-conflicting-attributes: same as Get-Printer-
successful-ok-conflicting-attributes: same as Print-Job. Attributes (see section 3.1.3.1.5).
For the error status codes, Group 3 is returned containing no attributes For the error status codes, Group 3 is returned containing no
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-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable. client-error-attributes-or-values-not-supported: not
applicable.
client-error-uri-scheme-not-supported: not applicable. client-error-uri-scheme-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not
Expires November 30, 2000 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 client-error-conflicting-attributes: not applicable
server-error-operation-not-supported: not applicable (since Get-Job- server-error-operation-not-supported: not applicable (since
Attributes is REQUIRED). Get-Job-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no document server-error-device-error: same as Print-Job, except no
data is involved. document data is involved.
server-error-temporary-error: sane as Print-Job, except no document server-error-temporary-error: sane as Print-Job, except no
data is involved.. document data is involved..
server-error-not-accepting-jobs: not applicable. server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable. server-error-job-canceled: not applicable.
3.1.3.2.5 Hold-Job 3.1.3.2.5 Hold-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 Print- All of the Print-Job status codes described in Section 3.1.3.1.1
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 [IPP-MOD] for a more specializations and differences. See Section 13 in [RFC2911] for a
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 or For the following success status codes, the Job object is being held
has been held: or has been held:
successful-ok: no request attributes were substituted or ignored successful-ok: no request attributes were substituted or
(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
Print-Job.
successful-ok-conflicting-attributes: same as Print-Job. successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been held or For any of the error status codes, the Job object has not been held
was previously held. or was previously held.
client-error-not-possible: The request cannot be carried out because client-error-not-possible: The request cannot be carried out
of the state of the Job object ('completed', 'canceled', or because of the state of the Job object ('completed',
'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 client-error-not-found: the target Printer and/or Job object
not exist. does not exist.
client-error-gone: the target Printer and/or Job object no longer client-error-gone: the target Printer and/or Job object no
exists and no forwarding address is known. longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job, except no client-error-request-entity-too-large: same as Print-Job,
document data is involved. except no document data is involved.
client-error-document-format-not-supported: not applicable. client-error-document-format-not-supported: not applicable.
client-error-conflicting-attributes: same as Print-Job, except that client-error-conflicting-attributes: same as Print-Job, except
the Printer's "printer-is-accepting-jobs" attribute is not that the Printer's "printer-is-accepting-jobs" attribute is
involved. not involved.
server-error-operation-not-supported: the Hold-Job operation is not server-error-operation-not-supported: the Hold-Job operation is
supported. not supported.
server-error-device-error: not applicable. server-error-device-error: not applicable.
server-error-temporary-error: same as Print-Job, except no document server-error-temporary-error: same as Print-Job, except no
data is involved. document data is involved.
server-error-not-accepting-jobs: not applicable. server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable. server-error-job-canceled: not applicable.
Expires November 30, 2000
3.1.3.2.6 Release-Job 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 are Print-Job Response with the specialization's described for Hold-Job
applicable to Release-Job. See Section 13 in [IPP-MOD] for a more are applicable to Release-Job. See Section 13 in [RFC2911] for a
complete description of each status code. more complete description of each status code.
server-error-operation-not-supported: the Release-Job operation is server-error-operation-not-supported: the Release-Job operation
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 are Print-Job Response with the specialization's described for Hold-Job
applicable to Restart-Job. See Section 13 in [IPP-MOD] for a more are applicable to Restart-Job. See Section 13 in [RFC2911] for a
complete description of each status code. more complete description of each status code.
server-error-operation-not-supported: the Restart-Job operation is server-error-operation-not-supported: the Restart-Job operation
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
. I issue a Restart-Job request on the job. Now the issue is that, if
I try to add new documents to the restarted job, will the IPP Server
permit me to do so or return "client-error-not-possible " and again
print those 5 jobs?
Assume I give a Create-Job request along with a set of 5 documents . All A job can not move to the 'completed' state until all the documents
the documents get printed and the job state is moved to completed . I have been processed. The 'last-document' flag indicates when the
issue a Restart-Job request on the job. Now the issue is that, if I try last document for a job is being sent from the client. This is the
to add new documents to the restarted job, will the IPP Server permit semantic equivalent of closing a job. No documents may be added once
me to do so or return "client-error-not-possible " and again print a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
those 5 jobs? is moved to the 'pending' job state and restarts the beginning on the
same IPP Printer object with the same attribute values." 'number-of-
A job can not move to the 'completed' state until all the documents have documents' is a job attribute.
been processed. The 'last-document' flag indicates when the last
document for a job is being sent from the client. This is the semantic
equivalent of closing a job. No documents may be added once a job is
closed. Section 3.3.7 of the IPP/1.1 model states "The job is moved to
the 'pending' job state and restarts the beginning on the same IPP
Printer object with the same attribute values." 'number-of-documents' is
a job attribute.
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 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 requested, returned in the Unsupported Attributes group that the client
requested, but are not supported by the IPP object. However, such
Expires November 30, 2000 unsupported requested attributes will not be returned in the Job
Attributes or Printer Attributes group (since they are unsupported).
but are not supported by the IPP object. However, such unsupported Furthermore, the IPP object is REQUIRED to return the 'successful-ok-
requested attributes will not be returned in the Job Attributes or ignored-or-substituted-attributes' status code, so that the client
Printer Attributes group (since they are unsupported). Furthermore, the knows that not all that was requested has been returned.
IPP object is REQUIRED to return the 'successful-ok-ignored-or-
substituted-attributes' status code, so that the client knows that not
all that was requested has been returned.
3.1.5 Sending empty attribute groups 3.1.5 Sending empty attribute groups
The [IPP-MOD] and [IPP-PRO] specifications RECOMMEND that a sender not The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender
send an empty attribute group in a request or a response. However, they not send an empty attribute group in a request or a response.
REQUIRE a receiver to accept an empty attribute group as equivalent to However, they REQUIRE a receiver to accept an empty attribute group
the omission of that group. So a client SHOULD omit the Job Template as equivalent to the omission of that group. So a client SHOULD omit
Attributes group entirely in a create operation that is not supplying the Job Template Attributes group entirely in a create operation that
any Job Template attributes. Similarly, an IPP object SHOULD omit an is not supplying any Job Template attributes. Similarly, an IPP
empty Unsupported Attributes group if there are no unsupported object SHOULD omit an empty Unsupported Attributes group if there are
attributes to be returned in a response. no unsupported attributes to be returned in a response.
The [IPP-PRO] specification REQUIRES a receiver to be able to receive The [RFC2910] specification REQUIRES a receiver to be able to receive
either an empty attribute group or an omitted attribute group and treat either an empty attribute group or an omitted attribute group and
them equivalently. The term "receiver" means an IPP object for a treat them equivalently. The term "receiver" means an IPP object for
request and a client for a response. The term "sender' means a client a request and a client for a response. The term "sender' means a
for a request and an IPP object for a response. client for a request and an IPP object for a response.
There is an exception to the rule for Get-Jobs when there are no There is an exception to the rule for Get-Jobs when there are no
attributes to be returned. [IPP-PRO] contains the following paragraph: attributes to be returned. [RFC2910] contains the following
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 way attribute-sequence that follows is empty. The syntax is defined this
to allow for the response of Get-Jobs where no attributes are returned way to allow for the response of Get-Jobs where no attributes are
for some job-objects. Although it is RECOMMENDED that the sender not returned for some job-objects. Although it is RECOMMENDED that the
send an xxx-attributes-tag if there are no attributes (except in the sender not send an xxx-attributes-tag if there are no attributes
Get-Jobs response just mentioned), the receiver MUST be able to decode (except in the Get-Jobs response just mentioned), the receiver MUST
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 1.22) (Issue 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
not return a response until the condition is changed.
Expires November 30, 2000 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
able to send all the document data. Consequently, the Printer will not and/or the condition will be freed either by human intervention or as
return a response until the condition is changed. jobs print.
The Printer should not return a Print-Job response with an error code in
any of these conditions, since either the printer will be resumed and/or
the condition will be freed either by human intervention or as jobs
print.
In writing test scripts to test IPP Printers, the script must also be In writing test scripts to test IPP Printers, the script must also be
written not to expect a response, if the printer has been paused, until written not to expect a response, if the printer has been paused,
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 the only if the IPP object returns one of the success status codes. Then
job-state would always be "pending" or "pending-held". the job-state would always be "pending" or "pending-held".
This issue comes up for the implementation of an IPP Printer object as a This issue comes up for the implementation of an IPP Printer object
server that forwards jobs to devices that do not provide job status back as a server that forwards jobs to devices that do not provide job
to the server. If the server is reasonably certain that the job status back to the server. If the server is reasonably certain that
completed successfully, then it should return the job-state as the job completed successfully, then it should return the job-state
'completed'. Also the server can keep the job in its "job history" long as 'completed'. Also the server can keep the job in its "job
after the job is no longer in the device. Then a user could query the history" long after the job is no longer in the device. Then a user
server and see that the job was in the 'completed' state and completed could query the server and see that the job was in the 'completed'
as specified by the jobs "time-at-completed" time, which would be the state and completed as specified by the jobs "time-at-completed"
same as the server submitted the job to the device. time, which would be the same as the server submitted the job to the
device.
An alternative is for the server to respond to the client before or An alternative is for the server to respond to the client before or
while sending the job to the device, instead of waiting until the server while sending the job to the device, instead of waiting until the
has finished sending the job to the device. In this case, the server server has finished sending the job to the device. In this case, the
can return the job's state as 'pending' with the 'job-outgoing' value in server can return the job's state as 'pending' with the 'job-
the job's "job-state-reasons" attribute. outgoing' value in the job's "job-state-reasons" attribute.
If the server doesn't know for sure whether the job completed If the server doesn't know for sure whether the job completed
successfully (or at all), it could return the (out-of-band) 'unknown' successfully (or at all), it could return the (out-of-band) 'unknown'
value. value.
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 the setup some sort of event notification that the device initiates when
job makes state transitions, then the server can return the current job the job makes state transitions, then the server can return the
current job state in the Print-Job response and in subsequent queries
Expires November 30, 2000 because the server knows what the job state is in the device (or can
query the device).
state in the Print-Job response and in subsequent queries because the
server knows what the job state is in the device (or can query the
device).
All of these alternatives depend on implementation of the server and the All of these alternatives depend on implementation of the server and
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 returns If a Printer supports the "printer-make-and-model" attribute and
the .INF file model name of the printer in that attribute, the Microsoft returns the .INF file model name of the printer in that attribute,
client will automatically install the correct driver (if available). the Microsoft client will automatically install the correct driver
(if available).
Clients which poll periodically for printer status or queued-job-count Clients which poll periodically for printer status or queued-job-
should use the "requested-attributes" operation attribute to limit the count should use the "requested-attributes" operation attribute to
scope of the query in order to save Printer and network resources. limit the scope of the query in order to save Printer and network
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 [IPP-MOD] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my- 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
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?
[IPP-MOD] Section 8.3 describes the various cases of "requesting-user- [RFC2911] Section 8.3 describes the various cases of "requesting-
name" being present or not for any operation. If the client does not user-name" being present or not for any operation. If the client
supply a value for "requesting-user-name", the printer MUST assume that does not supply a value for "requesting-user-name", the printer MUST
the client is supplying some anonymous name, such as "anonymous". assume that the client is supplying some anonymous name, such as
"anonymous".
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
When using the Get-Jobs operation a client implementer might choose to When using the Get-Jobs operation a client implementer might choose
limit the number of jobs that the client shows on the first screenful. to limit the number of jobs that the client shows on the first
For example, if its UI can only display 50 jobs, it can defend itself screenful. For example, if its UI can only display 50 jobs, it can
against a printer that would otherwise return 500 jobs, perhaps taking a defend itself against a printer that would otherwise return 500 jobs,
long time on a slow dial-up line. The client can then go and ask for a perhaps taking a long time on a slow dial-up line. The client can
larger number of jobs in the background, while showing the user the then go and ask for a larger number of jobs in the background, while
first 50 jobs. Since the job history is returned in reverse order, showing the user the first 50 jobs. Since the job history is returned
namely the most recently completed jobs are returned first, the user is in reverse order, namely the most recently completed jobs are
most likely interested in the first jobs that are returned. Limiting the returned first, the user is most likely interested in the first jobs
number of jobs may be especially useful for a client that is requesting that are returned. Limiting the number of jobs may be especially
'completed' jobs from a printer that keeps a long job history. Clients useful for a client that is requesting 'completed' jobs from a
printer that keeps a long job history. Clients that don't mind
Expires November 30, 2000 sometimes getting very large responses, can omit the "limit"
attribute in their Get-Jobs requests.
that don't mind sometimes getting very large responses, can omit the
"limit" attribute in their Get-Jobs requests.
3.2.4 Create-Job operation 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 it Printer, but the Printer is expecting additional document data before
can move the job into the 'processing' state. Alternatively, it may it can move the job into the 'processing' state. Alternatively, it
respond with "job-state" 'processing' and "job-state-reason" 'job- may respond with "job-state" 'processing' and "job-state-reason"
incoming' to indicate that the Create-Job operation has been accepted 'job-incoming' to indicate that the Create-Job operation has been
by the Printer, but the Printer is expecting additional Send-Document accepted by the Printer, but the Printer is expecting additional
and/or Send-URI operations and/or is accessing/accepting document data. Send-Document and/or Send-URI operations and/or is
The second alternative is for non-spooling Printers that don't implement accessing/accepting document data. The second alternative is for
the 'pending' state. non-spooling Printers that don't implement the 'pending' state.
Should the server wait for the "last-document" operation attribute set
to 'true' before starting to "process" the job?
Should the server wait for the "last-document" operation attribute
set to 'true' before starting to "process" the job?
It depends on implementation. Some servers spool the entire job, It depends on implementation. Some servers spool the entire job,
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 in then the server takes one of the indicated actions in section 3.3.1
the [IPP-MOD] document. Other servers will start to process document in the [RFC2911] document. Other servers will start to process
data as soon as they have some. These are the so-called "non-spooling" document data as soon as they have some. These are the so-called
printers. Currently, there isn't a way for a client to determine whether "non-spooling" printers. Currently, there isn't a way for a client to
the Printer will spool all the data or will start to process (and print) determine whether the Printer will spool all the data or will start
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 implementation The Validate-Job operation has been designed so that its
may be a part of the Print-Job operation. Therefore, requiring implementation may be a part of the Print-Job operation. Therefore,
Validate-Job is not a burden on implementers. Also it is useful for requiring Validate-Job is not a burden on implementers. Also it is
client's to be able to count on its presence in all conformance useful for client's to be able to count on its presence in all
implementations, so that the client can determine before sending a long conformance implementations, so that the client can determine before
document, whether the job will be accepted by the IPP Printer or not. sending a long document, whether the job will be accepted by the IPP
Printer or not.
3.3.2 Restart-Job 3.3.2 Restart-Job
Expires November 30, 2000
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 printer the Print-Job operation are an example. It is required that the
retains the job data after the job has moved to a 'completed state' in printer retains the job data after the job has moved to a 'completed
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 using Some jobs contain only a reference to the job data. A job created
the Print-URI is an example of such a job. When the Restart-Job using the Print-URI is an example of such a job. When the Restart-
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 SHALL data. When such a job is the target of a Restart-Job the Printer
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)
[IPP-MOD] states that the 'none' value should be used as the value of a [RFC2911] states that the 'none' value should be used as the value of
1setOf when the set is empty. In most cases, sets that are potentially a 1setOf when the set is empty. In most cases, sets that are
empty contain keywords so the keyword 'none' is used, but for the 3 potentially empty contain keywords so the keyword 'none' is used, but
finishings attributes, the values are enums and thus the empty set is for the 3 finishings attributes, the values are enums and thus the
represented by the enum 3. Currently there are no other attributes with empty set is represented by the enum 3. Currently there are no other
1setOf values, which can be empty and can contain values that are not attributes with 1setOf values, which can be empty and can contain
keywords. This exception requires special code and is a potential place values that are not keywords. This exception requires special code
for bugs. It would have been better if we had chosen an out-of-band and is a potential place for bugs. It would have been better if we
value, either "no-value" or some new value, such as 'none'. Since we had chosen an out-of-band value, either "no-value" or some new value,
didn't, implementations have to deal with the different representations such as 'none'. Since we didn't, implementations have to deal with
of 'none', depending on the attribute syntax. the different representations of 'none', depending on the attribute
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 some What is the attribute syntax for a multi-valued attribute? Since
attributes support values in more than one data type, such as "media", some attributes support values in more than one data type, such as
"job-hold-until", and "job-sheets", IPP semantics associate the "media", "job-hold-until", and "job-sheets", IPP semantics associate
attribute syntax with each value, not with the attribute as a whole. the attribute syntax with each value, not with the attribute as a
The protocol associates the attribute syntax tag with each value. Don't whole. The protocol associates the attribute syntax tag with each
be fooled, just because the attribute syntax tag comes before the value. Don't be fooled, just because the attribute syntax tag comes
attribute keyword. All attribute values after the first have a zero before the attribute keyword. All attribute values after the first
length attribute keyword as the indication of a subsequent value of the have a zero length attribute keyword as the indication of a
same attribute. subsequent value of the same attribute.
Expires November 30, 2000
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 URL Host names as case insensitive but reminds us that the rest of the
may well demonstrate case sensitivity. When creating URL's for fields URL may well demonstrate case sensitivity. When creating URL's for
where the choice is completely arbitrary, it is probably best to select fields where the choice is completely arbitrary, it is probably best
lower case. However, this cannot be guaranteed and implementations MUST to select lower case. However, this cannot be guaranteed and
NOT rely on any fields being case-sensitive or case-insensitive in the implementations MUST NOT rely on any fields being case-sensitive or
URL beyond the URL scheme and host name fields. case-insensitive in the URL beyond the URL scheme and host name
fields.
The reason that the IPP specification does not make any restrictions on The reason that the IPP specification does not make any restrictions
URIs, is so that implementations of IPP may use off-the-shelf components on URIs, is so that implementations of IPP may use off-the-shelf
that conform to the standards that define URIs, such as RFC 2396 and the components that conform to the standards that define URIs, such as
HTTP/1.1 specifications [RFC2616]. See these specifications for rules RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these
of matching, comparison, and case-sensitivity. specifications for rules of matching, comparison, and case-
sensitivity.
It is also recommended that System Administrators and implementations It is also recommended that System Administrators and implementations
avoid creating URLs for different printers that differ only in their avoid creating URLs for different printers that differ only in their
case. For example, don't have Printer1 and printer1 as two different case. For example, don't have Printer1 and printer1 as two different
IPP Printers. IPP Printers.
Example of equivalent URI's Example of equivalent URI's
http://abc.com:80/~smith/home.html http://abc.com:80/~smith/home.html
skipping to change at page 69, line 45 skipping to change at page 71, line 33
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 comparing The HTTP/1.1 specification [RFC2616] contains more details on
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 that The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
have two components. The first component is the 'language' component that have two components. The first component is the 'language'
that can contain up to 63 octets. The second component is the 'text' or component that can contain up to 63 octets. The second component is
'name' component. The maximum length of these are 1023 octets and 255 the 'text' or 'name' component. The maximum length of these are 1023
octets and 255 octets respectively. The definition of attributes
Expires November 30, 2000 with either syntax may further restrict the length. (e.g. printer-
name (name(127)))
octets respectively. The definition of attributes with either syntax
may further restrict the length. (e.g. printer-name (name(127)))
The length of the 'language' component has no effect on the allowable 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 would IPP/1.0 is silent on which of the four effects an implementation
perform if it supports Create-Job, but does not support "multiple- would perform if it supports Create-Job, but does not support
document-handling" or multiple documents per job. IPP/1.1 was changed "multiple-document-handling" or multiple documents per job. IPP/1.1
so that a Printer could support Create-Job without having to support was changed so that a Printer could support Create-Job without having
multiple document jobs. The "multiple-document-jobs-supported" to support multiple document jobs. The "multiple-document-jobs-
(boolean) Printer description attribute was added to IPP/1.1 along with supported" (boolean) Printer description attribute was added to
the 'server-error-multiple-document-jobs-not-supported' status code for IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
a Printer to indicate whether or not it supports multiple document jobs, supported' status code for a Printer to indicate whether or not it
when it supports the Create-Job operation. Also IPP/1.1 was clarified supports multiple document jobs, when it supports the Create-Job
that the Printer MUST support the "multiple-document-handling" (type2 operation. Also IPP/1.1 was clarified that the Printer MUST support
keyword) Job Template attribute with at least one value if the Printer the "multiple-document-handling" (type2 keyword) Job Template
supports multiple documents per job. attribute with at least one value if the Printer supports multiple
documents per job.
4.3 Job Description Attributes 4.3 Job Description Attributes
The time-at-creation, time-at-processing, and time-at-completed 4.3.1 Getting the date and time of day
attributes may be returned in integer time ticks or absolute dateTime
syntax. There are various ways for a Printer to get the time of day. The "date-time-at-creation", "date-time-at-processing", and "date-
time-at-completed" attributes are returned as dateTime syntax.
These attributes are OPTIONAL for a Printer to support. However,
there are various ways for a Printer to get the date and time of day.
Some suggestions: Some 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 in
RFC 2132 returns the IP address of the NTP server. 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.
Expires November 30, 2000
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 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 clients The reason that "queued-job-count" is RECOMMENDED, is that some
look at that attribute alone when summarizing the status of a list of clients look at that attribute alone when summarizing the status of a
printers, instead of doing a Get-Jobs to determine the number of jobs in list of printers, instead of doing a Get-Jobs to determine the number
the queue. Implementations that fail to support the "queued-job-count" of jobs in the queue. Implementations that fail to support the
will cause that client to display 0 jobs when there are actually queued "queued-job-count" will cause that client to display 0 jobs when
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 raised, implementations had already been completed before the issue was
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 is The "queued-job-count" is not a good measure of how busy the printer
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 startup date and time by any number of implementation-dependent means at
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,
Expires November 30, 2000
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
6. from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132] [RFC2132] that returns the IP address of the NTP server.
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. See attribute using the out-of-band 'no-value' meaning not configured.
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 to Since the new "date-and-time-at-xxx" Job Description attributes refer
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 values Must the operational attribute for printer-uri match one of the
in printer-uri-supported? values in "printer-uri-supported"?
A forgiving printer implementation would not reject the operation. But A forgiving printer implementation would not reject the operation.
the implementation has its rights to reject a printer or job operation But the implementation has its rights to reject a printer or job
if the operational attribute printer-uri is not a value of the printer- operation if the operational attribute printer-uri is not a value of
uri-supported. The printer may not be improperly configured. The request the printer-uri-supported. The printer might not be improperly
obviously reached the printer. The printer could treat the printer-uri configured. The request obviously reached the printer. The printer
as the logical equivalent of a value in the printer-uri-supported. It could treat the printer-uri as the logical equivalent of a value in
would be implementation dependent for which value, and associated the printer-uri-supported. It would be implementation dependent for
security policy, would apply. This does also apply to a job object which value, and associated security policy, would apply. This does
specified with a printer-uri and job-id, or with a job-uri. See section also apply to a job object specified with a printer-uri and job-id,
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 documents. The IPP object model does not prohibit a job that contains no
Such a job may be created in a number of ways including a 'create-job' documents. Such a job may be created in a number of ways including a
followed by an 'add-document' that contains no data and has the 'last- 'create-job' followed by an 'add-document' that contains no data and
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 no "closes" an empty job is not rejected because the job is empty. If
other conditions exist, other than the job is empty, the response to the no other conditions exist, other than the job is empty, the response
operation will indicate success. After the job is scheduled and to the operation will indicate success. After the job is scheduled
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-reasons'
attribute. It is required that if no conditions, other than the job
being empty, exist the 'job-state-reasons' SHALL include the 'completed-
Expires November 30, 2000
successfully'. If other conditions existed, the 'completed-with- There will be some variation in the value(s) of the "job-state-
warnings' or 'completed-with-errors' values may be used." reasons" attribute. It is required that if no conditions, other than
the job being empty, exist the "job-state-reasons" SHALL include the
'completed-successfully'. If other conditions existed, the
'completed-with-warnings' or 'completed-with-errors' values may be
used.
5 Directory Considerations 5 Directory Considerations
5.1 General Directory Schema Considerations 5.1 General Directory Schema Considerations
The [ipp-mod] document lists RECOMMENDED and OPTIONAL Printer object The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
attributes for directory schemas. See [ipp-mod] 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 printer Abstract Service Type v2.0" document [svrloc-printer]. The LDAP
template is defined in the "Internet Printing Protocol (IPP): LDAP printer template is defined in the "Internet Printing Protocol (IPP):
Schema for Printer Services" document [ldap-printer]. Both documents LDAP Schema for Printer Services" document [ldap-printer]. Both
systematically add "printer-" to any attribute that doesn't already documents systematically add "printer-" to any attribute that doesn't
start with "printer-" in order to keep the printer directory attributes already start with "printer-" in order to keep the printer directory
distinct from other directory attributes. Also, instead of using attributes distinct from other directory attributes. Also, instead
"printer-uri-supported", "uri-authentication-supported", and "uri- of using "printer-uri-supported", "uri-authentication-supported", and
security-supported", they use a "printer-xri-supported" attribute with "uri-security-supported", they use a "printer-xri-supported"
special syntax to contain all of the same information in a single attribute with special syntax to contain all of the same information
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 IPP-MOD Section 8 "Security This section corresponds to the RFC2911 Section 8 "Security
Considerations. Considerations.
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 [IPP-MOD] 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 device that an IPP Printer is representing is able to accept
jobs using other job submission protocols in addition to IPP, it is
RECOMMEND that such an implementation at least allow such "foreign"
jobs to be queried using Get-Jobs returning "job-id" and "job-uri"
as 'unknown'. Such an implementation NEED NOT support all of the
same IPP job attributes as for IPP jobs. The IPP object returns
the 'unknown' out-of-band value for any requested attribute of a
foreign job that is supported for IPP jobs, but not for foreign
jobs.
Expires November 30, 2000 It is further RECOMMENDED, that the IPP Printer generate "job-id"
and "job-uri" values for such "foreign jobs", if possible, so that
If the device that an IPP Printer is representing is able to accept jobs they may be targets of other IPP operations, such as Get-Job-
using other job submission protocols in addition to IPP, it is RECOMMEND Attributes and Cancel-Job. Such an implementation also needs to
that such an implementation at least allow such "foreign" jobs to be deal with the problem of authentication of such foreign jobs. One
queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. approach would be to treat all such foreign jobs as belonging to
Such an implementation NEED NOT support all of the same IPP job users other than the user of the IPP client. Another approach
attributes as for IPP jobs. The IPP object returns the 'unknown' out- would be for the foreign job to belong to 'anonymous'. Only if the
of-band value for any requested attribute of a foreign job that is IPP client has been authenticated as an operator or administrator
supported for IPP jobs, but not for foreign jobs. of the IPP Printer object, could the foreign jobs be queried by an
IPP request. Alternatively, if the security policy were to allow
It is further RECOMMENDED, that the IPP Printer generate "job-id" and users to query other users' jobs, then the foreign jobs would also
"job-uri" values for such "foreign jobs", if possible, so that they may be visible to an end-user IPP client using Get-Jobs and Get-Job-
be targets of other IPP operations, such as Get-Job-Attributes and Attributes.
Cancel-Job. Such an implementation also needs to deal with the problem
of authentication of such foreign jobs. One approach would be to treat
all such foreign jobs as belonging to users other than the user of the
IPP client. Another approach would be for the foreign job to belong to
'anonymous'. Only if the IPP client has been authenticated as an
operator or administrator of the IPP Printer object, could the foreign
jobs be queried by an IPP request. Alternatively, if the security
policy were to allow users to query other users' jobs, then the foreign
jobs would also be visible to an end-user IPP client using Get-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 provides
access to jobs submitted with any job submission protocol. As IPP access to jobs submitted with any job submission protocol. As IPP
becomes widely implemented, providing a more universal access makes becomes widely implemented, providing a more universal access makes
sense. sense.
7 Encoding and Transport 7 Encoding and Transport
This section discusses various aspects of IPP/1.1 Encoding and Transport This section discusses various aspects of IPP/1.1 Encoding and
[IPP-PRO]. Transport [RFC2910].
A server is not required to send a response until after it has received
the client's entire request. Hence, a client must not expect a response
until after it has sent the entire request. However, we recommend that
the server return a response as soon as possible if an error is detected
while the client is still sending the data, rather than waiting until
all of the data is received. Therefore, we also recommend that a client
listen for an error 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 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 than closing it). If the request is blocked for some
reason, a client MAY determine the reason by opening another connection
to query the server using Get-Printer-Attributes.
Expires November 30, 2000 A server is not required to send a response until after it has
received the client's entire request. Hence, a client must not
expect a response until after it has sent the entire request.
However, we recommend that the server return a response as soon as
possible if an error is detected while the client is still sending
the data, rather than waiting until all of the data is received.
Therefore, we also recommend that a client listen for an error
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
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
than closing it). If the request is blocked for some reason, a client
MAY determine the reason by opening another connection to query the
server using Get-Printer-Attributes.
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
throttle clients when Printers are busy. Therefore, it is perfectly to throttle clients when Printers are busy. Therefore, it is
normal for an IPP client transmitting a Job to be blocked for a really perfectly normal for an IPP client transmitting a Job to be blocked
long time. Accordingly, socket timeouts must be avoided. Some socket for a really long time. Accordingly, socket timeouts must be
implementations have a timeout option, which specifies how long a write avoided. Some socket implementations have a timeout option, which
operation on a socket can be blocked before it times out and the specifies how long a write operation on a socket can be blocked
blocking ends. A client should set this option for infinite timeout before it times out and the blocking ends. A client should set this
when transmitting Job submissions. option for infinite timeout when transmitting Job submissions.
Some IPP client applications might be able to perform other useful work Some IPP client applications might be able to perform other useful
while a Job transmission is blocked. For example, the client may have work while a Job transmission is blocked. For example, the client
other jobs that it could transmit to other Printers simultaneously. A may have other jobs that it could transmit to other Printers
client may have a GUI, which must remain responsive to the user while simultaneously. A client may have a GUI, which must remain
the Job transmission is blocked. These clients should be designed to responsive to the user while the Job transmission is blocked. These
spawn a thread to handle the Job transmission at its own pace, leaving clients should be designed to spawn a thread to handle the Job
the main application free to do other work. Alternatively, single- transmission at its own pace, leaving the main application free to do
threaded applications could use non-blocking I/O. other work. Alternatively, single-threaded applications could use
non-blocking I/O.
Some Printer conditions, such as jam or lack of paper, could cause a Some Printer conditions, such as jam or lack of paper, could cause a
client to be blocked indefinitely. Clients may open additional client to be blocked indefinitely. Clients may open additional
connections to the Printer to Get-Printer-Attributes, determine the connections to the Printer to Get-Printer-Attributes, determine the
state of the device, alert a user if the printer is stopped, and let a state of the device, alert a user if the printer is stopped, and let
user decide whether to abort the job transmission or not. a user decide whether to abort the job transmission or not.
In the following sections, there are tables of all HTTP headers, which In the following sections, there are tables of all HTTP headers,
describe their use in an IPP client or server. The following is an which describe their use in an IPP client or server. The following
explanation of each column in these tables. is an explanation of each column in these tables.
- the "header" column contains the name of a header - the "header" column contains the name of a header
- the "request/client" column indicates whether a client sends the - the "request/client" column indicates whether a client sends the
header. header.
- the "request/ server" column indicates whether a server supports - the "request/ server" column indicates whether a server supports
the header when received. the header when received.
- the "response/ server" column indicates whether a server sends - the "response/ server" column indicates whether a server sends
the header. the header.
- the "response /client" column indicates whether a client - the "response /client" column indicates whether a client
supports the header when received. supports the header when received.
- the "values and conditions" column specifies the allowed header - the "values and conditions" column specifies the allowed header
values and the conditions for the header to be present in a values and the conditions for the header to be present in a
request/response. request/response.
The table for "request headers" does not have columns for responses, and The table for "request headers" does not have columns for responses,
the table for "response headers" does not have columns for requests. and the table for "response headers" does not have columns for
requests.
The following is an explanation of the values in the "request/client" The following is an explanation of the values in the "request/client"
and "response/ server" columns. and "response/ server" columns.
- must: the client or server MUST send the header, - must: the client or server MUST send the header,
Expires November 30, 2000
- must-if: the client or server MUST send the header when the - must-if: the client or server MUST send the header when the
condition described in the "values and conditions" column is met, condition described in the "values and conditions" column is
met,
- may: the client or server MAY send the header - may: the client or server MAY send the header
- not: the client or server SHOULD NOT send the header. It is not - not: the client or server SHOULD NOT send the header. It is not
relevant to an IPP implementation. relevant to an IPP implementation.
The following is an explanation of the values in the "response/client" The following is an explanation of the values in the
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- must not must not "no-cache" only
Control Control
Connection must-if must must- must "close" only. Both Connection must- must must- must "close" only. Both
if client and server if if client and server SHOULD
SHOULD keep a keep a connection for
connection for the the duration of a
duration of a sequence sequence of operations.
of operations. The The client and server
client and server MUST MUST include this header
include this header
for the last operation for the last operation
in such a sequence. 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 from RFC 2616 [RFC2616]
[RFC2616]
Pragma must not must not "no-cache" only Pragma must not must not "no-cache" only
Transfer- must-if must must- must "chunked" only . Transfer- must- must must- must "chunked" only . Header
Encoding if Header MUST be present Encoding if if MUST be present if
if Content-Length is Content-Length is
absent. absent.
Upgrade not not not not Upgrade not not not not
Expires November 30, 2000
General- Request Response V alues and Conditions
Header
Client Server Server Client
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-Header Client Server Request Values and Conditions Request- Client Server Request Values and Conditions
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 value is the default if the client
client omits it omits it
Accept-Charset not not Charset information is within Accept- not not Charset information is within the
the application/ipp entity Charset application/ipp entity
Accept-Encoding may must empty and per RFC 2616 [RFC2616] Accept- may must empty and per RFC 2616 [RFC2616]
and IANA registry for content- Encoding and IANA registry for content-
codings codings
Accept-Language not not language information is within Accept- not not language information is within the
the application/ipp entity Language application/ipp entity
Authorization must-if must per RFC 2616. A client MUST send Authorization must- must per RFC 2616. A client MUST send
this header when it receives a if this header when it receives a 401
401 "Unauthorized" response and "Unauthorized" response and does
does not receive a "Proxy- 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, it
is not very useful 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
Expires November 30, 2000
Request-Header Client Server Request Values and Conditions
If-Range not not If-Range not not
If-Unmodified- not not If- not not
Unmodified-
Since Since
Max-Forwards not not Max-Forwards not not
Proxy- must-if not per RFC 2616. A client MUST send Proxy- must- not per RFC 2616. A client MUST send
Authorization this header when it receives a Authorization if this header when it receives a 401
401 "Unauthorized" response and a "Unauthorized" response and a
Request- Client Server Request Values and Conditions
Header
"Proxy-Authenticate" header. "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-if may per RFC 2616. When URI needs Location must- may per RFC 2616. When URI needs
redirection. if redirection.
Proxy- not must per RFC 2616 Proxy- not must per RFC 2616
Authenticate Authenticate
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
Expires November 30, 2000 WWW- must- must per RFC 2616. When a server needs
Authenticate if to authenticate a client.
Response- Server Client Response Values and Conditions
Header
WWW- must-if must per RFC 2616. When a server needs to
Authenticate 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 Conditions Entity-Header Request Response Values and
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 IANA Content- may must must must per RFC 2616 and
Encoding registry for content Encoding IANA registry for
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-if must must-if must the length of the Content- must- must must- must the length of the
Length message-body per RFC Length if if message-body per
2616. Header MUST be RFC 2616. Header
present if Transfer- MUST be present if
Encoding is absent.. Transfer-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
Expires November 30, 2000
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 the IPP implementations consist of an HTTP layer and an IPP layer. In
following discussion, the term "client" refers to the HTTP client layer the following discussion, the term "client" refers to the HTTP client
and the term "server" refers to the HTTP server layer. The Encoding and layer and the term "server" refers to the HTTP server layer. The
Transport document [IPP-PRO] requires that HTTP 1.1 MUST be supported by Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
all clients and all servers. However, a client and/or a server be supported by all clients and all servers. However, a client
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 the (non-conforming) client that only supports HTTP 1.0. In such cases
server should not use any HTTP 1.1 specific parameters or features and the server should not use any HTTP 1.1 specific parameters or
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, if (non-conforming) server that only supports HTTP 1.0. In such cases,
the server responds with an HTTP 'unsupported version number' to an HTTP if the server responds with an HTTP 'unsupported version number' to
1.1 request, the client should retry using HTTP version number 1.0. an HTTP 1.1 request, the client should retry using HTTP version
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 and Clients MUST anticipate that the HTTP/1.1 server may chunk responses
MUST accept them in responses. However, a (non-conforming) HTTP client and MUST accept them in responses. However, a (non-conforming) HTTP
that is unable to accept chunked responses may attempt to request an client that is unable to accept chunked responses may attempt to
HTTP 1.1 server not to use chunking in its response to an operation by request an HTTP 1.1 server not to use chunking in its response to an
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 from This mechanism should not be used by a server to disable a client
chunking a request, since chunking of document data is an important from chunking a request, since chunking of document data is an
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 support The HTTP/1.1 standard [RFC2616] requires that conforming servers
chunked requests for any method. However, in spite of this requirement, support chunked requests for any method. However, in spite of this
some HTTP/1.1 implementations support chunked responses in the GET requirement, some HTTP/1.1 implementations support chunked responses
method, but do not support chunked POST method requests. Some HTTP/1.1 in the GET method, but do not support chunked POST method requests.
implementations that support CGI scripts [CGI] and/or servlets [Servlet] Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
servlets [Servlet] require that the client supply a Content-Length.
Expires November 30, 2000 These implementations might reject a chunked POST method and return a
411 status code (Length Required), might attempt to buffer the
require that the client supply a Content-Length. These implementations request and run out of room returning a 413 status code (Request
might reject a chunked POST method and return a 411 status code (Length Entity Too Large), or might successfully accept the chunked request.
Required), might attempt to buffer the request and run out of room
returning a 413 status code (Request Entity Too Large), or might
successfully accept the chunked request.
Because of this lack of conformance of HTTP servers to the HTTP/1.1 Because of this lack of conformance of HTTP servers to the HTTP/1.1
standard, the IPP standard [IPP-PRO] 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 support implementers are warned to seek HTTP server implementations that
chunked POST requests in order to conform to the IPP standard and/or use support chunked POST requests in order to conform to the IPP standard
implementation techniques that support chunked POST requests. and/or use implementation techniques that support chunked POST
requests.
8 References 8 References
[CGI] [CGI]
CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11- CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11-
00.txt). 00.txt).
[IPP-MOD]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", draft-ietf-
ipp-model-v11-06.txt, March 1, 2000.
[IPP-PRO]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-protocol-v11-
05.txt, March 1, 2000.
[ldap-printer] [ldap-printer]
Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing
Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp- Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp-
ldap-printer-schema-01.txt>, work in progress, April 27, 2000. ldap-printer-schema-01.txt>, work in progress, April 27, 2000.
[RFC793] [RFC793]
J. Postel, "Transmission Control Protocol", RFC 793. J. Postel, "Transmission Control Protocol", RFC 793.
[RFC1123] [RFC1123]
Braden, S., "Requirements for Internet Hosts - Application and Braden, S., "Requirements for Internet Hosts - Application and
Support", RFC 1123, October, 1989. Support", RFC 1123, October, 1989.
[RFC2026] [RFC2026]
S. Bradner, "The Internet Standards Process -- Revision 3", RFC S. Bradner, "The Internet Standards Process -- Revision 3", RFC
2026, October 1996. 2026, October 1996.
[RFC2119] [RFC2119]
Expires November 30, 2000
S. Bradner, "Key words for use in RFCs to Indicate Requirement S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 , March 1997. Levels", RFC 2119 , March 1997.
[RFC2396] [RFC2396]
Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2565] [RFC2565]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999. April 1999.
[RFC2566] [RFC2566]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2567] [RFC2567]
Wright, D., "Design Goals for an Internet Printing Protocol", Wright, D., "Design Goals for an Internet Printing Protocol",
draft-ietf-ipp-req-03.txt, November, 1998. draft-ietf-ipp-req-03.txt, November, 1998.
[RFC2568 [RFC2568
Zilles, S., "Rationale for the Structure and Model and Protocol for Zilles, S., "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", RFC 2568, April 1999. the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2569] [RFC2569]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
LPD and IPP Protocols", RFC 2569, April 1999. LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2616] [RFC2616]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999. RFC 2616, June 1999.
[RFC2910]
Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000.
[RFC2911]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2911,
September, 2000.
[Servlet] [Servlet]
Servlet Specification Version 2.1 Servlet Specification Version 2.1
(http://java.sun.com/products/servlet/2.1/index.html). (http://java.sun.com/products/servlet/2.1/index.html).
[svrloc-printer] [svrloc-printer]
St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the
Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer- Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer-
scheme-06.txt>, work in progress, March 8, 2000. scheme-06.txt>, work in progress, March 8, 2000.
[SSL] [SSL]
Netscape, The SSL Protocol, Version 3, (Text version 3.02), Netscape, The SSL Protocol, Version 3, (Text version 3.02),
November 1996. November 1996.
9 Authors' Address 9 Authors' Address
Expires November 30, 2000
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 hastings@cp10.es.xerox.com
Carl-Uno Manros Carl-Uno Manros
Xerox Corporation Xerox Corporation
701 Aviation Blvd. 701 Aviation Blvd.
El Segundo, CA 90245 El Segundo, CA 90245
skipping to change at page 83, line 36 skipping to change at page 86, line 26
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 hh@I-data.com
Peter Zehler Peter Zehler
Xerox Corporation Xerox Corporation
800 Philips Road 800 Philips Road
Webster, NY 14580 Webster, NY 14580
Phone: 716 265-8755
peter.zehler@usa.xerox.com peter.zehler@usa.xerox.com
10 Notices 10 Full Copyright Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11[BCP-11]. Copies of claims
of rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the
IETF Secretariat.
Expires November 30, 2000
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights,
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
Copyright (C) The Internet Society (1999). All Rights Reserved Copyright (C) The Internet Society (1999). 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 or others, and derivative works that comment on or otherwise explain it
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are included kind, provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
may not be modified in any way, such as by removing the copyright notice document itself may not be modified in any way, such as by removing
or references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of
which case the procedures for copyrights defined in the Internet developing Internet standards in which case the procedures for
Standards process must be followed, or as required to translate it into copyrights defined in the Internet Standards process must be
languages other than English. followed, or as required to translate it into languages other than
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 "AS This document and the information contained herein is provided on an
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires November 30, 2000 Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/